From nobody Sat Nov 1 02:00:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46711A6F3C for ; Sat, 1 Nov 2014 02:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzla01pUoBDq for ; Sat, 1 Nov 2014 02:00:15 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id F3D021A6EF4 for ; Sat, 1 Nov 2014 02:00:14 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id D558D1EB84A8; Sat, 1 Nov 2014 10:00:13 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Sat, 1 Nov 2014 10:00:13 +0100 From: "Stach, Thomas" To: Paul Kyzivat , Christer Holmberg Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology Thread-Index: AQHP75C+xP9ueOyQhU+z/AR0yQ5D5JxKkmqJgADtcuA= Date: Sat, 1 Nov 2014 09:00:13 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8236@ESESSMB209.ericsson.se> <5453D54B.3020209@alum.mit.edu> In-Reply-To: <5453D54B.3020209@alum.mit.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/asPlFGg74t1fV9cjGhZSLRCr58c Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 09:00:18 -0000 Paul, > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Freitag, 31. Oktober 2014 19:31 > To: Christer Holmberg; Stach, Thomas > Cc: 'mmusic' > Subject: Re: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12= - > Terminology >=20 > On 10/25/14 10:31 AM, Christer Holmberg wrote: > > Hi, > > > > I'd like to hear Paul's opinions on this, because he is the one who > > suggested the current terminology. >=20 > Sorry to be so slow responding. >=20 > I've looked back at the thread, and I am not entirely clear what the > proposal is. In part it is replacing "BUNDLE mid" with "BUNDLE-tag". >=20 > Looking at where "BUNDLE mid" is used, it is mostly in constructs like: >=20 > In the offer, the address assigned to the "m=3D" line associated with > the offerer suggested BUNDLE mid indicates the address that the >=20 > Given the definition that Thomas proposed, that would still work with > the change, but ISTM the linkage from "mid" to "m=3D" line is a little > more obvious than from "tag" to "m=3D" line. My proposal to call that thing "tag" comes from the RFC5888 ABNF group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) mid-attribute =3D "a=3Dmid:" identification-tag Here "mid" is the name of an attribute, the values that we are talking abou= t are carried in the "identification-tag" With this linkage to 5888, we would have a more precise definition.=20 >=20 > I don't know if Thomas was intending that there would still be > definitions for "Offerer suggested BUNDLE-tag" and "Answerer selected > BUNDLE-tag". I think we would still need those. [TS] I would have used just a single term and made the semantics of suggest= ed vs. selected clear=20 from the surrounding text in the remainder of the document.=20 But that is already deep in the field of personal style and preferences.=20 I would be ok with two terms, especially with the change to "Offerer sugges= ted BUNDLE-tag/mid".=20 The corresponding edits that Christer suggested make the text already much = clearer. >=20 > As an alternative, perhaps a definition of "BUNDLE mid" could be added, > that has much of the text from Thomas' definition of "BUNDLE-tag". Having such a definition would be good.=20 In the proposed text, I tried to give some guidance to the reader how this = thing is used in the remainder of the text. Thanks=20 Thomas >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > > *Sent:* 24 October 2014 16:45 > > *To:* Christer Holmberg > > *Cc:* 'mmusic' > > *Subject:* RE: WGLC comments on > > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology > > > > Hi, > > > > There has been many long discussions in order to come up with the > > terminology. > > > > */[TS] I know that much effort was already put into that. /* > > > > *//* > > > > Also, > > > > considering the number of editorial re-structures that have already > > taken place, and the impact this would have on the document, I would > > suggest to NOT do the change. > > > > */[TS] I understand that there is not much appetite for putting more > > editorial work into the document./* > > > > */Nevertheless, I still think that understanding the text is still > > unnecessarily cumbersome, /* > > > > */which in turn could lead to unnecessary misinterpretations during > > implementation./* > > > > */But maybe it is just me, who has this problem, in which case I > > probably just have to improve my reading skills. ;-) /* > > > > But, if you think the existing definitions can be clarified, we can > > discuss that. > > > > */[TS] Well, considering reuse of the RFC5888 terminology might be stil= l > > worthwhile./* > > > > */That would e.g. include replacing "mid attribute value" with > > "identification-tag", etc./* > > > > *//* > > > > Regards, > > > > Christer > > > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > > *Sent:* 23 October 2014 18:34 > > *To:* Christer Holmberg > > *Cc:* 'mmusic' > > *Subject:* WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 > > - Terminology > > > > All > > > > Terminology > > > > Offerer suggested BUNDLE mid: The first mid value in a given SDP > > > > 'group:BUNDLE' attribute mid list in an offer. > > > > and > > > > Answerer selected BUNDLE mid: The first mid value in a given SDP > > > > 'group:BUNDLE' attribute mid list in an answer. > > > > These terms are not very intuitive and make the reading the related tex= t > > quite cumbersome. > > > > Since you are talking about the identification-tags from RFC5888 > > > > group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) > > > > mid-attribute =3D "a=3Dmid:" identification-tag > > > > may I suggest re-using that terminology and propose using a single, mor= e > > pregnant term for both > > > > together with additional explanation? > > > > E.g. > > > > BUNDLE-tag: The first element in the list of identification-tags of > > > > a 'group:' attribute [RFC5888] with BUNDLE semantics. > > > > This tag has special significance in that it identifies > > > > the m-line that carries the suggested or selected BUNDLE > > address. > > > > The corresponding m-line will carry the same tag in a 'mid= ' > > attribute. > > > > The offerer suggests a BUNDLE tag. The answerer preferably > > accepts > > > > the suggested BUNDLE-tag, but could select a different > > > > BUNDLE-tag, if necessary. > > > > Example: > > > > If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' wou= ld > > be the > > > > BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE ad= dress. > > > > If there is appetite for changing that terminology, I understand that i= t > > would cause quite a few > > > > other editorial changes in the remainder of the document. > > > > In order to not delay progress of the draft, I can only offer to help i= n > > any editorial effort and would be happy to propose changed text. > > > > Regards > > > > Thomas > > From nobody Sun Nov 2 07:07:33 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95801A891D for ; Sun, 2 Nov 2014 07:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffQS6EtT6R6v for ; Sun, 2 Nov 2014 07:07:26 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2778D1A8834 for ; Sun, 2 Nov 2014 07:07:26 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 61B03F1C27E20 for ; Sun, 2 Nov 2014 15:07:20 +0000 (GMT) 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 sA2F7NUv028562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 2 Nov 2014 16:07:23 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 2 Nov 2014 16:07:23 +0100 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: Ac/x88lK6mpn4HE9TuemRholN7+6tQEucedQ Date: Sun, 2 Nov 2014 15:07:22 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/X6sBSGfNTZ6TOAHUwvyRq6kf9YI Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 15:07:30 -0000 At the London IETF meeting, we were not quite at the point of asking for ad= option of draft-ejzak-mmusic-data-channel-sdpneg. There was a request that = certain revisions should be made and a couple of issues addressed. That has now occurred. I would like to ask if we can now moved forward to adoption of this draft a= s a working group item. While it is the responsibility of the chairs to mak= e a formal call, I have asked for a small amount of time in Honolulu with t= his intent, and it would be useful if people could start to express their o= pinions one way or other on the list, i.e. whether they think the draft is = generally useful, or alternatively, just a bad idea! Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: 27 October 2014 14:39 > To: mmusic@ietf.org > Subject: draft-ejzak-mmusic-data-channel-sdpneg and=20 > draft-ejzak-mmusic-msrp-usage-data-channel >=20 > Based on the discussion on list over the last few days, I=20 > have submitted revised versions of the two SDP negotiation=20 > over data channel drafts as follows: >=20 > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to=20 > the IETF repository. >=20 > Name: draft-ejzak-mmusic-data-channel-sdpneg > Revision: 02 > Title: SDP-based "SCTP over DTLS" data channel=20 > negotiation > Document date: 2014-10-27 > Group: Individual Submission > Pages: 22 > URL: =20 > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch > annel-sdpneg-02.txt > Status: =20 > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann > el-sdpneg/ > Htmlized: =20 > http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff: =20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-chann > el-sdpneg-02 >=20 > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb)=20 > working group is > charged to provide protocols to support direct interactive rich > communications using audio, video, and data between two peers' web- > browsers. For the support of data communication, the=20 > RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. Data=20 > channel setup > can be done using either the internal in-band band (also=20 > referred to > as 'internal' for the rest of the document) WebRTC Data Channel > Establishment Protocol or some external out-of-band simply referred > to as 'external negotiation' in the rest of the document . This > document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation. Even though data=20 > channels are > designed for RTCWeb use initially they may be used by=20 > other protocols > like, but not limited to, the CLUE protocol. This document is > intended to be used wherever data channels are used. >=20 >=20 > A new version of I-D,=20 > draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > has been successfully submitted by Keith Drage and posted to=20 > the IETF repository. >=20 > Name: draft-ejzak-mmusic-msrp-usage-data-channel > Revision: 01 > Title: MSRP over SCTP/DTLS data channels > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: =20 > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us > age-data-channel-01.txt > Status: =20 > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage > -data-channel/ > Htmlized: =20 > http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data- > channel-01 > Diff: =20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-usage > -data-channel-01 >=20 > Abstract: > This document specifies how the Message Session Relay=20 > Protocol (MSRP) > can be instantiated as a data channel sub-protocol, using=20 > the the SDP > offer/answer exchange-based external negotiation defined in > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > are documented: a WebRTC end-to-end configuration (connecting two > MSRP over data channel endpoints), and a gateway configuration > (connecting an MSRP over data channel endpoint with an=20 > MSRP over TCP > endpoint).= From nobody Sun Nov 2 07:50:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8D71A88DF for ; Sun, 2 Nov 2014 07:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0tSsOxVZ8-q for ; Sun, 2 Nov 2014 07:50:22 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA751A88DB for ; Sun, 2 Nov 2014 07:50:21 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-ee-545652bbfbc8 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4C.77.04081.BB256545; Sun, 2 Nov 2014 16:50:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Sun, 2 Nov 2014 16:50:19 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: AQHP9rSzZdrUsx48CkiSVfsREDM7hQ== Date: Sun, 2 Nov 2014 15:50:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4DE52A@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4DE52AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje7uoLAQg8NrtC2eNp5ltJi6/DGL A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4fOsbc8GWkorbEwsbGLtSuhg5OSQETCRu 3nrKCmGLSVy4t56ti5GLQ0jgCKNE48vVrBDOYkaJMx9mM3cxcnCwCVhIdP/TBmkQEUiS2Db5 DjuILSyQK3Fs33MmiHiexMt7S5ghbD2Jrx/PsoDYLAIqEgd2XAOr4RXwlbi/9QQjiC0kECVx au07sDmcAtESr6ctAoszAh30/dQasHpmAXGJpi8roQ4VkFiy5zwzhC0q8fLxP1aImnyJSysW M0PMF5Q4OfMJywRG4VlI2mchKZuFpAwibiDx5f1tKFtbYtnC18wQtr5E9/vTTMjiCxjZVzGK FqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERs/BLb8NdjC+fO54iFGAg1GJh7fgWmiIEGtiWXFl 7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgXPWGnaElYeMch5Y3Uy2E zKc7SjZ9O8B7O9B0tg87j/45nqKLjd/zj02StJyx6gqzW+uXwJ89Pl/WeE38E3Bs88YpPgdF LzxOjWJN2HmzZvfnaffnVb9d+eBeTm7M75cNCyKzIiL8JibNrO5Z3B+6Ycqdw2lXPMP/m/f3 mL24YV0q+boynf/gdiWW4oxEQy3mouJEALCOkW1/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hraqwxjGRkjqB_26nMV7cX0zcw0 Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 15:50:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4DE52AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I think the draft is useful, and I support adopting it as a WG item. I also= intend to be active in the work, review and provide comments, etc. Regards, Christer Sent from my Windows Phone ________________________________ From: DRAGE, Keith (Keith) Sent: =FD02/=FD11/=FD2014 17:07 To: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejza= k-mmusic-msrp-usage-data-channel At the London IETF meeting, we were not quite at the point of asking for ad= option of draft-ejzak-mmusic-data-channel-sdpneg. There was a request that = certain revisions should be made and a couple of issues addressed. That has now occurred. I would like to ask if we can now moved forward to adoption of this draft a= s a working group item. While it is the responsibility of the chairs to mak= e a formal call, I have asked for a small amount of time in Honolulu with t= his intent, and it would be useful if people could start to express their o= pinions one way or other on the list, i.e. whether they think the draft is = generally useful, or alternatively, just a bad idea! Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 27 October 2014 14:39 > To: mmusic@ietf.org > Subject: draft-ejzak-mmusic-data-channel-sdpneg and > draft-ejzak-mmusic-msrp-usage-data-channel > > Based on the discussion on list over the last few days, I > have submitted revised versions of the two SDP negotiation > over data channel drafts as follows: > > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to > the IETF repository. > > Name: draft-ejzak-mmusic-data-channel-sdpneg > Revision: 02 > Title: SDP-based "SCTP over DTLS" data channel > negotiation > Document date: 2014-10-27 > Group: Individual Submission > Pages: 22 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch > annel-sdpneg-02.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann > el-sdpneg/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-chann > el-sdpneg-02 > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) > working group is > charged to provide protocols to support direct interactive rich > communications using audio, video, and data between two peers' web- > browsers. For the support of data communication, the > RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. Data > channel setup > can be done using either the internal in-band band (also > referred to > as 'internal' for the rest of the document) WebRTC Data Channel > Establishment Protocol or some external out-of-band simply referred > to as 'external negotiation' in the rest of the document . This > document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation. Even though data > channels are > designed for RTCWeb use initially they may be used by > other protocols > like, but not limited to, the CLUE protocol. This document is > intended to be used wherever data channels are used. > > > A new version of I-D, > draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > has been successfully submitted by Keith Drage and posted to > the IETF repository. > > Name: draft-ejzak-mmusic-msrp-usage-data-channel > Revision: 01 > Title: MSRP over SCTP/DTLS data channels > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us > age-data-channel-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage > -data-channel/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data- > channel-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-usage > -data-channel-01 > > Abstract: > This document specifies how the Message Session Relay > Protocol (MSRP) > can be instantiated as a data channel sub-protocol, using > the the SDP > offer/answer exchange-based external negotiation defined in > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > are documented: a WebRTC end-to-end configuration (connecting two > MSRP over data channel endpoints), and a gateway configuration > (connecting an MSRP over data channel endpoint with an > MSRP over TCP > endpoint). _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D4DE52AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I think the draft is useful, and I support adopting it as a WG item. I also= intend to be active in the work, review and provide comments, etc.

Regards,

Christer

Sent from my Windows Phone
From: DRAGE, Keith (Keith)
Sent: =FD02= /=FD11/=FD2014 17:07
To: mmusic@ietf.org
Subject: Re: [= MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-= usage-data-channel

At the London IETF meeting, we were not quite at t= he point of asking for adoption of draft-ejzak-mmusic-data-channel-sdpneg. = There was a request that certain revisions should be made and a couple of i= ssues addressed.

That has now occurred.

I would like to ask if we can now moved forward to adoption of this draft a= s a working group item. While it is the responsibility of the chairs to mak= e a formal call, I have asked for a small amount of time in Honolulu with t= his intent, and it would be useful if people could start to express their opinions one way or other on the li= st, i.e. whether they think the draft is generally useful, or alternatively= , just a bad idea!

Regards

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith)
> Sent: 27 October 2014 14:39
> To: mmusic@ietf.org
> Subject: draft-ejzak-mmusic-data-channel-sdpneg and
> draft-ejzak-mmusic-msrp-usage-data-channel
>
> Based on the discussion on list over the last few days, I
> have submitted revised versions of the two SDP negotiation
> over data channel drafts as follows:
>
> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to
> the IETF repository.
>
> Name:         draft-ejzak-mmus= ic-data-channel-sdpneg
> Revision:     02
> Title:          &nbs= p;     SDP-based "SCTP over DTLS" data channe= l
> negotiation
> Document date:        2014-10-27 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     22
> URL:           =
> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch
> annel-sdpneg-02.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann
> el-sdpneg/
> Htmlized:      
> http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff:          
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-chann=
> el-sdpneg-02
>
> Abstract:
>    The Real-Time Communication in WEB-browsers (RTCWeb)=
> working group is
>    charged to provide protocols to support direct inter= active rich
>    communications using audio, video, and data between = two peers' web-
>    browsers.  For the support of data communicatio= n, the
> RTCWeb working
>    group has in particular defined the concept of bi-di= rectional data
>    channels over SCTP, where each data channel might be= used to
>    transport other protocols, called sub-protocols.&nbs= p; Data
> channel setup
>    can be done using either the internal in-band band (= also
> referred to
>    as 'internal' for the rest of the document) WebRTC D= ata Channel
>    Establishment Protocol or some external out-of-band = simply referred
>    to as 'external negotiation' in the rest of the docu= ment . This
>    document specifies how the SDP offer/answer exchange= can be used to
>    achieve such an external negotiation.  Even tho= ugh data
> channels are
>    designed for RTCWeb use initially they may be used b= y
> other protocols
>    like, but not limited to, the CLUE protocol.  T= his document is
>    intended to be used wherever data channels are used.=
>
>
> A new version of I-D,
> draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
> has been successfully submitted by Keith Drage and posted to
> the IETF repository.
>
> Name:         draft-ejzak-mmus= ic-msrp-usage-data-channel
> Revision:     01
> Title:          &nbs= p;     MSRP over SCTP/DTLS data channels
> Document date:        2014-10-27 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     11
> URL:           =
> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us
> age-data-channel-01.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage
> -data-channel/
> Htmlized:      
> http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-
> channel-01
> Diff:          
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-usage=
> -data-channel-01
>
> Abstract:
>    This document specifies how the Message Session Rela= y
> Protocol (MSRP)
>    can be instantiated as a data channel sub-protocol, = using
> the the SDP
>    offer/answer exchange-based external negotiation def= ined in
>    [I-D.ejzak-mmusic-data-channel-sdpneg].  Two ne= twork configurations
>    are documented: a WebRTC end-to-end configuration (c= onnecting two
>    MSRP over data channel endpoints), and a gateway con= figuration
>    (connecting an MSRP over data channel endpoint with = an
> MSRP over TCP
>    endpoint).
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1D4DE52AESESSMB209erics_-- From nobody Sun Nov 2 08:37:01 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBA81A8946 for ; Sun, 2 Nov 2014 08:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.972] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLccxzG3g17f for ; Sun, 2 Nov 2014 08:36:58 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E156E1A0065 for ; Sun, 2 Nov 2014 08:36:55 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-12v.sys.comcast.net with comcast id Agc51p00B516pyw01gcv5X; Sun, 02 Nov 2014 16:36:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id Agcu1p00H3Ge9ey01gcuqm; Sun, 02 Nov 2014 16:36:55 +0000 Message-ID: <54565DA6.7060706@alum.mit.edu> Date: Sun, 02 Nov 2014 11:36:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414946215; bh=lvIupg8IGCr3oylv02/ZD4x3DkechglAjVUnekyy+kk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QVL0z10Bj/vZJOhEiUufs6KqGFNhPb7gbRyEGckRPOZUr9xejlPdvRZYRvDv0mHAe lZNMRblCwXajlMzoiVSrLP7muht79s8fa4F0keEsliq9XYZAN5B2Km/x0ow/BFwy+u u5YiMwjBflJaKw+Bz4JjPmFMbkuYWX93il6n034T68gUcTWSw3fOjZwRIkLQh7DTcS 9VsZTB61RXMumHo2o2LhJCSdMuWYW61GES8bMHSrvgWws2FehCzlO0QG0imqCvZg51 HqMk4B9pv1Cl3HHkGfPX994uFc7IBhpTIYmpzfXPeldHGDz2hXBFqnpeOjWHPb2C3H nP5qEJr8qoLNg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8yAWNrE0o1JHV48RbJQY-ESzW0k Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 16:37:00 -0000 On 11/2/14 10:07 AM, DRAGE, Keith (Keith) wrote: > At the London IETF meeting, we were not quite at the point of asking for adoption of draft-ejzak-mmusic-data-channel-sdpneg. There was a request that certain revisions should be made and a couple of issues addressed. > > That has now occurred. > > I would like to ask if we can now moved forward to adoption of this draft as a working group item. While it is the responsibility of the chairs to make a formal call, I have asked for a small amount of time in Honolulu with this intent, and it would be useful if people could start to express their opinions one way or other on the list, i.e. whether they think the draft is generally useful, or alternatively, just a bad idea! I support adopting this draft. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: DRAGE, Keith (Keith) >> Sent: 27 October 2014 14:39 >> To: mmusic@ietf.org >> Subject: draft-ejzak-mmusic-data-channel-sdpneg and >> draft-ejzak-mmusic-msrp-usage-data-channel >> >> Based on the discussion on list over the last few days, I >> have submitted revised versions of the two SDP negotiation >> over data channel drafts as follows: >> >> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt >> has been successfully submitted by Keith Drage and posted to >> the IETF repository. >> >> Name: draft-ejzak-mmusic-data-channel-sdpneg >> Revision: 02 >> Title: SDP-based "SCTP over DTLS" data channel >> negotiation >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 22 >> URL: >> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch >> annel-sdpneg-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann >> el-sdpneg/ >> Htmlized: >> http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-chann >> el-sdpneg-02 >> >> Abstract: >> The Real-Time Communication in WEB-browsers (RTCWeb) >> working group is >> charged to provide protocols to support direct interactive rich >> communications using audio, video, and data between two peers' web- >> browsers. For the support of data communication, the >> RTCWeb working >> group has in particular defined the concept of bi-directional data >> channels over SCTP, where each data channel might be used to >> transport other protocols, called sub-protocols. Data >> channel setup >> can be done using either the internal in-band band (also >> referred to >> as 'internal' for the rest of the document) WebRTC Data Channel >> Establishment Protocol or some external out-of-band simply referred >> to as 'external negotiation' in the rest of the document . This >> document specifies how the SDP offer/answer exchange can be used to >> achieve such an external negotiation. Even though data >> channels are >> designed for RTCWeb use initially they may be used by >> other protocols >> like, but not limited to, the CLUE protocol. This document is >> intended to be used wherever data channels are used. >> >> >> A new version of I-D, >> draft-ejzak-mmusic-msrp-usage-data-channel-01.txt >> has been successfully submitted by Keith Drage and posted to >> the IETF repository. >> >> Name: draft-ejzak-mmusic-msrp-usage-data-channel >> Revision: 01 >> Title: MSRP over SCTP/DTLS data channels >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us >> age-data-channel-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage >> -data-channel/ >> Htmlized: >> http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data- >> channel-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage >> -data-channel-01 >> >> Abstract: >> This document specifies how the Message Session Relay >> Protocol (MSRP) >> can be instantiated as a data channel sub-protocol, using >> the the SDP >> offer/answer exchange-based external negotiation defined in >> [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations >> are documented: a WebRTC end-to-end configuration (connecting two >> MSRP over data channel endpoints), and a gateway configuration >> (connecting an MSRP over data channel endpoint with an >> MSRP over TCP >> endpoint). > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sun Nov 2 08:51:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179091A9081 for ; Sun, 2 Nov 2014 08:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E96yC4-dicYD for ; Sun, 2 Nov 2014 08:51:03 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259EA1A8965 for ; Sun, 2 Nov 2014 08:51:03 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 7f066545.2b7b16a90940.8014653.00-2455.22500254.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 02 Nov 2014 16:51:03 +0000 (UTC) X-MXL-Hash: 545660f716444867-3883d32d698d2359839be7ee96c921c5f4db6563 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 5f066545.0.8014646.00-2209.22500229.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 02 Nov 2014 16:51:02 +0000 (UTC) X-MXL-Hash: 545660f630aba0eb-a13aaf378c774ab08e36e16ff92edb61cf3651e4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sA2Gp09f027278; Sun, 2 Nov 2014 11:51:01 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sA2Gogi9026023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Nov 2014 11:50:53 -0500 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sun, 2 Nov 2014 16:50:24 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.207]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0195.001; Sun, 2 Nov 2014 11:50:24 -0500 From: "DOLLY, MARTIN C" To: Christer Holmberg , "DRAGE, Keith (Keith)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: Ac/x88lK6mpn4HE9TuemRholN7+6tQEucedQAAxC0AAACH/wMA== Date: Sun, 2 Nov 2014 16:50:23 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4DE52A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4DE52A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.203.187] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656032BA307MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=X9rl3hve c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=lEem9tHVhq4A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=EA-3BgdeT4f] X-AnalysisOut: [5u35CVzYA:9 a=F99EeyZzka0A:10 a=vgoIte4AP48YRrX-:21 a=dsQ-] X-AnalysisOut: [oLOqGyWLPCqW:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=-ktmRL] X-AnalysisOut: [i88tn7qcr3tWQA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZ] X-AnalysisOut: [eC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=_3D9Vb7sS_5CwDjo:21 a=nal] X-AnalysisOut: [c3KPwRDmc6blW:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f6ab8MUFrYR_tCogcLnRT6gCLNg Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 16:51:06 -0000 --_000_E42CCDDA6722744CB241677169E83656032BA307MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I support this as a WG item. From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Sunday, November 02, 2014 10:50 AM To: DRAGE, Keith (Keith); mmusic@ietf.org Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejza= k-mmusic-msrp-usage-data-channel Hi, I think the draft is useful, and I support adopting it as a WG item. I also= intend to be active in the work, review and provide comments, etc. Regards, Christer Sent from my Windows Phone ________________________________ From: DRAGE, Keith (Keith) Sent: =FD02/=FD11/=FD2014 17:07 To: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejza= k-mmusic-msrp-usage-data-channel At the London IETF meeting, we were not quite at the point of asking for ad= option of draft-ejzak-mmusic-data-channel-sdpneg. There was a request that = certain revisions should be made and a couple of issues addressed. That has now occurred. I would like to ask if we can now moved forward to adoption of this draft a= s a working group item. While it is the responsibility of the chairs to mak= e a formal call, I have asked for a small amount of time in Honolulu with t= his intent, and it would be useful if people could start to express their o= pinions one way or other on the list, i.e. whether they think the draft is = generally useful, or alternatively, just a bad idea! Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 27 October 2014 14:39 > To: mmusic@ietf.org > Subject: draft-ejzak-mmusic-data-channel-sdpneg and > draft-ejzak-mmusic-msrp-usage-data-channel > > Based on the discussion on list over the last few days, I > have submitted revised versions of the two SDP negotiation > over data channel drafts as follows: > > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to > the IETF repository. > > Name: draft-ejzak-mmusic-data-channel-sdpneg > Revision: 02 > Title: SDP-based "SCTP over DTLS" data channel > negotiation > Document date: 2014-10-27 > Group: Individual Submission > Pages: 22 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch > annel-sdpneg-02.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann > el-sdpneg/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-chann > el-sdpneg-02 > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) > working group is > charged to provide protocols to support direct interactive rich > communications using audio, video, and data between two peers' web- > browsers. For the support of data communication, the > RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. Data > channel setup > can be done using either the internal in-band band (also > referred to > as 'internal' for the rest of the document) WebRTC Data Channel > Establishment Protocol or some external out-of-band simply referred > to as 'external negotiation' in the rest of the document . This > document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation. Even though data > channels are > designed for RTCWeb use initially they may be used by > other protocols > like, but not limited to, the CLUE protocol. This document is > intended to be used wherever data channels are used. > > > A new version of I-D, > draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > has been successfully submitted by Keith Drage and posted to > the IETF repository. > > Name: draft-ejzak-mmusic-msrp-usage-data-channel > Revision: 01 > Title: MSRP over SCTP/DTLS data channels > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us > age-data-channel-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage > -data-channel/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data- > channel-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-usage > -data-channel-01 > > Abstract: > This document specifies how the Message Session Relay > Protocol (MSRP) > can be instantiated as a data channel sub-protocol, using > the the SDP > offer/answer exchange-based external negotiation defined in > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > are documented: a WebRTC end-to-end configuration (connecting two > MSRP over data channel endpoints), and a gateway configuration > (connecting an MSRP over data channel endpoint with an > MSRP over TCP > endpoint). _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_E42CCDDA6722744CB241677169E83656032BA307MISOUT7MSGUSRDB_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

I support this as a WG it= em.

 <= /p>

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Sunday, November 02, 2014 10:50 AM
To: DRAGE, Keith (Keith); mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and dra= ft-ejzak-mmusic-msrp-usage-data-channel

 

Hi,

I think the draft is useful, and I support adopting it as a WG item. I also= intend to be active in the work, review and provide comments, etc.

Regards,

Christer

Sent from my Windows Phone

From: D= RAGE, Keith (Keith)
Sent: =FD02/=FD11/=FD2014 17:07
To: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and dr= aft-ejzak-mmusic-msrp-usage-data-channel

At the London IETF = meeting, we were not quite at the point of asking for adoption of draft-ejz= ak-mmusic-data-channel-sdpneg. There was a request that certain revisions s= hould be made and a couple of issues addressed.

That has now occurred.

I would like to ask if we can now moved forward to adoption of this draft a= s a working group item. While it is the responsibility of the chairs to mak= e a formal call, I have asked for a small amount of time in Honolulu with t= his intent, and it would be useful if people could start to express their opinions one way or other on the li= st, i.e. whether they think the draft is generally useful, or alternatively= , just a bad idea!

Regards

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith)
> Sent: 27 October 2014 14:39
> To: mmusic@ietf.org
> Subject: draft-ejzak-mmusic-data-channel-sdpneg and
> draft-ejzak-mmusic-msrp-usage-data-channel
>
> Based on the discussion on list over the last few days, I
> have submitted revised versions of the two SDP negotiation
> over data channel drafts as follows:
>
> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to
> the IETF repository.
>
> Name:         draft-ejzak-mmus= ic-data-channel-sdpneg
> Revision:     02
> Title:          &nbs= p;     SDP-based "SCTP over DTLS" data channe= l
> negotiation
> Document date:        2014-10-27 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     22
> URL:           =
> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch
> annel-sdpneg-02.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann
> el-sdpneg/
> Htmlized:      
> http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff:          
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-chann=
> el-sdpneg-02
>
> Abstract:
>    The Real-Time Communication in WEB-browsers (RTCWeb)=
> working group is
>    charged to provide protocols to support direct inter= active rich
>    communications using audio, video, and data between = two peers' web-
>    browsers.  For the support of data communicatio= n, the
> RTCWeb working
>    group has in particular defined the concept of bi-di= rectional data
>    channels over SCTP, where each data channel might be= used to
>    transport other protocols, called sub-protocols.&nbs= p; Data
> channel setup
>    can be done using either the internal in-band band (= also
> referred to
>    as 'internal' for the rest of the document) WebRTC D= ata Channel
>    Establishment Protocol or some external out-of-band = simply referred
>    to as 'external negotiation' in the rest of the docu= ment . This
>    document specifies how the SDP offer/answer exchange= can be used to
>    achieve such an external negotiation.  Even tho= ugh data
> channels are
>    designed for RTCWeb use initially they may be used b= y
> other protocols
>    like, but not limited to, the CLUE protocol.  T= his document is
>    intended to be used wherever data channels are used.=
>
>
> A new version of I-D,
> draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
> has been successfully submitted by Keith Drage and posted to
> the IETF repository.
>
> Name:         draft-ejzak-mmus= ic-msrp-usage-data-channel
> Revision:     01
> Title:          &nbs= p;     MSRP over SCTP/DTLS data channels
> Document date:        2014-10-27 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     11
> URL:           =
> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us
> age-data-channel-01.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage
> -data-channel/
> Htmlized:      
> http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-
> channel-01
> Diff:          
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-usage=
> -data-channel-01
>
> Abstract:
>    This document specifies how the Message Session Rela= y
> Protocol (MSRP)
>    can be instantiated as a data channel sub-protocol, = using
> the the SDP
>    offer/answer exchange-based external negotiation def= ined in
>    [I-D.ejzak-mmusic-data-channel-sdpneg].  Two ne= twork configurations
>    are documented: a WebRTC end-to-end configuration (c= onnecting two
>    MSRP over data channel endpoints), and a gateway con= figuration
>    (connecting an MSRP over data channel endpoint with = an
> MSRP over TCP
>    endpoint).
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

--_000_E42CCDDA6722744CB241677169E83656032BA307MISOUT7MSGUSRDB_-- From nobody Sun Nov 2 17:01:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F541ACE7C for ; Sun, 2 Nov 2014 17:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gpKMWc8Gq2a for ; Sun, 2 Nov 2014 17:01:26 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF5F1ACE7B for ; Sun, 2 Nov 2014 17:01:25 -0800 (PST) Received: from [210.97.169.119] (port=31315 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xl60i-0001IL-0P for mmusic@ietf.org; Mon, 03 Nov 2014 12:00:44 +1100 Message-ID: <5456D3DE.9010808@nteczone.com> Date: Mon, 03 Nov 2014 12:01:18 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4DE52A@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TghfJm09_oYdVn8vgSW4ycoAtVc Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 01:01:28 -0000 I also support this as a WG item. Regards, Christian On 3/11/2014 3:50 AM, DOLLY, MARTIN C wrote: > > I support this as a WG item. > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* Sunday, November 02, 2014 10:50 AM > *To:* DRAGE, Keith (Keith); mmusic@ietf.org > *Subject:* Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and > draft-ejzak-mmusic-msrp-usage-data-channel > > Hi, > > I think the draft is useful, and I support adopting it as a WG item. I > also intend to be active in the work, review and provide comments, etc. > > Regards, > > Christer > > Sent from my Windows Phone > > ------------------------------------------------------------------------ > > *From: *DRAGE, Keith (Keith) > *Sent: *‎02/‎11/‎2014 17:07 > *To: *mmusic@ietf.org > *Subject: *Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and > draft-ejzak-mmusic-msrp-usage-data-channel > > At the London IETF meeting, we were not quite at the point of asking > for adoption of draft-ejzak-mmusic-data-channel-sdpneg. There was a > request that certain revisions should be made and a couple of issues > addressed. > > That has now occurred. > > I would like to ask if we can now moved forward to adoption of this > draft as a working group item. While it is the responsibility of the > chairs to make a formal call, I have asked for a small amount of time > in Honolulu with this intent, and it would be useful if people could > start to express their opinions one way or other on the list, i.e. > whether they think the draft is generally useful, or alternatively, > just a bad idea! > > Regards > > Keith > > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: 27 October 2014 14:39 > > To: mmusic@ietf.org > > Subject: draft-ejzak-mmusic-data-channel-sdpneg and > > draft-ejzak-mmusic-msrp-usage-data-channel > > > > Based on the discussion on list over the last few days, I > > have submitted revised versions of the two SDP negotiation > > over data channel drafts as follows: > > > > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > > has been successfully submitted by Keith Drage and posted to > > the IETF repository. > > > > Name: draft-ejzak-mmusic-data-channel-sdpneg > > Revision: 02 > > Title: SDP-based "SCTP over DTLS" data channel > > negotiation > > Document date: 2014-10-27 > > Group: Individual Submission > > Pages: 22 > > URL: > > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch > > annel-sdpneg-02.txt > > Status: > > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann > > el-sdpneg/ > > Htmlized: > > http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-chann > > el-sdpneg-02 > > > > Abstract: > > The Real-Time Communication in WEB-browsers (RTCWeb) > > working group is > > charged to provide protocols to support direct interactive rich > > communications using audio, video, and data between two peers' web- > > browsers. For the support of data communication, the > > RTCWeb working > > group has in particular defined the concept of bi-directional data > > channels over SCTP, where each data channel might be used to > > transport other protocols, called sub-protocols. Data > > channel setup > > can be done using either the internal in-band band (also > > referred to > > as 'internal' for the rest of the document) WebRTC Data Channel > > Establishment Protocol or some external out-of-band simply referred > > to as 'external negotiation' in the rest of the document . This > > document specifies how the SDP offer/answer exchange can be used to > > achieve such an external negotiation. Even though data > > channels are > > designed for RTCWeb use initially they may be used by > > other protocols > > like, but not limited to, the CLUE protocol. This document is > > intended to be used wherever data channels are used. > > > > > > A new version of I-D, > > draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > > has been successfully submitted by Keith Drage and posted to > > the IETF repository. > > > > Name: draft-ejzak-mmusic-msrp-usage-data-channel > > Revision: 01 > > Title: MSRP over SCTP/DTLS data channels > > Document date: 2014-10-27 > > Group: Individual Submission > > Pages: 11 > > URL: > > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us > > age-data-channel-01.txt > > Status: > > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage > > -data-channel/ > > Htmlized: > > http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data- > > channel-01 > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage > > -data-channel-01 > > > > Abstract: > > This document specifies how the Message Session Relay > > Protocol (MSRP) > > can be instantiated as a data channel sub-protocol, using > > the the SDP > > offer/answer exchange-based external negotiation defined in > > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > > are documented: a WebRTC end-to-end configuration (connecting two > > MSRP over data channel endpoints), and a gateway configuration > > (connecting an MSRP over data channel endpoint with an > > MSRP over TCP > > endpoint). > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Nov 3 04:18:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782771A0100 for ; Mon, 3 Nov 2014 04:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmjnX6PsIzeu for ; Mon, 3 Nov 2014 04:17:58 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4841A00FF for ; Mon, 3 Nov 2014 04:17:57 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-b7-54577273eeff Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.CE.04231.37277545; Mon, 3 Nov 2014 13:17:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Mon, 3 Nov 2014 13:17:55 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: IETF#91: BUNDLE in Hawaii Thread-Index: Ac/3X1aRfvK3oTHUTsa1cCoPsz4Q4g== Date: Mon, 3 Nov 2014 12:17:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E0032@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.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4E0032ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW5xUXiIwdqXRhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp2bn9gLeowqViz9zNLAeEe7i5GTQ0LARGLS+x2MELaYxIV7 69m6GLk4hASOMErMft7AAuEsZpTonHsVKMPBwSZgIdH9D6xZREBd4uveHmYQW1hASWLLym+s MPHDS1czQth6Eqdu3WECaWURUJHoaK8DCfMK+EqsmTmJBcRmBNr7/dQaJhCbWUBc4taT+UwQ 9whILNlznhnCFpV4+fgfK8gYCaBV07amQZTnS/y8NZcRYqSgxMmZT1gmMArNQjJpFpKyWUjK IOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wHg4uOW37g7G1a8dDzEKcDAq8fAWbA8LEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjAnfI1dUrH+VPU1WW8Neo+Pq64kzBMqPKK928D5a+ee/kN50/S7F 8G//OytiDKIqZBwqa+/8tft71unEjGmHs/MZP+SGuz5r0Vj1RPrTx8ki7bsnzsm+6OLJk/7x XhfftL89hsrlxjFpcbPmJUUpBs984mbKck99ReFDUYZQrwmTw2ay/d18T4mlOCPRUIu5qDgR AMrGpO1oAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OSVy0sTtzt1EpqBGqh5uX8qvSd0 Subject: [MMUSIC] IETF#91: BUNDLE in Hawaii X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 12:18:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4E0032ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Currently there are a couple of open technical issues in BUNDLE, for which = I don't think we have an agreement on how to move forward. I intend to bring them up in Honolulu, but the more we can do on the list b= efore that, the sooner we may be able to stop for lunch :) 1) Do we mandate symmetric RTP? 2) Usage of ICE candidates in bundle-only m- lines with zero port valu= e. In addition, I intend to present the way forward regarding whether to allow= moving sources between bundled m- lines. Colin P and Jonathan L has sugges= ted a way forward, by NOT allowing it, and nobody has objected. Text has al= so been suggested. Note that there are dedicated e-mail threads for these issues, so if you ha= ve any input please reply to those. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4E0032ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Currently there are a couple of open technical issue= s in BUNDLE, for which I don’t think we have an agreement on how to m= ove forward.

 

I intend to bring them up in Honolulu, but the more = we can do on the list before that, the sooner we may be able to stop for lu= nch :)

 

1)      Do we mandate symmetric RTP?

2)      Usage of ICE candidates in bundle-only m- lines wit= h zero port value.

 

In addition, I intend to present the way forward reg= arding whether to allow moving sources between bundled m- lines. Colin P an= d Jonathan L has suggested a way forward, by NOT allowing it, and nobody ha= s objected. Text has also been suggested.

 

Note that there are dedicated e-mail threads for = these issues, so if you have any input please reply to those.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4E0032ESESSMB209erics_-- From nobody Mon Nov 3 04:21:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0041A010A for ; Mon, 3 Nov 2014 04:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbOqjC-XRXFN for ; Mon, 3 Nov 2014 04:21:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839D11A0101 for ; Mon, 3 Nov 2014 04:21:21 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-26-5457733fd877 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.3F.04231.F3377545; Mon, 3 Nov 2014 13:21:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Mon, 3 Nov 2014 13:21:19 +0100 From: Christer Holmberg To: "'Stach, Thomas'" , Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology Thread-Index: Ac/u1sSmOrC76dpuRG2RzgUhUCSTWAACEKxAACg8ywAAOBE3oAE0CGKAAB5fIIAARaeJoA== Date: Mon, 3 Nov 2014 12:21:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E0093@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8236@ESESSMB209.ericsson.se> <5453D54B.3020209@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvja59cXiIQedpM4upyx+zWKzYcIDV 4uTObcwOzB5/339g8liy5CeTx/aexywBzFFcNimpOZllqUX6dglcGZ8W3WEsOBFQsW3LSuYG xna7LkZODgkBE4n5/76zQthiEhfurWfrYuTiEBI4wiix48dRKGcxo8TEq4+Yuxg5ONgELCS6 /2mDmCICYRKbGiRBepkF5CQ2TH7JBmILC0RK/H95lwnEFhGIkmg93cwOYYdJnOh7CWazCKhI PJjzD8zmFfCVaJ6+hRFiVROzxOrzy5lBEpwC/hK7pkwFK2IEOu77qTVMEMvEJW49mc8EcbSA xJI955khbFGJl4//sYLcJiGgJDFtaxpEuY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaxWUim zkLSMgtJyywkLQsYWVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbUwS2/dXcwrn7teIhR gINRiYe3YHtYiBBrYllxZe4hRmkOFiVx3kXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YFTc8lvCceOyA1wcpXxx9S9PGn9c2rrRvIUz4lf+ZbmGh14LdR+alcXc2yceNWe2zpyI766W T09qT44TLfQOP3VcTr7u1KHjX7+9y7q4/8mhj60RB4WUbp+/KqIXX5cwR19KcE5RI9NTnyTH rdt/fFZyrLxup72v/2vXbwbJXT9Y2ub7Zc7SfajEUpyRaKjFXFScCACRtY8wiQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/NwPXpzhLhNBv132PmhV41P-MD7Y Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 12:21:24 -0000 Hi, I started to go through BUNDLE, to look for the impacts due to changing "mi= d" to "tag". The list below is not complete, but it does give a good picture of the impa= cts. One question is whether we want to say "SDP 'mid' attribute identification-= tag value" or just "SDP 'mid' attribute value". Regards, Christer ----------------- OLD: Offerer suggested BUNDLE mid: The first mid value in a given=20 SDP 'group:BUNDLE' attribute mid list in an offer. NEW: Offerer suggested BUNDLE tag: The first value in a given=20 SDP 'group:BUNDLE' attribute identification-tag list in an offer. OLD: Bundled "m=3D" line: An "m=3D" line, whose SDP 'mid' attribute value is placed in a SDP 'group:BUNDLE' attribute mid value list in an=20 offer or answer. NEW: Bundled "m=3D" line: An "m=3D" line, whose SDP 'mid' attribute value is placed in a SDP 'group:BUNDLE' attribute identification-tag list in a= n=20 offer or answer. OLD: The BUNDLE extension is indicated using an SDP 'group' attribute with a "BUNDLE" semantics value . An SDP "mid" attribute is assigned to each bundled "m=3D" line, and the "mid" attribute value is listed in the 'group:BUNDLE' attribute mid value list. Each "m=3D" line, whose mid value is listed in the mid value list, is associated with a given BUNDL= E group. NEW: The BUNDLE extension is indicated using an SDP 'group' attribute with a "BUNDLE" semantics value . An SDP "mid" attribute is assigned to each bundled "m=3D" line, and the "mid" attribute identification-tag value i= s listed in the 'group:BUNDLE' attribute identification-tag list. Each "m=3D" line, who= se identification-tag value is listed in the identification-tag list, is associated with a gi= ven BUNDLE group. OLD: Place the SDP 'mid' attribute value of each bundled "m=3D" line to the SDP 'group:BUNDLE' attribute mid val= ue list; and NEW: Place the SDP 'mid' attribute identification-tag value of each bundled "m=3D" line to the SDP 'group:BUNDLE' attribute identif= ication-tag list; and OLD: If all of the criteria is not fulfilled, the answerer MUST select the n= ext mid=20 value in the mid list, and perform the same criteria check for the "m= =3D" line=20 associated with that mid value. If there are no more mid values in the = mid list, the answerer MUST NOT create the BUNDLE group. NEW: If all of the criteria is not fulfilled, the answerer MUST select the n= ext=20 value in the identification-tag list, and perform the same criteria che= ck for the "m=3D" line=20 associated with that value. If there are no more values in the identifi= cation-tag list, the answerer MUST NOT create the BUNDLE group. OLD: In addition, in either case above, the answerer MUST NOT include a mid = value, associated with the moved "m=3D" line, in the SDP 'group:BUNDLE' attribute mid lis= t associated with the BUNDLE group. NEW: In addition, in either case above, the answerer MUST NOT include an SDP= mid attribute identification-tag value, associated with the moved "m=3D" line, in the SDP 'group:BUNDLE' attribute identif= ication-tag list associated with the BUNDLE group. Etc etc etc. -----Original Message----- From: Stach, Thomas [mailto:thomas.stach@unify.com]=20 Sent: 01 November 2014 11:00 To: Paul Kyzivat; Christer Holmberg Cc: 'mmusic' Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 -= Terminology Paul, > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Freitag, 31. Oktober 2014 19:31 > To: Christer Holmberg; Stach, Thomas > Cc: 'mmusic' > Subject: Re: WGLC comments on=20 > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology >=20 > On 10/25/14 10:31 AM, Christer Holmberg wrote: > > Hi, > > > > I'd like to hear Paul's opinions on this, because he is the one who=20 > > suggested the current terminology. >=20 > Sorry to be so slow responding. >=20 > I've looked back at the thread, and I am not entirely clear what the=20 > proposal is. In part it is replacing "BUNDLE mid" with "BUNDLE-tag". >=20 > Looking at where "BUNDLE mid" is used, it is mostly in constructs like: >=20 > In the offer, the address assigned to the "m=3D" line associated with > the offerer suggested BUNDLE mid indicates the address that the >=20 > Given the definition that Thomas proposed, that would still work with=20 > the change, but ISTM the linkage from "mid" to "m=3D" line is a little=20 > more obvious than from "tag" to "m=3D" line. My proposal to call that thing "tag" comes from the RFC5888 ABNF group-attr= ibute =3D "a=3Dgroup:" semantics *(SP identification-tag) mid-attribute =3D "a=3Dmid:" identification-tag Here "mid" is the name of an attribute, the values that we are talking abou= t are carried in the "identification-tag" With this linkage to 5888, we would have a more precise definition.=20 >=20 > I don't know if Thomas was intending that there would still be=20 > definitions for "Offerer suggested BUNDLE-tag" and "Answerer selected=20 > BUNDLE-tag". I think we would still need those. [TS] I would have used just a single term and made the semantics of suggest= ed vs. selected clear from the surrounding text in the remainder of the doc= ument.=20 But that is already deep in the field of personal style and preferences.=20 I would be ok with two terms, especially with the change to "Offerer sugges= ted BUNDLE-tag/mid".=20 The corresponding edits that Christer suggested make the text already much = clearer. >=20 > As an alternative, perhaps a definition of "BUNDLE mid" could be=20 > added, that has much of the text from Thomas' definition of "BUNDLE-tag". Having such a definition would be good.=20 In the proposed text, I tried to give some guidance to the reader how this = thing is used in the remainder of the text. Thanks Thomas >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > > *Sent:* 24 October 2014 16:45 > > *To:* Christer Holmberg > > *Cc:* 'mmusic' > > *Subject:* RE: WGLC comments on > > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology > > > > Hi, > > > > There has been many long discussions in order to come up with the=20 > > terminology. > > > > */[TS] I know that much effort was already put into that. /* > > > > *//* > > > > Also, > > > > considering the number of editorial re-structures that have already=20 > > taken place, and the impact this would have on the document, I would=20 > > suggest to NOT do the change. > > > > */[TS] I understand that there is not much appetite for putting more=20 > > editorial work into the document./* > > > > */Nevertheless, I still think that understanding the text is still=20 > > unnecessarily cumbersome, /* > > > > */which in turn could lead to unnecessary misinterpretations during > > implementation./* > > > > */But maybe it is just me, who has this problem, in which case I=20 > > probably just have to improve my reading skills. ;-) /* > > > > But, if you think the existing definitions can be clarified, we can=20 > > discuss that. > > > > */[TS] Well, considering reuse of the RFC5888 terminology might be=20 > > still > > worthwhile./* > > > > */That would e.g. include replacing "mid attribute value" with=20 > > "identification-tag", etc./* > > > > *//* > > > > Regards, > > > > Christer > > > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > > *Sent:* 23 October 2014 18:34 > > *To:* Christer Holmberg > > *Cc:* 'mmusic' > > *Subject:* WGLC comments on=20 > > draft-ietf-mmusic-sdp-bundle-negotiation-12 > > - Terminology > > > > All > > > > Terminology > > > > Offerer suggested BUNDLE mid: The first mid value in a given SDP > > > > 'group:BUNDLE' attribute mid list in an offer. > > > > and > > > > Answerer selected BUNDLE mid: The first mid value in a given SDP > > > > 'group:BUNDLE' attribute mid list in an answer. > > > > These terms are not very intuitive and make the reading the related=20 > > text quite cumbersome. > > > > Since you are talking about the identification-tags from RFC5888 > > > > group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) > > > > mid-attribute =3D "a=3Dmid:" identification-tag > > > > may I suggest re-using that terminology and propose using a single,=20 > > more pregnant term for both > > > > together with additional explanation? > > > > E.g. > > > > BUNDLE-tag: The first element in the list of identification-tags of > > > > a 'group:' attribute [RFC5888] with BUNDLE semantics. > > > > This tag has special significance in that it identifies > > > > the m-line that carries the suggested or selected=20 > > BUNDLE address. > > > > The corresponding m-line will carry the same tag in a 'mid= ' > > attribute. > > > > The offerer suggests a BUNDLE tag. The answerer=20 > > preferably accepts > > > > the suggested BUNDLE-tag, but could select a different > > > > BUNDLE-tag, if necessary. > > > > Example: > > > > If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo'=20 > > would be the > > > > BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE ad= dress. > > > > If there is appetite for changing that terminology, I understand=20 > > that it would cause quite a few > > > > other editorial changes in the remainder of the document. > > > > In order to not delay progress of the draft, I can only offer to=20 > > help in any editorial effort and would be happy to propose changed text= . > > > > Regards > > > > Thomas > > From nobody Mon Nov 3 04:45:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABBA1A011F for ; Mon, 3 Nov 2014 04:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HezOachs6zDN for ; Mon, 3 Nov 2014 04:45:05 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F521A0119 for ; Mon, 3 Nov 2014 04:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2716; q=dns/txt; s=iport; t=1415018705; x=1416228305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=01hKIyIVHABmiTrIsYYtW8Q3DCWwXmLYo0hB3xCV3G4=; b=hXzDHJ9kc6PgLOxedH9rlCx7qRLKZltJ3MzFeTtkM//8LWAv1huR+7JC 0OeeLweScW1C71qoSlzH3+YJe/56C0UX8XO8kG/mYU81OkJB4FOgEBdI5 YSsy53IZTbP+6QcCCfAFgli2RdYPqQ23TauZhwfIXobaxvq7jsbB8mFzM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAIACF4V1StJA2B/2dsb2JhbABcgw5UWATOCIdHAgICgSUWAQEBAQF9hAIBAQEDAXkFCwIBCBgnBzIUEQIEDgUJEogdCQ3HLgEBAQEBAQEBAQEBAQEBAQEBAQEZkF0zB4MtgR4Fj3uCH4RPhxiBMYZ/jiCDeGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,307,1413244800"; d="scan'208";a="369105464" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP; 03 Nov 2014 12:45:04 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sA3Cj4si005483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Nov 2014 12:45:04 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 06:45:04 -0600 From: "Pal Martinsen (palmarti)" To: mmusic Thread-Topic: [MMUSIC] ICE Dual Stack Fairness Thread-Index: AQHP7wrHz5lJHIroHEqdhLPo9EyYeZxPTniA Date: Mon, 3 Nov 2014 12:45:03 +0000 Message-ID: <36F68831-D667-443B-A8DD-C508BD109D86@cisco.com> References: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> <761C04CA-32BA-4BF9-87DE-A8EFED61105C@cisco.com> <54497730.6070502@ericsson.com> In-Reply-To: <54497730.6070502@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.221.156] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7e_mAZA2-YX-y13CSDVv3A3v-eY Cc: =?Windows-1252?Q?Ari_Ker=E4nen?= Subject: Re: [MMUSIC] ICE Dual Stack Fairness X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 12:45:07 -0000 > On 23 Oct 2014, at 23:46, Ari Ker=E4nen wrote: >=20 > On 10/23/14 10:53 AM, Pal Martinsen (palmarti) wrote: >>=20 >> On 21 Oct 2014, at 16:53, Simon Perreault > > wrote: >>=20 >>>=20 >>> On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (palmarti) >>> > wrote: >>>=20 >>> We submitted a new draft that we believe cover the new milestone. >>>=20 >>> https://tools.ietf.org/html/draft-martinsen-mmusic-ice-dualstack-fai= rness-00 >>>=20 >>>=20 >>> I just read this for the first time. Forgive me if this has been >>> discussed before... As an implementer I would prefer if there was "the >>> one true" algorithm that I can go and implement and not have to think. >>> Having an example algorithm in an appendix makes me uneasy. If the >>> algorithm is not contentious, why not make it normative? >>>=20 >>=20 >> This have been briefly discussed. Some ICE implementations already do >> similar tricks to solve this problem. The main purpose of the draft is >> to make implementers aware that their might be a problem and hint that >> there is a solution they can use. >>=20 >> That said, I completely agree that the algorithm should be normative. >>=20 >> The algorithm in the draft already has wording in there to allow for >> implementation specific modifications. And should be able to handle any >> old ICE implementations without braking anything. >>=20 >> Anyone with objections regarding making the proposed algorithm normative >> in the draft? >=20 > We discussed this topic at #89 IETF: > http://www.ietf.org/proceedings/89/minutes/minutes-89-mmusic#h.caj5s2i38c= k0 >=20 Thanks for the pointer. MMUSIC minutes are very detailed and helpful.=20 > The algorithm as such is not, to best of my knowledge, contentious, but m= aking it something mandatory to follow was considered a bad idea. >=20 Agree, definitely not mandatory.=20 Wish I was clever enough to build a mathematical prof of the correctness of= the algorithm.=20 > As individual, I think one (RFC 2119) MAY/OPTIONAL default algorithm woul= d make sense, but having it as MUST would not be a good idea. >=20 I would like it stronger than MAY. Something like: =93Implementations SHOUL= D use the algorithm in Section xxx, but MAY user their own following the gu= idelines in Section yyy to ensure interoperability=94=20 I will rewrite the draft to ensure the guidelines for not breaking interope= rability stands out more clearly, and move the algorithm from appendix into= main.=20 Thanks for input. .-. P=E5l-Erik >=20 > Cheers, > Ari From nobody Mon Nov 3 05:59:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727AD1A023E for ; Mon, 3 Nov 2014 05:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkS_FydnjxoD for ; Mon, 3 Nov 2014 05:59:04 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9051A0127 for ; Mon, 3 Nov 2014 05:59:03 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id s18so4142750lam.27 for ; Mon, 03 Nov 2014 05:58:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Mr31xCrL2daOA/Emsail6pn/HzMFWmv0AHylTNbSOxo=; b=FLEkGVKACKRJHoHkv5vuqZlBQohCfnvJaBSIdnzVNzDNadwGwKG9oF0/eVlODzfn43 9oly4hqi3l48CHqRcpwHAhHRL4jUU2oHsLGzKa+wXqW3nLkq+IUZg5EaV7jjGXEcbc1s lF7Y36bxlTX3+ThmKO15U43xBvoV6eGAmpnD5U1tcx7TjxAnziwQDXIID0uf2CiQhxHy tWAtkw4TTMfJVxpBNDmEJpq//OyjX9vzpbgeIXcmt1Pr/3rGIZD23JEBFDbFt+k03Do2 Ov16ejwSgZ5rAuXFloytLq6O8bYoBlRfHv6LdYAp5/BWf3+LhdSra7jA3CP6kHO4vBVH MkGw== X-Gm-Message-State: ALoCoQmUwIUdHLpAUg/h8OSj7wCEyDfeMfEyqWFvgHPn7WXFDxYgNqWsppn9EtuLtAXyXUNrbVn8 MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr25142422lbb.6.1415023139527; Mon, 03 Nov 2014 05:58:59 -0800 (PST) Received: by 10.25.84.135 with HTTP; Mon, 3 Nov 2014 05:58:59 -0800 (PST) In-Reply-To: <36F68831-D667-443B-A8DD-C508BD109D86@cisco.com> References: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> <761C04CA-32BA-4BF9-87DE-A8EFED61105C@cisco.com> <54497730.6070502@ericsson.com> <36F68831-D667-443B-A8DD-C508BD109D86@cisco.com> Date: Mon, 3 Nov 2014 08:58:59 -0500 Message-ID: From: Simon Perreault To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a11c341c894b9ec0506f4bf8e Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4iDizrJscIQd15hAkSRxwFQ0Y-s Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] ICE Dual Stack Fairness X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 13:59:05 -0000 --001a11c341c894b9ec0506f4bf8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 3, 2014 at 7:45 AM, Pal Martinsen (palmarti) wrote: > I would like it stronger than MAY. Something like: =E2=80=9CImplementatio= ns SHOULD > use the algorithm in Section xxx, but MAY user their own following the > guidelines in Section yyy to ensure interoperability=E2=80=9D > > I will rewrite the draft to ensure the guidelines for not breaking > interoperability stands out more clearly, and move the algorithm from > appendix into main. > Works for me! Prescriptive enough to make clueless implementers like me go ahead and do it, with enough wiggle room to allow for engineering tweaks while doing it. Thanks, Simon --001a11c341c894b9ec0506f4bf8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 3, 2014 at 7:45 AM, Pal Martinsen (palmarti) = <palmarti@cisco.= com> wrote:
I would like it stronger than MAY= . Something like: =E2=80=9CImplementations SHOULD use the algorithm in Sect= ion xxx, but MAY user their own following the guidelines in Section yyy to = ensure interoperability=E2=80=9D

I will rewrite the draft to ensure the guidelines for not breaking interope= rability stands out more clearly, and move the algorithm from appendix into= main.

Works for me! Prescriptive enough to mak= e clueless implementers like me go ahead and do it, with enough wiggle room= to allow for engineering tweaks while doing it.

Thanks,
Simon
--001a11c341c894b9ec0506f4bf8e-- From nobody Mon Nov 3 06:54:12 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5979F1A0137 for ; Mon, 3 Nov 2014 06:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20nn26XBPfbo for ; Mon, 3 Nov 2014 06:54:05 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id EEB991A02F1 for ; Mon, 3 Nov 2014 06:54:03 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id D0E4E23F04D7; Mon, 3 Nov 2014 15:54:02 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 15:54:02 +0100 From: "Stach, Thomas" To: Christer Holmberg , Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology Thread-Index: AQHP75C+xP9ueOyQhU+z/AR0yQ5D5JxKkmqJgADtcuCAA1GVAIAAEZLA Date: Mon, 3 Nov 2014 14:54:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8236@ESESSMB209.ericsson.se> <5453D54B.3020209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4E0093@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E0093@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gfTH17H2JIW3IuSj20crAMYGCiI Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 14:54:08 -0000 Christer, > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Montag, 3. November 2014 13:21 > To: Stach, Thomas; Paul Kyzivat > Cc: 'mmusic' > Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12= - > Terminology >=20 >=20 > Hi, >=20 > I started to go through BUNDLE, to look for the impacts due to changing "= mid" > to "tag". >=20 > The list below is not complete, but it does give a good picture of the > impacts. >=20 > One question is whether we want to say "SDP 'mid' attribute identificatio= n-tag > value" or just "SDP 'mid' attribute value". =20 Well, "SDP 'mid' attribute identification-tag value" is a bit lengthy. Alternatively, you may just call it "identification-tag" and define the ter= m=20 in your terminology section. E.g. as Identification-tag: A unique token that is used to identify an m-line.=20 The SDP 'mid' attribute [RFC5888], associated to a "m=3D" line, carries=20 an unique identification-tag. The session-level SDP 'group' attribute=20 [RFC5888] carries a list of identification-tags that form the correspondin= g group. You could then simplify the new text as proposed below=20 >=20 > Regards, >=20 > Christer >=20 > ----------------- >=20 >=20 > OLD: >=20 > Offerer suggested BUNDLE mid: The first mid value in a given > SDP 'group:BUNDLE' attribute mid list in an offer. >=20 > NEW: >=20 > Offerer suggested BUNDLE tag: The first value in a given > SDP 'group:BUNDLE' attribute identification-tag list in an offer. >=20 >=20 >=20 > OLD: >=20 > Bundled "m=3D" line: An "m=3D" line, whose SDP 'mid' attribute value > is placed in a SDP 'group:BUNDLE' attribute mid value list in an > offer or answer. >=20 > NEW: >=20 > Bundled "m=3D" line: An "m=3D" line, whose SDP 'mid' attribute value > is placed in a SDP 'group:BUNDLE' attribute identification-tag list in a= n > offer or answer.=09 Bundled "m=3D" line: An "m=3D" line, whose identification-tag is placed in identification-tag list of a SDP 'group:BUNDLE' attribute. ... or you might also consider giving a bit more context=20 Bundled "m=3D" line: An "m=3D" line that shares the transport address wit= h=20 other "m=3D" lines after a corresponding offer/answer negotiation.=20 The bundled "m=3D" line can be identified via the identification-tag in t= he=20 associated SDP 'mid' attribute. That identification-tag will also be foun= d =20 in the identification-tag list of the SDP 'group:BUNDLE' attribute. >=20 >=20 > OLD: >=20 > The BUNDLE extension is indicated using an SDP 'group' attribute > with a "BUNDLE" semantics value format=3D"default" pageno=3D"fals= e" > target=3D"RFC5888"/>. An SDP "mid" attribute is assigned to each > bundled "m=3D" line, and the "mid" attribute value is listed in the > 'group:BUNDLE' attribute mid value list. Each "m=3D" line, whose mid > value is listed in the mid value list, is associated with a given BUNDLE > group. >=20 > NEW: >=20 > The BUNDLE extension is indicated using an SDP 'group' attribute > with a "BUNDLE" semantics value format=3D"default" pageno=3D"fal= se" > target=3D"RFC5888"/>. An SDP "mid:" attribute is assigned to each > bundled "m=3D" line, and the "mid" attribute identification-tag value is= listed in the > 'group:BUNDLE' attribute identification-tag list. Each "m=3D" line, whos= e identification-tag > value is listed in the identification-tag list, is associated with a giv= en BUNDLE > group. Alt. NEW=20 The BUNDLE extension is indicated using an SDP 'group' attribute with the semantics field set to "BUNDLE" format=3D"default" pagen= o=3D"false" target=3D"RFC5888"/>. An SDP "mid:" attribute is assigned to each bundled "m=3D" line, and each identification-tag is listed in the identification-tag list of the 'group' attribute. Each "m=3D" line, whose= identification-tag is listed in the identification-tag list, is associated with a given BUND= LE group.=09 >=20 >=20 > OLD: > Place the SDP 'mid' attribute value target=3D"RFC5888" pageno=3D= "false" format=3D"default"/> > of each bundled "m=3D" line to the SDP 'group:BUNDLE' attribute mid valu= e list; and >=20 >=20 > NEW: >=20 > Place the SDP 'mid' attribute identification-tag value > of each bundled "m=3D" line to the SDP 'group:BUNDLE' attribute identifi= cation-tag list; and Alt. New Include the identification-tag of each bundled "m=3D" line in the identif= ication-tag list of SDP 'group' attribute; and >=20 > OLD: >=20 > If all of the criteria is not fulfilled, the answerer MUST select the n= ext mid > value in the mid list, and perform the same criteria check for the "m=3D= " line > associated with that mid value. If there are no more mid values in the m= id list, > the answerer MUST NOT create the BUNDLE group. >=20 > NEW: >=20 > If all of the criteria is not fulfilled, the answerer MUST select the n= ext > value in the identification-tag list, and perform the same criteria chec= k for the "m=3D" line > associated with that value. If there are no more values in the identific= ation-tag list, > the answerer MUST NOT create the BUNDLE group. The proposed change looks good, but shouldn't the sentence start with=20 "If one of the criteria is not fulfilled, ..." >=20 > OLD: >=20 > In addition, in either case above, the answerer MUST NOT include a mid v= alue, associated > with the moved "m=3D" line, in the SDP 'group:BUNDLE' attribute mid list= associated > with the BUNDLE group. >=20 >=20 > NEW: >=20 > In addition, in either case above, the answerer MUST NOT include an SDP = mid attribute identification-tag value, associated > with the moved "m=3D" line, in the SDP 'group:BUNDLE' attribute identifi= cation-tag list associated > with the BUNDLE group. Alt. NEW In addition, in either case above, the answerer MUST NOT include the iden= tification-tag, associated with the moved "m=3D" line, in the identification-tag list of the corresp= onding SDP 'group' attribute. >=20 > Etc etc etc. Yes, there is more but from a simple search/replace for=20 /mid value/SDP 'mid' attribute value/SDP "mid" attribute value/ --> /identi= fication-tag/ I haven't found too much more editorial impact. At least section 13 seems t= o be straightforward. Regards Thomas >=20 >=20 > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@unify.com] > Sent: 01 November 2014 11:00 > To: Paul Kyzivat; Christer Holmberg > Cc: 'mmusic' > Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12= - > Terminology >=20 > Paul, >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Freitag, 31. Oktober 2014 19:31 > > To: Christer Holmberg; Stach, Thomas > > Cc: 'mmusic' > > Subject: Re: WGLC comments on > > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology > > > > On 10/25/14 10:31 AM, Christer Holmberg wrote: > > > Hi, > > > > > > I'd like to hear Paul's opinions on this, because he is the one who > > > suggested the current terminology. > > > > Sorry to be so slow responding. > > > > I've looked back at the thread, and I am not entirely clear what the > > proposal is. In part it is replacing "BUNDLE mid" with "BUNDLE-tag". > > > > Looking at where "BUNDLE mid" is used, it is mostly in constructs like: > > > > In the offer, the address assigned to the "m=3D" line associated wi= th > > the offerer suggested BUNDLE mid indicates the address that the > > > > Given the definition that Thomas proposed, that would still work with > > the change, but ISTM the linkage from "mid" to "m=3D" line is a little > > more obvious than from "tag" to "m=3D" line. > My proposal to call that thing "tag" comes from the RFC5888 ABNF group- > attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) > mid-attribute =3D "a=3Dmid:" identification-tag > Here "mid" is the name of an attribute, the values that we are talking ab= out > are carried in the "identification-tag" > With this linkage to 5888, we would have a more precise definition. > > > > I don't know if Thomas was intending that there would still be > > definitions for "Offerer suggested BUNDLE-tag" and "Answerer selected > > BUNDLE-tag". I think we would still need those. > [TS] I would have used just a single term and made the semantics of sugge= sted > vs. selected clear from the surrounding text in the remainder of the docu= ment. > But that is already deep in the field of personal style and preferences. > I would be ok with two terms, especially with the change to "Offerer sugg= ested > BUNDLE-tag/mid". > The corresponding edits that Christer suggested make the text already muc= h > clearer. > > > > As an alternative, perhaps a definition of "BUNDLE mid" could be > > added, that has much of the text from Thomas' definition of "BUNDLE-tag= ". > Having such a definition would be good. > In the proposed text, I tried to give some guidance to the reader how thi= s > thing is used in the remainder of the text. >=20 > Thanks > Thomas > > > > Thanks, > > Paul > > > > > Regards, > > > > > > Christer > > > > > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > > > *Sent:* 24 October 2014 16:45 > > > *To:* Christer Holmberg > > > *Cc:* 'mmusic' > > > *Subject:* RE: WGLC comments on > > > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology > > > > > > Hi, > > > > > > There has been many long discussions in order to come up with the > > > terminology. > > > > > > */[TS] I know that much effort was already put into that. /* > > > > > > *//* > > > > > > Also, > > > > > > considering the number of editorial re-structures that have already > > > taken place, and the impact this would have on the document, I would > > > suggest to NOT do the change. > > > > > > */[TS] I understand that there is not much appetite for putting more > > > editorial work into the document./* > > > > > > */Nevertheless, I still think that understanding the text is still > > > unnecessarily cumbersome, /* > > > > > > */which in turn could lead to unnecessary misinterpretations during > > > implementation./* > > > > > > */But maybe it is just me, who has this problem, in which case I > > > probably just have to improve my reading skills. ;-) /* > > > > > > But, if you think the existing definitions can be clarified, we can > > > discuss that. > > > > > > */[TS] Well, considering reuse of the RFC5888 terminology might be > > > still > > > worthwhile./* > > > > > > */That would e.g. include replacing "mid attribute value" with > > > "identification-tag", etc./* > > > > > > *//* > > > > > > Regards, > > > > > > Christer > > > > > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > > > *Sent:* 23 October 2014 18:34 > > > *To:* Christer Holmberg > > > *Cc:* 'mmusic' > > > *Subject:* WGLC comments on > > > draft-ietf-mmusic-sdp-bundle-negotiation-12 > > > - Terminology > > > > > > All > > > > > > Terminology > > > > > > Offerer suggested BUNDLE mid: The first mid value in a given SDP > > > > > > 'group:BUNDLE' attribute mid list in an offer. > > > > > > and > > > > > > Answerer selected BUNDLE mid: The first mid value in a given SDP > > > > > > 'group:BUNDLE' attribute mid list in an answer. > > > > > > These terms are not very intuitive and make the reading the related > > > text quite cumbersome. > > > > > > Since you are talking about the identification-tags from RFC5888 > > > > > > group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) > > > > > > mid-attribute =3D "a=3Dmid:" identification-tag > > > > > > may I suggest re-using that terminology and propose using a single, > > > more pregnant term for both > > > > > > together with additional explanation? > > > > > > E.g. > > > > > > BUNDLE-tag: The first element in the list of identification-tags of > > > > > > a 'group:' attribute [RFC5888] with BUNDLE semantics. > > > > > > This tag has special significance in that it identifies > > > > > > the m-line that carries the suggested or selected > > > BUNDLE address. > > > > > > The corresponding m-line will carry the same tag in a 'm= id' > > > attribute. > > > > > > The offerer suggests a BUNDLE tag. The answerer > > > preferably accepts > > > > > > the suggested BUNDLE-tag, but could select a different > > > > > > BUNDLE-tag, if necessary. > > > > > > Example: > > > > > > If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' > > > would be the > > > > > > BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE > address. > > > > > > If there is appetite for changing that terminology, I understand > > > that it would cause quite a few > > > > > > other editorial changes in the remainder of the document. > > > > > > In order to not delay progress of the draft, I can only offer to > > > help in any editorial effort and would be happy to propose changed te= xt. > > > > > > Regards > > > > > > Thomas > > > From nobody Mon Nov 3 20:22:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AAC1A888C for ; Mon, 3 Nov 2014 20:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUW4YVdKCZt5 for ; Mon, 3 Nov 2014 20:22:44 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063401A8886 for ; Mon, 3 Nov 2014 20:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=241; q=dns/txt; s=iport; t=1415074964; x=1416284564; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=h8oQmCRLyPUclpyy94THeLtZzb/sgSmUV8hLTKp9Xrw=; b=jbF9ZAlfN6UweGQHXavgLjf8Q2+1eu8EvOQaRee1XCqR+XeK7GchlHSo cOARnPFsxinO2g3f1qY/mpYQVqaBxsXe28r41Wxk1pXZEIP2biUwrGP/A MsVNqORfrjq3mheZS/E4vd68ug+CiljL+LJgy6MMPfSfjV1LLUCR6PPXH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4LAPhTWFStJA2G/2dsb2JhbABcgw5UWY1mrRwFAXSSV4dNgSgWAQEBAQF9hEFAATwWGAMCAQIBSw0BBwEBBYg4Dcs6AQEBAQYBAQEBAR2GN4pZhFIFi3aSC4Exg02Cd45bhBYfgnoBAQE X-IronPort-AV: E=Sophos;i="5.07,311,1413244800"; d="scan'208";a="93072722" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 04 Nov 2014 04:22:43 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sA44Mgs8022562; Tue, 4 Nov 2014 04:22:43 GMT Message-ID: <54585492.2090109@cisco.com> Date: Mon, 03 Nov 2014 23:22:42 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/33K_KCK2aOJOGwxZ-ymRdOmiM14 Cc: Ari Keranen Subject: [MMUSIC] Updated MMUSIC Agenda for IETF 91 (Honolulu) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 04:22:45 -0000 Greetings We have updated the MMUSIC agenda for IETF 91: http://www.ietf.org/proceedings/91/agenda/agenda-91-mmusic Please let us know if you have any questions or comments. Thanks Ari & Flemming (MMUSIC co-chairs) From nobody Tue Nov 4 09:51:00 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E281ACCE6 for ; Tue, 4 Nov 2014 09:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSwPcvDgpu-M for ; Tue, 4 Nov 2014 09:50:48 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A161ACCE2 for ; Tue, 4 Nov 2014 09:50:47 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-5b-545911f5b071 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 90.CA.04387.5F119545; Tue, 4 Nov 2014 18:50:45 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.174.1; Tue, 4 Nov 2014 18:50:45 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 27F5F110207; Tue, 4 Nov 2014 19:50:45 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A11E45F2A4; Tue, 4 Nov 2014 19:50:54 +0200 (EET) Received: from aris-mbp-2.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 434985953D; Tue, 4 Nov 2014 19:50:54 +0200 (EET) Message-ID: <545911E9.3070300@ericsson.com> Date: Tue, 4 Nov 2014 19:50:33 +0200 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Justin Uberti , Jonathan Lennox , mmusic , Martin Thomson , Dan Wing , Emil Ivov , =?windows-1252?Q?I=F1aki_Baz_Castillo?= References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvje5XwcgQgz0H9CwuXnvIZLFm5wQW i+n7bCz2Lz7PbLF1qpDFtTP/GC2mLn/M4sDuca7hPbvHlN8bWT12zrrL7rFgU6nHkiU/mTz+ vwn0aHt2hz2APYrLJiU1J7MstUjfLoErY0lbE0tBg3jFn57nrA2MDwW7GDk5JARMJN5fPsMC YYtJXLi3nq2LkYtDSOAIo8S8LVNYIJz1jBKzb/cyQzh7GCUaPv2CctYySvz+dI8Fzjmy6RsT yDBeAW2Js7sngdksAioSOxduBVvCJuAocfvhS1YQW1QgWaLr5UOoekGJkzOfgA0SEehkknh1 9wFYg7CAkcTitknMIDbQbiaJlo1mIDanQKBE+6/DQNdycDAL2Es82FoGEmYWkJdo3jqbGeIh NYmr5zZBtapKXP33inECo8gsJOtmIXTPQtK9gJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJ JkZgZB3c8ttqB+PB546HGAU4GJV4eA0cI0KEWBPLiitzDzFKc7AoifMuPDcvWEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVANj3uk359kad+l1rUnMKVTaG7trctD7ZQxr7/geiGMRcWSdopZr 4vjUZOd+R9+CgvY50/fkW0V7yZfdvRR3eP4rsRWZG0JiWr7pnHo269sux5fJ+j/UQx/knJ3h eCP9u7RCKnf69MV71evz9tw5I3E/+IXtS0/nyOZNWl3f38msrmh5Oy94ToOvEktxRqKhFnNR cSIASr5SbI0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sP76pum8Lz0bdZl39r6am9xB9fg Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 17:50:54 -0000 All, This feature seemed to get quite a bit of support. There were also some concerns about: * DTLS implementations *may* not like the fact that Hello comes from an unexpected candidate (may also apply to other protocols?) * Whether (and when) the selected candidate is really firm and the others can be freed, media on them discarded, or an ICE library can return a socket that is bound to right candidate See also the threads: http://www.ietf.org/mail-archive/web/mmusic/current/msg13596.html http://www.ietf.org/mail-archive/web/mmusic/current/msg13656.html I'm planning to take this as a discussion item during the meeting, but before that it would be great if the proponents of the change could come up with a text proposal. I assume we'd need an ICE option to indicate this and clarify what to do with data on a candidate without USE-CANDIDATE exchange. Also, if I missed some point why this would be a bad idea, please speak now. Cheers, Ari On 31/07/14 02:42, Justin Uberti wrote: > On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox > wrote: > > > On Jul 30, 2014, at 7:00 PM, Martin Thomson > > wrote: > > > On 30 July 2014 15:56, Jonathan Lennox > wrote: > >> The offerer can’t send its own connectivity checks until it > receives an answer, because it needs the remote ufrag and password. > Without this, it doesn’t have any valid pairs, and so can’t send > any media. > > > > Of course. But you could do all the computation necessary for > > generating the ServerHello and accompanying messages (which in > TLS 1.3 > > is quite a bit). > > > >> This suggestion might still save half an RTT, though? I’d need > to work through a full ladder diagram to figure it out. > > > > That's the idea. I haven't plotted it all out either, but I think > > that this is the fastest possible start assuming that you don't send > > any DTLS messages prior to getting a successful connectivity check > > response. > > Actually, if the answerer (controlled endpoint) can send on any > Valid pair, as in my suggestion, I don’t think you need the ICE role > reversal for this optimization. It can send ClientHello as soon as > its first check succeeds, despite never having received any remote > checks (with or without USE-CANDIDATE). > > This makes a lot of sense and we should do it. Implementations not > expecting media before choosing a selected pair (on the controlling side > this time) may eat the packet, but it won't be fatal. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Nov 4 10:53:41 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13C91A1B71 for ; Tue, 4 Nov 2014 10:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoePjyWYDC40 for ; Tue, 4 Nov 2014 10:53:35 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26FC1A017E for ; Tue, 4 Nov 2014 10:53:34 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-54-545920ac53f4 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.29.04231.CA029545; Tue, 4 Nov 2014 19:53:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 19:53:32 +0100 From: Christer Holmberg To: Martin Thomson , Emil Ivov Thread-Topic: [MMUSIC] Dummy ports Thread-Index: AQHPlkyhM6ORecxJvUu7xOA/TjaGopuNTt0AgAIiPICAANRuAIAEFj+AgAahqACAABXqAIAAB1WAgAAEmQCAtnRSQA== Date: Tue, 4 Nov 2014 18:53:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E530B@ESESSMB209.ericsson.se> References: <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu> <53BA81A3.8090108@jitsi.org> <53C02A45.40703@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvje4ahcgQg7lflC3W7JzAYnHtzD9G i6nLH7NYrNhwgNWBxePv+w9MHjtn3WX3WLLkJ5PH/zeBASxRXDYpqTmZZalF+nYJXBknDlxi KTgqULHh1QemBsalvF2MHBwSAiYSF8+UdTFyApliEhfurWfrYuTiEBI4wijx5fImdghnMaPE vl8gGQ4ONgELie5/2iANIgJeEke7D7GC2MwCvhLvf05nB7GFBRQldnWcZISoUZLYt38NO0ir iECWxMx2PZAwi4CKxIq1j5hBbF6g1mf/7kHtfc0ssf34XrCZnAKBEld63oDNYQQ67vupNUwQ u8Qlbj2ZzwRxtIDEkj3nmSFsUYmXj/+xQthKEmsPb2eBqNeRWLD7ExuErS2xbOFrqMWCEidn PmGZwCg2C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwBg7uOW3 7g7G1a8dDzEKcDAq8fAaOEaECLEmlhVX5h5ilOZgURLnXXRuXrCQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGRnkZ5zLRhNOrUmr29DcJ9k2/t3mKlqGQ2ib5ZsHAh2od5lZC/Le8BB9O2rzQ kV82pGHntxvPL92JOed3z6/y8JemeRVfRBhq1nCIMWVn8hdXLz8/Z/fGxOrU+wujuHSXSDps mb9kx7lpSR3btcWfyNxy0Hwurng0+Y6JQlflZve/oR2VNyQmKbEUZyQaajEXFScCANP9jWuS AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FR5septOS4533dYm2hm_OqqC2Bc Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Dummy ports X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 18:53:39 -0000 Hi, I went through this thread, to see whether it requires some text to BUNDLE. Justin said earlier that this has nothing to do with BUNDLE, as one could a= lso use port 9 in multiple non-bundled m- lines. That is partly true, but keep in mind that with BUNDLE the answerer has to = select the offerer BUNDLE address. It would have to choose port 9 - without= knowing what port will eventually be used.=20 Perhaps it doesn't care, but I think that would require some text in BUNDLE= . Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Martin Thomson Sent: 11 July 2014 21:34 To: Emil Ivov Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] Dummy ports On 11 July 2014 11:17, Emil Ivov wrote: > > > On 11.07.14, 19:51, Martin Thomson wrote: >> >> On 11 July 2014 09:33, Justin Uberti wrote: >>> >>> a) We require unique 'dummy' ports in the initial trickle offer. >>> b) We allow use of the same dummy port (9) in the initial trickle offer= . >>> (This is what Chrome does, although it currently uses port 1). >>> >>> We had been leaning towards (a) based on the legacy equipment case=20 >>> mentioned above. However, if nobody can provide details on this=20 >>> case, I agree we should end up with (b). >> >> >> As a general rule, if accommodating legacy equipment is particularly=20 >> hard for us here, then we should leave the fixups needed for that=20 >> legacy equipment to application code. This seems like a good=20 >> candidate for that. It's not like non-9 ports will work with all=20 >> legacy equipment anyway. > > Also note that, in the case of trickle, port 9s would only occur if=20 > the offerer expects (knows) it would be supported. In other cases it=20 > would just do half trickle and the problem wouldn't exist. Yeah, that's even more reason to do the right thing (as opposed to the safe= thing). _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Nov 4 13:52:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C381A010C for ; Tue, 4 Nov 2014 13:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6IK4JKE2hh2 for ; Tue, 4 Nov 2014 13:52:20 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CA31A0137 for ; Tue, 4 Nov 2014 13:52:20 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so15241617pab.18 for ; Tue, 04 Nov 2014 13:52:19 -0800 (PST) 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=O3V/OPtRTB20bYrFz03iiCzvjq5Z8sm29erDGbVBdJw=; b=LP/OtEqAw8x/2fwPY1kd4el/zrzYRcKLkxuyWRh3O58aiRJS6o5RnRoEgNk1tWz/vo 2irWTBhk77hA46NQ54yed4p3fUSCFKqfZWaRDewNTBxC51fismz1gt+N76LJuu7poSHd HaFfuwEeiiuhgeGs6qfyoSnQFIXI23ywdSFMWhtl4dAAT8aj8afL+dtiu+LgzeNWwo9g 61csWmTwIywwWWcUY3b21aBnvc88VWJWlzis4Y12FnN74uxnN7V1b+xneJUAcCgtTJl6 nJ4MGgSIKwT6icm4zBlO6ovyNb0dNehGgcOjPtZ5C5ftUheRrUB+ZoIdJBtdUtL6Pqj+ oRYA== MIME-Version: 1.0 X-Received: by 10.68.102.195 with SMTP id fq3mr51968153pbb.7.1415137939618; Tue, 04 Nov 2014 13:52:19 -0800 (PST) Received: by 10.70.60.201 with HTTP; Tue, 4 Nov 2014 13:52:19 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E530B@ESESSMB209.ericsson.se> References: <53B661C9.6090009@alvestrand.no> <53B713FC.5010507@alum.mit.edu> <53BA81A3.8090108@jitsi.org> <53C02A45.40703@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D4E530B@ESESSMB209.ericsson.se> Date: Tue, 4 Nov 2014 13:52:19 -0800 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b673a0633004905070f7ace Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1sYAzXncnnUIZoYp6XXczBQXfk0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Dummy ports X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 21:52:24 -0000 --047d7b673a0633004905070f7ace Content-Type: text/plain; charset=UTF-8 +1 on keeping 9 in all the m= lines for full trickle and also BUNDLE must say a note on this to clarify the usage. Thanks Suhas On Tue, Nov 4, 2014 at 10:53 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I went through this thread, to see whether it requires some text to BUNDLE. > > Justin said earlier that this has nothing to do with BUNDLE, as one could > also use port 9 in multiple non-bundled m- lines. > > That is partly true, but keep in mind that with BUNDLE the answerer has to > select the offerer BUNDLE address. It would have to choose port 9 - without > knowing what port will eventually be used. > > Perhaps it doesn't care, but I think that would require some text in > BUNDLE. > > Regards, > > Christer > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: 11 July 2014 21:34 > To: Emil Ivov > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] Dummy ports > > On 11 July 2014 11:17, Emil Ivov wrote: > > > > > > On 11.07.14, 19:51, Martin Thomson wrote: > >> > >> On 11 July 2014 09:33, Justin Uberti wrote: > >>> > >>> a) We require unique 'dummy' ports in the initial trickle offer. > >>> b) We allow use of the same dummy port (9) in the initial trickle > offer. > >>> (This is what Chrome does, although it currently uses port 1). > >>> > >>> We had been leaning towards (a) based on the legacy equipment case > >>> mentioned above. However, if nobody can provide details on this > >>> case, I agree we should end up with (b). > >> > >> > >> As a general rule, if accommodating legacy equipment is particularly > >> hard for us here, then we should leave the fixups needed for that > >> legacy equipment to application code. This seems like a good > >> candidate for that. It's not like non-9 ports will work with all > >> legacy equipment anyway. > > > > Also note that, in the case of trickle, port 9s would only occur if > > the offerer expects (knows) it would be supported. In other cases it > > would just do half trickle and the problem wouldn't exist. > > Yeah, that's even more reason to do the right thing (as opposed to the > safe thing). > > _______________________________________________ > 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 > --047d7b673a0633004905070f7ace Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on keeping 9 in all the m=3D lines for full trickle and= also BUNDLE must say a note on this to clarify the usage.

Thanks
Suhas

On Tue, Nov 4, 2014 at 10:53 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

I went through this thread, to see whether it requires some text to BUNDLE.=

Justin said earlier that this has nothing to do with BUNDLE, as one could a= lso use port 9 in multiple non-bundled m- lines.

That is partly true, but keep in mind that with BUNDLE the answerer has to = select the offerer BUNDLE address. It would have to choose port 9 - without= knowing what port will eventually be used.

Perhaps it doesn't care, but I think that would require some text in BU= NDLE.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-boun= ces@ietf.org] On Behalf Of Martin Thomson
Sent: 11 July 2014 21:34
To: Emil Ivov
Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] Dummy ports

On 11 July 2014 11:17, Emil Ivov <emc= ho@jitsi.org> wrote:
>
>
> On 11.07.14, 19:51, Martin Thomson wrote:
>>
>> On 11 July 2014 09:33, Justin Uberti <juberti@google.com> wrote:
>>>
>>> a) We require unique 'dummy' ports in the initial tric= kle offer.
>>> b) We allow use of the same dummy port (9) in the initial tric= kle offer.
>>> (This is what Chrome does, although it currently uses port 1).=
>>>
>>> We had been leaning towards (a) based on the legacy equipment = case
>>> mentioned above. However, if nobody can provide details on thi= s
>>> case, I agree we should end up with (b).
>>
>>
>> As a general rule, if accommodating legacy equipment is particular= ly
>> hard for us here, then we should leave the fixups needed for that<= br> >> legacy equipment to application code.=C2=A0 This seems like a good=
>> candidate for that.=C2=A0 It's not like non-9 ports will work = with all
>> legacy equipment anyway.
>
> Also note that, in the case of trickle, port 9s would only occur if > the offerer expects (knows) it would be supported. In other cases it > would just do half trickle and the problem wouldn't exist.

Yeah, that's even more reason to do the right thing (as opposed to the = safe thing).

_______________________________________________
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

--047d7b673a0633004905070f7ace-- From nobody Tue Nov 4 15:40:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C911A1A5B for ; Tue, 4 Nov 2014 15:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb86hXgem-yz for ; Tue, 4 Nov 2014 15:40:40 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F3C1A1A4F for ; Tue, 4 Nov 2014 15:40:40 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-01v.sys.comcast.net with comcast id Bbfx1p0055BUCh401bggTN; Tue, 04 Nov 2014 23:40:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id Bbgf1p0093Ge9ey01bgfsR; Tue, 04 Nov 2014 23:40:40 +0000 Message-ID: <545963F7.7040003@alum.mit.edu> Date: Tue, 04 Nov 2014 18:40:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF MMUSIC WG , Adam Roach Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415144440; bh=jbzoNs64W/ryDZtidMfSkjrKrMNOY8rJ2HjLLHR4Tbk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QEqv8CJ8aq7/BXKroTKU3/6F5qN1RyzLsomW2ZHyWuVKoTSF0LEvu/QtPImhaXM/x prHA9/tdOFSY9JqC5GpWmFrFKnDhD9U+iBtOKRKBNYdgeIYv2mLSDvLig4bKnvjPhJ ggjir4VwqrvyMDNCKEjMI6Sl+5bMbFxW5S3sUeAMpjSStJlXgmrc5sMXwBkAz1NXoN +5p7WwzVzRTj2qwdC+za13ll5uIaYg4mXMMLXwcgGPULk85TM4qT1Im0ob5jWPRmdJ D/dDtuQsT42xOVZAoaPVPWXrc5vMdFihSQtwhwnURFOX9Wa7joa0XgWYiEtfI+yyVB gBAQCh++KHPBg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jBfXigah-S_ER0zGYum3_ZY19AY Cc: Flemming Andreasen Subject: [MMUSIC] Comments on draft-roach-mmusic-pof-pan-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 23:40:42 -0000 I was asked to re-review pof-pan. Here are my current thoughts about this draft. I'm only focusing on fundamentals here - I think it is premature to worry about nits at this stage. My overall feeling about this is that it introduces a lot of new machinery. The primary motivation for all of this is to avoid glare and hence the need to carry out the glare backoff/retry mechanism of 3261 that can be slow. (Minimum time before starting to retry is a random value between zero and two seconds. So in some cases it may be necessary to suffer a two second delay!) So a fundamental question is whether the gain justifies all the added machinery. (Especially since the machinery doesn't avoid glare in all cases. The glare algorithms still must be implemented and used.) * A radical alternative: Rather than figuring out how to negotiate individual streams in order to minimize the occurrence of glare, I wonder if it might be better to work on optimizing glare handling so that it can be handled more quickly. Having said that, here are some comments on the draft as it is: * Section 3 says: ... (3) all partial offers and partial answers are sent using a technique that guarantees in-order and reliable delivery. I'm concerned that this requirement is a radical departure for O/A, and will severely limit applicability. Then: If the new stream needs to be added to an existing group, it does so by using the "a=in-group" attribute defined in [I-D.roach-mmusic-groupid], indicating the ID of a group that has already been established within the session. If the new stream needs to be added to a new group, then such a group may be created by adding an "a=in-group" attribute that contains a group ID that is not yet present in the session. In both cases, the session-level membership of the group is semantically updated to reflect the new member of the group (and, if necessary, the creation of a new group). A couple of issues with the above: - when adding to an existing bundle group, there is no specification of where the new mid is added in the mid list. I suppose the intent is that they be added to the end. Maybe it doesn't matter as long as all grouped m-lines are required to have the same address. - when creating a new group, I see no guarantee that both sides won't choose the same new group ID. What happens then is unclear. * Section 3.2 says: If the recipient of a partial offer that contains an existing MID has also sent a partial offer to change that exact same stream, and neither the received nor the sent partial offer contains a port number of zero, then a legitimate glare condition has arisen. Normal glare recovery procedures -- e.g., using a tie-breaker token or a back-off timer -- must be engaged to resolve the conflict. Is the intent to fall back to a full O/A? Or is it to define glare handling using pof/pan? If the intent is a full O/A, then how does that occur? Both sides will detect this same condition. If they each immediately try to send an offer, there is a high likelihood of glare on the full O/A too. But now the cost is higher than if the initial attempt had been a full offer. One possibility is that both sides should behave as if the glare had just occurred on a full O/A, so that the glare retry algorithm is started immediately. * Section 5.2: The following is in this section: ... Finally, the implementation evaluates whether the changes it needs to make can be performed exclusively using the values present in a media section, without any modifications necessary to session-level values (except for the sess- version value on the session-level o= line). This fails to call out an exception for use of a=group... for which you have a special mechanism. (This is sort of a nit.) * Section 5.5: This procedure makes me very uncomfortable. While I'm not *sure* there is a problem, it feels like there can be. some concerns that come to mind are: - if more than one partial offer is quarantined, ISTM that the order they are brought out of quarantine will impact the order of mids in the full SDP. Will it be deterministic on both sides? - for that matter, even when not quarantined, isn't there still a problem this way? - what if some a partial offer has changes or removals, and also has additions. Are the changes an removals processed immediately and only the additions quarantined? Or is the whole partial offer quarantined? (Seems like it could make a difference.) In general this mechanism seems "fragile". Thanks, Paul From nobody Thu Nov 6 03:20:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687941A1B3B for ; Thu, 6 Nov 2014 03:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MadPrcYKHhMa for ; Thu, 6 Nov 2014 03:20:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DFE1A1B30 for ; Thu, 6 Nov 2014 03:20:37 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-dc-545b59833565 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.5F.04231.3895B545; Thu, 6 Nov 2014 12:20:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Thu, 6 Nov 2014 12:20:34 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/g== Date: Thu, 6 Nov 2014 11:20:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4E82E8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvjW5zZHSIwflfqhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsIlNxkLnktXPL/5ga2Bca9EFyMHh4SAiUTvlcQuRk4gU0zi wr31bF2MXBxCAkcYJa7+P8gK4SxmlDgx9RgrSAObgIVE9z9tkAYRAXWJr3t7mEFsYQEjieXf VrNDxM0lPs9eCGXrSdy6tocVxGYRUJG4+nQpWJxXwFfixMujTCA2I9Di76fWgNnMAuISt57M Z4I4SEBiyZ7zzBC2qMTLx/9YIW5WlFjeLwdiMgvkS7y5HgYxUVDi5MwnLBMYhWYhGTQLoWoW kiqIEh2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNocWpxcW66kbFealFmcnFxfp5eXmrJ JkZgLBzc8lt3B+Pq146HGAU4GJV4eA2eRIUIsSaWFVfmHmKU5mBREudddG5esJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQZGb7E0I5PIfYxlmSsa93+fN/fhK7edwsHbG3iW3AxQ+lM+3Wfe o7dZx0x+Vhef/aIx4d4mpbXKVa9espp47NqmcSaqoWR2SZvwr8RI3epLJgqXXpnODmFNCqyO WOGnpaoo/N+ScVLUreXJzbfi+7o66lauenm/eWV2Osua6mtpvneD/v24P0FCiaU4I9FQi7mo OBEAvFyRiWYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OaCYnmf1LP8HCOP-n-JUn2JiWQk Subject: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 11:20:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4E82E8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I BUNDLE, we have the following text: "If multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identify each indi= vidual protocol." I think we need to clarify what we mean by "transported on DTLS". Are we ta= lking about on a single DTLS connection, a single DTLS session, or somethin= g else? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4E82E8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I BUNDLE, we have the following text:

 

“If multiple prot= ocols are transported on DTLS, there MUST exist a

         &nb= sp;      specification describing a mechanism for = identify each individual

         &nb= sp;      protocol.”

 

I think we need to clarify what we mean by “tr= ansported on DTLS”. Are we talking about on a single DTLS connection,= a single DTLS session, or something else?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4E82E8ESESSMB209erics_-- From nobody Thu Nov 6 06:59:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AC21A891A for ; Thu, 6 Nov 2014 06:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHuB02aPD0_T for ; Thu, 6 Nov 2014 06:59:35 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DD31A896F for ; Thu, 6 Nov 2014 06:59:34 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5F7F541502633; Thu, 6 Nov 2014 14:59:29 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sA6ExWCZ000542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Nov 2014 15:59:32 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 15:59:32 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/gAHOIkw Date: Thu, 6 Nov 2014 14:59:31 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC359937FR711WXCHMBA03zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VdHQ3PFKLh1g5kHZtOG8hGfqdHY Cc: "Arturo Martin De Nicolas \(AC/EED\)" Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 14:59:37 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC359937FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a good point! > Are we talking about on a single DTLS connection, a single DTLS session, = or something else? Actually I'm also interested to get a clear semantic of DTLS connection vs = DTLS session (and even vs DTLS association, a term which indicated in the = DTLS RFC too). This is particularily of interest for a) security reasons (due to the DTLS handshake protocol and DTLS change cip= her spec protocol, which are running on session or connection level?, affec= ting session or connection information?) b) to clarify text sth like "shares the DTLS connection with the SRTP media= channels ..." in draft-ietf-rtcweb-data-channel: DTLS-SRTP actually does n= ot allow to share the DTLS ? with other applications ("hence, there might b= e possible a single DTLS session and two DTLS connections, hm?) and c) WebRTC gateways due to interworking scenarios. Thanks for help from the (D)TLS experts community! Albrecht From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Donnerstag, 6. November 2014 12:21 To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? Hi, I BUNDLE, we have the following text: "If multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identify each indi= vidual protocol." I think we need to clarify what we mean by "transported on DTLS". Are we ta= lking about on a single DTLS connection, a single DTLS session, or somethin= g else? Regards, Christer --_000_786615F3A85DF44AA2A76164A71FE1AC359937FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

T= his is a good point!

 

> Are we talking about on a single DTLS connection, a single DTLS = session, or something else?

&n= bsp;

Actually I’m also interested to get a clear semantic of= DTLS connection vs DTLS session (and  even vs DTLS association, a ter= m which indicated in the DTLS RFC too).

This is particularily of interest for

a) security reasons (due to the DTLS handshake protocol and D= TLS change cipher spec protocol, which are running on session or connection= level?, affecting session or connection information?)

b) to clarify text sth like “shares the DTLS connection= with the SRTP media channels …” in draft-ietf-rtcweb-data-chan= nel: DTLS-SRTP actually does not allow to share the DTLS ? with other applications (“hence, there might be possible a single = DTLS session and two DTLS connections, hm?) and

c) WebRTC gateways due to interworking scenarios.<= /span>

 

Thanks for help from the (D)TLS experts community!=

Albrecht

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Donnerstag, 6. November 2014 12:21
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"= ?

 

Hi,

 

I BUNDLE, we have the following= text:

 

&#= 8220;If multiple protocols are transported on DTLS, there MUST exist a=

      =           specification descri= bing a mechanism for identify each individual

      =           protocol.”

 

I think we need to clarify what= we mean by “transported on DTLS”. Are we talking about on a si= ngle DTLS connection, a single DTLS session, or something else?<= /span>

 

Regards,

 

Christer

--_000_786615F3A85DF44AA2A76164A71FE1AC359937FR711WXCHMBA03zeu_-- From nobody Thu Nov 6 07:16:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466CC1A88E4 for ; Thu, 6 Nov 2014 07:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqzcjgot_fX8 for ; Thu, 6 Nov 2014 07:16:02 -0800 (PST) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0CD1A88D4 for ; Thu, 6 Nov 2014 07:16:01 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id i50so885555qgf.1 for ; Thu, 06 Nov 2014 07:16:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=R4EcgF9MSJApVDFWeWj7aO/mh3ZDyvPdFxmbrWr7H6k=; b=A4JMG/Cn6l+nIAvHSba92jtwRHDJIspqC/7wCl8ZR5BZzvumJQXrFFeY/Y69BuzIUf J1oeJ27J/Y9QGEumW1Yw6jeB45IhK/gEwfSfKBdJUPYpePOd4U+uVTX5hJwGCt4JGUrv 60gyqhi74dGfYk3HmQZRZt6OK7JrV35T1S9dBr9KWrLxH2W4jU3ho/jJ8b2TfLlcStgQ LJIPHBQiaWFhIuDbGcH0MnePHBIHwqpgxTdz+kf48TrtmZn2fQiZ0NvWEvltCOBref7y 011CE0Gb8M3gNi4FbYYpHBbLXPVHA1o6HB37xoXyLLMt9LHLgk+/2vFYVm00p1kHTpmk 4D9A== X-Gm-Message-State: ALoCoQmHxG9uNrnfBxdfVPbkWhgngr8xrZSTUchB6BfPa0HMwj7vPYHm3FfDkq76v3Yuvi4nspTC X-Received: by 10.140.105.164 with SMTP id c33mr7194229qgf.11.1415286961097; Thu, 06 Nov 2014 07:16:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 6 Nov 2014 07:15:36 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 6 Nov 2014 16:15:36 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/U7gE_rVFenYFiebWaEjjRDzJdRk Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 15:16:03 -0000 2014-11-06 12:20 GMT+01:00 Christer Holmberg : > I think we need to clarify what we mean by =E2=80=9Ctransported on DTLS= =E2=80=9D. Are we > talking about on a single DTLS connection, a single DTLS session, or > something else? I understand that "transported on DTLS" refers to SRTP (when the keys exchanged is performed via a DTLS handsake) and DataChannel (which obviously is a protocol on top of an established DTLS connection. --=20 I=C3=B1aki Baz Castillo From nobody Thu Nov 6 11:31:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F7E1A8A70 for ; Thu, 6 Nov 2014 11:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3tJ1b0dp9Ta for ; Thu, 6 Nov 2014 11:31:42 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A747E1A8A7F for ; Thu, 6 Nov 2014 11:31:41 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-88-545bcc9b0078 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1E.D9.04231.B9CCB545; Thu, 6 Nov 2014 20:31:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Thu, 6 Nov 2014 20:31:39 +0100 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , "mmusic@ietf.org" Thread-Topic: BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/gAHOIkwAAnwGgA= Date: Thu, 6 Nov 2014 19:31:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4E9EE5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rnf2megQg8cvrSz+tP5itJi6/DGL A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4t3cuS8GDsIrTszrYGhj3+3QxcnJICJhI rJhynw3CFpO4cG89kM3FISRwhFFiy7ZpUM5iRonXc34xdzFycLAJWEh0/9MGaRARyJc4tuUY O4jNLOAi8eDUcTBbWMBM4vCuZ6wQNeYSn2cvZIewrSRW/u9jBrFZBFQkPq9bAhbnFfCVeHLq GNSueYwSp65fZAFJcApES9xcuw5sECPQdd9PrWGCWCYucevJfCaIqwUkluw5zwxhi0q8fPyP FcJWkmhc8oQVoj5fYtahdhaIZYISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjJmTxBYzsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECI+7glt+6OxhXv3Y8xCjA wajEw2vwJCpEiDWxrLgy9xCjNAeLkjjvonPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw 1rolpyQa3tuqvv3HmZTE3Ur5/oeM6+b+d+60VBLJDrv25DS30IoVLprtgkb5UhtYxKwdfmjz /OP/zv1H+etD+WiTFe/fXJRb9v292C5nx/3xtyYlH7Tj+vt/BvPcpOf+N1c5/tzY6uwg9fTP zofcn/elnnQVXPH99oostWi5roT648+XuGntV2Ipzkg01GIuKk4EAOEzUfeZAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ip_W2eCcl0eUwivhVDhUwvaXS9I Cc: Arturo Martin De Nicolas Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 19:31:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4E9EE5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Albrecht, I think the RFCs explain the difference between DTLS session and DTLS conne= ction - that is not what I was asking about. I am more wondering about the text we have in BUNDLE :) Regards, Christer From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 06 November 2014 17:00 To: Christer Holmberg; mmusic@ietf.org Cc: Arturo Martin De Nicolas Subject: RE: BUNDLE: Meaning of "transported on DTLS"? This is a good point! > Are we talking about on a single DTLS connection, a single DTLS session, = or something else? Actually I'm also interested to get a clear semantic of DTLS connection vs = DTLS session (and even vs DTLS association, a term which indicated in the = DTLS RFC too). This is particularily of interest for a) security reasons (due to the DTLS handshake protocol and DTLS change cip= her spec protocol, which are running on session or connection level?, affec= ting session or connection information?) b) to clarify text sth like "shares the DTLS connection with the SRTP media= channels ..." in draft-ietf-rtcweb-data-channel: DTLS-SRTP actually does n= ot allow to share the DTLS ? with other applications ("hence, there might b= e possible a single DTLS session and two DTLS connections, hm?) and c) WebRTC gateways due to interworking scenarios. Thanks for help from the (D)TLS experts community! Albrecht From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Donnerstag, 6. November 2014 12:21 To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? Hi, I BUNDLE, we have the following text: "If multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identify each indi= vidual protocol." I think we need to clarify what we mean by "transported on DTLS". Are we ta= lking about on a single DTLS connection, a single DTLS session, or somethin= g else? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4E9EE5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Albrecht,

 

I think the RFCs explain the difference between DTLS session and DTLS = connection – that is not what I was asking about.

 

I am more wondering about the text we have in BUNDLE :)

 

Regards,

 

Christer

 

From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-l= ucent.com]
Sent: 06 November 2014 17:00
To: Christer Holmberg; mmusic@ietf.org
Cc: Arturo Martin De Nicolas
Subject: RE: BUNDLE: Meaning of "transported on DTLS"?

 

T= his is a good point!

 

> Are we talking about on a single DTLS connection, a single DTLS = session, or something else?

&n= bsp;

Actually I’m also interested to get a clear semantic of= DTLS connection vs DTLS session (and  even vs DTLS association, a ter= m which indicated in the DTLS RFC too).

This is particularily of interest for

a) security reasons (due to the DTLS handshake protocol and D= TLS change cipher spec protocol, which are running on session or connection= level?, affecting session or connection information?)

b) to clarify text sth like “shares the DTLS connection= with the SRTP media channels …” in draft-ietf-rtcweb-data-chan= nel: DTLS-SRTP actually does not allow to share the DTLS ? with other applications (“hence, there might be possible a single = DTLS session and two DTLS connections, hm?) and

c) WebRTC gateways due to interworking scenarios.<= /span>

 

Thanks for help from the (D)TLS experts community!=

Albrecht

 

 

From: mm= usic [mailto:mmusic-bounces@ietf= .org] On Behalf Of Christer Holmberg
Sent: Donnerstag, 6. November 2014 12:21
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"= ?

 

Hi,

 

I BUNDLE, we have the following= text:

 

&#= 8220;If multiple protocols are transported on DTLS, there MUST exist a=

      =           specification descri= bing a mechanism for identify each individual

      =           protocol.”

 

I think we need to clarify what= we mean by “transported on DTLS”. Are we talking about on a si= ngle DTLS connection, a single DTLS session, or something else?<= /span>

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4E9EE5ESESSMB209erics_-- From nobody Thu Nov 6 11:44:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640781A1BA9 for ; Thu, 6 Nov 2014 11:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsbrhoIer-XJ for ; Thu, 6 Nov 2014 11:44:36 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF3F1A1A9E for ; Thu, 6 Nov 2014 11:44:34 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id m8so1368280obr.36 for ; Thu, 06 Nov 2014 11:44:33 -0800 (PST) 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=s09zkldOw6dDyc8/btrrQ9CtBsVSGLDrS3cEm+Yys9A=; b=I1aLKgf+Y9AuSwN20quTe9OGqC5gs/nKiDkqiG2cE9o+RZey7ubA8UxI/DPZ3g1/PE 34T8rFwQymrSR0AyCE9YDHbfNBOiy3vyshivM7YPfLFADn/zJh4sJftINshzC1KFAGZc k9nBrunvzzLivWAtWh+oYOAxwGAFUssiHV/Zyibd8i9IQlZvSq5NLjtLhCoIq+9c5JAw +IR0LjqGdjmSgZ5kEfKnB8rf3KedvnpYx+ZenJH6v/CdfAV8JGhgxa4mWEJtNHfsYs+o WGFD+cVbM+XyFbizgva3QB7NAb2uAePThjPJPJATPSA+Ah2B8vNFGDRB+QgymYvEiZjA YbGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=s09zkldOw6dDyc8/btrrQ9CtBsVSGLDrS3cEm+Yys9A=; b=S7V0JsouKacOiqSK2PreaTRgEpq7xOhFLTbDjiRbvq0eHrM24jPNXM6OT1QLk8Kqrq GfqUuScABb4/OQMz+YEjmvEODBydkljvfBL7GxZpgakK31iz9zklc6lpHN7QU4EkbGYr M2sEX4HRX/BgXa5+jn7UhrLQDCn7dWo934IXA89EvgFiAOE0paScuNxtxNjO87r8Hr8s HbidLK8MrgQ65aWHn8kZcVRYYedV4S2rWwLbnycoWFUdXJ0+iZPcVvf5aJ51tmoiPLa4 nH7mvRgO1B65tr+yO59aKNR4KmBMvHWs+H5n1d970nt5BIpKgJA5OflESiueadPsgGSz YaQQ== X-Gm-Message-State: ALoCoQlC+kmuSJ69QL9xyz98nYOfon+QEzoCQfQKeb5ihEtB/B26r4GkORpnG6PeIJ4543HODGaD X-Received: by 10.60.102.211 with SMTP id fq19mr5606791oeb.2.1415303073324; Thu, 06 Nov 2014 11:44:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Thu, 6 Nov 2014 11:44:13 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 6 Nov 2014 11:44:13 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01160a2eef8ef8050735ec30 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Pc64K280S2c4UdeEEdtRTt1SxO4 Cc: Arturo Martin De Nicolas , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 19:44:38 -0000 --089e01160a2eef8ef8050735ec30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it is clear we are talking about these protocols being multiplexed across a single DTLS connection here. On Thu, Nov 6, 2014 at 11:31 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Albrecht, > > > > I think the RFCs explain the difference between DTLS session and DTLS > connection =E2=80=93 that is not what I was asking about. > > > > I am more wondering about the text we have in BUNDLE :) > > > > Regards, > > > > Christer > > > > *From:* Schwarz, Albrecht (Albrecht) [mailto: > albrecht.schwarz@alcatel-lucent.com] > *Sent:* 06 November 2014 17:00 > *To:* Christer Holmberg; mmusic@ietf.org > *Cc:* Arturo Martin De Nicolas > *Subject:* RE: BUNDLE: Meaning of "transported on DTLS"? > > > > This is a good point! > > > > > Are we talking about on a single DTLS connection, a single DTLS > session, or something else? > > > > Actually I=E2=80=99m also interested to get a clear semantic of DTLS conn= ection vs > DTLS session (and even vs DTLS association, a term which indicated in th= e > DTLS RFC too). > > This is particularily of interest for > > a) security reasons (due to the DTLS handshake protocol and DTLS change > cipher spec protocol, which are running on session or connection level?, > affecting session or connection information?) > > b) to clarify text sth like =E2=80=9Cshares the DTLS connection with the = SRTP > media channels =E2=80=A6=E2=80=9D in draft-ietf-rtcweb-data-channel: DTLS= -SRTP actually > does not allow to share the DTLS ? with other applications (=E2=80=9Chenc= e, there > might be possible a single DTLS session and two DTLS connections, hm?) an= d > > c) WebRTC gateways due to interworking scenarios. > > > > Thanks for help from the (D)TLS experts community! > > Albrecht > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org ]= *On > Behalf Of *Christer Holmberg > *Sent:* Donnerstag, 6. November 2014 12:21 > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? > > > > Hi, > > > > I BUNDLE, we have the following text: > > > > =E2=80=9CIf multiple protocols are transported on DTLS, there MUST exist = a > > specification describing a mechanism for identify each > individual > > protocol.=E2=80=9D > > > > I think we need to clarify what we mean by =E2=80=9Ctransported on DTLS= =E2=80=9D. Are we > talking about on a single DTLS connection, a single DTLS session, or > something else? > > > > Regards, > > > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e01160a2eef8ef8050735ec30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it is clear we are talking about these protocols b= eing multiplexed across a single DTLS connection here.=C2=A0

On Thu, Nov 6, 2014 at 11:= 31 AM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:

Hi Albrecht,=

=C2=A0

I think the RFCs expla= in the difference between DTLS session and DTLS connection =E2=80=93 that i= s not what I was asking about.

=C2=A0

I am more wondering ab= out the text we have in BUNDLE :)

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-luc= ent.com]
Sent: 06 November 2014 17:00
To: Christer Holmberg; mmusic@ietf.org
Cc: Arturo Martin De Nicolas
Subject: RE: BUNDLE: Meaning of "transported on DTLS"?<= /u>

=C2=A0

T= his is a good point!

=C2=A0

> Are we talking about on a single DTLS connection, a single DTLS = session, or something else?

= =C2=A0

Actually I=E2=80=99m also interested to get a clear semantic = of DTLS connection vs DTLS session (and=C2=A0 even vs DTLS association, a t= erm which indicated in the DTLS RFC too).

This is particularily of interest for

a) security reasons (due to the DTLS handshake protocol and D= TLS change cipher spec protocol, which are running on session or connection= level?, affecting session or connection information?)

b) to clarify text sth like =E2=80=9Cshares the DTLS connecti= on with the SRTP media channels =E2=80=A6=E2=80=9D in draft-ietf-rtcweb-dat= a-channel: DTLS-SRTP actually does not allow to share the DTLS ? with other applications (=E2=80=9Chence, there might be possible a singl= e DTLS session and two DTLS connections, hm?) and

c) WebRTC gateways due to interworking scenarios.

=C2=A0

Thanks for help from the (D)TLS experts community!<= /u>

Albrecht

=C2=A0

=C2=A0

From: mm= usic [mailto:m= music-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Donnerstag, 6. November 2014 12:21
To: mmusic@ietf= .org
Subject: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"= ?

=C2=A0

Hi,

=C2=A0

I BUNDLE, we have the following= text:

=C2=A0

= =E2=80=9CIf multiple protocols are transported on DTLS, there MUST exist a<= u>

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specification descri= bing a mechanism for identify each individual

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protocol.=E2=80=9D

=C2=A0

I think we need to clarify what= we mean by =E2=80=9Ctransported on DTLS=E2=80=9D. Are we talking about on = a single DTLS connection, a single DTLS session, or something else?<= u>

=C2=A0

Regards,

=C2=A0

Christer


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


--089e01160a2eef8ef8050735ec30-- From nobody Thu Nov 6 11:49:45 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26D1A1ACF for ; Thu, 6 Nov 2014 11:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 768U4IHgerjf for ; Thu, 6 Nov 2014 11:49:41 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313F61A1A27 for ; Thu, 6 Nov 2014 11:49:41 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id x69so1302185oia.21 for ; Thu, 06 Nov 2014 11:49:40 -0800 (PST) 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=aG8XeuO/w1Sg9LeXkicgE60RU70iYtQvXyMA7eRr2bo=; b=JAupO4OUa1NEHF2Z3IEqdVOmmTewvM5JlssP43VcVO08kXCEgi8wUD1VBi+gviROqw KNKDWHhHE19gFK20Gj99PyIrDHU8+CyJ3GXd2lENx4O8//1ZyWgQrq0IV27xv1zlZAzY y/jI/ZHl+1XlMDS0ocmVxrgd+g0kHto4K09meWopWqcco/TYYeajHQgcBQkvx/Kd5hgk +9wLaPdXp74l8Glp+8p0zRV1gcpByyFR28s6WSduxJ3hGifg1wU7LD0VisEWxNw8eOxW 1/8ztBUlHRPv9/B/CzntkHxej9dscNh7CTLb5n+SR0Xfc2KBYqUgDLveJg6xjTJaUO5Y vgsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aG8XeuO/w1Sg9LeXkicgE60RU70iYtQvXyMA7eRr2bo=; b=g687ZkSYws9Ydv41y3KtJOiK1PPjV0xoSsC+tG4q8govzzupbZcTy5YigtURllNCKH 2hgg6oi+I+ur7Qdiyp3X/K9MEB5BUxMe2RyZpGVSm5IzAMVziuF92+VmxM/f/zc+9oFJ wBBghSLtSHD/oUfzEWj1NYrXmcjoa6jSdc54kYyx/UatIxSiJKsBcpXbQfXHyHbgjDHa 1ehR5aejXv2zuj5FynMCX0OTr1EhkNBvEvLpBE9kc7PXNKKMiQL4ib7Js5Als6rXdEHf GYHvlko7Fdxz11VlSSE9mafEDA6y2FTg4Ev6axJXVqMX4X3rR3qsnofm9DiiY6ZxkJD1 16iw== X-Gm-Message-State: ALoCoQmEiavK3GECn3gOU1DGvUoMJgvHKg7TC53+wKptVjAi8jIVUeXj95gtTwUfNAIqsUPdaX4L X-Received: by 10.60.102.211 with SMTP id fq19mr5629039oeb.2.1415303380415; Thu, 06 Nov 2014 11:49:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Thu, 6 Nov 2014 11:49:20 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CCBC1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCBC1@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 6 Nov 2014 11:49:20 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01160a2e3d4dfb050735ff41 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BZOvR-NKXPW6I7Dy9IQwPnhdrzI Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- line with zero port value? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 19:49:43 -0000 --089e01160a2e3d4dfb050735ff41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think you need an ICE candidate for a m=3D line with a zero port value. We already covered something similar for trickle ICE (i.e. the dummy ports). On Mon, Oct 27, 2014 at 4:43 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > One question that has been raised by Thomas Stach during the BUNDLE WGLC, > is regarding ICE candidates and bundle-only m- lines with a zero port val= ue. > > > > The current text says that identical ICE candidate values are assigned to > bundle-only m- lines. > > > > Now, in the case where a zero port value is assigned to a bundle-only m- > lines, it means that a candidate with a zero port value is also needed (i= n > order to fulfil the ICE rules for default candidates). > > > > IF we want to avoid that, a couple of alternatives have been presented: > > > > 1) Do not assign ICE candidates to bundle-only m- lines with port > zero. The problem is that the answerer, even if it supports > BUNDLE/bundle-only, doesn=E2=80=99t know whether the offerer wants to use= ICE for > those m- lines; or > > 2) Relax the 5245 rules, so that there doesn=E2=80=99t need to be a > candidate matching the m- line port value. > > > > Comments? > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e01160a2e3d4dfb050735ff41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think you need an ICE candidate for a m=3D lin= e with a zero port value. We already covered something similar for trickle = ICE (i.e. the dummy ports).

On Mon, Oct 27, 2014 at 4:43 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

1)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do not assign ICE candidates to bundle-only m- lines w= ith port zero. The problem is that the answerer, even if it supports BUNDLE= /bundle-only, doesn=E2=80=99t know whether the offerer wants to use ICE for= those m- lines; or

2)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Relax the 5245 rules, so that there doesn=E2=80=99t ne= ed to be a candidate matching the m- line port value.

=C2=A0

Comments?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0


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


--089e01160a2e3d4dfb050735ff41-- From nobody Thu Nov 6 12:46:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0F51A6F30 for ; Thu, 6 Nov 2014 12:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUQQhgeDFx5H for ; Thu, 6 Nov 2014 12:46:03 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2891A6F2D for ; Thu, 6 Nov 2014 12:46:03 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id uz6so1519772obc.19 for ; Thu, 06 Nov 2014 12:46:02 -0800 (PST) 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=7fXDkUBmuuCh3Rf9krjDZPGuVyB5g+1+CNqKVuP+FAI=; b=YWRr4Trlm7eMuHjI5TsUc2riV2GKTmJIHdyPvsJKFoJYVuXqLg/OvAo/NzMeZw1UER 8F2spalnsQCI5b+DlZXNRhEGbrdUwRfkJjsJgAAkWFQTuubVpWP5zlmE16v+ipaUuTiE TbyQCm9jhmxCza0z9u45INRP0qG2IJ4M/cQNYDjwIRbYRhWWGi2sfgJ50KbUAweQoiqF SqBds6/YbpxaF31x47IbMLpHcFJCglOYp3OSzcGDITtHLD6UjSQ+lB40lqKWhUllpjgw ZsL6Am/y6FHKM8y9CPyzlZfjNlxdbFF33uJmtfQs+jqKdWRxCAfkRfJRXeE0yeCTx2Z8 CvUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7fXDkUBmuuCh3Rf9krjDZPGuVyB5g+1+CNqKVuP+FAI=; b=LAKxwoVMCsW7/b5S5iPQBLg83NPSqWpln7W8UrZGtSSSc9X/VRvJC8nU1jaRRuDbBm Qm3gSsjsmsZxtR6CrNlOooAu8Jnl37RXHh6PV+gqm2VDCEpRgYEfXeQw/euPbU6JzAYP GiN3qxpKC/lrGvrBjBFzTnb8z2ltABZyaxH0zkKzpz6BQz0adB/USUnfzNwabOOPpN8J PmZJ5VncTIR26BbFeF1NNRYWwyZ4U7JGnrCVFenan+7x/7KIdZrSppclpPPp9U0eMfYL sgv9MYN0G72S+kOAbB+KPxQrBKOyv+i6RF3B3wgaFgsXs4ULzXCXd4iKR//zttFF+IDE 7cWQ== X-Gm-Message-State: ALoCoQlgwGSpTBVwK9w9GJSPor0RYO0BCzjMI6O1Z77zFaSQ0ozPbV5PTjlhxCRAR31Nnzf8i/7n X-Received: by 10.202.80.1 with SMTP id e1mr3607830oib.80.1415306762332; Thu, 06 Nov 2014 12:46:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Thu, 6 Nov 2014 12:45:42 -0800 (PST) In-Reply-To: <545911E9.3070300@ericsson.com> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> From: Justin Uberti Date: Thu, 6 Nov 2014 12:45:42 -0800 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: multipart/alternative; boundary=001a113d8714d1516c050736c8fb Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yC8fqQbQ7jPq5kMLnbbCddOfNjQ Cc: Jonathan Lennox , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 20:46:05 -0000 --001a113d8714d1516c050736c8fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been noodling on two proposals here: a) merging regular and aggressive nom -- essentially, Jonathan's suggestion from before: -- controlling side sends on any Valid pair, even prior to a pair being selected -- controlled side can send on any Valid pair (although it could use receipt of media to align with controlling side) -- controller confirms selection with use-candidate (same as today), which ends concludes ICE -- no ice-options needed (AFAICT) b) adding a new mode, "continuous" nomination -- ICE never concludes; controlling side is always able to change media path dynamically -- as a corollary, controlling side controls when remote candidates can be freed -- new candidates can be trickled at any time -- controlled side uses either receipt of (secure) media to align with controlling side, or receipt of new use-candidate checks -- this mode requires opt-in via ice-options:continuous I still need to look at how b) might overlap with MICE, but I'd be happy to write either of these up or present them in Honolulu. On Tue, Nov 4, 2014 at 9:50 AM, Ari Ker=C3=A4nen wrote: > All, > > This feature seemed to get quite a bit of support. > > There were also some concerns about: > > * DTLS implementations *may* not like the fact that Hello comes from an > unexpected candidate (may also apply to other protocols?) > > * Whether (and when) the selected candidate is really firm and the others > can be freed, media on them discarded, or an ICE library can return a > socket that is bound to right candidate > > See also the threads: > http://www.ietf.org/mail-archive/web/mmusic/current/msg13596.html > http://www.ietf.org/mail-archive/web/mmusic/current/msg13656.html > > I'm planning to take this as a discussion item during the meeting, but > before that it would be great if the proponents of the change could come = up > with a text proposal. I assume we'd need an ICE option to indicate this a= nd > clarify what to do with data on a candidate without USE-CANDIDATE exchang= e. > > Also, if I missed some point why this would be a bad idea, please speak > now. > > > Cheers, > Ari > > On 31/07/14 02:42, Justin Uberti wrote: > >> On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox > > wrote: >> >> >> On Jul 30, 2014, at 7:00 PM, Martin Thomson >> > wrote: >> >> > On 30 July 2014 15:56, Jonathan Lennox > > wrote: >> >> The offerer can=E2=80=99t send its own connectivity checks until= it >> receives an answer, because it needs the remote ufrag and password. >> Without this, it doesn=E2=80=99t have any valid pairs, and so can= =E2=80=99t send >> any media. >> > >> > Of course. But you could do all the computation necessary for >> > generating the ServerHello and accompanying messages (which in >> TLS 1.3 >> > is quite a bit). >> > >> >> This suggestion might still save half an RTT, though? I=E2=80=99= d need >> to work through a full ladder diagram to figure it out. >> > >> > That's the idea. I haven't plotted it all out either, but I thin= k >> > that this is the fastest possible start assuming that you don't >> send >> > any DTLS messages prior to getting a successful connectivity chec= k >> > response. >> >> Actually, if the answerer (controlled endpoint) can send on any >> Valid pair, as in my suggestion, I don=E2=80=99t think you need the = ICE role >> reversal for this optimization. It can send ClientHello as soon as >> its first check succeeds, despite never having received any remote >> checks (with or without USE-CANDIDATE). >> >> This makes a lot of sense and we should do it. Implementations not >> expecting media before choosing a selected pair (on the controlling side >> this time) may eat the packet, but it won't be fatal. >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --001a113d8714d1516c050736c8fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been noodling on two proposals here:

=
a) merging regular and aggressive nom
-- essentially, Jonath= an's suggestion from before:
-- controlling side sends on any= Valid pair, even prior to a pair being selected
-- controlled si= de can send on any Valid pair (although it could use receipt of media to al= ign with controlling side)
-- controller confirms selection with = use-candidate (same as today), which ends concludes ICE
-- no ice= -options needed (AFAICT)

b) adding a new mode, &qu= ot;continuous" nomination
-- ICE never concludes; controllin= g side is always able to change media path dynamically
-- as a co= rollary, controlling side controls when remote candidates can be freed
-- new candidates can be trickled at any time
-- controlled= side uses either receipt of (secure) media to align with controlling side,= or receipt of new use-candidate checks
-- this mode requires opt= -in via ice-options:continuous

I still need to loo= k at how b) might overlap with MICE, but I'd be happy to write either o= f these up or present them in Honolulu.=C2=A0

On Tue, Nov 4, 2014 at 9:50 AM, Ari Ker= =C3=A4nen <ari.keranen@ericsson.com> wrote:
All,

This feature seemed to get quite a bit of support.

There were also some concerns about:

* DTLS implementations *may* not like the fact that Hello comes from an une= xpected candidate (may also apply to other protocols?)

* Whether (and when) the selected candidate is really firm and the others c= an be freed, media on them discarded, or an ICE library can return a socket= that is bound to right candidate

See also the threads:
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg13596.html
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg13656.html

I'm planning to take this as a discussion item during the meeting, but = before that it would be great if the proponents of the change could come up= with a text proposal. I assume we'd need an ICE option to indicate thi= s and clarify what to do with data on a candidate without USE-CANDIDATE exc= hange.

Also, if I missed some point why this would be a bad idea, please speak now= .


Cheers,
Ari

On 31/07/14 02:42, Justin Uberti wrote:
On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox <jonathan@vidyo.com
 <mailto:jonathan= @vidyo.com>> wrote:


=C2=A0 =C2=A0 On Jul 30, 2014, at 7:00 PM, Martin Thomson
 =C2=A0 =C2=A0 <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>= wrote:

=C2=A0 =C2=A0 =C2=A0> On 30 July 2014 15:56, Jonathan Lennox <jonathan@vidyo.com
= =C2=A0 =C2=A0 <mailto:jonathan@vidyo.com>> wrote:
=C2=A0 =C2=A0 =C2=A0>> The offerer can=E2=80=99t send its own connect= ivity checks until it
=C2=A0 =C2=A0 receives an answer, because it needs the remote ufrag and pas= sword.
=C2=A0 =C2=A0 =C2=A0 Without this, it doesn=E2=80=99t have any valid pairs,= and so can=E2=80=99t send
=C2=A0 =C2=A0 any media.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Of course.=C2=A0 But you could do all the computat= ion necessary for
=C2=A0 =C2=A0 =C2=A0> generating the ServerHello and accompanying messag= es (which in
=C2=A0 =C2=A0 TLS 1.3
=C2=A0 =C2=A0 =C2=A0> is quite a bit).
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>> This suggestion might still save half an RTT, = though? I=E2=80=99d need
=C2=A0 =C2=A0 to work through a full ladder diagram to figure it out.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> That's the idea.=C2=A0 I haven't plotted i= t all out either, but I think
=C2=A0 =C2=A0 =C2=A0> that this is the fastest possible start assuming t= hat you don't send
=C2=A0 =C2=A0 =C2=A0> any DTLS messages prior to getting a successful co= nnectivity check
=C2=A0 =C2=A0 =C2=A0> response.

=C2=A0 =C2=A0 Actually, if the answerer (controlled endpoint) can send on a= ny
=C2=A0 =C2=A0 Valid pair, as in my suggestion, I don=E2=80=99t think you ne= ed the ICE role
=C2=A0 =C2=A0 reversal for this optimization.=C2=A0 It can send ClientHello= as soon as
=C2=A0 =C2=A0 its first check succeeds, despite never having received any r= emote
=C2=A0 =C2=A0 checks (with or without USE-CANDIDATE).

This makes a lot of sense and we should do it. Implementations not
expecting media before choosing a selected pair (on the controlling side this time) may eat the packet, but it won't be fatal.


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



--001a113d8714d1516c050736c8fb-- From nobody Thu Nov 6 13:48:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843DC1A90C0 for ; Thu, 6 Nov 2014 13:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXVKdahRsX01 for ; Thu, 6 Nov 2014 13:48:19 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B420A1A90BF for ; Thu, 6 Nov 2014 13:48:18 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id uy5so1647115obc.12 for ; Thu, 06 Nov 2014 13:48:17 -0800 (PST) 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=Jb015phJcgZk1X+wLapgtWJUME2zzM0Tl6f+JzS6CDs=; b=S/2Z0rxWODBcznzAjnOdrxx/UxCm2JV7LEbLQ3DEwLHjgbRq5yK8qMtAnCSb0RiAxv HJmMObRpj2SANkf8rOAZNYuw3po8VrHyQh1Id8yMyV8zesq5FDv7HnCiQzZOd16ILUGY Bs3T9tuzrVPdnjxjE0+HB2G+MkRpqNFwoA4vOTIfjdJ6QchGZ3R1TbWJJSQSvbSqUtsz E+ulwDNZgJLfepUY0H4jafzeot57cvSi4mirGnvqdLDt4V23cuRfmUVcBTlXyG5DQQJV BioS165CuvMdeyFoiAIB32RQu1gm1X9fRAmw+o1UYQNFU2OHKxX+XO1hQK7ojvYYE5RU IaIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Jb015phJcgZk1X+wLapgtWJUME2zzM0Tl6f+JzS6CDs=; b=LDQGJ0nIT6AzBX3dw7YyDxK9cD1IJ6MHhJMSRxWfpkOv75nQkFDYKyX1PeAZsr4xyp BviVLoDpl2tn3FdW0/3DOZRM6IkNL6MqBsQZXQH+91ratcAuoC4hr3dDFx9ZkcrfOPKL Fbj26czwPN1c5aMBz0/lPas6Zn2fM/ou3fmm9+PyVV9SxLfv1CzGhlagiuFkUC96jgdy JvxIvOAD1cIVr0lbN7vJA5cUaPD+iSW5AUdFFcIr4gQeN7GQzdykDCiCXVFpj+bZwRMR 8LI0EWWkXJmKfxSQbrZIIFZqU9mr1j+zLgpwQnlZIyjYDTDz7WyeMC18SSMAwjwChnX5 b/gg== X-Gm-Message-State: ALoCoQmfSeP3JXz0XTKK8CuphBjkh4pb25rjTps58dUmpG+Rx3YCNe8iEKRpAccbkNIwcCCk1Q3m X-Received: by 10.60.55.200 with SMTP id u8mr5828280oep.43.1415310497813; Thu, 06 Nov 2014 13:48:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Thu, 6 Nov 2014 13:47:57 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> From: Justin Uberti Date: Thu, 6 Nov 2014 13:47:57 -0800 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: multipart/alternative; boundary=089e011606ee783af7050737a7ca Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/S8tGf-VDtXNIyH6U_5EkTRe0lzQ Cc: Jonathan Lennox , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:48:20 -0000 --089e011606ee783af7050737a7ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti wrote: > I have been noodling on two proposals here: > > a) merging regular and aggressive nom > -- essentially, Jonathan's suggestion from before: > -- controlling side sends on any Valid pair, even prior to a pair being > selected > -- controlled side can send on any Valid pair (although it could use > receipt of media to align with controlling side) > -- controller confirms selection with use-candidate (same as today), whic= h > ends concludes ICE > -- no ice-options needed (AFAICT) > > b) adding a new mode, "continuous" nomination > -- ICE never concludes; controlling side is always able to change media > path dynamically > -- as a corollary, controlling side controls when remote candidates can b= e > freed > -- new candidates can be trickled at any time > -- controlled side uses either receipt of (secure) media to align with > controlling side, or receipt of new use-candidate checks > -- this mode requires opt-in via ice-options:continuous > > I still need to look at how b) might overlap with MICE, but I'd be happy > to write either of these up or present them in Honolulu. > I looked into how MICE works; I think that continuous nomination might be able to effectively support that use case, as well as the case that Brandon was interested in, namely picking the route that uses the best set of TURN servers. > > On Tue, Nov 4, 2014 at 9:50 AM, Ari Ker=C3=A4nen > wrote: > >> All, >> >> This feature seemed to get quite a bit of support. >> >> There were also some concerns about: >> >> * DTLS implementations *may* not like the fact that Hello comes from an >> unexpected candidate (may also apply to other protocols?) >> >> * Whether (and when) the selected candidate is really firm and the other= s >> can be freed, media on them discarded, or an ICE library can return a >> socket that is bound to right candidate >> >> See also the threads: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg13596.html >> http://www.ietf.org/mail-archive/web/mmusic/current/msg13656.html >> >> I'm planning to take this as a discussion item during the meeting, but >> before that it would be great if the proponents of the change could come= up >> with a text proposal. I assume we'd need an ICE option to indicate this = and >> clarify what to do with data on a candidate without USE-CANDIDATE exchan= ge. >> >> Also, if I missed some point why this would be a bad idea, please speak >> now. >> >> >> --089e011606ee783af7050737a7ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti <juberti@google.com> wrote:
I ha= ve been noodling on two proposals here:

a) merging regul= ar and aggressive nom
-- essentially, Jonathan's suggestion f= rom before:
-- controlling side sends on any Valid pair, even pri= or to a pair being selected
-- controlled side can send on any Va= lid pair (although it could use receipt of media to align with controlling = side)
-- controller confirms selection with use-candidate (same a= s today), which ends concludes ICE
-- no ice-options needed (AFAI= CT)

b) adding a new mode, "continuous" n= omination
-- ICE never concludes; controlling side is always able= to change media path dynamically
-- as a corollary, controlling = side controls when remote candidates can be freed
-- new candidat= es can be trickled at any time
-- controlled side uses either rec= eipt of (secure) media to align with controlling side, or receipt of new us= e-candidate checks
-- this mode requires opt-in via ice-options:c= ontinuous

I still need to look at how b) might ove= rlap with MICE, but I'd be happy to write either of these up or present= them in Honolulu.=C2=A0

I look= ed into how MICE works; I think that continuous nomination might be able to= effectively support that use case, as well as the case that Brandon was in= terested in, namely picking the route that uses the best set of TURN server= s.

On Tue, Nov 4= , 2014 at 9:50 AM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com&g= t; wrote:
All,

This feature seemed to get quite a bit of support.

There were also some concerns about:

* DTLS implementations *may* not like the fact that Hello comes from an une= xpected candidate (may also apply to other protocols?)

* Whether (and when) the selected candidate is really firm and the others c= an be freed, media on them discarded, or an ICE library can return a socket= that is bound to right candidate

See also the threads:
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg13596.html
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg13656.html

I'm planning to take this as a discussion item during the meeting, but = before that it would be great if the proponents of the change could come up= with a text proposal. I assume we'd need an ICE option to indicate thi= s and clarify what to do with data on a candidate without USE-CANDIDATE exc= hange.

Also, if I missed some point why this would be a bad idea, please speak now= .


--089e011606ee783af7050737a7ca-- From nobody Thu Nov 6 14:08:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BB41A9236 for ; Thu, 6 Nov 2014 14:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.794 X-Spam-Level: X-Spam-Status: No, score=-14.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H565mtpazM8 for ; Thu, 6 Nov 2014 14:08:48 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68E61A9138 for ; Thu, 6 Nov 2014 14:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8208; q=dns/txt; s=iport; t=1415311727; x=1416521327; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=xq+z+OoFB/9eWFjKvlLFOX6A+W8fRjcluToDXtr9GsA=; b=DQD4gM0BMsrNbTKfjRlunDGh7GQwjjxvSL6mVy1uW7uBdGaTfQiDTLtL EOehOXt0AkgtOeIE8bC56tY6nZmTBQFhu3r4OQSubjlGIMSXReUxwGcmS sovkzwjFcF/2IV8aySY0n20sbSeckJF8JpwXxAvTJ7i6ItKGrPzTV1ppm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAAvxW1StJV2Y/2dsb2JhbABbgw5UWcsyhnlUAoEhFgEBAQEBfYQCAQEBAwF5BQsLDgouVwYTCYgvCQ3PKwEBAQEBAQEBAQEBAQEBAQEBAQEBAReKdYVLAQFPB4MtgR4FhR0Chl6SGYEyg06Cd45kgV2CPBwvAYEOgTwBAQE X-IronPort-AV: E=Sophos; i="5.07,328,1413244800"; d="scan'208,217"; a="94230536" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 06 Nov 2014 22:08:47 +0000 Received: from [10.21.75.236] ([10.21.75.236]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA6M8i0a025661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Nov 2014 22:08:45 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_9498041C-8D3F-4D09-8162-10386AAB591C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Thu, 6 Nov 2014 14:08:44 -0800 Message-Id: <9282A6B3-6F81-4C54-9AA7-02A8EB669713@cisco.com> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> To: Justin Uberti X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7crzuDg0MYA2HxOU4px41_WTOss Cc: Jonathan Lennox , =?utf-8?Q?Ari_Ker=C3=A4nen?= , mmusic Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 22:08:51 -0000 --Apple-Mail=_9498041C-8D3F-4D09-8162-10386AAB591C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 6, 2014, at 1:47 PM, Justin Uberti wrote: > On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti = wrote: > I have been noodling on two proposals here: >=20 > a) merging regular and aggressive nom > -- essentially, Jonathan's suggestion from before: > -- controlling side sends on any Valid pair, even prior to a pair = being selected > -- controlled side can send on any Valid pair (although it could use = receipt of media to align with controlling side) > -- controller confirms selection with use-candidate (same as today), = which ends concludes ICE > -- no ice-options needed (AFAICT) >=20 > b) adding a new mode, "continuous" nomination > -- ICE never concludes; controlling side is always able to change = media path dynamically > -- as a corollary, controlling side controls when remote candidates = can be freed > -- new candidates can be trickled at any time > -- controlled side uses either receipt of (secure) media to align with = controlling side, or receipt of new use-candidate checks > -- this mode requires opt-in via ice-options:continuous >=20 > I still need to look at how b) might overlap with MICE, but I'd be = happy to write either of these up or present them in Honolulu.=20 >=20 > I looked into how MICE works; I think that continuous nomination might = be able to effectively support that use case, Agreed, it should work nicely with MICE. The critical aspect of MICE is = the same as the continuous nomination, namely, that ICE keeps running on = both endpoints. > as well as the case that Brandon was interested in, namely picking the = route that uses the best set of TURN servers. -d >=20 > On Tue, Nov 4, 2014 at 9:50 AM, Ari Ker=E4nen = wrote: > All, >=20 > This feature seemed to get quite a bit of support. >=20 > There were also some concerns about: >=20 > * DTLS implementations *may* not like the fact that Hello comes from = an unexpected candidate (may also apply to other protocols?) >=20 > * Whether (and when) the selected candidate is really firm and the = others can be freed, media on them discarded, or an ICE library can = return a socket that is bound to right candidate >=20 > See also the threads: > http://www.ietf.org/mail-archive/web/mmusic/current/msg13596.html > http://www.ietf.org/mail-archive/web/mmusic/current/msg13656.html >=20 > I'm planning to take this as a discussion item during the meeting, but = before that it would be great if the proponents of the change could come = up with a text proposal. I assume we'd need an ICE option to indicate = this and clarify what to do with data on a candidate without = USE-CANDIDATE exchange. >=20 > Also, if I missed some point why this would be a bad idea, please = speak now. >=20 >=20 --Apple-Mail=_9498041C-8D3F-4D09-8162-10386AAB591C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 On Nov = 6, 2014, at 1:47 PM, Justin Uberti <juberti@google.com> = wrote:

On Thu, Nov 6, 2014 at 12:45 PM, = Justin Uberti <juberti@google.com> wrote:
I have been noodling on two = proposals here:

a) merging regular and aggressive = nom
-- essentially, Jonathan's suggestion from = before:
-- controlling side sends on any Valid pair, even = prior to a pair being selected
-- controlled side can send on = any Valid pair (although it could use receipt of media to align with = controlling side)
-- controller confirms selection with = use-candidate (same as today), which ends concludes ICE
-- no = ice-options needed (AFAICT)

b) adding a new = mode, "continuous" nomination
-- ICE never concludes; = controlling side is always able to change media path = dynamically
-- as a corollary, controlling side controls when = remote candidates can be freed
-- new candidates can be = trickled at any time
-- controlled side uses either receipt of = (secure) media to align with controlling side, or receipt of new = use-candidate checks
-- this mode requires opt-in via = ice-options:continuous

I still need to look at = how b) might overlap with MICE, but I'd be happy to write either of = these up or present them in = Honolulu. 

I looked = into how MICE works; I think that continuous nomination might be able to = effectively support that use case, =

Agreed, it = should work nicely with MICE.  The critical aspect of MICE is the = same as the continuous nomination, namely, that ICE keeps running on = both endpoints.

as well as the = case that Brandon was interested in, namely picking the route that uses = the best set of TURN = servers.

-d
<= div>


On Tue, Nov 4, 2014 = at 9:50 AM, Ari Ker=E4nen <ari.keranen@ericsson.com> = wrote:
All,

This feature seemed to get quite a bit of support.

There were also some concerns about:

* DTLS implementations *may* not like the fact that Hello comes from an = unexpected candidate (may also apply to other protocols?)

* Whether (and when) the selected candidate is really firm and the = others can be freed, media on them discarded, or an ICE library can = return a socket that is bound to right candidate

See also the threads:
http://www.ietf.org/mail-archive/web/mmusic/curre= nt/msg13596.html
http://www.ietf.org/mail-archive/web/mmusic/curre= nt/msg13656.html

I'm planning to take this as a discussion item during the meeting, but = before that it would be great if the proponents of the change could come = up with a text proposal. I assume we'd need an ICE option to indicate = this and clarify what to do with data on a candidate without = USE-CANDIDATE exchange.

Also, if I missed some point why this would be a bad idea, please speak = now.



= --Apple-Mail=_9498041C-8D3F-4D09-8162-10386AAB591C-- From nobody Thu Nov 6 14:16:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EA51A9308 for ; Thu, 6 Nov 2014 14:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0HprcBgKWpX for ; Thu, 6 Nov 2014 14:16:22 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9161A924A for ; Thu, 6 Nov 2014 14:16:22 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id hl2so11602098igb.16 for ; Thu, 06 Nov 2014 14:16:21 -0800 (PST) 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=OAnT+9r0+9+uIf6K83VxWhPj71zxm56+1aoPl7fhIB0=; b=hrF8y30CKUwzLJS4h5xWGk9wDDvTUp9WxFdtbAtsmaJ72s4QkfBhPK/qdWtqpm6Fjn oYjl9rS/fLPYsQG858NordneubPKWQByrXUhfjSjqavrNozDDK1vq4wKZMpVmzSiYRv5 zkJTJzYcIhnw9VYex095F4x+ZSHfUeH8p1Ptz7Q08hg554Vk09KM3/KMLkoTcyNoSzlN fuSFDeUuZScWN3dVB6PA3yJieHO39l8EPKkusb9yXiLE+avrDnlE/MH/4siROVrpq1cb y2d6TOPcR4dvtyB206NWX01vUXebWbKltzjyH00v7N61YqfBkfcuDU2tOiYUeDiWFjkv qjVA== MIME-Version: 1.0 X-Received: by 10.107.138.26 with SMTP id m26mr7926351iod.64.1415312181580; Thu, 06 Nov 2014 14:16:21 -0800 (PST) Received: by 10.50.95.199 with HTTP; Thu, 6 Nov 2014 14:16:21 -0800 (PST) Received: by 10.50.95.199 with HTTP; Thu, 6 Nov 2014 14:16:21 -0800 (PST) In-Reply-To: <9282A6B3-6F81-4C54-9AA7-02A8EB669713@cisco.com> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <9282A6B3-6F81-4C54-9AA7-02A8EB669713@cisco.com> Date: Thu, 6 Nov 2014 14:16:21 -0800 Message-ID: From: Varun Singh To: "Dan Wing (dwing)" Content-Type: multipart/alternative; boundary=001a113ff6aad45b540507380b97 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/an_nKCMD7M0ZfqEQAep76ZoWAmc Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 22:16:26 -0000 --001a113ff6aad45b540507380b97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6 Nov 2014 12:09, "=F0=9F=94=93Dan Wing" wrote: > > On Nov 6, 2014, at 1:47 PM, Justin Uberti wrote: > >> On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti wrote: >>> >>> I have been noodling on two proposals here: >>> >>> a) merging regular and aggressive nom >>> -- essentially, Jonathan's suggestion from before: >>> -- controlling side sends on any Valid pair, even prior to a pair being selected >>> -- controlled side can send on any Valid pair (although it could use receipt of media to align with controlling side) >>> -- controller confirms selection with use-candidate (same as today), which ends concludes ICE >>> -- no ice-options needed (AFAICT) >>> >>> b) adding a new mode, "continuous" nomination >>> -- ICE never concludes; controlling side is always able to change media path dynamically >>> -- as a corollary, controlling side controls when remote candidates can be freed >>> -- new candidates can be trickled at any time >>> -- controlled side uses either receipt of (secure) media to align with controlling side, or receipt of new use-candidate checks >>> -- this mode requires opt-in via ice-options:continuous >>> >>> I still need to look at how b) might overlap with MICE, but I'd be happy to write either of these up or present them in Honolulu. >> >> >> I looked into how MICE works; I think that continuous nomination might be able to effectively support that use case, > > > Agreed, it should work nicely with MICE. The critical aspect of MICE is the same as the continuous nomination, namely, that ICE keeps running on both endpoints. > >> as well as the case that Brandon was interested in, namely picking the route that uses the best set of TURN servers. > This behavior is also required by Multipath RTP, where an endpoint may change candidates and/or use several of these candidates simultaneously. > > -d > > >>> >>> On Tue, Nov 4, 2014 at 9:50 AM, Ari Ker=C3=A4nen wrote: >>>> >>>> All, >>>> >>>> This feature seemed to get quite a bit of support. >>>> >>>> There were also some concerns about: >>>> >>>> * DTLS implementations *may* not like the fact that Hello comes from an unexpected candidate (may also apply to other protocols?) >>>> >>>> * Whether (and when) the selected candidate is really firm and the others can be freed, media on them discarded, or an ICE library can return a socket that is bound to right candidate >>>> >>>> See also the threads: >>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg13596.html >>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg13656.html >>>> >>>> I'm planning to take this as a discussion item during the meeting, but before that it would be great if the proponents of the change could come up with a text proposal. I assume we'd need an ICE option to indicate this and clarify what to do with data on a candidate without USE-CANDIDATE exchange. >>>> >>>> Also, if I missed some point why this would be a bad idea, please speak now. >>>> >>>> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113ff6aad45b540507380b97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 Nov 2014 12:09, "=F0=9F=94=93Dan Wing" <dwing@cisco.com> wrote:
>
> On Nov 6, 2014, at 1:47 PM, Justin Uberti <juberti@google.com> wrote:
>
>> On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti <juberti@google.com> wrote:
>>>
>>> I have been noodling on two proposals here:
>>>
>>> a) merging regular and aggressive nom
>>> -- essentially, Jonathan's suggestion from before:
>>> -- controlling side sends on any Valid pair, even prior to a p= air being selected
>>> -- controlled side can send on any Valid pair (although it cou= ld use receipt of media to align with controlling side)
>>> -- controller confirms selection with use-candidate (same as t= oday), which ends concludes ICE
>>> -- no ice-options needed (AFAICT)
>>>
>>> b) adding a new mode, "continuous" nomination
>>> -- ICE never concludes; controlling side is always able to cha= nge media path dynamically
>>> -- as a corollary, controlling side controls when remote candi= dates can be freed
>>> -- new candidates can be trickled at any time
>>> -- controlled side uses either receipt of (secure) media to al= ign with controlling side, or receipt of new use-candidate checks
>>> -- this mode requires opt-in via ice-options:continuous
>>>
>>> I still need to look at how b) might overlap with MICE, but I&= #39;d be happy to write either of these up or present them in Honolulu.=C2= =A0
>>
>>
>> I looked into how MICE works; I think that continuous nomination m= ight be able to effectively support that use case,
>
>
> Agreed, it should work nicely with MICE.=C2=A0 The critical aspect of = MICE is the same as the continuous nomination, namely, that ICE keeps runni= ng on both endpoints.
>
>> as well as the case that Brandon was interested in, namely picking= the route that uses the best set of TURN servers.
>

This behavior is also required by Multipath RTP, where an en= dpoint may change candidates and/or use several of these candidates simulta= neously.

>
> -d
>
>
>>>
>>> On Tue, Nov 4, 2014 at 9:50 AM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote= :
>>>>
>>>> All,
>>>>
>>>> This feature seemed to get quite a bit of support.
>>>>
>>>> There were also some concerns about:
>>>>
>>>> * DTLS implementations *may* not like the fact that Hello = comes from an unexpected candidate (may also apply to other protocols?)
>>>>
>>>> * Whether (and when) the selected candidate is really firm= and the others can be freed, media on them discarded, or an ICE library ca= n return a socket that is bound to right candidate
>>>>
>>>> See also the threads:
>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg= 13596.html
>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg= 13656.html
>>>>
>>>> I'm planning to take this as a discussion item during = the meeting, but before that it would be great if the proponents of the cha= nge could come up with a text proposal. I assume we'd need an ICE optio= n to indicate this and clarify what to do with data on a candidate without = USE-CANDIDATE exchange.
>>>>
>>>> Also, if I missed some point why this would be a bad idea,= please speak now.
>>>>
>>>>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic
>

--001a113ff6aad45b540507380b97-- From nobody Thu Nov 6 14:34:00 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F029E1A0004 for ; Thu, 6 Nov 2014 14:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AplzEQ2npBh for ; Thu, 6 Nov 2014 14:33:58 -0800 (PST) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE701A0040 for ; Thu, 6 Nov 2014 14:33:52 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id q108so1567570qgd.13 for ; Thu, 06 Nov 2014 14:33:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=J7JfXs7dXMXegLb/6JMNwWLIaOgpen0Efigc/Xm3lvw=; b=OxzcHJwA8MZQsFVYjZhjyUuDf13UkIrwnFlpe8Ei31FlEbHBRDXr5OFlKgfldolHAY 8d5zYHqw1DgtGQDF0b/qiCSwwXwfkBM4cGE9fNy2sHv2EpQtnh5WFqg/P9W5/Xw5vrfb vXMYI2ugtkOfx0AZ0Z8MfpGTCpm37/TNQbZU6uI4CbXJiTtLMvt+k9bYDvoxMsqxvXJh iOEEEYm6zdPHPenM7hss/Kvx9TVfJcNXgb47RBzkpK0rS0sJLxvZZAZvLQe/Th2/wrXx m1GI+fnsEEqtBqcKfvHVWKZwo3E8vJQfbUcu/QfAJxuBdIslLtvpYtQPPPQAkzYkPmKu fpow== X-Gm-Message-State: ALoCoQl+vmSjtVLdIgYgBirF7EbbJRketBFqI0eccfdqN6w8nXY4yS77wyhHbSR7VVafIxZOCGdD X-Received: by 10.229.173.193 with SMTP id q1mr11749686qcz.10.1415313231409; Thu, 06 Nov 2014 14:33:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 6 Nov 2014 14:33:31 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 6 Nov 2014 23:33:31 +0100 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/btCn1VVq4PO9FEfwvTGoAw50uco Cc: Arturo Martin De Nicolas , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 22:33:59 -0000 2014-11-06 20:44 GMT+01:00 Justin Uberti : > I think it is clear we are talking about these protocols being multiplexe= d > across a single DTLS connection here. IMHO that's clear too. May be it should also be clear that SRTP is not carried on top of a DTLS connection, but on top of a "channel" established via a DTLS handshake. --=20 I=C3=B1aki Baz Castillo From nobody Thu Nov 6 14:42:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCE71AC42E for ; Thu, 6 Nov 2014 14:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-hUCSOxwVKQ for ; Thu, 6 Nov 2014 14:42:07 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F751A797C for ; Thu, 6 Nov 2014 14:42:06 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id m20so1685243qcx.13 for ; Thu, 06 Nov 2014 14:42:06 -0800 (PST) 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=J6zSuMc6hBWz3rfaHvPgDoqVw79ZFfpWRy4k/s5+2is=; b=U0oDamwaqRDRPUwG0POKqEiXVr44EXfL/ObFaq4xk0UCZTiCXcnL2K4/I7n0H2A8qd +mlD2Iw7v2oJO+R/76P4WLM0Lr4x0GSWUgwdZNH8UVAupuc/2wrwA0nEl4Uzbz3pvjpm 6YdkLp0hPrgWMmuYiv/X2gQpSGte3U+WwmdRclNuEVYO2I6nYnr5UUm6JprkMGxu0Snd fbmgpzuXZqNX3b5W59RvH+eH5snmHhHze8/hubECR3mjeS7lFhr+KWYgTnQdY5nxSpn4 Op31h3nfIlfkyJFqVpQKJ+NO3VbJZ6cKMGnoE3wUWfKBZpFdo5mXvA7Bc1F4BNwhM1+J PINg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=J6zSuMc6hBWz3rfaHvPgDoqVw79ZFfpWRy4k/s5+2is=; b=Gr2UruTyvQzfw6Kn9dAUZKiBPbc3WUVPmjbb+OmkGB+F6Cc3YKuocdJqIV5XgqNhvC nmV8cWaltTs7+hpK3pD7hXBXV7/Cj4v6IfGoNESOT3/4HpsHN7RIQSF1rzppvjZ/+tqt h6RcqNajO5/maNGeUnXi7vakk+4UOlHbOGh2JHq/Pyohai7vCMMz5JiQhiNNU+B4XdZ8 JDbg2PiYJvfgwlGNDSu8SxOrQyFoP6+f0Oc7EaarY+MNMPwoCqeR9T+ZP2xi7W0248vi 84NThFCLJvqI5JRV8xr0x/xka3qR8qAsT5id+QnMmoQI7hu8tgvcxgHwBPgtI/xqZ/e9 wABA== X-Gm-Message-State: ALoCoQncrRLGGR/q9hn0cmUaEgVPB2Mb6ZrkpNsc0SQDnIdvegYTOTCnBfK/XZjx0qGPpWlMURVc X-Received: by 10.229.115.7 with SMTP id g7mr11824793qcq.2.1415313726133; Thu, 06 Nov 2014 14:42:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.181.198 with HTTP; Thu, 6 Nov 2014 14:41:44 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 6 Nov 2014 14:41:44 -0800 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11333886e479b20507386711 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fL-swbZ6tppaCnh14BgJi6r3Em0 Cc: Arturo Martin De Nicolas , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 22:42:08 -0000 --001a11333886e479b20507386711 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable SRTP is already mentioned in the preceding paragraph ( https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-12#sec= tion-9.2), but I suppose you could spell it out here that the SRTP traffic is outside the DTLS connection. On Thu, Nov 6, 2014 at 2:33 PM, I=C3=B1aki Baz Castillo wro= te: > 2014-11-06 20:44 GMT+01:00 Justin Uberti : > > I think it is clear we are talking about these protocols being > multiplexed > > across a single DTLS connection here. > > IMHO that's clear too. May be it should also be clear that SRTP is not > carried on top of a DTLS connection, but on top of a "channel" > established via a DTLS handshake. > > > -- > I=C3=B1aki Baz Castillo > > --001a11333886e479b20507386711 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SRTP is already mentioned in the preceding paragraph (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-n= egotiation-12#section-9.2), but I suppose you could spell it out here t= hat the SRTP traffic is outside the DTLS connection.

On Thu, Nov 6, 2014 at 2:33 PM, I= =C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
2014-11-06 20:44 GMT+01:00 Justin Uberti &= lt;juberti@google.com>:
> I think it is clear we are talking about these protocols being multipl= exed
> across a single DTLS connection here.

IMHO that's clear too. May be it should also be clear that SRTP = is not
carried on top of a DTLS connection, but on top of a "channel" established via a DTLS handshake.


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

--001a11333886e479b20507386711-- From nobody Thu Nov 6 14:49:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7180D1A00B0 for ; Thu, 6 Nov 2014 14:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdSj44CVXYXW for ; Thu, 6 Nov 2014 14:49:31 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C31D1A0033 for ; Thu, 6 Nov 2014 14:49:31 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-06v.sys.comcast.net with comcast id CNpW1p0035Geu2801NpWCs; Thu, 06 Nov 2014 22:49:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-20v.sys.comcast.net with comcast id CNpW1p0043Ge9ey01NpW9V; Thu, 06 Nov 2014 22:49:30 +0000 Message-ID: <545BFAF9.7010301@alum.mit.edu> Date: Thu, 06 Nov 2014 17:49:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415314170; bh=kun29pVhYOpX0SbvZIeULhofq/SlgY5msOOLRu/yC+U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=v46QQrp4eGh6dEcOp6ijPdKba4GFbISXWAUk2fG8WSrkVLkxYImPnCVLxCmJb6Nss dULr7YWz77QQBAr4+QT5n0TvSh/TW/SzQUhpLlB+2N0dxfIKnIPW0Rx+Fh5WqN6RKk qEdQLY6wdANPPvPFRpux5X8Du4pXSllVAigsjywchwc4kPC55cLQ68mbdBAgKxPIOx P1N3mB7DDzKMyxuDwzmF28fMv/h1RTocAnWL4vN8AeaUszlLR0irt+LMhSCihjWprM qsUE9LTEnDIehHemD4zTP6VZiwu6jCrNUu55WnBpBhsjS/So26xCq2+0a2toaR5IQO LN2X9ww2JL7Ow== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1HDaeTk3U_X3HF5uNBQYUI5QUag Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 22:49:32 -0000 On 11/6/14 5:33 PM, Iñaki Baz Castillo wrote: > 2014-11-06 20:44 GMT+01:00 Justin Uberti : >> I think it is clear we are talking about these protocols being multiplexed >> across a single DTLS connection here. > > IMHO that's clear too. May be it should also be clear that SRTP is not > carried on top of a DTLS connection, but on top of a "channel" > established via a DTLS handshake. IIUC (dubious), SRTP is carried directly on UDP, multiplexed with DTLS messages. SRTP uses certain DTLS messages to negotiate the keys, so perhaps the key-negotiation part of SRTP can be considered to be within some aspect of DTLS. That might not be part of the DTLS *connection* - I would think that is reserved for the DTLS payload packets. Clearly the layering here is very weird. Thanks, Paul From nobody Thu Nov 6 15:29:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AA81ACD23 for ; Thu, 6 Nov 2014 15:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyU1O_0x_gsy for ; Thu, 6 Nov 2014 15:29:25 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D51E1A00A7 for ; Thu, 6 Nov 2014 15:29:25 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id 10so1818374lbg.0 for ; Thu, 06 Nov 2014 15:29:23 -0800 (PST) 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=rHEi9BAPXJhwUaXzTNtozjHGEyjGQL85VUdqYs9r6Yg=; b=N1xfqoQv+O8CX/qy66Mulne+gH4/4hD01tV843uRGm/4maIdBhk5rr7BPshYErnkgc 4QX1Qi1OGKXqS91kFrUBx4njxDmCip6yoMVD2wgdawOiNNVXo5DxFGXkOAFrwQulqq8S UmAeDNM0t7byTPN2/hz5hSOHEmP9BTdeeIu5q/NTXGrf6bOlzZmxJDWPbzd3nY59d85c dp2kxz6fi0oiScIcnpzdw9nXxqZGeKWHEiprWAV4Iitz7ydrGaiKJYwI/maFNLyCsVpI ZneN/ZEGDUyvV0XV5O3Hm60yUd2joPnwKAzLFpn1fk14i9TA7kbrLYQe6Eyp4kXHXxkM Scbg== MIME-Version: 1.0 X-Received: by 10.152.43.229 with SMTP id z5mr7778354lal.86.1415316563465; Thu, 06 Nov 2014 15:29:23 -0800 (PST) Received: by 10.25.215.134 with HTTP; Thu, 6 Nov 2014 15:29:23 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> Date: Thu, 6 Nov 2014 15:29:23 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Lz0ge7fJ-eENLsmvNXoojoxJz_s Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:29:27 -0000 On 6 November 2014 13:47, Justin Uberti wrote: > I looked into how MICE works; I think that continuous nomination might be > able to effectively support that use case, as well as the case that Brandon > was interested in, namely picking the route that uses the best set of TURN > servers. I've always believe that continuous ICE operation was the only way to ensure proper reliability. Multipath or otherwise. You just need to work out when it is safe to completely stop on any given pair, assuming that you don't want to be testing the complete mesh all the time. But you also might want multiple paths available, or maybe backup paths. From nobody Thu Nov 6 15:44:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD011A00FC for ; Thu, 6 Nov 2014 15:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo5c4yJas7sE for ; Thu, 6 Nov 2014 15:44:27 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836AA1A00F1 for ; Thu, 6 Nov 2014 15:44:27 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id a141so1576611oig.41 for ; Thu, 06 Nov 2014 15:44:26 -0800 (PST) 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=ZS4RPW65v314Pio2Bl1rEPbo4S22xvg9LtjYCl4vt90=; b=ogezpuwW35l3FVqtjdhmiHSXdWSKk+uUICOHO8ta09p2VU9CxK2pb+8VwI7elrpDz2 JtcK/03i9LDbbXevnuPura36uPBqtf4rhgQn37uBLaA94lWXL3xyN0BKh1GmYrXqqJ42 PAxneWeFgGMtNzYmMuB+nprRk+QfsaPyc/3HKjGL2zrVwnuemgIWUnEYhH7WJmw4fSL3 xJifp7zgVHWvm2e4qgh9IxMqU25I5IMLGxpuAopJN4vCFHa0TdqgdyzjGVlUNHDybA8E y94ZX0clopFej4AiX0xpQEfuUY5bJissb6HVDdgvgL90r8iabkN7Uoi+cpiaEfaU05fM o7Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZS4RPW65v314Pio2Bl1rEPbo4S22xvg9LtjYCl4vt90=; b=YACBA30ZAUv4ByLiWqZpIaCyWxfdggXJrpEWtHFxVjlrhOn5NSq5HaYRlK00bW3V15 Yeye+qZwrJFZ/BazfbLpjxLsJiWwQSJJasiofMxnhHtTbRwNY62Ddhtg+bXrfQ/9JmGl HYqubD8eewfR9NTPcTzdGJp22dlXJ4xTHqxdyQZ6PWSCzfe3283SbKzVj8gXakbk0Hd4 ajP1sLD9ZxYW5fQL2mVvfma38rmEo1jEZSWD6yIdt4f5IdEA7orfv1RNAQCoo70ies2m b4DgpBnGsSwG5fyaZEvm0l9SKrAwhNm+wnawwiog09VJjnpRmeL4KOchyJun8e0BTzAa d2Ng== X-Gm-Message-State: ALoCoQkAYpgaJIpI5Ki9DFAO7zO3oiZnvdkJmwxZ9vmHX/u6SHlR/ZxAYwnr0CTsRyK2vh5kUR6W X-Received: by 10.202.183.70 with SMTP id h67mr5975266oif.19.1415317466584; Thu, 06 Nov 2014 15:44:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Thu, 6 Nov 2014 15:44:05 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> From: Justin Uberti Date: Thu, 6 Nov 2014 15:44:05 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113ce068d7435d0507394690 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ip4-4KiUFBXHoJsALE2YBzgLmcU Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:44:29 -0000 --001a113ce068d7435d0507394690 Content-Type: text/plain; charset=UTF-8 Agreed. I wrote up a slightly more fleshed-out proposal at https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson wrote: > On 6 November 2014 13:47, Justin Uberti wrote: > > I looked into how MICE works; I think that continuous nomination might be > > able to effectively support that use case, as well as the case that > Brandon > > was interested in, namely picking the route that uses the best set of > TURN > > servers. > > > I've always believe that continuous ICE operation was the only way to > ensure proper reliability. Multipath or otherwise. You just need to > work out when it is safe to completely stop on any given pair, > assuming that you don't want to be testing the complete mesh all the > time. But you also might want multiple paths available, or maybe > backup paths. > --001a113ce068d7435d0507394690 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed.


On Thu, Nov 6, = 2014 at 3:29 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 6 Novemb= er 2014 13:47, Justin Uberti <jube= rti@google.com> wrote:
> I looked into how MICE works; I think that continuous nomination might= be
> able to effectively support that use case, as well as the case that Br= andon
> was interested in, namely picking the route that uses the best set of = TURN
> servers.


I've always believe that continuous ICE operation was the only w= ay to
ensure proper reliability.=C2=A0 Multipath or otherwise.=C2=A0 You just nee= d to
work out when it is safe to completely stop on any given pair,
assuming that you don't want to be testing the complete mesh all the time.=C2=A0 But you also might want multiple paths available, or maybe
backup paths.

--001a113ce068d7435d0507394690-- From nobody Thu Nov 6 16:31:41 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA871ACE2C for ; Thu, 6 Nov 2014 16:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id artzVKBK2OcI for ; Thu, 6 Nov 2014 16:31:38 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196151ACE2B for ; Thu, 6 Nov 2014 16:31:37 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kx10so2325916pab.6 for ; Thu, 06 Nov 2014 16:31:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mG4/gK9waVdan98KUBVUNooC9Dj4zCZhI7rEVTFrrwE=; b=bPOnGoxBL/eJ3okRFkzZGVwgbvXtq6qwVwLbQWkLR9otaNBDN8A9afOQE6mno4FSVF u1Jus8KXbdDMm2sC5V0GLlV0M3eqLG7l+v4jQh8rVOUjVHmFHQveTyHSnu3vylfg8KQW OGNj85oec6/nQQbq1wEJ6E/KwcOl0q3BR9FvVUTjUdDq/7mxyLhNrLVZNJl37Q1Qt8MP gXGFljJXxKggEVOkssvkgqQWDzgJ8/2q6icnGnZyzarYcUCu/Ogy6uSCuXotz/RJ0WSz vbdT4lgDUJwUkf6FPpt0qW0yKnWeQK9yOQtE++z/K+oYthjU9sz/xHCYzjwqkRC2xYX7 Z+cA== X-Gm-Message-State: ALoCoQmYqdx9LIW12E2pCdo5UFHsE83RXdbTSMg7s8PpGXgkhEMivBki0cM4yGwvKFuOfDYEvUrt X-Received: by 10.70.56.103 with SMTP id z7mr5450755pdp.164.1415320297596; Thu, 06 Nov 2014 16:31:37 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com. [209.85.220.48]) by mx.google.com with ESMTPSA id qu6sm6885785pbc.92.2014.11.06.16.31.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 16:31:36 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id ey11so2341102pad.21 for ; Thu, 06 Nov 2014 16:31:36 -0800 (PST) X-Received: by 10.66.194.39 with SMTP id ht7mr8023756pac.91.1415320296111; Thu, 06 Nov 2014 16:31:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.100.227 with HTTP; Thu, 6 Nov 2014 16:31:15 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> From: Emil Ivov Date: Fri, 7 Nov 2014 01:31:15 +0100 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lJH1SEUKQGJSSulFjDUkH5Is8K8 Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 00:31:40 -0000 On Fri, Nov 7, 2014 at 12:29 AM, Martin Thomson wrote: > On 6 November 2014 13:47, Justin Uberti wrote: >> I looked into how MICE works; I think that continuous nomination might be >> able to effectively support that use case, as well as the case that Brandon >> was interested in, namely picking the route that uses the best set of TURN >> servers. > > I've always believe that continuous ICE operation was the only way to > ensure proper reliability. Multipath or otherwise. You just need to > work out when it is safe to completely stop on any given pair, > assuming that you don't want to be testing the complete mesh all the > time. But you also might want multiple paths available, or maybe > backup paths. There are two aspects here: 1. Obtaining multiple valid paths as a result of ICE processing (and leaving it up to apps to use one or more) and 2. Handling events where new candidates become available and need to be communicated to the remote party. "1" can definitely be very useful so that would be a great feature to add to ICE. I agree that, especially with mobiles, "2" is also important. That said, what is the problem of doing this with Trickle ICE today? Starting a new Trickle ICE negotiation is a very light-weight process. It is basically a matter of sending a new ufrag/pwd pair. It is also a non-disruptive process as media continues during ICE processing and failure results in falling back to whatever one had before. Also note that, if new candidates appear as a result of mobility event, it might be worth rechecking your previous pairs anyway because some of them may have become invalid or, on the contrary, more relevant. On the other hand, having a clear "start" and "end" in ICE processing also has value as it allows one to declare failure in a deterministic way, as opposed to just waiting out magic timers. I other words, I think we already have everything that is necessary for continuous ICE operation, don't we? Emil -- https://jitsi.org From nobody Thu Nov 6 16:37:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3D71ACE43 for ; Thu, 6 Nov 2014 16:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8pRIFZ76ZKt for ; Thu, 6 Nov 2014 16:37:07 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABFA1ACE3A for ; Thu, 6 Nov 2014 16:37:07 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id gd6so3514875lab.20 for ; Thu, 06 Nov 2014 16:37:05 -0800 (PST) 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=1cQm0dPMlFxtLnS33MhfduvgT++gi9EScQy2rtBc6gY=; b=CLpZJzVTBsOnla493ZwwBiSno9UYiNHDfOfIiFsFHl6tTvhFkTjKnZdOOisjjAYRt3 Pu0ydHVXamh/V1H2BeyC6pRxXjfLI/pQI7pjoh428T30xZl/ivFA8Y/nimgRnWm1R/Aq LxyNvPz+hXpNeP3K1awbPLNHpqbICybHdKRWnUIbTGywNfkEw/RFb+s6sz/TCvAc7hTU Rtet1vmLlckhRnee0lubsFXhBiJE9UUEkhay2IgEFMBJRn4uW6bMZjxGwHTkkVrg/5EY FMAwMWur0SKF6bnGNupT2bOjn4GhH3Xu1gZDV0TZZyzAMb8DeQPm/yrfHj7AJU3b2Myn /jKQ== MIME-Version: 1.0 X-Received: by 10.112.54.229 with SMTP id m5mr8056598lbp.11.1415320625572; Thu, 06 Nov 2014 16:37:05 -0800 (PST) Received: by 10.25.215.134 with HTTP; Thu, 6 Nov 2014 16:37:05 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> Date: Thu, 6 Nov 2014 16:37:05 -0800 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FyyGK6u0iIIe5RzgVHzCQ3G9_PA Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 00:37:09 -0000 On 6 November 2014 16:31, Emil Ivov wrote: > I agree that, especially with mobiles, "2" is also important. That > said, what is the problem of doing this with Trickle ICE today? ICE ends. A candidate that arrives after that point is not going to change anything. > I other words, I think we already have everything that is necessary > for continuous ICE operation, don't we? Almost. I think that Justin has identified the gap reasonably well in his doc. (Justin, please turn this into a draft :) Honestly, I think that this is the sort of thing that ICE-bis should be tackling, more than just a little fixup. From nobody Thu Nov 6 16:42:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C371ACE4C for ; Thu, 6 Nov 2014 16:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_FZreuwulfp for ; Thu, 6 Nov 2014 16:42:04 -0800 (PST) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65FD1ACE38 for ; Thu, 6 Nov 2014 16:42:03 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id g10so2168661pdj.24 for ; Thu, 06 Nov 2014 16:42:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZsgeplbHzQwwCxGkFieJrAiIjALf5Ke7Ecsl9uge5ls=; b=V6P20p0DFDmb+kAtM0e/UdkwK1LoaXgebB+9GIPXQ6i1fVR81tE4/QiarbYvymgPct oLIJl4AL+XieswLye1plgXUnFI9zsVzgf/5JgYod1YXNdrm6ANs3JlrOJpGpoefFuYP4 wRnT71aj0bdTQBqTcYCehGS33D7Jk2roUy06uL4HcMPYrabSI6+OeSZpOCAxxcoDeEA2 Pb4tppvxu5EbJCLalaN7LBA9FdyORKXN2qAuuLWiU5jXypioblUNAUJOE9wPQmrHq+P8 WuMjg12tutZW/cLNMK6oyhRkQxB5FsKtVl0xKdNdhsFTcGpW6Y7TXEX50TgzrZO3J7Vb sNew== X-Gm-Message-State: ALoCoQkhZhDz5Z2KLsts81Wlr9uSg0phoGmvNyN7ybWmvv+Y2dNhOTQppHauCyGSfZ0gqSOeRQ25 X-Received: by 10.66.176.39 with SMTP id cf7mr8058271pac.93.1415320923556; Thu, 06 Nov 2014 16:42:03 -0800 (PST) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com. [209.85.192.172]) by mx.google.com with ESMTPSA id fn4sm7008895pab.39.2014.11.06.16.42.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 16:42:02 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id r10so2188094pdi.17 for ; Thu, 06 Nov 2014 16:42:02 -0800 (PST) X-Received: by 10.66.252.193 with SMTP id zu1mr5494922pac.153.1415320922438; Thu, 06 Nov 2014 16:42:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.100.227 with HTTP; Thu, 6 Nov 2014 16:41:42 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> From: Emil Ivov Date: Fri, 7 Nov 2014 01:41:42 +0100 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jsJz0it8bbvpfoV2Y-a78GvFBDI Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 00:42:06 -0000 On Fri, Nov 7, 2014 at 1:37 AM, Martin Thomson wrote: > On 6 November 2014 16:31, Emil Ivov wrote: >> I agree that, especially with mobiles, "2" is also important. That >> said, what is the problem of doing this with Trickle ICE today? > > ICE ends. Right, and that's a feature. It means that if you don't have a working pair by the time it ends you can rapidly declare failure. > A candidate that arrives after that point is not going to > change anything. This is wrong. Just attach a new ufrag/pwd to your new cand and it can change everything. >> I other words, I think we already have everything that is necessary >> for continuous ICE operation, don't we? > > Almost. I think that Justin has identified the gap reasonably well in > his doc. (Justin, please turn this into a draft :) Could you please point me to the text that you thing does this? I must be missing it because I don't see it. Emil -- https://jitsi.org From nobody Thu Nov 6 17:39:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CB91ACE50 for ; Thu, 6 Nov 2014 17:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y81JxiHhNsZA for ; Thu, 6 Nov 2014 17:39:40 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7232A1A6F38 for ; Thu, 6 Nov 2014 17:39:40 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id g201so1707407oib.38 for ; Thu, 06 Nov 2014 17:39:39 -0800 (PST) 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=FpJYzXgopcHxsHA4mi8W6RSuVLEUErtXe2nNADVzT3c=; b=AfoCIX9ervS6vtf0ATcxM/KeI+8TyU2V1sK7RV0zzgXkQo9lTF1+dMcDC1W2QYVPAL dDknXwhH2qD1JtcbpUdhhT0eWMQabCQjUNhT/Zrj7FhQCt4jeoy6vjWzOzPc+VMf7CXY Ex3lo4G71BjS6i+V6r0T8OdZmkdvgJqvn+7b9AYuMX1xz0o+cvoza2dCsCNVgy180z9J aFvfN5r16SzMpMP7Hrwt/uHepPj4DSQwzbHSQ9T5CuLl0xcmserdnr4+J3vaXdYA8qja WaMVCYf9UU8LjU6PSpvRKSNYZFsO3vnaXaIt1K9ybTbWfS6haB+cu8W1QTKAJ5gW/GFG Bweg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FpJYzXgopcHxsHA4mi8W6RSuVLEUErtXe2nNADVzT3c=; b=D3yKphRIVOnuzSChugy6dksy2o5Ljpwn4KxDlTySLv8GTNhntv7ZU3DbXNryxobBfx A7PPmCdVkCp0fW1relq4EqDuGNmXi/Oi3/GySkanmwK99PqIj56tgdzv1awnSr5S0skE p866dHtGTKB1mRv0u59eAGMZi4fSHm87UtRdAdVll9QH7rmWfSRkGfPIoV8bNFrlVNeg 39kgl+ELcfRtWbUwk9zfv1fzNz8I3vaSFFtM3Q2dcR4pN08sr+50scDpq5UjkrYhWF9R CHhX9ECIRk8QS16NaHPViYfgOyjUVgIc++efna4dBODJrK461926w0eGANWwpTguYihw 6Wsg== X-Gm-Message-State: ALoCoQm10F5cAN4vXIa2Y17vEruAwp/1Bhrh+dMl1+EO3Zi8H5vE/ERIl9x+V4ZLLRdGDztztwHH X-Received: by 10.202.178.131 with SMTP id b125mr4954047oif.72.1415324379722; Thu, 06 Nov 2014 17:39:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Thu, 6 Nov 2014 17:39:18 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> From: Justin Uberti Date: Thu, 6 Nov 2014 17:39:18 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113b7e9ce555b305073ae277 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/l1FRnXd-M47s2hpbfDFZy1khLww Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 01:39:42 -0000 --001a113b7e9ce555b305073ae277 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 6, 2014 at 4:37 PM, Martin Thomson wrote: > On 6 November 2014 16:31, Emil Ivov wrote: > > I agree that, especially with mobiles, "2" is also important. That > > said, what is the problem of doing this with Trickle ICE today? > > ICE ends. A candidate that arrives after that point is not going to > change anything. > > > I other words, I think we already have everything that is necessary > > for continuous ICE operation, don't we? > > Almost. I think that Justin has identified the gap reasonably well in > his doc. (Justin, please turn this into a draft :) > I'll see if I can get this done before I fly out. --001a113b7e9ce555b305073ae277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 6, 2014 at 4:37 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 6 November 2014 16:31, Emil Ivov <emcho@jitsi.org> wrote:
> I agree that, especially with mobiles, "2" is also important= . That
> said, what is the problem of doing this with Trickle ICE today?

ICE ends.=C2=A0 A candidate that arrives after that point is not goi= ng to
change anything.

> I other words, I think we already have everything that is necessary > for continuous ICE operation, don't we?

Almost.=C2=A0 I think that Justin has identified the gap reasonably = well in
his doc.=C2=A0 (Justin, please turn this into a draft :)

I'll see if I can get this done before I fly out.=C2= =A0

--001a113b7e9ce555b305073ae277-- From nobody Thu Nov 6 18:46:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722A21ACEA1 for ; Thu, 6 Nov 2014 18:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhfaSI0aXRNE for ; Thu, 6 Nov 2014 18:46:50 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FD31ACEA0 for ; Thu, 6 Nov 2014 18:46:49 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-aa-545c3297de6d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.73.04231.7923C545; Fri, 7 Nov 2014 03:46:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Fri, 7 Nov 2014 03:46:47 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- line with zero port value? Thread-Index: Ac/x2ZqcVHhXpFAJTrS4t9o7Pnz+rgIGMUUAABCsr0w= Date: Fri, 7 Nov 2014 02:46:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4EA6B2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCBC1@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4EA6B2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvje50o5gQg5e/zS22ThWymLr8MYsD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKuHzxE1tBq3nFwS1f2RoY/+t3MXJwSAiYSBz9 k9vFyAlkiklcuLeerYuRi0NI4AijxMUdX1ghnMWMEg9frWQCaWATsJDo/qcN0iAioCbxcNYu VpAws4C6xNXFQSBhYYEUie/LepggSlIlTsxvZgYpERGwklg2tRLEZBFQkfj5mxGkglfAV+LE lw2MEIsmMUp8efuKHSTBKRAocf9YG9gYRqDTvp9aA2YzC4hLNH1ZyQpxsoDEkj3nmSFsUYmX j/+xQtTkS/Ts2cwGsUBQ4uTMJywTGEVmIWmfhaRsFpIyiLiBxJf3t6FsbYllC18zQ9j6Et3v TzMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhNB7f81t3BuPq14yFGAQ5GJR5e gydRIUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXGOzQ/O XbPVmk1955htfsf6/sTj9adPvwtjOiZpIzgr/bRZ9je/UonFGudfhzjqyzV9/nD+9N1Gg8dq nYujXk9Y5HDj89vGBKHAANsG6+087QplydcXfltmOHth0vpnLybfOSUnvOA519elVvc8/9Rv WJS2U+pDFVPgjou66XOnhAdcvtIwgdNSiaU4I9FQi7moOBEAkCb55IcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Yk8MSeB0bV59rttprWITzzgP2jg Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- line with zero port value? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 02:46:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4EA6B2ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Justin, No candidates is what I intend to suggest too. Regards, Christer Sent from my Windows Phone ________________________________ From: Justin Uberti Sent: =FD06/=FD11/=FD2014 21:49 To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- lin= e with zero port value? I don't think you need an ICE candidate for a m=3D line with a zero port va= lue. We already covered something similar for trickle ICE (i.e. the dummy p= orts). On Mon, Oct 27, 2014 at 4:43 AM, Christer Holmberg > wrote: Hi, One question that has been raised by Thomas Stach during the BUNDLE WGLC, i= s regarding ICE candidates and bundle-only m- lines with a zero port value. The current text says that identical ICE candidate values are assigned to b= undle-only m- lines. Now, in the case where a zero port value is assigned to a bundle-only m- li= nes, it means that a candidate with a zero port value is also needed (in or= der to fulfil the ICE rules for default candidates). IF we want to avoid that, a couple of alternatives have been presented: 1) Do not assign ICE candidates to bundle-only m- lines with port zero= . The problem is that the answerer, even if it supports BUNDLE/bundle-only,= doesn=92t know whether the offerer wants to use ICE for those m- lines; or 2) Relax the 5245 rules, so that there doesn=92t need to be a candidat= e matching the m- line port value. Comments? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D4EA6B2ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Justin,
No candidates is what I intend to suggest too.

Regards,

Christer

Sent from my Windows Phone
From: Justin Uberti
Sent: =FD06= /=FD11/=FD2014 21:49
To: Christer Holmberg Cc: mmusic@ietf.org
Subject: Re: [= MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- line with zero po= rt value?

I don't think you need an ICE candidate for a m=3D line wi= th a zero port value. We already covered something similar for trickle ICE = (i.e. the dummy ports).

On Mon, Oct 27, 2014 at 4:43 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

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

 

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

 

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

 

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

 

1)&n= bsp;     Do not assign ICE candida= tes to bundle-only m- lines with port zero. The problem is that the answere= r, even if it supports BUNDLE/bundle-only, doesn=92t know whether the offer= er wants to use ICE for those m- lines; or

2)&n= bsp;     Relax the 5245 rules, so = that there doesn=92t need to be a candidate matching the m- line port value= .

 

Comments?

 

Regards,

 

Christer

 

 

 


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


--_000_7594FB04B1934943A5C02806D1A2204B1D4EA6B2ESESSMB209erics_-- From nobody Thu Nov 6 19:02:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F691A008A for ; Thu, 6 Nov 2014 19:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9qAGrHQJ2bh for ; Thu, 6 Nov 2014 19:02:15 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B217B1A005A for ; Thu, 6 Nov 2014 19:02:13 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-f0-545c3633277b Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 13.A1.04081.3363C545; Fri, 7 Nov 2014 04:02:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Fri, 7 Nov 2014 04:02:11 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/gAHOIkwAAnwGgD///LfgIAAL06AgAAEdoCAAFddvw== Date: Fri, 7 Nov 2014 03:02:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> , <545BFAF9.7010301@alum.mit.edu> In-Reply-To: <545BFAF9.7010301@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4EA783ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja6xWUyIwZ1rWhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxve0BU8EC44q5p9cxNjA+Mexi5OCQEDCR mP87u4uRE8gUk7hwbz1bFyMXh5DAEUaJqW9OMoIkhAQWM0o0LlMHqWcTsJDo/qcNEhYR8JV4 9vg2G4gtLGAv0bJtHiNE3EHi0NOJbCDlIgJhEm1rE0HCLAIqEnM3T2UBsXmBWhcvWssIsWoC s8TVH7fAEpwCOhJPv3Swg9iMQPd8P7WGCcRmFhCXaPqykhXiTgGJJXvOM0PYohIvH/9jhajJ l5g65RozxAJBiZMzn7BMYBSehaR9FpKyWUjKZgGdyiygKbF+lz5EiaLElO6H7BC2hkTrnLns yOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRGzsEtvw12ML587niIUYCDUYmHd4Np TIgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCU03ZI+qL2 revdupefO1kDvHxq71dde7HR7r6brOzirOT0thkPl6zu9sk6/XzqkvySHRwtZlHvDFMVtzfW 84U+UvuR+uVyQ/7cr1MqH6m/yAx0YmH9GZz3ucHyjmffshslVxdY8O8QCI46zrhq51TGWn9G 1wkGAXvXqd3feennXqfmlUmG2+WUWIozEg21mIuKEwHSYIw9fQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Qacrpv7JTm4YqGm2GrWKrAmc24M Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 03:02:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4EA783ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFGQUlLLCB5b3UgdXNlIGEgRFRMUyBjb25uZWN0aW9uIChJIGJlbGlldmUgRFRMUy1T UlRQIHVzZXMgYW5vdGhlciB3b3JkLCB0aG91Z2gpIGFsc28gZm9yIFNSVFAuDQoNCkhvd2V2ZXIs IHRoZSB0ZXh0IGFscmVhZHkgZGVzY3JpYmVzIGhvdyB0byBzZXBhcmF0ZSBTUlRQIHBhY2tldHMg ZnJvbSBEVExTIHBhY2tldHMsIHNvIHRoZSBwaWVjZSBvZiB0ZXh0IEkgYnJvdWdodCB1cCBvbmx5 IGFwcGxpZXMgdG8gRFRMUyBwYWNrZXRzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50 IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IFBhdWwgS3l6aXZhdDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KU2VudDog 4oCOMDcv4oCOMTEv4oCOMjAxNCAwMDo0OQ0KVG86IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEJVTkRMRTogTWVhbmluZyBvZiAi dHJhbnNwb3J0ZWQgb24gRFRMUyI/DQoNCk9uIDExLzYvMTQgNTozMyBQTSwgScOxYWtpIEJheiBD YXN0aWxsbyB3cm90ZToNCj4gMjAxNC0xMS0wNiAyMDo0NCBHTVQrMDE6MDAgSnVzdGluIFViZXJ0 aSA8anViZXJ0aUBnb29nbGUuY29tPjoNCj4+IEkgdGhpbmsgaXQgaXMgY2xlYXIgd2UgYXJlIHRh bGtpbmcgYWJvdXQgdGhlc2UgcHJvdG9jb2xzIGJlaW5nIG11bHRpcGxleGVkDQo+PiBhY3Jvc3Mg YSBzaW5nbGUgRFRMUyBjb25uZWN0aW9uIGhlcmUuDQo+DQo+IElNSE8gdGhhdCdzIGNsZWFyIHRv by4gTWF5IGJlIGl0IHNob3VsZCBhbHNvIGJlIGNsZWFyIHRoYXQgU1JUUCBpcyBub3QNCj4gY2Fy cmllZCBvbiB0b3Agb2YgYSBEVExTIGNvbm5lY3Rpb24sIGJ1dCBvbiB0b3Agb2YgYSAiY2hhbm5l bCINCj4gZXN0YWJsaXNoZWQgdmlhIGEgRFRMUyBoYW5kc2hha2UuDQoNCklJVUMgKGR1YmlvdXMp LCBTUlRQIGlzIGNhcnJpZWQgZGlyZWN0bHkgb24gVURQLCBtdWx0aXBsZXhlZCB3aXRoIERUTFMN Cm1lc3NhZ2VzLiBTUlRQIHVzZXMgY2VydGFpbiBEVExTIG1lc3NhZ2VzIHRvIG5lZ290aWF0ZSB0 aGUga2V5cywgc28NCnBlcmhhcHMgdGhlIGtleS1uZWdvdGlhdGlvbiBwYXJ0IG9mIFNSVFAgY2Fu IGJlIGNvbnNpZGVyZWQgdG8gYmUgd2l0aGluDQpzb21lIGFzcGVjdCBvZiBEVExTLiBUaGF0IG1p Z2h0IG5vdCBiZSBwYXJ0IG9mIHRoZSBEVExTICpjb25uZWN0aW9uKiAtIEkNCndvdWxkIHRoaW5r IHRoYXQgaXMgcmVzZXJ2ZWQgZm9yIHRoZSBEVExTIHBheWxvYWQgcGFja2V0cy4NCg0KQ2xlYXJs eSB0aGUgbGF5ZXJpbmcgaGVyZSBpcyB2ZXJ5IHdlaXJkLg0KDQogICAgICAgIFRoYW5rcywNCiAg ICAgICAgUGF1bA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K --_000_7594FB04B1934943A5C02806D1A2204B1D4EA783ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGksPGJyPg0KPGJyPg0KQUZBSUssIHlv dSB1c2UgYSBEVExTIGNvbm5lY3Rpb24gKEkgYmVsaWV2ZSBEVExTLVNSVFAgdXNlcyBhbm90aGVy IHdvcmQsIHRob3VnaCkgYWxzbyBmb3IgU1JUUC4NCjxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSB0 ZXh0IGFscmVhZHkgZGVzY3JpYmVzIGhvdyB0byBzZXBhcmF0ZSBTUlRQIHBhY2tldHMgZnJvbSBE VExTIHBhY2tldHMsIHNvIHRoZSBwaWVjZSBvZiB0ZXh0IEkgYnJvdWdodCB1cCBvbmx5IGFwcGxp ZXMgdG8gRFRMUyBwYWNrZXRzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0 ZXI8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxocj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5Gcm9tOg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MXB0Ij48YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5QYXVsIEt5eml2YXQ8 L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5TZW50Og0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij7i gI4wNy/igI4xMS/igI4yMDE0IDAwOjQ5PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xk Ij5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2lj QGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDoN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTFwdCI+UmU6IFtNTVVTSUNdIEJVTkRMRTogTWVhbmluZyBvZiAmcXVvdDt0cmFuc3Bv cnRlZCBvbiBEVExTJnF1b3Q7Pzwvc3Bhbj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPk9uIDExLzYvMTQgNTozMyBQTSwgScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZTo8 YnI+DQomZ3Q7IDIwMTQtMTEtMDYgMjA6NDQgR01UJiM0MzswMTowMCBKdXN0aW4gVWJlcnRpICZs dDtqdWJlcnRpQGdvb2dsZS5jb20mZ3Q7Ojxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgaXQgaXMgY2xl YXIgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlc2UgcHJvdG9jb2xzIGJlaW5nIG11bHRpcGxleGVk PGJyPg0KJmd0OyZndDsgYWNyb3NzIGEgc2luZ2xlIERUTFMgY29ubmVjdGlvbiBoZXJlLjxicj4N CiZndDs8YnI+DQomZ3Q7IElNSE8gdGhhdCdzIGNsZWFyIHRvby4gTWF5IGJlIGl0IHNob3VsZCBh bHNvIGJlIGNsZWFyIHRoYXQgU1JUUCBpcyBub3Q8YnI+DQomZ3Q7IGNhcnJpZWQgb24gdG9wIG9m IGEgRFRMUyBjb25uZWN0aW9uLCBidXQgb24gdG9wIG9mIGEgJnF1b3Q7Y2hhbm5lbCZxdW90Ozxi cj4NCiZndDsgZXN0YWJsaXNoZWQgdmlhIGEgRFRMUyBoYW5kc2hha2UuPGJyPg0KPGJyPg0KSUlV QyAoZHViaW91cyksIFNSVFAgaXMgY2FycmllZCBkaXJlY3RseSBvbiBVRFAsIG11bHRpcGxleGVk IHdpdGggRFRMUyA8YnI+DQptZXNzYWdlcy4gU1JUUCB1c2VzIGNlcnRhaW4gRFRMUyBtZXNzYWdl cyB0byBuZWdvdGlhdGUgdGhlIGtleXMsIHNvIDxicj4NCnBlcmhhcHMgdGhlIGtleS1uZWdvdGlh dGlvbiBwYXJ0IG9mIFNSVFAgY2FuIGJlIGNvbnNpZGVyZWQgdG8gYmUgd2l0aGluIDxicj4NCnNv bWUgYXNwZWN0IG9mIERUTFMuIFRoYXQgbWlnaHQgbm90IGJlIHBhcnQgb2YgdGhlIERUTFMgKmNv bm5lY3Rpb24qIC0gSSA8YnI+DQp3b3VsZCB0aGluayB0aGF0IGlzIHJlc2VydmVkIGZvciB0aGUg RFRMUyBwYXlsb2FkIHBhY2tldHMuPGJyPg0KPGJyPg0KQ2xlYXJseSB0aGUgbGF5ZXJpbmcgaGVy ZSBpcyB2ZXJ5IHdlaXJkLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGFua3MsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFBhdWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQptbXVzaWNA aWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8 L2E+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4EA783ESESSMB209erics_-- From nobody Thu Nov 6 23:17:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982531ACF08 for ; Thu, 6 Nov 2014 23:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF66p9NpKO0l for ; Thu, 6 Nov 2014 23:17:27 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B4E1ACF02 for ; Thu, 6 Nov 2014 23:17:27 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id la4so1482980vcb.9 for ; Thu, 06 Nov 2014 23:17:26 -0800 (PST) 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=u2CnOlDYymQuo0mbK9FBUFHBcUdxKM3GK+x/AX2MFUs=; b=i4AKdZpL2lidyBfa7VvI9lXQpndLY1ESXKX1HlKn4LIbuxtSadjRJgOR1SsaWpOyjv THAC5H2+meJvaVF3z+YaFiIrz1gB33F4EgvQcpOqy827QpEfr7CpMssPSRwMxNvUr9yY HULpN4QpQgaNpHu9tFxvbnqXBRWlGuOdRKXepkdRr9JvCfGYGJzikSEfQumH3D3l8FzE OVC6WW+38zLE3OxqvSw6ndvczek2D7VC1/ZT9DTTNJshjOaGmNSVFOBB/7uL6IdziFUR jtvr4zi0ofyIshUvU8XbQYHQmwnhbyiz/1su08OqDDOJxp5o3IPOqHgIwoz5GlG3N6mC krmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=u2CnOlDYymQuo0mbK9FBUFHBcUdxKM3GK+x/AX2MFUs=; b=Rxi71eApHcrRFIH3W9bToXpKc4EeYeHdVu5DzvJpS5tIrwkeFjnlfeQB/x2Axpqrn7 maJ0BTaTrIeqTZjaVK9elq6eoYGy5zkpkK3NFbRTDCgkG8YhslGbEioOYAkLheEqCEYw X6viGuTMDb/CTM2lM0VVR1LSqO5yEcREsGpK/n2FEXuLrF9SEiodnanCuDPHQK28C070 TxPoC21tVL9P7XIP2HXdu0ZNoW2mefO5sqZvEJ4+Nobigf6Lt6cGv4FxuR/SFt6Vu74w g4Deas9wVzqZC05G9TFVNH1hBefx0EiOhrpI1Yx0IKqMuqDSgKmY7ZYV0qJDllvZnHhV Ts0Q== X-Gm-Message-State: ALoCoQlkA8SkBpe2BxD9/FuQgelQvDKkKw3ma+IIMCF3FK54jdQiFRTbt/ElcA6bmxVIbORn/76z X-Received: by 10.52.73.67 with SMTP id j3mr3756730vdv.43.1415344646311; Thu, 06 Nov 2014 23:17:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Thu, 6 Nov 2014 23:17:06 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> <545BFAF9.7010301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 6 Nov 2014 23:17:06 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf3071c804e0ed6c05073f9ab6 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aFFeXbAzXGH6CM-YV67vAAKQSck Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:17:37 -0000 --20cf3071c804e0ed6c05073f9ab6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, the SRTP packets are sent outside the DTLS connection. On Thu, Nov 6, 2014 at 7:02 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > AFAIK, you use a DTLS connection (I believe DTLS-SRTP uses another word, > though) also for SRTP. > > However, the text already describes how to separate SRTP packets from DTL= S > packets, so the piece of text I brought up only applies to DTLS packets. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Paul Kyzivat > Sent: =E2=80=8E07/=E2=80=8E11/=E2=80=8E2014 00:49 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? > > On 11/6/14 5:33 PM, I=C3=B1aki Baz Castillo wrote: > > 2014-11-06 20:44 GMT+01:00 Justin Uberti : > >> I think it is clear we are talking about these protocols being > multiplexed > >> across a single DTLS connection here. > > > > IMHO that's clear too. May be it should also be clear that SRTP is not > > carried on top of a DTLS connection, but on top of a "channel" > > established via a DTLS handshake. > > IIUC (dubious), SRTP is carried directly on UDP, multiplexed with DTLS > messages. SRTP uses certain DTLS messages to negotiate the keys, so > perhaps the key-negotiation part of SRTP can be considered to be within > some aspect of DTLS. That might not be part of the DTLS *connection* - I > would think that is reserved for the DTLS payload packets. > > Clearly the layering here is very weird. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --20cf3071c804e0ed6c05073f9ab6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, the SRTP packets are sent outside the DTLS connection.=

On Thu, Nov= 6, 2014 at 7:02 PM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:
Hi,

AFAIK, you use a DTLS connection (I believe DTLS-SRTP uses another word, th= ough) also for SRTP.

However, the text already describes how to separate SRTP packets from DTLS = packets, so the piece of text I brought up only applies to DTLS packets.
Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =E2=80= =8E07/=E2=80=8E11/=E2=80=8E2014 00:49
To: mmusic@ietf.org Subject: Re: [M= MUSIC] BUNDLE: Meaning of "transported on DTLS"?

On 11/6/14 5:33 PM, I=C3=B1aki Baz Castillo wrote:
> 2014-11-06 20:44 GMT+01:00 Justin Uberti <juberti@google.com>:
>> I think it is clear we are talking about these protocols being mul= tiplexed
>> across a single DTLS connection here.
>
> IMHO that's clear too. May be it should also be clear that SRTP is= not
> carried on top of a DTLS connection, but on top of a "channel&quo= t;
> established via a DTLS handshake.

IIUC (dubious), SRTP is carried directly on UDP, multiplexed with DTLS
messages. SRTP uses certain DTLS messages to negotiate the keys, so
perhaps the key-negotiation part of SRTP can be considered to be within some aspect of DTLS. That might not be part of the DTLS *connection* - I would think that is reserved for the DTLS payload packets.

Clearly the layering here is very weird.

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

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

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


--20cf3071c804e0ed6c05073f9ab6-- From nobody Fri Nov 7 02:16:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8D51ACF79 for ; Fri, 7 Nov 2014 02:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B-6rL2FeYR3 for ; Fri, 7 Nov 2014 02:16:25 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE51C1ACF75 for ; Fri, 7 Nov 2014 02:16:24 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-22-545c9bf64528 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.65.04387.6FB9C545; Fri, 7 Nov 2014 11:16:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Fri, 7 Nov 2014 11:16:22 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/gAHOIkwAAnwGgD///LfgIAAL06AgAAEdoCAAFddv4AANnYA//+9vaA= Date: Fri, 7 Nov 2014 10:16:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4EBC1F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> <545BFAF9.7010301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4EBC1FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3Rvfb7JgQg/bLVhZbpwpZTF3+mMVi xYYDrA7MHn/ff2DyWLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBmLnrgW3MiqWDF/HnsD45P0 LkZODgkBE4nFJ06wQ9hiEhfurWfrYuTiEBI4wigxv30ZlLOYUWLK1RvMXYwcHGwCFhLd/7RB GkQE1CQeztrFCmIzC/hKvFzwhRnEFhawl2jZNo8RosZB4tDTiWwgrSICSRJN9+VBwiwCKhIT Dt5hA7F5gVqnrt0FdoOQwFwWiacQYzgFAiU+/WllArEZgW77fmoNE8QqcYlbT+YzQdwsILFk z3lmCFtU4uXjf6wQtpLEotufoerzJTr/XWaC2CUocXLmE5YJjKKzkIyahaRsFpKyWUBXMwto SqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGR d3DLb6sdjAefOx5iFOBgVOLh3WAaEyLEmlhWXJl7iFGag0VJnHfhuXnBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhht7S/zzV/2sraNe1vf5nsbp9mLbF5wfMsknbib6zhk8w6UbxVftE1D f+20/1oJxqUGTt83aSU1Fy1R0mcN+/1ptXi73D3jktqwLTM6pC/9OHHqdt5UzU+i7hP/Tnnr xOI0+QiXfXJ7pUz5w6DofI3EjV+12cLOTXsrGeJ+1EnS4QD/w/l1Oq5KLMUZiYZazEXFiQBw C/6znQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZfRcsIu3Zr_pkekjRbkLLQHCNQE Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 10:16:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4EBC1FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5ObywgdGhlIFNSVFAgcGFja2V0cyBhcmUgc2VudCBvdXRzaWRlIHRoZSBEVExTIGNv bm5lY3Rpb24uDQoNClRoYXQgaXMgdHJ1ZSwgYnV0IGRvbuKAmXQgeW91IGNyZWF0ZSBhIERUTFMg Y29ubmVjdGlvbiBqdXN0IGJ5IG5lZ290aWF0aW5nIHRoZSBrZXlzIHRoYXQgeW91IGFyZSBnb2lu ZyB0byB1c2UgZm9yIFNSVFA/DQoNCihJIGRvIGFncmVlIHRoYXQg4oCcY29ubmVjdGlvbuKAnSBp cyBtaXNsZWFkaW5nLikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiBUaHUsIE5vdiA2 LCAyMDE0IGF0IDc6MDIgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KSGksDQoNCkFGQUlLLCB5b3UgdXNlIGEgRFRMUyBjb25uZWN0aW9uIChJIGJlbGlldmUgRFRM Uy1TUlRQIHVzZXMgYW5vdGhlciB3b3JkLCB0aG91Z2gpIGFsc28gZm9yIFNSVFAuDQoNCkhvd2V2 ZXIsIHRoZSB0ZXh0IGFscmVhZHkgZGVzY3JpYmVzIGhvdyB0byBzZXBhcmF0ZSBTUlRQIHBhY2tl dHMgZnJvbSBEVExTIHBhY2tldHMsIHNvIHRoZSBwaWVjZSBvZiB0ZXh0IEkgYnJvdWdodCB1cCBv bmx5IGFwcGxpZXMgdG8gRFRMUyBwYWNrZXRzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpT ZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IFBhdWwgS3l6aXZhdDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KU2Vu dDog4oCOMDcv4oCOMTEv4oCOMjAxNCAwMDo0OQ0KVG86IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEJVTkRMRTogTWVhbmluZyBv ZiAidHJhbnNwb3J0ZWQgb24gRFRMUyI/DQpPbiAxMS82LzE0IDU6MzMgUE0sIEnDsWFraSBCYXog Q2FzdGlsbG8gd3JvdGU6DQo+IDIwMTQtMTEtMDYgMjA6NDQgR01UKzAxOjAwIEp1c3RpbiBVYmVy dGkgPGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj46DQo+PiBJ IHRoaW5rIGl0IGlzIGNsZWFyIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZXNlIHByb3RvY29scyBi ZWluZyBtdWx0aXBsZXhlZA0KPj4gYWNyb3NzIGEgc2luZ2xlIERUTFMgY29ubmVjdGlvbiBoZXJl Lg0KPg0KPiBJTUhPIHRoYXQncyBjbGVhciB0b28uIE1heSBiZSBpdCBzaG91bGQgYWxzbyBiZSBj bGVhciB0aGF0IFNSVFAgaXMgbm90DQo+IGNhcnJpZWQgb24gdG9wIG9mIGEgRFRMUyBjb25uZWN0 aW9uLCBidXQgb24gdG9wIG9mIGEgImNoYW5uZWwiDQo+IGVzdGFibGlzaGVkIHZpYSBhIERUTFMg aGFuZHNoYWtlLg0KDQpJSVVDIChkdWJpb3VzKSwgU1JUUCBpcyBjYXJyaWVkIGRpcmVjdGx5IG9u IFVEUCwgbXVsdGlwbGV4ZWQgd2l0aCBEVExTDQptZXNzYWdlcy4gU1JUUCB1c2VzIGNlcnRhaW4g RFRMUyBtZXNzYWdlcyB0byBuZWdvdGlhdGUgdGhlIGtleXMsIHNvDQpwZXJoYXBzIHRoZSBrZXkt bmVnb3RpYXRpb24gcGFydCBvZiBTUlRQIGNhbiBiZSBjb25zaWRlcmVkIHRvIGJlIHdpdGhpbg0K c29tZSBhc3BlY3Qgb2YgRFRMUy4gVGhhdCBtaWdodCBub3QgYmUgcGFydCBvZiB0aGUgRFRMUyAq Y29ubmVjdGlvbiogLSBJDQp3b3VsZCB0aGluayB0aGF0IGlzIHJlc2VydmVkIGZvciB0aGUgRFRM UyBwYXlsb2FkIHBhY2tldHMuDQoNCkNsZWFybHkgdGhlIGxheWVyaW5nIGhlcmUgaXMgdmVyeSB3 ZWlyZC4NCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIFBhdWwNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1t dXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4EBC1FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZndDs8L3NwYW4+Tm8sIHRoZSBTUlRQIHBhY2tldHMgYXJlIHNlbnQgb3V0c2lk ZSB0aGUgRFRMUyBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGF0IGlzIHRydWUsIGJ1dCBkb27igJl0IHlvdSBjcmVhdGUgYSBEVExT IGNvbm5lY3Rpb24ganVzdCBieSBuZWdvdGlhdGluZyB0aGUga2V5cyB0aGF0IHlvdSBhcmUgZ29p bmcgdG8gdXNlIGZvciBTUlRQPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+KEkgZG8gYWdyZWUgdGhhdCDigJxjb25uZWN0aW9u4oCdIGlzIG1pc2xlYWRpbmcuKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBOb3YgNiwgMjAxNCBhdCA3 OjAyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkhpLDxicj4NCjxicj4NCkFGQUlLLCB5b3UgdXNlIGEgRFRMUyBjb25uZWN0aW9uIChJ IGJlbGlldmUgRFRMUy1TUlRQIHVzZXMgYW5vdGhlciB3b3JkLCB0aG91Z2gpIGFsc28gZm9yIFNS VFAuDQo8YnI+DQo8YnI+DQpIb3dldmVyLCB0aGUgdGV4dCBhbHJlYWR5IGRlc2NyaWJlcyBob3cg dG8gc2VwYXJhdGUgU1JUUCBwYWNrZXRzIGZyb20gRFRMUyBwYWNrZXRzLCBzbyB0aGUgcGllY2Ug b2YgdGV4dCBJIGJyb3VnaHQgdXAgb25seSBhcHBsaWVzIHRvIERUTFMgcGFja2V0cy48YnI+DQo8 YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15 IFdpbmRvd3MgUGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxh IGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5QYXVs IEt5eml2YXQ8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAjjA3L+KAjjExL+KAjjIwMTQgMDA6NDk8L3NwYW4+PGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxh IGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmU6IFtNTVVTSUNdIEJVTkRMRTogTWVhbmluZyBvZiAm cXVvdDt0cmFuc3BvcnRlZCBvbiBEVExTJnF1b3Q7Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T24gMTEvNi8xNCA1OjMzIFBNLCBJw7Fha2kg QmF6IENhc3RpbGxvIHdyb3RlOjxicj4NCiZndDsgMjAxNC0xMS0wNiAyMDo0NCBHTVQmIzQzOzAx OjAwIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0 OyBJIHRoaW5rIGl0IGlzIGNsZWFyIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZXNlIHByb3RvY29s cyBiZWluZyBtdWx0aXBsZXhlZDxicj4NCiZndDsmZ3Q7IGFjcm9zcyBhIHNpbmdsZSBEVExTIGNv bm5lY3Rpb24gaGVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJTUhPIHRoYXQncyBjbGVhciB0b28u IE1heSBiZSBpdCBzaG91bGQgYWxzbyBiZSBjbGVhciB0aGF0IFNSVFAgaXMgbm90PGJyPg0KJmd0 OyBjYXJyaWVkIG9uIHRvcCBvZiBhIERUTFMgY29ubmVjdGlvbiwgYnV0IG9uIHRvcCBvZiBhICZx dW90O2NoYW5uZWwmcXVvdDs8YnI+DQomZ3Q7IGVzdGFibGlzaGVkIHZpYSBhIERUTFMgaGFuZHNo YWtlLjxicj4NCjxicj4NCklJVUMgKGR1YmlvdXMpLCBTUlRQIGlzIGNhcnJpZWQgZGlyZWN0bHkg b24gVURQLCBtdWx0aXBsZXhlZCB3aXRoIERUTFMgPGJyPg0KbWVzc2FnZXMuIFNSVFAgdXNlcyBj ZXJ0YWluIERUTFMgbWVzc2FnZXMgdG8gbmVnb3RpYXRlIHRoZSBrZXlzLCBzbyA8YnI+DQpwZXJo YXBzIHRoZSBrZXktbmVnb3RpYXRpb24gcGFydCBvZiBTUlRQIGNhbiBiZSBjb25zaWRlcmVkIHRv IGJlIHdpdGhpbiA8YnI+DQpzb21lIGFzcGVjdCBvZiBEVExTLiBUaGF0IG1pZ2h0IG5vdCBiZSBw YXJ0IG9mIHRoZSBEVExTICpjb25uZWN0aW9uKiAtIEkgPGJyPg0Kd291bGQgdGhpbmsgdGhhdCBp cyByZXNlcnZlZCBmb3IgdGhlIERUTFMgcGF5bG9hZCBwYWNrZXRzLjxicj4NCjxicj4NCkNsZWFy bHkgdGhlIGxheWVyaW5nIGhlcmUgaXMgdmVyeSB3ZWlyZC48YnI+DQo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYXVsPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4EBC1FESESSMB209erics_-- From nobody Fri Nov 7 06:25:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608051AD03B for ; Fri, 7 Nov 2014 06:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gc6DRLQWG1M for ; Fri, 7 Nov 2014 06:25:01 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B8E1A1C00 for ; Fri, 7 Nov 2014 06:24:57 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-80-545cd6385528 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 93.01.04231.836DC545; Fri, 7 Nov 2014 15:24:56 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.174.1; Fri, 7 Nov 2014 15:24:56 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EED4D110299; Fri, 7 Nov 2014 16:24:55 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 573915F329; Fri, 7 Nov 2014 16:25:09 +0200 (EET) Received: from aris-mbp-2.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E94B05F328; Fri, 7 Nov 2014 16:25:08 +0200 (EET) Message-ID: <545CD60E.70205@ericsson.com> Date: Fri, 7 Nov 2014 16:24:14 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Justin Uberti References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3RtfiWkyIwYluOYuL1x4yWazZOYHF Yvo+G4v9i88zW2ydKmRx7cw/Roupyx+zOLB7nGt4z+4x5fdGVo+ds+6yeyzYVOqxZMlPJo// bwI92p7dYQ9gj+KySUnNySxLLdK3S+DKaHwwkangCV/Fk9UP2RsYn3J3MXJySAiYSHx9foQN whaTuHBvPZDNxSEkcIRRYlHjS2YIZz2jxKVZF5kgnD2MEvevf2OHcNYyShyYuAmsH8y5dl8X xOYV0JT4NeE/I4jNIqAicXjBEzCbTcBWYvWrmywgtqhAskTXy4dMEPWCEidnPgGLiwioSTyc tYsVZAGzwGeg1e+nsYIkhAWMJBa3TYK6aSGzxNWzH9hBEpwCgRIXzxwHK2IWsJCYOf88I4Qt L7H97RxmiO/UJK6e28QMcamqxNV/rxgnMIrOQrJ8FpL2WUjaFzAyr2IULU4tLs5NNzLWSy3K TC4uzs/Ty0st2cQIjLqDW37r7mBc/drxEKMAB6MSD+8G05gQIdbEsuLK3EOM0hwsSuK8i87N CxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWNbL/ueKCvf1/LsnAkLex5SLHXfyav4w8+SS eVFn7y6z+5N/ZeMNnts57/d+ncYjkH9via+pc5Khb+ayxSu2rS7SrBAottjmqdty/61aeOrP iNpWaxPJl5e+bdk0JXK+gPCWudN2mlcX1SQVnd2ufHNx6WOu/Nvnn0yLOOZwr23OFLmMNl2t bCWW4oxEQy3mouJEAFQc+HqbAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yDzU129hmaQ5aw9xBKkzKI5UZKg Cc: Jonathan Lennox , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 14:25:03 -0000 On 06/11/14 22:45, Justin Uberti wrote: > I have been noodling on two proposals here: > > a) merging regular and aggressive nom > -- essentially, Jonathan's suggestion from before: > -- controlling side sends on any Valid pair, even prior to a pair being > selected > -- controlled side can send on any Valid pair (although it could use > receipt of media to align with controlling side) > -- controller confirms selection with use-candidate (same as today), > which ends concludes ICE > -- no ice-options needed (AFAICT) This seems to me something that could potentially go to ICE bis. Do we need here considerations on which one would send Client Hello? Also would be good to hear from folks would this kind of functionality break (with) something? Middle boxes doing rate control? ICE library waiting for ICE to finish before giving out socket to app? OTOH, probably we cant rely on this working 100% anyway, and then we could always fall back to regular nomination. > b) adding a new mode, "continuous" nomination > -- ICE never concludes; controlling side is always able to change media > path dynamically > -- as a corollary, controlling side controls when remote candidates can > be freed > -- new candidates can be trickled at any time > -- controlled side uses either receipt of (secure) media to align with > controlling side, or receipt of new use-candidate checks > -- this mode requires opt-in via ice-options:continuous > > I still need to look at how b) might overlap with MICE, but I'd be happy > to write either of these up or present them in Honolulu. This is slightly more complicated and I'm looking forward to more details and discussion. I saw there was some good text on the Gdoc document, so once that's somewhat stable, posting that to the list or ID tracker would be good for a stable reference. Cheers, Ari From nobody Fri Nov 7 06:42:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAA41A3B9D for ; Fri, 7 Nov 2014 06:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poNmu_l8JJVh for ; Fri, 7 Nov 2014 06:42:24 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id CB84A1A1BA4 for ; Fri, 7 Nov 2014 06:42:19 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 5315423F051A; Fri, 7 Nov 2014 15:42:18 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 7 Nov 2014 15:42:18 +0100 From: "Stach, Thomas" To: Christer Holmberg , Justin Uberti Thread-Topic: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- line with zero port value? Thread-Index: AQHP+frT5N2isU6eFUqH8zBM/XqbipxUZWoAgADYfuA= Date: Fri, 7 Nov 2014 14:42:17 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCBC1@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D4EA6B2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4EA6B2@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E246210MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rMcm5ax2Q9BTWXMZuQ_JQeBAR_o Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- line with zero port value? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 14:42:26 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E246210MCHP04MSXglobal_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable +1 From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Freitag, 7. November 2014 03:47 To: Justin Uberti Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- lin= e with zero port value? Hi Justin, No candidates is what I intend to suggest too. Regards, Christer Sent from my Windows Phone ________________________________ From: Justin Uberti Sent: =FD06/=FD11/=FD2014 21:49 To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- lin= e with zero port value? I don't think you need an ICE candidate for a m=3D line with a zero port va= lue. We already covered something similar for trickle ICE (i.e. the dummy p= orts). On Mon, Oct 27, 2014 at 4:43 AM, Christer Holmberg > wrote: Hi, One question that has been raised by Thomas Stach during the BUNDLE WGLC, i= s regarding ICE candidates and bundle-only m- lines with a zero port value. The current text says that identical ICE candidate values are assigned to b= undle-only m- lines. Now, in the case where a zero port value is assigned to a bundle-only m- li= nes, it means that a candidate with a zero port value is also needed (in or= der to fulfil the ICE rules for default candidates). IF we want to avoid that, a couple of alternatives have been presented: 1) Do not assign ICE candidates to bundle-only m- lines with port zero= . The problem is that the answerer, even if it supports BUNDLE/bundle-only,= doesn=92t know whether the offerer wants to use ICE for those m- lines; or 2) Relax the 5245 rules, so that there doesn=92t need to be a candidat= e matching the m- line port value. Comments? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_F81CEE99482EFE438DAE2A652361EE121E246210MCHP04MSXglobal_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

+1

 <= /p>

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Freitag, 7. November 2014 03:47
To: Justin Uberti
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only= m- line with zero port value?

 

Hi Justin,

No candidates is what I intend to suggest too.

Regards,

Christer

Sent from my Windows Phone

From: Justin Uberti=
Sent: =FD06/=FD11/=FD2014 21:49
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-onl= y m- line with zero port value?

I don't think you need an ICE candidate for a m=3D l= ine with a zero port value. We already covered something similar for trickl= e ICE (i.e. the dummy ports).

 

On Mon, Oct 27, 2014 at 4:43 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

One question that has been raised by Thomas Stach during the BUNDL= E WGLC, is regarding ICE candidates and bundle-only m- lines with a zero po= rt value.

 

The current text says that identical ICE candidate values are assi= gned to bundle-only m- lines.

 

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

 

IF we want to avoid that, a couple of alternatives have been prese= nted:

 

1)      = Do not assign ICE candidates to bundle-only m- lines with port zero. The pr= oblem is that the answerer, even if it supports BUNDLE/bundle-only, doesn= =92t know whether the offerer wants to use ICE for those m- lines; or

2)      = Relax the 5245 rules, so that there doesn=92t need to be a candidate matchi= ng the m- line port value.

 

Comments?

 

Regards,

 

Christer

 

 

 


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

 

--_000_F81CEE99482EFE438DAE2A652361EE121E246210MCHP04MSXglobal_-- From nobody Fri Nov 7 07:03:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9F91A1B9C for ; Fri, 7 Nov 2014 07:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwdY0AOJAcLD for ; Fri, 7 Nov 2014 07:03:52 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274C81A870D for ; Fri, 7 Nov 2014 07:03:50 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-27-545cdf54f6d6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.16.04231.45FDC545; Fri, 7 Nov 2014 16:03:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Fri, 7 Nov 2014 16:03:48 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/gAHOIkwAAnwGgD///LfgIAAL06AgAAEdoCAAFddv4AANnYA//+9vaD//ys68A== Date: Fri, 7 Nov 2014 15:03:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4ECFEA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> <545BFAF9.7010301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4EBC1F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4EBC1F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4ECFEAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rjf0fkyIwe/rXBZbpwpZTF3+mMVi xYYDrA7MHn/ff2DyWLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBnbXxkXPJjOWNHesY21gfHG ZMYuRg4OCQETiWV/q7oYOYFMMYkL99azdTFycQgJHGGU6Lh+hwXCWcwo8f7LD1aQBjYBC4nu f9ogDSICahIPZ+1iBbGZBXwl3v+czg5iCwvYS7Rsm8cIUeMgcejpRDYIO0ti4ZLZYPUsAioS B1cvYgYZyQvUu2UV1KqHLBJ7dl1gAqnhFPCT6H/wGGwmI9Bx30+tYYLYJS5x68l8JoijBSSW 7DnPDGGLSrx8/I8VwlaSWHT7M1R9vsTtMw/B7uEVEJQ4OfMJywRG0VlIRs1CUjYLSdksoPOY BTQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wOg7uOW37g7G1a8dDzEKcDAq8fBuMI0JEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjAxikVPkX3/e9UdTZK/wOsuM6LszF5cJCNtp3bymIVy4eruT7NzV l28dndYd4fBv2lmtQI/YjczCOwozG+4oLXz67fevnEKGSc+mWtstN2VedURjZmvOxNPJTBuz 9hT+Y//rp/9E6Lvs5alTVYwPX3tbuSj58Uqz1zfn6FjvZvZcosYssXfT089KLMUZiYZazEXF iQADm44DnwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/H4QHEfpkOY3sgiIddTmJT61ERO4 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:03:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4ECFEAESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkRUTFMtU1JUUCB0YWxrcyBhYm91dCDigJxhc3NvY2lhdGlvbuKAnSwgYnV0IGl04oCZ cyB0aGUgc2FtZSB0aGluZyBhcyDigJxjb25uZWN0aW9u4oCdLg0KDQpTZWN0aW9uIDMgaW4gUkZD IDU3NjQgc2F5czoNCg0K4oCcRWFjaCBEVExTLVNSVFAgc2Vzc2lvbiBjb250YWlucyBhIHNpbmds ZSBEVExTIGFzc29jaWF0aW9uIChjYWxsZWQgYSAiY29ubmVjdGlvbiIgaW4gVExTIGphcmdvbiks 4oCm4oCdDQoNCihFS1IgY2FuIHByb2JhYmx5IGV4cGxhaW4gd2h5IHRoZXkgY2hvc2UgdG8gdXNl IGRpZmZlcmVudCB0ZXJtaW5vbG9neSkNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpGcm9t OiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENo cmlzdGVyIEhvbG1iZXJnDQpTZW50OiAwNyBOb3ZlbWJlciAyMDE0IDEyOjE2DQpUbzogSnVzdGlu IFViZXJ0aQ0KQ2M6IG1tdXNpY0BpZXRmLm9yZzsgUGF1bCBLeXppdmF0DQpTdWJqZWN0OiBSZTog W01NVVNJQ10gQlVORExFOiBNZWFuaW5nIG9mICJ0cmFuc3BvcnRlZCBvbiBEVExTIj8NCg0KSGks DQoNCj5ObywgdGhlIFNSVFAgcGFja2V0cyBhcmUgc2VudCBvdXRzaWRlIHRoZSBEVExTIGNvbm5l Y3Rpb24uDQoNClRoYXQgaXMgdHJ1ZSwgYnV0IGRvbuKAmXQgeW91IGNyZWF0ZSBhIERUTFMgY29u bmVjdGlvbiBqdXN0IGJ5IG5lZ290aWF0aW5nIHRoZSBrZXlzIHRoYXQgeW91IGFyZSBnb2luZyB0 byB1c2UgZm9yIFNSVFA/DQoNCihJIGRvIGFncmVlIHRoYXQg4oCcY29ubmVjdGlvbuKAnSBpcyBt aXNsZWFkaW5nLikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiBUaHUsIE5vdiA2LCAy MDE0IGF0IDc6MDIgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K SGksDQoNCkFGQUlLLCB5b3UgdXNlIGEgRFRMUyBjb25uZWN0aW9uIChJIGJlbGlldmUgRFRMUy1T UlRQIHVzZXMgYW5vdGhlciB3b3JkLCB0aG91Z2gpIGFsc28gZm9yIFNSVFAuDQoNCkhvd2V2ZXIs IHRoZSB0ZXh0IGFscmVhZHkgZGVzY3JpYmVzIGhvdyB0byBzZXBhcmF0ZSBTUlRQIHBhY2tldHMg ZnJvbSBEVExTIHBhY2tldHMsIHNvIHRoZSBwaWVjZSBvZiB0ZXh0IEkgYnJvdWdodCB1cCBvbmx5 IGFwcGxpZXMgdG8gRFRMUyBwYWNrZXRzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50 IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IFBhdWwgS3l6aXZhdDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KU2VudDog 4oCOMDcv4oCOMTEv4oCOMjAxNCAwMDo0OQ0KVG86IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEJVTkRMRTogTWVhbmluZyBvZiAi dHJhbnNwb3J0ZWQgb24gRFRMUyI/DQpPbiAxMS82LzE0IDU6MzMgUE0sIEnDsWFraSBCYXogQ2Fz dGlsbG8gd3JvdGU6DQo+IDIwMTQtMTEtMDYgMjA6NDQgR01UKzAxOjAwIEp1c3RpbiBVYmVydGkg PGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj46DQo+PiBJIHRo aW5rIGl0IGlzIGNsZWFyIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZXNlIHByb3RvY29scyBiZWlu ZyBtdWx0aXBsZXhlZA0KPj4gYWNyb3NzIGEgc2luZ2xlIERUTFMgY29ubmVjdGlvbiBoZXJlLg0K Pg0KPiBJTUhPIHRoYXQncyBjbGVhciB0b28uIE1heSBiZSBpdCBzaG91bGQgYWxzbyBiZSBjbGVh ciB0aGF0IFNSVFAgaXMgbm90DQo+IGNhcnJpZWQgb24gdG9wIG9mIGEgRFRMUyBjb25uZWN0aW9u LCBidXQgb24gdG9wIG9mIGEgImNoYW5uZWwiDQo+IGVzdGFibGlzaGVkIHZpYSBhIERUTFMgaGFu ZHNoYWtlLg0KDQpJSVVDIChkdWJpb3VzKSwgU1JUUCBpcyBjYXJyaWVkIGRpcmVjdGx5IG9uIFVE UCwgbXVsdGlwbGV4ZWQgd2l0aCBEVExTDQptZXNzYWdlcy4gU1JUUCB1c2VzIGNlcnRhaW4gRFRM UyBtZXNzYWdlcyB0byBuZWdvdGlhdGUgdGhlIGtleXMsIHNvDQpwZXJoYXBzIHRoZSBrZXktbmVn b3RpYXRpb24gcGFydCBvZiBTUlRQIGNhbiBiZSBjb25zaWRlcmVkIHRvIGJlIHdpdGhpbg0Kc29t ZSBhc3BlY3Qgb2YgRFRMUy4gVGhhdCBtaWdodCBub3QgYmUgcGFydCBvZiB0aGUgRFRMUyAqY29u bmVjdGlvbiogLSBJDQp3b3VsZCB0aGluayB0aGF0IGlzIHJlc2VydmVkIGZvciB0aGUgRFRMUyBw YXlsb2FkIHBhY2tldHMuDQoNCkNsZWFybHkgdGhlIGxheWVyaW5nIGhlcmUgaXMgdmVyeSB3ZWly ZC4NCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIFBhdWwNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNp Y0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxt YWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4ECFEAESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RFRMUy1TUlRQIHRhbGtzIGFi b3V0IOKAnGFzc29jaWF0aW9u4oCdLCBidXQgaXTigJlzIHRoZSBzYW1lIHRoaW5nIGFzIOKAnGNv bm5lY3Rpb27igJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZWN0 aW9uIDMgaW4gUkZDIDU3NjQgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKAnEVhY2ggRFRMUy1TUlRQIHNl c3Npb24gY29udGFpbnMgYSBzaW5nbGUgRFRMUyBhc3NvY2lhdGlvbiAoY2FsbGVkIGEgJnF1b3Q7 Y29ubmVjdGlvbiZxdW90OyBpbiBUTFMgamFyZ29uKSzigKbigJ08bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4oRUtS IGNhbiBwcm9iYWJseSBleHBsYWluIHdoeSB0aGV5IGNob3NlIHRvIHVzZSBkaWZmZXJlbnQgdGVy bWlub2xvZ3kpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxi PlNlbnQ6PC9iPiAwNyBOb3ZlbWJlciAyMDE0IDEyOjE2PGJyPg0KPGI+VG86PC9iPiBKdXN0aW4g VWJlcnRpPGJyPg0KPGI+Q2M6PC9iPiBtbXVzaWNAaWV0Zi5vcmc7IFBhdWwgS3l6aXZhdDxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gQlVORExFOiBNZWFuaW5nIG9mICZxdW90O3Ry YW5zcG9ydGVkIG9uIERUTFMmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPk5vLCB0aGUgU1JUUCBwYWNr ZXRzIGFyZSBzZW50IG91dHNpZGUgdGhlIERUTFMgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGF0IGlzIHRydWUsIGJ1dCBkb27igJl0IHlvdSBj cmVhdGUgYSBEVExTIGNvbm5lY3Rpb24ganVzdCBieSBuZWdvdGlhdGluZyB0aGUga2V5cyB0aGF0 IHlvdSBhcmUgZ29pbmcgdG8gdXNlIGZvciBTUlRQPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+KEkgZG8gYWdyZWUgdGhhdCDigJxjb25uZWN0aW9u4oCdIGlzIG1p c2xlYWRpbmcuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBOb3Yg NiwgMjAxNCBhdCA3OjAyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5I aSw8YnI+DQo8YnI+DQpBRkFJSywgeW91IHVzZSBhIERUTFMgY29ubmVjdGlvbiAoSSBiZWxpZXZl IERUTFMtU1JUUCB1c2VzIGFub3RoZXIgd29yZCwgdGhvdWdoKSBhbHNvIGZvciBTUlRQLg0KPGJy Pg0KPGJyPg0KSG93ZXZlciwgdGhlIHRleHQgYWxyZWFkeSBkZXNjcmliZXMgaG93IHRvIHNlcGFy YXRlIFNSVFAgcGFja2V0cyBmcm9tIERUTFMgcGFja2V0cywgc28gdGhlIHBpZWNlIG9mIHRleHQg SSBicm91Z2h0IHVwIG9ubHkgYXBwbGllcyB0byBEVExTIHBhY2tldHMuPGJyPg0KPGJyPg0KUmVn YXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dz IFBob25lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl ciI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJt YWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+UGF1bCBLeXppdmF0 PC9hPjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlbnQ6IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj7igI4wNy/igI4xMS/igI4yMDE0IDAwOjQ5PC9zcGFuPjxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJt YWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9h Pjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YmplY3Q6IDwvc3Bhbj4NCjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlJlOiBbTU1VU0lDXSBCVU5ETEU6IE1lYW5pbmcgb2YgJnF1b3Q7dHJh bnNwb3J0ZWQgb24gRFRMUyZxdW90Oz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIDExLzYvMTQgNTozMyBQTSwgScOxYWtpIEJheiBDYXN0 aWxsbyB3cm90ZTo8YnI+DQomZ3Q7IDIwMTQtMTEtMDYgMjA6NDQgR01UJiM0MzswMTowMCBKdXN0 aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDs6PGJyPg0KJmd0OyZndDsgSSB0aGlu ayBpdCBpcyBjbGVhciB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGVzZSBwcm90b2NvbHMgYmVpbmcg bXVsdGlwbGV4ZWQ8YnI+DQomZ3Q7Jmd0OyBhY3Jvc3MgYSBzaW5nbGUgRFRMUyBjb25uZWN0aW9u IGhlcmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSU1ITyB0aGF0J3MgY2xlYXIgdG9vLiBNYXkgYmUg aXQgc2hvdWxkIGFsc28gYmUgY2xlYXIgdGhhdCBTUlRQIGlzIG5vdDxicj4NCiZndDsgY2Fycmll ZCBvbiB0b3Agb2YgYSBEVExTIGNvbm5lY3Rpb24sIGJ1dCBvbiB0b3Agb2YgYSAmcXVvdDtjaGFu bmVsJnF1b3Q7PGJyPg0KJmd0OyBlc3RhYmxpc2hlZCB2aWEgYSBEVExTIGhhbmRzaGFrZS48YnI+ DQo8YnI+DQpJSVVDIChkdWJpb3VzKSwgU1JUUCBpcyBjYXJyaWVkIGRpcmVjdGx5IG9uIFVEUCwg bXVsdGlwbGV4ZWQgd2l0aCBEVExTIDxicj4NCm1lc3NhZ2VzLiBTUlRQIHVzZXMgY2VydGFpbiBE VExTIG1lc3NhZ2VzIHRvIG5lZ290aWF0ZSB0aGUga2V5cywgc28gPGJyPg0KcGVyaGFwcyB0aGUg a2V5LW5lZ290aWF0aW9uIHBhcnQgb2YgU1JUUCBjYW4gYmUgY29uc2lkZXJlZCB0byBiZSB3aXRo aW4gPGJyPg0Kc29tZSBhc3BlY3Qgb2YgRFRMUy4gVGhhdCBtaWdodCBub3QgYmUgcGFydCBvZiB0 aGUgRFRMUyAqY29ubmVjdGlvbiogLSBJIDxicj4NCndvdWxkIHRoaW5rIHRoYXQgaXMgcmVzZXJ2 ZWQgZm9yIHRoZSBEVExTIHBheWxvYWQgcGFja2V0cy48YnI+DQo8YnI+DQpDbGVhcmx5IHRoZSBs YXllcmluZyBoZXJlIGlzIHZlcnkgd2VpcmQuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGF1bDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVz aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D4ECFEAESESSMB209erics_-- From nobody Fri Nov 7 14:32:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120121A1B61 for ; Fri, 7 Nov 2014 14:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxeOgzYAGzCI for ; Fri, 7 Nov 2014 14:32:25 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAE31A1B3B for ; Fri, 7 Nov 2014 14:32:24 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id ij19so2252873vcb.24 for ; Fri, 07 Nov 2014 14:32:24 -0800 (PST) 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=yk94M3jaYdTco+lPq7cpESorFeGYA9nkrDaBKCYaTD0=; b=X2s4praGnEJnqhOz8GGFMhK9D+/gcGjFik3QpRHBDhOQ4pC8jvMzIGRyF4b3u/JRex wRf0+CHuEk8SBIhonmQPIacADjfAVzhnFse6/pnGK3ULcOpCsRsNPMtTybrvNhQBzxzr B96XCYf69XJQrRKfj10Cym5j3VgcFT313BLNmIh2s1v3QlYmJoFFi7qvoLfI/Rgg0+2A cI9eEOpbAhWEZEpx6yOi1XQ8Kwkc+Aegn+yjHGWml8KMxF9so3CzzenIu7guzyTgjlNV nETzPvvyxKANFkAm5cgu9ohMLCLHDP6OVjUakHKIUox4IEn4XppThzIvUR0hBDt/SQju XXgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yk94M3jaYdTco+lPq7cpESorFeGYA9nkrDaBKCYaTD0=; b=ipsROFXNi00x9bw4rub272GypxrdIKI/3ZRh+YLMLisjJ7QtbD/9zdQW9z+hFJCrbF 3LHsVO2s7PFqgS8IVZ4YxCJZI1fXoaemJnrBCeoiEescC+1kukLnE5Y2+upRrtMcxJ4b IeHDzxvkehLoW/lvLCu3+4ufGthaoZMPW4XFonG47F2yPi/LXHNGoBmzg1WJWoUxoNnl Xl2Xkykk3+pTKguHiCXIRRdHh6cJushAfk2az8EtiLF/bSuLC6ZsDlXYyo511cTFfw9j g01YwBpHaDkkl0WlP87jYG2dJmpPDQLCw15aFCCFmkSXotJUMh6g6q4ncufbTVGKAoTt 9+Gw== X-Gm-Message-State: ALoCoQmDtCW7/yRqKYAP4OtUKoPyXG4Kkg1EN/wQ+TT0hUH71AHBHuytF82cZkk9/HnYRpyyL7DI X-Received: by 10.220.124.4 with SMTP id s4mr6890860vcr.38.1415399543878; Fri, 07 Nov 2014 14:32:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Fri, 7 Nov 2014 14:32:03 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4EBC1F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> <545BFAF9.7010301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4EBC1F@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 7 Nov 2014 14:32:03 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0115fe3a07581905074c63cc Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/NRz1OdeWVBNazHksDa9U7NPcCiA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:32:27 -0000 --089e0115fe3a07581905074c63cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In this context, the key exchange mechanism is immaterial. The key point is that you don't need to demultiplex SRTP packets from other stuff arriving on the DTLS connection, because those packets aren't sent on the DTLS connection (and therefore the demux is already covered by 5764). On Fri, Nov 7, 2014 at 2:16 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >No, the SRTP packets are sent outside the DTLS connection. > > > > That is true, but don=E2=80=99t you create a DTLS connection just by nego= tiating > the keys that you are going to use for SRTP? > > > > (I do agree that =E2=80=9Cconnection=E2=80=9D is misleading.) > > > > Regards, > > > > Christer > > > > > > On Thu, Nov 6, 2014 at 7:02 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > AFAIK, you use a DTLS connection (I believe DTLS-SRTP uses another word, > though) also for SRTP. > > However, the text already describes how to separate SRTP packets from DTL= S > packets, so the piece of text I brought up only applies to DTLS packets. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > > *From: *Paul Kyzivat > *Sent: *=E2=80=8E07/=E2=80=8E11/=E2=80=8E2014 00:49 > *To: *mmusic@ietf.org > *Subject: *Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? > > On 11/6/14 5:33 PM, I=C3=B1aki Baz Castillo wrote: > > 2014-11-06 20:44 GMT+01:00 Justin Uberti : > >> I think it is clear we are talking about these protocols being > multiplexed > >> across a single DTLS connection here. > > > > IMHO that's clear too. May be it should also be clear that SRTP is not > > carried on top of a DTLS connection, but on top of a "channel" > > established via a DTLS handshake. > > IIUC (dubious), SRTP is carried directly on UDP, multiplexed with DTLS > messages. SRTP uses certain DTLS messages to negotiate the keys, so > perhaps the key-negotiation part of SRTP can be considered to be within > some aspect of DTLS. That might not be part of the DTLS *connection* - I > would think that is reserved for the DTLS payload packets. > > Clearly the layering here is very weird. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --089e0115fe3a07581905074c63cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In this context, the key exchange mechanism is immaterial.= The key point is that you don't need to demultiplex SRTP packets from = other stuff arriving on the DTLS connection, because those packets aren'= ;t sent on the DTLS connection (and therefore the demux is already covered = by 5764).

On= Fri, Nov 7, 2014 at 2:16 AM, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:

Hi,

=C2=A0

>No, the SRT= P packets are sent outside the DTLS connection.

=C2=A0

That is true, but don=E2=80=99t you c= reate a DTLS connection just by negotiating the keys that you are going to = use for SRTP?

=C2=A0

(I do agree that =E2=80=9Cconnection= =E2=80=9D is misleading.)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

On Thu, Nov 6, 2014 at 7:02 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

AFAIK, you use a DTLS connection (I believe DTLS-SRTP uses another word, th= ough) also for SRTP.

However, the text already describes how to separate SRTP packets from DTLS = packets, so the piece of text I brought up only applies to DTLS packets.
Regards,

Christer

Sent from my Windows Phone

From: Paul= Kyzivat
Sent: =E2=80=8E07/=E2=80=8E11/=E2=80=8E2014 00:49 To: mm= usic@ietf.org
Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"?

On 11/6/14 5:33 PM,= I=C3=B1aki Baz Castillo wrote:
> 2014-11-06 20:44 GMT+01:00 Justin Uberti <juberti@google.com>:
>> I think it is clear we are talking about these protocols being mul= tiplexed
>> across a single DTLS connection here.
>
> IMHO that's clear too. May be it should also be clear that SRTP is= not
> carried on top of a DTLS connection, but on top of a "channel&quo= t;
> established via a DTLS handshake.

IIUC (dubious), SRTP is carried directly on UDP, multiplexed with DTLS
messages. SRTP uses certain DTLS messages to negotiate the keys, so
perhaps the key-negotiation part of SRTP can be considered to be within some aspect of DTLS. That might not be part of the DTLS *connection* - I would think that is reserved for the DTLS payload packets.

Clearly the layering here is very weird.

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

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


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

=C2=A0


--089e0115fe3a07581905074c63cc-- From nobody Fri Nov 7 14:41:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59AA1A1B61 for ; Fri, 7 Nov 2014 14:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYTff7aLQEmx for ; Fri, 7 Nov 2014 14:41:13 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042401A1B3B for ; Fri, 7 Nov 2014 14:41:13 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so4754397wgh.1 for ; Fri, 07 Nov 2014 14:41:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JKLcUfReFyibJhTxnC+3kvhk7tUpkkOOk2xtkicMPWw=; b=L5YR7dlpEpPYVbX4Wa9yddtxf0CvzWg3FuMzfMHRxuNBgonCQU0DDCOj4TL8A6Aeyu rc6FRyZfg35WwJTROOux/hrxt7keHEqFb4NOOwdxeKcZNGm5lbmO/wmFU5WyZvn1nurL y11YYlepn0JYQvlqL4mvh/rKg17m0SXnTj7Pbyucu2yPuxxzAg3IGUd3m3QLFQrJWFrX 5BtezGZXypwrazDAKBTHjWsvmVGKUQ+XLH1xw+Mxp7xOSMCmH2daRwcimtagvvKY5G9F FRCQrpXXxTMdTnCnT/G2W86aMQzzwmP9zl0xEG8hIW801zoDNLO6FK0cYGHr8G0mwQ63 qb+w== X-Gm-Message-State: ALoCoQn4pE1YlSTf3T7hWB0x76LCFSOpWvDtdeTA2iak+SP1mw4Z7wUDrqGAm3xWYFwtGVTQ3+QO X-Received: by 10.180.99.163 with SMTP id er3mr9109472wib.18.1415400071798; Fri, 07 Nov 2014 14:41:11 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id d14sm13408502wjz.26.2014.11.07.14.41.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 14:41:10 -0800 (PST) Message-ID: <545D4A84.1000608@jitsi.org> Date: Fri, 07 Nov 2014 23:41:08 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti , Martin Thomson References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gRUcNqghuMjTMM8IOD716rvjWsQ Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:41:15 -0000 Hey all, In the context of the ongoing discussion on two potential ICE improvements, I wanted to spin off this thread on the idea of continuous nomination. So first of all, as I already mentioned in Toronto, I am very much in favour of a mechanism that would allow ICE processing to yield more than a single nominated pair. Back then the discussion was about MPRTP but there would likely be other use cases as well. In that context, it seems perfectly valid to me that nomination among all validated pairs can occur multiple times within a session. Again, I find this to be a very valid and useful feature. I am however bothered by the "ICE never ends" suggestions made by the document below and more specifically by the fact that candidates may continue to be trickled forever. I think that's both unnecessary and a problem. It is a problem because a) being able to know when the remote agent is done trickling is one of the very reasons we started the work on trickle ICE. This allows to quickly and deterministically detect and declare failure when it occurs. Not having this would require implementations to use magic timers of the sort: "Surely if I couldn't connect in .. say 20 seconds ... then the situation must be hopeless ... I think". b) being able to continuously trickle new candidates forever and ever means that they would have to be paired with all of the peer's *initial* candidates. This means that ICE agents would have to maintain all gathered candidates even when they are not working for them. More importantly however, the whole concept is likely unnecessary because an ICE restart only sounds scary, and it doesn't actually need to be ;). A restart is non-disruptive as media can keep flowing while we are doing ICE processing. 5245 already supports pair reuse and we can easily port that concept to multipath ICE. The one thing that we might be missing today is the syntax to allow for a restart without using offer/answer. This would be trivial to resolve: we just need to allow trickling a restart command. Sending your ufrag and pwd in a trickle update should do the job. To put that into perspective, let's look at the following use cases: I. You have used the new multipath ICE and you have successfully discovered a couple of working routes: one going through your wi-fi interface and another one going through 4G. During your session, you move closer to your Wi-Fi access point so you detect that RTT and packet loss start looking better on your Wi-Fi interface. You decide to switch from 4G to Wi-Fi. *No ICE restart* would be necessary here because no new paths would need to negotiated. This would be a native feature of the new multipath ICE. II. You start on Wi-Fi in the presence of a 4G interface that you keep for backup. Multipath ICE comes up with pairs over both your interfaces. I don't believe this requires an ICE restart either. You just switch between pre-existing path and one of them expires as pointed out in Justin's document below III. You setup a session at a point of time where 4G is your only working interface. Your Wi-Fi interface then comes up and you want to include it in the game. Here's what you do: a) You gather host, srflx and relay candidates for the new interface. b) You gather candidates on the old interface that haven't been valid before but that are worth trying again (this is non-essential) d) you then trickle a new ufrag and pwd to trigger a restart. b) you batch trickle all currently working candidates that you'd wish to preserve (you can omit any candidates you no longer wish to use, for whatever reason). c) you trickle the newly gathered candidates. The remote party, your peer, would then do the following a) Gather all candidates that didn't work before but that deserve a second chance. This time *this is essential*. SRFLX candiates on your peer might not have worked with your 4G connection but they have every chance of working this time. There are a number of other scenarios where candidates would be worth retrying. b) Your peer would then trickle back to you all the working candidates it wishes to preserve (as long as they are still valid) c) It trickles all candidates it gathered for the occasion, that it wishes to retry. Connectivity checks then proceed as usual. It might be worth paying special attention to the in-use candidates. Implementations might want to either confirm that data is still flowing there, or start the checks with them. This would determine how urgently ICE processing needs to yield results and it may imply changes in nomination strategies. Thoughts? Emil On 7.11.14, 0:44, Justin Uberti wrote: > Agreed. > > I wrote up a slightly more fleshed-out proposal at > https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit > > On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson > wrote: > > On 6 November 2014 13:47, Justin Uberti > wrote: > > I looked into how MICE works; I think that continuous nomination might be > > able to effectively support that use case, as well as the case that Brandon > > was interested in, namely picking the route that uses the best set of TURN > > servers. > > > I've always believe that continuous ICE operation was the only way to > ensure proper reliability. Multipath or otherwise. You just need to > work out when it is safe to completely stop on any given pair, > assuming that you don't want to be testing the complete mesh all the > time. But you also might want multiple paths available, or maybe > backup paths. > > -- https://jitsi.org From nobody Fri Nov 7 16:35:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632851A0032 for ; Fri, 7 Nov 2014 16:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.795 X-Spam-Level: X-Spam-Status: No, score=-14.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly70p7F2mAhd for ; Fri, 7 Nov 2014 16:35:35 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2FB1A000E for ; Fri, 7 Nov 2014 16:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6677; q=dns/txt; s=iport; t=1415406936; x=1416616536; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QAJJ+Jp27sAyFG0vphaQa7RlGoKEcYRX6EW+XvgWS0k=; b=fWNiVISuofdwFX71dn65XULRr0YVVn4kiGpmebPxfIa/o0m2xj4t0TOU Ibrn5HGc4lE1lAAnYzkrOn0aBDu3oLRspbJZ5Qga8aMnmS4XTmmpMpngs Vhnr1sQfZtE9OwEabO/umW1r81A/7ZhVduV/PIy5Urs8sP4NEBT5EeaM+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAE9kXVStJV2b/2dsb2JhbABWBYMOVFnLX4dNAoEaFgEBAQEBfYQCAQEBAwE6PwULCw4KJwchJREGE4gsAwkJDchADYZZAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKdYNigU8qDjMHgy2BHgWEajMChl+KfYRKQ4ISgTKNeEKCZ4QJhBocL4EIJIEfAQEB X-IronPort-AV: E=Sophos;i="5.07,336,1413244800"; d="scan'208";a="370431319" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 08 Nov 2014 00:35:35 +0000 Received: from sjc-vpn1-815.cisco.com (sjc-vpn1-815.cisco.com [10.21.99.47]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sA80ZT00031358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Nov 2014 00:35:30 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <545D4A84.1000608@jitsi.org> Date: Fri, 7 Nov 2014 16:35:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/guHG67zNcBQszc2mpKzUdihGZBI Cc: Jonathan Lennox , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 00:35:37 -0000 On Nov 7, 2014, at 2:41 PM, Emil Ivov wrote: > Hey all, >=20 > In the context of the ongoing discussion on two potential ICE = improvements, I wanted to spin off this thread on the idea of continuous = nomination. >=20 > So first of all, as I already mentioned in Toronto, I am very much in = favour of a mechanism that would allow ICE processing to yield more than = a single nominated pair. Back then the discussion was about MPRTP but = there would likely be other use cases as well. >=20 > In that context, it seems perfectly valid to me that nomination among = all validated pairs can occur multiple times within a session. Again, I = find this to be a very valid and useful feature. >=20 > I am however bothered by the "ICE never ends" suggestions made by the = document below and more specifically by the fact that candidates may = continue to be trickled forever. I think that's both unnecessary and a = problem. >=20 > It is a problem because >=20 > a) being able to know when the remote agent is done trickling is one = of the very reasons we started the work on trickle ICE. This allows to = quickly and deterministically detect and declare failure when it occurs. = Not having this would require implementations to use magic timers of the = sort: "Surely if I couldn't connect in .. say 20 seconds ... then the = situation must be hopeless ... I think". >=20 > b) being able to continuously trickle new candidates forever and ever = means that they would have to be paired with all of the peer's *initial* = candidates. This means that ICE agents would have to maintain all = gathered candidates even when they are not working for them. >=20 > More importantly however, the whole concept is likely unnecessary = because an ICE restart only sounds scary, and it doesn't actually need = to be ;). >=20 > A restart is non-disruptive as media can keep flowing while we are = doing ICE processing. >=20 > 5245 already supports pair reuse and we can easily port that concept = to multipath ICE. >=20 > The one thing that we might be missing today is the syntax to allow = for a restart without using offer/answer. For MICE and some other use cases, I agree that need to signal (in SDP) = is the 'scary' part of an ICE restart. > This would be trivial to resolve: we just need to allow trickling a = restart command. Sending your ufrag and pwd in a trickle update should = do the job. That is a nice approach -- move the 'ICE restart' signaling to an = (existing, working) media path. >=20 > To put that into perspective, let's look at the following use cases: >=20 > I. You have used the new multipath ICE and you have successfully = discovered a couple of working routes: one going through your wi-fi = interface and another one going through 4G. During your session, you = move closer to your Wi-Fi access point so you detect that RTT and packet = loss start looking better on your Wi-Fi interface. >=20 > You decide to switch from 4G to Wi-Fi. >=20 > *No ICE restart* would be necessary here because no new paths would = need to negotiated. This would be a native feature of the new multipath = ICE. >=20 > II. You start on Wi-Fi in the presence of a 4G interface that you keep = for backup. Multipath ICE comes up with pairs over both your interfaces. = I don't believe this requires an ICE restart either. You just switch = between pre-existing path and one of them expires as pointed out in = Justin's document below >=20 > III. You setup a session at a point of time where 4G is your only = working interface. Your Wi-Fi interface then comes up and you want to = include it in the game. Here's what you do: >=20 > a) You gather host, srflx and relay candidates for the new interface. > b) You gather candidates on the old interface that haven't been valid = before but that are worth trying again (this is non-essential) >=20 > d) you then trickle a new ufrag and pwd to trigger a restart. If that trickling happens over the SIP/WebRTC/XMPP signaling channel, = MICE would prefer not requiring that SDP signaling step or to at least = allow it to be done later. -d > b) you batch trickle all currently working candidates that you'd wish = to preserve (you can omit any candidates you no longer wish to use, for = whatever reason). > c) you trickle the newly gathered candidates. >=20 > The remote party, your peer, would then do the following >=20 > a) Gather all candidates that didn't work before but that deserve a = second chance. This time *this is essential*. SRFLX candiates on your = peer might not have worked with your 4G connection but they have every = chance of working this time. There are a number of other scenarios where = candidates would be worth retrying. >=20 > b) Your peer would then trickle back to you all the working candidates = it wishes to preserve (as long as they are still valid) > c) It trickles all candidates it gathered for the occasion, that it = wishes to retry. >=20 > Connectivity checks then proceed as usual. It might be worth paying = special attention to the in-use candidates. Implementations might want = to either confirm that data is still flowing there, or start the checks = with them. This would determine how urgently ICE processing needs to = yield results and it may imply changes in nomination strategies. >=20 > Thoughts? >=20 > Emil >=20 >=20 > On 7.11.14, 0:44, Justin Uberti wrote: >> Agreed. >>=20 >> I wrote up a slightly more fleshed-out proposal at >> = https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8= bk-Xw/edit >>=20 >> On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson = > > wrote: >>=20 >> On 6 November 2014 13:47, Justin Uberti > > wrote: >> > I looked into how MICE works; I think that continuous nomination = might be >> > able to effectively support that use case, as well as the case = that Brandon >> > was interested in, namely picking the route that uses the best = set of TURN >> > servers. >>=20 >>=20 >> I've always believe that continuous ICE operation was the only way = to >> ensure proper reliability. Multipath or otherwise. You just need = to >> work out when it is safe to completely stop on any given pair, >> assuming that you don't want to be testing the complete mesh all = the >> time. But you also might want multiple paths available, or maybe >> backup paths. >>=20 >>=20 >=20 > --=20 > https://jitsi.org From nobody Fri Nov 7 17:18:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89CA1A00CD for ; Fri, 7 Nov 2014 17:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KymsQvJHfW5T for ; Fri, 7 Nov 2014 17:18:39 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1814A1A00C0 for ; Fri, 7 Nov 2014 17:18:39 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so5995801wiv.1 for ; Fri, 07 Nov 2014 17:18:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BHjP5f6qyzWNJr1vf1dUUbeu2TO5tzcVpP1Rmsprlns=; b=kseh2OhB/Z5VtbTflHLbLEq3QpL8X8oUVkjIMw7lcOT5q7qJp8yIFCq83qwlhDOOSf KAUUqsyTBz+ZI2mUN0yIZ8msdq9Y4C8p9zBYSS3FMgNGH8j0nSSLLCT+H2bMqQ/EQjpd tUxVN+SgYmizzQ3oghCOs03xEi5hGGhirKC0ExOzlnXkqNBsLZNTe2EwcmDgHzSfMI5O w+Bk7OHApjDnPgybBMowq0+iyrRmmVuyLNtitVb2geRA1+HYAaiHJNMzG9+GoLPWmEF6 WWkn0e3Wx8tK/x/8JTJtjdQ1uD8VJYUkmHVIR0+dKtB9giXFcEKMZcKMFehimS7ncEwS oVMg== X-Gm-Message-State: ALoCoQk/DhxRCCc2o7ZVRko5wYMdF8yY/vmXmhWcnwUUUuFngcv+GffxspxasO2cuAzptnko7LFP X-Received: by 10.180.82.34 with SMTP id f2mr9713771wiy.69.1415409517717; Fri, 07 Nov 2014 17:18:37 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id wl1sm13770031wjb.4.2014.11.07.17.18.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 17:18:36 -0800 (PST) Message-ID: <545D6F6A.3020003@jitsi.org> Date: Sat, 08 Nov 2014 02:18:34 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> In-Reply-To: <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eWAcF75g03aqpCcdfS2Qo-_1adE Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 01:18:41 -0000 On 8.11.14, 1:35, 🔓Dan Wing wrote: > > On Nov 7, 2014, at 2:41 PM, Emil Ivov wrote: > >> Hey all, >> >> In the context of the ongoing discussion on two potential ICE >> improvements, I wanted to spin off this thread on the idea of >> continuous nomination. >> >> So first of all, as I already mentioned in Toronto, I am very much >> in favour of a mechanism that would allow ICE processing to yield >> more than a single nominated pair. Back then the discussion was >> about MPRTP but there would likely be other use cases as well. >> >> In that context, it seems perfectly valid to me that nomination >> among all validated pairs can occur multiple times within a >> session. Again, I find this to be a very valid and useful feature. >> >> I am however bothered by the "ICE never ends" suggestions made by >> the document below and more specifically by the fact that >> candidates may continue to be trickled forever. I think that's both >> unnecessary and a problem. >> >> It is a problem because >> >> a) being able to know when the remote agent is done trickling is >> one of the very reasons we started the work on trickle ICE. This >> allows to quickly and deterministically detect and declare failure >> when it occurs. Not having this would require implementations to >> use magic timers of the sort: "Surely if I couldn't connect in .. >> say 20 seconds ... then the situation must be hopeless ... I >> think". >> >> b) being able to continuously trickle new candidates forever and >> ever means that they would have to be paired with all of the peer's >> *initial* candidates. This means that ICE agents would have to >> maintain all gathered candidates even when they are not working for >> them. >> >> More importantly however, the whole concept is likely unnecessary >> because an ICE restart only sounds scary, and it doesn't actually >> need to be ;). >> >> A restart is non-disruptive as media can keep flowing while we are >> doing ICE processing. >> >> 5245 already supports pair reuse and we can easily port that >> concept to multipath ICE. >> >> The one thing that we might be missing today is the syntax to allow >> for a restart without using offer/answer. > > For MICE and some other use cases, I agree that need to signal (in > SDP) is the 'scary' part of an ICE restart. > >> This would be trivial to resolve: we just need to allow trickling a >> restart command. Sending your ufrag and pwd in a trickle update >> should do the job. > > That is a nice approach -- move the 'ICE restart' signaling to an > (existing, working) media path. I was actually thinking of the signalling path. So for SIP this would be a SIP INFO request with the ufrag/pwd as the sole content. A couple of a= lines would do it for WebRTC. I am slightly uncomfortable about doing it on the media path because it requires you to make the assumption that one of your media paths is certain to survive any sort of mobility event. Even if you keep your TURN connection open for that purpose, how do you know that your new location wouldn't be one where TURN-TCP is the only way to get out of the local network? Or what if you don't even have a TURN server? You signalling channel would be a safer bet, but more importantly, you'd likely want to tear down your call if it didn't. >> To put that into perspective, let's look at the following use >> cases: >> >> I. You have used the new multipath ICE and you have successfully >> discovered a couple of working routes: one going through your wi-fi >> interface and another one going through 4G. During your session, >> you move closer to your Wi-Fi access point so you detect that RTT >> and packet loss start looking better on your Wi-Fi interface. >> >> You decide to switch from 4G to Wi-Fi. >> >> *No ICE restart* would be necessary here because no new paths would >> need to negotiated. This would be a native feature of the new >> multipath ICE. >> >> II. You start on Wi-Fi in the presence of a 4G interface that you >> keep for backup. Multipath ICE comes up with pairs over both your >> interfaces. I don't believe this requires an ICE restart either. >> You just switch between pre-existing path and one of them expires >> as pointed out in Justin's document below >> >> III. You setup a session at a point of time where 4G is your only >> working interface. Your Wi-Fi interface then comes up and you want >> to include it in the game. Here's what you do: >> >> a) You gather host, srflx and relay candidates for the new >> interface. b) You gather candidates on the old interface that >> haven't been valid before but that are worth trying again (this is >> non-essential) >> >> d) you then trickle a new ufrag and pwd to trigger a restart. > > If that trickling happens over the SIP/WebRTC/XMPP signaling channel, > MICE would prefer not requiring that SDP signaling step or to at > least allow it to be done later. Well, if you had multipath ICE, you would be able to switch your media over to TURN (this wouldn't require any signalling) if that still works and then do the non-disruptive restart after that to discover other paths. Would this work? Emil > > -d > > >> b) you batch trickle all currently working candidates that you'd >> wish to preserve (you can omit any candidates you no longer wish to >> use, for whatever reason). c) you trickle the newly gathered >> candidates. >> >> The remote party, your peer, would then do the following >> >> a) Gather all candidates that didn't work before but that deserve a >> second chance. This time *this is essential*. SRFLX candiates on >> your peer might not have worked with your 4G connection but they >> have every chance of working this time. There are a number of other >> scenarios where candidates would be worth retrying. >> >> b) Your peer would then trickle back to you all the working >> candidates it wishes to preserve (as long as they are still valid) >> c) It trickles all candidates it gathered for the occasion, that it >> wishes to retry. >> >> Connectivity checks then proceed as usual. It might be worth paying >> special attention to the in-use candidates. Implementations might >> want to either confirm that data is still flowing there, or start >> the checks with them. This would determine how urgently ICE >> processing needs to yield results and it may imply changes in >> nomination strategies. >> >> Thoughts? >> >> Emil >> >> >> On 7.11.14, 0:44, Justin Uberti wrote: >>> Agreed. >>> >>> I wrote up a slightly more fleshed-out proposal at >>> https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit >>> >>> >>> On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson >> > wrote: >>> >>> On 6 November 2014 13:47, Justin Uberti >> > wrote: >>>> I looked into how MICE works; I think that continuous >>>> nomination might be able to effectively support that use case, >>>> as well as the case that Brandon was interested in, namely >>>> picking the route that uses the best set of TURN servers. >>> >>> >>> I've always believe that continuous ICE operation was the only >>> way to ensure proper reliability. Multipath or otherwise. You >>> just need to work out when it is safe to completely stop on any >>> given pair, assuming that you don't want to be testing the >>> complete mesh all the time. But you also might want multiple >>> paths available, or maybe backup paths. >>> >>> >> >> -- https://jitsi.org > > -- https://jitsi.org From nobody Fri Nov 7 18:03:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370721A00FB for ; Fri, 7 Nov 2014 18:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKKafOB23c9K for ; Fri, 7 Nov 2014 18:03:45 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B901A00FD for ; Fri, 7 Nov 2014 18:03:45 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so2404459vcb.5 for ; Fri, 07 Nov 2014 18:03:44 -0800 (PST) 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=jigy4i+n2GLBCPfs+CvR9lgJg9G7OSOd3s+C7TOVZAk=; b=nPJdR3zVcp7cECMO0Y11+9zBubNo754IKSO90XDPRcsDTKRJ/9bxsGt2C9FC4Csa38 RoxkSsX0NtwOvL/O2xUcSogJmnY6MtxoW/gspXXZQRHC3jXPwzIGXEXaXWW+9TV6Txb4 KN4wTcwtm/3155T05DxmyJDHgmQK0aBJwKucLABVcvQkPJm9hvoEHl990hY+J7px+1m5 d+MtxQwQ8STp8yFfpMz61rQuDmJlOT7RuGOIfAQPnSrrRl9/zWxlBid3eW4vsXNlDDFM kzGhdM2Khv+PxZRW9HkCVIZLZCmib+Pmni5w4RnLH+WrzxS0XvWNnPSRiRgpVQV+muDu yWVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jigy4i+n2GLBCPfs+CvR9lgJg9G7OSOd3s+C7TOVZAk=; b=UZJxbJKHTQ4hlXHFD2FiMzp/uS+H/ec8s8fBQqWobjO7lGBDqwyH/jHtT8kFQo+c9s JD+cZz4cFTwNiwPo8e9YGCBZR18qoYgIfj5YMlbXxmteL1pgwj2CH3Ly22A5HiQ+XXOC xIvkjrB0/LRt1KScljB2m152bjSqaZYKPIYmrmokx1h48jXwZpnfFgydCHjnJbPhvYbL zu1LvwvEbOyRJH63ndqhZV1fQQlRRxi+fo8iPhn4OkM3c4pagyIHDMj/ubWGXIObe/iO YeEA9pVBhxqzx76QLGQzR2suq+Vf+ma4QNFfPw/pRmHVrfdyMc496rRbpliqC4a5eN8E i5wQ== X-Gm-Message-State: ALoCoQnj+mrU/oNaCDrPglryPfuQwQco6IlKloF9NCJ9VyFP5FokRTxKde2kY5H3q66aKTNkQ8XE X-Received: by 10.52.29.212 with SMTP id m20mr8535527vdh.34.1415412223950; Fri, 07 Nov 2014 18:03:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Fri, 7 Nov 2014 18:03:23 -0800 (PST) In-Reply-To: <545D6F6A.3020003@jitsi.org> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> From: Justin Uberti Date: Fri, 7 Nov 2014 18:03:23 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=20cf3079b7ced1da5a05074f56da Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fwnkfW3R1nPIQ7R1OOZmQdE3DN8 Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 02:03:49 -0000 --20cf3079b7ced1da5a05074f56da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's getting hard to follow the idea here, so I suggest you write it up in a document and then we can try to find some time in Hono to sit down and discuss the pros/cons of continuous nomination and your approach. On Fri, Nov 7, 2014 at 5:18 PM, Emil Ivov wrote: > > > On 8.11.14, 1:35, =F0=9F=94=93Dan Wing wrote: > >> >> On Nov 7, 2014, at 2:41 PM, Emil Ivov wrote: >> >> Hey all, >>> >>> In the context of the ongoing discussion on two potential ICE >>> improvements, I wanted to spin off this thread on the idea of >>> continuous nomination. >>> >>> So first of all, as I already mentioned in Toronto, I am very much >>> in favour of a mechanism that would allow ICE processing to yield >>> more than a single nominated pair. Back then the discussion was >>> about MPRTP but there would likely be other use cases as well. >>> >>> In that context, it seems perfectly valid to me that nomination >>> among all validated pairs can occur multiple times within a >>> session. Again, I find this to be a very valid and useful feature. >>> >>> I am however bothered by the "ICE never ends" suggestions made by >>> the document below and more specifically by the fact that >>> candidates may continue to be trickled forever. I think that's both >>> unnecessary and a problem. >>> >>> It is a problem because >>> >>> a) being able to know when the remote agent is done trickling is >>> one of the very reasons we started the work on trickle ICE. This >>> allows to quickly and deterministically detect and declare failure >>> when it occurs. Not having this would require implementations to >>> use magic timers of the sort: "Surely if I couldn't connect in .. >>> say 20 seconds ... then the situation must be hopeless ... I >>> think". >>> >>> b) being able to continuously trickle new candidates forever and >>> ever means that they would have to be paired with all of the peer's >>> *initial* candidates. This means that ICE agents would have to >>> maintain all gathered candidates even when they are not working for >>> them. >>> >>> More importantly however, the whole concept is likely unnecessary >>> because an ICE restart only sounds scary, and it doesn't actually >>> need to be ;). >>> >>> A restart is non-disruptive as media can keep flowing while we are >>> doing ICE processing. >>> >>> 5245 already supports pair reuse and we can easily port that >>> concept to multipath ICE. >>> >>> The one thing that we might be missing today is the syntax to allow >>> for a restart without using offer/answer. >>> >> >> For MICE and some other use cases, I agree that need to signal (in >> SDP) is the 'scary' part of an ICE restart. >> >> This would be trivial to resolve: we just need to allow trickling a >>> restart command. Sending your ufrag and pwd in a trickle update >>> should do the job. >>> >> >> That is a nice approach -- move the 'ICE restart' signaling to an >> (existing, working) media path. >> > > I was actually thinking of the signalling path. So for SIP this would be = a > SIP INFO request with the ufrag/pwd as the sole content. A couple of a=3D > lines would do it for WebRTC. > > I am slightly uncomfortable about doing it on the media path because it > requires you to make the assumption that one of your media paths is certa= in > to survive any sort of mobility event. > > Even if you keep your TURN connection open for that purpose, how do you > know that your new location wouldn't be one where TURN-TCP is the only wa= y > to get out of the local network? > > Or what if you don't even have a TURN server? > > You signalling channel would be a safer bet, but more importantly, you'd > likely want to tear down your call if it didn't. > > > To put that into perspective, let's look at the following use >>> cases: >>> >>> I. You have used the new multipath ICE and you have successfully >>> discovered a couple of working routes: one going through your wi-fi >>> interface and another one going through 4G. During your session, >>> you move closer to your Wi-Fi access point so you detect that RTT >>> and packet loss start looking better on your Wi-Fi interface. >>> >>> You decide to switch from 4G to Wi-Fi. >>> >>> *No ICE restart* would be necessary here because no new paths would >>> need to negotiated. This would be a native feature of the new >>> multipath ICE. >>> >>> II. You start on Wi-Fi in the presence of a 4G interface that you >>> keep for backup. Multipath ICE comes up with pairs over both your >>> interfaces. I don't believe this requires an ICE restart either. >>> You just switch between pre-existing path and one of them expires >>> as pointed out in Justin's document below >>> >>> III. You setup a session at a point of time where 4G is your only >>> working interface. Your Wi-Fi interface then comes up and you want >>> to include it in the game. Here's what you do: >>> >>> a) You gather host, srflx and relay candidates for the new >>> interface. b) You gather candidates on the old interface that >>> haven't been valid before but that are worth trying again (this is >>> non-essential) >>> >>> d) you then trickle a new ufrag and pwd to trigger a restart. >>> >> >> If that trickling happens over the SIP/WebRTC/XMPP signaling channel, >> MICE would prefer not requiring that SDP signaling step or to at >> least allow it to be done later. >> > > Well, if you had multipath ICE, you would be able to switch your media > over to TURN (this wouldn't require any signalling) if that still works > and then do the non-disruptive restart after that to discover other paths= . > > Would this work? > > Emil > > > >> -d >> >> >> b) you batch trickle all currently working candidates that you'd >>> wish to preserve (you can omit any candidates you no longer wish to >>> use, for whatever reason). c) you trickle the newly gathered >>> candidates. >>> >>> The remote party, your peer, would then do the following >>> >>> a) Gather all candidates that didn't work before but that deserve a >>> second chance. This time *this is essential*. SRFLX candiates on >>> your peer might not have worked with your 4G connection but they >>> have every chance of working this time. There are a number of other >>> scenarios where candidates would be worth retrying. >>> >>> b) Your peer would then trickle back to you all the working >>> candidates it wishes to preserve (as long as they are still valid) >>> c) It trickles all candidates it gathered for the occasion, that it >>> wishes to retry. >>> >>> Connectivity checks then proceed as usual. It might be worth paying >>> special attention to the in-use candidates. Implementations might >>> want to either confirm that data is still flowing there, or start >>> the checks with them. This would determine how urgently ICE >>> processing needs to yield results and it may imply changes in >>> nomination strategies. >>> >>> Thoughts? >>> >>> Emil >>> >>> >>> On 7.11.14, 0:44, Justin Uberti wrote: >>> >>>> Agreed. >>>> >>>> I wrote up a slightly more fleshed-out proposal at >>>> https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_ >>>> FzJQe-fvN8bk-Xw/edit >>>> >>>> >>>> >>>> On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson < > martin.thomson@gmail.com > >> > wrote: >>>> >>>> On 6 November 2014 13:47, Justin Uberti >>> > wrote: >>>> >>>>> I looked into how MICE works; I think that continuous >>>>> nomination might be able to effectively support that use case, >>>>> as well as the case that Brandon was interested in, namely >>>>> picking the route that uses the best set of TURN servers. >>>>> >>>> >>>> >>>> I've always believe that continuous ICE operation was the only >>>> way to ensure proper reliability. Multipath or otherwise. You >>>> just need to work out when it is safe to completely stop on any >>>> given pair, assuming that you don't want to be testing the >>>> complete mesh all the time. But you also might want multiple >>>> paths available, or maybe backup paths. >>>> >>>> >>>> >>> -- https://jitsi.org >>> >> >> >> > -- > https://jitsi.org > --20cf3079b7ced1da5a05074f56da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's getting hard to follow the idea here, so I sugges= t you write it up in a document and then we can try to find some time in Ho= no to sit down and discuss the pros/cons of continuous nomination and your = approach.

On= Fri, Nov 7, 2014 at 5:18 PM, Emil Ivov <emcho@jitsi.org> wrot= e:


On 8.11.14, 1:35, =F0=9F=94=93Dan Wing wrote:

On Nov 7, 2014, at 2:41 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

In the context of the ongoing discussion on two potential ICE
improvements, I wanted to spin off this thread on the idea of
continuous nomination.

So first of all, as I already mentioned in Toronto, I am very much
in favour of a mechanism that would allow ICE processing to yield
more than a single nominated pair. Back then the discussion was
about MPRTP but there would likely be other use cases as well.

In that context, it seems perfectly valid to me that nomination
among all validated pairs can occur multiple times within a
session. Again, I find this to be a very valid and useful feature.

I am however bothered by the "ICE never ends" suggestions made by=
the document below and more specifically by the fact that
candidates may continue to be trickled forever. I think that's both
unnecessary and a problem.

It is a problem because

a) being able to know when the remote agent is done trickling is
one of the very reasons we started the work on trickle ICE. This
allows to quickly and deterministically detect and declare failure
when it occurs. Not having this would require implementations to
use magic timers of the sort: "Surely if I couldn't connect in ..<= br> say 20 seconds ... then the situation must be hopeless ... I
think".

b) being able to continuously trickle new candidates forever and
ever means that they would have to be paired with all of the peer's
*initial* candidates. This means that ICE agents would have to
maintain all gathered candidates even when they are not working for
them.

More importantly however, the whole concept is likely unnecessary
because an ICE restart only sounds scary, and it doesn't actually
need to be ;).

A restart is non-disruptive as media can keep flowing while we are
doing ICE processing.

5245 already supports pair reuse and we can easily port that
concept to multipath ICE.

The one thing that we might be missing today is the syntax to allow
for a restart without using offer/answer.

For MICE and some other use cases, I agree that need to signal (in
SDP) is the 'scary' part of an ICE restart.

This would be trivial to resolve: we just need to allow trickling a
restart command. Sending your ufrag and pwd in a trickle update
should do the job.

That is a nice approach -- move the 'ICE restart' signaling to an (existing, working) media path.

I was actually thinking of the signalling path. So for SIP this would be a = SIP INFO request with the ufrag/pwd as the sole content. A couple of a=3D l= ines would do it for WebRTC.

I am slightly uncomfortable about doing it on the media path because it req= uires you to make the assumption that one of your media paths is certain to= survive any sort of mobility event.

Even if you keep your TURN connection open for that purpose, how do you kno= w that your new location wouldn't be one where TURN-TCP is the only way= to get out of the local network?

Or what if you don't even have a TURN server?

You signalling channel would be a safer bet, but more importantly, you'= d likely want to tear down your call if it didn't.


To put that into perspective, let's look at the following use
cases:

I. You have used the new multipath ICE and you have successfully
discovered a couple of working routes: one going through your wi-fi
interface and another one going through 4G. During your session,
you move closer to your Wi-Fi access point so you detect that RTT
and packet loss start looking better on your Wi-Fi interface.

You decide to switch from 4G to Wi-Fi.

*No ICE restart* would be necessary here because no new paths would
need to negotiated. This would be a native feature of the new
multipath ICE.

II. You start on Wi-Fi in the presence of a 4G interface that you
keep for backup. Multipath ICE comes up with pairs over both your
interfaces. I don't believe this requires an ICE restart either.
You just switch between pre-existing path and one of them expires
as pointed out in Justin's document below

III. You setup a session at a point of time where 4G is your only
working interface. Your Wi-Fi interface then comes up and you want
to include it in the game. Here's what you do:

a) You gather host, srflx and relay candidates for the new
interface. b) You gather candidates on the old interface that
haven't been valid before but that are worth trying again (this is
non-essential)

d) you then trickle a new ufrag and pwd to trigger a restart.

If that trickling happens over the SIP/WebRTC/XMPP signaling channel,
MICE would prefer not requiring that SDP signaling step or to at
least allow it to be done later.

Well, if you had multipath ICE, you would be able to switch your media over= to TURN (this wouldn't require any signalling)=C2=A0 if that still wor= ks and then do the non-disruptive restart after that to discover other path= s.

Would this work?

Emil



-d


b) you batch trickle all currently working candidates that you'd
wish to preserve (you can omit any candidates you no longer wish to
use, for whatever reason). c) you trickle the newly gathered
candidates.

The remote party, your peer, would then do the following

a) Gather all candidates that didn't work before but that deserve a
second chance. This time *this is essential*. SRFLX candiates on
your peer might not have worked with your 4G connection but they
have every chance of working this time. There are a number of other
scenarios where candidates would be worth retrying.

b) Your peer would then trickle back to you all the working
candidates it wishes to preserve (as long as they are still valid)
c) It trickles all candidates it gathered for the occasion, that it
wishes to retry.

Connectivity checks then proceed as usual. It might be worth paying
special attention to the in-use candidates. Implementations might
want to either confirm that data is still flowing there, or start
the checks with them. This would determine how urgently ICE
processing needs to yield results and it may imply changes in
nomination strategies.

Thoughts?

Emil


On 7.11.14, 0:44, Justin Uberti wrote:
Agreed.

I wrote up a slightly more fleshed-out proposal at
https://docs.google.com/docu= ment/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit<= br>


On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson <martin.thomson@gmail.com
<mailto:ma= rtin.thomson@gmail.com>> wrote:

On 6 November 2014 13:47, Justin Uberti <juberti@google.com
<mailto:juberti@= google.com>> wrote:
I looked into how MICE works; I think that continuous
nomination might be able to effectively support that use case,
as well as the case that Brandon was interested in, namely
picking the route that uses the best set of TURN servers.


I've always believe that continuous ICE operation was the only
way to ensure proper reliability.=C2=A0 Multipath or otherwise.=C2=A0 You just need to work out when it is safe to completely stop on any
given pair, assuming that you don't want to be testing the
complete mesh all the time.=C2=A0 But you also might want multiple
paths available, or maybe backup paths.



-- https://jitsi.org



--
https://jitsi.org

--20cf3079b7ced1da5a05074f56da-- From nobody Fri Nov 7 20:56:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11681A026E for ; Fri, 7 Nov 2014 20:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5Cj_hIcMUJ1 for ; Fri, 7 Nov 2014 20:56:42 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80AA1A0263 for ; Fri, 7 Nov 2014 20:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12522; q=dns/txt; s=iport; t=1415422601; x=1416632201; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=j4o6PVjog+LeWY8TuXml8JPIybHZJmYKyJMMj7CfjoU=; b=m3sLON02m66ygjQQqkYRwQFpsxRoM73ajO+ynBfN1ch3SUWhqQa6CEbo Z4Y5pLQ8OthEaEets+97smWellbs1zZYohvCbiZbGZwG6CFmcNm/C6Zk9 OTDW+Ye3UzLkB2lqNMy3oPYypECwDPW8LhYXt2K3+aYvQGuPjM1aC1vL0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgHAPKhXVStJV2Z/2dsb2JhbABWBYMOVFkEgwLITwyGeFUCHH8WAQEBAQF9hAIBAQEDAQEBASAROgsMBgEGAg4DBAEBAQICBh0DAgQfBgsUAQgJAQQBDQUIiCQDCQkNnCScX456DYZZAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EtiUiDYoFPKhAxDYJxNoEeBYRqMwKNCIRUhEpDg0Q9jTtCgmeECYN5bAGBByQcgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,337,1413244800"; d="scan'208";a="94663894" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 08 Nov 2014 04:56:40 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA84uefH004270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Nov 2014 04:56:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 7 Nov 2014 22:56:40 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov , "Dan Wing (dwing)" Thread-Topic: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) Thread-Index: Ac/7EFz6NUzJiCvAQKOA1KCeBUvJNw== Date: Sat, 8 Nov 2014 04:56:39 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28357FF0@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.70.232.155] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DXWQIDv1UNhnl4c6SyvUViZPZBA Cc: Jonathan Lennox , =?utf-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 04:56:45 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtbXVzaWMgW21haWx0bzptbXVz aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVtaWwgSXZvdg0KPiBTZW50OiBTYXR1 cmRheSwgTm92ZW1iZXIgMDgsIDIwMTQgNjo0OSBBTQ0KPiBUbzogRGFuIFdpbmcgKGR3aW5nKQ0K PiBDYzogSm9uYXRoYW4gTGVubm94OyBBcmkgS2Vyw6RuZW47IG1tdXNpYw0KPiBTdWJqZWN0OiBS ZTogW01NVVNJQ10gQ29udGludW91cyBOb21pbmF0aW9uIChXYXM6IEZhc3RlciBJQ0UgYnkgcm9s ZQ0KPiByZXZlcnNhbD8pDQo+IA0KPiANCj4gDQo+IE9uIDguMTEuMTQsIDE6MzUsIPCflJNEYW4g V2luZyB3cm90ZToNCj4gPg0KPiA+IE9uIE5vdiA3LCAyMDE0LCBhdCAyOjQxIFBNLCBFbWlsIEl2 b3YgPGVtY2hvQGppdHNpLm9yZz4gd3JvdGU6DQo+ID4NCj4gPj4gSGV5IGFsbCwNCj4gPj4NCj4g Pj4gSW4gdGhlIGNvbnRleHQgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbiBvbiB0d28gcG90ZW50 aWFsIElDRQ0KPiA+PiBpbXByb3ZlbWVudHMsIEkgd2FudGVkIHRvIHNwaW4gb2ZmIHRoaXMgdGhy ZWFkIG9uIHRoZSBpZGVhIG9mDQo+ID4+IGNvbnRpbnVvdXMgbm9taW5hdGlvbi4NCj4gPj4NCj4g Pj4gU28gZmlyc3Qgb2YgYWxsLCBhcyBJIGFscmVhZHkgbWVudGlvbmVkIGluIFRvcm9udG8sIEkg YW0gdmVyeSBtdWNoIGluDQo+ID4+IGZhdm91ciBvZiBhIG1lY2hhbmlzbSB0aGF0IHdvdWxkIGFs bG93IElDRSBwcm9jZXNzaW5nIHRvIHlpZWxkIG1vcmUNCj4gPj4gdGhhbiBhIHNpbmdsZSBub21p bmF0ZWQgcGFpci4gQmFjayB0aGVuIHRoZSBkaXNjdXNzaW9uIHdhcyBhYm91dA0KPiA+PiBNUFJU UCBidXQgdGhlcmUgd291bGQgbGlrZWx5IGJlIG90aGVyIHVzZSBjYXNlcyBhcyB3ZWxsLg0KPiA+ Pg0KPiA+PiBJbiB0aGF0IGNvbnRleHQsIGl0IHNlZW1zIHBlcmZlY3RseSB2YWxpZCB0byBtZSB0 aGF0IG5vbWluYXRpb24gYW1vbmcNCj4gPj4gYWxsIHZhbGlkYXRlZCBwYWlycyBjYW4gb2NjdXIg bXVsdGlwbGUgdGltZXMgd2l0aGluIGEgc2Vzc2lvbi4gQWdhaW4sDQo+ID4+IEkgZmluZCB0aGlz IHRvIGJlIGEgdmVyeSB2YWxpZCBhbmQgdXNlZnVsIGZlYXR1cmUuDQo+ID4+DQo+ID4+IEkgYW0g aG93ZXZlciBib3RoZXJlZCBieSB0aGUgIklDRSBuZXZlciBlbmRzIiBzdWdnZXN0aW9ucyBtYWRl IGJ5IHRoZQ0KPiA+PiBkb2N1bWVudCBiZWxvdyBhbmQgbW9yZSBzcGVjaWZpY2FsbHkgYnkgdGhl IGZhY3QgdGhhdCBjYW5kaWRhdGVzIG1heQ0KPiA+PiBjb250aW51ZSB0byBiZSB0cmlja2xlZCBm b3JldmVyLiBJIHRoaW5rIHRoYXQncyBib3RoIHVubmVjZXNzYXJ5IGFuZA0KPiA+PiBhIHByb2Js ZW0uDQo+ID4+DQo+ID4+IEl0IGlzIGEgcHJvYmxlbSBiZWNhdXNlDQo+ID4+DQo+ID4+IGEpIGJl aW5nIGFibGUgdG8ga25vdyB3aGVuIHRoZSByZW1vdGUgYWdlbnQgaXMgZG9uZSB0cmlja2xpbmcg aXMgb25lDQo+ID4+IG9mIHRoZSB2ZXJ5IHJlYXNvbnMgd2Ugc3RhcnRlZCB0aGUgd29yayBvbiB0 cmlja2xlIElDRS4gVGhpcyBhbGxvd3MNCj4gPj4gdG8gcXVpY2tseSBhbmQgZGV0ZXJtaW5pc3Rp Y2FsbHkgZGV0ZWN0IGFuZCBkZWNsYXJlIGZhaWx1cmUgd2hlbiBpdA0KPiA+PiBvY2N1cnMuIE5v dCBoYXZpbmcgdGhpcyB3b3VsZCByZXF1aXJlIGltcGxlbWVudGF0aW9ucyB0byB1c2UgbWFnaWMN Cj4gPj4gdGltZXJzIG9mIHRoZSBzb3J0OiAiU3VyZWx5IGlmIEkgY291bGRuJ3QgY29ubmVjdCBp biAuLg0KPiA+PiBzYXkgMjAgc2Vjb25kcyAuLi4gdGhlbiB0aGUgc2l0dWF0aW9uIG11c3QgYmUg aG9wZWxlc3MgLi4uIEkgdGhpbmsiLg0KPiA+Pg0KPiA+PiBiKSBiZWluZyBhYmxlIHRvIGNvbnRp bnVvdXNseSB0cmlja2xlIG5ldyBjYW5kaWRhdGVzIGZvcmV2ZXIgYW5kIGV2ZXINCj4gPj4gbWVh bnMgdGhhdCB0aGV5IHdvdWxkIGhhdmUgdG8gYmUgcGFpcmVkIHdpdGggYWxsIG9mIHRoZSBwZWVy J3MNCj4gPj4gKmluaXRpYWwqIGNhbmRpZGF0ZXMuIFRoaXMgbWVhbnMgdGhhdCBJQ0UgYWdlbnRz IHdvdWxkIGhhdmUgdG8NCj4gPj4gbWFpbnRhaW4gYWxsIGdhdGhlcmVkIGNhbmRpZGF0ZXMgZXZl biB3aGVuIHRoZXkgYXJlIG5vdCB3b3JraW5nIGZvcg0KPiA+PiB0aGVtLg0KPiA+Pg0KPiA+PiBN b3JlIGltcG9ydGFudGx5IGhvd2V2ZXIsIHRoZSB3aG9sZSBjb25jZXB0IGlzIGxpa2VseSB1bm5l Y2Vzc2FyeQ0KPiA+PiBiZWNhdXNlIGFuIElDRSByZXN0YXJ0IG9ubHkgc291bmRzIHNjYXJ5LCBh bmQgaXQgZG9lc24ndCBhY3R1YWxseQ0KPiA+PiBuZWVkIHRvIGJlIDspLg0KPiA+Pg0KPiA+PiBB IHJlc3RhcnQgaXMgbm9uLWRpc3J1cHRpdmUgYXMgbWVkaWEgY2FuIGtlZXAgZmxvd2luZyB3aGls ZSB3ZSBhcmUNCj4gPj4gZG9pbmcgSUNFIHByb2Nlc3NpbmcuDQo+ID4+DQo+ID4+IDUyNDUgYWxy ZWFkeSBzdXBwb3J0cyBwYWlyIHJldXNlIGFuZCB3ZSBjYW4gZWFzaWx5IHBvcnQgdGhhdCBjb25j ZXB0DQo+ID4+IHRvIG11bHRpcGF0aCBJQ0UuDQo+ID4+DQo+ID4+IFRoZSBvbmUgdGhpbmcgdGhh dCB3ZSBtaWdodCBiZSBtaXNzaW5nIHRvZGF5IGlzIHRoZSBzeW50YXggdG8gYWxsb3cNCj4gPj4g Zm9yIGEgcmVzdGFydCB3aXRob3V0IHVzaW5nIG9mZmVyL2Fuc3dlci4NCj4gPg0KPiA+IEZvciBN SUNFIGFuZCBzb21lIG90aGVyIHVzZSBjYXNlcywgSSBhZ3JlZSB0aGF0IG5lZWQgdG8gc2lnbmFs IChpbg0KPiA+IFNEUCkgaXMgdGhlICdzY2FyeScgcGFydCBvZiBhbiBJQ0UgcmVzdGFydC4NCj4g Pg0KPiA+PiBUaGlzIHdvdWxkIGJlIHRyaXZpYWwgdG8gcmVzb2x2ZTogd2UganVzdCBuZWVkIHRv IGFsbG93IHRyaWNrbGluZyBhDQo+ID4+IHJlc3RhcnQgY29tbWFuZC4gU2VuZGluZyB5b3VyIHVm cmFnIGFuZCBwd2QgaW4gYSB0cmlja2xlIHVwZGF0ZQ0KPiA+PiBzaG91bGQgZG8gdGhlIGpvYi4N Cj4gPg0KPiA+IFRoYXQgaXMgYSBuaWNlIGFwcHJvYWNoIC0tIG1vdmUgdGhlICdJQ0UgcmVzdGFy dCcgc2lnbmFsaW5nIHRvIGFuDQo+ID4gKGV4aXN0aW5nLCB3b3JraW5nKSBtZWRpYSBwYXRoLg0K PiANCj4gSSB3YXMgYWN0dWFsbHkgdGhpbmtpbmcgb2YgdGhlIHNpZ25hbGxpbmcgcGF0aC4gU28g Zm9yIFNJUCB0aGlzIHdvdWxkIGJlIGEgU0lQDQo+IElORk8gcmVxdWVzdCB3aXRoIHRoZSB1ZnJh Zy9wd2QgYXMgdGhlIHNvbGUgY29udGVudC4gQSBjb3VwbGUgb2YgYT0gbGluZXMNCj4gd291bGQg ZG8gaXQgZm9yIFdlYlJUQy4NCj4gDQo+IEkgYW0gc2xpZ2h0bHkgdW5jb21mb3J0YWJsZSBhYm91 dCBkb2luZyBpdCBvbiB0aGUgbWVkaWEgcGF0aCBiZWNhdXNlIGl0DQo+IHJlcXVpcmVzIHlvdSB0 byBtYWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQgb25lIG9mIHlvdXIgbWVkaWEgcGF0aHMgaXMgY2Vy dGFpbg0KPiB0byBzdXJ2aXZlIGFueSBzb3J0IG9mIG1vYmlsaXR5IGV2ZW50Lg0KPiANCj4gRXZl biBpZiB5b3Uga2VlcCB5b3VyIFRVUk4gY29ubmVjdGlvbiBvcGVuIGZvciB0aGF0IHB1cnBvc2Us IGhvdyBkbyB5b3UNCj4ga25vdyB0aGF0IHlvdXIgbmV3IGxvY2F0aW9uIHdvdWxkbid0IGJlIG9u ZSB3aGVyZSBUVVJOLVRDUCBpcyB0aGUgb25seQ0KPiB3YXkgdG8gZ2V0IG91dCBvZiB0aGUgbG9j YWwgbmV0d29yaz8NCg0KVFVSTiBNb2JpbGl0eSBjYW4gYmUgdXNlZCB0byBzb2x2ZWQgdGhlIHBy b2JsZW0gYW5kIGFsbG93cyBjbGllbnQgdG8gc3dpdGNoLW92ZXIgdG8gVFVSTi1UQ1AuIE9ubHkg VFVSTiB3b3JrcyBpbiBjYXNlIG9mICBTaW11bHRhbmVvdXMgTW9iaWxpdHkgKElmIGJvdGggdGhl IGVuZHBvaW50cyBhcmUgbW9iaWxlIGFuZCByb2FtIGF0IHRoZSBzYW1lIHRpbWUgYmV0d2VlbiBu ZXR3b3Jrcy4pDQoNCj4gDQo+IE9yIHdoYXQgaWYgeW91IGRvbid0IGV2ZW4gaGF2ZSBhIFRVUk4g c2VydmVyPw0KDQpUVVJOIHNlcnZlcnMgY291bGQgYmUgcHJvdmlkZWQgYnkgYWNjZXNzIG5ldHdv cmssIGFwcGxpY2F0aW9uIHNlcnZpY2UgcHJvdmlkZXIgb3IgYSB0aGlyZCBwYXJ0eSBwcm92aWRl ciAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdGlsLXRyYW0tdHVybi1zZXJ2 LXNlbGVjdGlvbi0wMCkgYW5kIHNob3VsZCBiZSByZWFjaGFibGUgYWNyb3NzIGRpZmZlcmVudCBu ZXR3b3Jrcy4NCg0KPiANCj4gWW91IHNpZ25hbGxpbmcgY2hhbm5lbCB3b3VsZCBiZSBhIHNhZmVy IGJldCwgYnV0IG1vcmUgaW1wb3J0YW50bHksIHlvdSdkDQo+IGxpa2VseSB3YW50IHRvIHRlYXIg ZG93biB5b3VyIGNhbGwgaWYgaXQgZGlkbid0Lg0KPiANCj4gPj4gVG8gcHV0IHRoYXQgaW50byBw ZXJzcGVjdGl2ZSwgbGV0J3MgbG9vayBhdCB0aGUgZm9sbG93aW5nIHVzZQ0KPiA+PiBjYXNlczoN Cj4gPj4NCj4gPj4gSS4gWW91IGhhdmUgdXNlZCB0aGUgbmV3IG11bHRpcGF0aCBJQ0UgYW5kIHlv dSBoYXZlIHN1Y2Nlc3NmdWxseQ0KPiA+PiBkaXNjb3ZlcmVkIGEgY291cGxlIG9mIHdvcmtpbmcg cm91dGVzOiBvbmUgZ29pbmcgdGhyb3VnaCB5b3VyIHdpLWZpDQo+ID4+IGludGVyZmFjZSBhbmQg YW5vdGhlciBvbmUgZ29pbmcgdGhyb3VnaCA0Ry4gRHVyaW5nIHlvdXIgc2Vzc2lvbiwgeW91DQo+ ID4+IG1vdmUgY2xvc2VyIHRvIHlvdXIgV2ktRmkgYWNjZXNzIHBvaW50IHNvIHlvdSBkZXRlY3Qg dGhhdCBSVFQgYW5kDQo+ID4+IHBhY2tldCBsb3NzIHN0YXJ0IGxvb2tpbmcgYmV0dGVyIG9uIHlv dXIgV2ktRmkgaW50ZXJmYWNlLg0KPiA+Pg0KPiA+PiBZb3UgZGVjaWRlIHRvIHN3aXRjaCBmcm9t IDRHIHRvIFdpLUZpLg0KPiA+Pg0KPiA+PiAqTm8gSUNFIHJlc3RhcnQqIHdvdWxkIGJlIG5lY2Vz c2FyeSBoZXJlIGJlY2F1c2Ugbm8gbmV3IHBhdGhzIHdvdWxkDQo+ID4+IG5lZWQgdG8gbmVnb3Rp YXRlZC4gVGhpcyB3b3VsZCBiZSBhIG5hdGl2ZSBmZWF0dXJlIG9mIHRoZSBuZXcNCj4gPj4gbXVs dGlwYXRoIElDRS4NCj4gPj4NCj4gPj4gSUkuIFlvdSBzdGFydCBvbiBXaS1GaSBpbiB0aGUgcHJl c2VuY2Ugb2YgYSA0RyBpbnRlcmZhY2UgdGhhdCB5b3UNCj4gPj4ga2VlcCBmb3IgYmFja3VwLiBN dWx0aXBhdGggSUNFIGNvbWVzIHVwIHdpdGggcGFpcnMgb3ZlciBib3RoIHlvdXINCj4gPj4gaW50 ZXJmYWNlcy4gSSBkb24ndCBiZWxpZXZlIHRoaXMgcmVxdWlyZXMgYW4gSUNFIHJlc3RhcnQgZWl0 aGVyLg0KPiA+PiBZb3UganVzdCBzd2l0Y2ggYmV0d2VlbiBwcmUtZXhpc3RpbmcgcGF0aCBhbmQg b25lIG9mIHRoZW0gZXhwaXJlcyBhcw0KPiA+PiBwb2ludGVkIG91dCBpbiBKdXN0aW4ncyBkb2N1 bWVudCBiZWxvdw0KPiA+Pg0KPiA+PiBJSUkuIFlvdSBzZXR1cCBhIHNlc3Npb24gYXQgYSBwb2lu dCBvZiB0aW1lIHdoZXJlIDRHIGlzIHlvdXIgb25seQ0KPiA+PiB3b3JraW5nIGludGVyZmFjZS4g WW91ciBXaS1GaSBpbnRlcmZhY2UgdGhlbiBjb21lcyB1cCBhbmQgeW91IHdhbnQgdG8NCj4gPj4g aW5jbHVkZSBpdCBpbiB0aGUgZ2FtZS4gSGVyZSdzIHdoYXQgeW91IGRvOg0KPiA+Pg0KPiA+PiBh KSBZb3UgZ2F0aGVyIGhvc3QsIHNyZmx4IGFuZCByZWxheSBjYW5kaWRhdGVzIGZvciB0aGUgbmV3 IGludGVyZmFjZS4NCj4gPj4gYikgWW91IGdhdGhlciBjYW5kaWRhdGVzIG9uIHRoZSBvbGQgaW50 ZXJmYWNlIHRoYXQgaGF2ZW4ndCBiZWVuIHZhbGlkDQo+ID4+IGJlZm9yZSBidXQgdGhhdCBhcmUg d29ydGggdHJ5aW5nIGFnYWluICh0aGlzIGlzDQo+ID4+IG5vbi1lc3NlbnRpYWwpDQo+ID4+DQo+ ID4+IGQpIHlvdSB0aGVuIHRyaWNrbGUgYSBuZXcgdWZyYWcgYW5kIHB3ZCB0byB0cmlnZ2VyIGEg cmVzdGFydC4NCj4gPg0KPiA+IElmIHRoYXQgdHJpY2tsaW5nIGhhcHBlbnMgb3ZlciB0aGUgU0lQ L1dlYlJUQy9YTVBQIHNpZ25hbGluZyBjaGFubmVsLA0KPiA+IE1JQ0Ugd291bGQgcHJlZmVyIG5v dCByZXF1aXJpbmcgdGhhdCBTRFAgc2lnbmFsaW5nIHN0ZXAgb3IgdG8gYXQgbGVhc3QNCj4gPiBh bGxvdyBpdCB0byBiZSBkb25lIGxhdGVyLg0KPiANCj4gV2VsbCwgaWYgeW91IGhhZCBtdWx0aXBh dGggSUNFLCB5b3Ugd291bGQgYmUgYWJsZSB0byBzd2l0Y2ggeW91ciBtZWRpYSBvdmVyDQo+IHRv IFRVUk4gKHRoaXMgd291bGRuJ3QgcmVxdWlyZSBhbnkgc2lnbmFsbGluZykgIGlmIHRoYXQgc3Rp bGwgd29ya3MgYW5kIHRoZW4gZG8NCj4gdGhlIG5vbi1kaXNydXB0aXZlIHJlc3RhcnQgYWZ0ZXIg dGhhdCB0byBkaXNjb3ZlciBvdGhlciBwYXRocy4NCg0KWWVzLCBpdCdzIGRpc2N1c3NlZCBpbiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHkt MDYjc2VjdGlvbi0zLjIuDQoNCi1UaXJ1DQoNCj4gDQo+IFdvdWxkIHRoaXMgd29yaz8NCj4gDQo+ IEVtaWwNCj4gDQo+ID4NCj4gPiAtZA0KPiA+DQo+ID4NCj4gPj4gYikgeW91IGJhdGNoIHRyaWNr bGUgYWxsIGN1cnJlbnRseSB3b3JraW5nIGNhbmRpZGF0ZXMgdGhhdCB5b3UnZCB3aXNoDQo+ID4+ IHRvIHByZXNlcnZlICh5b3UgY2FuIG9taXQgYW55IGNhbmRpZGF0ZXMgeW91IG5vIGxvbmdlciB3 aXNoIHRvIHVzZSwNCj4gPj4gZm9yIHdoYXRldmVyIHJlYXNvbikuIGMpIHlvdSB0cmlja2xlIHRo ZSBuZXdseSBnYXRoZXJlZCBjYW5kaWRhdGVzLg0KPiA+Pg0KPiA+PiBUaGUgcmVtb3RlIHBhcnR5 LCB5b3VyIHBlZXIsIHdvdWxkIHRoZW4gZG8gdGhlIGZvbGxvd2luZw0KPiA+Pg0KPiA+PiBhKSBH YXRoZXIgYWxsIGNhbmRpZGF0ZXMgdGhhdCBkaWRuJ3Qgd29yayBiZWZvcmUgYnV0IHRoYXQgZGVz ZXJ2ZSBhDQo+ID4+IHNlY29uZCBjaGFuY2UuIFRoaXMgdGltZSAqdGhpcyBpcyBlc3NlbnRpYWwq LiBTUkZMWCBjYW5kaWF0ZXMgb24geW91cg0KPiA+PiBwZWVyIG1pZ2h0IG5vdCBoYXZlIHdvcmtl ZCB3aXRoIHlvdXIgNEcgY29ubmVjdGlvbiBidXQgdGhleSBoYXZlDQo+ID4+IGV2ZXJ5IGNoYW5j ZSBvZiB3b3JraW5nIHRoaXMgdGltZS4gVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG90aGVyDQo+ID4+ IHNjZW5hcmlvcyB3aGVyZSBjYW5kaWRhdGVzIHdvdWxkIGJlIHdvcnRoIHJldHJ5aW5nLg0KPiA+ Pg0KPiA+PiBiKSBZb3VyIHBlZXIgd291bGQgdGhlbiB0cmlja2xlIGJhY2sgdG8geW91IGFsbCB0 aGUgd29ya2luZw0KPiA+PiBjYW5kaWRhdGVzIGl0IHdpc2hlcyB0byBwcmVzZXJ2ZSAoYXMgbG9u ZyBhcyB0aGV5IGFyZSBzdGlsbCB2YWxpZCkNCj4gPj4gYykgSXQgdHJpY2tsZXMgYWxsIGNhbmRp ZGF0ZXMgaXQgZ2F0aGVyZWQgZm9yIHRoZSBvY2Nhc2lvbiwgdGhhdCBpdA0KPiA+PiB3aXNoZXMg dG8gcmV0cnkuDQo+ID4+DQo+ID4+IENvbm5lY3Rpdml0eSBjaGVja3MgdGhlbiBwcm9jZWVkIGFz IHVzdWFsLiBJdCBtaWdodCBiZSB3b3J0aCBwYXlpbmcNCj4gPj4gc3BlY2lhbCBhdHRlbnRpb24g dG8gdGhlIGluLXVzZSBjYW5kaWRhdGVzLiBJbXBsZW1lbnRhdGlvbnMgbWlnaHQNCj4gPj4gd2Fu dCB0byBlaXRoZXIgY29uZmlybSB0aGF0IGRhdGEgaXMgc3RpbGwgZmxvd2luZyB0aGVyZSwgb3Ig c3RhcnQgdGhlDQo+ID4+IGNoZWNrcyB3aXRoIHRoZW0uIFRoaXMgd291bGQgZGV0ZXJtaW5lIGhv dyB1cmdlbnRseSBJQ0UgcHJvY2Vzc2luZw0KPiA+PiBuZWVkcyB0byB5aWVsZCByZXN1bHRzIGFu ZCBpdCBtYXkgaW1wbHkgY2hhbmdlcyBpbiBub21pbmF0aW9uDQo+ID4+IHN0cmF0ZWdpZXMuDQo+ ID4+DQo+ID4+IFRob3VnaHRzPw0KPiA+Pg0KPiA+PiBFbWlsDQo+ID4+DQo+ID4+DQo+ID4+IE9u IDcuMTEuMTQsIDA6NDQsIEp1c3RpbiBVYmVydGkgd3JvdGU6DQo+ID4+PiBBZ3JlZWQuDQo+ID4+ Pg0KPiA+Pj4gSSB3cm90ZSB1cCBhIHNsaWdodGx5IG1vcmUgZmxlc2hlZC1vdXQgcHJvcG9zYWwg YXQNCj4gPj4+DQo+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2QvMVAxWFBDUkpL QmtTandDeklJRVVKbXA3VjY5NF9GekoNCj4gUQ0KPiA+Pj4gZS1mdk44YmstWHcvZWRpdA0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiBPbiBUaHUsIE5vdiA2LCAyMDE0IGF0IDM6MjkgUE0sIE1hcnRp biBUaG9tc29uDQo+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20NCj4gPj4+IDxtYWlsdG86bWFy dGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gT24gNiBOb3ZlbWJl ciAyMDE0IDEzOjQ3LCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20NCj4gPj4+IDxt YWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQo+ID4+Pj4gSSBsb29rZWQgaW50byBo b3cgTUlDRSB3b3JrczsgSSB0aGluayB0aGF0IGNvbnRpbnVvdXMgbm9taW5hdGlvbg0KPiA+Pj4+ IG1pZ2h0IGJlIGFibGUgdG8gZWZmZWN0aXZlbHkgc3VwcG9ydCB0aGF0IHVzZSBjYXNlLCBhcyB3 ZWxsIGFzIHRoZQ0KPiA+Pj4+IGNhc2UgdGhhdCBCcmFuZG9uIHdhcyBpbnRlcmVzdGVkIGluLCBu YW1lbHkgcGlja2luZyB0aGUgcm91dGUgdGhhdA0KPiA+Pj4+IHVzZXMgdGhlIGJlc3Qgc2V0IG9m IFRVUk4gc2VydmVycy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gSSd2ZSBhbHdheXMgYmVsaWV2ZSB0 aGF0IGNvbnRpbnVvdXMgSUNFIG9wZXJhdGlvbiB3YXMgdGhlIG9ubHkgd2F5DQo+ID4+PiB0byBl bnN1cmUgcHJvcGVyIHJlbGlhYmlsaXR5LiAgTXVsdGlwYXRoIG9yIG90aGVyd2lzZS4gIFlvdSBq dXN0DQo+ID4+PiBuZWVkIHRvIHdvcmsgb3V0IHdoZW4gaXQgaXMgc2FmZSB0byBjb21wbGV0ZWx5 IHN0b3Agb24gYW55IGdpdmVuDQo+ID4+PiBwYWlyLCBhc3N1bWluZyB0aGF0IHlvdSBkb24ndCB3 YW50IHRvIGJlIHRlc3RpbmcgdGhlIGNvbXBsZXRlIG1lc2gNCj4gPj4+IGFsbCB0aGUgdGltZS4g IEJ1dCB5b3UgYWxzbyBtaWdodCB3YW50IG11bHRpcGxlIHBhdGhzIGF2YWlsYWJsZSwgb3INCj4g Pj4+IG1heWJlIGJhY2t1cCBwYXRocy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pg0KPiA+PiAtLSBodHRw czovL2ppdHNpLm9yZw0KPiA+DQo+ID4NCj4gDQo+IC0tDQo+IGh0dHBzOi8vaml0c2kub3JnDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBt bXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K From nobody Fri Nov 7 21:15:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161C61A0369 for ; Fri, 7 Nov 2014 21:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na7WmhrUJJUd for ; Fri, 7 Nov 2014 21:15:40 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5AC1A036F for ; Fri, 7 Nov 2014 21:15:40 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id hz20so5383045lab.23 for ; Fri, 07 Nov 2014 21:15:39 -0800 (PST) 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=y+3rbaou1I4MXOPxB+yP1xqSj5rqHoMWKpeT6NrUggw=; b=YXsfNecnTLufkLzJ7mIK3g0VLoFdqqfG4Siz2op8Sq/OPmTwR6HN+h4d7GUAdSCijV MUXv11sEocl45fo8saxbQmBcIaeuh4V5RGANv5IO3T1C9i+g9JiCnvYEHC87mN/3EHQ8 HdeTLf+Uop3BO6GtrfnuFegIxrgJpsO/JDrlf7ftJ5fMAH4fRjFmW8vvZpzsPnAiYzP5 j/NBaymiovK13KlRAsAIwmpEi4h+E/d5/nC9hraQsoUUosKc/4bJkvQTudVHKEKQBmBL 3jzPLIM4KAoAZKkJmx+Y9Dbpfq4eOdoiRShyWhJhiiJa47df+yOszpJNqG9f96Pl31pv zQ6Q== MIME-Version: 1.0 X-Received: by 10.152.203.196 with SMTP id ks4mr15047943lac.51.1415423739023; Fri, 07 Nov 2014 21:15:39 -0800 (PST) Received: by 10.25.215.134 with HTTP; Fri, 7 Nov 2014 21:15:38 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> Date: Fri, 7 Nov 2014 21:15:38 -0800 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mrn36JXke6txn7rvAxAZfJZl9sQ Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 05:15:42 -0000 On 6 November 2014 16:41, Emil Ivov wrote: >> A candidate that arrives after that point is not going to >> change anything. > > This is wrong. > > Just attach a new ufrag/pwd to your new cand and it can change everything. There's a marked difference between ICE restart and trickling. From nobody Fri Nov 7 22:08:32 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA4F1A03AB for ; Fri, 7 Nov 2014 22:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqrE_JK3AAZO for ; Fri, 7 Nov 2014 22:08:29 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BF11A0395 for ; Fri, 7 Nov 2014 22:08:28 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so2519531vcb.19 for ; Fri, 07 Nov 2014 22:08:28 -0800 (PST) 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=1heCBhQtlVeJix8I7FlVt83GWdOzDtBIsxcG4nGRYQo=; b=aEYkgaa5TReZSUDStjBbrJQbxBFi4hmYXEHOnUyNUMDGX5a4a5MegzNIR3kuYvBHV4 QnatgYzq0Gu/d6N62KUPFH4iuh9aAlfNPwqknRTi5NJg2XoowrNTcAJw7aFSo4RnqMIj b+0c+ibgm4dyTAD2m6ar8vMVIkIZ7uuiMv81BbeIB1QSMs5rIyEDc1cTol902Yv+H7Ne HqXEwzRQDmGZA5CTQ1p5U3/yXKWaPnOPTeyoBVH+X3JnqeWn559SHjmBf0QAc6kd2N+w T6Naj9TCurVcnFSHlTlLAatI0KkwQ9+9aQ3fWAjIdI4vxvBDOYDi+FxJwL+qyn/Zt7fp doEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1heCBhQtlVeJix8I7FlVt83GWdOzDtBIsxcG4nGRYQo=; b=HWnlRSoT7/yjJJKl8qwLs/h8K56F58TxSkZJR69zozF0pyTYe4u4Bz3K7fbeeG96Km Y9xG2Jd1kcMf8fAJmJxkrYVRxvpXjhVQ5vPvOHzeT80GuK5wW93XjBlwl9/2JdYQKzQj yocl6UpumD3QZIZh5PDFmXdWCicKHbVvGr5q4S72yeWKCjEXRY8po+R6uqFOe2I0qTa+ R/jGbGXtgSMK6k5Lsc1JQYIt3Ai8L1Y/lQld8xwRIp2zcblCyzLbRGofUpWF6v5uj2yS xeK9tntl8Gj7FyEhNKeF8JuprZMYeAb34Jqtmi9XRteqnQCzRce2KNRB/dzKEsGnbcqT PScw== X-Gm-Message-State: ALoCoQn+zuMpAqytsifrG/BIXeJ+OBce6mfHQL6M9Gkb//cTcYx8dSpCiGLvzvnKFCZP07gteCiX X-Received: by 10.221.74.131 with SMTP id yw3mr4419879vcb.20.1415426908051; Fri, 07 Nov 2014 22:08:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Fri, 7 Nov 2014 22:08:07 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> From: Justin Uberti Date: Fri, 7 Nov 2014 22:08:07 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11364d9e0f8662050752c298 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PQZ1mkRy-Y0tJgO9lZco5bXY45o Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 06:08:30 -0000 --001a11364d9e0f8662050752c298 Content-Type: text/plain; charset=UTF-8 Yeah, I'm of the same opinion. If you are going to allow tricking of new candidates, you only have two choices: a) ICE never ends, or b) ICE restart But ICE restart invalidates existing candidates, which is a serious issue. Therefore I think continuous nomination is the simplest solution to this problem. On Fri, Nov 7, 2014 at 9:15 PM, Martin Thomson wrote: > On 6 November 2014 16:41, Emil Ivov wrote: > >> A candidate that arrives after that point is not going to > >> change anything. > > > > This is wrong. > > > > Just attach a new ufrag/pwd to your new cand and it can change > everything. > > > There's a marked difference between ICE restart and trickling. > --001a11364d9e0f8662050752c298 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, I'm of the same opinion. If you are going to all= ow tricking of new candidates, you only have two choices:
a) ICE never = ends, or
b) ICE restart

But ICE restart = invalidates existing candidates, which is a serious issue.=C2=A0
=
Therefore I think continuous nomination is the simplest solu= tion to this problem.

On Fri, Nov 7, 2014 at 9:15 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 6 November 2014 16:41, Emil Ivov <emcho@jitsi.org> wrote:
>> A candidate that arrives after that point is not going to
>> change anything.
>
> This is wrong.
>
> Just attach a new ufrag/pwd to your new cand and it can change everyth= ing.


There's a marked difference between ICE restart and trickling.

--001a11364d9e0f8662050752c298-- From nobody Sat Nov 8 01:46:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52621A6F04 for ; Sat, 8 Nov 2014 01:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgFsW-7gCsdO for ; Sat, 8 Nov 2014 01:46:12 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9C51A6F02 for ; Sat, 8 Nov 2014 01:46:11 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-55-545de6619839 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.22.04387.166ED545; Sat, 8 Nov 2014 10:46:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Sat, 8 Nov 2014 10:46:08 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/gAHOIkwAAnwGgD///LfgIAAL06AgAAEdoCAAFddv4AANnYA//+9vaCAAUHmgP//NDkg Date: Sat, 8 Nov 2014 09:46:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4ED6AA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> <545BFAF9.7010301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4EBC1F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4ED6AAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3RjfxWWyIwasZ4hZbpwpZTF3+mMVi xYYDrA7MHn/ff2DyWLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBkrX65jLriznrHi3aIzjA2M HasZuxg5OSQETCReL5/KDGGLSVy4t56ti5GLQ0jgCKPE1tfbmCCcxYwSM46tAurg4GATsJDo /qcN0iAioCbxcNYuVhCbWcBX4uWCL2CDhAXsJVq2zWOEqHGQOPR0IhuEnSfx+XYPO4jNIqAi caX/MBOIzQvU+2NzBzvErhWsEi3LloIlOAUCJe4vegvWwAh03fdTa5gglolL3HoynwniagGJ JXvOQ30gKvHy8T9WCFtJYu3h7SwQ9fkSFyeeY4NYJihxcuYTlgmMorOQjJqFpGwWkrJZQC8z C2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsY gTF4cMtvqx2MB587HmIU4GBU4uE1aI8NEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjD5vP+358chX7cuFDafmTmxsM1dmexwTUPebl0HY/VHTXfPgvE2x qVbrNAzeey4v1jKZ2/Xu3NFpW9ZO9t95Z9UO3lfRpyMYJ81YFzFhtVr76eojl5bO2/BuT+gv pwVe/Ckee+qdbl5XftQr+Wr9ncnxxbdtH4lMylgUHex63izzvPDBgp8mR12VWIozEg21mIuK EwHv6dWRogIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/puxvZaqtMSKeWXONsHPIegQ7PyY Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 09:46:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4ED6AAESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JbiB0aGlzIGNvbnRleHQsIHRoZSBrZXkgZXhjaGFuZ2UgbWVjaGFuaXNtIGlzIGlt bWF0ZXJpYWwuIFRoZSBrZXkgPnBvaW50IGlzIHRoYXQgeW91IGRvbid0IG5lZWQgdG8gZGVtdWx0 aXBsZXggU1JUUCBwYWNrZXRzIGZyb20gb3RoZXIgPnN0dWZmIGFycml2aW5nIG9uIHRoZSBEVExT IGNvbm5lY3Rpb24sIGJlY2F1c2UgdGhvc2UgcGFja2V0cyBhcmVuJ3QgPnNlbnQgb24gdGhlIERU TFMgY29ubmVjdGlvbiAoYW5kIHRoZXJlZm9yZSB0aGUgZGVtdXggaXMgYWxyZWFkeSA+Y292ZXJl ZCBieSA1NzY0KS4NCg0KQ29ycmVjdCwgYW5kIGl04oCZcyBhbHNvIG1lbnRpb25lZCBpbiBCVU5E TEUuDQoNClNvLCBhZ2FpbiwgdGhlIHN0YXRlbWVudCBJIHJlZmVycmVkIHRvIG9ubHkgY292ZXJz IHBhY2tldHMgd2hpY2ggYXJlIERUTFMgZW5jcnlwdGVkLg0KDQrigJxJZiBtdWx0aXBsZSBwcm90 b2NvbHMgYXJlIHRyYW5zcG9ydGVkIG9uIERUTFMsIHRoZXJlIE1VU1QgZXhpc3QgYQ0KICAgICAg ICAgICAgIHNwZWNpZmljYXRpb24gZGVzY3JpYmluZyBhIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnkg ZWFjaCBpbmRpdmlkdWFsDQogICAgICAgICAgICAgcHJvdG9jb2wu4oCdDQoNCkRvIHdlIGUuZy4g YXNzdW1lIHRoYXQgYWxsIERUTFMgZW5jcnlwdGVkIHRyYWZmaWMgd2lsbCBiZSB0cmFuc3BvcnRl ZCBvbiBhIHNpbmdsZSBEVExTIGNvbm5lY3Rpb24/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQoNCk9uIEZyaSwgTm92IDcsIDIwMTQgYXQgMjoxNiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KPk5vLCB0aGUgU1JUUCBwYWNrZXRzIGFyZSBz ZW50IG91dHNpZGUgdGhlIERUTFMgY29ubmVjdGlvbi4NCg0KVGhhdCBpcyB0cnVlLCBidXQgZG9u 4oCZdCB5b3UgY3JlYXRlIGEgRFRMUyBjb25uZWN0aW9uIGp1c3QgYnkgbmVnb3RpYXRpbmcgdGhl IGtleXMgdGhhdCB5b3UgYXJlIGdvaW5nIHRvIHVzZSBmb3IgU1JUUD8NCg0KKEkgZG8gYWdyZWUg dGhhdCDigJxjb25uZWN0aW9u4oCdIGlzIG1pc2xlYWRpbmcuKQ0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQoNCk9uIFRodSwgTm92IDYsIDIwMTQgYXQgNzowMiBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KQUZBSUssIHlvdSB1c2UgYSBEVExTIGNv bm5lY3Rpb24gKEkgYmVsaWV2ZSBEVExTLVNSVFAgdXNlcyBhbm90aGVyIHdvcmQsIHRob3VnaCkg YWxzbyBmb3IgU1JUUC4NCg0KSG93ZXZlciwgdGhlIHRleHQgYWxyZWFkeSBkZXNjcmliZXMgaG93 IHRvIHNlcGFyYXRlIFNSVFAgcGFja2V0cyBmcm9tIERUTFMgcGFja2V0cywgc28gdGhlIHBpZWNl IG9mIHRleHQgSSBicm91Z2h0IHVwIG9ubHkgYXBwbGllcyB0byBEVExTIHBhY2tldHMuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUGF1bCBLeXppdmF0PG1haWx0bzpwa3l6 aXZhdEBhbHVtLm1pdC5lZHU+DQpTZW50OiDigI4wNy/igI4xMS/igI4yMDE0IDAwOjQ5DQpUbzog bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01N VVNJQ10gQlVORExFOiBNZWFuaW5nIG9mICJ0cmFuc3BvcnRlZCBvbiBEVExTIj8NCk9uIDExLzYv MTQgNTozMyBQTSwgScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZToNCj4gMjAxNC0xMS0wNiAyMDo0 NCBHTVQrMDE6MDAgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJl cnRpQGdvb2dsZS5jb20+PjoNCj4+IEkgdGhpbmsgaXQgaXMgY2xlYXIgd2UgYXJlIHRhbGtpbmcg YWJvdXQgdGhlc2UgcHJvdG9jb2xzIGJlaW5nIG11bHRpcGxleGVkDQo+PiBhY3Jvc3MgYSBzaW5n bGUgRFRMUyBjb25uZWN0aW9uIGhlcmUuDQo+DQo+IElNSE8gdGhhdCdzIGNsZWFyIHRvby4gTWF5 IGJlIGl0IHNob3VsZCBhbHNvIGJlIGNsZWFyIHRoYXQgU1JUUCBpcyBub3QNCj4gY2FycmllZCBv biB0b3Agb2YgYSBEVExTIGNvbm5lY3Rpb24sIGJ1dCBvbiB0b3Agb2YgYSAiY2hhbm5lbCINCj4g ZXN0YWJsaXNoZWQgdmlhIGEgRFRMUyBoYW5kc2hha2UuDQoNCklJVUMgKGR1YmlvdXMpLCBTUlRQ IGlzIGNhcnJpZWQgZGlyZWN0bHkgb24gVURQLCBtdWx0aXBsZXhlZCB3aXRoIERUTFMNCm1lc3Nh Z2VzLiBTUlRQIHVzZXMgY2VydGFpbiBEVExTIG1lc3NhZ2VzIHRvIG5lZ290aWF0ZSB0aGUga2V5 cywgc28NCnBlcmhhcHMgdGhlIGtleS1uZWdvdGlhdGlvbiBwYXJ0IG9mIFNSVFAgY2FuIGJlIGNv bnNpZGVyZWQgdG8gYmUgd2l0aGluDQpzb21lIGFzcGVjdCBvZiBEVExTLiBUaGF0IG1pZ2h0IG5v dCBiZSBwYXJ0IG9mIHRoZSBEVExTICpjb25uZWN0aW9uKiAtIEkNCndvdWxkIHRoaW5rIHRoYXQg aXMgcmVzZXJ2ZWQgZm9yIHRoZSBEVExTIHBheWxvYWQgcGFja2V0cy4NCg0KQ2xlYXJseSB0aGUg bGF5ZXJpbmcgaGVyZSBpcyB2ZXJ5IHdlaXJkLg0KDQogICAgICAgIFRoYW5rcywNCiAgICAgICAg UGF1bA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxp bmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D4ED6AAESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+SW4gdGhpcyBjb250 ZXh0LCB0aGUga2V5IGV4Y2hhbmdlIG1lY2hhbmlzbSBpcyBpbW1hdGVyaWFsLiBUaGUga2V5DQo8 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5wb2ludCBpcyB0aGF0IHlvdSBk b24ndCBuZWVkIHRvIGRlbXVsdGlwbGV4IFNSVFAgcGFja2V0cyBmcm9tIG90aGVyDQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5zdHVmZiBhcnJpdmluZyBvbiB0aGUgRFRM UyBjb25uZWN0aW9uLCBiZWNhdXNlIHRob3NlIHBhY2tldHMgYXJlbid0DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5zZW50IG9uIHRoZSBEVExTIGNvbm5lY3Rpb24gKGFu ZCB0aGVyZWZvcmUgdGhlIGRlbXV4IGlzIGFscmVhZHkNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPmNvdmVyZWQgYnkgNTc2NCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNvcnJlY3QsIGFuZCBpdOKAmXMgYWxzbyBtZW50aW9u ZWQgaW4gQlVORExFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ U28sIGFnYWluLCB0aGUgc3RhdGVtZW50IEkgcmVmZXJyZWQgdG8gb25seSBjb3ZlcnMgcGFja2V0 cyB3aGljaCBhcmUgRFRMUyBlbmNyeXB0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJxJZiBtdWx0aXBsZSBw cm90b2NvbHMgYXJlIHRyYW5zcG9ydGVkIG9uIERUTFMsIHRoZXJlIE1VU1QgZXhpc3QgYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbiBkZXNjcmliaW5nIGEg bWVjaGFuaXNtIGZvciBpZGVudGlmeSBlYWNoIGluZGl2aWR1YWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHByb3RvY29sLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+RG8gd2UgZS5nLiBhc3N1bWUgdGhhdCBhbGwgRFRMUyBlbmNyeXB0ZWQg dHJhZmZpYyB3aWxsIGJlIHRyYW5zcG9ydGVkIG9uIGEgc2luZ2xlIERUTFMgY29ubmVjdGlvbj88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBOb3YgNywgMjAxNCBhdCAyOjE2IEFN LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jmd0Ozwvc3Bhbj5ObywgdGhlIFNSVFAgcGFja2V0cyBhcmUgc2VudCBvdXRzaWRlIHRoZSBEVExT IGNvbm5lY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGF0IGlzIHRydWUsIGJ1dCBkb27igJl0IHlvdSBjcmVhdGUgYSBEVExTIGNvbm5l Y3Rpb24ganVzdCBieSBuZWdvdGlhdGluZyB0aGUga2V5cyB0aGF0IHlvdSBhcmUgZ29pbmcNCiB0 byB1c2UgZm9yIFNSVFA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+KEkgZG8gYWdyZWUgdGhhdCDigJxjb25uZWN0aW9u4oCdIGlzIG1pc2xlYWRpbmcuKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBUaHUsIE5vdiA2LCAyMDE0IGF0IDc6MDIgUE0sIENocmlzdGVy IEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGksPGJyPg0KPGJyPg0KQUZBSUssIHlvdSB1 c2UgYSBEVExTIGNvbm5lY3Rpb24gKEkgYmVsaWV2ZSBEVExTLVNSVFAgdXNlcyBhbm90aGVyIHdv cmQsIHRob3VnaCkgYWxzbyBmb3IgU1JUUC4NCjxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSB0ZXh0 IGFscmVhZHkgZGVzY3JpYmVzIGhvdyB0byBzZXBhcmF0ZSBTUlRQIHBhY2tldHMgZnJvbSBEVExT IHBhY2tldHMsIHNvIHRoZSBwaWVjZSBvZiB0ZXh0IEkgYnJvdWdodCB1cCBvbmx5IGFwcGxpZXMg dG8gRFRMUyBwYWNrZXRzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8 YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjMiIHdpZHRoPSIx MDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206DQo8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVt Lm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBhdWwgS3l6aXZhdDwv c3Bhbj48L2E+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW50OiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+4oCOMDcv4oCOMTEv4oCOMjAxNCAwMDo0OTwvc3Bhbj48YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlRvOiA8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm1tdXNpY0BpZXRmLm9yZzwvc3Bh bj48L2E+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5SZTogW01NVVNJQ10gQlVORExFOiBNZWFuaW5nIG9mICZxdW90O3RyYW5z cG9ydGVkIG9uIERUTFMmcXVvdDs/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIDExLzYvMTQgNTozMyBQTSwgScOxYWtpIEJheiBDYXN0 aWxsbyB3cm90ZTo8YnI+DQomZ3Q7IDIwMTQtMTEtMDYgMjA6NDQgR01UJiM0MzswMTowMCBKdXN0 aW4gVWJlcnRpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5qdWJlcnRpQGdv b2dsZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Ojxi cj4NCiZndDsmZ3Q7IEkgdGhpbmsgaXQgaXMgY2xlYXIgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhl c2UgcHJvdG9jb2xzIGJlaW5nIG11bHRpcGxleGVkPGJyPg0KJmd0OyZndDsgYWNyb3NzIGEgc2lu Z2xlIERUTFMgY29ubmVjdGlvbiBoZXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IElNSE8gdGhhdCdz IGNsZWFyIHRvby4gTWF5IGJlIGl0IHNob3VsZCBhbHNvIGJlIGNsZWFyIHRoYXQgU1JUUCBpcyBu b3Q8YnI+DQomZ3Q7IGNhcnJpZWQgb24gdG9wIG9mIGEgRFRMUyBjb25uZWN0aW9uLCBidXQgb24g dG9wIG9mIGEgJnF1b3Q7Y2hhbm5lbCZxdW90Ozxicj4NCiZndDsgZXN0YWJsaXNoZWQgdmlhIGEg RFRMUyBoYW5kc2hha2UuPGJyPg0KPGJyPg0KSUlVQyAoZHViaW91cyksIFNSVFAgaXMgY2Fycmll ZCBkaXJlY3RseSBvbiBVRFAsIG11bHRpcGxleGVkIHdpdGggRFRMUyA8YnI+DQptZXNzYWdlcy4g U1JUUCB1c2VzIGNlcnRhaW4gRFRMUyBtZXNzYWdlcyB0byBuZWdvdGlhdGUgdGhlIGtleXMsIHNv IDxicj4NCnBlcmhhcHMgdGhlIGtleS1uZWdvdGlhdGlvbiBwYXJ0IG9mIFNSVFAgY2FuIGJlIGNv bnNpZGVyZWQgdG8gYmUgd2l0aGluIDxicj4NCnNvbWUgYXNwZWN0IG9mIERUTFMuIFRoYXQgbWln aHQgbm90IGJlIHBhcnQgb2YgdGhlIERUTFMgKmNvbm5lY3Rpb24qIC0gSSA8YnI+DQp3b3VsZCB0 aGluayB0aGF0IGlzIHJlc2VydmVkIGZvciB0aGUgRFRMUyBwYXlsb2FkIHBhY2tldHMuPGJyPg0K PGJyPg0KQ2xlYXJseSB0aGUgbGF5ZXJpbmcgaGVyZSBpcyB2ZXJ5IHdlaXJkLjxicj4NCjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1t dXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5tbXVz aWNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+ DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D4ED6AAESESSMB209erics_-- From nobody Sat Nov 8 09:35:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359391A1B88 for ; Sat, 8 Nov 2014 09:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.146 X-Spam-Level: X-Spam-Status: No, score=-13.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbBxpo21-s5M for ; Sat, 8 Nov 2014 09:35:01 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B761A1B66 for ; Sat, 8 Nov 2014 09:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9170; q=dns/txt; s=iport; t=1415468100; x=1416677700; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bKrexJyjdmE0zWAanf+Vl5Ldy8FezUtbR91guj7wHDU=; b=FO0StLlUKBHxtW+TkukHrytWRLxY4VOlTbUcItWk7ubJh/j3McZBfYAL /ClUN0Shk9PnhdLX0yyq5mjRmzG0PnRs/1+c4gMHqSFTZTvkFEVv/zMBN O6ioYRLsB9rybbhM+39oPKg8Up2UIVAtSXlP4IVYaly7ROfgiWwwVNbYf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FACFTXlStJV2R/2dsb2JhbABWBYMOVFmDBshah00CgRsWAQEBAQF9hAIBAQEDASNWBQsJAg4KAgIjAwICISURBhOILAMJCQ2bUpxfjkcNhlkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEtiUiDYoFPKg4zB4J3NoEeBYRqMwKGX4p9hEpDghKBMoZFhzNCgmeECYQaHC+BBgIFGQaBHwEBAQ X-IronPort-AV: E=Sophos;i="5.07,341,1413244800"; d="scan'208";a="94703551" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 08 Nov 2014 17:34:59 +0000 Received: from [10.21.70.241] ([10.21.70.241]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sA8HYtUM008651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Nov 2014 17:34:58 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <545D6F6A.3020003@jitsi.org> Date: Fri, 7 Nov 2014 17:29:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <47B152C2-ED0C-4EB1-A15E-C81260D94D0F@cisco.com> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ApYvA0YgSuj-LDzxelAey0PV_n8 Cc: Jonathan Lennox , =?utf-8?Q?Ari_Ker=C3=A4nen?= , mmusic Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 17:35:03 -0000 On Nov 7, 2014, at 5:18 PM, Emil Ivov wrote: >=20 >=20 > On 8.11.14, 1:35, =F0=9F=94=93Dan Wing wrote: >>=20 >> On Nov 7, 2014, at 2:41 PM, Emil Ivov wrote: >>=20 >>> Hey all, >>>=20 >>> In the context of the ongoing discussion on two potential ICE >>> improvements, I wanted to spin off this thread on the idea of >>> continuous nomination. >>>=20 >>> So first of all, as I already mentioned in Toronto, I am very much >>> in favour of a mechanism that would allow ICE processing to yield >>> more than a single nominated pair. Back then the discussion was >>> about MPRTP but there would likely be other use cases as well. >>>=20 >>> In that context, it seems perfectly valid to me that nomination >>> among all validated pairs can occur multiple times within a >>> session. Again, I find this to be a very valid and useful feature. >>>=20 >>> I am however bothered by the "ICE never ends" suggestions made by >>> the document below and more specifically by the fact that >>> candidates may continue to be trickled forever. I think that's both >>> unnecessary and a problem. >>>=20 >>> It is a problem because >>>=20 >>> a) being able to know when the remote agent is done trickling is >>> one of the very reasons we started the work on trickle ICE. This >>> allows to quickly and deterministically detect and declare failure >>> when it occurs. Not having this would require implementations to >>> use magic timers of the sort: "Surely if I couldn't connect in .. >>> say 20 seconds ... then the situation must be hopeless ... I >>> think". >>>=20 >>> b) being able to continuously trickle new candidates forever and >>> ever means that they would have to be paired with all of the peer's >>> *initial* candidates. This means that ICE agents would have to >>> maintain all gathered candidates even when they are not working for >>> them. >>>=20 >>> More importantly however, the whole concept is likely unnecessary >>> because an ICE restart only sounds scary, and it doesn't actually >>> need to be ;). >>>=20 >>> A restart is non-disruptive as media can keep flowing while we are >>> doing ICE processing. >>>=20 >>> 5245 already supports pair reuse and we can easily port that >>> concept to multipath ICE. >>>=20 >>> The one thing that we might be missing today is the syntax to allow >>> for a restart without using offer/answer. >>=20 >> For MICE and some other use cases, I agree that need to signal (in >> SDP) is the 'scary' part of an ICE restart. >>=20 >>> This would be trivial to resolve: we just need to allow trickling a >>> restart command. Sending your ufrag and pwd in a trickle update >>> should do the job. >>=20 >> That is a nice approach -- move the 'ICE restart' signaling to an >> (existing, working) media path. >=20 > I was actually thinking of the signalling path. So for SIP this would = be a SIP INFO request with the ufrag/pwd as the sole content. A couple = of a=3D lines would do it for WebRTC. >=20 > I am slightly uncomfortable about doing it on the media path because = it requires you to make the assumption that one of your media paths is = certain to survive any sort of mobility event. I am slightly uncomfortable using signaling path for same reason, and = signaling path takes longer to start up (TCP, TLS). Even if we make the = signaling path start up faster with all the spiffy new TLS 0-RTT or QUIC = or whatever, the signaling path should remain slower because a server is = involved and the path isn't as straight as the peer-to-peer path. = That's why MICE does not require to first send a=3Dcandidate over the = signaling path. > Even if you keep your TURN connection open for that purpose, how do = you know that your new location wouldn't be one where TURN-TCP is the = only way to get out of the local network? >=20 > Or what if you don't even have a TURN server? You're right, we don't know, of course. But same risk exists of the signaling path on a mobility event. > You signalling channel would be a safer bet, but more importantly, = you'd likely want to tear down your call if it didn't. =46rom my perspective, thinking about MICE, I want to make the mobility = event (voice/video) successful. If signaling takes a little while to = get re-established, *shrug*, I don't care. =20 >=20 >>> To put that into perspective, let's look at the following use >>> cases: >>>=20 >>> I. You have used the new multipath ICE and you have successfully >>> discovered a couple of working routes: one going through your wi-fi >>> interface and another one going through 4G. During your session, >>> you move closer to your Wi-Fi access point so you detect that RTT >>> and packet loss start looking better on your Wi-Fi interface. >>>=20 >>> You decide to switch from 4G to Wi-Fi. >>>=20 >>> *No ICE restart* would be necessary here because no new paths would >>> need to negotiated. This would be a native feature of the new >>> multipath ICE. >>>=20 >>> II. You start on Wi-Fi in the presence of a 4G interface that you >>> keep for backup. Multipath ICE comes up with pairs over both your >>> interfaces. I don't believe this requires an ICE restart either. >>> You just switch between pre-existing path and one of them expires >>> as pointed out in Justin's document below >>>=20 >>> III. You setup a session at a point of time where 4G is your only >>> working interface. Your Wi-Fi interface then comes up and you want >>> to include it in the game. Here's what you do: >>>=20 >>> a) You gather host, srflx and relay candidates for the new >>> interface. b) You gather candidates on the old interface that >>> haven't been valid before but that are worth trying again (this is >>> non-essential) >>>=20 >>> d) you then trickle a new ufrag and pwd to trigger a restart. >>=20 >> If that trickling happens over the SIP/WebRTC/XMPP signaling channel, >> MICE would prefer not requiring that SDP signaling step or to at >> least allow it to be done later. >=20 > Well, if you had multipath ICE, you would be able to switch your media = over to TURN (this wouldn't require any signalling) if that still works = and then do the non-disruptive restart after that to discover other = paths. >=20 > Would this work? It would help. But multipath ICE requires I have that connection to = TURN set up prior to the mobility event, right? If I'm right, that is = not desirable. -d >=20 > Emil >=20 >>=20 >> -d >>=20 >>=20 >>> b) you batch trickle all currently working candidates that you'd >>> wish to preserve (you can omit any candidates you no longer wish to >>> use, for whatever reason). c) you trickle the newly gathered >>> candidates. >>>=20 >>> The remote party, your peer, would then do the following >>>=20 >>> a) Gather all candidates that didn't work before but that deserve a >>> second chance. This time *this is essential*. SRFLX candiates on >>> your peer might not have worked with your 4G connection but they >>> have every chance of working this time. There are a number of other >>> scenarios where candidates would be worth retrying. >>>=20 >>> b) Your peer would then trickle back to you all the working >>> candidates it wishes to preserve (as long as they are still valid) >>> c) It trickles all candidates it gathered for the occasion, that it >>> wishes to retry. >>>=20 >>> Connectivity checks then proceed as usual. It might be worth paying >>> special attention to the in-use candidates. Implementations might >>> want to either confirm that data is still flowing there, or start >>> the checks with them. This would determine how urgently ICE >>> processing needs to yield results and it may imply changes in >>> nomination strategies. >>>=20 >>> Thoughts? >>>=20 >>> Emil >>>=20 >>>=20 >>> On 7.11.14, 0:44, Justin Uberti wrote: >>>> Agreed. >>>>=20 >>>> I wrote up a slightly more fleshed-out proposal at >>>> = https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8= bk-Xw/edit >>>>=20 >>>>=20 >>>>=20 > On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson = >>> > wrote: >>>>=20 >>>> On 6 November 2014 13:47, Justin Uberti >>> > wrote: >>>>> I looked into how MICE works; I think that continuous >>>>> nomination might be able to effectively support that use case, >>>>> as well as the case that Brandon was interested in, namely >>>>> picking the route that uses the best set of TURN servers. >>>>=20 >>>>=20 >>>> I've always believe that continuous ICE operation was the only >>>> way to ensure proper reliability. Multipath or otherwise. You >>>> just need to work out when it is safe to completely stop on any >>>> given pair, assuming that you don't want to be testing the >>>> complete mesh all the time. But you also might want multiple >>>> paths available, or maybe backup paths. >>>>=20 >>>>=20 >>>=20 >>> -- https://jitsi.org >>=20 >>=20 >=20 > --=20 > https://jitsi.org From nobody Sat Nov 8 17:43:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808E81A00F2 for ; Sat, 8 Nov 2014 17:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkgvXxtRSKqu for ; Sat, 8 Nov 2014 17:43:11 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925E01A00E9 for ; Sat, 8 Nov 2014 17:43:11 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x13so6312157wgg.36 for ; Sat, 08 Nov 2014 17:43:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0kuDiv5DQhdJfnj4jSbCPlfCbv9HAZJ2/x0ckWVnDHo=; b=myG2gAh4G3xddYLbEZYj8FfwhKl9Jc4mx+wBq3Nbiu6ciT6+dfJ5K8NPMJYfYrZNQn CsFJS2LIsxwwpbub5dzh1WVSSFIsf1yK2vGKWwj8A4869NHmD5dWKpdOrFvNv9GFgZHK c7L1bpOqM0QXQR5ZMDH3JfTMHTjNngzDo8n6Q+LTv3gaB1H5uZcHu1I38RJU2yCxnU1O gS16UsnqnOsqDwCrnwJSP6GVC5vysuPOMl5YxT5cO/AGwixc30ObXbYB3i8+1FjeiovM sZxoEl7QdTRND9U7ZrrHp2m/pdKijW08u214DxAQiE0vVbXY+ZNNzmX6sn09TMM2mLA6 NISw== X-Gm-Message-State: ALoCoQlWefcitNOtfuSHOXpqlr/tHs4Q93Z3wZ1NKBUzuSEVTylJXWRRXil+yTi1qohVr9kEkG1Q X-Received: by 10.180.91.227 with SMTP id ch3mr18041087wib.17.1415497390138; Sat, 08 Nov 2014 17:43:10 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id ll2sm4626220wjb.11.2014.11.08.17.43.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Nov 2014 17:43:08 -0800 (PST) Message-ID: <545EC6AA.2070505@jitsi.org> Date: Sun, 09 Nov 2014 02:43:06 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Nu7CRt9XqVh6jJNwX3EoHuDDRWE Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 01:43:13 -0000 On 8.11.14, 3:03, Justin Uberti wrote: > It's getting hard to follow the idea here, so I suggest you write it up > in a document and then we can try to find some time in Hono to sit down > and discuss the pros/cons of continuous nomination and your approach. Indeed, this is a good idea. I have tried to describe all this here: https://github.com/emcho/ice-updates/blob/master/draft-ivov-mmusic-ice-updates-00.txt -- https://jitsi.org From nobody Sat Nov 8 17:43:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD30A1A00E6 for ; Sat, 8 Nov 2014 17:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RioL7hSYksHt for ; Sat, 8 Nov 2014 17:43:55 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC051A007F for ; Sat, 8 Nov 2014 17:43:55 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id n3so7419363wiv.4 for ; Sat, 08 Nov 2014 17:43:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FHudSUkwzGLsVyT16ClWPkJS64R4caoZVC03LzYJyRU=; b=NHxkjjrq2jg+v8OHlKyIxsDLvK/liobrXsgYKTLnrS4uU1fzzFfoa6SHwnwaeGlrPf PilD3w0JBcMh0fxN/z/roHNZQ4dXE7OLRZpcrbJ+dI/AgMYwAPOk9qFEP0KMUKFIromI C43akNYW7JZy+zEBXAxo1dOggaba0Nqn074f+p7b/IQTTG1d6q9g8AnGLykCR0xw4l2c kbGvMylTBi2HECDTiJB97WZmnaTW3yde82S3mz7nNGuZJh1+/4/d42RskC8VnhgROH7M 1guYuECOHUcE4IQpT8tvkSDCBX8tL6eon+R3i+TA1RGEojuddyYBe64F3GCZRhHgO92F Hm2A== X-Gm-Message-State: ALoCoQkRIPksTdFZJ2LQmZE+E1WWBltNYxy/kEwmwUcWtee1amgccW44PUbDNYIjjPLb/rjspitx X-Received: by 10.194.242.4 with SMTP id wm4mr29361707wjc.61.1415497433856; Sat, 08 Nov 2014 17:43:53 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id s8sm17375169wjx.9.2014.11.08.17.43.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Nov 2014 17:43:52 -0800 (PST) Message-ID: <545EC6D3.6030602@jitsi.org> Date: Sun, 09 Nov 2014 02:43:47 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FCSPXyBdOCLohOIwD9n-_T9yksc Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 01:43:56 -0000 On 8.11.14, 6:15, Martin Thomson wrote: > On 6 November 2014 16:41, Emil Ivov wrote: >>> A candidate that arrives after that point is not going to >>> change anything. >> >> This is wrong. >> >> Just attach a new ufrag/pwd to your new cand and it can change everything. > > There's a marked difference between ICE restart and trickling. Trickle ICE is one of the components that helps alleviate potential inconveniences in an ICE restart. Emil -- https://jitsi.org From nobody Sat Nov 8 17:50:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB51A008F for ; Sat, 8 Nov 2014 17:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97c_3ZItUI_k for ; Sat, 8 Nov 2014 17:50:27 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BD61A0089 for ; Sat, 8 Nov 2014 17:50:27 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so6337460wgg.37 for ; Sat, 08 Nov 2014 17:50:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fEVP8AdOF8D19ceD+vQoH1ZONcvhXW5k8XQYnHSn3sc=; b=ZvNBSoQrwtQd7uQqa9B+fJKbhPBr+ESOPpp42BKoc4yiDUsE6STaot2GhDMQvjTmu0 RnM2mkFlsyx5jDHgD98EesZKESC8nHmnG492hVklHKoSmRm2XFu8PsUqFarhMwjzej1Y BnTAYlHaELKq+v2cWZnAvRcPwLMwVzWkRmzcenFE7YZB7R/+p3Kd9kMHs/1R3tfAnil3 uTa5xvs974iH9Y65l24Y/Sy7e5dTQwBtrZgQqkxTHEzWjcJDfubySBhvGTFlRojzMddu zrE2+MoAqQbU0PnGzAHAU7mYs5EwoLtCzRTanCtNhHwMc8t7ZUI3XsALorKsmq+uXfYL ZcHw== X-Gm-Message-State: ALoCoQmHkCtQhuBDcoEzPdDTQO7wkSVuI0EGYEeLD7OSDRzRwRm+SAYHuimwcsSUFSkRXvldQvLf X-Received: by 10.194.206.72 with SMTP id lm8mr30820324wjc.70.1415497825930; Sat, 08 Nov 2014 17:50:25 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id ua8sm17391288wjc.7.2014.11.08.17.50.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Nov 2014 17:50:24 -0800 (PST) Message-ID: <545EC85E.8000208@jitsi.org> Date: Sun, 09 Nov 2014 02:50:22 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti , Martin Thomson References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sqd-I1lgfngrWCuIFMoDBzOPWeU Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 01:50:29 -0000 On 8.11.14, 7:08, Justin Uberti wrote: > Yeah, I'm of the same opinion. If you are going to allow tricking of new > candidates, you only have two choices: > a) ICE never ends, or > b) ICE restart > > But ICE restart invalidates existing candidates, Existing candidates can very well be part of the new ICE negotiation and if they are confirmed as "still working", no invalidation needs to occur. 5245 even already mentions this: Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1. > which is a serious issue. > > Therefore I think continuous nomination is the simplest solution to this > problem. Continuous nomination has at least two serious problems: a) we lose the possibility to clearly detect failures and we need to resort to magic timers b) it is no longer clear when unused candidates (srflx and relay) can be released. We could obivously work on resolving the above issues by preserving the end-of-candidates indication and then allowing new candidates to still arrive after it. We could also work on clearing out a few other points, like for example, how receiving a trickled candidate means one needs to potentially re-gather and re-trickle and re-check local candidates. While this is certainly a possibility ... it is likely to simply take us to something very similar to ICE restarts. Potentially even the exact same thing, only triggered with something other and a ufrag/pwd update. :) So, it might be more productive to just rename "ICE restarts" to something that scares us less and see if and how we need to address any actual issues there. Emil -- https://jitsi.org From nobody Sat Nov 8 21:53:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBE81A0A85 for ; Sat, 8 Nov 2014 21:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JnvJ-LBEu8R for ; Sat, 8 Nov 2014 21:53:29 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00391A0A6A for ; Sat, 8 Nov 2014 21:53:29 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id hy4so2942735vcb.6 for ; Sat, 08 Nov 2014 21:53:28 -0800 (PST) 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=k2fhzS0rmmfg5k8RRQiEhZ463hKF6rcMntI+INwCEvc=; b=EngjMhE1Hhh88LfNF1B/fto/aY6KEBgNHIqr6T15AcXihVzhl6LDy40XNaLCdwlmzB AAfw7nN4+2RJBoy7eP48/+9jTMcY7dq+ZGueMmvzCs3IA8P6SGX4uXqx0rilonotVkOH Sbdn2sc7Xy1VX4fGc6Ijfu0ziqdFux8VZ/0YJH4XjUU3hBXpPErjgX0sjv9j3qyBbHgj C8zlRTZChhePkQURxbSQLzJrcOAm1ekyMnS/Busa1Z+8zKQux7CA1Dfe+XeeOMsk2j/F Mpv1Dd2xdwo74LhWpmDHqntkNNszMoloUJgVifmSzubsoevt1KBc2d4SHYO/5AxDxgZT p1DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k2fhzS0rmmfg5k8RRQiEhZ463hKF6rcMntI+INwCEvc=; b=CgQrKM/l4oj4V2aW8boWVU1dmuRZKy6yUHWfjA4UDFubB0Lt3A2OjCzOw3wgtAoVVD V8pKzchDsJ73WNWvy2rNCWCa0Fz8jsEdLdshlYMORNQVJKhnnRCHsQqBxSuzV/Dh0rBH u0hHmgPeZKlu3S0xulpv5NNQAviRkY7Pjekabt7mo49mFa17kgjzPIt2liAh9OeHxek6 vrnZ2ycv1owcN20om1DAjrU5uWK3uYyoDscetnI0uOkdIsMREOvZphhrsgw6nPzr+9YK eAbX6BmH/pfk3cFyQ3aXHTNRdkfEfqWC6JkX5R5QzHr9cMfwIm2n5NKayALAplcrtj7o wA7g== X-Gm-Message-State: ALoCoQlt8m+VA1rz8FZ8OinlQdcsxZfl/fuBOZ/zAlDIcFdJ/lZb5mNHJcp4zxNfDToiJXON7utS X-Received: by 10.52.146.100 with SMTP id tb4mr12624789vdb.23.1415512408550; Sat, 08 Nov 2014 21:53:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Sat, 8 Nov 2014 21:53:07 -0800 (PST) In-Reply-To: <545EC85E.8000208@jitsi.org> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> From: Justin Uberti Date: Sat, 8 Nov 2014 21:53:07 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=bcaec51ba22149881c050766aa90 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/NDTNDHtJM_XoW-QBnIdqLWFpWlw Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 05:53:33 -0000 --bcaec51ba22149881c050766aa90 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 8, 2014 at 5:50 PM, Emil Ivov wrote: > > > On 8.11.14, 7:08, Justin Uberti wrote: > >> Yeah, I'm of the same opinion. If you are going to allow tricking of new >> candidates, you only have two choices: >> a) ICE never ends, or >> b) ICE restart >> >> But ICE restart invalidates existing candidates, >> > > Existing candidates can very well be part of the new ICE negotiation and > if they are confirmed as "still working", no invalidation needs to occur. > > 5245 even already mentions this: > Consequently, the set of candidates MAY include some, > none, or all of the previous candidates for that stream and MAY > include a totally new set of candidates gathered as described in > Section 4.1.1. > > > > which is a serious issue. >> >> Therefore I think continuous nomination is the simplest solution to this >> problem. >> > > Continuous nomination has at least two serious problems: > > a) we lose the possibility to clearly detect failures and we need to > resort to magic timers > It's timers one way or another (e.g. how do you know when to give up on retransmitting ICE checks?). I don't think this is a salient point. > b) it is no longer clear when unused candidates (srflx and relay) can be > released. > This is explicitly discussed in my proposal. > > We could obivously work on resolving the above issues by preserving the > end-of-candidates indication and then allowing new candidates to still > arrive after it. We could also work on clearing out a few other points, > like for example, how receiving a trickled candidate means one needs to > potentially re-gather and re-trickle and re-check local candidates. > > While this is certainly a possibility ... it is likely to simply take us > to something very similar to ICE restarts. Potentially even the exact same > thing, only triggered with something other and a ufrag/pwd update. :) > > So, it might be more productive to just rename "ICE restarts" to something > that scares us less and see if and how we need to address any actual issues > there. > > Emil > > > -- > https://jitsi.org > --bcaec51ba22149881c050766aa90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 8, 2014 at 5:50 PM, Emil Ivov <emcho@jitsi.org> wrote:


On 8.11.14, 7:08, Justin Uberti wrote:
Yeah, I'm of the same opinion. If you are going to allow tricking of ne= w
candidates, you only have two choices:
a) ICE never ends, or
b) ICE restart

But ICE restart invalidates existing candidates,

 Existing candidates can very well be part of the new ICE negotiation and if= they are confirmed as "still working", no invalidation needs to = occur.

5245 even already mentions this:
=C2=A0 =C2=A0Consequently, the set of candidates MAY include some,
=C2=A0 =C2=A0none, or all of the previous candidates for that stream and MA= Y
=C2=A0 =C2=A0include a totally new set of candidates gathered as described = in
=C2=A0 =C2=A0Section 4.1.1.



which is a serious issue.

Therefore I think continuous nomination is the simplest solution to this problem.

 Continuous nomination has at least two serious problems:

a) we lose the possibility to clearly detect failures and we need to resort= to magic timers

It's timers one wa= y or another (e.g. how do you know when to give up on retransmitting ICE ch= ecks?). I don't think this is a salient point.=C2=A0
=C2=A0
b) it is no longer clear when unused can= didates (srflx and relay) can be released.

<= div>This is explicitly discussed in my proposal.=C2=A0

We could obivously work on resolving the above issues by preserving the end= -of-candidates indication and then allowing new candidates to still arrive = after it. We could also work on clearing out a few other points, like for e= xample, how receiving a trickled candidate means one needs to potentially r= e-gather and re-trickle and re-check local candidates.

While this is certainly a possibility ... it is likely to simply take us to= something very similar to ICE restarts. Potentially even the exact same th= ing, only triggered with something other and a ufrag/pwd update. :)

So, it might be more productive to just rename "ICE restarts" to = something that scares us less and see if and how we need to address any act= ual issues there.

Emil


--
https://jitsi.org

--bcaec51ba22149881c050766aa90-- From nobody Sun Nov 9 06:13:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2251A1AC2 for ; Sun, 9 Nov 2014 06:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFgIW4jt8hzm for ; Sun, 9 Nov 2014 06:13:00 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF421A1ABE for ; Sun, 9 Nov 2014 06:12:59 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so6963230wgh.12 for ; Sun, 09 Nov 2014 06:12:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nabnKaExpwAL5GpQyONGBmn6KLa9Moi9+lpgdxv+6Ho=; b=GDhOVgjLdHpmDATLBCcalEp15v5iJsR9weqZs02OOIqA6Pv2ko0QkEVxgNMWsmTE7v YfhVz00aOveKUmm8Ze4w+gciYn2sNtvd3heMzlIJPbqCcXNNOobT2PGSTBMteiNbxR89 U+U4mlteHecvYHf3Rq7y1Bfsthn/hW9wVyS/p6xJzDmOb4UfVI4VE7XX6hVR+xmPjrS/ +eX+IqqcaHGlTLMSFUsor10n7TLWyQDOAz7Vmg7RgQNewfLk4tc1gP+GtYw+ULufwdUE hjVJ7fIbjKcKX9FwwPN33MjoGgipbjG2qN+CN8yxKp4VH9risGf9Uc27bGRrlcIjYxAh Z7yg== X-Gm-Message-State: ALoCoQlkjo8J4IFQDA78hPSYmss20LFl39XrZYq0jnnOX3XltWd+hAdydL30XKrwd62ETUVtS4az X-Received: by 10.180.100.129 with SMTP id ey1mr22858328wib.28.1415542378364; Sun, 09 Nov 2014 06:12:58 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id jw2sm9534656wid.3.2014.11.09.06.12.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 06:12:57 -0800 (PST) Message-ID: <545F7667.9000700@jitsi.org> Date: Sun, 09 Nov 2014 15:12:55 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti References: <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f56GTtGmyC0ubmqoCGnDjjpE3UE Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 14:13:02 -0000 On 9.11.14, 6:53, Justin Uberti wrote: > > > On Sat, Nov 8, 2014 at 5:50 PM, Emil Ivov > wrote: > > > > On 8.11.14, 7:08, Justin Uberti wrote: > > Yeah, I'm of the same opinion. If you are going to allow > tricking of new > candidates, you only have two choices: > a) ICE never ends, or > b) ICE restart > > But ICE restart invalidates existing candidates, > > > Existing candidates can very well be part of the new ICE negotiation > and if they are confirmed as "still working", no invalidation needs > to occur. > > 5245 even already mentions this: > Consequently, the set of candidates MAY include some, > none, or all of the previous candidates for that stream and MAY > include a totally new set of candidates gathered as described in > Section 4.1.1. > > > > which is a serious issue. > > Therefore I think continuous nomination is the simplest solution > to this > problem. > > > Continuous nomination has at least two serious problems: > > a) we lose the possibility to clearly detect failures and we need to > resort to magic timers > > > It's timers one way or another (e.g. how do you know when to give up on > retransmitting ICE checks?). If you don't define a clear end of trickling, then continuous nomination would require an extra layer of timers, that would actually need to be very dependent on usage scenarios. This is unnecessary. So, yes, while there will always be timers somewhere in the stack this is in no way an excuse to keep piling them up. > I don't think this is a salient point. > > b) it is no longer clear when unused candidates (srflx and relay) > can be released. > > This is explicitly discussed in my proposal. I don't think it is. Your proposal talks about pruning pairs you no longer wish to use. That's a strategy decision that mostly belongs to the implementation and in that way having the option is certainly useful. However, your proposal says nothing about the connectivity decision: when can I release the ports on the interfaces that I am not using? When can I stop refreshing server-reflexive candidates? When do I drop relay candidates that haven't been used? I assume the answer would be: when timer X fires ... ... and obviously you should reallocate all of these again later, when your peer enters a Wi-Fi network and starts trickling the new candidates. You would need to go over all the interfaces and relays that you released and claim them again. So the irony is, that at the end of the day, even with continuous nomination you would still need two modes of operation: one where you are actively looking for possible routes/paths and another where you are operating and using a set of pairs/paths that have been validated. In other words you would have ICE restarts in all but name. Emil > We could obivously work on resolving the above issues by preserving > the end-of-candidates indication and then allowing new candidates to > still arrive after it. We could also work on clearing out a few > other points, like for example, how receiving a trickled candidate > means one needs to potentially re-gather and re-trickle and re-check > local candidates. > > While this is certainly a possibility ... it is likely to simply > take us to something very similar to ICE restarts. Potentially even > the exact same thing, only triggered with something other and a > ufrag/pwd update. :) > > So, it might be more productive to just rename "ICE restarts" to > something that scares us less and see if and how we need to address > any actual issues there. > > Emil > > > -- > https://jitsi.org > > -- https://jitsi.org From nobody Sun Nov 9 11:11:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451B31A6F44 for ; Sun, 9 Nov 2014 11:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjbeSlF1o_IU for ; Sun, 9 Nov 2014 11:11:22 -0800 (PST) Received: from BLU004-OMC1S13.hotmail.com (blu004-omc1s13.hotmail.com [65.55.116.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8FB1A6F38 for ; Sun, 9 Nov 2014 11:11:22 -0800 (PST) Received: from BLU406-EAS274 ([65.55.116.9]) by BLU004-OMC1S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 9 Nov 2014 11:11:21 -0800 X-TMN: [irUOqEdJbHOTljzbzeOsdFHf0GlFJKg6] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Sun, 9 Nov 2014 07:41:13 -1000 References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> To: Emil Ivov In-Reply-To: <545EC85E.8000208@jitsi.org> X-OriginalArrivalTime: 09 Nov 2014 19:11:21.0821 (UTC) FILETIME=[F2CE18D0:01CFFC50] Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/I3JYC35g3gL7W0psYZ_eqfsfaZg Cc: Jonathan Lennox , =?utf-8?Q?Ari_Ker=C3=A4nen?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:11:28 -0000 On Nov 8, 2014, at 3:50 PM, Emil Ivov wrote: >>=20 >=20 > Continuous nomination has at least two serious problems: >=20 > a) we lose the possibility to clearly detect failures and we need to resor= t to magic timers > b) it is no longer clear when unused candidates (srflx and relay) can be r= eleased. [BA] Justin's proposal does provide a way to know when unused candidates can= be released. The problem is that those released candidates might actually b= e needed after a new interface comes up. For example, say two peers are initially on the same WiFi LAN so that host c= andidate checks work. As a result, there is no reason for either peer to ke= ep unused relay candidates. Media is flowing, then one peer senses WiFi sign= al strength decreasing so it brings up an LTE interface. While it can trickl= e the new host, srflx and relay candidates, the other peer no longer has fun= ctioning relay candidates so the checks could fail. While the peer could ha= ve kept its LTE interface hot all along and used it to ensure that the other= peer kept its relay candidates that would have a high cost in terms of ener= gy usage. From nobody Sun Nov 9 11:29:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663E11A6F64 for ; Sun, 9 Nov 2014 11:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-zD3Di4T-av for ; Sun, 9 Nov 2014 11:29:35 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB95C1A6F3F for ; Sun, 9 Nov 2014 11:29:34 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id vb8so4709118obc.23 for ; Sun, 09 Nov 2014 11:29:34 -0800 (PST) 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=xoZ94Q5OwNoYdgzGogfGC0iX3Yg4EZNU9Y8xkWOfGz8=; b=eu3KlwOC3bLssXeuan8jQWw0BKs7Wx5QuOvWONEnV/7WnPcSsmmUpHYtpn93+ucKr+ TxQ71cwxowfgHeLOJF2UBxJuTtNteN3/TzxG0LdWH48FOuRTw5FR5z1kLCuS8LYKDB+9 Y/95e2p1lrNZZH0F87GUavHkmxHZ2CrLbIvfMac/mz8zfK6uM8sYMpPZXsc4/SkxwEQP Y0yJQOeFTaTpHTYhoG1eOiym96eRp/yWv9bWAf1UgyvVy83ipV97Bv8xrRBLAjx3ITIW gtoTENr7Y1rygVNu/70QpQRly0m3lR2UZIs+ABNsQqKLvnchSh5cULxygeh5XvUYm25i DiYw== MIME-Version: 1.0 X-Received: by 10.202.63.137 with SMTP id m131mr3010807oia.75.1415561374037; Sun, 09 Nov 2014 11:29:34 -0800 (PST) Received: by 10.60.42.210 with HTTP; Sun, 9 Nov 2014 11:29:33 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> Date: Sun, 9 Nov 2014 11:29:33 -0800 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YzSuMpwQUsUEv1et-a7J0-vYj8U Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:29:36 -0000 On 9 November 2014 09:41, Bernard Aboba wrote: > For example, say two peers are initially on the same WiFi LAN so that hos= t candidate checks work. As a result, there is no reason for either peer t= o keep unused relay candidates. Media is flowing, then one peer senses WiFi= signal strength decreasing so it brings up an LTE interface. While it can = trickle the new host, srflx and relay candidates, the other peer no longer = has functioning relay candidates so the checks could fail. While the peer = could have kept its LTE interface hot all along and used it to ensure that = the other peer kept its relay candidates that would have a high cost in ter= ms of energy usage. I think that this is the key problem. And we need to start to concentrate on the properties that we are looking for, rather than looking dogmatically at one solution or other. We need clear rules (or an acknowledgment that there is a policy decision) around when a given candidate can be released. We probably also need rules or mechanisms to support a reduction in testing of candidate pairs. Emil's suggestion that you have some sort of explicit marker to declare candidates dead or unusable is definitely worthwhile. I wonder if that's not better suited to something on the media path though. From nobody Sun Nov 9 13:23:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06FB1A8731 for ; Sun, 9 Nov 2014 13:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgcrEtPdHVpW for ; Sun, 9 Nov 2014 13:23:02 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE961A8729 for ; Sun, 9 Nov 2014 13:23:01 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id l18so7263318wgh.24 for ; Sun, 09 Nov 2014 13:23:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hoyk3Gd+WdPacAmNPw3+dX6WKRFb57sKWOgzW97edjc=; b=O5M+hGN9c4lDxreM4AtPr4tGZP40oWybogqqPtga1ph3qmg7bmSNs7hOkXYJ8F0miW TIaJAgu5wTzSHediGhcSgpHjqTc4PTRPQSqyEIRuroBjCYUFeqwLPHWBKsyAige+ncef w34mceWtG7cn0oaDq2jH4UiXThY1Jw0XZaSAEmH8NCl4LBfVKMFyrjN/Wy87J7YChmRA kjfEd56HW3IzcVH36iJRGbhhU2nrW4zA9Vcso41SprorS0KICdVL/ZRa/ijtzQBQH/89 gas+HgtJhKzrWMLy26n8uEWZa+PbrKfbLAqxxSmyRzcwEgenfw6VcyeN2v/3H8CHq6mU 7uPA== X-Gm-Message-State: ALoCoQkeiTSPCbRSjUXOhXsik5kdVhgjzm9+KAxHaL8jsfWfmuWx6gxhcbvOmYhnKpkk5HC/+uX/ X-Received: by 10.180.212.110 with SMTP id nj14mr24808231wic.45.1415568180221; Sun, 09 Nov 2014 13:23:00 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id s10sm10830102wix.14.2014.11.09.13.22.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 13:22:58 -0800 (PST) Message-ID: <545FDB2F.1090906@jitsi.org> Date: Sun, 09 Nov 2014 22:22:55 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson , Bernard Aboba References: <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jDoPT_UDmUZJvNE8n47sKhu6dCU Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 21:23:05 -0000 On 9.11.14, 20:29, Martin Thomson wrote: > On 9 November 2014 09:41, Bernard Aboba wrote: >> For example, say two peers are initially on the same WiFi LAN so that host candidate checks work. As a result, there is no reason for either peer to keep unused relay candidates. Media is flowing, then one peer senses WiFi signal strength decreasing so it brings up an LTE interface. While it can trickle the new host, srflx and relay candidates, the other peer no longer has functioning relay candidates so the checks could fail. While the peer could have kept its LTE interface hot all along and used it to ensure that the other peer kept its relay candidates that would have a high cost in terms of energy usage. > > > I think that this is the key problem. And we need to start to > concentrate on the properties that we are looking for, rather than > looking dogmatically at one solution or other. We need clear rules > (or an acknowledgment that there is a policy decision) around when a > given candidate can be released. We probably also need rules or > mechanisms to support a reduction in testing of candidate pairs. > > Emil's suggestion that you have some sort of explicit marker to > declare candidates dead or unusable is definitely worthwhile. I > wonder if that's not better suited to something on the media path > though. So how about the following: 1. Ability for ICE to yield multiple paths 2. The ability to use these paths simultaneously or exclusively 3. Switching between available paths with no non-ICE signalling 4. (?) If paths are used exclusively, the ability for either path to do a switch (we may want to limit this to switches that only change the local candidate and not the remote one. 5. As interfaces come up: ability to add new candidates without disrupting ongoing communication 6. As interfaces go down: ability to update without disrupting the communication (well ... to whatever extent that is possible). I think those are the main set. And then there's also one that is more MICE-specific: 7. In the case of a mobility event: the ability to attempt to quickly recover at least partial connectivity (as opposed to restoring all paths). I think the value that MICE brings here, and that is not addressed by points 1-6 is that it optimizes cases where a NATed mobile node is talking to a public media server (e.g., a tablet in a WebEx/Hangouts/Jitsi Meet conference). In those cases, MICE allows the mobile conference participant to move to a new location and just continue streaming to the media server. The server would latch onto the new address of the mobile and the disruption time would be very low. The reason I kept it as a separate item is because it has different constraints than regular ICE updates. It is an optimization for some cases. It tries to recover any form of connectivity as quickly as possible in order to reduce handover latency. Period. There are many cases where this specific MICE optimization wouldn't work (e.g., when both peers are behind common types of NATs) but this is not a problem since MICE would then do a proper update through signalling anyway (e.g., an ICE restart) in order to re-establish other paths of communication or cover the cases that didn't connect with the optimization. Dan, Pal, Tiru, is the above summary correct? If so, I think we have the option of addressing this case separately. The following is vague but, for example, we could allow for peer-reflexive candidates to be discovered at any point, with the possibility to replace a pre-existing path.I am not even sure we need the extra ICE attributes defined by MICE in that case ... but I am likely missing something. Anyways, the importance here is that agents would not attempt to pair these late peer reflexive candidates anything else than the address that they were received on. They would just latch onto them and do nothing else until a restart is triggered. Thoughts? Emil -- https://jitsi.org From nobody Sun Nov 9 16:50:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C911A8825 for ; Sun, 9 Nov 2014 16:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxeX3xcLq9cr for ; Sun, 9 Nov 2014 16:50:44 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C811A8827 for ; Sun, 9 Nov 2014 16:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2032; q=dns/txt; s=iport; t=1415580610; x=1416790210; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4JnLJZONXHW+nbk65bEpFNYyNWChkdV1Mc29rWSJU58=; b=Orx5HY/p3kg3FwNVghoeiU+K5GYMQYS/akNuY0fCwnXPSGFqsfSd86E+ GGfQ6U20LoPXDgAnvYQgnxuMBYDEOAwzkd04VWw1kGzC8q4sZ4vC+bDQk vEUmhr8Owi2ahRYkswVsHv+6csr8s8g3NIdEreipSPc1CT3DfAZljLtYk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFANMKYFStJA2F/2dsb2JhbABbgw5UWQTLXgqGelUCgRgWAQEBAQF9hAIBAQEEAQEBawsMBAIBCBEEAQEBCh0HJwsUCQgCBAENBQiIOQ3NGgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkGQxBwaDJ4EeBYtGhmuEU54Bg3psgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,348,1413244800"; d="scan'208";a="367622024" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP; 10 Nov 2014 00:50:09 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sAA0o9d9012948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 00:50:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sun, 9 Nov 2014 18:50:09 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Bernard Aboba , Emil Ivov Thread-Topic: [MMUSIC] Faster ICE by role reversal? Thread-Index: AQHP+FfnbAbj/TDeQkqb3v7sw/kJtpxUeScAgAARZYCAABxXgIAAEUmAgAABoYCAAAFLAIAB3t4AgAAOqYCAAUpSAIABCaqAgAALZuA= Date: Mon, 10 Nov 2014 00:50:09 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2835AE48@xmb-rcd-x10.cisco.com> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.205] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GThOt-n6ip8GaIhCxoZS923N0K0 Cc: Jonathan Lennox , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 00:50:46 -0000 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard > Aboba > Sent: Sunday, November 09, 2014 7:41 AM > To: Emil Ivov > Cc: Jonathan Lennox; Ari Ker=E4nen; mmusic; Dan Wing (dwing) > Subject: Re: [MMUSIC] Faster ICE by role reversal? >=20 > On Nov 8, 2014, at 3:50 PM, Emil Ivov wrote: > >> > > > > Continuous nomination has at least two serious problems: > > > > a) we lose the possibility to clearly detect failures and we need to re= sort to > magic timers > > b) it is no longer clear when unused candidates (srflx and relay) can b= e > released. >=20 > [BA] Justin's proposal does provide a way to know when unused candidates > can be released. The problem is that those released candidates might > actually be needed after a new interface comes up. >=20 > For example, say two peers are initially on the same WiFi LAN so that hos= t > candidate checks work. As a result, there is no reason for either peer t= o keep > unused relay candidates. Media is flowing, then one peer senses WiFi sign= al > strength decreasing so it brings up an LTE interface. While it can trickl= e the > new host, srflx and relay candidates, the other peer no longer has > functioning relay candidates so the checks could fail. While the peer co= uld > have kept its LTE interface hot all along and used it to ensure that the = other > peer kept its relay candidates that would have a high cost in terms of en= ergy > usage. Alternatively unused relayed candidate could be maintained on the Wifi inte= rface and after switch-over to LTE use TURN Mobility (https://tools.ietf.or= g/html/draft-wing-tram-turn-mobility-02) to retain the allocations. The ove= rhead is that unused candidate pair with relayed candidate has to be mainta= ined with connectivity checks for fail-over. -Tiru >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Sun Nov 9 17:19:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911441A87F0 for ; Sun, 9 Nov 2014 17:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MDYbH091I5H for ; Sun, 9 Nov 2014 17:19:18 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDF91A87E7 for ; Sun, 9 Nov 2014 17:19:17 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id rp18so8364325iec.37 for ; Sun, 09 Nov 2014 17:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9LUuMnQ14/lZmeoiOdstK0Z0Jj5y9ey7b7kqxnijVE0=; b=oTVE9IuHl6Ir9NGgaCcje00HTmrdQBSxcFWpzbtEJlCVTIy7HVrJ316ES2gdeFskyx 1UcKrJOdg9SOgoFfH68fJ4qoiYA51EYD0f491poD9PKhMsgHFcOARMTtuSJS/HPpSRBv 4lDktle6urqEJmB8j9LzmdJ1xW0IyIU1sr2v9+GI515n9TYoHTln1J/rvrlq/qDkukk8 AHDuJX1pSbgzFhLqBqP2/eAfTInYgr1wvGPK39XnCyw4FKHvpqiQTOF4NSIWzeL5sbLU hbPaAzNW2yWHkElrRDA3GE4sGW8R3QaNCz6H+IY/FG956wwOSM9HbTvZU+4nYEcmB+pJ Gp1g== X-Received: by 10.42.64.143 with SMTP id g15mr4800662ici.59.1415582357007; Sun, 09 Nov 2014 17:19:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.95.199 with HTTP; Sun, 9 Nov 2014 17:18:56 -0800 (PST) In-Reply-To: <47B152C2-ED0C-4EB1-A15E-C81260D94D0F@cisco.com> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> <47B152C2-ED0C-4EB1-A15E-C81260D94D0F@cisco.com> From: Varun Singh Date: Sun, 9 Nov 2014 15:18:56 -1000 Message-ID: To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5w8XbvNFk92wSNNcR8HFTqzPsBE Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 01:19:20 -0000 Catching up on the mailing list. One comment inline, reflecting on our experiments with MPRTP. On Fri, Nov 7, 2014 at 3:29 PM, =F0=9F=94=93Dan Wing wrot= e: > > On Nov 7, 2014, at 5:18 PM, Emil Ivov wrote: > >> >> >> On 8.11.14, 1:35, =F0=9F=94=93Dan Wing wrote: >>> >>> On Nov 7, 2014, at 2:41 PM, Emil Ivov wrote: >>> >>>> Hey all, >>>> >>>> In the context of the ongoing discussion on two potential ICE >>>> improvements, I wanted to spin off this thread on the idea of >>>> continuous nomination. >>>> >>>> So first of all, as I already mentioned in Toronto, I am very much >>>> in favour of a mechanism that would allow ICE processing to yield >>>> more than a single nominated pair. Back then the discussion was >>>> about MPRTP but there would likely be other use cases as well. >>>> >>>> In that context, it seems perfectly valid to me that nomination >>>> among all validated pairs can occur multiple times within a >>>> session. Again, I find this to be a very valid and useful feature. >>>> >>>> I am however bothered by the "ICE never ends" suggestions made by >>>> the document below and more specifically by the fact that >>>> candidates may continue to be trickled forever. I think that's both >>>> unnecessary and a problem. >>>> >>>> It is a problem because >>>> >>>> a) being able to know when the remote agent is done trickling is >>>> one of the very reasons we started the work on trickle ICE. This >>>> allows to quickly and deterministically detect and declare failure >>>> when it occurs. Not having this would require implementations to >>>> use magic timers of the sort: "Surely if I couldn't connect in .. >>>> say 20 seconds ... then the situation must be hopeless ... I >>>> think". >>>> >>>> b) being able to continuously trickle new candidates forever and >>>> ever means that they would have to be paired with all of the peer's >>>> *initial* candidates. This means that ICE agents would have to >>>> maintain all gathered candidates even when they are not working for >>>> them. >>>> >>>> More importantly however, the whole concept is likely unnecessary >>>> because an ICE restart only sounds scary, and it doesn't actually >>>> need to be ;). >>>> >>>> A restart is non-disruptive as media can keep flowing while we are >>>> doing ICE processing. >>>> >>>> 5245 already supports pair reuse and we can easily port that >>>> concept to multipath ICE. >>>> >>>> The one thing that we might be missing today is the syntax to allow >>>> for a restart without using offer/answer. >>> >>> For MICE and some other use cases, I agree that need to signal (in >>> SDP) is the 'scary' part of an ICE restart. >>> >>>> This would be trivial to resolve: we just need to allow trickling a >>>> restart command. Sending your ufrag and pwd in a trickle update >>>> should do the job. >>> >>> That is a nice approach -- move the 'ICE restart' signaling to an >>> (existing, working) media path. >> >> I was actually thinking of the signalling path. So for SIP this would be= a SIP INFO request with the ufrag/pwd as the sole content. A couple of a= =3D lines would do it for WebRTC. >> >> I am slightly uncomfortable about doing it on the media path because it = requires you to make the assumption that one of your media paths is certain= to survive any sort of mobility event. > Back in 2010, before we had trickle ICE, in Multipath RTP, we implemented advertising the interfaces in RTCP, we wanted to do it in-band with the media, because we wanted to avoid the SDP offer/answer. It was more like a notification to the other party that a new interface is available and that the endpoint wants to make use of it. On receiving the RTCP message with the interface advertisement, the endpoints would perform connectivity checks on the interfaces and reported successful candidates to the RTP layer, and the scheduling algorithm would figure out over time, which candidates should be active/passive depending on the performance metrics (e.g., loss, delay, throughput, etc.). OTOH, the application needs to know if any paths work or else it would be stuck waiting for the transports to be setup. We tried not implementing ICE, but ended up doing something similar anyway. Some of the early experiments are described in Section 7.1 of MPRTP paper. [1] [1] http://www.netlab.tkk.fi/~jo/papers/2013-mmsys-mprtp.pdf. > I am slightly uncomfortable using signaling path for same reason, and sig= naling path takes longer to start up (TCP, TLS). Even if we make the signa= ling path start up faster with all the spiffy new TLS 0-RTT or QUIC or what= ever, the signaling path should remain slower because a server is involved = and the path isn't as straight as the peer-to-peer path. That's why MICE d= oes not require to first send a=3Dcandidate over the signaling path. > >> Even if you keep your TURN connection open for that purpose, how do you = know that your new location wouldn't be one where TURN-TCP is the only way = to get out of the local network? >> >> Or what if you don't even have a TURN server? > > You're right, we don't know, of course. > > But same risk exists of the signaling path on a mobility event. > > >> You signalling channel would be a safer bet, but more importantly, you'd= likely want to tear down your call if it didn't. > > From my perspective, thinking about MICE, I want to make the mobility eve= nt (voice/video) successful. If signaling takes a little while to get re-e= stablished, *shrug*, I don't care. > +1 > > > >> >>>> To put that into perspective, let's look at the following use >>>> cases: >>>> >>>> I. You have used the new multipath ICE and you have successfully >>>> discovered a couple of working routes: one going through your wi-fi >>>> interface and another one going through 4G. During your session, >>>> you move closer to your Wi-Fi access point so you detect that RTT >>>> and packet loss start looking better on your Wi-Fi interface. >>>> >>>> You decide to switch from 4G to Wi-Fi. >>>> >>>> *No ICE restart* would be necessary here because no new paths would >>>> need to negotiated. This would be a native feature of the new >>>> multipath ICE. >>>> >>>> II. You start on Wi-Fi in the presence of a 4G interface that you >>>> keep for backup. Multipath ICE comes up with pairs over both your >>>> interfaces. I don't believe this requires an ICE restart either. >>>> You just switch between pre-existing path and one of them expires >>>> as pointed out in Justin's document below >>>> >>>> III. You setup a session at a point of time where 4G is your only >>>> working interface. Your Wi-Fi interface then comes up and you want >>>> to include it in the game. Here's what you do: >>>> >>>> a) You gather host, srflx and relay candidates for the new >>>> interface. b) You gather candidates on the old interface that >>>> haven't been valid before but that are worth trying again (this is >>>> non-essential) >>>> >>>> d) you then trickle a new ufrag and pwd to trigger a restart. >>> >>> If that trickling happens over the SIP/WebRTC/XMPP signaling channel, >>> MICE would prefer not requiring that SDP signaling step or to at >>> least allow it to be done later. >> >> Well, if you had multipath ICE, you would be able to switch your media o= ver to TURN (this wouldn't require any signalling) if that still works and= then do the non-disruptive restart after that to discover other paths. >> >> Would this work? > > It would help. But multipath ICE requires I have that connection to TURN= set up prior to the mobility event, right? If I'm right, that is not desi= rable. > > -d > > >> >> Emil >> >>> >>> -d >>> >>> >>>> b) you batch trickle all currently working candidates that you'd >>>> wish to preserve (you can omit any candidates you no longer wish to >>>> use, for whatever reason). c) you trickle the newly gathered >>>> candidates. >>>> >>>> The remote party, your peer, would then do the following >>>> >>>> a) Gather all candidates that didn't work before but that deserve a >>>> second chance. This time *this is essential*. SRFLX candiates on >>>> your peer might not have worked with your 4G connection but they >>>> have every chance of working this time. There are a number of other >>>> scenarios where candidates would be worth retrying. >>>> >>>> b) Your peer would then trickle back to you all the working >>>> candidates it wishes to preserve (as long as they are still valid) >>>> c) It trickles all candidates it gathered for the occasion, that it >>>> wishes to retry. >>>> >>>> Connectivity checks then proceed as usual. It might be worth paying >>>> special attention to the in-use candidates. Implementations might >>>> want to either confirm that data is still flowing there, or start >>>> the checks with them. This would determine how urgently ICE >>>> processing needs to yield results and it may imply changes in >>>> nomination strategies. >>>> >>>> Thoughts? >>>> >>>> Emil >>>> >>>> >>>> On 7.11.14, 0:44, Justin Uberti wrote: >>>>> Agreed. >>>>> >>>>> I wrote up a slightly more fleshed-out proposal at >>>>> https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe= -fvN8bk-Xw/edit >>>>> >>>>> >>>>> >> On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson >>>> > wrote: >>>>> >>>>> On 6 November 2014 13:47, Justin Uberti >>>> > wrote: >>>>>> I looked into how MICE works; I think that continuous >>>>>> nomination might be able to effectively support that use case, >>>>>> as well as the case that Brandon was interested in, namely >>>>>> picking the route that uses the best set of TURN servers. >>>>> >>>>> >>>>> I've always believe that continuous ICE operation was the only >>>>> way to ensure proper reliability. Multipath or otherwise. You >>>>> just need to work out when it is safe to completely stop on any >>>>> given pair, assuming that you don't want to be testing the >>>>> complete mesh all the time. But you also might want multiple >>>>> paths available, or maybe backup paths. >>>>> >>>>> >>>> >>>> -- https://jitsi.org >>> >>> >> >> -- >> https://jitsi.org > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 http://www.netlab.tkk.fi/~varun/ From nobody Sun Nov 9 17:29:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2D1A8851 for ; Sun, 9 Nov 2014 17:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAOPYgcfswcc for ; Sun, 9 Nov 2014 17:29:12 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A691A8852 for ; Sun, 9 Nov 2014 17:29:12 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id rd18so8087515iec.7 for ; Sun, 09 Nov 2014 17:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DlP0ND/cn6JAOS05XyKUleuj+A0RzS3QQ50o1qknYZg=; b=Nw0OBtNgLG2BFbaBNwPBEA28j/Q/htaPzBxcLQYuxWpOa6HnObzNo6+RPFQhw8n9kz 6hg27Ul2zmzgO2CcN7uKwXBfts6DZjnfIGfgzDSK6lSlrg3y+fszyZyc2/bbR1615yIl zfBhhroOEcIdELPAFQmdLYZaAXtPTA6c4iZLUF5hVxXoIFSG+OIHHcfvJHWLEFiTG6wa ujMDkLaww5ewJ3haUnkqRSM040m2d+fkIs5udRDaB15qz8KRW1IAskZYJ2TwPuLyJmC7 +ADtZtugt56KSjEI7T3OP00mR1Vae4dWZZpR111cbBfq0yyboBIu9YpV1HJk7zoVRTkh UCZw== X-Received: by 10.50.109.133 with SMTP id hs5mr4407848igb.15.1415582951924; Sun, 09 Nov 2014 17:29:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.95.199 with HTTP; Sun, 9 Nov 2014 17:28:51 -0800 (PST) In-Reply-To: <545FDB2F.1090906@jitsi.org> References: <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> <545FDB2F.1090906@jitsi.org> From: Varun Singh Date: Sun, 9 Nov 2014 15:28:51 -1000 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YqUFLNjk4bcBzkpwTn9OhG3txv4 Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 01:29:15 -0000 On Sun, Nov 9, 2014 at 11:22 AM, Emil Ivov wrote: > > > On 9.11.14, 20:29, Martin Thomson wrote: >> >> On 9 November 2014 09:41, Bernard Aboba wrote: >>> >>> For example, say two peers are initially on the same WiFi LAN so that >>> host candidate checks work. As a result, there is no reason for either peer >>> to keep unused relay candidates. Media is flowing, then one peer senses WiFi >>> signal strength decreasing so it brings up an LTE interface. While it can >>> trickle the new host, srflx and relay candidates, the other peer no longer >>> has functioning relay candidates so the checks could fail. While the peer >>> could have kept its LTE interface hot all along and used it to ensure that >>> the other peer kept its relay candidates that would have a high cost in >>> terms of energy usage. >> >> >> >> I think that this is the key problem. And we need to start to >> concentrate on the properties that we are looking for, rather than >> looking dogmatically at one solution or other. We need clear rules >> (or an acknowledgment that there is a policy decision) around when a >> given candidate can be released. We probably also need rules or >> mechanisms to support a reduction in testing of candidate pairs. >> >> Emil's suggestion that you have some sort of explicit marker to >> declare candidates dead or unusable is definitely worthwhile. I >> wonder if that's not better suited to something on the media path >> though. > > > So how about the following: > > 1. Ability for ICE to yield multiple paths > 2. The ability to use these paths simultaneously or exclusively > 3. Switching between available paths with no non-ICE signalling do you mean: switching between paths with ICE signalling? In the case of MPRTP, the scheduling algorithm/congestion controller can make the decision on which paths to use. However, if it is single RTP, then switching from one to another makes sense. > 4. (?) If paths are used exclusively, the ability for either path to do a > switch (we may want to limit this to switches that only change the local > candidate and not the remote one. > 5. As interfaces come up: ability to add new candidates without disrupting > ongoing communication > 6. As interfaces go down: ability to update without disrupting the > communication (well ... to whatever extent that is possible). > +1 for the rest. > I think those are the main set. And then there's also one that is more > MICE-specific: > > 7. In the case of a mobility event: the ability to attempt to quickly > recover at least partial connectivity (as opposed to restoring all paths). > > I think the value that MICE brings here, and that is not addressed by points > 1-6 is that it optimizes cases where a NATed mobile node is talking to a > public media server (e.g., a tablet in a WebEx/Hangouts/Jitsi Meet > conference). In those cases, MICE allows the mobile conference participant > to move to a new location and just continue streaming to the media server. > The server would latch onto the new address of the mobile and the disruption > time would be very low. > > The reason I kept it as a separate item is because it has different > constraints than regular ICE updates. It is an optimization for some cases. > It tries to recover any form of connectivity as quickly as possible in order > to reduce handover latency. Period. > > There are many cases where this specific MICE optimization wouldn't work > (e.g., when both peers are behind common types of NATs) but this is not a > problem since MICE would then do a proper update through signalling anyway > (e.g., an ICE restart) in order to re-establish other paths of communication > or cover the cases that didn't connect with the optimization. > > Dan, Pal, Tiru, is the above summary correct? > > If so, I think we have the option of addressing this case separately. The > following is vague but, for example, we could allow for peer-reflexive > candidates to be discovered at any point, with the possibility to replace a > pre-existing path.I am not even sure we need the extra ICE attributes > defined by MICE in that case ... but I am likely missing something. > > Anyways, the importance here is that agents would not attempt to pair these > late peer reflexive candidates anything else than the address that they were > received on. They would just latch onto them and do nothing else until a > restart is triggered. > > Thoughts? > > Emil > > -- > https://jitsi.org > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- http://www.netlab.tkk.fi/~varun/ From nobody Sun Nov 9 18:35:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6727D1A889F for ; Sun, 9 Nov 2014 18:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3IJr9Rpzy11 for ; Sun, 9 Nov 2014 18:35:16 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981BE1A889C for ; Sun, 9 Nov 2014 18:35:16 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id x12so7727010wgg.32 for ; Sun, 09 Nov 2014 18:35:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4KK5AAZi0uRwT+YhiYs+AtL+HCMJaPud7PHvCt6dm0E=; b=MWYGhvyhAkh+rkit0W2xUs8ZACvymO691r+/lKkBZH+2loV+1/m8PjL5e0OUP3IJEt cE3uSNRuHDlrtXWXJnwoAaxJIukMWtOEs/zL5vnQHNT2gOv1MhNjwF1dDzfetAH8ocDZ UrPxzMMiymR+U6YC4wyhHx6mw2Ny/coUkSB1NE8i/h9jb2fmvCRnC9OI+UsB9ViqtMLe 9CsNWqoJRgKpIRH0HbJUG3yqLcurTKpEf3ouiAPDjIMELJAbF0AfqcTfTCRgRgltudFF xguvwKiX4BjHjPonKnFU23XdSJ2WcrkJWxc5WkZq+UnKlrN6nEGJG5ev0M0jJ9PhKbTE 6D+Q== X-Gm-Message-State: ALoCoQnT+nkh7wjiFtDTwDhwNZL7YMNzVG9SnJOqZH5xFPG4CYocGcBPydP+LHm9n51plOBhCl4R X-Received: by 10.180.211.70 with SMTP id na6mr25846907wic.3.1415586915238; Sun, 09 Nov 2014 18:35:15 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id q10sm21308162wjq.35.2014.11.09.18.35.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 18:35:13 -0800 (PST) Message-ID: <5460245F.5090803@jitsi.org> Date: Mon, 10 Nov 2014 03:35:11 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson , Bernard Aboba References: <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> <545FDB2F.1090906@jitsi.org> In-Reply-To: <545FDB2F.1090906@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lhEEDD0TUuZOznWWQGlUE64Tmrs Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 02:35:18 -0000 On 9.11.14, 22:22, Emil Ivov wrote: > 1. Ability for ICE to yield multiple paths > 2. The ability to use these paths simultaneously or exclusively > 3. Switching between available paths with no non-ICE signalling > 4. (?) If paths are used exclusively, the ability for either path to do > a switch (we may want to limit this to switches that only change the > local candidate and not the remote one. > 5. As interfaces come up: ability to add new candidates without > disrupting ongoing communication > 6. As interfaces go down: ability to update without disrupting the > communication (well ... to whatever extent that is possible). > > I think those are the main set. And then there's also one that is more > MICE-specific: > > 7. In the case of a mobility event: the ability to attempt to quickly > recover at least partial connectivity (as opposed to restoring all paths). I'd like to add one more here: 8. Preserve the possibility to detect an end of the candidate trickling. That is: end of the candidates that are currently available to a peer. This options allows us to: a) quickly recognize failure when it occurs and b) release candidates that are not used as a result of ICE processing. Emil -- https://jitsi.org From nobody Sun Nov 9 18:37:54 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5517D1A889B for ; Sun, 9 Nov 2014 18:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvaTQ3tKAsF0 for ; Sun, 9 Nov 2014 18:37:51 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E4F1A8832 for ; Sun, 9 Nov 2014 18:37:50 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so9354171wib.17 for ; Sun, 09 Nov 2014 18:37:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Rmb7k20R6RLqkOy3JGBhQa0H9UH9I7PBxtkY7didLuQ=; b=VdfiCpfPdYWnbT8/ZEoUkNIIyzpr4avwJrZ0iVK0lozdgAbxcWvr4EBlC9nn57NLhW tFUIzeg2F/I3owP3QFr0oIzoU1vaW1Bf6QS0MQ8kvUnPBgLPxHZKhg2/LIZkdhFGSL9n 8b908xAPBfIX1PyWxfIuqA6DUleeqL3qVP9AXHnahR4KFyQd6UkatSHvx5Nsuy8rU0ye GmHuGI3C7JZvLNTP8yN59wk+VJyMoR1ZqNpPZCNlAXtBAW+7NBH685tAHFx9gtQnkg8C ypvJdE4/pBhGmlkMvtS4on/qi0yycg0n39hiW0fhj5i2swTtxXaa5ObmmaBgKVIUcG9y aDXQ== X-Gm-Message-State: ALoCoQmxE9/bzNoQx57AGbRpq7ij8rDAwFXImdx38Yi4Ihj6XwWmawj28yLCxCXsFKvXVApFywPH X-Received: by 10.180.13.226 with SMTP id k2mr26705892wic.25.1415587069548; Sun, 09 Nov 2014 18:37:49 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id mw7sm11537816wib.14.2014.11.09.18.37.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 18:37:48 -0800 (PST) Message-ID: <546024FA.4020800@jitsi.org> Date: Mon, 10 Nov 2014 03:37:46 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Varun Singh References: <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> <545FDB2F.1090906@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/oST2FoKJcopHjk_hqi1o4R9YKwA Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 02:37:52 -0000 On 10.11.14, 2:28, Varun Singh wrote: >> 1. Ability for ICE to yield multiple paths >> >2. The ability to use these paths simultaneously or exclusively >> >3. Switching between available paths with no non-ICE signalling > do you mean: switching between paths with ICE signalling? Yes. With only media-path signalling. > In the case of MPRTP, the scheduling algorithm/congestion controller > can make the decision on which paths to use. > However, if it is single RTP, then switching from one to another makes sense. Well ... I am expecting that if and when we do come up with Multipath ICE we would have the option for endpoints/applications to decide whether those paths are meant to be used together or separately. So MPRTP could simply go for the aggregate option. Emil -- https://jitsi.org From nobody Sun Nov 9 19:03:32 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255F41A889F for ; Sun, 9 Nov 2014 19:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsLXsPBTvkbh for ; Sun, 9 Nov 2014 19:03:29 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BE91A887D for ; Sun, 9 Nov 2014 19:03:29 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id hl2so8384417igb.10 for ; Sun, 09 Nov 2014 19:03:28 -0800 (PST) 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=dkwO/RXT4wetLBWB0R5rb9ZVgcDXzM7kHEWNzvchDVM=; b=J6QFPbCkdrXRkuOhV8PnqzDPtwB91kbNSmlt4SFUbHlpyq2RPFtkp7JNdnGy1l0Q2w al0PlrCIHifvoUARU2+qDPcBXO1g1cQREgkmEet5mPv3zbpVSJcrD28739KaPakkUMFp 7WzKHuSTrO78bHG6X1NJxXkwIE98g7071kWGc/lHjCVBmAOU/OmVCMQbzlYfu2fzOTxn 2eaY3rNlYBoJl7OHE2dv6WTf+M7mlHzSfZjpxPKmpuRnz9yy4z/d67cCaRWWXFu/gKV4 YQX6TaOzTLLb9JpcjiEX1DtVGoK81/WXNuq8F5pqbjbG8+eMOvYoHKWpbnxMGrb+wXra zgUw== MIME-Version: 1.0 X-Received: by 10.50.111.8 with SMTP id ie8mr11978574igb.37.1415588608563; Sun, 09 Nov 2014 19:03:28 -0800 (PST) Received: by 10.50.95.199 with HTTP; Sun, 9 Nov 2014 19:03:28 -0800 (PST) Received: by 10.50.95.199 with HTTP; Sun, 9 Nov 2014 19:03:28 -0800 (PST) In-Reply-To: <546024FA.4020800@jitsi.org> References: <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> <545FDB2F.1090906@jitsi.org> <546024FA.4020800@jitsi.org> Date: Sun, 9 Nov 2014 17:03:28 -1000 Message-ID: From: Varun Singh To: Emil Ivov Content-Type: multipart/alternative; boundary=089e0149c028295f2705077868b8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0XHiXPDtXZkPrTdYJquov2qoiTc Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 03:03:31 -0000 --089e0149c028295f2705077868b8 Content-Type: text/plain; charset=UTF-8 On 9 Nov 2014 16:37, "Emil Ivov" wrote: > > > > On 10.11.14, 2:28, Varun Singh wrote: >>> >>> 1. Ability for ICE to yield multiple paths >>> >2. The ability to use these paths simultaneously or exclusively >>> >3. Switching between available paths with no non-ICE signalling >> >> do you mean: switching between paths with ICE signalling? > > > Yes. With only media-path signalling. > > >> In the case of MPRTP, the scheduling algorithm/congestion controller >> can make the decision on which paths to use. >> However, if it is single RTP, then switching from one to another makes sense. > > > Well ... I am expecting that if and when we do come up with Multipath ICE we would have the option for endpoints/applications to decide whether those paths are meant to be used together or separately. So MPRTP could simply go for the aggregate option. > Yes, For MPRTP knowing which paths have connectivity is sufficient for operation. I just want to make sure that ICE doesn't switch interfaces unless it is for failover (the current candidate disappears) because it will pollute the path metrics used by the congestion control. > Emil > > > -- > https://jitsi.org --089e0149c028295f2705077868b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 Nov 2014 16:37, "Emil Ivov" <emcho@jitsi.org> wrote:
>
>
>
> On 10.11.14, 2:28, Varun Singh wrote:
>>>
>>> 1. Ability for ICE to yield multiple paths
>>> >2. The ability to use these paths simultaneously or exclus= ively
>>> >3. Switching between available paths with no non-ICE signa= lling
>>
>> do you mean: switching between paths with ICE signalling?
>
>
> Yes. With only media-path signalling.
>
>
>> In the case of MPRTP, the scheduling algorithm/congestion controll= er
>> can make the decision on which paths to use.
>> However, if it is single RTP, then switching from one to another m= akes sense.
>
>
> Well ... I am expecting that if and when we do come up with Multipath = ICE we would have the option for endpoints/applications to decide whether t= hose paths are meant to be used together or separately. So MPRTP could simp= ly go for the aggregate option.
>

Yes, For MPRTP knowing which paths have connectivity is suff= icient for operation.

I just want to make sure that ICE doesn't switch interfa= ces unless it is for failover (the current candidate disappears) because it= will pollute the path metrics used by the congestion control.

> Emil
>
>
> --
> https://jitsi.org

--089e0149c028295f2705077868b8-- From nobody Sun Nov 9 19:17:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEB91A88B9 for ; Sun, 9 Nov 2014 19:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lVhHvobBZWB for ; Sun, 9 Nov 2014 19:17:07 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C256E1A88B8 for ; Sun, 9 Nov 2014 19:17:06 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id s18so7052766lam.27 for ; Sun, 09 Nov 2014 19:17:03 -0800 (PST) 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=zIao3CKHrudhQ7G5NWoCqaxYre9hIRMMJo/vCaFFqQU=; b=EqpfdgoXYhBZTfZ73sVx+/nLTXvTG/RzK7uW6u1hkT3N8UDekuQU5csPr2Mm1/2Q2p mKdCAvz6ct9XBpHAp1T6Waogeqn8adkVolcjJksP0nKt+SPSQjSrRy9AJsJ18gH2GAAQ uSG23/HFKhSfaGcW5SVyqsUbXqcq7ERQdy2U6hBhO36Dws1OGBQteUmp/VoKX388GfUV gOjeSU1/u1yDM0Ey8ez4dNp1cZNkOfEJ/552wp1mRzbPeYYfjvNSANWbtIPZWqRo1RdZ 9yIsk8VLCN/YQA89oWTCdAe9hNo0nyJV38DBJXpVYhAiVU3LTzG7J3R5FrES3er4B2jw rdXw== MIME-Version: 1.0 X-Received: by 10.152.29.8 with SMTP id f8mr26783974lah.56.1415589423795; Sun, 09 Nov 2014 19:17:03 -0800 (PST) Received: by 10.25.215.134 with HTTP; Sun, 9 Nov 2014 19:17:03 -0800 (PST) In-Reply-To: <5460245F.5090803@jitsi.org> References: <545911E9.3070300@ericsson.com> <545EC85E.8000208@jitsi.org> <545FDB2F.1090906@jitsi.org> <5460245F.5090803@jitsi.org> Date: Sun, 9 Nov 2014 19:17:03 -0800 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/B4OIc1IJpa6qb4teNfIaq0BVhDw Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Dan Wing Subject: Re: [MMUSIC] Faster ICE by role reversal? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 03:17:08 -0000 On 9 November 2014 18:35, Emil Ivov wrote: > 8. Preserve the possibility to detect an end of the candidate trickling. > That is: end of the candidates that are currently available to a peer. > > This options allows us to: > > a) quickly recognize failure when it occurs and > b) release candidates that are not used as a result of ICE processing. I think that these two are the actual requirements: 8. Detect a dead-end: where there is no further chance of success because there are no more candidates forthcoming and all combinations have been tested 9. Have a means to remove candidates from the set that a peer has offered (I'm not sure if a peer might want to remove candidates its peer has offered, but a peer should definitely be able to retract its own candidates) From nobody Mon Nov 10 08:10:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205B01A005A for ; Mon, 10 Nov 2014 08:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCz2-a1eOdCO for ; Mon, 10 Nov 2014 08:10:52 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D5C1A005C for ; Mon, 10 Nov 2014 08:10:51 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id BAF2D8343439; Mon, 10 Nov 2014 16:10:47 +0000 (GMT) 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 sAAGAnMO029253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 17:10:50 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 17:10:50 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , Justin Uberti Thread-Topic: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? Thread-Index: Ac/5s5ZE4VFWXasARgqQmOGfC31l/gAHOIkwAAnwGgD///LfgIAAL06AgAAEdoCAAFddv4AANnYA//+9vaCAAUHmgP//NDkg//rbh+A= Date: Mon, 10 Nov 2014 16:10:49 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC35BB25@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D4E82E8@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC359937@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4E9EE5@ESESSMB209.ericsson.se> <545BFAF9.7010301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4EA783@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4EBC1F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4ED6AA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4ED6AA@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC35BB25FR711WXCHMBA03zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1y5jX_e-PSEexMRo6ehLCa3z6ws Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Meaning of "transported on DTLS"? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 16:10:55 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC35BB25FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KPkkgdGhpbmsgdGhlIFJGQ3MgZXhwbGFpbiB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIERU TFMgc2Vzc2lvbiBhbmQgRFRMUyBjb25uZWN0aW9uIOKAkyB0aGF0IGlzIG5vdCB3aGF0IEkgd2Fz IGFza2luZyBhYm91dC4NCg0KV2VsbCwgaWYgdGhlIFJGQ3Mgd291bGQgcHJvdmlkZSBhIHRlcm0g ZGVmaW5pdGlvbiB0aGVuIHRoZXJlIHdvdWxkbuKAmXQgYmUgYW55IGRpc2N1c3Npb24uDQpUaGUg VExTIFJGQyBwcm92aWRlcyBhIGdsb3NzYXJ5LCB3aGljaCBoZWxwcyBzb21laG93IGF0IGhpZ2gg bGV2ZWwsIGJ1dCBkb2VzbuKAmXQgcHJvdmlkZSBkZWZpbml0aW9ucyBhcyByZXF1aXJlZCBmb3Ig cHJvdG9jb2wgZGlzY3Vzc2lvbnMgaGVyZS4NCkFuZCB0aGUgdGhyZWFkIGp1c3QgY29uZmlybXMg dGhhdCB0aGUgc3VwcG9zZWQgY29uY2VwdHMgYXJlIG5vdCByZWFsbHkgY2xlYXIuDQoNClJlZ2Fy ZHMsDQpBbGJyZWNodA0KDQoNCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogU2Ftc3RhZywg OC4gTm92ZW1iZXIgMjAxNCAxMDo0Ng0KVG86IEp1c3RpbiBVYmVydGkNCkNjOiBtbXVzaWNAaWV0 Zi5vcmc7IFBhdWwgS3l6aXZhdA0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEJVTkRMRTogTWVhbmlu ZyBvZiAidHJhbnNwb3J0ZWQgb24gRFRMUyI/DQoNCkhpLA0KDQo+SW4gdGhpcyBjb250ZXh0LCB0 aGUga2V5IGV4Y2hhbmdlIG1lY2hhbmlzbSBpcyBpbW1hdGVyaWFsLiBUaGUga2V5ID5wb2ludCBp cyB0aGF0IHlvdSBkb24ndCBuZWVkIHRvIGRlbXVsdGlwbGV4IFNSVFAgcGFja2V0cyBmcm9tIG90 aGVyID5zdHVmZiBhcnJpdmluZyBvbiB0aGUgRFRMUyBjb25uZWN0aW9uLCBiZWNhdXNlIHRob3Nl IHBhY2tldHMgYXJlbid0ID5zZW50IG9uIHRoZSBEVExTIGNvbm5lY3Rpb24gKGFuZCB0aGVyZWZv cmUgdGhlIGRlbXV4IGlzIGFscmVhZHkgPmNvdmVyZWQgYnkgNTc2NCkuDQoNCkNvcnJlY3QsIGFu ZCBpdOKAmXMgYWxzbyBtZW50aW9uZWQgaW4gQlVORExFLg0KDQpTbywgYWdhaW4sIHRoZSBzdGF0 ZW1lbnQgSSByZWZlcnJlZCB0byBvbmx5IGNvdmVycyBwYWNrZXRzIHdoaWNoIGFyZSBEVExTIGVu Y3J5cHRlZC4NCg0K4oCcSWYgbXVsdGlwbGUgcHJvdG9jb2xzIGFyZSB0cmFuc3BvcnRlZCBvbiBE VExTLCB0aGVyZSBNVVNUIGV4aXN0IGENCiAgICAgICAgICAgICBzcGVjaWZpY2F0aW9uIGRlc2Ny aWJpbmcgYSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5IGVhY2ggaW5kaXZpZHVhbA0KICAgICAgICAg ICAgIHByb3RvY29sLuKAnQ0KDQpEbyB3ZSBlLmcuIGFzc3VtZSB0aGF0IGFsbCBEVExTIGVuY3J5 cHRlZCB0cmFmZmljIHdpbGwgYmUgdHJhbnNwb3J0ZWQgb24gYSBzaW5nbGUgRFRMUyBjb25uZWN0 aW9uPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQpPbiBGcmksIE5vdiA3LCAyMDE0 IGF0IDI6MTYgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGks DQoNCj5ObywgdGhlIFNSVFAgcGFja2V0cyBhcmUgc2VudCBvdXRzaWRlIHRoZSBEVExTIGNvbm5l Y3Rpb24uDQoNClRoYXQgaXMgdHJ1ZSwgYnV0IGRvbuKAmXQgeW91IGNyZWF0ZSBhIERUTFMgY29u bmVjdGlvbiBqdXN0IGJ5IG5lZ290aWF0aW5nIHRoZSBrZXlzIHRoYXQgeW91IGFyZSBnb2luZyB0 byB1c2UgZm9yIFNSVFA/DQoNCihJIGRvIGFncmVlIHRoYXQg4oCcY29ubmVjdGlvbuKAnSBpcyBt aXNsZWFkaW5nLikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiBUaHUsIE5vdiA2LCAy MDE0IGF0IDc6MDIgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K SGksDQoNCkFGQUlLLCB5b3UgdXNlIGEgRFRMUyBjb25uZWN0aW9uIChJIGJlbGlldmUgRFRMUy1T UlRQIHVzZXMgYW5vdGhlciB3b3JkLCB0aG91Z2gpIGFsc28gZm9yIFNSVFAuDQoNCkhvd2V2ZXIs IHRoZSB0ZXh0IGFscmVhZHkgZGVzY3JpYmVzIGhvdyB0byBzZXBhcmF0ZSBTUlRQIHBhY2tldHMg ZnJvbSBEVExTIHBhY2tldHMsIHNvIHRoZSBwaWVjZSBvZiB0ZXh0IEkgYnJvdWdodCB1cCBvbmx5 IGFwcGxpZXMgdG8gRFRMUyBwYWNrZXRzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50 IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IFBhdWwgS3l6aXZhdDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KU2VudDog 4oCOMDcv4oCOMTEv4oCOMjAxNCAwMDo0OQ0KVG86IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEJVTkRMRTogTWVhbmluZyBvZiAi dHJhbnNwb3J0ZWQgb24gRFRMUyI/DQpPbiAxMS82LzE0IDU6MzMgUE0sIEnDsWFraSBCYXogQ2Fz dGlsbG8gd3JvdGU6DQo+IDIwMTQtMTEtMDYgMjA6NDQgR01UKzAxOjAwIEp1c3RpbiBVYmVydGkg PGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj46DQo+PiBJIHRo aW5rIGl0IGlzIGNsZWFyIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZXNlIHByb3RvY29scyBiZWlu ZyBtdWx0aXBsZXhlZA0KPj4gYWNyb3NzIGEgc2luZ2xlIERUTFMgY29ubmVjdGlvbiBoZXJlLg0K Pg0KPiBJTUhPIHRoYXQncyBjbGVhciB0b28uIE1heSBiZSBpdCBzaG91bGQgYWxzbyBiZSBjbGVh ciB0aGF0IFNSVFAgaXMgbm90DQo+IGNhcnJpZWQgb24gdG9wIG9mIGEgRFRMUyBjb25uZWN0aW9u LCBidXQgb24gdG9wIG9mIGEgImNoYW5uZWwiDQo+IGVzdGFibGlzaGVkIHZpYSBhIERUTFMgaGFu ZHNoYWtlLg0KDQpJSVVDIChkdWJpb3VzKSwgU1JUUCBpcyBjYXJyaWVkIGRpcmVjdGx5IG9uIFVE UCwgbXVsdGlwbGV4ZWQgd2l0aCBEVExTDQptZXNzYWdlcy4gU1JUUCB1c2VzIGNlcnRhaW4gRFRM UyBtZXNzYWdlcyB0byBuZWdvdGlhdGUgdGhlIGtleXMsIHNvDQpwZXJoYXBzIHRoZSBrZXktbmVn b3RpYXRpb24gcGFydCBvZiBTUlRQIGNhbiBiZSBjb25zaWRlcmVkIHRvIGJlIHdpdGhpbg0Kc29t ZSBhc3BlY3Qgb2YgRFRMUy4gVGhhdCBtaWdodCBub3QgYmUgcGFydCBvZiB0aGUgRFRMUyAqY29u bmVjdGlvbiogLSBJDQp3b3VsZCB0aGluayB0aGF0IGlzIHJlc2VydmVkIGZvciB0aGUgRFRMUyBw YXlsb2FkIHBhY2tldHMuDQoNCkNsZWFybHkgdGhlIGxheWVyaW5nIGhlcmUgaXMgdmVyeSB3ZWly ZC4NCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIFBhdWwNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNp Y0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxt YWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMNCg0KDQo= --_000_786615F3A85DF44AA2A76164A71FE1AC35BB25FR711WXCHMBA03zeu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5IaTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mZ3Q7SSB0aGluayB0aGUgUkZDcyBleHBsYWluIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gRFRM UyBzZXNzaW9uIGFuZCBEVExTIGNvbm5lY3Rpb24g4oCTIHRoYXQgaXMgbm90IHdoYXQgSSB3YXMg YXNraW5nIGFib3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5XZWxsLCBpZiB0 aGUgUkZDcyB3b3VsZCBwcm92aWRlIGEgdGVybSBkZWZpbml0aW9uIHRoZW4gdGhlcmUgd291bGRu 4oCZdCBiZSBhbnkgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMUY0OTdEIj5UaGUgVExTIFJGQyBwcm92aWRlcyBhIGdsb3NzYXJ5LCB3aGlj aCBoZWxwcyBzb21laG93IGF0IGhpZ2ggbGV2ZWwsIGJ1dCBkb2VzbuKAmXQgcHJvdmlkZSBkZWZp bml0aW9ucyBhcyByZXF1aXJlZCBmb3IgcHJvdG9jb2wgZGlzY3Vzc2lvbnMgaGVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbmQgdGhlIHRo cmVhZCBqdXN0IGNvbmZpcm1zIHRoYXQgdGhlIHN1cHBvc2VkIGNvbmNlcHRzIGFyZSBub3QgcmVh bGx5IGNsZWFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+QWxicmVjaHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9i PiBTYW1zdGFnLCA4LiBOb3ZlbWJlciAyMDE0IDEwOjQ2PGJyPg0KPGI+VG86PC9iPiBKdXN0aW4g VWJlcnRpPGJyPg0KPGI+Q2M6PC9iPiBtbXVzaWNAaWV0Zi5vcmc7IFBhdWwgS3l6aXZhdDxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gQlVORExFOiBNZWFuaW5nIG9mICZxdW90O3Ry YW5zcG9ydGVkIG9uIERUTFMmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPkluIHRoaXMgY29udGV4dCwgdGhlIGtleSBleGNoYW5n ZSBtZWNoYW5pc20gaXMgaW1tYXRlcmlhbC4gVGhlIGtleQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZndDs8L3NwYW4+cG9pbnQgaXMgdGhhdCB5b3UgZG9uJ3QgbmVlZCB0byBkZW11bHRp cGxleCBTUlRQIHBhY2tldHMgZnJvbSBvdGhlcg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZndDs8L3NwYW4+c3R1ZmYgYXJyaXZpbmcgb24gdGhlIERUTFMgY29ubmVjdGlvbiwgYmVjYXVz ZSB0aG9zZSBwYWNrZXRzIGFyZW4ndA0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8 L3NwYW4+c2VudCBvbiB0aGUgRFRMUyBjb25uZWN0aW9uIChhbmQgdGhlcmVmb3JlIHRoZSBkZW11 eCBpcyBhbHJlYWR5DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5jb3Zl cmVkIGJ5IDU3NjQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Db3JyZWN0LCBhbmQgaXTigJlzIGFsc28gbWVudGlvbmVkIGluIEJV TkRMRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNvLCBhZ2FpbiwgdGhlIHN0YXRlbWVudCBJIHJlZmVycmVkIHRvIG9u bHkgY292ZXJzIHBhY2tldHMgd2hpY2ggYXJlIERUTFMgZW5jcnlwdGVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcSWYgbXVsdGlwbGUgcHJvdG9jb2xzIGFyZSB0cmFu c3BvcnRlZCBvbiBEVExTLCB0aGVyZSBNVVNUIGV4aXN0IGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gZGVzY3JpYmluZyBhIG1lY2hh bmlzbSBmb3IgaWRlbnRpZnkgZWFjaCBpbmRpdmlkdWFsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm90b2NvbC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvIHdlIGUuZy4g YXNzdW1lIHRoYXQgYWxsIERUTFMgZW5jcnlwdGVkIHRyYWZmaWMgd2lsbCBiZSB0cmFuc3BvcnRl ZCBvbiBhIHNpbmdsZSBEVExTIGNvbm5lY3Rpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTm92IDcsIDIw MTQgYXQgMjoxNiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+Tm8sIHRoZSBTUlRQIHBhY2tldHMg YXJlIHNlbnQgb3V0c2lkZSB0aGUgRFRMUyBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBpcyB0cnVl LCBidXQgZG9u4oCZdCB5b3UgY3JlYXRlIGEgRFRMUyBjb25uZWN0aW9uIGp1c3QgYnkgbmVnb3Rp YXRpbmcgdGhlIGtleXMgdGhhdCB5b3UgYXJlIGdvaW5nDQogdG8gdXNlIGZvciBTUlRQPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPihJIGRvIGFncmVlIHRoYXQg4oCcY29ubmVjdGlvbuKAnSBpcyBtaXNsZWFkaW5n Lik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBOb3YgNiwgMjAxNCBh dCA3OjAyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkhpLDxicj4NCjxicj4NCkFGQUlLLCB5b3UgdXNlIGEgRFRMUyBjb25uZWN0aW9uIChJIGJl bGlldmUgRFRMUy1TUlRQIHVzZXMgYW5vdGhlciB3b3JkLCB0aG91Z2gpIGFsc28gZm9yIFNSVFAu DQo8YnI+DQo8YnI+DQpIb3dldmVyLCB0aGUgdGV4dCBhbHJlYWR5IGRlc2NyaWJlcyBob3cgdG8g c2VwYXJhdGUgU1JUUCBwYWNrZXRzIGZyb20gRFRMUyBwYWNrZXRzLCBzbyB0aGUgcGllY2Ugb2Yg dGV4dCBJIGJyb3VnaHQgdXAgb25seSBhcHBsaWVzIHRvIERUTFMgcGFja2V0cy48YnI+DQo8YnI+ DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdp bmRvd3MgUGhvbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Og0KPC9zcGFuPjwvYj48YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYXVsIEt5eml2YXQ8L3Nw YW4+PC9hPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VudDogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCOMDcv4oCOMTEv4oCOMjAxNCAw MDo0OTwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOiA8L3Nw YW4+PC9iPjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTogW01NVVNJQ10gQlVORExFOiBNZWFuaW5n IG9mICZxdW90O3RyYW5zcG9ydGVkIG9uIERUTFMmcXVvdDs/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIDExLzYvMTQgNTozMyBQTSwg ScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZTo8YnI+DQomZ3Q7IDIwMTQtMTEtMDYgMjA6NDQgR01U JiM0MzswMTowMCBKdXN0aW4gVWJlcnRpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmp1YmVy dGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5qdWJlcnRpQGdvb2dsZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7Ojxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgaXQgaXMgY2xlYXIgd2UgYXJlIHRh bGtpbmcgYWJvdXQgdGhlc2UgcHJvdG9jb2xzIGJlaW5nIG11bHRpcGxleGVkPGJyPg0KJmd0OyZn dDsgYWNyb3NzIGEgc2luZ2xlIERUTFMgY29ubmVjdGlvbiBoZXJlLjxicj4NCiZndDs8YnI+DQom Z3Q7IElNSE8gdGhhdCdzIGNsZWFyIHRvby4gTWF5IGJlIGl0IHNob3VsZCBhbHNvIGJlIGNsZWFy IHRoYXQgU1JUUCBpcyBub3Q8YnI+DQomZ3Q7IGNhcnJpZWQgb24gdG9wIG9mIGEgRFRMUyBjb25u ZWN0aW9uLCBidXQgb24gdG9wIG9mIGEgJnF1b3Q7Y2hhbm5lbCZxdW90Ozxicj4NCiZndDsgZXN0 YWJsaXNoZWQgdmlhIGEgRFRMUyBoYW5kc2hha2UuPGJyPg0KPGJyPg0KSUlVQyAoZHViaW91cyks IFNSVFAgaXMgY2FycmllZCBkaXJlY3RseSBvbiBVRFAsIG11bHRpcGxleGVkIHdpdGggRFRMUyA8 YnI+DQptZXNzYWdlcy4gU1JUUCB1c2VzIGNlcnRhaW4gRFRMUyBtZXNzYWdlcyB0byBuZWdvdGlh dGUgdGhlIGtleXMsIHNvIDxicj4NCnBlcmhhcHMgdGhlIGtleS1uZWdvdGlhdGlvbiBwYXJ0IG9m IFNSVFAgY2FuIGJlIGNvbnNpZGVyZWQgdG8gYmUgd2l0aGluIDxicj4NCnNvbWUgYXNwZWN0IG9m IERUTFMuIFRoYXQgbWlnaHQgbm90IGJlIHBhcnQgb2YgdGhlIERUTFMgKmNvbm5lY3Rpb24qIC0g SSA8YnI+DQp3b3VsZCB0aGluayB0aGF0IGlzIHJlc2VydmVkIGZvciB0aGUgRFRMUyBwYXlsb2Fk IHBhY2tldHMuPGJyPg0KPGJyPg0KQ2xlYXJseSB0aGUgbGF5ZXJpbmcgaGVyZSBpcyB2ZXJ5IHdl aXJkLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGFua3MsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFBhdWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5tbXVzaWNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_786615F3A85DF44AA2A76164A71FE1AC35BB25FR711WXCHMBA03zeu_-- From nobody Mon Nov 10 10:45:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B271A8943 for ; Mon, 10 Nov 2014 10:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF9VkXk9ikfj for ; Mon, 10 Nov 2014 10:45:12 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856AC1A86FF for ; Mon, 10 Nov 2014 10:45:12 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so10028720wgh.41 for ; Mon, 10 Nov 2014 10:45:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wJz1ki0ylfX0RMtopo0eEsavELemwpffxHe0tz0NR8E=; b=Zn2PJw9ih+lp9cFMbC6L1NLuqkT/oj4YUa/2/ZylQp4am4ZMTG5tu6mIzE2DzN0oRe DctizQfbxxWQDYM1vFPovdcv/mN6JBG8fM7D1ePtutCJl+rJyfukXKOcoQ/X6q+4/RaX 7pv2CIzttkzMTUN8UDY9F3Pg5lEg4p8BlIDGC2ftx3luMZob5Dos02CxmBXmqOP/W6I+ b7/WdyvB7AMtJWbbMJgwIfVzC1snyubN6PY7ySOwFqfxM1bA+gON6qpJO0hF2yLEcca0 JxZtHlJPqIoNV/nIO+2b3o1ZzAflFLteDjN0oQ4P3KfKz/ti8Q/pZ99c0AdTwcAa4BUO 0ZJw== X-Gm-Message-State: ALoCoQk2249c33wOVjsjGgpXmo/iZEyE/z9QBhm9D1LJUz+4yymZjmbHIMDscvUDHxK3Pqqrk/fz X-Received: by 10.180.93.195 with SMTP id cw3mr32450143wib.68.1415645110130; Mon, 10 Nov 2014 10:45:10 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id x13sm24215983wjw.18.2014.11.10.10.45.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 10:45:08 -0800 (PST) Message-ID: <546107B2.8010100@jitsi.org> Date: Mon, 10 Nov 2014 19:45:06 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> <545EC6AA.2070505@jitsi.org> In-Reply-To: <545EC6AA.2070505@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/6cgoeJN9-ssNUDmmodgjHY8g6UU Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 18:45:15 -0000 FYI: this draft is now submitted: http://tools.ietf.org/html/draft-ivov-mmusic-ice-updates-00 Emil On 9.11.14, 2:43, Emil Ivov wrote: > On 8.11.14, 3:03, Justin Uberti wrote: >> It's getting hard to follow the idea here, so I suggest you write it up >> in a document and then we can try to find some time in Hono to sit down >> and discuss the pros/cons of continuous nomination and your approach. > > Indeed, this is a good idea. I have tried to describe all this here: > > https://github.com/emcho/ice-updates/blob/master/draft-ivov-mmusic-ice-updates-00.txt > > > > -- https://jitsi.org From nobody Mon Nov 10 13:25:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA531A1BA3 for ; Mon, 10 Nov 2014 13:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za71BCbFZ7os for ; Mon, 10 Nov 2014 13:25:52 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCD51A1B1B for ; Mon, 10 Nov 2014 13:25:52 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id f73so2522102yha.39 for ; Mon, 10 Nov 2014 13:25:51 -0800 (PST) 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=NStg14xINJC3NKNxIzjygZB2N9NK45GNc+EGW/F1Qjg=; b=RbvOPnfD8AahBkgNXmN1fw4xL7lHNOO4eL3IBnn1/KLoyRIzM/u2YWONm+/tUNmXbK 8Lkgx9W8XAWK6DabiZSB+JGLh3USjszaO/cAxMZBzKHQNFkhuKADOPDOu2BJOEBKBYdk KSnMv5rgQ9Hi6vfzQV3ICgNt75d/SNS86e3Djn1s/oiJizycnhIxPicvLQi7OUC0X8xS drLYwRMhLmnGkfH6xY1DcsSd/L6dP5MYm1P4PtG3VBxo1mMtMIJyp0xDo+dxPINhy3da jXnjuWqL3MRQpO5k8odJphx7A84NIzAE6yjMOLdaBXotI1mNG4dclkG0oioFgFjk6R1S Yprg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NStg14xINJC3NKNxIzjygZB2N9NK45GNc+EGW/F1Qjg=; b=CQpp2wnzNkd3ng4E/HSbY+YqjBv/nrQrtsnh0zd1hSIwaPOqsRnxeWUwwjgZvlZODW KH+TTSW9ts6HJtB7R7IdeHbJ79Yrf2oLFNGHNrNFOKGSt9UddCGa39Mfwp/EC652OE5A joYkCv1ReYyi8wesRq6wRHlGRsmJHzlOu5uZbKPfyyjtOCmsizZ4sYEcYT7oNOd/YqSb eTxwFl89tTuUTa4ZJwyXiKtFAnBMjcXj/qpfRU+x40JpimOikWa52ksBmflOFSgu0Tgl FyElvpSiM482BwuaJHf5D7LC4fCHQ7i4SKMq8MAoCjLwDkz6fpJJYQJ5xrNNw3/2aa5Y UVHw== X-Gm-Message-State: ALoCoQnzIcga1EH8NpnAdgopr06WAEE7j1xr+dBxE5OgnL/DDLJY6hT2s1OMNSv0MmGyrP2vjHUh X-Received: by 10.52.35.141 with SMTP id h13mr2704319vdj.47.1415654751742; Mon, 10 Nov 2014 13:25:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 10 Nov 2014 13:25:31 -0800 (PST) In-Reply-To: <546107B2.8010100@jitsi.org> References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> <545EC6AA.2070505@jitsi.org> <546107B2.8010100@jitsi.org> From: Justin Uberti Date: Mon, 10 Nov 2014 13:25:31 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=20cf30780d029a4d61050787ce2d Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4IO7EE6kXB9AFRh-knaJYzzd9mQ Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 21:25:54 -0000 --20cf30780d029a4d61050787ce2d Content-Type: text/plain; charset=UTF-8 I've written up a draft as well, detailing the goals discussed earlier in this thread, as well as our proposed solution. http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.txt Anyone up for discussing in the 1PM slot this afternoon? On Mon, Nov 10, 2014 at 10:45 AM, Emil Ivov wrote: > FYI: this draft is now submitted: > > http://tools.ietf.org/html/draft-ivov-mmusic-ice-updates-00 > > Emil > > > On 9.11.14, 2:43, Emil Ivov wrote: > >> On 8.11.14, 3:03, Justin Uberti wrote: >> >>> It's getting hard to follow the idea here, so I suggest you write it up >>> in a document and then we can try to find some time in Hono to sit down >>> and discuss the pros/cons of continuous nomination and your approach. >>> >> >> Indeed, this is a good idea. I have tried to describe all this here: >> >> https://github.com/emcho/ice-updates/blob/master/draft- >> ivov-mmusic-ice-updates-00.txt >> >> >> >> >> > -- > https://jitsi.org > --20cf30780d029a4d61050787ce2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've written up a draft as well, detailing the goals d= iscussed earlier in this thread, as well as our proposed solution.

=
http://juberti.github.io/draughts/nombis/draft-uberti-m= music-nombis.txt

Anyone up for discussing in the= 1PM slot this afternoon?

<= div class=3D"gmail_quote">On Mon, Nov 10, 2014 at 10:45 AM, Emil Ivov <emcho= @jitsi.org> wrote:
FYI: thi= s draft is now submitted:

http://tools.ietf.org/html/draft-ivov-mmusic-ice-upda= tes-00

Emil


On 9.11.14, 2:43, Emil Ivov wrote:
On 8.11.14, 3:03, Justin Uberti wrote:
It's getting hard to follow the idea here, so I suggest you write it up=
in a document and then we can try to find some time in Hono to sit down
and discuss the pros/cons of continuous nomination and your approach.

Indeed, this is a good idea. I have tried to describe all this here:

https://github.com/emcho/ice-updates/blob/master/draft-ivov-mmusic-ice-updates-00.txt





--
https://jitsi.org

--20cf30780d029a4d61050787ce2d-- From nobody Mon Nov 10 14:26:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33CF1A8979 for ; Mon, 10 Nov 2014 14:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkBfS3wTJa3w for ; Mon, 10 Nov 2014 14:26:08 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512601A8973 for ; Mon, 10 Nov 2014 14:26:08 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so9107055pab.5 for ; Mon, 10 Nov 2014 14:26:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FxkOjqYegSA7wU0rALHW89fHfCb8k+HKCH1amZqHpBg=; b=ZXrDeVCTZ6AlpPWDRomO7trEHtMNvOCr1/GsENN9xeOl9JeCNhxGvZ2C3u/7VY6K18 yufWfGjDk3rdMgUgGRpUd52ddfvIAO16c/etxf80JpUsX1M5GKx5BhVJPV6q8ChJNimQ /ibw/eoq/w34RfMplwzRBNPyhwWOHaEsZGbz3StE4Xs3Hk4nIoeXU/6rq0tQZB5lxf11 eVygFRrudJeSOekPm5clajJlLXTdOFc6QGm5Mih30qzjL1AzI+3N+21hBgBBl5YSvzIi ZEX8nwHIASN6GJ/+LL7klBLc+F1nJgQEVpknd6rbhC8bJ69isOHJdoDsunMXaLrZbLFJ d0Aw== X-Gm-Message-State: ALoCoQmYcBxx1AEukmno9eIlsT4BfJ7pMSR7x2GLJgXzr7VdVuQSprUGhlqCgn83Db4deo0LuEpr X-Received: by 10.68.220.169 with SMTP id px9mr7062056pbc.146.1415658368031; Mon, 10 Nov 2014 14:26:08 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com. [209.85.220.50]) by mx.google.com with ESMTPSA id ba7sm17414496pdb.87.2014.11.10.14.26.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 14:26:06 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id eu11so9167540pac.37 for ; Mon, 10 Nov 2014 14:26:06 -0800 (PST) X-Received: by 10.66.138.72 with SMTP id qo8mr5358212pab.148.1415658366814; Mon, 10 Nov 2014 14:26:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.100.227 with HTTP; Mon, 10 Nov 2014 14:25:46 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> <545EC6AA.2070505@jitsi.org> <546107B2.8010100@jitsi.org> From: Emil Ivov Date: Mon, 10 Nov 2014 23:25:46 +0100 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sxtXe0OR6PStwF37jQFDcEXyYjY Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 22:26:11 -0000 Could we maybe have the discussion in a way that would allow those of us not present in Hawaii to also attend? Emil On Mon, Nov 10, 2014 at 10:25 PM, Justin Uberti wrote: > I've written up a draft as well, detailing the goals discussed earlier in > this thread, as well as our proposed solution. > > http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.txt > > Anyone up for discussing in the 1PM slot this afternoon? > > On Mon, Nov 10, 2014 at 10:45 AM, Emil Ivov wrote: >> >> FYI: this draft is now submitted: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-ice-updates-00 >> >> Emil >> >> >> On 9.11.14, 2:43, Emil Ivov wrote: >>> >>> On 8.11.14, 3:03, Justin Uberti wrote: >>>> >>>> It's getting hard to follow the idea here, so I suggest you write it up >>>> in a document and then we can try to find some time in Hono to sit down >>>> and discuss the pros/cons of continuous nomination and your approach. >>> >>> >>> Indeed, this is a good idea. I have tried to describe all this here: >>> >>> >>> https://github.com/emcho/ice-updates/blob/master/draft-ivov-mmusic-ice-updates-00.txt >>> >>> >>> >>> >> >> -- >> https://jitsi.org > > -- https://jitsi.org From nobody Mon Nov 10 15:16:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1701ACF86 for ; Mon, 10 Nov 2014 15:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldkuO06lqMW2 for ; Mon, 10 Nov 2014 15:16:47 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415BC1ACFD8 for ; Mon, 10 Nov 2014 15:16:47 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 142so4551101ykq.8 for ; Mon, 10 Nov 2014 15:16:46 -0800 (PST) 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=RCfhIx7y9cNr7RVWwW8qVIvqQB5CN/VeZM3Y+cWU7GQ=; b=ipuAMltrCHv9PmW6gavtAPtIdE+czR5Ky0BQCaBeyixB1nPujsfJ4RUGLUxYxH4kkh dM83zV09XP8jtY27/PzqF38TGEWNXhEBPCX8XWj1THCSRHzUKrRfn3+K3Ia/8JF30OSa Dd8eA08zB7WqD2DozCyT0M2yiE0wmtVwJ/E9OnFOjgcmhLz7VlA1/2sJAc/UciwvILCe iANvNMphywESBBKcHRtC2Sh2C114nkjfx5n4A76x6AV9AxMAlzkgs+cH1LmtL7rNNCCI oLV3mdn4tzDjRfTNkGasXzLWo5wjkk9VZGXTU60fdTKRCsZepVyzhOOWgiHmKQHduzuS CsJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RCfhIx7y9cNr7RVWwW8qVIvqQB5CN/VeZM3Y+cWU7GQ=; b=fL5pB2emWvPkHWF7P2fht/l/jNl2AaQw2FQ0ObupShPrEcReYI06hCs+wz1fadIXrq 0/j7FkMQ+rlorfCa4sXQq3calyypwQm7SNDkN5G0xYqCb7TKeGhBqcVTQd2czWFPsLdY SNlrsrpDX1xJ5EbPNLu7PXEr+BxaUKl/g3U3ir3R+gIKa/Tw6IqHFFm4JbcGskrE83rZ /01KfuYtuzh+M7MZTqp48WzyOvDGKhcmY0Ys0HUpO+WmwMgz4Bk8aVtUggUIZz7JfImp H9MUlJ60opQVwmKCIV3W66JnOW+hCwPC64lUIPBDbkqQ3mJIsSq7FZwgWzS8cgV82jNz LNDQ== X-Gm-Message-State: ALoCoQnxPdbSjep94foUYA7KAuGk2lv9QWMEgRcFhRG533u6jciNaqDThQphgxB+YCwOOaaJRd3z X-Received: by 10.220.177.10 with SMTP id bg10mr232477vcb.60.1415661406546; Mon, 10 Nov 2014 15:16:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 10 Nov 2014 15:16:26 -0800 (PST) In-Reply-To: References: <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <545911E9.3070300@ericsson.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org> <545EC6AA.2070505@jitsi.org> <546107B2.8010100@jitsi.org> From: Justin Uberti Date: Mon, 10 Nov 2014 15:16:26 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c2c7aa428d680507895b87 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/z8dNCuMnHJyXDFHK3xXw0Z9cKww Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:16:50 -0000 --001a11c2c7aa428d680507895b87 Content-Type: text/plain; charset=UTF-8 Let's meet in the lounge upstairs. I'm at the back table. Emil, we might have to have a sidebar here in person and then have a call later to discuss next steps. On Mon, Nov 10, 2014 at 1:25 PM, Justin Uberti wrote: > I've written up a draft as well, detailing the goals discussed earlier in > this thread, as well as our proposed solution. > > http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.txt > > Anyone up for discussing in the 1PM slot this afternoon? > > On Mon, Nov 10, 2014 at 10:45 AM, Emil Ivov wrote: > >> FYI: this draft is now submitted: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-ice-updates-00 >> >> Emil >> >> >> On 9.11.14, 2:43, Emil Ivov wrote: >> >>> On 8.11.14, 3:03, Justin Uberti wrote: >>> >>>> It's getting hard to follow the idea here, so I suggest you write it up >>>> in a document and then we can try to find some time in Hono to sit down >>>> and discuss the pros/cons of continuous nomination and your approach. >>>> >>> >>> Indeed, this is a good idea. I have tried to describe all this here: >>> >>> https://github.com/emcho/ice-updates/blob/master/draft- >>> ivov-mmusic-ice-updates-00.txt >>> >>> >>> >>> >>> >> -- >> https://jitsi.org >> > > --001a11c2c7aa428d680507895b87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Let's meet in the lounge upstairs. I'm at = the back table.


Emil, we might have to have a sidebar here i= n person and then have a call later to discuss next steps.


On Mon, N= ov 10, 2014 at 1:25 PM, Justin Uberti <juberti@google.com> = wrote:
I've written = up a draft as well, detailing the goals discussed earlier in this thread, a= s well as our proposed solution.

http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.txt=

Anyone up for discussing in the 1PM slot this a= fternoon?

On Mon, Nov 10, 2014 at 1= 0:45 AM, Emil Ivov <emcho@jitsi.org> wrote:
FYI: this draft is now submitted:

http://tools.ietf.org/html/draft-ivov-mmusic-ice-upda= tes-00

Emil


On 9.11.14, 2:43, Emil Ivov wrote:
On 8.11.14, 3:03, Justin Uberti wrote:
It's getting hard to follow the idea here, so I suggest you write it up=
in a document and then we can try to find some time in Hono to sit down
and discuss the pros/cons of continuous nomination and your approach.

Indeed, this is a good idea. I have tried to describe all this here:

https://github.com/emcho/ice-updates/blob/master/draft-ivov-mmusic-ice-updates-00.txt





--
https://jitsi.org


--001a11c2c7aa428d680507895b87-- From nobody Mon Nov 10 19:06:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336451AD4F4; Mon, 10 Nov 2014 18:59:46 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.595 X-Spam-Level: X-Spam-Status: No, score=-7.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRUm95ffSeEv; Mon, 10 Nov 2014 18:59:44 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74941AD4FC; Mon, 10 Nov 2014 18:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1415674782; x=1447210782; h=x-ojodefuego:message-id:x-mailer:date:to:from:subject: content-type; bh=me+wBoVNB+yVTmICEEzw1gOHtj/r51N0uc8iSAXIe5U=; b=ikk6JLZBL7vaYMh+zl4isqS5QCKxoel5mduK1nHIUTpc3tKHcPgviZuG 8pxhqEK3SDZVtNGLNTN8YkexQdofdzFWdJ7oxF5nlPhhIch5WQkSPedRt Pa/phU00uGvLtJLMqafzJvtQ14DvUn5Xyia7vcveFEZ2epK0Wo28J0FKk s=; X-IronPort-AV: E=McAfee;i="5600,1067,7618"; a="83162748" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 18:59:42 -0800 X-IronPort-AV: E=Sophos;i="5.07,357,1413270000"; d="scan'208";a="773491541" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 18:59:42 -0800 Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id sAB2xeKk019413; Mon, 10 Nov 2014 18:59:40 -0800 X-IronPort-AV: E=Sophos;i="5.07,357,1413270000"; d="scan'208";a="773491474" X-ojodefuego: yes Received: from unknown (HELO dhcp-97d8.meeting.ietf.org) ([10.64.165.21]) by Ironmsg03-L.qualcomm.com with ESMTP; 10 Nov 2014 18:59:38 -0800 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Mon, 10 Nov 2014 18:59:27 -0800 To: "clue@ietf.org" , , , , From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QRNidyYsbgphjFGeOPxEiOWk-zs X-Mailman-Approved-At: Mon, 10 Nov 2014 19:06:57 -0800 Subject: [MMUSIC] New mailing list for human language discussions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:59:46 -0000 I'm sending this message to the IETF lists where some discussions occurred on the work to let people know that we have a new mailing list for the work. If you have any interest in it, please subscribe. https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- MIPS: Meaningless Indicator of Processor Speed. From nobody Tue Nov 11 01:44:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BCF1A888D for ; Tue, 11 Nov 2014 01:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4xyGB7S9q4h for ; Tue, 11 Nov 2014 01:44:42 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854151A897A for ; Tue, 11 Nov 2014 01:44:41 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id z6so1220777yhz.8 for ; Tue, 11 Nov 2014 01:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=SPc6W5iYrs/+JvaqIhUEHzqBo7ZODyj4sIVXe+cSjuk=; b=SSD/xBgi0QF/Cs3RQGpKIoRfBP62zCJI/hSVtz8wBlspFERIsx4dRKDC3p1VjZkaBT 3aokCMNwVGJ/5yz00dv+jD4zeSrKYmVNtX3nPNVGGdxF23Vd7eAxT2D2ss2BJXzyc9MC i1+65PPBb96Fjll2D12IVAMUgsFbQa87YzGk4NK92qo60cj2ciuc41Gj0KG6hvB6F7pj p2g3rrLMma1E1y+opq8y09Dneb135vRlSQYa1+IXpKd0RfdU6eHcVo9XhZR/OODjvVKw nOx2MzpK8FbZCNSIMoJyo6GELP36Tp9B4cw1Kz81m04OVRfNZgVjjpCHuVfclg5G+0Nd aPUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=SPc6W5iYrs/+JvaqIhUEHzqBo7ZODyj4sIVXe+cSjuk=; b=O4+zD0r/wyK38KJYKcMIKsK49NHJ2iYJhxqqpg7Cmg7qZD+SJztD1sEu2mhcy5Vphj MXQlcIu3BlMAzdPwhhWpS57bsRAEaZF+Re2gciN7YTOBMi9CFphqhZJxslEDffSlAFPb Mln4fd9ENfxxr+cMjhL6IKsgn9RRd1L8H4KrzaslNp1u2oXbjJHPdP4rbmV1ijZxZftM RsOH2IwBfsl6VLWdwlBWGuoPFWL7LKNqbYBptkioJzTuBHGdrXUUJNMBoVZqqmVCFDVy Nc2bnf/4Zr51kAjZQbFmEPkhzgrANwc0af4mjEn1i6ACQHkeGshezijFWOtw16ky+P43 zLxA== X-Gm-Message-State: ALoCoQmjBBYdfNDg97p0sMPCUglIdqM4aaYC2oPTpCKT8BBwTfYp75bK5tedDDlZRzSSt0yt770E X-Received: by 10.220.124.4 with SMTP id s4mr5626364vcr.38.1415699080594; Tue, 11 Nov 2014 01:44:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Tue, 11 Nov 2014 01:44:20 -0800 (PST) From: Justin Uberti Date: Tue, 11 Nov 2014 01:44:20 -0800 Message-ID: To: "mmusic@ietf.org" , Brandon Williams , Varun Singh , Dan Wing , Martin Thomson , Emil Ivov , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Christer Holmberg , Jonathan Lennox , Bernard Aboba , "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=089e0115fe3acef8910507922099 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yeHwFOCOgnA-t5FLLeJJMJgO6Cs Subject: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:44:44 -0000 --089e0115fe3acef8910507922099 Content-Type: text/plain; charset=UTF-8 Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today to discuss the goals for the work to improve ICE nomination. In short, there was good consensus that the goals outlined in http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html (updated since the meeting) are the correct goals to be shooting for, even if the exact mechanisms aren't completely nailed down. We think the goals enumerated by Emil in his email earlier this week are all covered by the goals in this document. It also seemed reasonable to adopt the work to merge Regular and Aggressive Nomination in ICE-bis, and have the Continuous Nomination change be its own document. While there was some interest in figuring out how ICE could support multiple selected pairs simultaneously, this was agreed to be out of scope for now. We can discuss more in the WG meeting; Ari, can you set aside some agenda time? --089e0115fe3acef8910507922099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Several of us (Bernard, Jonathan, Varun, Martin, Brandon, = Pal) met today to discuss the goals for the work to improve ICE nomination.=

In short, there was good consensus that the goals o= utlined in=C2=A0
http://juberti.github.io/draughts/nomb= is/draft-uberti-mmusic-nombis.html (updated since the meeting)
are the correct goals to be shooting for, even if the exact mechanism= s aren't completely nailed down. We think the goals enumerated by Emil = in his email earlier this week are all covered by the goals in this documen= t.

It also seemed reasonable to adopt the work to = merge Regular and Aggressive Nomination in ICE-bis, and have the Continuous= Nomination change be its own document. While there was some interest in fi= guring out how ICE could support multiple selected pairs simultaneously, th= is was agreed to be out of scope for now.

We can d= iscuss more in the WG meeting; Ari, can you set aside some agenda time?
--089e0115fe3acef8910507922099-- From nobody Tue Nov 11 02:48:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F5A1ACD8E for ; Tue, 11 Nov 2014 02:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvJPEAacBFC1 for ; Tue, 11 Nov 2014 02:48:16 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BFC1A894F for ; Tue, 11 Nov 2014 02:48:15 -0800 (PST) Received: by mail-yk0-f179.google.com with SMTP id 131so5364573ykp.10 for ; Tue, 11 Nov 2014 02:48:15 -0800 (PST) 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 :content-type; bh=5hhqb76G7LWwDKisQY0xAs7EOkj0ioeUebXgMDSz8IM=; b=CGn1pUhJp6XRhoo2qHcb+t643ylZxbmU04wYW03HDBD+hbLxqvTQ10ECiNqQVsLrNW PcO9ORgrrx4iFdIenupCEFcCezDADfsDMoyEPHEprbu8tFReCiq0qGPA3JX06Z9q2c2w 2ZoC6UN3grVOTqTAIxTmt/up7mhNzLT1lBfShNcaCwfSHZcf15GO+qMbDkwaKfv/7Kmo p/krnymi+//EhoPkenz1BcqSummzO919Fs46eiSJ45FwwnOh3OysngmrLSavVH0+VuJg JKl3MdllwX2uH8goF4jCTq85UHOMyl0cG/lHR+PH9VwGbtQoZWt8joAUIoA2UVO4RFbK g0nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=5hhqb76G7LWwDKisQY0xAs7EOkj0ioeUebXgMDSz8IM=; b=PvliL8uwpP1CkrN31a1/dOnX2YMQSm7trfF0qx2F2HlPpIsRaUYqHtVA/BiwRF7XV6 0VzDVe8yN9ef5EEHvUdDVnxj2bpolflsKmDCYNtiTivUd+5ioj8/OBn2StmOQ7yxmHA+ LZQo+nL9P9SWneL0VDCvYd8LGyBn2vPfiYQcBZ083uDZQn5Qw7E/6X9Rv0JHvQuubUot 2ZrPTk8I/4JUGa8RGiRhiyZbV2bU5CD5FR1wLC0YW1bVnrypEwgkLmx9udPzk7AqR/Os Kw6TMR+tDaDzaJpck4B+ihAVSbsVOnsB37GAulir/0pAn2POT9UIvEChUzaFLVmg7qwS hIqA== X-Gm-Message-State: ALoCoQlokvVcnv4HOhfBQMsnVE/kfqkkHFZfQZy6hBA7evXau6jSNF636ZmiQ+gxZlf74XpzWxVr X-Received: by 10.220.136.17 with SMTP id p17mr26196182vct.3.1415702895163; Tue, 11 Nov 2014 02:48:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Tue, 11 Nov 2014 02:47:55 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Tue, 11 Nov 2014 02:47:55 -0800 Message-ID: To: "mmusic@ietf.org" , Brandon Williams , Varun Singh , Dan Wing , Martin Thomson , Emil Ivov , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Christer Holmberg , Jonathan Lennox , Bernard Aboba , "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a113642e42c9c30050793041a Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hnj3uNE6ntr8oynZj3SAu-j_xK4 Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 10:48:21 -0000 --001a113642e42c9c30050793041a Content-Type: text/plain; charset=UTF-8 One other note - although Dan wasn't present, the consensus was that the continuous nomination solution provides an effective solution to the ICE issues raised in draft-singh-avtcore-mprtp, draft-wing-ice-mobility, and draft-williams-peer-redirect. On Tue, Nov 11, 2014 at 1:44 AM, Justin Uberti wrote: > Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today > to discuss the goals for the work to improve ICE nomination. > > In short, there was good consensus that the goals outlined in > http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html > (updated since the meeting) > are the correct goals to be shooting for, even if the exact mechanisms > aren't completely nailed down. We think the goals enumerated by Emil in his > email earlier this week are all covered by the goals in this document. > > It also seemed reasonable to adopt the work to merge Regular and > Aggressive Nomination in ICE-bis, and have the Continuous Nomination change > be its own document. While there was some interest in figuring out how ICE > could support multiple selected pairs simultaneously, this was agreed to be > out of scope for now. > > We can discuss more in the WG meeting; Ari, can you set aside some agenda > time? > --001a113642e42c9c30050793041a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One other note - although Dan wasn't present, the cons= ensus was that the continuous nomination solution provides an effective sol= ution to the ICE issues raised in draft-singh-avtcore-mprtp, draft-wing-ice= -mobility, and draft-williams-peer-redirect.

On Tue, Nov 11, 2014 at 1:44 AM, Justin Ub= erti <juberti@google.com> wrote:
Several of us (Bernard, Jonathan, Varun, Martin, B= randon, Pal) met today to discuss the goals for the work to improve ICE nom= ination.

In short, there was good consensus that the= goals outlined in=C2=A0
are the correct goals to be shooting for, e= ven if the exact mechanisms aren't completely nailed down. We think the= goals enumerated by Emil in his email earlier this week are all covered by= the goals in this document.

It also seemed reason= able to adopt the work to merge Regular and Aggressive Nomination in ICE-bi= s, and have the Continuous Nomination change be its own document. While the= re was some interest in figuring out how ICE could support multiple selecte= d pairs simultaneously, this was agreed to be out of scope for now.

We can discuss more in the WG meeting; Ari, can you set a= side some agenda time?

--001a113642e42c9c30050793041a-- From nobody Tue Nov 11 04:32:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5C51A1B8B for ; Tue, 11 Nov 2014 04:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjdhyXHAt3sY for ; Tue, 11 Nov 2014 04:32:04 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D531A1A46 for ; Tue, 11 Nov 2014 04:32:04 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so11371329wgh.39 for ; Tue, 11 Nov 2014 04:32:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aGZPDYWJMzJ62Dy+bU9OuYwJhS70ZPc9Z+u8Gf1xFCo=; b=mA19eQ7pfNbMUaKkVma8ow3YRtBMENUfmqdJwL+57PESJwWaCoJR59I2aFhtrIV7ej 8waRkLdFeMYgrDhe8GpYwIbJ9t3UBp2qiYe8xUtaF8HUISY/TErXavp8M8Ii6q1I+lSr pxst+mVhBaHXK0o1N5RXQuTZR6Tcq1UYKTxeK4xT5RwI+CgGXrcnCM6GyoSERLgPSlfc igXHwKTvMtSttfYlcit/2BROjBBBtReVZG8PNfgb4yA5l+paFLF+b7KMH3ACuxU4YfLf izCIlXdi3DD60a1BQxIYhbULkKVy6/VDmpWn/MuTyqf/8jtCGowuRb742BBbwW0G7S13 dgrA== X-Gm-Message-State: ALoCoQmEkj+1g003cTGn1MXZbjGL+PXOPAAoJOnI/4MU6K45zFmFDPCVeoCV1c0ece/n/vbQ63fD X-Received: by 10.194.95.100 with SMTP id dj4mr12225381wjb.48.1415709121130; Tue, 11 Nov 2014 04:32:01 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id s10sm17308131wix.14.2014.11.11.04.31.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 04:31:59 -0800 (PST) Message-ID: <546201BE.1000102@jitsi.org> Date: Tue, 11 Nov 2014 13:31:58 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti , "mmusic@ietf.org" , Brandon Williams , Varun Singh , Dan Wing , Martin Thomson , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Christer Holmberg , Jonathan Lennox , Bernard Aboba , "Pal Martinsen (palmarti)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/he55Ud7HemS399B3waIPzsqiFQc Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 12:32:05 -0000 On 11.11.14, 10:44, Justin Uberti wrote: > Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today > to discuss the goals for the work to improve ICE nomination. > > In short, there was good consensus that the goals outlined in > http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html > (updated since the meeting) > are the correct goals to be shooting for, even if the exact mechanisms > aren't completely nailed down. We think the goals enumerated by Emil in > his email earlier this week are all covered by the goals in this document. Hm? I might have missed something but how does it cover the need to detect an end of currently available candidates? How does one know when it is safe to release unused candidates? Whether we call it an ICE restart or not, the mechanism we come up with would need to support these things. Emil -- https://jitsi.org From nobody Tue Nov 11 04:51:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060061A87E8 for ; Tue, 11 Nov 2014 04:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvoRmjHQOJYo for ; Tue, 11 Nov 2014 04:51:15 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9A71A8714 for ; Tue, 11 Nov 2014 04:51:15 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so11412296wgh.39 for ; Tue, 11 Nov 2014 04:51:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WRaKIpd4fi/XNSHxfE6SdJR+LriCStQyzjUy+srHiS4=; b=OjkOdahZOPWiLV7ytyZzgozxa6NyzKr1+8V5oyuk9IbFTvpukud/XzjHvLnkU4ptQ6 Zqq9jrb23ELReWH02SfHq18KIaOXQphqsCjBFvsamsBKoJWS67sLyq0N306x058s7xGG VJ5712EJy8sfUW/nWzxgrm6y0slRzKJWRMZDmUEcGK/zdLQ7JdaTyPVUh4EgjdIfJBwP C93MKk5Ta/UM+iFFN48b+xj55gijZfdr5qDSuUtCLd0yt8H8qxzV9kXc/GhMoKpiG/Kg 4ayjHR4rI0c66iCZKtksnBlH9EZ8MpKC2LJhUIrNuQJVwmXFh8dTrwW61W5Cv2LnLgjn /DXQ== X-Gm-Message-State: ALoCoQkrj8+1KWsvkbQxvSna4ecOLhfWY3MKnMQqzxkl0qyq5+iIJH+MtQr4jNP2H3V/BgTlrnsS X-Received: by 10.194.9.1 with SMTP id v1mr52511483wja.124.1415710273871; Tue, 11 Nov 2014 04:51:13 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id d14sm27166430wjz.26.2014.11.11.04.51.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 04:51:12 -0800 (PST) Message-ID: <5462063E.1010008@jitsi.org> Date: Tue, 11 Nov 2014 13:51:10 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti , "mmusic@ietf.org" , Brandon Williams , Varun Singh , Dan Wing , Martin Thomson , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Christer Holmberg , Jonathan Lennox , Bernard Aboba , "Pal Martinsen (palmarti)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Kv7DIPLEqmPzb7FaHc4Qx4zb9rM Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 12:51:19 -0000 One more comment here: On 11.11.14, 10:44, Justin Uberti wrote: > In short, there was good consensus that the goals outlined in > http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html > (updated since the meeting) While I agree with the majority of the goals expressed in the above document there is one that sounds a bit naïve. Section 3.4 says: While this could be done using an ICE restart, as described in [RFC5245], Section 9.1, the ICE restart may have unintended consequences, such as causing the remote side to regather all candidates. Instead, it would be best if the new candidates could be trickled, as discussed in [I-D.ietf-mmusic-trickle-ice], but even after ICE processing has completed. Unless you are planning on mandating that every ICE agent on the planet must never release a single port number and must continuously block NAT and TURN resources it is not using, then the remote side will have to re-gather candidates regardless of whether you call your scheme an ICE restart or not. This is not so hard to resolve so I am not sure how to explain the insistence to not address it. Emil -- https://jitsi.org From nobody Tue Nov 11 11:35:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C941A87DF for ; Tue, 11 Nov 2014 11:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdzb1aoJSAMa for ; Tue, 11 Nov 2014 11:35:07 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE9A1A87F0 for ; Tue, 11 Nov 2014 11:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7520; q=dns/txt; s=iport; t=1415734506; x=1416944106; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TiDgXY9coTtRkKqbzbgbarXI5jyI8hMkiYqr3nu0JA4=; b=kWyxSJjDA2lP+MnO+AEuTTN/oYqWqDBXEgXuNSaHE9VSUY+BvwmBdnaC hTDB7yxoawPxn09I/UJtflUrZERr1JJPaZ9mHXTCqD840pGGi+s4pM3qY KysuTTNj+JVau4JjXoDnedOETKOpbtsJvEyFvCgoqP5pl/M3WGLOwXD8t w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQJAApkYlStJV2Y/2dsb2JhbABcgw5UWQSDAsc0gXCHTQIcfBYBAQEBAX2EAwEBBCNWEAIBCA4xAwICAjAUEQIEDgUbiCYNuGOWLAEBAQEBAQEBAQEBAQEBAQEBAQEBGJAyEQFQB4J3NoEeBYUgAopsgiOEU4chgTQ9jTyDKYQKg3psAYEOOYEDAQEB X-IronPort-AV: E=Sophos; i="5.07,362,1413244800"; d="scan'208,217"; a="95620296" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 11 Nov 2014 19:35:05 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sABJZ58N013534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 19:35:05 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 13:35:05 -0600 From: "Pal Martinsen (palmarti)" To: Justin Uberti Thread-Topic: Notes from Continuous Nomination discussion Thread-Index: AQHP/ZQe0+8t6IkIME+H0r7ph/eakJxbo1KAgACTTYA= Date: Tue, 11 Nov 2014 19:35:04 +0000 Message-ID: <37067FC0-B61F-4A5E-BF09-8AF2DC1140B6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.217] Content-Type: multipart/alternative; boundary="_000_37067FC0B61F4A5EBF098AF2DC1140B6ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/04J8LpUrc1hOQQFmB-dveqoPQUM Cc: Jonathan Lennox , =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , "Dan Wing \(dwing\)" , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:35:14 -0000 --_000_37067FC0B61F4A5EBF098AF2DC1140B6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxMSBOb3YgMjAxNCwgYXQgMDA6NDcsIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xl LmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCk9uZSBvdGhlciBub3Rl IC0gYWx0aG91Z2ggRGFuIHdhc27igJl0IHByZXNlbnQsIHRoZSBjb25zZW5zdXMgd2FzIHRoYXQg dGhlIGNvbnRpbnVvdXMgbm9taW5hdGlvbiBzb2x1dGlvbiBwcm92aWRlcyBhbiBlZmZlY3RpdmUg c29sdXRpb24gdG8gdGhlIElDRSBpc3N1ZXMgcmFpc2VkIGluIGRyYWZ0LXNpbmdoLWF2dGNvcmUt bXBydHAsIGRyYWZ0LXdpbmctaWNlLW1vYmlsaXR5LCBhbmQgZHJhZnQtd2lsbGlhbXMtcGVlci1y ZWRpcmVjdC4NCg0KUmVnYXJkaW5nIE1JQ0UuDQoNClRoZSBtYWluIGdvYWwgdGhlcmUgaXMgdG8g dHJ5IG91dCBhbnkgb2YgdGhlIG9sZCByZW1vdGUgY2FuZGlkYXRlcyBiZWZvcmUgeW91IGFjdHVh bGx5IHRyaWNrbGUgeW91ciBuZXcgbG9jYWwgY2FuZGlkYXRlcy4gVGhlcmUgaXMgYSBjaGFuY2Ug dGhhdCB0aGUgb2xkIE5BVCBiaW5kaW5nIG9uIHRoZSByZW1vdGUgc2lkZSBtaWdodCB3b3JrIGlm IHRoZSBOQVQgaXMgb2YgdGhlIHR5cGUg4oCcZ29vZOKAnS4gSWRlYSBpcyB0byBnZXQgbWVkaWEg Zmxvd2luZyB3aXRob3V0IHRoZSB1c2Ugb2YgdGhlIHNpZ25hbGxpbmcgY2hhbm5lbC4gIFRoZSB0 cmlja2xpbmcgb2YgdGhlIG5ldyBsb2NhbCBjYW5kaWRhdGVzIHNob3VsZCBoYXBwZW4gaW4gcGFy YWxsZWwuDQoNCldlIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCB0byBmaXQgaW50byB0aGUgY29udGlu dW91cyBub21pbmF0aW9uIGFuZCB0cmlja2xlIHNjaGVtZSBvbmNlIHRoZSBkdXN0IHNldHRsZXMu DQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KT24gVHVlLCBOb3YgMTEsIDIwMTQgYXQgMTo0NCBBTSwg SnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5j b20+PiB3cm90ZToNClNldmVyYWwgb2YgdXMgKEJlcm5hcmQsIEpvbmF0aGFuLCBWYXJ1biwgTWFy dGluLCBCcmFuZG9uLCBQYWwpIG1ldCB0b2RheSB0byBkaXNjdXNzIHRoZSBnb2FscyBmb3IgdGhl IHdvcmsgdG8gaW1wcm92ZSBJQ0Ugbm9taW5hdGlvbi4NCg0KSW4gc2hvcnQsIHRoZXJlIHdhcyBn b29kIGNvbnNlbnN1cyB0aGF0IHRoZSBnb2FscyBvdXRsaW5lZCBpbg0KaHR0cDovL2p1YmVydGku Z2l0aHViLmlvL2RyYXVnaHRzL25vbWJpcy9kcmFmdC11YmVydGktbW11c2ljLW5vbWJpcy5odG1s ICh1cGRhdGVkIHNpbmNlIHRoZSBtZWV0aW5nKQ0KYXJlIHRoZSBjb3JyZWN0IGdvYWxzIHRvIGJl IHNob290aW5nIGZvciwgZXZlbiBpZiB0aGUgZXhhY3QgbWVjaGFuaXNtcyBhcmVuJ3QgY29tcGxl dGVseSBuYWlsZWQgZG93bi4gV2UgdGhpbmsgdGhlIGdvYWxzIGVudW1lcmF0ZWQgYnkgRW1pbCBp biBoaXMgZW1haWwgZWFybGllciB0aGlzIHdlZWsgYXJlIGFsbCBjb3ZlcmVkIGJ5IHRoZSBnb2Fs cyBpbiB0aGlzIGRvY3VtZW50Lg0KDQpJdCBhbHNvIHNlZW1lZCByZWFzb25hYmxlIHRvIGFkb3B0 IHRoZSB3b3JrIHRvIG1lcmdlIFJlZ3VsYXIgYW5kIEFnZ3Jlc3NpdmUgTm9taW5hdGlvbiBpbiBJ Q0UtYmlzLCBhbmQgaGF2ZSB0aGUgQ29udGludW91cyBOb21pbmF0aW9uIGNoYW5nZSBiZSBpdHMg b3duIGRvY3VtZW50LiBXaGlsZSB0aGVyZSB3YXMgc29tZSBpbnRlcmVzdCBpbiBmaWd1cmluZyBv dXQgaG93IElDRSBjb3VsZCBzdXBwb3J0IG11bHRpcGxlIHNlbGVjdGVkIHBhaXJzIHNpbXVsdGFu ZW91c2x5LCB0aGlzIHdhcyBhZ3JlZWQgdG8gYmUgb3V0IG9mIHNjb3BlIGZvciBub3cuDQoNCldl IGNhbiBkaXNjdXNzIG1vcmUgaW4gdGhlIFdHIG1lZXRpbmc7IEFyaSwgY2FuIHlvdSBzZXQgYXNp ZGUgc29tZSBhZ2VuZGEgdGltZT8NCg0KDQo= --_000_37067FC0B61F4A5EBF098AF2DC1140B6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <46350C955C74E348A5031453538A93E5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxMSBO b3YgMjAxNCwgYXQgMDA6NDcsIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJl cnRpQGdvb2dsZS5jb20iIGNsYXNzPSIiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5PbmUgb3RoZXIgbm90ZSAtIGFsdGhvdWdo IERhbiB3YXNu4oCZdCBwcmVzZW50LCB0aGUgY29uc2Vuc3VzIHdhcyB0aGF0IHRoZSBjb250aW51 b3VzIG5vbWluYXRpb24gc29sdXRpb24gcHJvdmlkZXMgYW4gZWZmZWN0aXZlIHNvbHV0aW9uIHRv IHRoZSBJQ0UgaXNzdWVzIHJhaXNlZCBpbiBkcmFmdC1zaW5naC1hdnRjb3JlLW1wcnRwLCBkcmFm dC13aW5nLWljZS1tb2JpbGl0eSwgYW5kIGRyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJlY3QuPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PlJlZ2FyZGluZyBNSUNFLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+VGhlIG1haW4gZ29hbCB0aGVyZSBpcyB0byB0cnkgb3V0IGFueSBvZiB0aGUgb2xkIHJlbW90 ZSBjYW5kaWRhdGVzIGJlZm9yZSB5b3UgYWN0dWFsbHkgdHJpY2tsZSB5b3VyIG5ldyBsb2NhbCBj YW5kaWRhdGVzLiBUaGVyZSBpcyBhIGNoYW5jZSB0aGF0IHRoZSBvbGQgTkFUIGJpbmRpbmcgb24g dGhlIHJlbW90ZSBzaWRlIG1pZ2h0IHdvcmsgaWYgdGhlIE5BVCBpcyBvZiB0aGUgdHlwZSDigJxn b29k4oCdLiBJZGVhIGlzIHRvIGdldCBtZWRpYSBmbG93aW5nDQogd2l0aG91dCB0aGUgdXNlIG9m IHRoZSBzaWduYWxsaW5nIGNoYW5uZWwuICZuYnNwO1RoZSB0cmlja2xpbmcgb2YgdGhlIG5ldyBs b2NhbCBjYW5kaWRhdGVzIHNob3VsZCBoYXBwZW4gaW4gcGFyYWxsZWwuJm5ic3A7PC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5XZSB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQg dG8gZml0IGludG8gdGhlIGNvbnRpbnVvdXMgbm9taW5hdGlvbiBhbmQgdHJpY2tsZSBzY2hlbWUg b25jZSB0aGUgZHVzdCBzZXR0bGVzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+Li0uPC9kaXY+DQo8ZGl2PlDDpWwtRXJpazwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P biBUdWUsIE5vdiAxMSwgMjAxNCBhdCAxOjQ0IEFNLCBKdXN0aW4gVWJlcnRpIDxzcGFuIGRpcj0i bHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDs8L3NwYW4+ IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+U2V2ZXJhbCBvZiB1cyAoQmVybmFy ZCwgSm9uYXRoYW4sIFZhcnVuLCBNYXJ0aW4sIEJyYW5kb24sIFBhbCkgbWV0IHRvZGF5IHRvIGRp c2N1c3MgdGhlIGdvYWxzIGZvciB0aGUgd29yayB0byBpbXByb3ZlIElDRSBub21pbmF0aW9uLjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkluIHNob3J0LCB0aGVyZSB3YXMgZ29vZCBjb25zZW5zdXMgdGhhdCB0aGUgZ29hbHMg b3V0bGluZWQgaW4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL2p1 YmVydGkuZ2l0aHViLmlvL2RyYXVnaHRzL25vbWJpcy9kcmFmdC11YmVydGktbW11c2ljLW5vbWJp cy5odG1sIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cDovL2p1YmVydGkuZ2l0aHViLmlv L2RyYXVnaHRzL25vbWJpcy9kcmFmdC11YmVydGktbW11c2ljLW5vbWJpcy5odG1sPC9hPiAodXBk YXRlZCBzaW5jZSB0aGUgbWVldGluZyk8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+YXJlIHRoZSBjb3JyZWN0IGdvYWxzIHRvIGJlIHNob290aW5nIGZvciwgZXZlbiBpZiB0aGUg ZXhhY3QgbWVjaGFuaXNtcyBhcmVuJ3QgY29tcGxldGVseSBuYWlsZWQgZG93bi4gV2UgdGhpbmsg dGhlIGdvYWxzIGVudW1lcmF0ZWQgYnkgRW1pbCBpbiBoaXMgZW1haWwgZWFybGllciB0aGlzIHdl ZWsgYXJlIGFsbCBjb3ZlcmVkIGJ5IHRoZSBnb2FscyBpbiB0aGlzIGRvY3VtZW50LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQgYWxz byBzZWVtZWQgcmVhc29uYWJsZSB0byBhZG9wdCB0aGUgd29yayB0byBtZXJnZSBSZWd1bGFyIGFu ZCBBZ2dyZXNzaXZlIE5vbWluYXRpb24gaW4gSUNFLWJpcywgYW5kIGhhdmUgdGhlIENvbnRpbnVv dXMgTm9taW5hdGlvbiBjaGFuZ2UgYmUgaXRzIG93biBkb2N1bWVudC4gV2hpbGUgdGhlcmUgd2Fz IHNvbWUgaW50ZXJlc3QgaW4gZmlndXJpbmcgb3V0IGhvdyBJQ0UgY291bGQgc3VwcG9ydCBtdWx0 aXBsZSBzZWxlY3RlZA0KIHBhaXJzIHNpbXVsdGFuZW91c2x5LCB0aGlzIHdhcyBhZ3JlZWQgdG8g YmUgb3V0IG9mIHNjb3BlIGZvciBub3cuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBjYW4gZGlzY3VzcyBtb3JlIGluIHRoZSBXRyBt ZWV0aW5nOyBBcmksIGNhbiB5b3Ugc2V0IGFzaWRlIHNvbWUgYWdlbmRhIHRpbWU/PC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_37067FC0B61F4A5EBF098AF2DC1140B6ciscocom_-- From nobody Tue Nov 11 12:06:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117241A1A72 for ; Tue, 11 Nov 2014 12:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMHTN7bVu9h8 for ; Tue, 11 Nov 2014 12:05:59 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E2D1A6FF5 for ; Tue, 11 Nov 2014 12:05:58 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so12398668wgh.15 for ; Tue, 11 Nov 2014 12:05:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xw8vmvbzciZlIFo3VP8ixjqUfL1PWwREhconVCtnyBI=; b=GV6h2uIWxmUHpC46M4EzGKv/j4NHdz6P154lXX3c+kAU88L4u4maEhlQirZRCmztRf /VbxUbq7JjGrXt14nkJ3ui5/WSoq5MHqMggSA0Vn1Xqv+cBbqqCnNyEHOI5eGW56R0sr NjVM9V8K3tRlA9cSiWBAgJpmrQjMqrDuIqr6QVyYBIfVC+xZWUhuHZDSV652qQ9siM8D VR9nVyWMKEjBh1cMcMEaglNlXsuDoCLOEAINpsx7N/cr7La3KQbRQ7wFYtlV4nM73TPf jEplH9XFwJOx/RFu2aSUPAGgDc2UL4mGvxOvDJZPW4XJ0+3U41DrWgzA8OrcMaHok8b/ QYzQ== X-Gm-Message-State: ALoCoQkhUhZe+qCVkXu2D0XWbOKmY+M4nAkYVzDhMSXxFKF9QP303WF9Yo9/0xlO6o+u/gxQgRGY X-Received: by 10.180.211.166 with SMTP id nd6mr43232886wic.81.1415736357345; Tue, 11 Nov 2014 12:05:57 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id n4sm28592103wjb.40.2014.11.11.12.05.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 12:05:56 -0800 (PST) Message-ID: <54626C22.2090001@jitsi.org> Date: Tue, 11 Nov 2014 21:05:54 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , Justin Uberti References: <37067FC0-B61F-4A5E-BF09-8AF2DC1140B6@cisco.com> In-Reply-To: <37067FC0-B61F-4A5E-BF09-8AF2DC1140B6@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/a3VRi0294gW3IR1K8LuDa2PU5fc Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , "Dan Wing \(dwing\)" , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:06:04 -0000 Hey Pal, On 11.11.14, 20:35, Pal Martinsen (palmarti) wrote: > >> On 11 Nov 2014, at 00:47, Justin Uberti > > wrote: >> >> One other note - although Dan wasn’t present, the consensus was that >> the continuous nomination solution provides an effective solution to >> the ICE issues raised in draft-singh-avtcore-mprtp, >> draft-wing-ice-mobility, and draft-williams-peer-redirect. > > Regarding MICE. > > The main goal there is to try out any of the old remote candidates > before you actually trickle your new local candidates. As discussed off-list I am in favour of this, provided we focus on the right use case. (more below) > There is a chance > that the old NAT binding on the remote side might work if the NAT is of > the type “goodâ€. I think you are asking for more than a "good" NAT. Normally NATs with endpoint-dependent filtering are considered "good" as long as they don't do endpoint-dependent mapping. You are asking for NATs that don't do filtering and let anyone come in on an existing binding. I haven't seen NATs behave this way in years ... unless they had been manually configured with port-forwarding. Even if the NAT does allow packets to come in, the FW features in many modern OSes would drop them. So I think there is really little incentive to optimize for that use case (i.e., the one where both nodes are behind NATs). That said, the same optimization also solves the case of a mobile node talking to a media service (e.g., a multi-party video conferencing application). In that case it is also much more reasonable to expect that all original candidates would be kept alive. Very often those would be limited to the in-use UDP candidates and potentially a shared TCP host candidate using port 443. In other words, they would likely be in-use regardless and there won't be any resource wasting involved. I think that use case is definitely worth optimizing. I also think the entire draft would be much easier to define if it focuses on this use case. > Idea is to get media flowing without the use of the > signalling channel. This comes down to allowing peer-reflexive candidates to be discovered at any point of the communication. I believe that stated this way, the problem is relatively easy to solve. Emil > The trickling of the new local candidates should > happen in parallel. > > We will update the draft to fit into the continuous nomination and > trickle scheme once the dust settles. > > .-. > PÃ¥l-Erik > >> >> On Tue, Nov 11, 2014 at 1:44 AM, Justin Uberti > > wrote: >> >> Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met >> today to discuss the goals for the work to improve ICE nomination. >> >> In short, there was good consensus that the goals outlined in >> http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html >> (updated since the meeting) >> are the correct goals to be shooting for, even if the exact >> mechanisms aren't completely nailed down. We think the goals >> enumerated by Emil in his email earlier this week are all covered >> by the goals in this document. >> >> It also seemed reasonable to adopt the work to merge Regular and >> Aggressive Nomination in ICE-bis, and have the Continuous >> Nomination change be its own document. While there was some >> interest in figuring out how ICE could support multiple selected >> pairs simultaneously, this was agreed to be out of scope for now. >> >> We can discuss more in the WG meeting; Ari, can you set aside some >> agenda time? >> >> > -- https://jitsi.org From nobody Tue Nov 11 12:06:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849A21A1B6F for ; Tue, 11 Nov 2014 12:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRxXut5ee9i4 for ; Tue, 11 Nov 2014 12:06:28 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21B91A1A4E for ; Tue, 11 Nov 2014 12:06:27 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id 10so8337781lbg.28 for ; Tue, 11 Nov 2014 12:06:26 -0800 (PST) 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=hqME56S15KOhLLFAWhfzLyueSXvtvqdYgmOtitkufP0=; b=nRch9VhUYKSVlpmWfj+6q4Ae3aAW4nbkRSkmlsnF2FvncaaHbo0Rn9uLywGnZgEAey G6YlWIrUQTJ58vYeWVzepeOmeE1daONiT7xpGzARiq05V40MvcdrV62KzWPN5hXGZC8d sg+mEpq83okLCs2K37ERZnvdftIIrqnFwnvG7iboGEYLW0vgqQou4WAVs58SOcYs7VBA gUYbeU+x+3fdIL/Rexpb3dXgLlBfG9cNJ9TMTXwc2S3+EYDvAuN3zBAr0J7NRytIBOtI YgyQbZGgYdQfbi96qxA9LZ5bVfdK80ezZiHH2EcThGWo+a+Myzo9rHkwaG1D6cOCYhiD Yjyg== MIME-Version: 1.0 X-Received: by 10.152.27.38 with SMTP id q6mr4466990lag.92.1415736386494; Tue, 11 Nov 2014 12:06:26 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 12:06:26 -0800 (PST) In-Reply-To: <5462063E.1010008@jitsi.org> References: <5462063E.1010008@jitsi.org> Date: Tue, 11 Nov 2014 12:06:26 -0800 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/45j_YK6EhtC5sRz1mW2144lpx2U Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:06:33 -0000 On 11 November 2014 04:51, Emil Ivov wrote: > Unless you are planning on mandating that every ICE agent on the planet must > never release a single port number and must continuously block NAT and TURN > resources it is not using, then the remote side will have to re-gather > candidates regardless of whether you call your scheme an ICE restart or not. It was my conclusion at least that ICE restart is going to be necessary to avoid the pairing of stale and fresh candidates. That is, it is useful - maybe even necessary - in providing agents a way to control which candidates are used on an ongoing basis. Being able to remove a candidate from consideration is hugely valuable. I think that the problem Justin cites can be ameliorated by having guidance about candidate reuse from previous phases (or generations). Slapping a new ufrag/pwd on an existing candidate avoids the need for gathering, but there are risks. You need to be certain that the candidates you are providing are "fresh", which means either that you have active traffic or checks on them, or that you have recently acquired them. From nobody Tue Nov 11 12:07:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5F1A19F9 for ; Tue, 11 Nov 2014 12:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odXwHXQO54Xa for ; Tue, 11 Nov 2014 12:07:20 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966E71A1B6F for ; Tue, 11 Nov 2014 12:07:19 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-0e-54626c7487a4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.94.04387.47C62645; Tue, 11 Nov 2014 21:07:16 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.174.1; Tue, 11 Nov 2014 21:07:15 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B18BA110207; Tue, 11 Nov 2014 22:07:15 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D297D5F3A8; Tue, 11 Nov 2014 22:07:34 +0200 (EET) Received: from dhcp-bbed.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DF5355F3A7; Tue, 11 Nov 2014 22:07:29 +0200 (EET) Message-ID: <54626C6F.6050700@ericsson.com> Date: Tue, 11 Nov 2014 10:07:11 -1000 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti , "mmusic@ietf.org" , Brandon Williams , Varun Singh , Dan Wing , Martin Thomson , Emil Ivov , Christer Holmberg , Jonathan Lennox , Bernard Aboba , "Pal Martinsen (palmarti)" References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+JvjW5JTlKIwbVZxhZLe9vZLZY93slq cfHaQyaLNTsnsFjsX3ye2WLrVCGLa2f+MVpMXf6YxeL99ZUsFnub/B24PCYfWcDsMeX3RlaP nbPusnss2FTqsWTJTyaP/28CPVp3/GX3aHt2hz2AI4rLJiU1J7MstUjfLoErY/v27UwFE5kq lh39ytjAeJ6xi5GTQ0LARGLapTOsELaYxIV769m6GLk4hASOMErs27CCBcLZwChx7egUqMwe RomnW4+yQjhrGSVezX7KBOc82rGABWQYr4C2RNuVFiYQm0VAVeLm6r1sIDabgK3E6lc3wWpE BZIl1mydxA5RLyhxcuYTsH0iAieYJfZcbQa7UFjAQmL94lawC4UEAiRmnP8AZnMKBEq8OviK GcRmBqpZ/OYgO4QtL7H97RxmiI/UJK6e28QM0asqcfXfK8YJjCKzkOybhaR9FpL2BYzMqxhF i1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo/Dglt9WOxgPPnc8xCjAwajEw7uhOjFEiDWxrLgy 9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwFoosYWJYcGp9zcRlE3jO 8+9ucTSdVnnicZfcLNZ1SZk3TUTDjbMf2aue0ErY/uC9Yr+wZhD7NOmn8WGsWfsuv7IOSe2c VWu18NG6Blb99v2fxcJFZjbp570wXXqi4tQU1hkbhTKazl2eure7dLPG5945qzlOxue515jW f1igY3v1Jcc5SaZJSizFGYmGWsxFxYkADjNymqMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xvtL6ieHxHmrb6pe_ytqIpbF7_8 Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:07:22 -0000 On 11/10/14 11:44 PM, Justin Uberti wrote: > We can discuss more in the WG meeting; Ari, can you set aside some > agenda time? Yes, let's take this as part of the ICE bis slot. I was planning to have this and the updated offer as the main topics. Cheers, Ari From nobody Tue Nov 11 12:26:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E021A88EB for ; Tue, 11 Nov 2014 12:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPSL3RNr12P4 for ; Tue, 11 Nov 2014 12:26:44 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA5F1A014C for ; Tue, 11 Nov 2014 12:26:43 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so1070248vcb.31 for ; Tue, 11 Nov 2014 12:26:43 -0800 (PST) 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=4fyL+/1DLLIJIanHEDPBmzN8mvCL0nk0S7Ius7I9BHc=; b=E5yfZwpUrB8/4Snn/dH0HydPpNrcz/GjJLmr4NRf7tB3g2bQXtMQ/FVZNWAgUdrLfr i01a4wPkZoimYaBCrMeaj/9pqLKorstMfFLB6l6BFbPGoaEIH7YxYQyT6LP3obeBPdtf xS4peeuN0Bt53XdADZCyEGOFV924aWpCkA49c1iUn7N2IwXUyIpSOUJ39Ma35karwh0T 2kwI4XUv483Af1Sp4q7YnskeagkragK59IyGpPOWmDlvbDGLmD5HKmoU8t1GXePqyY6W 0YCsKd/MpCvbh4uBwhFVtWFZQaYa5ArKQd93QOgc3GM3K60LGX4V8+DBLCPwtxAvebTd fhRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4fyL+/1DLLIJIanHEDPBmzN8mvCL0nk0S7Ius7I9BHc=; b=PhmHdmL0fSnlnMRP53FYbFaL7eIhXyLSoYHjzict8I0y21NjaRmbQ+wOBeyQjoU9vs Gkgj93tNHKaD2EVXHx6TJRE7E9FjwWpX3zi7wQrSkevdlR0TSEpS0yRW3MpBli3pH28U T3UJJuEEkhMGBMJfhk0vlKUv1fqTOMBvOVy3g4FkVj7SMB6oTQOAW93Q1Wr0LMzBSyHh 0kVxD2hFdRjdiZDmueQ15gBSZIJMhtYT2eev0WZ31CWIA4O5fbcG7eR+9VWsXfUwZ2Q0 n/Z+TmXoXD/obO/l5lvHT1wylfQ9/CsY/JtP9YFFeEy0hw+A8XVkNI7onNFAxDgiPgrL RVDg== X-Gm-Message-State: ALoCoQlprhPITUFc1cL23tOtq8fIvL3z0mzm0RXbN0e1TYykZo8MGCu7aQgEZvyOqAuT9r0+bGa/ X-Received: by 10.221.22.136 with SMTP id qw8mr3303070vcb.77.1415737602818; Tue, 11 Nov 2014 12:26:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Tue, 11 Nov 2014 12:26:22 -0800 (PST) In-Reply-To: <546201BE.1000102@jitsi.org> References: <546201BE.1000102@jitsi.org> From: Justin Uberti Date: Tue, 11 Nov 2014 12:26:22 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11337688e965e705079b187e Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/qutZEKVMQdMgdPDS_HVgqdXKOzM Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:26:46 -0000 --001a11337688e965e705079b187e Content-Type: text/plain; charset=UTF-8 On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov wrote: > > > On 11.11.14, 10:44, Justin Uberti wrote: > >> Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today >> to discuss the goals for the work to improve ICE nomination. >> >> In short, there was good consensus that the goals outlined in >> http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html >> (updated since the meeting) >> are the correct goals to be shooting for, even if the exact mechanisms >> aren't completely nailed down. We think the goals enumerated by Emil in >> his email earlier this week are all covered by the goals in this document. >> > > Hm? I might have missed something but how does it cover the need to detect > an end of currently available candidates? How does one know when it is safe > to release unused candidates? > These questions are addressed specifically in the draft - Section 5.2, paragraphs 5 and 4, respectively. > > Whether we call it an ICE restart or not, the mechanism we come up with > would need to support these things. > > Emil > > -- > https://jitsi.org > --001a11337688e965e705079b187e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov <emcho@jitsi.org> wrote:


On 11.11.14, 10:44, Justin Uberti wrote:
Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today to discuss the goals for the work to improve ICE nomination.

In short, there was good consensus that the goals outlined in
http://juberti.github.io/draughts/nombis= /draft-uberti-mmusic-nombis.html
(updated since the meeting)
are the correct goals to be shooting for, even if the exact mechanisms
aren't completely nailed down. We think the goals enumerated by Emil in=
his email earlier this week are all covered by the goals in this document.<= br>

Hm? I might have missed something but how does it cover the need to detect = an end of currently available candidates? How does one know when it is safe= to release unused candidates?

These qu= estions are addressed specifically in the draft - Section 5.2, paragraphs 5= and 4, respectively.=C2=A0

Whether we call it an ICE restart or not, the mechanism we come up with wou= ld need to support these things.

Emil

--
https://jitsi.org

--001a11337688e965e705079b187e-- From nobody Tue Nov 11 12:32:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCBB1A9102 for ; Tue, 11 Nov 2014 12:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyBlwrjRiIGH for ; Tue, 11 Nov 2014 12:32:17 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DD71A90E0 for ; Tue, 11 Nov 2014 12:31:53 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq12so2198922vcb.9 for ; Tue, 11 Nov 2014 12:31:52 -0800 (PST) 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=7qQYWtWeHZVMk5STliuwPrjp5bSV1p5Cpos39frpRcE=; b=PTBan1smX1dGnhMfCeKfWgMjep4VD8xxp6vCJgy2z6PSF1Mw7kWeXdJXGb3tM0TW5M s1P+wgR1+wVXMMjmMqgefsc+7H+VNn/m2iMLEffpPC6Ms1BOzoNMVnmn3gJ5JBj7jIFA BXd/wgYZhkPRP9TEtM9r6pEyKwaGpG4Swz4ZiEt/Lfdoj2L7bR4Hl9FNjDY3rksuD4nw u+ObgPIqNev5geF2koVt/jGdx0RxRXjPxuWECM9GGrp50l36d5DEtQELgxHb8ZDCdjdo OsNdeT3YKj9xClcKjY9eDLrlz9XzMts6ZwEN/rPT4owF1LQEo29E3PpkXKDVHOxQKjP/ DuMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7qQYWtWeHZVMk5STliuwPrjp5bSV1p5Cpos39frpRcE=; b=XBVSVSDe26iEEB5ySjXle6/N58tns1j4+OuOyf6RJP+m5OKdxJgvUY42/shz8Ee1Fi 56e6EoUhPCQ3Q94yzQfXKdHpkXmV8ipeQWYWoVoKJBtjowcUh1qd3OvZkGo06gRdfYno WRnYTgsPpHLKLH3Cnd9h4dA+f0F3HIVpBha7heddXrOBhBhwWGEFX8J8+99M701OnpQO 9aaLnMIDm5wYj3wmo6Bxblz486qyZdNaQ93KrGPggWmdGS70PmcxRtC8buWVaQYMbZB6 BdGj7KGja/ZSJC8bkFOTTWD4MUduuOKLQ3wqVAfffceQvk/caCmAZjldx/Kmdp4BhpOi h2Rg== X-Gm-Message-State: ALoCoQnSCmrYpCx5VulDbvER3SVyOIF8DSyuzeWwFwiwDqbKXAsywl9DeGKyVhFlk3YqeoPrbRDX X-Received: by 10.52.237.131 with SMTP id vc3mr25085727vdc.12.1415737912346; Tue, 11 Nov 2014 12:31:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Tue, 11 Nov 2014 12:31:32 -0800 (PST) In-Reply-To: <5462063E.1010008@jitsi.org> References: <5462063E.1010008@jitsi.org> From: Justin Uberti Date: Tue, 11 Nov 2014 12:31:32 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=089e01182b245c614205079b2b7d Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ik3uw8wxeq9KW21P49yXG67Z1bc Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:32:23 -0000 --089e01182b245c614205079b2b7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 11, 2014 at 4:51 AM, Emil Ivov wrote: > One more comment here: > > On 11.11.14, 10:44, Justin Uberti wrote: > >> In short, there was good consensus that the goals outlined in >> http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html >> (updated since the meeting) >> > > While I agree with the majority of the goals expressed in the above > document there is one that sounds a bit na=C3=AFve. > > Section 3.4 says: > > While this could > be done using an ICE restart, as described in [RFC5245], Section 9.1, > the ICE restart may have unintended consequences, such as causing the > remote side to regather all candidates. Instead, it would be best if > the new candidates could be trickled, as discussed in > [I-D.ietf-mmusic-trickle-ice], but even after ICE processing has > completed. > > Unless you are planning on mandating that every ICE agent on the planet > must never release a single port number and must continuously block NAT a= nd > TURN resources it is not using, then the remote side will have to re-gath= er > candidates regardless of whether you call your scheme an ICE restart or n= ot. > > This is not so hard to resolve so I am not sure how to explain the > insistence to not address it. Continuous Nomination allows pairs to be kept alive; see Section 5.2, paragraph 4; this is a key part of the approach, since it allows quick switching between pairs. But even if only the selected pair is kept alive, it will often be possible to use new candidates from the local side without a regather on the remote side. --089e01182b245c614205079b2b7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 11, 2014 at 4:51 AM, Emil Ivov <emcho@jitsi.org> wrote:
One more comment here:

On 11.11.14, 10:44, Justin Uberti wrote:
In short, there was good consensus that the goals outlined in
http://juberti.github.io/draughts/nombis= /draft-uberti-mmusic-nombis.html
(updated since the meeting)

 While I agree with the majority of the goals expressed in the above documen= t there is one that sounds a bit na=C3=AFve.

Section 3.4 says:

=C2=A0 =C2=A0While this could
=C2=A0 =C2=A0be done using an ICE restart, as described in [RFC5245], Secti= on 9.1,
=C2=A0 =C2=A0the ICE restart may have unintended consequences, such as caus= ing the
=C2=A0 =C2=A0remote side to regather all candidates.=C2=A0 Instead, it woul= d be best if
=C2=A0 =C2=A0the new candidates could be trickled, as discussed in
=C2=A0 =C2=A0[I-D.ietf-mmusic-trickle-ice], but even after ICE processing h= as
=C2=A0 =C2=A0completed.

Unless you are planning on mandating that every ICE agent on the planet mus= t never release a single port number and must continuously block NAT and TU= RN resources it is not using, then the remote side will have to re-gather c= andidates regardless of whether you call your scheme an ICE restart or not.=

This is not so hard to resolve so I am not sure how to explain the insisten= ce to not address it.

Continuous Nomination= allows pairs to be kept alive; see Section 5.2, paragraph 4; this is a key= part of the approach, since it allows quick switching between pairs.=C2=A0=

But even if only the selected pair is kept alive,= it will often be possible to use new candidates from the local side withou= t a regather on the remote side.


<= /div>
--089e01182b245c614205079b2b7d-- From nobody Tue Nov 11 12:55:32 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4BC1AC3F1 for ; Tue, 11 Nov 2014 12:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8olvboLQdrrE for ; Tue, 11 Nov 2014 12:55:30 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A119B1AC3F3 for ; Tue, 11 Nov 2014 12:55:27 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id x12so12538058wgg.17 for ; Tue, 11 Nov 2014 12:55:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VrkE93W3Z1vH8YnHWU52EMUTekbqv0NiEgXp1BFD0Io=; b=FNTPtfwLLUFd623SLa900pBuzxJZngZ8kvdy6Iz0JThnVA6ZpotJVXKkls2rhC5mj9 H6dOVNWgXr8dWF5Uj4W4Ob8l0fACyy8pfZpUdXDULvBcHUOvhNHD9gSzwUxca1aJj+Dy iixVCB/E7q2intlo2x3TMIL95pc75QItkJzRO1+SBu8STT8JceM0fwmkN60yl6VMMX1Q cKBNASg8GCVglMtyeka7yXl4UXctE4tA0Tt8w+x4M4GCn88A+Lc4zi+BrKQz+1Jslzqb c3yjImfvxZZ3g5l8Ni8J5wxQ7rXAuGtG+aQ5UjKBwczDatU+SrfIiSvu2AmEBwOYH5KZ gfjA== X-Gm-Message-State: ALoCoQkJKRAY7U61cJc1eTZGioPVQeqmiZG/2BgKdfA/HTRjvInFlX1qsyUPpJuBCx5dKnFZBiYZ X-Received: by 10.194.238.3 with SMTP id vg3mr8046473wjc.69.1415739326326; Tue, 11 Nov 2014 12:55:26 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id cu9sm28791966wjb.0.2014.11.11.12.55.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 12:55:24 -0800 (PST) Message-ID: <546277BA.7070402@jitsi.org> Date: Tue, 11 Nov 2014 21:55:22 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti References: <546201BE.1000102@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gorcGgm6EqDWnHNj9aAOVjRjF4Y Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:55:31 -0000 On 11.11.14, 21:26, Justin Uberti wrote: > > > On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov > wrote: > > > > On 11.11.14, 10:44, Justin Uberti wrote: > > Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) > met today > to discuss the goals for the work to improve ICE nomination. > > In short, there was good consensus that the goals outlined in > http://juberti.github.io/__draughts/nombis/draft-uberti-__mmusic-nombis.html > > (updated since the meeting) > are the correct goals to be shooting for, even if the exact > mechanisms > aren't completely nailed down. We think the goals enumerated by > Emil in > his email earlier this week are all covered by the goals in this > document. > > > Hm? I might have missed something but how does it cover the need to > detect an end of currently available candidates? How does one know > when it is safe to release unused candidates? > > > These questions are addressed specifically in the draft - Section 5.2, > paragraphs 5 Indeed. That wasn't in the google doc however so I didn't realise you had changed it. It would have been nice to mention this. Anyways. Glad we are making progress. > and 4, respectively. OK, nice, almost there! What this doesn't yet say is that the released candidates would need to be regathered once new remote candidates start trickling in again. This is when it turns effectively in an ICE restart. I agree with Martin that guidance on implementing restarts and handling existing pairs should address most concerns. Emil > Whether we call it an ICE restart or not, the mechanism we come up > with would need to support these things. > > Emil > > -- > https://jitsi.org > > -- https://jitsi.org From nobody Tue Nov 11 16:47:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0353B1A6FD8 for ; Tue, 11 Nov 2014 16:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-kEuaxXC3-w for ; Tue, 11 Nov 2014 16:47:39 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4071A6FEB for ; Tue, 11 Nov 2014 16:47:38 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id la4so475631vcb.21 for ; Tue, 11 Nov 2014 16:47:38 -0800 (PST) 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=nZtlpOeXkkTq1IlxEy8sJY/cZgPiQAZnlJLZoVBSkeA=; b=PJtFZsMo89k22PL4QRDK91H26sWzR94ZMkwrIBG5FMqq7gKvydVND0ApYP2GeOt8EC MH6+NBWcjceV5Kbu+PMzOA7k9lQbZpcqrwe1ocLZG0dcJqFVKJOp+eoG3rHQpIsIdpG/ Fzk60eI1Nup6kkbLkT+aY9QKW/3SZYBJKAiXjAYRSOTVPa96BnSkvzI1EEic5eZ0C/cu aGShCEopexs43RwHbu2kbJR+u+UEfjswOjDecslEiYUURRe2amC3CnioZP0Lxyv9cnmE BzEjStqzN42ErvPGIB0N0ZrjzJJlYHR53ImLlqpJBnE6EXdTA0Nb5mxObWzJ7p65Sqqu /qPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nZtlpOeXkkTq1IlxEy8sJY/cZgPiQAZnlJLZoVBSkeA=; b=esVkCdicgqKjGF3W2tRxOrfoIICglIfxxh3lmNU/dlw8ZyCXfOiOtxCKPcBaXyCeEx +sl2MrOoMiSDpZPIFzWtCSqHwmp+zjTQY9fLw/NyR9wxMcIPvlsyf5uU3aBUq4XWQZbn 3jUjxM70RxEd11ylaRsD/e4+Whe4Y+1DHqsepLjlS5PwKggcgDNJVTWL8Qe5i2otL3wq ZlBCi+1QcIJlx5QfhpqvArbiRPp4HNgLTHYqn+apcQY0JBEg/yNE+UXvGCH8SrvPo/UQ sJytqS4iwM1p7d+/+U1S0E6SjNKcJ0glRmAFOJKVKYlpz+fITu11yxLrjemFg4caqg15 cTUQ== X-Gm-Message-State: ALoCoQnxAClKbNrCK38EZTH02KB54LvjU2NI1ZHTv9MPhH/P0BCnRXcmCwTgbd/xrwHi6RDDyfTh X-Received: by 10.220.118.194 with SMTP id w2mr19200519vcq.24.1415753257869; Tue, 11 Nov 2014 16:47:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Tue, 11 Nov 2014 16:47:17 -0800 (PST) In-Reply-To: <546277BA.7070402@jitsi.org> References: <546201BE.1000102@jitsi.org> <546277BA.7070402@jitsi.org> From: Justin Uberti Date: Tue, 11 Nov 2014 16:47:17 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a1132f4ba06821505079ebe3b Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f4m7D_1Z2jcinq1fs3pwFqcqY1c Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 00:47:41 -0000 --001a1132f4ba06821505079ebe3b Content-Type: text/plain; charset=UTF-8 On Tue, Nov 11, 2014 at 12:55 PM, Emil Ivov wrote: > > > On 11.11.14, 21:26, Justin Uberti wrote: > >> >> >> On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov > > wrote: >> >> >> >> On 11.11.14, 10:44, Justin Uberti wrote: >> >> Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) >> met today >> to discuss the goals for the work to improve ICE nomination. >> >> In short, there was good consensus that the goals outlined in >> http://juberti.github.io/__draughts/nombis/draft-uberti-_ >> _mmusic-nombis.html >> > mmusic-nombis.html> >> (updated since the meeting) >> are the correct goals to be shooting for, even if the exact >> mechanisms >> aren't completely nailed down. We think the goals enumerated by >> Emil in >> his email earlier this week are all covered by the goals in this >> document. >> >> >> Hm? I might have missed something but how does it cover the need to >> detect an end of currently available candidates? How does one know >> when it is safe to release unused candidates? >> >> >> These questions are addressed specifically in the draft - Section 5.2, >> paragraphs 5 >> > > Indeed. That wasn't in the google doc however so I didn't realise you had > changed it. It would have been nice to mention this. > > Anyways. Glad we are making progress. > > and 4, respectively. >> > > OK, nice, almost there! > > What this doesn't yet say is that the released candidates would need to be > regathered once new remote candidates start trickling in again. > > This is when it turns effectively in an ICE restart. > Yes, we need to figure out how this should work. Released candidates won't always need to be regathered; the new candidates might just be 'hey, try these also'. But there are certainly mobility scenarios where one side wants to inform the other that 'hey, my existing candidates are about to go away, so we want to do a restart'. > > I agree with Martin that guidance on implementing restarts and handling > existing pairs should address most concerns. > Yes. It probably would be useful to walk through a few flows and see if some patterns emerge. > > Emil > > > Whether we call it an ICE restart or not, the mechanism we come up >> with would need to support these things. >> >> Emil >> >> -- >> https://jitsi.org >> >> >> > -- > https://jitsi.org > --001a1132f4ba06821505079ebe3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 11, 2014 at 12:55 PM, Emil Ivov <emcho@jitsi.org> wrote:


On 11.11.14, 21:26, Justin Uberti wrote:


On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov <emcho@jitsi.org
 <mailto:emcho@jitsi= .org>> wrote:



=C2=A0 =C2=A0 On 11.11.14, 10:44, Justin Uberti wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Several of us (Bernard, Jonathan, Varun, Martin= , Brandon, Pal)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 met today
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to discuss the goals for the work to improve IC= E nomination.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In short, there was good consensus that the goa= ls outlined in
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://juberti.= github.io/__draughts/nombis/draft-uberti-__mmusic-nombis.html=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://juberti.= github.io/draughts/nombis/draft-uberti-mmusic-nombis.html= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (updated since the meeting)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are the correct goals to be shooting for, even = if the exact
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms
=C2=A0 =C2=A0 =C2=A0 =C2=A0 aren't completely nailed down. We think the= goals enumerated by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Emil in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 his email earlier this week are all covered by = the goals in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 document.


=C2=A0 =C2=A0 Hm? I might have missed something but how does it cover the n= eed to
=C2=A0 =C2=A0 detect an end of currently available candidates? How does one= know
=C2=A0 =C2=A0 when it is safe to release unused candidates?


These questions are addressed specifically in the draft - Section 5.2,
paragraphs 5

Indeed. That wasn't in the google doc however so I didn't realise y= ou had changed it. It would have been nice to mention this.

Anyways. Glad we are making progress.

and 4, respectively.

OK, nice, almost there!

What this doesn't yet say is that the released candidates would need to= be regathered once new remote candidates start trickling in again.


This is when it turns effectively in an ICE restart.
<= br>
Yes, we need to figure out how this should work. Released can= didates won't always need to be regathered; the new candidates might ju= st be 'hey, try these also'. But there are certainly mobility scena= rios where one side wants to inform the other that 'hey, my existing ca= ndidates are about to go away, so we want to do a restart'.
= =C2=A0

I agree with Martin that guidance on implementing restarts and handling exi= sting pairs should address most concerns.

Yes. It probably would be useful to walk through a few flows and see if = some patterns emerge.=C2=A0

Emil


=C2=A0 =C2=A0 Whether we call it an ICE restart or not, the mechanism we co= me up
=C2=A0 =C2=A0 with would need to support these things.

=C2=A0 =C2=A0 Emil

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 https://jitsi= .org



--
https://jitsi.org

--001a1132f4ba06821505079ebe3b-- From nobody Tue Nov 11 19:17:51 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9941ABD35 for ; Tue, 11 Nov 2014 19:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_12=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v21MLUsS-yz8 for ; Tue, 11 Nov 2014 19:17:47 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F2F1A7031 for ; Tue, 11 Nov 2014 19:17:46 -0800 (PST) Received: from ppp118-209-83-124.lns20.mel4.internode.on.net ([118.209.83.124]:56413 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoOPt-00065A-HX for mmusic@ietf.org; Wed, 12 Nov 2014 14:16:21 +1100 Message-ID: <5462D156.2080100@nteczone.com> Date: Wed, 12 Nov 2014 14:17:42 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/N4G9S0QTZX9gY2_omx-gGkclVAY Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 03:17:49 -0000 Hello I had a chance to look over the latest draft in more details. Some comments/questions: 5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated: dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( maxretr-opt / maxtime-opt ) 5.1.1.3: I think you can remove the "action item". draft-ietf-rtcweb-data-protocol indicates "The protocol field is to ease cross-application interoperation("federation") by identifying the user data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in [RFC6455]). I wouldn't see the out of band method using a different registry. 5.1.1.4. max-retr parameter: This draft seems to use the absence of the "max-retr" parameter to indicate the use of a reliable channel It also indicates a default value of "unbounded". draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels this field MUST be set to 0 on the sending side and MUST be ignored on the receiving side." To better align with the data channel protocol i'd suggest changing the of 5.1.1.4 to indicate that "The max-retr parameter is optional with the default value equal to 0 indicating that no retramsmission is used. Also is the term "unreliable" appropriate given that the data channel protocol talks about "partial reliability"? 5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about specific behaviour when the parameter is omitted rather than saying "unbounded". 6. Example: In the examples a=dcmap:0 subprotocol="BFCP";label="BGCP" lines. Is the BCP for the label intentional? Regards, Christian On 28/10/2014 1:39 AM, DRAGE, Keith (Keith) wrote: > Based on the discussion on list over the last few days, I have submitted revised versions of the two SDP negotiation over data channel drafts as follows: > > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to the IETF repository. > > Name: draft-ejzak-mmusic-data-channel-sdpneg > Revision: 02 > Title: SDP-based "SCTP over DTLS" data channel negotiation > Document date: 2014-10-27 > Group: Individual Submission > Pages: 22 > URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt > Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/ > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02 > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working group is > charged to provide protocols to support direct interactive rich > communications using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. Data channel setup > can be done using either the internal in-band band (also referred to > as 'internal' for the rest of the document) WebRTC Data Channel > Establishment Protocol or some external out-of-band simply referred > to as 'external negotiation' in the rest of the document . This > document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation. Even though data channels are > designed for RTCWeb use initially they may be used by other protocols > like, but not limited to, the CLUE protocol. This document is > intended to be used wherever data channels are used. > > > A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > has been successfully submitted by Keith Drage and posted to the IETF repository. > > Name: draft-ejzak-mmusic-msrp-usage-data-channel > Revision: 01 > Title: MSRP over SCTP/DTLS data channels > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/ > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01 > > Abstract: > This document specifies how the Message Session Relay Protocol (MSRP) > can be instantiated as a data channel sub-protocol, using the the SDP > offer/answer exchange-based external negotiation defined in > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > are documented: a WebRTC end-to-end configuration (connecting two > MSRP over data channel endpoints), and a gateway configuration > (connecting an MSRP over data channel endpoint with an MSRP over TCP > endpoint). > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Nov 12 11:10:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2534C1A0364 for ; Wed, 12 Nov 2014 11:10:18 -0800 (PST) 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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_BACKHAIR_12=1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH7t4t2iCmks for ; Wed, 12 Nov 2014 11:10:09 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D951A038D for ; Wed, 12 Nov 2014 11:09:04 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 8E7EC96458405 for ; Wed, 12 Nov 2014 19:08:59 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sACJ936Y008732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Nov 2014 20:09:03 +0100 Received: from [135.244.176.49] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 12 Nov 2014 20:09:02 +0100 Message-ID: <5463B04C.9090409@alcatel-lucent.com> Date: Wed, 12 Nov 2014 20:09:00 +0100 From: Juergen Stoetzer-Bradler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5462D156.2080100@nteczone.com> In-Reply-To: <5462D156.2080100@nteczone.com> Content-Type: multipart/alternative; boundary="------------010607040000020503050901" X-Originating-IP: [135.239.27.38] Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mBiUbrxgvJ88ScsT7oOPTnNGPXI Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:10:18 -0000 --------------010607040000020503050901 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello Christian, Thank you for your comments. Please see my remarks inserted below. Thanks, Juergen On 12.11.2014 04:17, Christian Groves wrote: > Hello > > I had a chance to look over the latest draft in more details. Some comments/questions: > > 5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated: > dcmap-opt = ordering-opt / subprotocol-opt / label-opt > / ( maxretr-opt / maxtime-opt ) [Juergen] Actually, I am not sure if this would formally prevent maxretr-opt and maxtime-opt from both being present simultaneously, as we would still have dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] (allowing an arbitrary number of "dcmap-opt"). My understanding of RFC 5234's definition of "alternation" has so far been that dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt and dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( maxretr-opt / maxtime-opt ) are actually equivalent. Right now don't see a "compact" way of strengthening the actual ABNF rules without having to list all possible parameter combinations and permutations. > > > 5.1.1.3: I think you can remove the "action item". draft-ietf-rtcweb-data-protocol indicates "The > protocol field is to ease cross-application interoperation("federation") by identifying the user > data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in > [RFC6455]). I wouldn't see the out of band method using a different registry. [Juergen] Agree. > > > 5.1.1.4. max-retr parameter: This draft seems to use the absence of the "max-retr" parameter to > indicate the use of a reliable channel It also indicates a default value of "unbounded". > draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels this field MUST be set to 0 > on the sending side and MUST be ignored on the receiving side." > To better align with the data channel protocol i'd suggest changing the of 5.1.1.4 to indicate > that "The max-retr parameter is optional with the default value equal to 0 indicating that no > retramsmission is used. [Juergen] Our current intention is that the absence of "max-retr" and "max-time" in the a=dcmap attribute value would indicate a reliable data channel, similar as channel types "DATA_CHANNEL_RELIABLE" and "DATA_CHANNEL_RELIABLE_UNORDERED" in DCEP's DATA_CHANNEL_OPEN message. And that "max-retr=0" would actually indicate a partial reliable data channel with the maximal number of retransmissions set to zero (similar to DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT(_UNORDERED) and "Reliability Parameter" = 0 in the DATA_CHANNEL_OPEN message). If we kept this semantic of "max-retr=0", then a default value equal to 0 would result in an a=dcmap attribute without "max-retr" parameter actually indicating a correspondingly partial reliable data channel, such that then the data channel would actually not be reliable as far as I understand. > > Also is the term "unreliable" appropriate given that the data channel protocol talks about > "partial reliability"? [Juergen] Agree. We should replace "unreliable" with "partially reliable" throughout the document. > > 5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about specific behaviour when the > parameter is omitted rather than saying "unbounded". [Juergen] Agree. We should make this case more explicit and e.g. refer to RFC 4960 and say: "The max-time parameter is optional. If the max-time parameter is not present, then the generic SCTP retransmission timing rules apply as specified in [RFC 4960]." Similarly in 5.1.1.4; there we could e.g. say: "The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal number of retransmissions is determined as per the generic SCTP retransmission rules as specified in [RFC 4960]." Would you agree to this? > > 6. Example: In the examples a=dcmap:0 subprotocol="BFCP";label="BGCP" lines. Is the BCP for the > label intentional? [Juergen] That's a typo. Should have been 'label="BFCP"'. We'll correct this. > > > Regards, Christian > > > > > On 28/10/2014 1:39 AM, DRAGE, Keith (Keith) wrote: >> Based on the discussion on list over the last few days, I have submitted revised versions of the >> two SDP negotiation over data channel drafts as follows: >> >> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt >> has been successfully submitted by Keith Drage and posted to the IETF repository. >> >> Name: draft-ejzak-mmusic-data-channel-sdpneg >> Revision: 02 >> Title: SDP-based "SCTP over DTLS" data channel negotiation >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 22 >> URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt >> Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/ >> Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02 >> >> Abstract: >> The Real-Time Communication in WEB-browsers (RTCWeb) working group is >> charged to provide protocols to support direct interactive rich >> communications using audio, video, and data between two peers' web- >> browsers. For the support of data communication, the RTCWeb working >> group has in particular defined the concept of bi-directional data >> channels over SCTP, where each data channel might be used to >> transport other protocols, called sub-protocols. Data channel setup >> can be done using either the internal in-band band (also referred to >> as 'internal' for the rest of the document) WebRTC Data Channel >> Establishment Protocol or some external out-of-band simply referred >> to as 'external negotiation' in the rest of the document . This >> document specifies how the SDP offer/answer exchange can be used to >> achieve such an external negotiation. Even though data channels are >> designed for RTCWeb use initially they may be used by other protocols >> like, but not limited to, the CLUE protocol. This document is >> intended to be used wherever data channels are used. >> >> >> A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt >> has been successfully submitted by Keith Drage and posted to the IETF repository. >> >> Name: draft-ejzak-mmusic-msrp-usage-data-channel >> Revision: 01 >> Title: MSRP over SCTP/DTLS data channels >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 11 >> URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt >> Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/ >> Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01 >> >> Abstract: >> This document specifies how the Message Session Relay Protocol (MSRP) >> can be instantiated as a data channel sub-protocol, using the the SDP >> offer/answer exchange-based external negotiation defined in >> [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations >> are documented: a WebRTC end-to-end configuration (connecting two >> MSRP over data channel endpoints), and a gateway configuration >> (connecting an MSRP over data channel endpoint with an MSRP over TCP >> endpoint). >> _______________________________________________ >> 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 > > -- JSB_email_signature --------------010607040000020503050901 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello Christian,

Thank you for your comments.
Please see my remarks inserted below.

Thanks,
Juergen


On 12.11.2014 04:17, Christian Groves wrote:
Hello

I had a chance to look over the latest draft in more details. Some comments/questions:

5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated:
   dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
                     / ( maxretr-opt / maxtime-opt )

[Juergen] Actually, I am not sure if this would formally prevent  maxretr-opt and maxtime-opt  from both being present simultaneously, as we would still have
    dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ]
(allowing an arbitrary number of "dcmap-opt").
My understanding of RFC 5234's definition of "alternation" has so far been that
     dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt
and
    dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( maxretr-opt / maxtime-opt )
are actually equivalent.
Right now don't see a "compact" way of strengthening the actual ABNF rules without having to list all possible parameter combinations and permutations.



5.1.1.3: I think you can remove the "action item". draft-ietf-rtcweb-data-protocol indicates "The protocol field is to ease cross-application interoperation("federation") by identifying the user data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in [RFC6455]). I wouldn't see the out of band method using a different registry.

[Juergen] Agree.



5.1.1.4. max-retr parameter: This draft seems to use the absence of the "max-retr" parameter to indicate the use of a reliable channel It also indicates a default value of "unbounded". draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels this field MUST be set to 0 on the sending side and MUST be ignored on the receiving side."
To better align with the data channel protocol i'd suggest changing the of 5.1.1.4 to indicate that "The max-retr parameter is optional with the default value equal to 0 indicating that no retramsmission is used.

[Juergen] Our current intention is that the absence of "max-retr" and "max-time" in the a=dcmap attribute value would indicate a reliable data channel, similar as channel types "DATA_CHANNEL_RELIABLE" and "DATA_CHANNEL_RELIABLE_UNORDERED" in DCEP's DATA_CHANNEL_OPEN message.
And that "max-retr=0" would actually indicate a partial reliable data channel with the maximal number of retransmissions set to zero (similar to DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT(_UNORDERED) and "Reliability Parameter" = 0 in the DATA_CHANNEL_OPEN message).
If we kept this semantic of "max-retr=0", then a default value equal to 0 would result in an a=dcmap attribute without "max-retr" parameter actually indicating a correspondingly partial reliable data channel, such that then the data channel would actually not be reliable as far as I understand.


Also is the term "unreliable" appropriate given that the data channel protocol talks about "partial reliability"?

[Juergen] Agree. We should replace "unreliable" with "partially reliable" throughout the document.


5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about specific behaviour when the parameter is omitted rather than saying "unbounded".

[Juergen] Agree. We should make this case more explicit and e.g. refer to RFC 4960 and say:
"The max-time parameter is optional. If the max-time parameter is not present, then the generic SCTP retransmission timing rules apply as specified in [RFC 4960]."

Similarly in 5.1.1.4; there we could e.g. say:
"The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal number of retransmissions is determined as per the generic SCTP retransmission rules as specified in [RFC 4960]."

Would you agree to this?


6. Example: In the examples a=dcmap:0 subprotocol="BFCP";label="BGCP" lines. Is the B<G>CP for the label intentional?

[Juergen] That's a typo. Should have been 'label="BFCP"'. We'll correct this.



Regards, Christian




On 28/10/2014 1:39 AM, DRAGE, Keith (Keith) wrote:
Based on the discussion on list over the last few days, I have submitted revised versions of the two SDP negotiation over data channel drafts as follows:

A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt
has been successfully submitted by Keith Drage and posted to the IETF repository.

Name:        draft-ejzak-mmusic-data-channel-sdpneg
Revision:    02
Title:        SDP-based "SCTP over DTLS" data channel negotiation
Document date:    2014-10-27
Group:        Individual Submission
Pages:        22
URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/
Htmlized:       http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02

Abstract:
    The Real-Time Communication in WEB-browsers (RTCWeb) working group is
    charged to provide protocols to support direct interactive rich
    communications using audio, video, and data between two peers' web-
    browsers.  For the support of data communication, the RTCWeb working
    group has in particular defined the concept of bi-directional data
    channels over SCTP, where each data channel might be used to
    transport other protocols, called sub-protocols.  Data channel setup
    can be done using either the internal in-band band (also referred to
    as 'internal' for the rest of the document) WebRTC Data Channel
    Establishment Protocol or some external out-of-band simply referred
    to as 'external negotiation' in the rest of the document . This
    document specifies how the SDP offer/answer exchange can be used to
    achieve such an external negotiation.  Even though data channels are
    designed for RTCWeb use initially they may be used by other protocols
    like, but not limited to, the CLUE protocol.  This document is
    intended to be used wherever data channels are used.


A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
has been successfully submitted by Keith Drage and posted to the IETF repository.

Name:        draft-ejzak-mmusic-msrp-usage-data-channel
Revision:    01
Title:        MSRP over SCTP/DTLS data channels
Document date:    2014-10-27
Group:        Individual Submission
Pages:        11
URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/
Htmlized:       http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01

Abstract:
    This document specifies how the Message Session Relay Protocol (MSRP)
    can be instantiated as a data channel sub-protocol, using the the SDP
    offer/answer exchange-based external negotiation defined in
    [I-D.ejzak-mmusic-data-channel-sdpneg].  Two network configurations
    are documented: a WebRTC end-to-end configuration (connecting two
    MSRP over data channel endpoints), and a gateway configuration
    (connecting an MSRP over data channel endpoint with an MSRP over TCP
    endpoint).
_______________________________________________
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



--
JSB_email_signature
--------------010607040000020503050901-- From nobody Wed Nov 12 11:45:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A113D1ACFF4 for ; Wed, 12 Nov 2014 11:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMxC8D0RRb2D for ; Wed, 12 Nov 2014 11:45:31 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886C61ACFF2 for ; Wed, 12 Nov 2014 11:45:31 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-10v.sys.comcast.net with comcast id Ejkc1p0034s37d401jlXMX; Wed, 12 Nov 2014 19:45:31 +0000 Received: from dhcp-a55a.meeting.ietf.org ([31.133.165.90]) by resomta-po-01v.sys.comcast.net with comcast id EjjN1p00A1xLjbz01jjQJc; Wed, 12 Nov 2014 19:43:29 +0000 Message-ID: <5463B85B.1090100@alum.mit.edu> Date: Wed, 12 Nov 2014 09:43:23 -1000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5462D156.2080100@nteczone.com> <5463B04C.9090409@alcatel-lucent.com> In-Reply-To: <5463B04C.9090409@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cfXF9MO7jTfm-bWvDNLBFFFL_2I Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:45:32 -0000 On 11/12/14 9:09 AM, Juergen Stoetzer-Bradler wrote: > On 12.11.2014 04:17, Christian Groves wrote: >> Hello >> >> I had a chance to look over the latest draft in more details. Some >> comments/questions: >> >> 5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated: >> dcmap-opt = ordering-opt / subprotocol-opt / label-opt >> / ( maxretr-opt / maxtime-opt ) > > [Juergen] Actually, I am not sure if this would formally prevent > maxretr-opt and maxtime-opt from both being present simultaneously, as > we would still have > dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] > (allowing an arbitrary number of "dcmap-opt"). > My understanding of RFC 5234's definition of "alternation" has so far > been that > dcmap-opt = ordering-opt / subprotocol-opt / label-opt / > maxretr-opt / maxtime-opt > and > dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( > maxretr-opt / maxtime-opt ) > are actually equivalent. > Right now don't see a "compact" way of strengthening the actual ABNF > rules without having to list all possible parameter combinations and > permutations. Yes. I agree. There is no good way to do this in ABNF. One could get "closer", with something like: dcmap-value = dcmap-stream-id *(";" dcmap-non-max-opt) [dcmap-max-opt] *(";" dcmap-non-max-opt) dcmap-non-max-opt = ordering-opt / subprotocol-opt / label-opt dcmap-max-opt = maxretr-opt / maxtime-opt Note that this separates the stream-id from the opts with ";" rather than " ". (It would be much harder while preserving the space.) But this still syntactically allows multiple use of the non-max-opts (e.g. multiple occurrences of ordering-opt.) So there is still a need for normative text to forbid that. IMO it is more straightforward to do all of these constraints in text. Thanks, Paul From nobody Wed Nov 12 12:11:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5353F1AD0C3 for ; Wed, 12 Nov 2014 12:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ8-tzf4iE2f for ; Wed, 12 Nov 2014 12:10:43 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id BF4581A879D for ; Wed, 12 Nov 2014 12:09:09 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 92D7D23F0603; Wed, 12 Nov 2014 21:09:08 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 21:09:08 +0100 From: "Stach, Thomas" To: Justin Uberti Thread-Topic: Continuous nomination and mapping to SIP Thread-Index: Ac/+tICtLIyfzfNOSjWrqblMRJRNQA== Date: Wed, 12 Nov 2014 20:09:08 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E253AE2MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hmIr7pm3bethEidjhCf3skZIRj0 Cc: Jonathan Lennox , =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: [MMUSIC] Continuous nomination and mapping to SIP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:10:55 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E253AE2MCHP04MSXglobal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, maybe is too early to get an answer, but how is the SIP INVITE transaction= and SDP offer/answer affected by continuous nomination? If I understand correctly, the nomination and trickling does not necessaril= y end when a 200OK is received for the INVITE. In that case the SDP Answer in the 200OK would not include all candidates, = but only those known at the time when the SIP 200 OK response is being sent= . Further candidates could still be trickled (and nominated) during the confi= rmed dialog. Is that correct? ... and related to another discussion, wouldn't that render the ICE update= d offer procedures either useless, or alternatively, would require a new of= fer/answer cycle each time a new candidate is nominated? Regards Thomas --_000_F81CEE99482EFE438DAE2A652361EE121E253AE2MCHP04MSXglobal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,

 

maybe is too early  to get an answer, but how i= s the SIP INVITE transaction and SDP offer/answer affected by continuous no= mination?

 

If I understand correctly, the nomination and trickl= ing does not necessarily end when a 200OK is received for the INVITE.<= /o:p>

In that case the SDP Answer in the 200OK would not i= nclude all candidates, but only those known at the time when the SIP 200 OK= response is being sent.

Further candidates could still be trickled (and nomi= nated) during the confirmed dialog.

Is that correct?

 

… and related to another discussion, wouldn= 217;t  that render the ICE updated offer procedures either useless, or= alternatively, would require a new offer/answer cycle each time a new cand= idate is nominated?

 

Regards

Thomas

 

--_000_F81CEE99482EFE438DAE2A652361EE121E253AE2MCHP04MSXglobal_-- From nobody Wed Nov 12 12:34:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA821A8745 for ; Wed, 12 Nov 2014 12:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tel5u8bTe-1Y for ; Wed, 12 Nov 2014 12:34:00 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F1B1A1A36 for ; Wed, 12 Nov 2014 12:34:00 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq12so3525562vcb.9 for ; Wed, 12 Nov 2014 12:33:59 -0800 (PST) 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=jPDaCK1DtYp7+bjOgYbR4VpMeW+3mMLPBT3uUEw3vzs=; b=Du/UNKWt9+h3vVvqig8vRKr3LdkkKS5qWtDFGSKZCCZbo+iIUafXw/GEkrptVMNM2b gVCw3Sl+S/DNLJcCbxcaawJsZwsEtdmfD2p+knTPTmlpRK/8b96AxsPlbkrqFViACLlr 44aRLAWeCskSPADCvvugIdAt2Ehkpy5NeKuxy/3O5B+PA7yVWlJ//arx0/RMimHjR/J6 PLmELLbaZEe0YKM7jo6yq8Yy9JbNbrqVQKsFEQaQsKynTYqhtQpaVj3gGqAqR4BvJVl5 v/qogQ+EOCN0S7mgSzbMXtVN1nIk+97n0uUiYfSngKANKmTXl0zIAwiFEUKEYktKzyFo YF/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jPDaCK1DtYp7+bjOgYbR4VpMeW+3mMLPBT3uUEw3vzs=; b=E+kS5FxxjfwPEg9at6rEhDiuYQM1V5tq/zqIwuBwCr7B5KnC640BQmGYBKelFPjTMM pxK9O5YzrdGS9fy6gsPXlyre6deyJmnkRYCUDnE9+i98jIurBmfQ9E7+rpLKF/hEU1HB T5l5dZg81MhHIoNN+BVAv/j3yoH/IeW/FIsdEAXrOahYa/P1IEjoMAx4mCdR8vqmaki8 eH7h1gGGaTAxvJUu3KfnV/8Idj/PsPycy2GWNxtbSCaUbrLUkcfzSjZVHanWC3gKwX06 K6XWhDbOPywHmXeP+D571qnHKOdoNIS9QLM/vYU5wocIpjNOgS9SedVlctG3gsKIf2BS Ykwg== X-Gm-Message-State: ALoCoQlsACt/v9hYmram0JXsFQ3viben+Y3d/CQcjcas1Io22ags+Abf+huKyhhqkEEOyQR1OCDK X-Received: by 10.52.170.78 with SMTP id ak14mr8212632vdc.60.1415824439419; Wed, 12 Nov 2014 12:33:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Wed, 12 Nov 2014 12:33:39 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Wed, 12 Nov 2014 12:33:39 -0800 Message-ID: To: "Stach, Thomas" Content-Type: multipart/alternative; boundary=047d7b86f54ec6cbd20507af507d Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xEZJjlooeZvWyBkqK4zvofe4sVo Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: Re: [MMUSIC] Continuous nomination and mapping to SIP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:34:03 -0000 --047d7b86f54ec6cbd20507af507d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 12, 2014 at 12:09 PM, Stach, Thomas wrote: > All, > > > > maybe is too early to get an answer, but how is the SIP INVITE > transaction and SDP offer/answer affected by continuous nomination? > > > > If I understand correctly, the nomination and trickling does not > necessarily end when a 200OK is received for the INVITE. > > In that case the SDP Answer in the 200OK would not include all candidates= , > but only those known at the time when the SIP 200 OK response is being se= nt. > Correct. > Further candidates could still be trickled (and nominated) during the > confirmed dialog. > > Is that correct? > Correct. Since they are sent as SIP INFO (IIRC), I don't think this presents a problem. > > > =E2=80=A6 and related to another discussion, wouldn=E2=80=99t that rende= r the ICE updated > offer procedures either useless, or alternatively, would require a new > offer/answer cycle each time a new candidate is nominated? > If we were going to strictly follow the rules, then yes, one would need to send an updated offer any time the selected pair changes. I defer any comments on whether this is a good idea to the updated-offer discussion we are going to have later this week. --047d7b86f54ec6cbd20507af507d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 12, 2014 at 12:09 PM, Stach, Thomas <<= a href=3D"mailto:thomas.stach@unify.com" target=3D"_blank">thomas.stach@uni= fy.com> wrote:

All,

=C2=A0

maybe is too early =C2=A0to get an answer, but how i= s the SIP INVITE transaction and SDP offer/answer affected by continuous no= mination?

=C2=A0

If I understand correctly, the nomination and trickl= ing does not necessarily end when a 200OK is received for the INVITE.

In that case the SDP Answer in the 200OK would not i= nclude all candidates, but only those known at the time when the SIP 200 OK= response is being sent.


Co= rrect.
=C2=A0

<= /u>

Further candidates could still be trickled (and nomi= nated) during the confirmed dialog.

Is that correct?

Correct. Since they are sent as SIP INFO (IIRC), I don't t= hink this presents a problem.=C2=A0

=C2=A0

=E2=80=A6 and related to another discussion, wouldn= =E2=80=99t =C2=A0that render the ICE updated offer procedures either useles= s, or alternatively, would require a new offer/answer cycle each time a new= candidate is nominated?


If= we were going to strictly follow the rules, then yes, one would need to se= nd an updated offer any time the selected pair changes. I defer any comment= s on whether this is a good idea to the updated-offer discussion we are goi= ng to have later this week.
--047d7b86f54ec6cbd20507af507d-- From nobody Wed Nov 12 12:37:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7911A19EC for ; Wed, 12 Nov 2014 12:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jTey5lGNTce for ; Wed, 12 Nov 2014 12:36:45 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5242B1A700E for ; Wed, 12 Nov 2014 12:36:44 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id hq11so911964vcb.17 for ; Wed, 12 Nov 2014 12:36:43 -0800 (PST) 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=wz5if7N9G1RYjeylgFLVaqvO8gJx36cAldGPsJ1R3kI=; b=Tda1HmqkvdA0/l1f8yjLTR7auqpc2Mx7jpDk5FXea6EZV1P86Xkp5bGE5lf8HbET1x vTmiZyCuFoWj6ByiJKvS4GGT4jBHKM8BxbEsktQrHdLhcLkeKrwTjZsnQm2/AW+n5Exu B1I4c42G28AzOM0CXayQbUeg+lzKUDKL1mAnc8zTuc+UWjJf6CnMYo6EP59ibVjsbsoR ICN/7a7juga3ImzWwKtJGLCrWZjcR5RRMs+MteEGzw6N37vl+9wr8hzziUalRpRoiax7 KBkp8YeSSH9VeGrUvizaXzxWo6A5McnukNjDdDbHoZ7uSCyv7Hm79J1UoyrkTtMls5VX HBsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wz5if7N9G1RYjeylgFLVaqvO8gJx36cAldGPsJ1R3kI=; b=dUUzO9WmsTEk1QLzlZjtQS8e9JFGBVfGumj+yX6UGQ4nWtFk0+XcGtuHsT0999liJr kPMdV6Akooc/QTNCiHEba8YWZFAWfxVFS7MY5foHv7+Sc7XSxhVxW/qUPNot78LX9m6B pcZiavZtuUTnvMqbN/zIL6JY+2stSu7pqE48OGd9YzbYCseWalwoWCbW5clEUGHYIoOH FQLuutmjwmA2cyCeRlUm61Vh0mXZkZwESg82dPL+15MKKnHKkD+5aOXew55LzglxBOpR POUdS1xBzIUDGAIV3JSXiTDKHPYvndURUhHBF+fCGWML0vnG7Yt1oDieS5Hj6EzXXobf p/eA== X-Gm-Message-State: ALoCoQld54PdWW1PZQJUKla/sc+dXQks1XwWUZzpGNBDrl49TpnnY3fKvvlw2IrZXxUKY0Sb7YSm X-Received: by 10.220.174.193 with SMTP id u1mr35975121vcz.28.1415824603426; Wed, 12 Nov 2014 12:36:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Wed, 12 Nov 2014 12:36:23 -0800 (PST) In-Reply-To: References: <546201BE.1000102@jitsi.org> <546277BA.7070402@jitsi.org> From: Justin Uberti Date: Wed, 12 Nov 2014 12:36:23 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=089e01538db28d513e0507af5a44 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/k_Zc9L5FAY_OhKDyfoIbJvCpXQM Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Bernard Aboba , Dan Wing , Christer Holmberg Subject: Re: [MMUSIC] Notes from Continuous Nomination discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:36:51 -0000 --089e01538db28d513e0507af5a44 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 11, 2014 at 4:47 PM, Justin Uberti wrote: > > > On Tue, Nov 11, 2014 at 12:55 PM, Emil Ivov wrote: > >> >> >> On 11.11.14, 21:26, Justin Uberti wrote: >> >>> >>> >>> On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov >> > wrote: >>> >>> >>> >>> On 11.11.14, 10:44, Justin Uberti wrote: >>> >>> Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) >>> met today >>> to discuss the goals for the work to improve ICE nomination. >>> >>> In short, there was good consensus that the goals outlined in >>> http://juberti.github.io/__draughts/nombis/draft-uberti-_ >>> _mmusic-nombis.html >>> >> mmusic-nombis.html> >>> (updated since the meeting) >>> are the correct goals to be shooting for, even if the exact >>> mechanisms >>> aren't completely nailed down. We think the goals enumerated by >>> Emil in >>> his email earlier this week are all covered by the goals in this >>> document. >>> >>> >>> Hm? I might have missed something but how does it cover the need to >>> detect an end of currently available candidates? How does one know >>> when it is safe to release unused candidates? >>> >>> >>> These questions are addressed specifically in the draft - Section 5.2, >>> paragraphs 5 >>> >> >> Indeed. That wasn't in the google doc however so I didn't realise you had >> changed it. It would have been nice to mention this. >> >> Anyways. Glad we are making progress. >> >> and 4, respectively. >>> >> >> OK, nice, almost there! >> >> What this doesn't yet say is that the released candidates would need to >> be regathered once new remote candidates start trickling in again. >> > > >> This is when it turns effectively in an ICE restart. >> > > Yes, we need to figure out how this should work. Released candidates won't > always need to be regathered; the new candidates might just be 'hey, try > these also'. But there are certainly mobility scenarios where one side > wants to inform the other that 'hey, my existing candidates are about to go > away, so we want to do a restart'. > > >> >> I agree with Martin that guidance on implementing restarts and handling >> existing pairs should address most concerns. >> > > Yes. It probably would be useful to walk through a few flows and see if > some patterns emerge. > Quick update - Emil and I synced up yesterday and I think we are overall in agreement. As a next step I am going to add Emil's examples to my document along with a few other examples we thought of and use that to figure out whether we are overlooking anything. --089e01538db28d513e0507af5a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 11, 2014 at 4:47 PM, Justin Uberti <juberti@google.com> wrote:

=

= On Tue, Nov 11, 2014 at 12:55 PM, Emil Ivov <emcho@jitsi.org> wrote:


On 11.11.14, 21:26, Justin Uberti wrote:


On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov <emcho@jitsi.org
 <mailto:emcho@jitsi= .org>> wrote:



=C2=A0 =C2=A0 On 11.11.14, 10:44, Justin Uberti wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Several of us (Bernard, Jonathan, Varun, Martin= , Brandon, Pal)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 met today
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to discuss the goals for the work to improve IC= E nomination.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In short, there was good consensus that the goa= ls outlined in
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://juberti.= github.io/__draughts/nombis/draft-uberti-__mmusic-nombis.html=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://juberti.= github.io/draughts/nombis/draft-uberti-mmusic-nombis.html= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (updated since the meeting)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are the correct goals to be shooting for, even = if the exact
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms
=C2=A0 =C2=A0 =C2=A0 =C2=A0 aren't completely nailed down. We think the= goals enumerated by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Emil in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 his email earlier this week are all covered by = the goals in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 document.


=C2=A0 =C2=A0 Hm? I might have missed something but how does it cover the n= eed to
=C2=A0 =C2=A0 detect an end of currently available candidates? How does one= know
=C2=A0 =C2=A0 when it is safe to release unused candidates?


These questions are addressed specifically in the draft - Section 5.2,
paragraphs 5

Indeed. That wasn't in the google doc however so I didn't realise y= ou had changed it. It would have been nice to mention this.

Anyways. Glad we are making progress.

and 4, respectively.

OK, nice, almost there!

What this doesn't yet say is that the released candidates would need to= be regathered once new remote candidates start trickling in again.


This is when it turns effectively in an ICE restart.
<= br>
Yes, we need to figure out how this should work. = Released candidates won't always need to be regathered; the new candida= tes might just be 'hey, try these also'. But there are certainly mo= bility scenarios where one side wants to inform the other that 'hey, my= existing candidates are about to go away, so we want to do a restart'.=
=C2=A0

I agree with Martin that guidance on implementing restarts and handling exi= sting pairs should address most concerns.

Yes. It probably would be useful to walk through a few flows and = see if some patterns emerge.=C2=A0

Quick update - Emil and I synced up yesterday and I think w= e are overall in agreement. As a next step I am going to add Emil's exa= mples to my document along with a few other examples we thought of and use = that to figure out whether we are overlooking anything.=C2=A0
--089e01538db28d513e0507af5a44-- From nobody Wed Nov 12 16:07:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEC81A0016 for ; Wed, 12 Nov 2014 16:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P55eqUa4ulBe for ; Wed, 12 Nov 2014 16:06:56 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FD61A0071 for ; Wed, 12 Nov 2014 16:06:51 -0800 (PST) Received: from ppp118-209-5-12.lns20.mel4.internode.on.net ([118.209.5.12]:53255 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XohuV-0007oS-Dr for mmusic@ietf.org; Thu, 13 Nov 2014 11:05:15 +1100 Message-ID: <5463F612.9070504@nteczone.com> Date: Thu, 13 Nov 2014 11:06:42 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5462D156.2080100@nteczone.com> <5463B04C.9090409@alcatel-lucent.com> In-Reply-To: <5463B04C.9090409@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EVQ0lRMZg8pXT3tgr00l0XDB6wI Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 00:06:58 -0000 Hello Juergen, Thanks for your reply. Please see below. Regards, Christian ..snip.. >> Hello >> >> I had a chance to look over the latest draft in more details. Some >> comments/questions: >> >> 5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated: >> dcmap-opt = ordering-opt / subprotocol-opt / label-opt >> / ( maxretr-opt / maxtime-opt ) > > [Juergen] Actually, I am not sure if this would formally prevent > maxretr-opt and maxtime-opt from both being present simultaneously, > as we would still have > dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] > (allowing an arbitrary number of "dcmap-opt"). > My understanding of RFC 5234's definition of "alternation" has so far > been that > dcmap-opt = ordering-opt / subprotocol-opt / label-opt / > maxretr-opt / maxtime-opt > and > dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( > maxretr-opt / maxtime-opt ) > are actually equivalent. > Right now don't see a "compact" way of strengthening the actual ABNF > rules without having to list all possible parameter combinations and > permutations. [CNG] Yes you're right. In other protocols this has been covered by an "At most once" statement on the ABNF. The ( ) would ensure that only one would be used. > > ..snip.. >> >> >> 5.1.1.4. max-retr parameter: This draft seems to use the absence of >> the "max-retr" parameter to indicate the use of a reliable channel It >> also indicates a default value of "unbounded". >> draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels >> this field MUST be set to 0 on the sending side and MUST be ignored >> on the receiving side." >> To better align with the data channel protocol i'd suggest changing >> the of 5.1.1.4 to indicate that "The max-retr parameter is optional >> with the default value equal to 0 indicating that no retramsmission >> is used. > > [Juergen] Our current intention is that the absence of "max-retr" and > "max-time" in the a=dcmap attribute value would indicate a reliable > data channel, similar as channel types "DATA_CHANNEL_RELIABLE" and > "DATA_CHANNEL_RELIABLE_UNORDERED" in DCEP's DATA_CHANNEL_OPEN message. > And that "max-retr=0" would actually indicate a partial reliable data > channel with the maximal number of retransmissions set to zero > (similar to DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT(_UNORDERED) and > "Reliability Parameter" = 0 in the DATA_CHANNEL_OPEN message). > If we kept this semantic of "max-retr=0", then a default value equal > to 0 would result in an a=dcmap attribute without "max-retr" parameter > actually indicating a correspondingly partial reliable data channel, > such that then the data channel would actually not be reliable as far > as I understand. [CNG] OK my point was that the behaviour should be defined better and your comment below covers it. As an aside, is there a reason why the draft doesn't follow the parameter structure of I-D.ietf-rtcweb-data-channel if its trying to emulate the information? i.e. a channel type and a reliability parameter. With these two parameters it's clear what type of data channel is being asked for rather than relying on the absence of parameters and also avoids having to specify valid combinations. It would allow support of new types (via the IANA registry) without new parameters. > > ..snip.. >> >> 5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about >> specific behaviour when the parameter is omitted rather than saying >> "unbounded". > > [Juergen] Agree. We should make this case more explicit and e.g. refer > to RFC 4960 and say: > "The max-time parameter is optional. If the max-time parameter is not > present, then the generic SCTP retransmission timing rules apply as > specified in [RFC 4960]." > > Similarly in 5.1.1.4; there we could e.g. say: > "The max-retr parameter is optional. If the max-retr parameter is not > present, then the maximal number of retransmissions is determined as > per the generic SCTP retransmission rules as specified in [RFC 4960]." > > Would you agree to this? [CNG] Yes > >> ..snip.. From nobody Thu Nov 13 02:49:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105EA1A6FEE for ; Thu, 13 Nov 2014 02:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jK3bT4zoozc for ; Thu, 13 Nov 2014 02:49:20 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714101A6FF2 for ; Thu, 13 Nov 2014 02:49:18 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-ce-54648cadef6a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.D0.24955.DAC84645; Thu, 13 Nov 2014 11:49:17 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.174.1; Thu, 13 Nov 2014 11:49:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ACF61110207; Thu, 13 Nov 2014 12:49:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 01F585F3DE; Thu, 13 Nov 2014 12:49:38 +0200 (EET) Received: from dhcp-9749.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CB4BE5F3A7; Thu, 13 Nov 2014 12:49:36 +0200 (EET) Message-ID: <54648CB1.6050401@ericsson.com> Date: Thu, 13 Nov 2014 00:49:21 -1000 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje7anpQQg69/BC2mLn/MYnFy5zZm ByaPJUt+Mnls73nMEsAUxWWTkpqTWZZapG+XwJWxfOlzxoLbChXfF59kamDskOpi5OCQEDCR OH5JrYuRE8gUk7hwbz1bFyMXh5DAEUaJ5cuvs4IkhAQ2MEo0vI+ASOxhlGh/uZQZIrGWUWLH BkWIBJD9YusdRpAEr4C2xL8tG8GKWARUJc4e+cYCYrMJOErcfvgSbKqoQLLEmq2T2CHqBSVO znwCViMiICOxd9NmsF5mAR2JRR83gdnCAoESf7atZIRY7Cextf0dWJxTwF/i+bTfrCDfMAvY SzzYWgbRKi/RvHU2M8RnahJXz22CullV4uq/V4wTGEVnIdk8C6F7FpLuBYzMqxhFi1OLk3LT jYz1Uosyk4uL8/P08lJLNjECo+Hglt+qOxgvv3E8xCjAwajEw7tBLiVEiDWxrLgy9xCjNAeL kjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwJgnyCh7f2LV2WW1ID8+/aXnhRUGH uwwTXrk63jlx9dLOuwFflBtagio2B/4WXxz5nU3uoYva9+PcZxldlC3cpfMe8jmcuCyU9kq9 79XL5ezG36Tr6ovXHpD5+8FpR9/96aoXT23lfz5HL77HhbPsdpBz/dbltz0n1Amssu73UeXc dEV7QXaGEktxRqKhFnNRcSIAcTaX3mcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TDcSxZMMZ0AZ6Zk1ec-3_mAm9K0 Subject: Re: [MMUSIC] Text proposal resolving the ICE-"unexpected answer" issue X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 10:49:22 -0000 I think this text proposal is good and would not mind adding it to the ICE SDP draft. Does anyone else have comments on this? Cheers, Ari (as individual contributor) On 10/7/14 3:26 AM, Stach, Thomas wrote: > All, > > at the last MMUSIC session I was asked to provide some text resolving > the "unexpected answer" issue that I brought up on the MMUSIC list. > > It took a while, but below is what I propose to include in > draft-ietf-mmusic-ice-sip-sdp. > > Currently there thee section dealing with the initial SDP offer/answer > exchange. > > 3. Sending the Initial Offer > > 4. Receiving the Initial Offer > > 5. Receipt of the Initial Answer > > Now, section 9 deals with subsequent SDP offer/answer exchanges, where > the new text needs to go in. > > It has subsections (9.1, 9.2) equivalent to 3 and 4 above, however, > nothing equivalent to 5. > > Thus, I think the existing 9.3 should be moved in new subsection 9.4 and > the following text should be introduced: > > 9.3 <#section-9.3>. Receiving the answer for a subsequent offer > > Some deployments of ICE include e.g. SDP-Modifying Signaling-only B2BUAs > [RFC7092] that modify the SDP body during the subsequent offer/answer > exchange. With the B2BUA being ICE-unaware a subsequent answer might be > manipulated and might not include SDP candidates although the initial > answer did. > > An example of a situation where such an “unexpected” answer might be > experienced appears when such aB2BUA introduces a media server during > call hold using 3^rd party call-control procedures. Omitting further > details how this is done this could result in an answer being received > at the holding UA that was constructed by the B2BUA. With the B2BUA > being ICE-unaware that answer would not include SDP candidates. > > Receiving an answer without ICE attributes in this situation might be > unexpected, but would not necessarily impair the user experience. > > In addition to procedures for the expected answer, the following > sections give also some advice how to recover from the unexpected situation. > > 9.3.1 Procedures for All Implementations > > When receiving an answer within an existing session for a subsequent > offer as specified in 9.1.2.2, an agent MUST verify ICE support as > specified in Section 5.1. > > 9.3.1.1 ICE restarts > > If ICE support is indicated in the SDP answer, the agent MUST perform > ICE restart procedures as specified in section 9.4 (the existing section > 9.3) below. > > If ICE support is no longer indicated in the SDP answer, the agent MUST > fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog just > because of missing ICE support. If the agent sends a new offer later on > it SHOULD perform an ICE restart as specified in 9.1.1.1. > > 9.3.1.2 Existing Media Streams with ICE Running > > If ICE support is indicated in the SDP answer, the agent MUST continue > ICE procedures as specified in section 9.4.1.4 (the existing section > 9.3.1.4) below. > > If ICE support is no longer indicated in the SDP answer, the agent MUST > abort the ongoing ICE processing and fall-back to RFC 3264 procedures. > The agent SHOULD NOT drop the dialog just because of missing ICE > support. If the agent sends a new offer later on, it SHOULD perform an > ICE restart as specified in 9.1.1.1. > > 9.3.1.3 Existing Media Streams with ICE Completed > > If ICE support is indicated in the SDP answer and if the answer conforms > to 9.2.2.3, the agent MUST remain in the ICE Completed state. > > If ICE support is no longer indicated in the SDP answer, the agent MUST > fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog just > because of this unexpected answer. Once the agent sends a new offer > later on it MUST perform an ICE restart. > > Existing 9.3 à*9.4* <#section-9.3>. Updating the Check and Valid Lists > > …. > > I’d like to get your feedback, if that proposal is reasonable. > > Regards > > Thomas > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Nov 13 11:32:41 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCB91ACD0F for ; Thu, 13 Nov 2014 11:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_EQyO8NPu9F for ; Thu, 13 Nov 2014 11:32:34 -0800 (PST) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6F01A8AF3 for ; Thu, 13 Nov 2014 11:32:34 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/13/2014 2:32:28 PM X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/7/2014 8:53:38 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-615/SG:5 11/13/2014 2:31:29 PM X-GBUdb-Analysis: 0, 67.231.149.202, Ugly c=0.737526 p=-0.970382 Source White X-Signature-Violations: 0-0-0-10995-c X-Note-419: 15.6266 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 11/13/2014 2:32:27 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.149.202 X-Note-Reverse-DNS: mx0a-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G241 G242 G243 G244 G248 G249 G361 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.149.202] (HELO mx0a-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 171231689 for mmusic@ietf.org; Thu, 13 Nov 2014 14:32:28 -0500 Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sADJWSLN005843 for ; Thu, 13 Nov 2014 14:32:29 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1qn2nm0038-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 13 Nov 2014 14:32:28 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 13:32:27 -0600 From: Jonathan Lennox To: mmusic Thread-Topic: RFC 6544: DTLS over 4571 framing over TCP Thread-Index: AQHP/3iOolFwBA8/I0ak56FUZ4KvaQ== Date: Thu, 13 Nov 2014 19:32:26 +0000 Message-ID: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.214] Content-Type: multipart/alternative; boundary="_000_44035890A5164D01A679A85032AA10EDvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-13_08:2014-11-13,2014-11-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411130148 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RKWHa3h1BAxevuE_GI17KkI-gGk Subject: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:32:38 -0000 --_000_44035890A5164D01A679A85032AA10EDvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here=92s the citation from RFC 6544 for DTLS over RFC 4571 framing over TCP= . 3. Overview of Operation [...] ICE requires an agent to demultiplex STUN and application-layer traffic, since they appear on the same port. This demultiplexing is described in [RFC5245] and is done = using the magic cookie and other fields of the message. Stream-oriented transports introduce another wrinkle, since they require a way to frame the connection so that the application and STUN packets can be extracted in order to differentiate STUN packets from application-layer traffic. For this reason, TCP media streams utilizing ICE use the basic framing provided in RFC 4571 [RFC4571], even if the application layer protocol is not RTP. When Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) is used, they are also run over the RFC 4571 framing shim, while STUN runs outside of the (D)TLS connection. The resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on the left side and without it on the right side. +----------+ | | | App | +----------+----------+ +----------+----------+ | | | | | | | STUN | (D)TLS | | STUN | App | +----------+----------+ +----------+----------+ | | | | | RFC 4571 | = | RFC 4571 | +---------------------+ +---------------------+ | | | | | TCP | | TCP | +---------------------+ +---------------------+ | | | | | IP | | IP | +---------------------+ +---------------------+ Figure 1: ICE TCP Stack with and without (D)TLS --_000_44035890A5164D01A679A85032AA10EDvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8F3846565DE2AC4D862708F53344EF06@vidyo.com> Content-Transfer-Encoding: quoted-printable 
Here=92s the citation from RFC 6544 for DTLS over RF=
C 4571 framing over TCP. 
3.  Overview of Operation
   [...]
   ICE requires an agent to demultiplex STUN and app=
lication-layer
   traffic, since they appear on the same port.  This demultiplexing is
   described in [RFC5245=
] and is done using the magic cookie and other
   fields of the message.  Stream-oriented transports introduce another
   wrinkle, since they require a way to frame the connection so that the
   application and STUN packets can be extracted in order to
   differentiate STUN packets from application-layer traffic.  For this
   reason, TCP media streams utilizing ICE use the basic framing
   provided in RFC 4571=
 [RFC4571], even if the applicat=
ion layer
   protocol is not RTP.

   When Transport Layer Security (TLS) or Datagram Transport Layer
   Security (DTLS) is used, they are also run over the RFC 4571 framing
   shim, while STUN runs outside of the (D)TLS connection.  The
   resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on
   the left side and without it on the right side.

                       +----------+
                       |          |
                       |    App   |
            +----------+----------+     +----------+---=
-------+
            |          |          |     |          |          |
            |   STUN   |  (D)TLS  |     |   STUN   |    App   |
            +----------+----------+     +----------+---=
-------+
            |                     |     |                     |
            |      RFC 4571=
       |     |      RFC=
 4571       |
            +---------------------+     +---------------------&=
#43;
            |                     |     |                     |
            |         TCP         |     |         TCP         |
            +---------------------+     +---------------------&=
#43;
            |                     |     |                     |
            |         IP          |     |         IP          |
            +---------------------+     +---------------------&=
#43;

              Figure 1: ICE TCP Stack with and without (D)TLS

--_000_44035890A5164D01A679A85032AA10EDvidyocom_-- From nobody Thu Nov 13 11:37:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC681ACD84 for ; Thu, 13 Nov 2014 11:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBEryoLLY2GK for ; Thu, 13 Nov 2014 11:37:39 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F661ACE45 for ; Thu, 13 Nov 2014 11:36:56 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B21EB7EC1388C for ; Thu, 13 Nov 2014 19:36:50 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sADJarNF030516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Nov 2014 20:36:54 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 20:36:53 +0100 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" Thread-Topic: draft-nandakumar-mmusic-proto-iana-registration-00 Thread-Index: Ac//eSwk52GPSOCCTCuZWCX0n++Akw== Date: Thu, 13 Nov 2014 19:36:53 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B27A2DB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xooyuftkN3ZnHUTkh1e5onDJGXU Subject: [MMUSIC] draft-nandakumar-mmusic-proto-iana-registration-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:37:41 -0000 So based on the discussion just taking place in MMUSIC I would make the fol= lowing two comments: 1) In section 3, every item should contain a normative reference to the RFC= (or other document) that defines the framing structure that goes with that= label. 2) In section 4, I would prefer to see text that defines exactly the change= s that need to be made and to exactly where. So this is to the "proto" subregistry within "Session Description Protocol = (SDP) Parameters" registry. And essentially for every entry you need to state: Type: protoc SDP Name: ... Reference: ... Will the reference just be to this draft, or to this draft and the document= that also defines the framing. Regards Keith= From nobody Thu Nov 13 12:46:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C859F1AD3C4 for ; Thu, 13 Nov 2014 12:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT34701lFU9e for ; Thu, 13 Nov 2014 12:46:25 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941431AD391 for ; Thu, 13 Nov 2014 12:46:24 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so2854664vcb.36 for ; Thu, 13 Nov 2014 12:46:23 -0800 (PST) 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=erCwpsE+1AVDxVot0NpBxZQdHbjvWMWB+N3tqG9+tT0=; b=MIAi609Eaq2sa9dc2zKi49WJwOQ8r3PDn/6Cgbkv0x6yXLc83G4dYrHFh8NeFcE5sM obfw7FMsKZP1H9XxM43TvrgIXvM3Fir8GuFxj4zDsal52ca11SBUgOfT86beB2FVzRCi XwZHlCsViQ+ljJbqyKPbH4gqc2b//PJzT+dlEGlEipyQRb/FG/4CgiGB82i/hWV731HK mgZRTorRD+t07kWI/SOj1BwuEjs9CC8q6vnR98q37Jyxu1JJUCwG2/sbnA7xVUNKBGUp AnfqAvAXLUeWiWYyHE4/4dLoFv0Q/jwO6wF4b5xnj58UXWPyGpMG/b8kv1AMxQPkMWay UynQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=erCwpsE+1AVDxVot0NpBxZQdHbjvWMWB+N3tqG9+tT0=; b=KOJRKmtRM/zS6IR9QFxJP/Yft8Zwp256iMZbLZ/Ixo1g0eQHnq5brPN3arESX7dath LIro/qTruK2CLToe203GDKaZtYSgaPiFvBhJkuGM5iuFMEhZqjsLZgitLENgeJi4Wdp7 0k8W0/hETvZwX0lv1TbxlfKJfL3cQG3vOoqSYyDzeRHjlPFSkDnQ2QSkiuC2hlvuWeuu rjH8fH/X7kb1ocrb6LXz8BbjSYSfLamrmTWuoTIEDBKdeo789BlrSBJ4KH5U1vbxRuIa xSVCjUFREo4/jVtct2t3Xc4UNnqxhLuOJXiTxPYVJsQo2GGelZC9DCt3+zltdZEI3ltX XLVg== X-Gm-Message-State: ALoCoQm+QQaD64GA57sKwx/yVwfug4R7QaeEq+0fpFeO/an6Z1jsOY6mg5fstXDhqksSKR9uKw4J X-Received: by 10.52.228.67 with SMTP id sg3mr3045968vdc.2.1415911583593; Thu, 13 Nov 2014 12:46:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Thu, 13 Nov 2014 12:46:03 -0800 (PST) In-Reply-To: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> References: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> From: Justin Uberti Date: Thu, 13 Nov 2014 12:46:03 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=089e01183d4ef958d00507c39a2a Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f2--iEL28BwM0LipeJWiGcyDNZY Cc: mmusic Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:46:29 -0000 --089e01183d4ef958d00507c39a2a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that makes the framing very clear; it is unfortunate that it is coupled to ICE, but we can fix that by revving 4571. On the topic of naming, RFC 4572 makes the meaning of TCP/TLS clear; it's (non-D) TLS. However, TCP transport for media isn't guaranteed to be reliable, as explained in 4571, Section 3 : The reliable nature of a connection does not imply that a framed RTP stream has a contiguous sequence number ordering. For example, if the connection is used to tunnel a UDP stream through a network middlebox that only passes TCP, the sequence numbers in the framed stream reflect any packet loss or reordering on the UDP portion of the end-to-end flow. This necessarily implies that we want to use DTLS whenever the layer 4 transport is TCP. We could try to be explicit about this by making the identifiers TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some inconsistency with RFC5763, which indicates use of DTLS via UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since you would only want to run DTLS over UDP). So I think we have two options: a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the definitions of these that DTLS is to be used here. b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight inconsistency with the UDP variants from 5763. Personally, I prefer b) as being less error-prone. Lastly, for SCTP transport over DTLS over UDP, I think we should use UDP/TLS/SCTP for consistency with 5763. On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox wrote: > Here=E2=80=99s the citation from RFC 6544 for DTLS over RFC 4571 framing= over TCP. > > 3. Overview of Operation > > [...] > > ICE requires an agent to demultiplex STUN and application-layer > traffic, since they appear on the same port. This demultiplexing is > described in [RFC5245 ] and is do= ne using the magic cookie and other > fields of the message. Stream-oriented transports introduce another > wrinkle, since they require a way to frame the connection so that the > application and STUN packets can be extracted in order to > differentiate STUN packets from application-layer traffic. For this > reason, TCP media streams utilizing ICE use the basic framing > provided in RFC 4571 [RFC4571 ], even if the application layer > protocol is not RTP. > > When Transport Layer Security (TLS) or Datagram Transport Layer > Security (DTLS) is used, they are also run over the RFC 4571 framing > shim, while STUN runs outside of the (D)TLS connection. The > resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on > the left side and without it on the right side. > > +----------+ > | | > | App | > +----------+----------+ +----------+----------+ > | | | | | | > | STUN | (D)TLS | | STUN | App | > +----------+----------+ +----------+----------+ > | | | | > | RFC 4571 |= | RFC 4571 | > +---------------------+ +---------------------+ > | | | | > | TCP | | TCP | > +---------------------+ +---------------------+ > | | | | > | IP | | IP | > +---------------------+ +---------------------+ > > Figure 1: ICE TCP Stack with and without (D)TLS > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e01183d4ef958d00507c39a2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that makes the framing very clear; it is unfortuna= te that it is coupled to ICE, but we can fix that by revving 4571.

=
On the topic of naming, RFC 4572 makes the meaning of TCP/TLS clear; it's (non-D) T= LS.=C2=A0

However, TCP transport for media isn'= ;t guaranteed to be reliable, as explained in 4571, Section 3:

= 
      The reliable nature of a connection does not imply tha=
t a framed
      RTP stream has a contiguous sequence number ordering.  For
      example, if the connection is used to tunnel a UDP stream through
      a network middlebox that only passes TCP, the sequence numbers in
      the framed stream reflect any packet loss or reordering on the UDP
      portion of the end-to-end flow.

This n= ecessarily implies that we want to use DTLS whenever the layer 4 transport = is TCP.

We could try to be explicit about this by = making the identifiers TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this intro= duces some inconsistency with RFC5763, which indicates use of DTLS via UDP/= TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since you would= only want to run DTLS over UDP).=C2=A0

So I think= we have two options:
a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, = and make it clear in the definitions of these that DTLS is to be used here.=
b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the s= light inconsistency with the UDP variants from 5763.

Personally, I prefer b) as being less error-prone.

<= div>Lastly, for SCTP transport over DTLS over UDP, I think we should use UD= P/TLS/SCTP for consistency with 5763.


On Thu, Nov 13, 2014 at 11:= 32 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
Here=E2=80=99s the citation from RFC 6544 for DTLS over RFC 4571 frami=
ng over TCP. 
3.=C2=A0 Overview of Operation
   [...]
   ICE requires an agent to demultiplex STUN and application-layer
   traffic, since they appear on the same port.  This demultiplexing is
   described in [RFC5245] and is done using the magic cookie and other
   fields of the message.  Stream-oriented transports introduce another
   wrinkle, since they require a way to frame the connection so that the
   application and STUN packets can be extracted in order to
   differentiate STUN packets from application-layer traffic.  For this
   reason, TCP media streams utilizing ICE use the basic framing
   provided in RFC 4571 [RFC4571], even if the application layer
   protocol is not RTP.

   When Transport Layer Security (TLS) or Datagram Transport Layer
   Security (DTLS) is used, they are also run over the RFC 4571 framing
   shim, while STUN runs outside of the (D)TLS connection.  The
   resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on
   the left side and without it on the right side.

                       +----------+
                       |          |
                       |    App   |
            +----------+----------+     +----------+----------+
            |          |          |     |          |          |
            |   STUN   |  (D)TLS  |     |   STUN   |    App   |
            +----------+----------+     +----------+----------+
            |                     |     |                     |
            |      RFC 4571       |     |      RFC 4571       |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         TCP         |     |         TCP         |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         IP          |     |         IP          |
            +---------------------+     +---------------------+

              Figure 1: ICE TCP Stack with and without (D)TLS


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


--089e01183d4ef958d00507c39a2a-- From nobody Thu Nov 13 13:14:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115501AD590 for ; Thu, 13 Nov 2014 13:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9v9LsoiTCNe for ; Thu, 13 Nov 2014 13:14:48 -0800 (PST) Received: from BLU004-OMC2S12.hotmail.com (blu004-omc2s12.hotmail.com [65.55.111.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369541AD597 for ; Thu, 13 Nov 2014 13:14:03 -0800 (PST) Received: from BLU406-EAS115 ([65.55.111.71]) by BLU004-OMC2S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 13 Nov 2014 13:14:02 -0800 X-TMN: [Pv5SrIeFNh/mQM2xmN7ffyD6W3t0iQFO] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Date: Thu, 13 Nov 2014 11:14:00 -1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0114_01CFFF32.ED0773D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac//hrDTDB8sQcnDQHelyuRbbhz+hw== Content-Language: en-us X-OriginalArrivalTime: 13 Nov 2014 21:14:02.0705 (UTC) FILETIME=[BFE2DC10:01CFFF86] Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uAD9qElW9lNdz4m02s8N673HtdI Subject: [MMUSIC] IPR declaration relating to draft-burman-mmusic-sdp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 21:14:51 -0000 ------=_NextPart_000_0114_01CFFF32.ED0773D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Microsoft previously filed an IPR declaration relating to draft-westerlund-avtcore-rtp-simulcast: https://datatracker.ietf.org/ipr/2157/ Given the contents of Section V of that declaration ("Disclosure of Patent Information"), the WG should be aware that this declaration may also relate to draft-burman-mmusic-sdp-simulcast ------=_NextPart_000_0114_01CFFF32.ED0773D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Microsoft previously filed an IPR declaration relating = to draft-westerlund-avtcore-rtp-simulcast:

https://datatracker.ietf.= org/ipr/2157/

 

Given the = contents of Section V of that declaration (“Disclosure of Patent = Information”), the WG should be aware that this declaration may = also relate to = draft-burman-mmusic-sdp-simulcast

------=_NextPart_000_0114_01CFFF32.ED0773D0-- From nobody Thu Nov 13 14:35:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40241AE09A for ; Thu, 13 Nov 2014 14:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ-Bku_uqUZH for ; Thu, 13 Nov 2014 14:35:34 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06121AE062 for ; Thu, 13 Nov 2014 14:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=780; q=dns/txt; s=iport; t=1415918076; x=1417127676; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=C9NnJXKF04H6yMG6TryVKug8LPUTtBlUU8HA0VR7pvE=; b=Tk8ItRfVYyUHFe8ebjB/91EGxdiHrFiGpU4QdaoDZ7Y5bctHVHLH3ODl DB8gkbHdtQYmD+mSOqbqTImFaSbsKoTKdT1gr5CIwTELMIIRzKDJidoQB 0vJY4I9rfw8Fwknxh83/eLF0Hian81c05D1bj5DVk36e32ctLEzeOMX0K s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwIAHgwZVStJA2F/2dsb2JhbABbgw6BMYMC0V6BBRYBAQEBAX2ECSMRVwEiAiYCBDAVEgSIVKsvj0KWKQEBAQEBAQQBAQEBAQEBG4EtkmU2gR4FkjqLd5Zng3yCNYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,380,1413244800"; d="scan'208";a="96439899" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 13 Nov 2014 22:34:35 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sADMYYiK011003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Nov 2014 22:34:35 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 16:34:34 -0600 From: "Pal Martinsen (palmarti)" To: mmusic Thread-Topic: STUN Transactions, still needed in ICE? Thread-Index: AQHP/5H/1fIi8h64DEimadz0y+I+Yw== Date: Thu, 13 Nov 2014 22:34:33 +0000 Message-ID: <2E9E03AE-DEF0-4C17-AB8A-BB59A87D9126@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.118.97] Content-Type: text/plain; charset="utf-8" Content-ID: <3E319DAFAD08C343A305B0E13307034A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YxoQ5S_UlA_PMK4D35AIP2Cs21U Subject: [MMUSIC] STUN Transactions, still needed in ICE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 22:35:39 -0000 SGksDQoNCkR1cmluZyB0aGUgVFJBTSBtZWV0aW5nIGl0IHdhcyBicmllZmx5IGRpc2N1c3NlZCBp ZiB3ZSBjb3VsZCBjaGFuZ2luZyB0aGUgU1RVTiB0cmFuc2FjdGlvbiBJRCB3aGVuIHJldHJhbnNt aXR0aW5nIGEgU1RVTiByZXF1ZXN0LiBNYWluIHJlYXNvbiBpcyB0byBnZXQgbW9yZSBhY2N1cmF0 ZS9lYXNpZXIgUlRUIG1lYXN1cmVtZW50cy4NCg0KQ2FuIHdlIHJlbW92ZSB0aGUgU1RVTiB0cmFu c2FjdGlvbiBjb25jZXB0IGZyb20gSUNFYmlzIHdpdGhvdXQgYnJlYWtpbmcgYW55dGhpbmc/IFdv dWxkIHRoZXJlIGJlIHNpbXBsaWZpY2F0aW9uIHRoZXJlIGFzIHdlbGwgYXMgd2Ugbm8gbG9uZ2Vy IHdvdWxkIG5lZWQgdHdvIHRpbWVycyAoT25lIHRyYW5zYWN0aW9uIHRpbWVyIGFuZCBvbmUgcmV0 cmFuc21pdCB0aW1lcikuIA0KDQpGcm9tIGEgY29kZSAoQXQgbGVhc3QgbWluZS4uKSBwZXJzcGVj dGl2ZSBpdCB3b3VsZCBzaW1wbGlmeSB0aGUgU1RVTiBwYXJ0IChjbGllbnQvc2VydmVyKSBhbmQg cHV0IHNvbWUgbW9yZSBsb2dpYyBpbnRvIHRoZSBJQ0UgcGFydC4gDQoNCi4tLg0KUMOlbC1Fcmlr From nobody Thu Nov 13 16:10:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CFF1A001D for ; Thu, 13 Nov 2014 16:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfEIMKsH36Tw for ; Thu, 13 Nov 2014 16:10:42 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE78F1A009E for ; Thu, 13 Nov 2014 16:10:35 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-05v.sys.comcast.net with comcast id FCAN1p00757bBgG01CAblw; Fri, 14 Nov 2014 00:10:35 +0000 Received: from dhcp-a55a.meeting.ietf.org ([31.133.165.90]) by resomta-po-13v.sys.comcast.net with comcast id FC8S1p00T1xLjbz01C8VCt; Fri, 14 Nov 2014 00:08:33 +0000 Message-ID: <546547FA.2060207@alum.mit.edu> Date: Thu, 13 Nov 2014 14:08:26 -1000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B27A2DB@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B27A2DB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415923835; bh=ksE6U7ktYuwRwNrcOuXcP8sqrY4+72aVphf5zLegIQ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WGFfdas4yEWCNTDTTRBdKjGb4H04Od6p5y3sKNhwei1MSDE+sf9dgGF7kuaMXbZEW kFybhYblZw1dwF+gQKDYwsefIOW1r9NTcPJKp8+T2NTXqDRpNYvN6MXJPC0iilCdl6 o03/JnQ6V7aolBw5P61IBH4Oa2dr2Ge4GXHU9arMyLo6MXbiqQn6s/GBgTLx/owfoK P8jqcYAdPuPigOcYtA3Yx6NtTBpEvTTVia7m8AiK9U6N7JOEyK0Vy+B7c0m6AOAZTj /vx9x+D4OlpHBtS5d5Z+cBNqX6IskrnnbrS+ueWNeXaWNKhJlMCgW9xQDBat7+dlXU JWeGbPOkFTeLQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RGodVLu5ZNnerSftFLIw8bvnNhM Subject: Re: [MMUSIC] draft-nandakumar-mmusic-proto-iana-registration-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 00:10:44 -0000 On 11/13/14 9:36 AM, DRAGE, Keith (Keith) wrote: > So based on the discussion just taking place in MMUSIC I would make the following two comments: > > 1) In section 3, every item should contain a normative reference to the RFC (or other document) that defines the framing structure that goes with that label. We are talking about protos of the form A/B/C/D For each boundary in there (A/B, B/C, C/D) there must exist, somewhere, a definition of how the upper layer is packaged within the lower layer. This is basic network stack stuff. In many cases the lower layer has a well defined mechanism for this. In some cases (e.g. TCP) it does not. In some cases the upper layer spec has a specification for how it is framed over specific lower layers. In some cases it may need to be separate. We probably don't want to force people to declare the obvious. But may not be clear what is obvious and what is not. Thanks, Paul > 2) In section 4, I would prefer to see text that defines exactly the changes that need to be made and to exactly where. > > So this is to the "proto" subregistry within "Session Description Protocol (SDP) Parameters" registry. > > And essentially for every entry you need to state: > Type: protoc > SDP Name: ... > Reference: ... > > Will the reference just be to this draft, or to this draft and the document that also defines the framing. > > Regards > > Keith > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Nov 13 17:31:41 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56621A19E3 for ; Thu, 13 Nov 2014 17:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6VEzmt4Eh1r for ; Thu, 13 Nov 2014 17:31:38 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCC71A00B8 for ; Thu, 13 Nov 2014 17:31:37 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id x69so11180609oia.7 for ; Thu, 13 Nov 2014 17:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=WYy0xH9xaRNMXvrObDKauuw1PrpjbGACJELF1Pg5WIs=; b=wjWLeQ+WDRn4YRt6BtqJP9JCPSh/tWDHnEOmkV2eZVrnV8Y0LHXpp8ECpBGoBJ60Qd vMcsn/d2Xdm3wetboRLVCPn6vj8oZTWmEodpaKGlcU+Top+m/ExhxedwAYNY/olaX8cV KpUoCqWSRy61QVN7I0jGtrorBVmMegpQ0lSYcj1Mn0iZcAJKnVvsyMCsdf27uFa//Wms f10xrMMreqbTxPmnrj9iimBhjgcWbkn+YXRdMoRec185e57YltHfUp6vd4XIeTJ9hp5r OrFwiQtu9wLiQ4ogMGKhPsMSnbhtNP9dJSyKoH0z9gPb4ADILagRF//jjKZoKJmAimWJ nodg== X-Received: by 10.202.227.73 with SMTP id a70mr4688691oih.59.1415928697016; Thu, 13 Nov 2014 17:31:37 -0800 (PST) MIME-Version: 1.0 References: <2E9E03AE-DEF0-4C17-AB8A-BB59A87D9126@cisco.com> From: Martin Thomson Date: Fri, 14 Nov 2014 01:31:36 +0000 Message-ID: To: "Pal Martinsen (palmarti)" , mmusic Content-Type: multipart/alternative; boundary=001a114093d20359670507c79720 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hiJ1QJNXbChlWDhQEtKGApzSn6M Subject: Re: [MMUSIC] STUN Transactions, still needed in ICE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 01:31:39 -0000 --001a114093d20359670507c79720 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let me get this straight. This would, in effect, remove the transaction id re-use requirement (?). You would maintain the retransmission timing with back-off, though, and basically everything else stays the same. In the repeated id mode that you would have us drop, forgetting about requests is covered by a single timer that might run after the retransmission of requests ceases. In the proposed mode, you might use a timer for every request. You don't have to, but it makes it feasible. And it then makes the timing stuff possible in light of retransmission. P.s. this is actually what I did when I built ICE. Just one of many things that I willfully violated in 5245. On Thu, Nov 13, 2014, 12:35 Pal Martinsen (palmarti) wrote: > Hi, > > During the TRAM meeting it was briefly discussed if we could changing the > STUN transaction ID when retransmitting a STUN request. Main reason is to > get more accurate/easier RTT measurements. > > Can we remove the STUN transaction concept from ICEbis without breaking > anything? Would there be simplification there as well as we no longer wou= ld > need two timers (One transaction timer and one retransmit timer). > > From a code (At least mine..) perspective it would simplify the STUN part > (client/server) and put some more logic into the ICE part. > > .-. > P=C3=A5l-Erik > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114093d20359670507c79720 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let me get this straight. This would, in effect, remove the transaction id = re-use requirement (?). You would maintain the retransmission timing with b= ack-off, though, and basically everything else stays the same.

In th= e repeated id mode that you would have us drop, forgetting about requests i= s covered by a single timer that might run after the retransmission of requ= ests ceases. In the proposed mode, you might use a timer for every request.= You don't have to, but it makes it feasible. And it then makes the tim= ing stuff possible in light of retransmission.

P.s. this is actually= what I did when I built ICE. Just one of many things that I willfully viol= ated in 5245.

On Thu, Nov 13, 2014, 12:35= =C2=A0Pal Martinsen (palmarti) <pa= lmarti@cisco.com> wrote:
Hi,

During the TRAM meeting it was briefly discussed if we could changing the S= TUN transaction ID when retransmitting a STUN request. Main reason is to ge= t more accurate/easier RTT measurements.

Can we remove the STUN transaction concept from ICEbis without breaking any= thing? Would there be simplification there as well as we no longer would ne= ed two timers (One transaction timer and one retransmit timer).

>From a code (At least mine..) perspective it would simplify the STUN part (= client/server) and put some more logic into the ICE part.

.-.
P=C3=A5l-Erik
_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic
--001a114093d20359670507c79720-- From nobody Thu Nov 13 21:38:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810581A6FAA for ; Thu, 13 Nov 2014 21:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkTzexlWlEdv for ; Thu, 13 Nov 2014 21:38:54 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDEA1A1B6E for ; Thu, 13 Nov 2014 21:38:54 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so1603638wiw.3 for ; Thu, 13 Nov 2014 21:38:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LdpIulQqli15wrfffg8mVfIjtq/nlYRo+f+u9c6YgHI=; b=ZlQwpqgcvSg1zpBYgXOrBt5k0a3UCPlkgZdL0YBliJ2all0uNf+ChOGEpwtdID7LL/ QNwja8JPlfmATgVhj0jvifvxSysaKMRhRvmk5jWlOaJlg++YlV4ISHBpDc2AJh+n4WRV paYaEnEUubCDsVWFOQfpSrgPjj8S/3t8YqtQLiXCbn4T2YIPSVm2NS/3c3XKIOYMwgOE MjbvifEIi+Ga40TKNGBcgQKM41GONoyGL3Hw9SkFLtbvp/TxGlbdZxgqwvH3+DBGv+CA EwaZ4v1IaYXIO05adDFIK66S4WTJq/f3EhLNz62E4vQS+PfX863drSbdrYy1UHl4bG7A La7A== X-Gm-Message-State: ALoCoQn8gROQUttcchQYSRI0pcRXMX1nh8lO0FkNC27D3fcIeuGhfjso5ov2/QyZIpVNbTcmMftl X-Received: by 10.180.198.230 with SMTP id jf6mr4321094wic.42.1415943533013; Thu, 13 Nov 2014 21:38:53 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id u13sm1975964wiv.10.2014.11.13.21.38.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 21:38:51 -0800 (PST) Message-ID: <5465956A.8090001@jitsi.org> Date: Fri, 14 Nov 2014 06:38:50 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , mmusic References: <2E9E03AE-DEF0-4C17-AB8A-BB59A87D9126@cisco.com> In-Reply-To: <2E9E03AE-DEF0-4C17-AB8A-BB59A87D9126@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/V5rjK1kQKUohBqVhD8p1JT_dpbg Subject: Re: [MMUSIC] STUN Transactions, still needed in ICE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 05:38:56 -0000 On 13.11.14, 23:34, Pal Martinsen (palmarti) wrote: > Hi, > > During the TRAM meeting it was briefly discussed if we could changing > the STUN transaction ID when retransmitting a STUN request. Main > reason is to get more accurate/easier RTT measurements. > > Can we remove the STUN transaction concept from ICEbis without > breaking anything? Would there be simplification there as well as we > no longer would need two timers (One transaction timer and one > retransmit timer). > > From a code (At least mine..) perspective it would simplify the STUN > part (client/server) and put some more logic into the ICE part. I guess that for anyone who did implement transactions as per the spec, this would be a considerable effort. For us it certainly would be. Much more so than the perceived gain of improving RTT measurements. Wouldn't it be easier to just repurose three or four bits from the transaction ID and use them as a counter? This way the receiving side can also learn about loss and use it as a factor in constructing pair preferences. Emil -- https://jitsi.org From nobody Thu Nov 13 21:51:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592591A6FDA for ; Thu, 13 Nov 2014 21:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8RFCsy8rE3Y for ; Thu, 13 Nov 2014 21:51:30 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA431A6FFA for ; Thu, 13 Nov 2014 21:51:29 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so1618570wiv.6 for ; Thu, 13 Nov 2014 21:51:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kQD4+WCgw+vT9sYTtK29sdrj6R/qf9EK4xwY8hTxK9E=; b=Z41jC/nGnhlnmcdDRpygAq6BcQU0JSfOeYmcknKnENctYJ8jnGLho3gI3YxEy4AP8i LvVI3Z0D9cbYBl5hS4CUc0zru/LXjn3QccmtnJPGQWx1RpfgFhBxKeCw5gj2SkC+U0dE Ja8cqM13lp0vD8TtdGQm1tRRz5u6oFol6QndHRVDjgxYtrOoLUsZ3tS0l4fbmoEESQz/ cLhAsOCtZYXNJi0Mz05nql1Mo9KL8dUK+z1TLipDAZbvmjezbOsm2GaQm1q6mEPej6m4 WFIho6X3HBdqGUXBwmt5UHyvRONAQOMBNIuIEAwjGKCJjp0RhOhvURE7vNmr8cnsZi3X uSOw== X-Gm-Message-State: ALoCoQnLJn8j9ybS/AMxefH5b4hPiFhEO67p90wUYuwUMpkFD0Hkn1Ol3TVYCTgqzz0LqZzifZYe X-Received: by 10.194.89.129 with SMTP id bo1mr10568368wjb.29.1415944288463; Thu, 13 Nov 2014 21:51:28 -0800 (PST) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id mu4sm2017755wib.2.2014.11.13.21.51.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 21:51:26 -0800 (PST) Message-ID: <5465985D.2090806@jitsi.org> Date: Fri, 14 Nov 2014 06:51:25 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , mmusic References: <2E9E03AE-DEF0-4C17-AB8A-BB59A87D9126@cisco.com> <5465956A.8090001@jitsi.org> In-Reply-To: <5465956A.8090001@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1JqsIJHQNIQrjvpvQea3hP_KbkI Subject: Re: [MMUSIC] STUN Transactions, still needed in ICE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 05:51:34 -0000 On 14.11.14, 6:38, Emil Ivov wrote: > On 13.11.14, 23:34, Pal Martinsen (palmarti) wrote: >> Hi, >> >> During the TRAM meeting it was briefly discussed if we could changing >> the STUN transaction ID when retransmitting a STUN request. Main >> reason is to get more accurate/easier RTT measurements. >> >> Can we remove the STUN transaction concept from ICEbis without >> breaking anything? Would there be simplification there as well as we >> no longer would need two timers (One transaction timer and one >> retransmit timer). >> >> From a code (At least mine..) perspective it would simplify the STUN >> part (client/server) and put some more logic into the ICE part. > > I guess that for anyone who did implement transactions as per the spec, > this would be a considerable effort. For us it certainly would be. Much > more so than the perceived gain of improving RTT measurements. > > Wouldn't it be easier to just repurose three or four bits from the > transaction ID and use them as a counter? This way the receiving side > can also learn about loss and use it as a factor in constructing pair > preferences. And obviously there's also the option of just doing that in an extra attribute. And just to be clear, I do think improving the RTT measurement would be a good thing. I just don't believe that repurposing the entire transaction ID as a counter is the best way to do it. Emil -- https://jitsi.org From nobody Fri Nov 14 09:36:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C51A1B22; Fri, 14 Nov 2014 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjWwrsA2d4Ov; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B6A1A1B14; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9F109F68A2C77; Fri, 14 Nov 2014 17:36:05 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sAEHa86J013836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 18:36:08 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 18:36:08 +0100 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" , "mmusic@ietf.org" , CLUE , "avt@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Thread-Index: AQHQAAM2TU9IvAskwUumiAHVoVNISJxgYKPwgAABkqA= Date: Fri, 14 Nov 2014 17:36:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B27B43B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RFCOVVl1tnAfBU4w0ipVMLWmD98 Subject: [MMUSIC] FW: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:36:12 -0000 This is to bring your attention to the following WGLC, in which your workin= g group may have some interest. Please send your comments to avtext@ietf.org If you are not a member of that list, then please still use that address, a= nd we will release it from the moderator queue when we receive notification= . Regards Keith=20 -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Ke= ith) Sent: 14 November 2014 17:32 To: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t (As WG cochair)=20 This is to start a working group last call on draft-ietf-avtext-rtp-groupin= g-taxonomy-03. To cater for the end of the IETF meeting, and for various national holidays= , this working group last call will last three weeks. Therefore please comment on this document by Friday 5th December 2014. Please send comments to the working group list. It is helpful to give some assessment of the nature of your comment, as to = whether you regard it as editorial, minor technical, or a rather more major= flaw. Regards Keith -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 14 November 2014 12:05 To: i-d-announce@ietf.org Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Working = Group of the IETF. Title : A Taxonomy of Grouping Semantics and Mechanisms f= or Real-Time Transport Protocol (RTP) Sources Authors : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Pages : 42 Date : 2014-11-14 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxonomy-= 03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Nov 18 01:49:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7193D1A012D for ; Tue, 18 Nov 2014 01:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV_pjkPNQen4 for ; Tue, 18 Nov 2014 01:49:17 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBBE1A00DF for ; Tue, 18 Nov 2014 01:49:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2223B7C0456 for ; Tue, 18 Nov 2014 10:49:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v48CrBuVUxo for ; Tue, 18 Nov 2014 10:49:11 +0100 (CET) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id CC2787C0429 for ; Tue, 18 Nov 2014 10:49:11 +0100 (CET) Message-ID: <546B1615.8010701@alvestrand.no> Date: Tue, 18 Nov 2014 01:49:09 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000204050802020307030503" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aVQlXm4zibC1z4lV3rmSuH4VPrQ Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 09:49:21 -0000 This is a multi-part message in MIME format. --------------000204050802020307030503 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/13/2014 12:46 PM, Justin Uberti wrote: > I think that makes the framing very clear; it is unfortunate that it > is coupled to ICE, but we can fix that by revving 4571. > > On the topic of naming, RFC 4572 > makes the meaning of TCP/TLS clear; it's (non-D) TLS. > > However, TCP transport for media isn't guaranteed to be reliable, as > explained in 4571, Section 3 > : > > The reliable nature of a connection does not imply that a framed > RTP stream has a contiguous sequence number ordering. For > example, if the connection is used to tunnel a UDP stream through > a network middlebox that only passes TCP, the sequence numbers in > the framed stream reflect any packet loss or reordering on the UDP > portion of the end-to-end flow. > > This necessarily implies that we want to use DTLS whenever the layer 4 > transport is TCP. > > We could try to be explicit about this by making the identifiers > TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some > inconsistency with RFC5763, which indicates use of DTLS via > UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since > you would only want to run DTLS over UDP). > > So I think we have two options: > a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the > definitions of these that DTLS is to be used here. > b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight > inconsistency with the UDP variants from 5763. > > Personally, I prefer b) as being less error-prone. I prefer b) as being more explicit. The RFC 5763 decision to use TLS as the name for DTLS was unfortunate, and we shouldn't keep on doing it if we don't have to. > > Lastly, for SCTP transport over DTLS over UDP, I think we should use > UDP/TLS/SCTP for consistency with 5763. In this case, I guess we have to.... > > > On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox > wrote: > > Here’s the citation from RFC 6544 for DTLS over RFC 4571 framing over TCP. > > 3. Overview of Operation > > [...] > > ICE requires an agent to demultiplex STUN and application-layer > traffic, since they appear on the same port. This demultiplexing is > described in [RFC5245 ] and is done using the magic cookie and other > fields of the message. Stream-oriented transports introduce another > wrinkle, since they require a way to frame the connection so that the > application and STUN packets can be extracted in order to > differentiate STUN packets from application-layer traffic. For this > reason, TCP media streams utilizing ICE use the basic framing > provided in RFC 4571 [RFC4571 ], even if the application layer > protocol is not RTP. > > When Transport Layer Security (TLS) or Datagram Transport Layer > Security (DTLS) is used, they are also run over the RFC 4571 framing > shim, while STUN runs outside of the (D)TLS connection. The > resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on > the left side and without it on the right side. > > +----------+ > | | > | App | > +----------+----------+ +----------+----------+ > | | | | | | > | STUN | (D)TLS | | STUN | App | > +----------+----------+ +----------+----------+ > | | | | > | RFC 4571 | | RFC 4571 | > +---------------------+ +---------------------+ > | | | | > | TCP | | TCP | > +---------------------+ +---------------------+ > | | | | > | IP | | IP | > +---------------------+ +---------------------+ > > Figure 1: ICE TCP Stack with and without (D)TLS > > > > > _______________________________________________ > 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 -- Surveillance is pervasive. Go Dark. --------------000204050802020307030503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/13/2014 12:46 PM, Justin Uberti wrote:
I think that makes the framing very clear; it is unfortunate that it is coupled to ICE, but we can fix that by revving 4571.

On the topic of naming, RFC 4572 makes the meaning of TCP/TLS clear; it's (non-D) TLS. 

However, TCP transport for media isn't guaranteed to be reliable, as explained in 4571, Section 3:

      The reliable nature of a connection does not imply that a framed
      RTP stream has a contiguous sequence number ordering.  For
      example, if the connection is used to tunnel a UDP stream through
      a network middlebox that only passes TCP, the sequence numbers in
      the framed stream reflect any packet loss or reordering on the UDP
      portion of the end-to-end flow.

This necessarily implies that we want to use DTLS whenever the layer 4 transport is TCP.

We could try to be explicit about this by making the identifiers TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some inconsistency with RFC5763, which indicates use of DTLS via UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since you would only want to run DTLS over UDP). 

So I think we have two options:
a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the definitions of these that DTLS is to be used here.
b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight inconsistency with the UDP variants from 5763.

Personally, I prefer b) as being less error-prone.

I prefer b) as being more explicit. The RFC 5763 decision to use TLS as the name for DTLS was unfortunate, and we shouldn't keep on doing it if we don't have to.


Lastly, for SCTP transport over DTLS over UDP, I think we should use UDP/TLS/SCTP for consistency with 5763.

In this case, I guess we have to....



On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
Here’s the citation from RFC 6544 for DTLS over RFC 4571 framing over TCP. 
3.  Overview of Operation
   [...]
   ICE requires an agent to demultiplex STUN and application-layer
   traffic, since they appear on the same port.  This demultiplexing is
   described in [RFC5245] and is done using the magic cookie and other
   fields of the message.  Stream-oriented transports introduce another
   wrinkle, since they require a way to frame the connection so that the
   application and STUN packets can be extracted in order to
   differentiate STUN packets from application-layer traffic.  For this
   reason, TCP media streams utilizing ICE use the basic framing
   provided in RFC 4571 [RFC4571], even if the application layer
   protocol is not RTP.

   When Transport Layer Security (TLS) or Datagram Transport Layer
   Security (DTLS) is used, they are also run over the RFC 4571 framing
   shim, while STUN runs outside of the (D)TLS connection.  The
   resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on
   the left side and without it on the right side.

                       +----------+
                       |          |
                       |    App   |
            +----------+----------+     +----------+----------+
            |          |          |     |          |          |
            |   STUN   |  (D)TLS  |     |   STUN   |    App   |
            +----------+----------+     +----------+----------+
            |                     |     |                     |
            |      RFC 4571       |     |      RFC 4571       |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         TCP         |     |         TCP         |
            +---------------------+     +---------------------+
            |                     |     |                     |
            |         IP          |     |         IP          |
            +---------------------+     +---------------------+

              Figure 1: ICE TCP Stack with and without (D)TLS


_______________________________________________
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



-- 
Surveillance is pervasive. Go Dark.
--------------000204050802020307030503-- From nobody Tue Nov 18 07:13:12 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142291A19F2 for ; Tue, 18 Nov 2014 07:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaif9by3mbqo for ; Tue, 18 Nov 2014 07:13:03 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2CA1A19EF for ; Tue, 18 Nov 2014 07:13:02 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 5EECD370B9774; Tue, 18 Nov 2014 15:12:56 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sAIFCouh016002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Nov 2014 10:12:57 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 18 Nov 2014 10:12:53 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP Thread-Index: AQHQAxTzsllRJVy8f0OE9GUS8Yz5CpxmRoIw Date: Tue, 18 Nov 2014 15:12:52 +0000 Message-ID: References: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> <546B1615.8010701@alvestrand.no> In-Reply-To: <546B1615.8010701@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E62AA90US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jW7UzqRl5qH8msilZUNoUnH7Rmc Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 15:13:08 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E62AA90US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for option b. IMO, use of "D" in "TCP/DTLS/RTP/SAVPF" can also be justified because of th= e use of RFC 4571 for framing to make TCP transport as "datagram transport"= (which also allows multiplexing of STUN). BR Raju From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: Tuesday, November 18, 2014 3:49 AM To: mmusic@ietf.org Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP On 11/13/2014 12:46 PM, Justin Uberti wrote: I think that makes the framing very clear; it is unfortunate that it is cou= pled to ICE, but we can fix that by revving 4571. On the topic of naming, RFC 4572 makes= the meaning of TCP/TLS clear; it's (non-D) TLS. However, TCP transport for media isn't guaranteed to be reliable, as explai= ned in 4571, Section 3: The reliable nature of a connection does not imply that a framed RTP stream has a contiguous sequence number ordering. For example, if the connection is used to tunnel a UDP stream through a network middlebox that only passes TCP, the sequence numbers in the framed stream reflect any packet loss or reordering on the UDP portion of the end-to-end flow. This necessarily implies that we want to use DTLS whenever the layer 4 tran= sport is TCP. We could try to be explicit about this by making the identifiers TCP/DTLS/R= TP/SAVPF and TCP/DTLS/SCTP, but this introduces some inconsistency with RFC= 5763, which indicates use of DTLS via UDP/TLS/RTP/SAVPF. (In the context of= UDP, this is unambiguous, since you would only want to run DTLS over UDP). So I think we have two options: a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the definit= ions of these that DTLS is to be used here. b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight incon= sistency with the UDP variants from 5763. Personally, I prefer b) as being less error-prone. I prefer b) as being more explicit. The RFC 5763 decision to use TLS as the= name for DTLS was unfortunate, and we shouldn't keep on doing it if we don= 't have to. Lastly, for SCTP transport over DTLS over UDP, I think we should use UDP/TL= S/SCTP for consistency with 5763. In this case, I guess we have to.... On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox > wrote: Here's the citation from RFC 6544 for DTLS over RFC 4571 framing over TCP. 3. Overview of Operation [...] ICE requires an agent to demultiplex STUN and application-layer traffic, since they appear on the same port. This demultiplexing is described in [RFC5245] and is done = using the magic cookie and other fields of the message. Stream-oriented transports introduce another wrinkle, since they require a way to frame the connection so that the application and STUN packets can be extracted in order to differentiate STUN packets from application-layer traffic. For this reason, TCP media streams utilizing ICE use the basic framing provided in RFC 4571 [RFC4571], even if the application layer protocol is not RTP. When Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) is used, they are also run over the RFC 4571 framing shim, while STUN runs outside of the (D)TLS connection. The resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on the left side and without it on the right side. +----------+ | | | App | +----------+----------+ +----------+----------+ | | | | | | | STUN | (D)TLS | | STUN | App | +----------+----------+ +----------+----------+ | | | | | RFC 4571 | = | RFC 4571 | +---------------------+ +---------------------+ | | | | | TCP | | TCP | +---------------------+ +---------------------+ | | | | | IP | | IP | +---------------------+ +---------------------+ Figure 1: ICE TCP Stack with and without (D)TLS _______________________________________________ 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 -- Surveillance is pervasive. Go Dark. --_000_E1FE4C082A89A246A11D7F32A95A17828E62AA90US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for option b.=

IMO, use of “D̶= 1; in “TCP/DTLS/RTP/SAVPF” can also be justified because of the= use of RFC 4571 for framing to make TCP transport as “datagram trans= port” (which also allows multiplexing of STUN).

 <= /p>

BR

Raju

 <= /p>

 <= /p>

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Tuesday, November 18, 2014 3:49 AM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP=

 

On 11/13/2014 12:46 PM, Justin Uberti wrote:

I think that makes the framing very clear; it is unf= ortunate that it is coupled to ICE, but we can fix that by revving 4571.

 

On the topic of naming, RFC 4572 makes the meaning of TCP/TLS clear; it's (non-D) TLS. 

 

However, TCP transport for media isn't guaranteed to= be reliable, as explained in 4571, Section 3:

 

      The re=
liable nature of a connection does not imply that a framed
      RTP st=
ream has a contiguous sequence number ordering.  For=

      exampl=
e, if the connection is used to tunnel a UDP stream through
      a netw=
ork middlebox that only passes TCP, the sequence numbers in
      the fr=
amed stream reflect any packet loss or reordering on the UDP
      portio=
n of the end-to-end flow.

 

This necessarily implies that we want to use DTLS wh= enever the layer 4 transport is TCP.

 

We could try to be explicit about this by making the= identifiers TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some= inconsistency with RFC5763, which indicates use of DTLS via UDP/TLS/RTP/SA= VPF. (In the context of UDP, this is unambiguous, since you would only want to run DTLS over UDP). 

 

So I think we have two options:

a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make = it clear in the definitions of these that DTLS is to be used here.

b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and liv= e with the slight inconsistency with the UDP variants from 5763.=

 

Personally, I prefer b) as being less error-prone.


I prefer b) as being more explicit. The RFC 5763 decision to use TLS as the= name for DTLS was unfortunate, and we shouldn't keep on doing it if we don= 't have to.


 

Lastly, for SCTP transport over DTLS over UDP, I thi= nk we should use UDP/TLS/SCTP for consistency with 5763.


In this case, I guess we have to....


 

 

On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox &l= t;jonathan@vidyo.co= m> wrote:

Here’s the citation from RFC 6544 for DTLS over RFC 4571 framing=
 over TCP. 
3.  Overview of Operation
   [...]
   ICE requires an agent to demultiplex STUN and application=
-layer
   traffic, since they appear on the same port.  This d=
emultiplexing is
   described in [RFC5245] and is done using the magic cookie a=
nd other
   fields of the message.  Stream-oriented transports i=
ntroduce another
   wrinkle, since they require a way to frame the connection=
 so that the
   application and STUN packets can be extracted in order to=

   differentiate STUN packets from application-layer traffic=
.  For this
   reason, TCP media streams utilizing ICE use the basic fra=
ming
   provided in RFC 4571 [RFC4571], even if the application layer

   protocol is not RTP.


 


   When Transport Layer Security (TLS) or Datagram Transport=
 Layer


   Security (DTLS) is used, they are also run over the RFC 4571 f=
raming


   shim, while STUN runs outside of the (D)TLS connection.&n=
bsp; The


   resulting ICE TCP protocol stack is shown in Figure 1, wi=
th (D)TLS on


   the left side and without it on the right side.


 


           &nbs=
p;           +-------=
---+


           &nbs=
p;           |  =
;        |


           &nbs=
p;           |  =
;  App   |


            =
3;----------+----------+     +----------=
3;----------+


            |&n=
bsp;         |   &nb=
sp;      |     |  &n=
bsp;       |     &nb=
sp;    |


            |&n=
bsp;  STUN   |  (D)TLS  |     =
|   STUN   |    App   |


            =
3;----------+----------+     +----------=
3;----------+


            |&n=
bsp;            =
;        |     |&nbs=
p;            &=
nbsp;       |


            |&n=
bsp;     RFC 4571       | =
;    |      RFC 4571   &n=
bsp;   |


            =
3;---------------------+     +-----------------=
----+


            |&n=
bsp;            =
;        |     |&nbs=
p;            &=
nbsp;       |


            |&n=
bsp;        TCP    &=
nbsp;    |     |    =
     TCP        =
; |


            =
3;---------------------+     +-----------------=
----+


            |&n=
bsp;            =
;        |     |&nbs=
p;            &=
nbsp;       |


            |&n=
bsp;        IP    &n=
bsp;     |     |   &=
nbsp;     IP       &=
nbsp;  |


            =
3;---------------------+     +-----------------=
----+


 


           &nbs=
p;  Figure 1: ICE TCP Stack with and without (D)TLS


 


 




 


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

 




_______________________________________________
mmusic mailing list
mmusic@ietf.org

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











-- 


Surveillance is pervasive. Go Dark.
--_000_E1FE4C082A89A246A11D7F32A95A17828E62AA90US70UWXCHMBA02z_-- From nobody Tue Nov 18 17:30:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E01ACE41 for ; Tue, 18 Nov 2014 17:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hftNKiUkEPiJ for ; Tue, 18 Nov 2014 17:30:01 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501D31ACE52 for ; Tue, 18 Nov 2014 17:30:01 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id id10so9196335vcb.30 for ; Tue, 18 Nov 2014 17:30:00 -0800 (PST) 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=eWDpf+MPTVXz46NIptVcGxDTtDnA/MUKgB6+NTat50A=; b=ZLsKfSMYlRT3jA4MPxrqwQxNfR1t7bgtXjCWHVG7FLhkuptyluIPYnxlXTrKJ8KVyQ fWyLBRRlVYz9TmiHdW8npMbrpUZLCgpHU3IOp/uuOU4/2i5E2pWr+9SffKjC7WhlZ9XQ 71ktSgGZVThAPebLjI3ac0MhWZUyEJdIaWTkADhY25vGR01U7ELk3Ak2fEBuhneXo6O+ kp79T4G02lgCrbbdLk4psCVG/oMHd5jlmSfV7CB8gmshLKx6S/SqYY2S81Dm+uktIS4p h/Sowvq3iOyoktMruzKUC2pW+a7hVZ4NXQ/oduObkrjHKVpWqcvI3Fsp8tA0JPFglJ5h a5iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eWDpf+MPTVXz46NIptVcGxDTtDnA/MUKgB6+NTat50A=; b=WWUeS+4zmrsTw1/PGdo8uYswxjsS5gf0UB730U/Dm+2tjIcYkwTR69TM9kxeFjMeub 3cD2gJbJuAntOPZQ2gunvd45rbcGOb1DmXH1tZuUAeD5YtDPhQ61m8P6hVCIKBaeDCyl 2POfQZFW1HhPe4q9pyffABBmmpFdMhAkMgPui1THhqKblWs4yNtsSS/LfyTGcQwrQoCs SaMPn9+adrLXqAuodtFRSvwiSpfWp9mqFs9Pd6G4mqEexC6PnFG66gHwo4JQzkygVdic 8Y950z4fqYv3atl7SxGR0LHBBCxN9GkA258allfh/XpDgUm5XF2yX4ngDCIbxB8C6jGk mGcw== X-Gm-Message-State: ALoCoQkAM6n+6foChcb3ousUvsxZ22tbUW5rIUEp4jIjUDBWOo0kIkvaPw15zGPV+/Snbo0sriqv X-Received: by 10.220.139.147 with SMTP id e19mr103013vcu.27.1416360600323; Tue, 18 Nov 2014 17:30:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Tue, 18 Nov 2014 17:29:40 -0800 (PST) In-Reply-To: References: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> <546B1615.8010701@alvestrand.no> From: Justin Uberti Date: Tue, 18 Nov 2014 17:29:40 -0800 Message-ID: To: "Makaraju, Maridi Raju (Raju)" , Suhas Nandakumar Content-Type: multipart/alternative; boundary=047d7b34332674f40c05082c260c Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/h0D5J0eYoVrhl1rF4GmplhCi6JM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 01:30:05 -0000 --047d7b34332674f40c05082c260c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +Suhas Suhas, thoughts? On Tue, Nov 18, 2014 at 7:12 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > +1 for option b. > > IMO, use of =E2=80=9CD=E2=80=9D in =E2=80=9CTCP/DTLS/RTP/SAVPF=E2=80=9D c= an also be justified because of > the use of RFC 4571 for framing to make TCP transport as =E2=80=9Cdatagra= m > transport=E2=80=9D (which also allows multiplexing of STUN). > > > > BR > > Raju > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Harald > Alvestrand > *Sent:* Tuesday, November 18, 2014 3:49 AM > *To:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP > > > > On 11/13/2014 12:46 PM, Justin Uberti wrote: > > I think that makes the framing very clear; it is unfortunate that it is > coupled to ICE, but we can fix that by revving 4571. > > > > On the topic of naming, RFC 4572 > makes the meaning of TCP/TLS clear; it's (non-D) TLS. > > > > However, TCP transport for media isn't guaranteed to be reliable, as > explained in 4571, Section 3 > : > > > > The reliable nature of a connection does not imply that a framed > > RTP stream has a contiguous sequence number ordering. For > > example, if the connection is used to tunnel a UDP stream through > > a network middlebox that only passes TCP, the sequence numbers in > > the framed stream reflect any packet loss or reordering on the UDP > > portion of the end-to-end flow. > > > > This necessarily implies that we want to use DTLS whenever the layer 4 > transport is TCP. > > > > We could try to be explicit about this by making the identifiers > TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some > inconsistency with RFC5763, which indicates use of DTLS via > UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since you > would only want to run DTLS over UDP). > > > > So I think we have two options: > > a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the > definitions of these that DTLS is to be used here. > > b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight > inconsistency with the UDP variants from 5763. > > > > Personally, I prefer b) as being less error-prone. > > > I prefer b) as being more explicit. The RFC 5763 decision to use TLS as > the name for DTLS was unfortunate, and we shouldn't keep on doing it if w= e > don't have to. > > > > > Lastly, for SCTP transport over DTLS over UDP, I think we should use > UDP/TLS/SCTP for consistency with 5763. > > > In this case, I guess we have to.... > > > > > > > On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox > wrote: > > Here=E2=80=99s the citation from RFC 6544 for DTLS over RFC 4571 framing = over TCP. > > 3. Overview of Operation > > [...] > > ICE requires an agent to demultiplex STUN and application-layer > > traffic, since they appear on the same port. This demultiplexing is > > described in [RFC5245 ] and is do= ne using the magic cookie and other > > fields of the message. Stream-oriented transports introduce another > > wrinkle, since they require a way to frame the connection so that the > > application and STUN packets can be extracted in order to > > differentiate STUN packets from application-layer traffic. For this > > reason, TCP media streams utilizing ICE use the basic framing > > provided in RFC 4571 [RFC4571 ], even if the application layer > > protocol is not RTP. > > > > When Transport Layer Security (TLS) or Datagram Transport Layer > > Security (DTLS) is used, they are also run over the RFC 4571 framing > > shim, while STUN runs outside of the (D)TLS connection. The > > resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on > > the left side and without it on the right side. > > > > +----------+ > > | | > > | App | > > +----------+----------+ +----------+----------+ > > | | | | | | > > | STUN | (D)TLS | | STUN | App | > > +----------+----------+ +----------+----------+ > > | | | | > > | RFC 4571 |= | RFC 4571 | > > +---------------------+ +---------------------+ > > | | | | > > | TCP | | TCP | > > +---------------------+ +---------------------+ > > | | | | > > | IP | | IP | > > +---------------------+ +---------------------+ > > > > Figure 1: ICE TCP Stack with and without (D)TLS > > > > > > > > > _______________________________________________ > 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 > > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --047d7b34332674f40c05082c260c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+Suhas

Suhas, thoughts?

On Tue, Nov 18, 2014 = at 7:12 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alc= atel-lucent.com> wrote:

+1 for option b.

IMO, use of =E2=80=9CD=E2= =80=9D in =E2=80=9CTCP/DTLS/RTP/SAVPF=E2=80=9D can also be justified becaus= e of the use of RFC 4571 for framing to make TCP transport as =E2=80=9Cdata= gram transport=E2=80=9D (which also allows multiplexing of STUN).

=C2=A0

BR

Raju=

=C2=A0

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Tuesday, November 18, 2014 3:49 AM
To: mmusic@ietf= .org
Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP

=C2=A0

On 11/13/2014 12:46 PM, Justin Uberti wrote:<= u>

I think that makes the framing very clear; it is unf= ortunate that it is coupled to ICE, but we can fix that by revving 4571.

=C2=A0

On the topic of naming, RFC 4572 makes the meaning of TCP/TLS clear; it's (non-D) TLS.=C2= =A0

=C2=A0

However, TCP transport for media isn't guarantee= d to be reliable, as explained in 4571, Section 3:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The re=
liable nature of a connection does not imply that a framed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RTP st=
ream has a contiguous sequence number ordering.=C2=A0 For
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exampl=
e, if the connection is used to tunnel a UDP stream through
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a netw=
ork middlebox that only passes TCP, the sequence numbers in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the fr=
amed stream reflect any packet loss or reordering on the UDP<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 portio=
n of the end-to-end flow.

=C2=A0

This necessarily implies that we want to use DTLS wh= enever the layer 4 transport is TCP.

=C2=A0

We could try to be explicit about this by making the= identifiers TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some= inconsistency with RFC5763, which indicates use of DTLS via UDP/TLS/RTP/SA= VPF. (In the context of UDP, this is unambiguous, since you would only want to run DTLS over UDP).=C2=A0<= /u>

=C2=A0

So I think we have two options:

a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make = it clear in the definitions of these that DTLS is to be used here.

b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and liv= e with the slight inconsistency with the UDP variants from 5763.<= /u>

=C2=A0

Personally, I prefer b) as being less error-prone.


I prefer b) as being more explicit. The RFC 5763 decision to use TLS as the= name for DTLS was unfortunate, and we shouldn't keep on doing it if we= don't have to.


=C2=A0

Lastly, for SCTP transport over DTLS over UDP, I thi= nk we should use UDP/TLS/SCTP for consistency with 5763.


In this case, I guess we have to....


=C2=A0

=C2=A0

On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox &l= t;jonathan@vidyo.co= m> wrote:

Here=E2=80=99s the citation from RFC 6544 for DTLS over RFC 4571 frami=
ng over TCP. 
3.=C2=A0 Overview of Operation
=C2=A0=C2=A0 [...]
=C2=A0=C2=A0 ICE requires an agent to demultiplex STUN and application=
-layer
=C2=A0=C2=A0 traffic, since they appear on the same port.=C2=A0 This d=
emultiplexing is
=C2=A0 =C2=A0described in [RFC5245] and is done using the magic cookie a=
nd other
=C2=A0=C2=A0 fields of the message.=C2=A0 Stream-oriented transports i=
ntroduce another
=C2=A0=C2=A0 wrinkle, since they require a way to frame the connection=
 so that the
=C2=A0=C2=A0 application and STUN packets can be extracted in order to=

=C2=A0=C2=A0 differentiate STUN packets from application-layer traffic=
.=C2=A0 For this
=C2=A0=C2=A0 reason, TCP media streams utilizing ICE use the basic fra=
ming
=C2=A0=C2=A0 provided in RFC 4571 [RFC4571], even if the application layer<=
/pre>

=C2=A0=C2=A0 protocol is not RTP.


=C2=A0


=C2=A0=C2=A0 When Transport Layer Security (TLS) or Datagram Transport=
 Layer


=C2=A0=C2=A0 Security (DTLS) is used, they are also run over the RFC 4571 f=
raming


=C2=A0=C2=A0 shim, while STUN runs outside of the (D)TLS connection.=
=C2=A0 The


=C2=A0=C2=A0 resulting ICE TCP protocol stack is shown in Figure 1, wi=
th (D)TLS on


=C2=A0=C2=A0 the left side and without it on the right side.=



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +----------=
+


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0 App=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
--------+----------+=C2=A0=C2=A0=C2=A0=C2=A0 +----------+----------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0 STUN=C2=A0=C2=A0 |=C2=A0 (D)TLS=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0 STUN=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 App=C2=A0=C2=A0 |=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
--------+----------+=C2=A0=C2=A0=C2=A0=C2=A0 +----------+----------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0RFC 4571=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0RFC 4571=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
-------------------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------------------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
-------------------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------------------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IP=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
-------------------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------------------+=



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 Figure 1: ICE TCP Stack with and without (D)TLS

=C2=A0


=C2=A0




=C2=A0


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

=C2=A0




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




-- 
Surveillance is pervasive. Go Dark.

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


--047d7b34332674f40c05082c260c-- From nobody Tue Nov 18 21:35:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73DE1ACF82 for ; Tue, 18 Nov 2014 21:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBRTM1OR0O3D for ; Tue, 18 Nov 2014 21:35:41 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4F41ACF67 for ; Tue, 18 Nov 2014 21:35:41 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id et14so11363740pad.31 for ; Tue, 18 Nov 2014 21:35:39 -0800 (PST) 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=rS+eq9PDe+/lMgaoURO7Q8Uu7kXjoWbiftNCH8oNBi4=; b=tB7PWDIrQ+6Im6NoP1/KQb8Vb5bgcXz8GsJK7/T9UiEBOAlcj0VRXgEqRWSbPRPmZO 6s894vrZDzRrmwlTjqLGDp5blASQzLkHtLDgrKdHz5fhHwO9w5oXtee/JJcinAQPQJ47 wuzx60c2oBN7OPXrY9ISm0ADrATVreDy/hIEVBTUUtxIEnof5DAqBV5aAmgEa9MD6y8v HtUQFcX+fPGH/M5DRo3wY4eXgDpnTnwc97PC5adREs6IbgEi3LfjNrDQFstx7rVA1kOy 6+MirFZV+cOpVVD1Lc6BkjzhRhZcfwvA5WVad4e4fffWrU+5BQ+6Z+f0ojHg7o3aZoGm YeHA== MIME-Version: 1.0 X-Received: by 10.68.206.98 with SMTP id ln2mr42605441pbc.83.1416375339417; Tue, 18 Nov 2014 21:35:39 -0800 (PST) Received: by 10.70.60.201 with HTTP; Tue, 18 Nov 2014 21:35:39 -0800 (PST) In-Reply-To: References: <44035890-A516-4D01-A679-A85032AA10ED@vidyo.com> <546B1615.8010701@alvestrand.no> Date: Tue, 18 Nov 2014 21:35:39 -0800 Message-ID: From: Suhas Nandakumar To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0160b784f985d805082f94ac Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9dheV6aBuUr93xo2C7JfE--wKZI Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 05:35:45 -0000 --089e0160b784f985d805082f94ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Option b looks good to me as well. I can update the draft to capture this. Also I was wondering if in JSEP or somewhere , we need to capture the fact that we will never be sending RTP media over RFC5246 TLS Connections framed using RFC4571 framing for TCP. Thanks Suhas On Tue, Nov 18, 2014 at 5:29 PM, Justin Uberti wrote: > +Suhas > > Suhas, thoughts? > > On Tue, Nov 18, 2014 at 7:12 AM, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > >> +1 for option b. >> >> IMO, use of =E2=80=9CD=E2=80=9D in =E2=80=9CTCP/DTLS/RTP/SAVPF=E2=80=9D = can also be justified because of >> the use of RFC 4571 for framing to make TCP transport as =E2=80=9Cdatagr= am >> transport=E2=80=9D (which also allows multiplexing of STUN). >> >> >> >> BR >> >> Raju >> >> >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Harald >> Alvestrand >> *Sent:* Tuesday, November 18, 2014 3:49 AM >> *To:* mmusic@ietf.org >> *Subject:* Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP >> >> >> >> On 11/13/2014 12:46 PM, Justin Uberti wrote: >> >> I think that makes the framing very clear; it is unfortunate that it is >> coupled to ICE, but we can fix that by revving 4571. >> >> >> >> On the topic of naming, RFC 4572 >> makes the meaning of TCP/TLS clear; it's (non-D) TLS. >> >> >> >> However, TCP transport for media isn't guaranteed to be reliable, as >> explained in 4571, Section 3 >> : >> >> >> >> The reliable nature of a connection does not imply that a framed >> >> RTP stream has a contiguous sequence number ordering. For >> >> example, if the connection is used to tunnel a UDP stream through >> >> a network middlebox that only passes TCP, the sequence numbers in >> >> the framed stream reflect any packet loss or reordering on the UDP >> >> portion of the end-to-end flow. >> >> >> >> This necessarily implies that we want to use DTLS whenever the layer 4 >> transport is TCP. >> >> >> >> We could try to be explicit about this by making the identifiers >> TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some >> inconsistency with RFC5763, which indicates use of DTLS via >> UDP/TLS/RTP/SAVPF. (In the context of UDP, this is unambiguous, since yo= u >> would only want to run DTLS over UDP). >> >> >> >> So I think we have two options: >> >> a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make it clear in the >> definitions of these that DTLS is to be used here. >> >> b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and live with the slight >> inconsistency with the UDP variants from 5763. >> >> >> >> Personally, I prefer b) as being less error-prone. >> >> >> I prefer b) as being more explicit. The RFC 5763 decision to use TLS as >> the name for DTLS was unfortunate, and we shouldn't keep on doing it if = we >> don't have to. >> >> >> >> >> Lastly, for SCTP transport over DTLS over UDP, I think we should use >> UDP/TLS/SCTP for consistency with 5763. >> >> >> In this case, I guess we have to.... >> >> >> >> >> >> >> On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox >> wrote: >> >> Here=E2=80=99s the citation from RFC 6544 for DTLS over RFC 4571 framing= over TCP. >> >> 3. Overview of Operation >> >> [...] >> >> ICE requires an agent to demultiplex STUN and application-layer >> >> traffic, since they appear on the same port. This demultiplexing is >> >> described in [RFC5245 ] and is d= one using the magic cookie and other >> >> fields of the message. Stream-oriented transports introduce another >> >> wrinkle, since they require a way to frame the connection so that the >> >> application and STUN packets can be extracted in order to >> >> differentiate STUN packets from application-layer traffic. For this >> >> reason, TCP media streams utilizing ICE use the basic framing >> >> provided in RFC 4571 [RFC4571 <= https://tools.ietf.org/html/rfc4571>], even if the application layer >> >> protocol is not RTP. >> >> >> >> When Transport Layer Security (TLS) or Datagram Transport Layer >> >> Security (DTLS) is used, they are also run over the RFC 4571 framing >> >> shim, while STUN runs outside of the (D)TLS connection. The >> >> resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on >> >> the left side and without it on the right side. >> >> >> >> +----------+ >> >> | | >> >> | App | >> >> +----------+----------+ +----------+----------+ >> >> | | | | | | >> >> | STUN | (D)TLS | | STUN | App | >> >> +----------+----------+ +----------+----------+ >> >> | | | | >> >> | RFC 4571 = | | RFC 4571 | >> >> +---------------------+ +---------------------+ >> >> | | | | >> >> | TCP | | TCP | >> >> +---------------------+ +---------------------+ >> >> | | | | >> >> | IP | | IP | >> >> +---------------------+ +---------------------+ >> >> >> >> Figure 1: ICE TCP Stack with and without (D)TLS >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> -- >> >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --089e0160b784f985d805082f94ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Option b looks good to me as well. I can update the draft = to capture this.


Also I was wondering if in JSE= P or somewhere , we need to capture the fact that we will never be sending = RTP media over RFC5246 TLS Connections framed using RFC4571 framing for TCP= .


Thanks
Suhas

On Tue, No= v 18, 2014 at 5:29 PM, Justin Uberti <juberti@google.com> w= rote:
+Suhas

Suhas, thoughts?

On Tue, Nov 18, = 2014 at 7:12 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraj= u@alcatel-lucent.com> wrote:

+1 for option b.

IMO, use of =E2=80=9CD=E2= =80=9D in =E2=80=9CTCP/DTLS/RTP/SAVPF=E2=80=9D can also be justified becaus= e of the use of RFC 4571 for framing to make TCP transport as =E2=80=9Cdata= gram transport=E2=80=9D (which also allows multiplexing of STUN).

=C2=A0

BR

Raju=

=C2=A0

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Tuesday, November 18, 2014 3:49 AM
To: mmusic@ietf= .org
Subject: Re: [MMUSIC] RFC 6544: DTLS over 4571 framing over TCP

=C2=A0

On 11/13/2014 12:46 PM, Justin Uberti wrote:<= u>

I think that makes the framing very clear; it is unf= ortunate that it is coupled to ICE, but we can fix that by revving 4571.

=C2=A0

On the topic of naming, RFC 4572 makes the meaning of TCP/TLS clear; it's (non-D) TLS.=C2= =A0

=C2=A0

However, TCP transport for media isn't guarantee= d to be reliable, as explained in 4571, Section 3:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The re=
liable nature of a connection does not imply that a framed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RTP st=
ream has a contiguous sequence number ordering.=C2=A0 For
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exampl=
e, if the connection is used to tunnel a UDP stream through
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a netw=
ork middlebox that only passes TCP, the sequence numbers in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the fr=
amed stream reflect any packet loss or reordering on the UDP<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 portio=
n of the end-to-end flow.

=C2=A0

This necessarily implies that we want to use DTLS wh= enever the layer 4 transport is TCP.

=C2=A0

We could try to be explicit about this by making the= identifiers TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, but this introduces some= inconsistency with RFC5763, which indicates use of DTLS via UDP/TLS/RTP/SA= VPF. (In the context of UDP, this is unambiguous, since you would only want to run DTLS over UDP).=C2=A0<= /u>

=C2=A0

So I think we have two options:

a) use TCP/TLS/RTP/SAVPF and TCP/TLS/SCTP, and make = it clear in the definitions of these that DTLS is to be used here.

b) use TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP, and liv= e with the slight inconsistency with the UDP variants from 5763.<= /u>

=C2=A0

Personally, I prefer b) as being less error-prone.


I prefer b) as being more explicit. The RFC 5763 decision to use TLS as the= name for DTLS was unfortunate, and we shouldn't keep on doing it if we= don't have to.


=C2=A0

Lastly, for SCTP transport over DTLS over UDP, I thi= nk we should use UDP/TLS/SCTP for consistency with 5763.


In this case, I guess we have to....


=C2=A0

=C2=A0

On Thu, Nov 13, 2014 at 11:32 AM, Jonathan Lennox &l= t;jonathan@vidyo.co= m> wrote:

Here=E2=80=99s the citation from RFC 6544 for DTLS over RFC 4571 frami=
ng over TCP. 
3.=C2=A0 Overview of Operation
=C2=A0=C2=A0 [...]
=C2=A0=C2=A0 ICE requires an agent to demultiplex STUN and application=
-layer
=C2=A0=C2=A0 traffic, since they appear on the same port.=C2=A0 This d=
emultiplexing is
=C2=A0 =C2=A0described in [RFC5245] and is done using the magic cookie a=
nd other
=C2=A0=C2=A0 fields of the message.=C2=A0 Stream-oriented transports i=
ntroduce another
=C2=A0=C2=A0 wrinkle, since they require a way to frame the connection=
 so that the
=C2=A0=C2=A0 application and STUN packets can be extracted in order to=

=C2=A0=C2=A0 differentiate STUN packets from application-layer traffic=
.=C2=A0 For this
=C2=A0=C2=A0 reason, TCP media streams utilizing ICE use the basic fra=
ming
=C2=A0=C2=A0 provided in RFC 4571 [RFC4571], even if the application layer<=
/pre>

=C2=A0=C2=A0 protocol is not RTP.


=C2=A0


=C2=A0=C2=A0 When Transport Layer Security (TLS) or Datagram Transport=
 Layer


=C2=A0=C2=A0 Security (DTLS) is used, they are also run over the RFC 4571 f=
raming


=C2=A0=C2=A0 shim, while STUN runs outside of the (D)TLS connection.=
=C2=A0 The


=C2=A0=C2=A0 resulting ICE TCP protocol stack is shown in Figure 1, wi=
th (D)TLS on


=C2=A0=C2=A0 the left side and without it on the right side.=



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +----------=
+


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0 App=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
--------+----------+=C2=A0=C2=A0=C2=A0=C2=A0 +----------+----------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0 STUN=C2=A0=C2=A0 |=C2=A0 (D)TLS=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0 STUN=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 App=C2=A0=C2=A0 |=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
--------+----------+=C2=A0=C2=A0=C2=A0=C2=A0 +----------+----------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0RFC 4571=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0RFC 4571=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
-------------------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------------------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
-------------------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------------------+=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IP=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--=
-------------------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------------------+=



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 Figure 1: ICE TCP Stack with and without (D)TLS

=C2=A0


=C2=A0




=C2=A0


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

=C2=A0




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




-- 
Surveillance is pervasive. Go Dark.

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



--089e0160b784f985d805082f94ac-- From nobody Fri Nov 21 11:17:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946621A01AE for ; Fri, 21 Nov 2014 11:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch2LCjvA6s3d for ; Fri, 21 Nov 2014 11:17:03 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67131A007E for ; Fri, 21 Nov 2014 11:17:02 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-bb-546f8face7ec Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.40.04231.CAF8F645; Fri, 21 Nov 2014 20:17:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 20:17:00 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHw== Date: Fri, 21 Nov 2014 19:16:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D52ED2EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6a/vwQg0OnFC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHcrJjEVXJevaJ7eyd7AeEy6i5GTQ0LAROLh29dsELaYxIV7 64FsLg4hgSOMEk2vLjNCOEsYJWau+MHaxcjBwSZgIdH9TxukQURAXeLr3h5mkLAwUHjpfQ+I sK3E9Cf7WCBsPYlzM24yg9gsAqoSP+/+AtvFK+ArMf3sFLAaRqC930+tYQKxmQXEJW49mc8E cY+AxJI955khbFGJl4//sULYShKNS56wQtTnSxz+uYcJYqagxMmZT1gmMArNQjJqFpKyWUjK IOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wIg4uOW37g7G1a8dDzEKcDAq8fBuWJUXIsSaWFZcmXuIUZqDRUmcd9G5ecFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGI1qDJ7Ms3jFVhubI5u8ophrF0N7cYD0ws0aG3qrguym28QKzExd 3q+64d+5Ccn/8xkubXNkvXRsCRuDpggLj7T7XIO5gi3iq7LnPZkq/ykuNK1SclP7hcKbgiea p2Xu1tcwsv6ackx/8g59lY55K9SPJNsG/j15oEp6scjhxGkeYduqyhznKrEUZyQaajEXFScC AKauc+xpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yEOF-NJLPn-LqeWp3QwZdJDOttk Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:17:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D52ED2EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that DCEP = will not be used to open data channels - instead data channels will be cons= idered open once the SDP O/A negotiation has finished and the SCTP associat= ion used to realize the data channel(s) has been created. My question is whether the intention is to forbid usage of DCEP together wi= th draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be optional= ? If optional, there needs to be a way to indicate that application data shal= l not be sent until a channel has been opened using DCEP. In addition, it w= ould be useful to be able to indicate which endpoint is responsible for sen= ding the DCEP_CHANNEL_OPEN message. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D52ED2EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

draft-ejzak-mmusic-data-channel-sdpneg currently see= ms to assume that DCEP will not be used to open data channels – inste= ad data channels will be considered open once the SDP O/A negotiation has f= inished and the SCTP association used to realize the data channel(s) has been created.

 

My question is whether the intention is to forbid us= age of DCEP together with draft-ejzak-mmusic-data-channel-sdpneg, or whethe= r it should be optional?

 

If optional, there needs to be a way to indicate tha= t application data shall not be sent until a channel has been opened using = DCEP. In addition, it would be useful to be able to indicate which endpoint= is responsible for sending the DCEP_CHANNEL_OPEN message.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D52ED2EESESSMB209erics_-- From nobody Tue Nov 25 00:33:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA161A0067 for ; Tue, 25 Nov 2014 00:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eqeiZapQ_rE for ; Tue, 25 Nov 2014 00:33:14 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F5B1A0053 for ; Tue, 25 Nov 2014 00:33:13 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-24-54743ec72c52 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.DF.24955.7CE34745; Tue, 25 Nov 2014 09:33:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 09:33:10 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzA== Date: Tue, 25 Nov 2014 08:33:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D534E7B@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.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D534E7BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvje5xu5IQg8b3mhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqPFSQUfDCoOfhZuYOzS6mLk5JAQMJE43r2PEcIWk7hwbz1b FyMXh5DAEUaJW1OOMEM4Sxglns1oYO9i5OBgE7CQ6P6nDdIgIqAu8XVvDzOILSygLXH3+F5G iLiBRP+a+4wg5SICehJtb0pAwiwCqhLXJr5jB7F5BXwllq89AGYzAu39fmoNE4jNLCAucevJ fCaIewQkluw5zwxhi0q8fPyPFWSkhICSxLStaRDl+RJN97cxQYwUlDg58wnLBEahWUgmzUJS NgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eX WrKJERgLB7f8Vt3BePmN4yFGAQ5GJR7eDR+KQ4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUAyP73U+vrnbKpUWKCbKp/J/62nbrGb80nldhR19vD6h8Gqhl OPfI9dar9cu10iMs1/3dN4e728Yi+bvo4n1PX10/13jnWqfTEiWrsDdX3lsoS9qLBz1NyZ+4 vNB9X4VeXbSd7xk1u+36ZgKTA/RuprFMOyK6zLHQzavzDd/0HQ7bVHPuP57XfEuJpTgj0VCL uag4EQCYSZp7ZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VKSVvoGTB9ZMJyHnrXqlVyf97q8 Subject: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:33:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D534E7BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Hopefully there are some SCTP experts in da hause that can clarify the foll= owing: Previously, in the SCTP-SDP discussions, we have agreed that for a given SC= TP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g.= a webrtc-datachannel). So, if one wants multiple usages, one needs to establish multiple associati= ons, using multiple m- lines. BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one = SCTP association between them at any given time. Not exactly sure why, but = that is what the text says... "SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state infor= mation including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association = can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT = have more than one SCTP association between them at any given ti= me." Now, does that mean that, for a given SDP session, we can only have a singl= e SCTP m- line (read: single SCTP usage)? For WebRTC usage that is probably enough, as we use SCTP only for the data = channel, but in general... Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D534E7BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Hopefully there are some SCTP experts in da hause th= at can clarify the following:

 

Previously, in the SCTP-SDP discussions, we have agr= eed that for a given SCTP/SCTPoDTLS/DTLSoSCTP association, we will only all= ow a single usage (e.g. a webrtc-datachannel).

 

So, if one wants multiple usages, one needs to estab= lish multiple associations, using multiple m- lines.

 

BUT, according to RFC 4960, two SCTP endpoints MUST = NOT have more than one SCTP association between them at any given time. Not= exactly sure why, but that is what the text says…

 

“SCTP association= : A protocol relationship between SCTP endpoints,

         &nb= sp;      composed of the two SCTP endpoints and pr= otocol state information

         &nb= sp;      including Verification Tags and the curre= ntly active set of

         &nb= sp;      Transmission Sequence Numbers (TSNs), etc= .  An association can be

         &nb= sp;      uniquely identified by the transport addr= esses used by the

         &nb= sp;      endpoints in the association.  Tw= o SCTP endpoints MUST NOT have

         =        more than one SCTP association between= them at any given time.”

 

Now, does that mean that, for a given SDP session, w= e can only have a single SCTP m- line (read: single SCTP usage)?=

 

For WebRTC usage that is probably enough, as we use = SCTP only for the data channel, but in general…

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D534E7BESESSMB209erics_-- From nobody Tue Nov 25 04:19:01 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCA01A0111 for ; Tue, 25 Nov 2014 04:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3qCpQXOHWLz for ; Tue, 25 Nov 2014 04:18:55 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279001A0102 for ; Tue, 25 Nov 2014 04:18:55 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 47176903F962E; Tue, 25 Nov 2014 12:18:49 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sAPCIoSa004681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 07:18:50 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 07:18:51 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqg Date: Tue, 25 Nov 2014 12:18:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E63BC0FUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2uQiVna2f6vj-qJhGj19MsFK7o8 Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:18:59 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E63BC0FUS70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Hopefully there are some SCTP experts in da hause that can clarify the foll= owing: Previously, in the SCTP-SDP discussions, we have agreed that for a given SC= TP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g.= a webrtc-datachannel). So, if one wants multiple usages, one needs to establish multiple associati= ons, using multiple m- lines. BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one = SCTP association between them at any given time. Not exactly sure why, but = that is what the text says... An SCTP association is identified by 4-tuple: src ip, src port, dst = ip, dst port (they form 2 Endpoints). To have a new SCTP association you ne= ed to change one parameter in the 4-tuple and most of the times local ip of= the client is changed (if app does not specify a port then OS selects a lo= cal port). So, between same 2 hosts more than one SCTP associations are all= owed. Per "TCP-Based Media Transport in the Session Description Protocol (SDP) "R= FC 4145 (section 4.1), the port conveyed in m=3D line is server port when a= =3Dsetup:actpass or passive is used. For a=3Dsetup:active, port 9 (discard)= should be used (as the client port may not be known until TCP conn is init= iated). I do not see similar semantics in http://www.ietf.org/id/draft-ietf-mmusic-= sctp-sdp-07.txt . These semantics are needed in this draft as well for nati= ve SCTP usage as well as SCTP over DTLS. BR Raju "SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state infor= mation including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association = can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT = have more than one SCTP association between them at any given ti= me." Now, does that mean that, for a given SDP session, we can only have a singl= e SCTP m- line (read: single SCTP usage)? For WebRTC usage that is probably enough, as we use SCTP only for the data = channel, but in general... Regards, Christer --_000_E1FE4C082A89A246A11D7F32A95A17828E63BC0FUS70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

   &nbs= p;          =

Hi,

 

Hopefully there are some SCTP experts in da hause th= at can clarify the following:

 

Previously, in the SCTP-SDP discussions, we have agr= eed that for a given SCTP/SCTPoDTLS/DTLSoSCTP association, we will only all= ow a single usage (e.g. a webrtc-datachannel).

 

So, if one wants multiple usages, one needs to estab= lish multiple associations, using multiple m- lines.

 

BUT, according to RFC 4960, two SCTP endpoints MUST = NOT have more than one SCTP association between them at any given time. Not= exactly sure why, but that is what the text says…

<Raju> An SCTP association is identified by 4-tu=
ple: src ip, src port, dst ip, dst port (they form 2 Endpoints). To have a =
new SCTP association you need to change one parameter in the 4-tuple and mo=
st of the times local ip of the client is changed (if app does not specify =
a port then OS selects a local port). So, between same 2 hosts more than on=
e SCTP associations are allowed.
 <=
/i>
Per “TCP-Based Media Transport in the Session De=
scription Protocol (SDP) “RFC 4145 (section 4.1), the port conveyed i=
n m=3D line is server port when a=3Dsetup:actpass or passive is used. For a=
=3Dsetup:active, port 9 (discard) should be used (as the client port may no=
t be known until TCP conn is initiated).

I do not see sim= ilar semantics in http:/= /www.ietf.org/id/draft-ietf-mmusic-sctp-sdp-07.txt . These semantics ar= e needed in this draft as well for native SCTP usage as well as SCTP over D= TLS.

</Raju>
 <=
/i>
BR
Raju

 

“SCTP association: = A protocol relationship between SCTP endpoints,

         &nb= sp;      composed of the two SCTP endpoints and pr= otocol state information

         &nb= sp;      including Verification Tags and the curre= ntly active set of

         &nb= sp;      Transmission Sequence Numbers (TSNs), etc= .  An association can be

         &nb= sp;      uniquely identified by the transport addr= esses used by the

         &nb= sp;      endpoints in the association.  Tw= o SCTP endpoints MUST NOT have

         =        more than one SCTP association between= them at any given time.”

 

Now, does that mean that, for a given SDP session, w= e can only have a single SCTP m- line (read: single SCTP usage)?=

 

For WebRTC usage that is probably enough, as we use = SCTP only for the data channel, but in general…

 

Regards,

 

Christer

--_000_E1FE4C082A89A246A11D7F32A95A17828E63BC0FUS70UWXCHMBA02z_-- From nobody Tue Nov 25 04:34:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2651A0155 for ; Tue, 25 Nov 2014 04:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA6tqEun5Fk4 for ; Tue, 25 Nov 2014 04:34:23 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070DE1A0151 for ; Tue, 25 Nov 2014 04:34:23 -0800 (PST) Received: from [130.209.157.39] (port=6873 helo=glaroam2-128-189.wireless.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XtFK0-0002xj-7N for mmusic@ietf.org; Tue, 25 Nov 2014 12:34:21 +0000 From: Colin Perkins Content-Type: multipart/alternative; boundary="Apple-Mail=_67F45DA9-D96E-4DAA-8577-7C9D2E7489F2" Message-Id: <596DA376-D525-49A2-B260-2BADB38AF2E2@csperkins.org> Date: Tue, 25 Nov 2014 12:34:17 +0000 To: mmusic Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4G1lh-kslNqqjNBgMxB0wYNW1NQ Subject: [MMUSIC] Comments on ABNF in 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:34:25 -0000 --Apple-Mail=_67F45DA9-D96E-4DAA-8577-7C9D2E7489F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, The chairs asked me to review the ABNF in rfc4566bis. This looks to be = going in the right direction. Some comments: a=3Dcat: - This attribute was used with SAP [RFC2974] to categorise session = announcements, for example =93a=3Dcat:sport.football=94. There was never = a formal definition beyond a dot-separated string, and intentionally no = central registry of categories.=20 - Should likely have a not to say this is obsolete. - Syntax should likely be non-ws-string a=3Dkeywds: - Like a=3Dcat:, this was intended for use with SAP. I=92m not aware = that it was ever implemented.=20 - Should likely have a not to say this is obsolete. - Syntax should likely be: =93keywords =3D text=94 a=3Dtool: - Something like HTTP user agent string - Syntax should likely be: =93tool-name-and-version =3D text=94 a=3Dptime: and a=3Dmaxptime: - Are these always integers? a=3Drtpmap: - payload-type is an integer in the range 0-127 in RTP - encoding-name is a MIME subtype, and should have the syntax to match = this - is clock-rate always an integer? a=3Dtype: - I assume a registry was intended, but it=92s not clear there=92s any = need now a=3Dcharset: - This is a name from the registry at = http://www.iana.org/assignments/character-sets/character-sets.xhtml and = needs to follow that syntax a=3Dsdplang: and a=3Dlang: - Should reference the RFC5646 definition a=3Dquality: - I thought the intent here was a real number, in the range 0=8510 a=3Dfmtp: - The format parameters are MIME media type parameters, and need to = reflect their syntax. Colin --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_67F45DA9-D96E-4DAA-8577-7C9D2E7489F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

The chairs asked me to review = the ABNF in rfc4566bis. This looks to be going in the right direction. = Some comments:

a=3Dcat:
- This attribute was used with SAP = [RFC2974] to categorise session announcements, for example = =93a=3Dcat:sport.football=94. There was never a formal definition beyond = a dot-separated string, and intentionally no central registry of = categories. 
- Should = likely have a not to say this is obsolete.
- Syntax should likely be = non-ws-string

a=3Dkeywds:
- Like a=3Dcat:, this was intended for use = with SAP. I=92m not aware that it was ever implemented. 
- Should likely have a not to say this is = obsolete.
- Syntax should likely = be: =93keywords =3D text=94

a=3Dtool:
- Something like HTTP user agent = string
- Syntax should likely = be: =93tool-name-and-version =3D text=94

a=3Dptime: and = a=3Dmaxptime:
- Are these = always integers?

a=3Drtpmap:
- payload-type is an integer in the range = 0-127 in RTP
- encoding-name is = a MIME subtype, and should have the syntax to match this
- is clock-rate always an = integer?

a=3Dtype:
- I assume a registry was intended, but = it=92s not clear there=92s any need now

a=3Dcharset:
- This is a name from the registry at http://www.iana.org/assignments/character-sets/character-sets.xhtml= and needs to follow that syntax

a=3Dsdplang: and = a=3Dlang:
- Should = reference the RFC5646 definition

a=3Dquality:
- I thought the intent here was a real = number, in the range 0=8510

a=3Dfmtp:
- The format parameters are MIME media = type parameters, and need to reflect their syntax.

Colin



-- 
Colin Perkins
https://csperkins.org/



=

= --Apple-Mail=_67F45DA9-D96E-4DAA-8577-7C9D2E7489F2-- From nobody Tue Nov 25 04:40:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BD91A0172 for ; Tue, 25 Nov 2014 04:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOyg6e6nznz7 for ; Tue, 25 Nov 2014 04:40:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814841A0158 for ; Tue, 25 Nov 2014 04:40:21 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-f9-547478b3181d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.A0.04231.3B874745; Tue, 25 Nov 2014 13:40:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 13:40:19 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKA= Date: Tue, 25 Nov 2014 12:40:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53595DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje7mipIQg5nH5CymLn/MYtGw8Qqr A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4cKOFqWBrbMXcKV1sDYzvA7oYOTkkBEwk Hj9dygphi0lcuLeerYuRi0NI4AijxKxZl5kgnCWMEtNOHmHsYuTgYBOwkOj+pw3SICKQI/H7 1nuwZmEBfYnV7ROYIOIGEv1r7jNC2FYSP0+2M4PYLAKqEvsPtbKA2LwCvhLfdl6Dmr+AUWLt ukVsIAlOgViJR4v6wYYyAl30/dQasKHMAuISt57MZ4K4VEBiyZ7zzBC2qMTLx/9YQW6TEFCS mLY1DaI8X+LA/b2sELsEJU7OfMIygVFkFpJJs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yB x0zI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbVwS2/dXcwrn7teIhRgINRiYd3 w4fiECHWxLLiytxDjNIcLErivIvOzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDhNspzl +JJtlxtb9tz6c6RQ/GL0wmXPhIL6t/oxbHQ8H/7ow4N/c3asU5Be9rhzn8ypHMd9VkU34/vF VzhrLTru3znhoWHJeY0M7YmWZ93UjaoclKX3vbp7RLbKY0eb7b3YO8Us7QrMAqa2fH0Hz1nf ShY66fZ9ubTg1PwpIj8ynQU95opxMSqxFGckGmoxFxUnAgCBv9PqjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/I-ZAv7atK5ENQTzbjtsUBb5e8xg Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:40:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53595DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Hopefully there are some SCTP experts in da hause that can clarify the foll= owing: Previously, in the SCTP-SDP discussions, we have agreed that for a given SC= TP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g.= a webrtc-datachannel). So, if one wants multiple usages, one needs to establish multiple associati= ons, using multiple m- lines. BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one = SCTP association between them at any given time. Not exactly sure why, but = that is what the text says... An SCTP association is identified by 4-tuple: src ip, src port, dst = ip, dst port (they form 2 Endpoints). To have a new SCTP association you ne= ed to change one parameter in the 4-tuple and most of the times local ip of= the client is changed (if app does not specify a port then OS selects a lo= cal port). So, between same 2 hosts more than one SCTP associations are all= owed. That would make sense, but that is not my understanding of the t= ext in RFC 4960, which talks about SCTP endpoints, not 4-tuples. Or, is the= 4-tuple part of the SCTP endpoint definition? Per "TCP-Based Media Transport in the Session Description Protocol (SDP) "R= FC 4145 (section 4.1), the port conveyed in m=3D line is server port when a= =3Dsetup:actpass or passive is used. For a=3Dsetup:active, port 9 (discard)= should be used (as the client port may not be known until TCP conn is init= iated). I do not see similar semantics in http://www.ietf.org/id/draft-ietf-mmusic-= sctp-sdp-07.txt . These semantics are needed in this draft as well for nati= ve SCTP usage as well as SCTP over DTLS. This was discussed in Honolulu, and the agreement was that the s= etup attribute will NOT be used to determine who initiates the SCTP associa= tion. Instead BOTH endpoints are supposed to trigger the initiation. The se= tup attribute will only be used to determine the TLS role. Regards, Christer "SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state infor= mation including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association = can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT = have more than one SCTP association between them at any given ti= me." Now, does that mean that, for a given SDP session, we can only have a singl= e SCTP m- line (read: single SCTP usage)? For WebRTC usage that is probably enough, as we use SCTP only for the data = channel, but in general... Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D53595DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Hopefully there are some SCTP experts in da hause th= at can clarify the following:

 

Previously, in the SCTP-SDP discussions, we have agr= eed that for a given SCTP/SCTPoDTLS/DTLSoSCTP association, we will only all= ow a single usage (e.g. a webrtc-datachannel).

 

So, if one wants multiple usages, one needs to estab= lish multiple associations, using multiple m- lines.

 

BUT, according to RFC 4960, two SCTP endpoints MUST = NOT have more than one SCTP association between them at any given time. Not= exactly sure why, but that is what the text says…

<Raju> An SCTP association is identified by 4-tu=
ple: src ip, src port, dst ip, dst port (they form 2 Endpoints). To have a =
new SCTP association you need to change one parameter in the 4-tuple and mo=
st of the times local ip of the client is changed (if app does not specify =
a port then OS selects a local port). So, between same 2 hosts more than on=
e SCTP associations are allowed.
 

<Christer> That would make sense, but =
that is not my understanding of the text in RFC 4960, which talks about SCT=
P endpoints, not 4-tuples. Or, is the 4-tuple part of the SCTP endpoint def=
inition?


 <=
/i>


Per “TCP-Based Media Transport in the Session De=
scription Protocol (SDP) “RFC 4145 (section 4.1), the port conveyed i=
n m=3D line is server port when a=3Dsetup:actpass or passive is used. For a=
=3Dsetup:active, port 9 (discard) should be used (as the client port may no=
t be known until TCP conn is initiated).


I do not see sim=
ilar semantics in
http:/=
/www.ietf.org/id/draft-ietf-mmusic-sctp-sdp-07.txt . These semantics ar=
e needed in this draft as well for native SCTP usage as well as SCTP over D=
TLS.


 


<Christer> This was discussed in Honol=
ulu, and the agreement was that the setup attribute will NOT be used to det=
ermine who initiates the SCTP association. Instead BOTH endpoints are suppo=
sed to trigger the initiation. The setup attribute will only be used to det=
ermine the TLS role.


 


Regards,


 


Christer


 


 


 


“SCTP association=
: A protocol relationship between SCTP endpoints,


         &nb=
sp;      composed of the two SCTP endpoints and pr=
otocol state information


         &nb=
sp;      including Verification Tags and the curre=
ntly active set of


         &nb=
sp;      Transmission Sequence Numbers (TSNs), etc=
.  An association can be


         &nb=
sp;      uniquely identified by the transport addr=
esses used by the


         &nb=
sp;      endpoints in the association.  Tw=
o SCTP endpoints MUST NOT have


         =
       more than one SCTP association between=
 them at any given time.”


 


Now, does that mean that, for a given SDP session, w=
e can only have a single SCTP m- line (read: single SCTP usage)?=



 


For WebRTC usage that is probably enough, as we use =
SCTP only for the data channel, but in general…


 


Regards,


 


Christer
--_000_7594FB04B1934943A5C02806D1A2204B1D53595DESESSMB209erics_-- From nobody Tue Nov 25 04:51:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8446A1A01FA for ; Tue, 25 Nov 2014 04:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Od-YGVdyBHg for ; Tue, 25 Nov 2014 04:51:54 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CD91A01D6 for ; Tue, 25 Nov 2014 04:51:53 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-60-54747b677f3a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7F.12.24955.76B74745; Tue, 25 Nov 2014 13:51:51 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.195.1; Tue, 25 Nov 2014 13:51:51 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3EE701102B1; Tue, 25 Nov 2014 14:51:51 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E20A15F633; Tue, 25 Nov 2014 14:52:28 +0200 (EET) Received: from ip-193-234-217-64.guest.ericsson.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 84B0C593E0; Tue, 25 Nov 2014 14:52:28 +0200 (EET) Message-ID: <54747B60.4000104@ericsson.com> Date: Tue, 25 Nov 2014 14:51:44 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW56dUmIwa9/VhafujewWUxd/pjF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MrY0nyXseATc8XUs41sDYwTmLsYOTkkBEwk fhyfwgJhi0lcuLeerYuRi0NI4AijxJyrj9khnA2MEn0N2xkhnD2MEvfvf4Ry1jJKvP3xCcrZ xijRO/UQ2GBeAW2JRwffANkcHCwCqhLzT/CBhNkEbCVWv7oJtk9UIFmi6+VDJohyQYmTM5+A xUWAanqPLWUEsZkFZCRmnG0EqxEWcJO4MfsXM0TcQmLm/PNQNfIS29/OgfpHTeLquU1gthDQ 2qv/XjFOYBSehWTFLCTts5C0L2BkXsUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGOQHt/xW 3cF4+Y3jIUYBDkYlHt4NH4pDhFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY3zLhJS8X/u3H5q87vz6hW41KQu+rAxkYTJ4UTGxPe1tDvf70DX6rdW8//+e X1a05WCpI39OaNi+69nv5j7ebOtTIpl88pTxSfG4/YeTZn1svvkwQH+zlfGWNI2r/PNalrxP mefJt/ZD4PfTfw/apx5sXpO990DVsrd/zt1L4ss2OX9Q7kOGVJoSS3FGoqEWc1FxIgCgt/u6 UwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/iDgBJqKvRq0KT60hkEcXi3KxFcI Cc: mmusic Subject: [MMUSIC] WGLC comments for draft-ietf-mmusic-sdp-bundle-negotiation-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:51:55 -0000 Hi, Couple of more review comments for the bundle draft: The "New RTP Header Extension URI" doesn't have any normative text in the draft, only the IANA considerations (Section 14.2). The security considerations section could discuss the fact that when bundle is used, any security middleboxes (e.g., firewalls and IDS devices) implementing policies based solely on transport layer port numbers don't work since various kind of traffic is using the same 5-tuple. Cheers, Ari From nobody Tue Nov 25 05:29:01 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A6F1A0A6A for ; Tue, 25 Nov 2014 05:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGt91TSt2w3D for ; Tue, 25 Nov 2014 05:28:52 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8981A0636 for ; Tue, 25 Nov 2014 05:28:51 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 2028D33BDFA7C; Tue, 25 Nov 2014 13:28:46 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sAPDSlFc000398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 08:28:47 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 08:28:47 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAA== Date: Tue, 25 Nov 2014 13:28:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E63BE81US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_QkqiP60efR96WPnBl7CLlIozVc Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 13:28:56 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E63BE81US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline comments marked under tags. Hi, Hopefully there are some SCTP experts in da hause that can clarify the foll= owing: Previously, in the SCTP-SDP discussions, we have agreed that for a given SC= TP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g.= a webrtc-datachannel). So, if one wants multiple usages, one needs to establish multiple associati= ons, using multiple m- lines. BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one = SCTP association between them at any given time. Not exactly sure why, but = that is what the text says... An SCTP association is identified by 4-tuple: src ip, src port, dst = ip, dst port (they form 2 Endpoints). To have a new SCTP association you ne= ed to change one parameter in the 4-tuple and most of the times local ip of= the client is changed (if app does not specify a port then OS selects a lo= cal port). So, between same 2 hosts more than one SCTP associations are all= owed. That would make sense, but that is not my understanding of the t= ext in RFC 4960, which talks about SCTP endpoints, not 4-tuples. Or, is the= 4-tuple part of the SCTP endpoint definition? RFC 4960 defines SCTP Endpoint as the following. And yes, ip address(es)+po= rt on each side constitutes an endpoint. o SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. Per "TCP-Based Media Transport in the Session Description Protocol (SDP) "R= FC 4145 (section 4.1), the port conveyed in m=3D line is server port when a= =3Dsetup:actpass or passive is used. For a=3Dsetup:active, port 9 (discard)= should be used (as the client port may not be known until TCP conn is init= iated). I do not see similar semantics in http://www.ietf.org/id/draft-ietf-mmusic-= sctp-sdp-07.txt . These semantics are needed in this draft as well for nati= ve SCTP usage as well as SCTP over DTLS. This was discussed in Honolulu, and the agreement was that the s= etup attribute will NOT be used to determine who initiates the SCTP associa= tion. Instead BOTH endpoints are supposed to trigger the initiation. The se= tup attribute will only be used to determine the TLS role. 2 use cases: 1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS. The sctp port usage needs be clarified indicating it is the server port, = not the client port. 2.Native SCTP: I believe a=3Dsetup is for SCTP association. When a=3Dsetup:passive/actpass is used the sctp port usage needs to be clar= ified indicating it is the server port. When a=3Dsetup:active is used port = must be 9 (discard port). This needs clarification as well. Both sides trying to open SCTP simultaneously is probably ok because SCTP a= llows them to be converted into single association if there are simultaneou= s INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. = This is per RFC 4960 section 5.2.1 and 5.2.2 . But the key here is same 4-tuple, which means the client must use same **se= rver port** to initiate an outgoing association. If this is not done then, = the end result will be 2 SCTP associations setup and/or one of them may be = rejected and may depend on implementation. So, I believe some clarifications are needed in this area. BR Raju Regards, Christer "SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state infor= mation including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association = can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT = have more than one SCTP association between them at any given ti= me." Now, does that mean that, for a given SDP session, we can only have a singl= e SCTP m- line (read: single SCTP usage)? For WebRTC usage that is probably enough, as we use SCTP only for the data = channel, but in general... Regards, Christer --_000_E1FE4C082A89A246A11D7F32A95A17828E63BE81US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline comm= ents marked under <Raju2> tags.

 

Hi,

 

Hopefully there are some SCTP experts in da hause th= at can clarify the following:

 

Previously, in the SCTP-SDP discussions, we have agr= eed that for a given SCTP/SCTPoDTLS/DTLSoSCTP association, we will only all= ow a single usage (e.g. a webrtc-datachannel).

 

So, if one wants multiple usages, one needs to estab= lish multiple associations, using multiple m- lines.

 

BUT, according to RFC 4960, two SCTP endpoints MUST = NOT have more than one SCTP association between them at any given time. Not= exactly sure why, but that is what the text says…

<Raju> An SCTP association is identified by 4-tu=
ple: src ip, src port, dst ip, dst port (they form 2 Endpoints). To have a =
new SCTP association you need to change one parameter in the 4-tuple and mo=
st of the times local ip of the client is changed (if app does not specify =
a port then OS selects a local port). So, between same 2 hosts more than on=
e SCTP associations are allowed.
 

<Christer> That would make sense, but =
that is not my understanding of the text in RFC 4960, which talks about SCT=
P endpoints, not 4-tuples. Or, is the 4-tuple part of the SCTP endpoint def=
inition?


<Raju2>


RFC 4960 defines SCTP Endpoint as the=
 following. And yes, ip address(es)+port on each side constitutes an en=
dpoint.


 

o  SCT=
P endpoint: The logical sender/receiver of SCTP packets.  On a


  =
;    multi-homed host, an SCTP endpoint is represented to it=
s peers as


  =
;    a combination of a set of eligible destination transpor=
t addresses


  =
;    to which SCTP packets can be sent and a set of eligible=
 source


  =
;    transport addresses from which SCTP packets can be rece=
ived.  All


  =
;    transport addresses used by an SCTP endpoint must use t=
he same


  =
;    port number, but can use multiple IP addresses.  A=
 transport


  =
;    address used by an SCTP endpoint must not be used by an=
other SCTP


  =
;    endpoint.  In other words, a transport address is =
unique to an


  =
;    SCTP endpoint.


 

</Raju2>


 


 <=
/i>


Per “TCP-Based Media Transport in the Session De=
scription Protocol (SDP) “RFC 4145 (section 4.1), the port conveyed i=
n m=3D line is server port when a=3Dsetup:actpass or passive is used. For a=
=3Dsetup:active, port 9 (discard) should be used (as the client port may no=
t be known until TCP conn is initiated).


I do not see sim=
ilar semantics in
http:/=
/www.ietf.org/id/draft-ietf-mmusic-sctp-sdp-07.txt . These semantics ar=
e needed in this draft as well for native SCTP usage as well as SCTP over D=
TLS.


 


<Christer> This was discussed in Honol=
ulu, and the agreement was that the setup attribute will NOT be used to det=
ermine who initiates the SCTP association. Instead BOTH endpoints are suppo=
sed to trigger the initiation. The setup attribute will only be used to det=
ermine the TLS role.


<Raju2>


2 use cases:


1.SCTP over DTLS: For this yes, a=3Dsetu=
p is for DTLS.


  The sctp port usage needs be clar=
ified indicating it is the server port, not the client port.


2.Native SCTP: I believe a=3Dsetup is fo=
r SCTP association.


When a=3Dsetup:passive/actpass is used t=
he sctp port usage needs to be clarified indicating it is the server port. =
When a=3Dsetup:active is used port must be 9 (discard port). This needs cla=
rification as well.


Both sides trying to open SCTP simultane=
ously is probably ok because SCTP allows them to be converted into single a=
ssociation if there are simultaneous INITs (or INIT chunk received in ESTAB=
LISHED state) on the same 4-tuple. This is per RFC 4960 section 5.2.1 and 5.2.2 .


But the key here is same 4-tuple, which =
means the client must use same **server port** to initiate an outgoing asso=
ciation. If this is not done then, the end result will be 2 SCTP associatio=
ns setup and/or one of them may be rejected and may depend on implementatio=
n.


So, I believe some clarifications are ne=
eded in this area.


 


</Raju2><=
/b>


 

BR


Raju


 


Regards,


 


Christer


 


 


 


“SCTP association: =
A protocol relationship between SCTP endpoints,


         &nb=
sp;      composed of the two SCTP endpoints and pr=
otocol state information


         &nb=
sp;      including Verification Tags and the curre=
ntly active set of


         &nb=
sp;      Transmission Sequence Numbers (TSNs), etc=
.  An association can be


         &nb=
sp;      uniquely identified by the transport addr=
esses used by the


         &nb=
sp;      endpoints in the association.  Tw=
o SCTP endpoints MUST NOT have


         =
       more than one SCTP association between=
 them at any given time.”


 


Now, does that mean that, for a given SDP session, w=
e can only have a single SCTP m- line (read: single SCTP usage)?=



 


For WebRTC usage that is probably enough, as we use =
SCTP only for the data channel, but in general…


 


Regards,


 


Christer
--_000_E1FE4C082A89A246A11D7F32A95A17828E63BE81US70UWXCHMBA02z_-- From nobody Tue Nov 25 05:46:05 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3101A1A32 for ; Tue, 25 Nov 2014 05:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekwDe2Q-lZsw for ; Tue, 25 Nov 2014 05:46:00 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968A21A1A38 for ; Tue, 25 Nov 2014 05:45:58 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-ba-547488141501 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.52.04081.41884745; Tue, 25 Nov 2014 14:45:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 14:45:56 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAAABS24g Date: Tue, 25 Nov 2014 13:45:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D535B26ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvja5IR0mIwc4GS4upyx+zWDRsvMLq wOTR+mwvq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJWPXrAVnBoG2PF/7snWRoYWxYwdjFyckgI mEhsebSeBcIWk7hwbz1bFyMXh5DAEUaJPXfWsUM4Sxglvn1Zy9rFyMHBJmAh0f1PG6RBRCBH 4vet96wgtrCAvsTq9glMEHEDif419xkhbDeJOz8XsIHYLAKqEhuutzGD2LwCvhKL+75Azd/O JPHkwF52kASnQKzErWXbwAYxAl30/dQaMJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B/YbRIC ShLTtqZBlOdL3F37jRVil6DEyZlPWCYwisxCMmkWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOf OfCYCVl8ASP7KkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzA2Dq45bfBDsaXzx0PMQpwMCrx 8G74UBwixJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYK9rd vy63k5t7nsk18f76xxf1fj/yfcv/8l1a9sWtnhqLUt7nzgkpf/jom9z+/mtyJs2Fn02y7H+V Pdj6MKy5UcPMv9h8vmzOWhNdkUOOKsskF8h4FpwJ67C73u/3+8gxVuMJf3SPrp1zPZDne/FP 8Vlyf2ZvUT7Wct2k74hy6Tr5abauaXl5SizFGYmGWsxFxYkARwLfxo4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nGyOiZTXsswCAEH8b9cRw9eb8ZA Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 13:46:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D535B26ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Hopefully there are some SCTP experts in da hause that can clarify the foll= owing: Previously, in the SCTP-SDP discussions, we have agreed that for a given SC= TP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g.= a webrtc-datachannel). So, if one wants multiple usages, one needs to establish multiple associati= ons, using multiple m- lines. BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one = SCTP association between them at any given time. Not exactly sure why, but = that is what the text says... An SCTP association is identified by 4-tuple: src ip, src port, dst = ip, dst port (they form 2 Endpoints). To have a new SCTP association you ne= ed to change one parameter in the 4-tuple and most of the times local ip of= the client is changed (if app does not specify a port then OS selects a lo= cal port). So, between same 2 hosts more than one SCTP associations are all= owed. That would make sense, but that is not my understanding of the t= ext in RFC 4960, which talks about SCTP endpoints, not 4-tuples. Or, is the= 4-tuple part of the SCTP endpoint definition? RFC 4960 defines SCTP Endpoint as the following. And yes, ip address(es)+po= rt on each side constitutes an endpoint. o SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. Well, I hope you are right :) Per "TCP-Based Media Transport in the Session Description Protocol (SDP) "R= FC 4145 (section 4.1), the port conveyed in m=3D line is server port when a= =3Dsetup:actpass or passive is used. For a=3Dsetup:active, port 9 (discard)= should be used (as the client port may not be known until TCP conn is init= iated). I do not see similar semantics in http://www.ietf.org/id/draft-ietf-mmusic-= sctp-sdp-07.txt . These semantics are needed in this draft as well for nati= ve SCTP usage as well as SCTP over DTLS. This was discussed in Honolulu, and the agreement was that the s= etup attribute will NOT be used to determine who initiates the SCTP associa= tion. Instead BOTH endpoints are supposed to trigger the initiation. The se= tup attribute will only be used to determine the TLS role. 2 use cases: 1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS. The sctp port usage needs be clarified indicating it is the server port, = not the client port. Yes. 2.Native SCTP: I believe a=3Dsetup is for SCTP association. When a=3Dsetup:passive/actpass is used the sctp port usage needs to be clar= ified indicating it is the server port. When a=3Dsetup:active is used port = must be 9 (discard port). This needs clarification as well. Both sides trying to open SCTP simultaneously is probably ok because SCTP a= llows them to be converted into single association if there are simultaneou= s INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. = This is per RFC 4960 section 5.2.1 and 5.2.2 . But the key here is same 4-tuple, which means the client must use same **se= rver port** to initiate an outgoing association. If this is not done then, = the end result will be 2 SCTP associations setup and/or one of them may be = rejected and may depend on implementation. So, I believe some clarifications are needed in this area. So, assuming we don't use (per the agreement in Honolulu) a=3Ds= etup for the SCTP association, we would need to mandate (or, at least say S= HOULD) usage of the server port also to initiate an outgoing association, i= n order to avoid 2 SCTP associations. But, that also applies to SCTP over DTLS, doesn't it? Regards, Christer "SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state infor= mation including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association = can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT = have more than one SCTP association between them at any given ti= me." Now, does that mean that, for a given SDP session, we can only have a singl= e SCTP m- line (read: single SCTP usage)? For WebRTC usage that is probably enough, as we use SCTP only for the data = channel, but in general... Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D535B26ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Hopefully there are some SCTP experts in da hause th= at can clarify the following:

 

Previously, in the SCTP-SDP discussions, we have agr= eed that for a given SCTP/SCTPoDTLS/DTLSoSCTP association, we will only all= ow a single usage (e.g. a webrtc-datachannel).

 

So, if one wants multiple usages, one needs to estab= lish multiple associations, using multiple m- lines.

 

BUT, according to RFC 4960, two SCTP endpoints MUST = NOT have more than one SCTP association between them at any given time. Not= exactly sure why, but that is what the text says…

<Raju> An SCTP association is identified by 4-tu=
ple: src ip, src port, dst ip, dst port (they form 2 Endpoints). To have a =
new SCTP association you need to change one parameter in the 4-tuple and mo=
st of the times local ip of the client is changed (if app does not specify =
a port then OS selects a local port). So, between same 2 hosts more than on=
e SCTP associations are allowed.
 

<Christer> That would make sense, but =
that is not my understanding of the text in RFC 4960, which talks about SCT=
P endpoints, not 4-tuples. Or, is the 4-tuple part of the SCTP endpoint def=
inition?


<Raju2>


RFC 4960 defines SCTP Endpoint as the=
 following. And yes, ip address(es)+port on each side constitutes an en=
dpoint.


 

o  SCT=
P endpoint: The logical sender/receiver of SCTP packets.  On a


  =
;    multi-homed host, an SCTP endpoint is represented to it=
s peers as


  =
;    a combination of a set of eligible destination transpor=
t addresses


  =
;    to which SCTP packets can be sent and a set of eligible=
 source


  =
;    transport addresses from which SCTP packets can be rece=
ived.  All


  =
;    transport addresses used by an SCTP endpoint must use t=
he same


  =
;    port number, but can use multiple IP addresses.  A=
 transport


  =
;    address used by an SCTP endpoint must not be used by an=
other SCTP


  =
;    endpoint.  In other words, a transport address is =
unique to an


  =
;    SCTP endpoint.


 

</Raju2>


 


<Christer2> Well, I hope you are right=
 :)


 


 <=
/i>


Per “TCP-Based Media Transport in the Session De=
scription Protocol (SDP) “RFC 4145 (section 4.1), the port conveyed i=
n m=3D line is server port when a=3Dsetup:actpass or passive is used. For a=
=3Dsetup:active, port 9 (discard) should be used (as the client port may no=
t be known until TCP conn is initiated).


I do not see sim=
ilar semantics in
http:/=
/www.ietf.org/id/draft-ietf-mmusic-sctp-sdp-07.txt . These semantics ar=
e needed in this draft as well for native SCTP usage as well as SCTP over D=
TLS.


 


<Christer> This was discussed in Honol=
ulu, and the agreement was that the setup attribute will NOT be used to det=
ermine who initiates the SCTP association. Instead BOTH endpoints are suppo=
sed to trigger the initiation. The setup attribute will only be used to det=
ermine the TLS role.


<Raju2>


2 use cases:


1.SCTP over DTLS: For this yes, a=3Dsetu=
p is for DTLS.


  The sctp port usage needs be clar=
ified indicating it is the server port, not the client port.


 


<Christer2> Yes.=



 


 


2.Native SCTP: I believe a=3Dsetup is fo=
r SCTP association.


When a=3Dsetup:passive/actpass is used t=
he sctp port usage needs to be clarified indicating it is the server port. =
When a=3Dsetup:active is used port must be 9 (discard port). This needs cla=
rification as well.


Both sides trying to open SCTP simultane=
ously is probably ok because SCTP allows them to be converted into single a=
ssociation if there are simultaneous INITs (or INIT chunk received in ESTAB=
LISHED state) on the same 4-tuple. This is per RFC 4960 section 5.2.1 and 5.2.2 .


But the key here is same 4-tuple, which =
means the client must use same **server port** to initiate an outgoing asso=
ciation. If this is not done then, the end result will be 2 SCTP associatio=
ns setup and/or one of them may be rejected and may depend on implementatio=
n.


So, I believe some clarifications are ne=
eded in this area.


 


<Christer2> So, assuming we don’=
t use (per the agreement in Honolulu) a=3Dsetup for the SCTP association, w=
e would need to mandate (or, at least say SHOULD) usage of the server port =
also to initiate an outgoing association, in order to avoid 2 SCTP associat=
ions.


 


But, that also applies to SCTP over DTLS, do=
esn’t it?


 


Regards,


 


Christer


 


 

 

 

 


 


“SCTP association=
: A protocol relationship between SCTP endpoints,


         &nb=
sp;      composed of the two SCTP endpoints and pr=
otocol state information


         &nb=
sp;      including Verification Tags and the curre=
ntly active set of


         &nb=
sp;      Transmission Sequence Numbers (TSNs), etc=
.  An association can be


         &nb=
sp;      uniquely identified by the transport addr=
esses used by the


         &nb=
sp;      endpoints in the association.  Tw=
o SCTP endpoints MUST NOT have


         =
       more than one SCTP association between=
 them at any given time.”


 


Now, does that mean that, for a given SDP session, w=
e can only have a single SCTP m- line (read: single SCTP usage)?=



 


For WebRTC usage that is probably enough, as we use =
SCTP only for the data channel, but in general…


 


Regards,


 


Christer
--_000_7594FB04B1934943A5C02806D1A2204B1D535B26ESESSMB209erics_-- From nobody Tue Nov 25 05:53:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D431A1A3C for ; Tue, 25 Nov 2014 05:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0ke-0cnixrE for ; Tue, 25 Nov 2014 05:53:40 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DDD1A1A32 for ; Tue, 25 Nov 2014 05:53:34 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 63E272D738064; Tue, 25 Nov 2014 13:53:29 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sAPDrUC6017587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 08:53:30 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 08:53:30 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAAABS24gAABbYpA= Date: Tue, 25 Nov 2014 13:53:29 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E63BF30US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VO_QGnNv5Govx0l0sLEzQTXYt6g Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 13:53:47 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E63BF30US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see comments under tags. This was discussed in Honolulu, and the agreement was that the s= etup attribute will NOT be used to determine who initiates the SCTP associa= tion. Instead BOTH endpoints are supposed to trigger the initiation. The se= tup attribute will only be used to determine the TLS role. 2 use cases: 1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS. The sctp port usage needs be clarified indicating it is the server port, = not the client port. Yes. 2.Native SCTP: I believe a=3Dsetup is for SCTP association. When a=3Dsetup:passive/actpass is used the sctp port usage needs to be clar= ified indicating it is the server port. When a=3Dsetup:active is used port = must be 9 (discard port). This needs clarification as well. Both sides trying to open SCTP simultaneously is probably ok because SCTP a= llows them to be converted into single association if there are simultaneou= s INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. = This is per RFC 4960 section 5.2.1 and 5.2.2 . But the key here is same 4-tuple, which means the client must use same **se= rver port** to initiate an outgoing association. If this is not done then, = the end result will be 2 SCTP associations setup and/or one of them may be = rejected and may depend on implementation. So, I believe some clarifications are needed in this area. So, assuming we don't use (per the agreement in Honolulu) a=3Ds= etup for the SCTP association, we would need to mandate (or, at least say S= HOULD) usage of the server port also to initiate an outgoing association, i= n order to avoid 2 SCTP associations. But, that also applies to SCTP over DTLS, doesn't it? Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above de= scription under "native SCTP" instead of "SCTP over DTLS". For native SCTP,= as discussed, a=3Dsetup negotiation determines which side initiates SCTP a= ssociation, so the semantics are very clear here. BR Raju --_000_E1FE4C082A89A246A11D7F32A95A17828E63BF30US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see comments un= der <Raju3> tags.

 

<Christer> This was discussed in Honol=
ulu, and the agreement was that the setup attribute will NOT be used to det=
ermine who initiates the SCTP association. Instead BOTH endpoints are suppo=
sed to trigger the initiation. The setup attribute will only be used to det=
ermine the TLS role.
<Raju2>
2 use cases:
1.SCTP over DTLS: For this yes, a=3Dsetu=
p is for DTLS.
  The sctp port usage needs be clar=
ified indicating it is the server port, not the client port.
 
<Christer2> Yes.=

 
 
2.Native SCTP: I believe a=3Dsetup is fo=
r SCTP association.
When a=3Dsetup:passive/actpass is used t=
he sctp port usage needs to be clarified indicating it is the server port. =
When a=3Dsetup:active is used port must be 9 (discard port). This needs cla=
rification as well.
Both sides trying to open SCTP simultane=
ously is probably ok because SCTP allows them to be converted into single a=
ssociation if there are simultaneous INITs (or INIT chunk received in ESTAB=
LISHED state) on the same 4-tuple. This is per RFC 4960 section 5.2.1 and 5.2.2 .
But the key here is same 4-tuple, which =
means the client must use same **server port** to initiate an outgoing asso=
ciation. If this is not done then, the end result will be 2 SCTP associatio=
ns setup and/or one of them may be rejected and may depend on implementatio=
n.
So, I believe some clarifications are ne=
eded in this area.
 
<Christer2> So, assuming we don’=
t use (per the agreement in Honolulu) a=3Dsetup for the SCTP association, w=
e would need to mandate (or, at least say SHOULD) usage of the server port =
also to initiate an outgoing association, in order to avoid 2 SCTP associat=
ions.
 
But, that also applies to SCTP over DTLS, do=
esn’t it?
<Raju3>
Sorry, it actually ONLY applies to SC=
TP over DTLS. I misplaced the above description under “native SCTP=
221; instead of “SCTP over DTLS”. For native SCTP, as discussed=
, a=3Dsetup negotiation determines which side initiates SCTP association, s=
o the semantics are very clear here.
</Raju3>
 
BR
Raju
 
--_000_E1FE4C082A89A246A11D7F32A95A17828E63BF30US70UWXCHMBA02z_-- From nobody Tue Nov 25 06:04:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361921A1A55 for ; Tue, 25 Nov 2014 06:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN94LvfWoTld for ; Tue, 25 Nov 2014 06:04:15 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DF81A1A3B for ; Tue, 25 Nov 2014 06:04:02 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-f8-54748c50105b Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.6C.04076.05C84745; Tue, 25 Nov 2014 15:04:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 15:04:00 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAAABS24gAABbYpAAAHFTwA== Date: Tue, 25 Nov 2014 14:03:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D535BB7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjW5AT0mIwZujNhZTlz9msWjYeIXV gcmj9dleVo8lS34yBTBFcdmkpOZklqUW6dslcGXM6F7AWtAQU/Hm0m/mBsaNgV2MnBwSAiYS H79PZoWwxSQu3FvP1sXIxSEkcIRRYsOCv0wQzhJGie4Dq4GqODjYBCwkuv9pgzSICORI/L71 HqxZWEBfYnX7BCaIuIFE/5r7jBB2mMTV5xfZQGwWAVWJFStPg9XwCvhKTNpzCaxXSOAcs8Sp fYkgNqdArMStz3dYQGxGoIO+n1oDVs8sIC5x68l8JohDBSSW7DnPDGGLSrx8/A/sNAkBJYlp W9MgyvMluk/OZ4dYJShxcuYTlgmMIrOQTJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxm QhZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwqg5u+W21g/Hgc8dDjAIcjEo8vBs+ FIcIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGiC7lA1Gc P9bOOHx0nY9e0acfQtsfrDqh3v2yuej+WZa+l+8nqR9bdzFhw1WbwqniUZ9v9M/bHMf//b9S 09m+a75vd8yTybPaHfmVUajtlvaR3UzZ7RMk9b8aHHF6xt/vcjMhqlXqjYH/uoYHqy7Ibp80 c2fPlROT5BvDMpqDLog7bWXdtCvIQYmlOCPRUIu5qDgRAH6pWQqLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/s02aI44lNCIfbvKpdSzJfTtSAZ0 Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 14:04:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D535BB7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This was discussed in Honolulu, and the agreement was that the s= etup attribute will NOT be used to determine who initiates the SCTP associa= tion. Instead BOTH endpoints are supposed to trigger the initiation. The se= tup attribute will only be used to determine the TLS role. 2 use cases: 1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS. The sctp port usage needs be clarified indicating it is the server port, = not the client port. Yes. 2.Native SCTP: I believe a=3Dsetup is for SCTP association. When a=3Dsetup:passive/actpass is used the sctp port usage needs to be clar= ified indicating it is the server port. When a=3Dsetup:active is used port = must be 9 (discard port). This needs clarification as well. Both sides trying to open SCTP simultaneously is probably ok because SCTP a= llows them to be converted into single association if there are simultaneou= s INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. = This is per RFC 4960 section 5.2.1 and 5.2.2 . But the key here is same 4-tuple, which means the client must use same **se= rver port** to initiate an outgoing association. If this is not done then, = the end result will be 2 SCTP associations setup and/or one of them may be = rejected and may depend on implementation. So, I believe some clarifications are needed in this area. So, assuming we don't use (per the agreement in Honolulu) a=3Ds= etup for the SCTP association, we would need to mandate (or, at least say S= HOULD) usage of the server port also to initiate an outgoing association, i= n order to avoid 2 SCTP associations. But, that also applies to SCTP over DTLS, doesn't it? Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above de= scription under "native SCTP" instead of "SCTP over DTLS". For native SCTP,= as discussed, a=3Dsetup negotiation determines which side initiates SCTP a= ssociation, so the semantics are very clear here. The idea was to not use a=3Dsetup for any "type" of SCTP, inclu= ding native SCTP. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D535BB7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

<Christer> This was discussed in Honol=
ulu, and the agreement was that the setup attribute will NOT be used to det=
ermine who initiates the SCTP association. Instead BOTH endpoints are suppo=
sed to trigger the initiation. The setup attribute will only be used to det=
ermine the TLS role.
<Raju2>
2 use cases:
1.SCTP over DTLS: For this yes, a=3Dsetu=
p is for DTLS.
  The sctp port usage needs be clar=
ified indicating it is the server port, not the client port.
 
<Christer2> Yes.=

 
 
2.Native SCTP: I believe a=3Dsetup is fo=
r SCTP association.
When a=3Dsetup:passive/actpass is used t=
he sctp port usage needs to be clarified indicating it is the server port. =
When a=3Dsetup:active is used port must be 9 (discard port). This needs cla=
rification as well.
Both sides trying to open SCTP simultane=
ously is probably ok because SCTP allows them to be converted into single a=
ssociation if there are simultaneous INITs (or INIT chunk received in ESTAB=
LISHED state) on the same 4-tuple. This is per RFC 4960 section 5.2.1 and 5.2.2 .
But the key here is same 4-tuple, which =
means the client must use same **server port** to initiate an outgoing asso=
ciation. If this is not done then, the end result will be 2 SCTP associatio=
ns setup and/or one of them may be rejected and may depend on implementatio=
n.
So, I believe some clarifications are ne=
eded in this area.
 
<Christer2> So, assuming we don’=
t use (per the agreement in Honolulu) a=3Dsetup for the SCTP association, w=
e would need to mandate (or, at least say SHOULD) usage of the server port =
also to initiate an outgoing association, in order to avoid 2 SCTP associat=
ions.
 
But, that also applies to SCTP over DTLS, do=
esn’t it?
<Raju3>
Sorry, it actually ONLY applies to SC=
TP over DTLS. I misplaced the above description under “native SCTP=
221; instead of “SCTP over DTLS”. For native SCTP, as discussed=
, a=3Dsetup negotiation determines which side initiates SCTP association, s=
o the semantics are very clear here.
 

<Christer3> The idea was to not use a=
=3Dsetup for any “type” of SCTP, including native SCTP.


 


Regards,


 


Christer
--_000_7594FB04B1934943A5C02806D1A2204B1D535BB7ESESSMB209erics_-- From nobody Tue Nov 25 06:26:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841A41A1AA6 for ; Tue, 25 Nov 2014 06:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0IqrhrQ3BiC for ; Tue, 25 Nov 2014 06:26:51 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079611A1AA0 for ; Tue, 25 Nov 2014 06:26:51 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id E41BBB2C2B3B5; Tue, 25 Nov 2014 14:26:46 +0000 (GMT) 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 sAPEQgfP024421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 15:26:48 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 15:26:41 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAAABS24gAABbYpAAAHFTwAAAfp9A Date: Tue, 25 Nov 2014 14:26:40 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC36940A@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC36940AFR711WXCHMBA03zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Jxh19aWF1mRZ_2ioyaX9-yLBAns Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 14:26:55 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC36940AFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To SCTP (RFC 4960), - and without consideration of SCTP protocol object rep= resenation in SDP: RFC 4960 defines actually (SCTP)-transport-connection-endpoints (using OSI-= BRM terminology), equated as SCTP endpoint. Whereas an (SCTP)-endpoint usually relates to the SCTP protocol implementat= ion in an open system (terminal, gateway, etc). An (SCTP)-endpoint is always able to instantiate multiple (SCTP)-connection= -endpoint or (SCTP)-transport-connection-endpoint objects (given that the o= pen systems provides multihomed IP host support). Hence, there's a 1:N relation between (SCTP)-endpoint and (SCTP)-(transport= )-connection-endpoints. Consequently, an SDP media description ( c/m lines) indicates an (SCTP)-tra= nsport-connection-endpoint object, but not an (SCTP)-endpoint. Fairly precise and clear in OSI-BRM terms (but you might be in trouble if y= ou equate both). -Albrecht From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Dienstag, 25. November 2014 15:04 To: Makaraju, Maridi Raju (Raju); mmusic@ietf.org Subject: Re: [MMUSIC] Single SCTP usage per SDP session? Hi, This was discussed in Honolulu, and the agreement was that the s= etup attribute will NOT be used to determine who initiates the SCTP associa= tion. Instead BOTH endpoints are supposed to trigger the initiation. The se= tup attribute will only be used to determine the TLS role. 2 use cases: 1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS. The sctp port usage needs be clarified indicating it is the server port, = not the client port. Yes. 2.Native SCTP: I believe a=3Dsetup is for SCTP association. When a=3Dsetup:passive/actpass is used the sctp port usage needs to be clar= ified indicating it is the server port. When a=3Dsetup:active is used port = must be 9 (discard port). This needs clarification as well. Both sides trying to open SCTP simultaneously is probably ok because SCTP a= llows them to be converted into single association if there are simultaneou= s INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. = This is per RFC 4960 section 5.2.1 and 5.2.2 . But the key here is same 4-tuple, which means the client must use same **se= rver port** to initiate an outgoing association. If this is not done then, = the end result will be 2 SCTP associations setup and/or one of them may be = rejected and may depend on implementation. So, I believe some clarifications are needed in this area. So, assuming we don't use (per the agreement in Honolulu) a=3Ds= etup for the SCTP association, we would need to mandate (or, at least say S= HOULD) usage of the server port also to initiate an outgoing association, i= n order to avoid 2 SCTP associations. But, that also applies to SCTP over DTLS, doesn't it? Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above de= scription under "native SCTP" instead of "SCTP over DTLS". For native SCTP,= as discussed, a=3Dsetup negotiation determines which side initiates SCTP a= ssociation, so the semantics are very clear here. The idea was to not use a=3Dsetup for any "type" of SCTP, inclu= ding native SCTP. Regards, Christer --_000_786615F3A85DF44AA2A76164A71FE1AC36940AFR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

T= o SCTP (RFC 4960), - and without consideration of SCTP protocol object repr= esenation in SDP:

<= o:p> 

R= FC 4960 defines actually (SCTP)-transport-connection-endpoints (using OSI-BRM terminology), e= quated as SCTP endpoint.

W= hereas an (SCTP)-endpoint usually relates to the SCTP protocol implementation<= /i> in an open system (terminal, gateway, etc).

A= n (SCTP)-endpoint is always able to instantiate multiple (SCTP)-connection-endpoint or (SCTP)-transpo= rt-connection-endpoint objects (given that the open systems provides mu= ltihomed IP host support).

<= o:p> 

H= ence, there’s a 1:N relation between (SCTP)-endpoint and (SCTP)-(tran= sport)-connection-endpoints.

<= o:p> 

C= onsequently, an SDP media description ( c/m lines) indicates an (SCTP)-tran= sport-connection-endpoint object, but not an (SCTP)-endpoint.

F= airly precise and clear in OSI-BRM terms (but you might be in trouble if yo= u equate both).

<= o:p> 

-= Albrecht

<= o:p> 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Dienstag, 25. November 2014 15:04
To: Makaraju, Maridi Raju (Raju); mmusic@ietf.org
Subject: Re: [MMUSIC] Single SCTP usage per SDP session?<= /span>

 

Hi,

&n= bsp;

<Christer> This was dis=
cussed in Honolulu, and the agreement was that the setup attribute will NOT=
 be used to determine who initiates the SCTP association. Instead BOTH endp=
oints are supposed to trigger the initiation. The setup attribute will only=
 be used to determine the TLS role.
<Raju2>
2 use cases:
1.SCTP over DTLS: For thi=
s yes, a=3Dsetup is for DTLS.
  The sctp port usag=
e needs be clarified indicating it is the server port, not the client port.=

 <=
/i>
<Christer2> Yes.
 <=
/i>
 <=
/i>
2.Native SCTP: I believe =
a=3Dsetup is for SCTP association.
When a=3Dsetup:passive/ac=
tpass is used the sctp port usage needs to be clarified indicating it is th=
e server port. When a=3Dsetup:active is used port must be 9 (discard port).=
 This needs clarification as well.
Both sides trying to open=
 SCTP simultaneously is probably ok because SCTP allows them to be converte=
d into single association if there are simultaneous INITs (or INIT chunk re=
ceived in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 sect=
ion 5.2.1 =
and 5.2.2 =
.
But the key here is same =
4-tuple, which means the client must use same **server port** to initiate a=
n outgoing association. If this is not done then, the end result will be 2 =
SCTP associations setup and/or one of them may be rejected and may depend o=
n implementation.
So, I believe some clarif=
ications are needed in this area.
 <=
/i>
<Christer2> So, assumin=
g we don’t use (per the agreement in Honolulu) a=3Dsetup for the SCTP=
 association, we would need to mandate (or, at least say SHOULD) usage of t=
he server port also to initiate an outgoing association, in order to avoid =
2 SCTP associations.
 <=
/pre>

But, that also applies to SCT=
P over DTLS, doesn’t it?


<Raju3>


Sorry, it actually ONL=
Y applies to SCTP over DTLS. I misplaced the above description under “=
;native SCTP” instead of “SCTP over DTLS”. For native SCT=
P, as discussed, a=3Dsetup negotiation determines which side initiates SCTP=
 association, so the semantics are very clear here.


 


<Christer3> The idea wa=
s to not use a=3Dsetup for any “type” of SCTP, including native=
 SCTP.


 <=
/pre>

Regards,


 <=
/pre>

Christer
--_000_786615F3A85DF44AA2A76164A71FE1AC36940AFR711WXCHMBA03zeu_-- From nobody Tue Nov 25 07:05:14 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED711A6F64 for ; Tue, 25 Nov 2014 07:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy6gTIM3DTWY for ; Tue, 25 Nov 2014 07:05:10 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBF91A6FA8 for ; Tue, 25 Nov 2014 07:05:10 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 90D569D900A99; Tue, 25 Nov 2014 15:05:05 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sAPF4rWQ007985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 10:05:07 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 10:04:56 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg Thread-Topic: Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAAABS24gAABbYpAAAHFTwAACJ/IA Date: Tue, 25 Nov 2014 15:04:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E63C11DUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/bfP2szelVC_spAEpkGruM7OLtE0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:05:13 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E63C11DUS70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline comments marked under 2.Native SCTP: I believe a=3Dsetup is for SCTP association. When a=3Dsetup:passive/actpass is used the sctp port usage needs to be clar= ified indicating it is the server port. When a=3Dsetup:active is used port = must be 9 (discard port). This needs clarification as well. Both sides trying to open SCTP simultaneously is probably ok because SCTP a= llows them to be converted into single association if there are simultaneou= s INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. = This is per RFC 4960 section 5.2.1 and 5.2.2 . But the key here is same 4-tuple, which means the client must use same **se= rver port** to initiate an outgoing association. If this is not done then, = the end result will be 2 SCTP associations setup and/or one of them may be = rejected and may depend on implementation. So, I believe some clarifications are needed in this area. So, assuming we don't use (per the agreement in Honolulu) a=3Ds= etup for the SCTP association, we would need to mandate (or, at least say S= HOULD) usage of the server port also to initiate an outgoing association, i= n order to avoid 2 SCTP associations. But, that also applies to SCTP over DTLS, doesn't it? Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above de= scription under "native SCTP" instead of "SCTP over DTLS". For native SCTP,= as discussed, a=3Dsetup negotiation determines which side initiates SCTP a= ssociation, so the semantics are very clear here. The idea was to not use a=3Dsetup for any "type" of SCTP, inclu= ding native SCTP. I see. The SCTP draft-ietf-mmusic-sctp-sdp is obviously not yet updated as = it still has a=3Dsetup based semantics. BR Raju Regards, Christer --_000_E1FE4C082A89A246A11D7F32A95A17828E63C11DUS70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline comm= ents marked under <Raju4>

 

2.Native SCTP: I believe a=3Dsetup is fo=
r SCTP association.
When a=3Dsetup:passive/actpass is used t=
he sctp port usage needs to be clarified indicating it is the server port. =
When a=3Dsetup:active is used port must be 9 (discard port). This needs cla=
rification as well.
Both sides trying to open SCTP simultane=
ously is probably ok because SCTP allows them to be converted into single a=
ssociation if there are simultaneous INITs (or INIT chunk received in ESTAB=
LISHED state) on the same 4-tuple. This is per RFC 4960 section 5.2.1 and 5.2.2 .
But the key here is same 4-tuple, which =
means the client must use same **server port** to initiate an outgoing asso=
ciation. If this is not done then, the end result will be 2 SCTP associatio=
ns setup and/or one of them may be rejected and may depend on implementatio=
n.
So, I believe some clarifications are ne=
eded in this area.
 
<Christer2> So, assuming we don’=
t use (per the agreement in Honolulu) a=3Dsetup for the SCTP association, w=
e would need to mandate (or, at least say SHOULD) usage of the server port =
also to initiate an outgoing association, in order to avoid 2 SCTP associat=
ions.
 
But, that also applies to SCTP over DTLS, do=
esn’t it?
<Raju3>
Sorry, it actually ONLY applies to SC=
TP over DTLS. I misplaced the above description under “native SCTP=
221; instead of “SCTP over DTLS”. For native SCTP, as discussed=
, a=3Dsetup negotiation determines which side initiates SCTP association, s=
o the semantics are very clear here.
 

<Christer3> The idea was to not use a=
=3Dsetup for any “type” of SCTP, including native SCTP.


<Raju4>


I see. The SCTP draft-ietf-mmusic-sct=
p-sdp is obviously not yet updated as it still has a=3Dsetup based semantic=
s.


</Raju4><=
/b>


 

BR


Raju


 


Regards,


 


Christer
--_000_E1FE4C082A89A246A11D7F32A95A17828E63C11DUS70UWXCHMBA02z_-- From nobody Tue Nov 25 07:30:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226921A3BA4 for ; Tue, 25 Nov 2014 07:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGl3Ehv_uU0d for ; Tue, 25 Nov 2014 07:30:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6687F1A3BA1 for ; Tue, 25 Nov 2014 07:30:17 -0800 (PST) Received: from Orochi.local ([38.100.151.157]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAPFUAhj046308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 09:30:10 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [38.100.151.157] claimed to be Orochi.local Message-ID: <5474A07C.5030701@nostrum.com> Date: Tue, 25 Nov 2014 09:30:04 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christer Holmberg , "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------010006070209090909010604" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZtGnLBj84v2IzPUT9bSnx1R-Ze4 Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:30:21 -0000 This is a multi-part message in MIME format. --------------010006070209090909010604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I want to go on record to say that this is the least readable quoting/reply style I've ever had to deal with in my life. I lost track of the conversation about three messages ago. /a On 11/25/14 08:03, Christer Holmberg wrote: > > Hi, > > / This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role./ > *//* > /2 use cases:/ > /1.SCTP over DTLS: For this yes, a=setup is for DTLS./ > / The sctp port usage needs be clarified indicating it is the server port, not the client port./ > / / > / Yes./ > / / > / / > /2.Native SCTP: I believe a=setup is for SCTP association./ > /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./ > /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1 and5.2.2 ./ > /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./ > /So, I believe some clarifications are needed in this area./ > / / > / So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./ > / / > /But, that also applies to SCTP over DTLS, doesn’t it?/ > *//* > */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP†instead of “SCTP over DTLSâ€. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here./* > */ /* > / The idea was to not use a=setup for any “type†of SCTP, including native SCTP./ > / / > /Regards,/ > / / > /Christer/ > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------010006070209090909010604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I want to go on record to say that this is the least readable quoting/reply style I've ever had to deal with in my life. I lost track of the conversation about three messages ago.

/a


On 11/25/14 08:03, Christer Holmberg wrote:

Hi,

 

<Christer> This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role.
<Raju2>
2 use cases:
1.SCTP over DTLS: For this yes, a=setup is for DTLS.
  The sctp port usage needs be clarified indicating it is the server port, not the client port.
 
<Christer2> Yes.
 
 
2.Native SCTP: I believe a=setup is for SCTP association.
When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well.
Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section 5.2.1 and 5.2.2 .
But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation.
So, I believe some clarifications are needed in this area.
 
<Christer2> So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations.
 
But, that also applies to SCTP over DTLS, doesn’t it?
<Raju3>
Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP†instead of “SCTP over DTLSâ€. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here.
 
<Christer3> The idea was to not use a=setup for any “type†of SCTP, including native SCTP.
 
Regards,
 
Christer


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

--------------010006070209090909010604-- From nobody Tue Nov 25 07:44:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C81A6F81 for ; Tue, 25 Nov 2014 07:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tkY1SVPuxCg for ; Tue, 25 Nov 2014 07:44:03 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFC41A6FCB for ; Tue, 25 Nov 2014 07:44:02 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E265BC1A19735 for ; Tue, 25 Nov 2014 15:43:57 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sAPFi0Vc015953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Nov 2014 16:44:01 +0100 Received: from [149.204.69.247] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 25 Nov 2014 16:43:58 +0100 Message-ID: <5474A3BD.6080206@alcatel-lucent.com> Date: Tue, 25 Nov 2014 16:43:57 +0100 From: Juergen Stoetzer-Bradler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Content-Type: multipart/alternative; boundary="------------090204090409050802080100" X-Originating-IP: [135.239.27.39] Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-P1pt7GH4JcWYPk1k5X3nPxKsvA Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg - "label" optional in a=dcmap? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:44:05 -0000 --------------090204090409050802080100 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi, The ABNF rules in draft-ejzak-mmusic-data-channel-sdpneg-02's section 5.1.1.1 allow the "label" parameter to _not_ being present in a=dcmap attribute lines. However, the "label" related description in section 5.1.1.2 says: "...Label is a mandatory parameter. ...". Recent CLUE related discussions indicate that there may be use cases, where applications may not need to convey data channel label values in draft-ejzak-mmusic-data-channel-sdpneg based SDP offers or answers. Therefore we would propose to actually make the "label" parameter optional in a=dcmap attribute lines and to replace section 5.1.1.2's sentence "Label is a mandatory parameter" with "Label is an optional parameter. If the label parameter is not present, then its value defaults to the empty string. Note: The empty string may also be explicitly used as "label" value, such that label="" is equivalent to the "label" parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's "Label" value to be an empty string." Would this be agreeable? Thanks, Juergen JSB_email_signature --------------090204090409050802080100 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi,

The ABNF rules in draft-ejzak-mmusic-data-channel-sdpneg-02's section  5.1.1.1 allow the "label" parameter to _not_ being present in a=dcmap attribute lines.
However, the "label" related description in section 5.1.1.2 says: "...Label is a mandatory parameter. ...".

Recent CLUE related discussions indicate that there may be use cases, where applications may not need to convey data channel label values in draft-ejzak-mmusic-data-channel-sdpneg based SDP offers or answers.

Therefore we would propose to actually make the "label" parameter optional in a=dcmap attribute lines and to replace section 5.1.1.2's sentence "Label is a mandatory parameter" with

    "Label is an optional parameter. If the label parameter is not present, then its value defaults to the empty string.

     Note: The empty string may also be explicitly used as "label" value, such that label="" is equivalent to the "label" parameter not being present at all.
     [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's "Label" value to be an empty string."

Would this be agreeable?

Thanks,
Juergen
JSB_email_signature
--------------090204090409050802080100-- From nobody Tue Nov 25 08:49:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEB11ACE13 for ; Tue, 25 Nov 2014 08:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT1iI7O4U_5c for ; Tue, 25 Nov 2014 08:49:50 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFE11ACE0A for ; Tue, 25 Nov 2014 08:49:50 -0800 (PST) Received: from [130.209.247.112] (port=52739 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XtJJE-0002p2-76 for mmusic@ietf.org; Tue, 25 Nov 2014 16:49:48 +0000 From: Colin Perkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 25 Nov 2014 16:49:45 +0000 To: mmusic Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cy-v36Auc9BknFWWBZyOWGu3vNI Subject: [MMUSIC] Comments on 4566bis-iana-updates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 16:49:52 -0000 Hi, The chairs asked me to review = draft-begen-mmusic-rfc4566bis-iana-updates-00. This looks okay. My only = comment is that it would be better to consider what addrtype is usable = for a particular nettype, whereas the draft seems to consider nettypes = in the context of addrtypes. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Tue Nov 25 10:55:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407B1A877A for ; Tue, 25 Nov 2014 10:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmTUsAvKPkAC for ; Tue, 25 Nov 2014 10:54:16 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087601A1A67 for ; Tue, 25 Nov 2014 10:54:15 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with comcast id Kuta1p00452QWKC01uuFiq; Tue, 25 Nov 2014 18:54:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id KuuE1p00g3Ge9ey01uuFcQ; Tue, 25 Nov 2014 18:54:15 +0000 Message-ID: <5474D056.3090408@alum.mit.edu> Date: Tue, 25 Nov 2014 13:54:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> <5474A07C.5030701@nostrum.com> In-Reply-To: <5474A07C.5030701@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416941655; bh=ZECEc4L31lqAap4UGZ4Z2OKpJEEyvmqNPsD+F2Ow/0E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bUNYym//mHx4FNbbxoi1uKDxVjIiQbCHCudT+HdLTKkQ/tEz7wpLK40TiMb6OsCIE 73cCKC2IX4owNA0o2Q9Ru4HboELK8q9LnjbH58Fj8/j2AeEJVQZ6Bq6DgNRDTek/XX Gn5Zy3fkr4we/CHEC88s//Mi9Iwm6ch4vxQomXzs6rZl0N/3mKM2vssQFJkpub/yL0 T0y9ABSGqGWuYPaDfW2aBzvdDbQWJ10BLuJAfDJaRNwQhl/BiD0cDSrDKXSIsnbqVd sTnzbapPsAA6TEZ7pSlsn4ooB6k8mGiCnYctIhcySEW4KH6iirjwKL7HoRDm8CV4T2 ID02dLuFi35Pw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/i_t9_mNH8CDpebE6i7fxtCtPzTk Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 18:54:18 -0000 On 11/25/14 10:30 AM, Adam Roach wrote: > I want to go on record to say that this is the least readable > quoting/reply style I've ever had to deal with in my life. I lost track > of the conversation about three messages ago. +1 !!! > /a > > > On 11/25/14 08:03, Christer Holmberg wrote: >> >> Hi, >> >> / This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role./ >> *//* >> /2 use cases:/ >> /1.SCTP over DTLS: For this yes, a=setup is for DTLS./ >> / The sctp port usage needs be clarified indicating it is the server port, not the client port./ >> / / >> / Yes./ >> / / >> / / >> /2.Native SCTP: I believe a=setup is for SCTP association./ >> /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./ >> /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1 and5.2.2 ./ >> /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./ >> /So, I believe some clarifications are needed in this area./ >> / / >> / So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./ >> / / >> /But, that also applies to SCTP over DTLS, doesn’t it?/ >> *//* >> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP” instead of “SCTP over DTLS”. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here./* >> */ /* >> / The idea was to not use a=setup for any “type” of SCTP, including native SCTP./ >> / / >> /Regards,/ >> / / >> /Christer/ >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Nov 25 11:05:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF5D1ACF57 for ; Tue, 25 Nov 2014 11:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_I2JhZBOKef for ; Tue, 25 Nov 2014 11:04:50 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4BC1ACEFC for ; Tue, 25 Nov 2014 11:04:49 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-11v.sys.comcast.net with comcast id Kv3f1p002516pyw01v4p2T; Tue, 25 Nov 2014 19:04:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id Kv4o1p00V3Ge9ey01v4pKT; Tue, 25 Nov 2014 19:04:49 +0000 Message-ID: <5474D2D0.3010509@alum.mit.edu> Date: Tue, 25 Nov 2014 14:04:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC36940A@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC36940A@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416942289; bh=ep1cgkrQEAf1D7alm7KtepTo8/WexmK8OwnMGe1Hx48=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MBCFy0Brh3TGyte2+14+px063ZInj/RUXW6Ybm2ES3h7VfWc1O9MQmKhpMj3y9YIp kBkZ0xIeSSA8P+Y657Nk6MBwyJQPKBvUGaXPz5wSythWe6DdUcDBApLYLE3RL2oBTL nFd0rYJjrWOUNEokzQwHIrPlFl3edTpW/WGHnze/5DfkTo9Uu+mySXwUVpHIki+6rS Cc9zAvKCmF7pBr5kDSNJX38rR8WaE7FwQhE8bKOb+cUR8e4S3KBY4+ABbO+oOnzRqc olgXtAEFKA2uAbQGYAxhx+TOD+SyRhAh2F1j6F/pFtKKq8ayAS1AZAMpDcRs4GCCm2 MgIOYuYdOWLkA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Qr8HzUKAzMyLAeYqUClFRW87n_0 Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:04:51 -0000 I've been trying to follow this thread, without much success. But I hadn't seen much said that seemed to be authoritative about SCTP until I got to this message. But without going to study 4960 I don't find the quote below to be very enlightening either. It does seem like it must be important to identify exactly what an SCTP endpoint is. It may well be that an SDP offerer or answerer might be allowed to be managing multiple SCTP endpoints. I will guess that the constraint Christer is asking about has something to do with multihomed SCTP associations, and the need to recognize that all of those are tied together. I don't know how that is expected to be done in SDP, if at all. I don't see any way within SDP to explicitly identify multiple IP address/port combinations for the same SCTP association. Perhaps if the c-line has a DNS name, and that can be resolved to multiple IP addresses? ISTM that, absent some additional bundle extensions, every SCTP m-line in an SDP offer/answer should be considered to be bound to a separate SCTP association. Thanks, Paul On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote: > To SCTP (RFC 4960), - and without consideration of SCTP protocol object > represenation in SDP: > > RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (using > OSI-BRM terminology), equated as SCTP endpoint. > > Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol > implementation/ in an open system (terminal, gateway, etc). > > An (SCTP)-endpoint is always able to /instantiate multiple > (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint > objects/ (given that the open systems provides multihomed IP host support). > > Hence, there’s a 1:N relation between (SCTP)-endpoint and > (SCTP)-(transport)-connection-endpoints. > > Consequently, an SDP media description ( c/m lines) indicates an > (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint. > > Fairly precise and clear in OSI-BRM terms (but you might be in trouble > if you equate both). > > -Albrecht > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* Dienstag, 25. November 2014 15:04 > *To:* Makaraju, Maridi Raju (Raju); mmusic@ietf.org > *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session? > > Hi, > > / This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role./ > > *//* > > /2 use cases:/ > > /1.SCTP over DTLS: For this yes, a=setup is for DTLS./ > > / The sctp port usage needs be clarified indicating it is the server port, not the client port./ > > / / > > / Yes./ > > / / > > / / > > /2.Native SCTP: I believe a=setup is for SCTP association./ > > /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./ > > /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1 and5.2.2 ./ > > /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./ > > /So, I believe some clarifications are needed in this area./ > > / / > > / So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./ > > / / > > /But, that also applies to SCTP over DTLS, doesn’t it?/ > > *//* > > */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP” instead of “SCTP over DTLS”. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here./* > > */ /* > > / The idea was to not use a=setup for any “type” of SCTP, including native SCTP./ > > / / > > /Regards,/ > > / / > > /Christer/ > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Nov 25 11:15:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C36A1ACF5D for ; Tue, 25 Nov 2014 11:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY4xGx7bixsE for ; Tue, 25 Nov 2014 11:13:58 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873D71A87DB for ; Tue, 25 Nov 2014 11:13:57 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-b8-5474d4f2d80f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1A.48.04231.2F4D4745; Tue, 25 Nov 2014 20:13:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 20:13:54 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAAABS24gAABbYpAAAHFTwAAAfp9AAAf+6AAAAmnQYw== Date: Tue, 25 Nov 2014 19:13:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53663A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC36940A@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <5474D2D0.3010509@alum.mit.edu> In-Reply-To: <5474D2D0.3010509@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53663AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje6nKyUhBpN3m1hMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG318HWQu+FVe83LqUtYHxU0IXIyeHhICJ RPfua8wQtpjEhXvr2boYuTiEBI4wSrQvfscC4SxhlLjQ+JC9i5GDg03AQqL7nzZIg4iAr8Sz x7fZQGxhoPC8Xe3MEHFLiTmf3jODlIsIZEk0rPEDCbMIqEp8vnOFCcTmBWq9/X0h1K5mVoml O5axgyQ4BXQkPr2dyghiMwId9P3UGrAGZgFxiaYvK1khDhWQWLLnPNTRohIvH/9jhajJl+h4 d50dYoGgxMmZT1gmMArPQtI+C0nZLCRlEHEDiS/vb0PZ2hLLFr5mhrD1Jbrfn2ZCFl/AyL6K UbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzB+Dm75rbuDcfVrx0OMAhyMSjy8Gz4UhwixJpYV V+YeYpTmYFES5110bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZkL141689tX8/Uzd1Q dd+GW+nqzHlTvQJUFaflGvctcew42j85J3iBVKhZysn2ibtnhD61PnShyUil7ZXanLjtPnKm Sxldt2oJzNrxX+nc38sbTezYI9fOecDKrVdpIpL2qXnh9Xsd6u3+lcLb1bdJZX3L/fi5p3+K 6NGOuSz+EyryI0S2b1RiKc5INNRiLipOBACnTBJWgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BINC7sA-WAkPnS5cJQJhT1MluTU Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:14:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53663AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Paul, My question was not about multihoming, about the fact that an SCTP endpoint= is only allowed to create a single association, which would mean that we c= ould only have one SCTP usage per SDP session. ...unless, "SCTP device" is bound to a specific address:port, in which case= an SDP body could contain multiple SCTP associations - at least if they we= re un-bundled. Within a BUNDLE group, however, it would mean that only one = SCTP association is allowed. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD25/=FD11/=FD2014 21:05 To: mmusic@ietf.org Subject: Re: [MMUSIC] Single SCTP usage per SDP session? I've been trying to follow this thread, without much success. But I hadn't seen much said that seemed to be authoritative about SCTP until I got to this message. But without going to study 4960 I don't find the quote below to be very enlightening either. It does seem like it must be important to identify exactly what an SCTP endpoint is. It may well be that an SDP offerer or answerer might be allowed to be managing multiple SCTP endpoints. I will guess that the constraint Christer is asking about has something to do with multihomed SCTP associations, and the need to recognize that all of those are tied together. I don't know how that is expected to be done in SDP, if at all. I don't see any way within SDP to explicitly identify multiple IP address/port combinations for the same SCTP association. Perhaps if the c-line has a DNS name, and that can be resolved to multiple IP addresses? ISTM that, absent some additional bundle extensions, every SCTP m-line in an SDP offer/answer should be considered to be bound to a separate SCTP association. Thanks, Paul On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote: > To SCTP (RFC 4960), - and without consideration of SCTP protocol object > represenation in SDP: > > RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (using > OSI-BRM terminology), equated as SCTP endpoint. > > Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol > implementation/ in an open system (terminal, gateway, etc). > > An (SCTP)-endpoint is always able to /instantiate multiple > (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint > objects/ (given that the open systems provides multihomed IP host support= ). > > Hence, there=92s a 1:N relation between (SCTP)-endpoint and > (SCTP)-(transport)-connection-endpoints. > > Consequently, an SDP media description ( c/m lines) indicates an > (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint. > > Fairly precise and clear in OSI-BRM terms (but you might be in trouble > if you equate both). > > -Albrecht > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* Dienstag, 25. November 2014 15:04 > *To:* Makaraju, Maridi Raju (Raju); mmusic@ietf.org > *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session? > > Hi, > > / This was discussed in Honolulu, and the agreement was that th= e setup attribute will NOT be used to determine who initiates the SCTP asso= ciation. Instead BOTH endpoints are supposed to trigger the initiation. The= setup attribute will only be used to determine the TLS role./ > > *//* > > /2 use cases:/ > > /1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS./ > > / The sctp port usage needs be clarified indicating it is the server po= rt, not the client port./ > > / / > > / Yes./ > > / / > > / / > > /2.Native SCTP: I believe a=3Dsetup is for SCTP association./ > > /When a=3Dsetup:passive/actpass is used the sctp port usage needs to be c= larified indicating it is the server port. When a=3Dsetup:active is used po= rt must be 9 (discard port). This needs clarification as well./ > > /Both sides trying to open SCTP simultaneously is probably ok because SCT= P allows them to be converted into single association if there are simultan= eous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tupl= e. This is per RFC 4960 section5.2.1 and5.2.2 = ./ > > /But the key here is same 4-tuple, which means the client must use same *= *server port** to initiate an outgoing association. If this is not done the= n, the end result will be 2 SCTP associations setup and/or one of them may = be rejected and may depend on implementation./ > > /So, I believe some clarifications are needed in this area./ > > / / > > / So, assuming we don=92t use (per the agreement in Honolulu) = a=3Dsetup for the SCTP association, we would need to mandate (or, at least = say SHOULD) usage of the server port also to initiate an outgoing associati= on, in order to avoid 2 SCTP associations./ > > / / > > /But, that also applies to SCTP over DTLS, doesn=92t it?/ > > *//* > > */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the abov= e description under =93native SCTP=94 instead of =93SCTP over DTLS=94. For = native SCTP, as discussed, a=3Dsetup negotiation determines which side init= iates SCTP association, so the semantics are very clear here./* > > */ /* > > / The idea was to not use a=3Dsetup for any =93type=94 of SCTP= , including native SCTP./ > > / / > > /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 --_000_7594FB04B1934943A5C02806D1A2204B1D53663AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Paul,

My question was not about multihoming, about the fact that an SCTP endpoint= is only allowed to create a single association, which would mean that we c= ould only have one SCTP usage per SDP session.

...unless, "SCTP device" is bound to a specific address:port, in = which case an SDP body could contain multiple SCTP associations - at least = if they were un-bundled. Within a BUNDLE group, however, it would mean that= only one SCTP association is allowed.

Regards,

Christer


Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD25= /=FD11/=FD2014 21:05
To: mmusic@ietf.org
Subject: Re: [= MMUSIC] Single SCTP usage per SDP session?

I've been trying to follow this thread, without mu= ch success. But I
hadn't seen much said that seemed to be authoritative about SCTP until I got to this message. But without going to study 4960 I don't find the
quote below to be very enlightening either.

It does seem like it must be important to identify exactly what an SCTP endpoint is. It may well be that an SDP offerer or answerer might be
allowed to be managing multiple SCTP endpoints.

I will guess that the constraint Christer is asking about has something to do with multihomed SCTP associations, and the need to recognize that all of those are tied together. I don't know how that is expected to be done in SDP, if at all. I don't see any way within SDP to explicitly
identify multiple IP address/port combinations for the same SCTP
association. Perhaps if the c-line has a DNS name, and that can be
resolved to multiple IP addresses?

ISTM that, absent some additional bundle extensions, every SCTP m-line
in an SDP offer/answer should be considered to be bound to a separate
SCTP association.

        Thanks,
        Paul

On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote:
> To SCTP (RFC 4960), - and without consideration of SCTP protocol objec= t
> represenation in SDP:
>
> RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (usi= ng
> OSI-BRM terminology), equated as SCTP endpoint.
>
> Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol
> implementation/ in an open system (terminal, gateway, etc).
>
> An (SCTP)-endpoint is always able to /instantiate multiple
> (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint > objects/ (given that the open systems provides multihomed IP host supp= ort).
>
> Hence, there=92s a 1:N relation between (SCTP)-endpoint and
> (SCTP)-(transport)-connection-endpoints.
>
> Consequently, an SDP media description ( c/m lines) indicates an
> (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoin= t.
>
> Fairly precise and clear in OSI-BRM terms (but you might be in trouble=
> if you equate both).
>
> -Albrecht
>
> *From:*mmusic [mailto:mmusi= c-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* Dienstag, 25. November 2014 15:04
> *To:* Makaraju, Maridi Raju (Raju); mmusic@ietf.org
> *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session?
>
> Hi,
>
> /<Christer> This was discussed in Honolulu, and the agreement wa= s that the setup attribute will NOT be used to determine who initiates the = SCTP association. Instead BOTH endpoints are supposed to trigger the initia= tion. The setup attribute will only be used to determine the TLS role./
>
> */<Raju2>/*
>
> /2 use cases:/
>
> /1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS./
>
> /   The sctp port usage needs be clarified indicating it is = the server port, not the client port./
>
> /  /
>
> /<Christer2> Yes./
>
> /  /
>
> /  /
>
> /2.Native SCTP: I believe a=3Dsetup is for SCTP association./
>
> /When a=3Dsetup:passive/actpass is used the sctp port usage needs to b= e clarified indicating it is the server port. When a=3Dsetup:active is used= port must be 9 (discard port). This needs clarification as well./
>
> /Both sides trying to open SCTP simultaneously is probably ok because = SCTP allows them to be converted into single association if there are simul= taneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-t= uple. This is per RFC 4960 section5.2.1  <http://to= ols.ietf.org/html/rfc4960#section-5.2.1>  and5.2.2  <http://tools.iet= f.org/html/rfc4960#section-5.2.2>  ./
>
> /But the key here is same 4-tuple, which means the client must use sam= e **server port** to initiate an outgoing association. If this is not done = then, the end result will be 2 SCTP associations setup and/or one of them m= ay be rejected and may depend on implementation./
>
> /So, I believe some clarifications are needed in this area./
>
> /  /
>
> /<Christer2> So, assuming we don=92t use (per the agreement in H= onolulu) a=3Dsetup for the SCTP association, we would need to mandate (or, = at least say SHOULD) usage of the server port also to initiate an outgoing = association, in order to avoid 2 SCTP associations./
>
> /  /
>
> /But, that also applies to SCTP over DTLS, doesn=92t it?/
>
> */<Raju3>/*
>
> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the a= bove description under =93native SCTP=94 instead of =93SCTP over DTLS=94. F= or native SCTP, as discussed, a=3Dsetup negotiation determines which side i= nitiates SCTP association, so the semantics are very clear here./*
>
> */  /*
>
> /<Christer3> The idea was to not use a=3Dsetup for any =93type= =94 of SCTP, including native SCTP./
>
> /  /
>
> /Regards,/
>
> /  /
>
> /Christer/
>
>
>
> _______________________________________________
> 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_7594FB04B1934943A5C02806D1A2204B1D53663AESESSMB209erics_-- From nobody Tue Nov 25 11:32:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D71A0367 for ; Tue, 25 Nov 2014 11:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeaWHtFVoRvx for ; Tue, 25 Nov 2014 11:30:53 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CE51ACD32 for ; Tue, 25 Nov 2014 11:30:52 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-07v.sys.comcast.net with comcast id KvWK1p00A4vw8ds01vWsve; Tue, 25 Nov 2014 19:30:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-04v.sys.comcast.net with comcast id KvWr1p00K3Ge9ey01vWrH2; Tue, 25 Nov 2014 19:30:52 +0000 Message-ID: <5474D8EB.5030209@alum.mit.edu> Date: Tue, 25 Nov 2014 14:30:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC36940A@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <5474D2D0.3010509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D53663A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53663A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416943852; bh=9bjCqnjm8LAm+cX292wei1H6AFMi8Fd7JJi0qEADXV4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KCZudLGTl4hOw6IY370nq5+wOST4JtTz0hzx+htNmwKjqiMiD5FSMDXrki/jHPHV9 gQyGU44CiC5P/GscDyqMoOf7/CXeA2GEo8mqUjIiX+KzJUYK7roEsqtQGQpFHkx8Sw TgD3Mo/hbqxTt5v76dwiz5ZywUUfZ3dYS+odAI7KFXxbNoKTn41mWgAryNXIsy/Jkp GQLuPDerGrfVzcnR1EpyvpEB28N8vBzpXHtadl6KTAB1Kewm59FVfePDIZiVaAfgHj IAPRDbVor93P57bnGyDLiKEdWEU69CIKpUx69UepmvaOPJALEx0vN3t/TwZPmySNmm 0Tur4IN3eJ2LA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PexWyY-yBbnw44eiFw7Eqoz_ukQ Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:30:54 -0000 On 11/25/14 2:13 PM, Christer Holmberg wrote: > Hi Paul, > > My question was not about multihoming, about the fact that an SCTP > endpoint is only allowed to create a single association, which would > mean that we could only have one SCTP usage per SDP session. I know your question wasn't about multihoming. I brought it up because of an inference on my part that the restriction you reference is probably related to multihoming - that different addresses will be bound to the same association rather than to different ones. That assumes there is isn't any way to distinguish the differing usages and allow them to coexist in some sensible way. > ...unless, "SCTP device" is bound to a specific address:port, in which > case an SDP body could contain multiple SCTP associations - at least if > they were un-bundled. Within a BUNDLE group, however, it would mean that > only one SCTP association is allowed. In a bundle group, with SCTPoDTLS, ISTM you could have multiple SCTP associations, each on a distinct SCTP port. I don't see any ambiguity there. But it will require added specification of how bundle works in that case. Clearly they won't be multihomed - SCTPoDTLS can't be. Thanks, Paul > Regards, > > Christer > > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý25/ý11/ý2014 21:05 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Single SCTP usage per SDP session? > > I've been trying to follow this thread, without much success. But I > hadn't seen much said that seemed to be authoritative about SCTP until I > got to this message. But without going to study 4960 I don't find the > quote below to be very enlightening either. > > It does seem like it must be important to identify exactly what an SCTP > endpoint is. It may well be that an SDP offerer or answerer might be > allowed to be managing multiple SCTP endpoints. > > I will guess that the constraint Christer is asking about has something > to do with multihomed SCTP associations, and the need to recognize that > all of those are tied together. I don't know how that is expected to be > done in SDP, if at all. I don't see any way within SDP to explicitly > identify multiple IP address/port combinations for the same SCTP > association. Perhaps if the c-line has a DNS name, and that can be > resolved to multiple IP addresses? > > ISTM that, absent some additional bundle extensions, every SCTP m-line > in an SDP offer/answer should be considered to be bound to a separate > SCTP association. > > Thanks, > Paul > > On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote: >> To SCTP (RFC 4960), - and without consideration of SCTP protocol object >> represenation in SDP: >> >> RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (using >> OSI-BRM terminology), equated as SCTP endpoint. >> >> Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol >> implementation/ in an open system (terminal, gateway, etc). >> >> An (SCTP)-endpoint is always able to /instantiate multiple >> (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint >> objects/ (given that the open systems provides multihomed IP host support). >> >> Hence, there’s a 1:N relation between (SCTP)-endpoint and >> (SCTP)-(transport)-connection-endpoints. >> >> Consequently, an SDP media description ( c/m lines) indicates an >> (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint. >> >> Fairly precise and clear in OSI-BRM terms (but you might be in trouble >> if you equate both). >> >> -Albrecht >> >> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer >> Holmberg >> *Sent:* Dienstag, 25. November 2014 15:04 >> *To:* Makaraju, Maridi Raju (Raju); mmusic@ietf.org >> *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session? >> >> Hi, >> >> / This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role./ >> >> *//* >> >> /2 use cases:/ >> >> /1.SCTP over DTLS: For this yes, a=setup is for DTLS./ >> >> / The sctp port usage needs be clarified indicating it is the server port, not the client port./ >> >> / / >> >> / Yes./ >> >> / / >> >> / / >> >> /2.Native SCTP: I believe a=setup is for SCTP association./ >> >> /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./ >> >> /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1 and5.2.2 > ./ >> >> /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./ >> >> /So, I believe some clarifications are needed in this area./ >> >> / / >> >> / So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./ >> >> / / >> >> /But, that also applies to SCTP over DTLS, doesn’t it?/ >> >> *//* >> >> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP” instead of “SCTP over DTLS”. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here./* >> >> */ /* >> >> / The idea was to not use a=setup for any “type” of SCTP, including native SCTP./ >> >> / / >> >> /Regards,/ >> >> / / >> >> /Christer/ >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Nov 25 11:44:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC1D1A1EED for ; Tue, 25 Nov 2014 11:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqkaKDexpZqX for ; Tue, 25 Nov 2014 11:42:49 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14A91A007C for ; Tue, 25 Nov 2014 11:42:48 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-e4-5474dbb61507 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5B.6A.24955.6BBD4745; Tue, 25 Nov 2014 20:42:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 20:42:46 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAHckqgAAEasKAAAOZEAAABS24gAABbYpAAAHFTwAAAfp9AAAf+6AAAAmnQY///8/iAgAAUGFs= Date: Tue, 25 Nov 2014 19:42:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53677A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC36940A@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <5474D2D0.3010509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D53663A@ESESSMB209.ericsson.se>, <5474D8EB.5030209@alum.mit.edu> In-Reply-To: <5474D8EB.5030209@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53677AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvje622yUhBp9eG1tMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG/fdT2QpOTGKsuHFkGVMD46+qLkZODgkB E4kPi3eyQNhiEhfurWfrYuTiEBI4wiix9n8PM4SzhFHi5+GF7F2MHBxsAhYS3f+0QRpEBHwl nj2+zQZiCwOF5+1qZ4aIW0rM+fQeyi6TWLGmjQnEZhFQlbj3cAtYnBeot2/fC3aI+c9ZJX4c +wc2iFNAR+Lv86fsIDYj0EXfT60Ba2YWEJdo+rKSFeJSAYkle84zQ9iiEi8f/2OFqMmX2LK3 D2qBoMTJmU9YJjAKz0LSPgtJ2SwkZRBxA4kv729D2doSyxa+Zoaw9SW6359mQhZfwMi+ilG0 OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwhg5u+a26g/HyG8dDjAIcjEo8vBs+FIcIsSaWFVfm HmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG0wirk++51KdJ10uEe27N eGHeIx6/ZDVnQWpttRzvJAvJ3qyHK+OeNB/Yypm+8X/7NfF7GpdmW75KEnzk71S67+KNvxvm baritnyasTZdcBUz05ScjOqU5fsnTuB+cUBM60uemxvbowPvP1Y27b3fYfZCLoyRxfjAxt6H X0M0//Ka9TmVC51QYinOSDTUYi4qTgQA3lAbhYICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jke3wNuDDxp__J7UcQJXYpmHXe0 Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:42:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53677AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Paul, Whether multiple SCTP associations, with different SCTP port values, are al= lowed depends on whether they are considered to belong to different SCTP en= dpoints or not. Perhaps this is the wrong WG to ask this question:) Regards, Christet Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD25/=FD11/=FD2014 21:30 To: Christer Holmberg; mmusic@ietf.o= rg Subject: Re: [MMUSIC] Single SCTP usage per SDP session? On 11/25/14 2:13 PM, Christer Holmberg wrote: > Hi Paul, > > My question was not about multihoming, about the fact that an SCTP > endpoint is only allowed to create a single association, which would > mean that we could only have one SCTP usage per SDP session. I know your question wasn't about multihoming. I brought it up because of an inference on my part that the restriction you reference is probably related to multihoming - that different addresses will be bound to the same association rather than to different ones. That assumes there is isn't any way to distinguish the differing usages and allow them to coexist in some sensible way. > ...unless, "SCTP device" is bound to a specific address:port, in which > case an SDP body could contain multiple SCTP associations - at least if > they were un-bundled. Within a BUNDLE group, however, it would mean that > only one SCTP association is allowed. In a bundle group, with SCTPoDTLS, ISTM you could have multiple SCTP associations, each on a distinct SCTP port. I don't see any ambiguity there. But it will require added specification of how bundle works in that case. Clearly they won't be multihomed - SCTPoDTLS can't be. Thanks, Paul > Regards, > > Christer > > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: =FD25/=FD11/=FD2014 21:05 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Single SCTP usage per SDP session? > > I've been trying to follow this thread, without much success. But I > hadn't seen much said that seemed to be authoritative about SCTP until I > got to this message. But without going to study 4960 I don't find the > quote below to be very enlightening either. > > It does seem like it must be important to identify exactly what an SCTP > endpoint is. It may well be that an SDP offerer or answerer might be > allowed to be managing multiple SCTP endpoints. > > I will guess that the constraint Christer is asking about has something > to do with multihomed SCTP associations, and the need to recognize that > all of those are tied together. I don't know how that is expected to be > done in SDP, if at all. I don't see any way within SDP to explicitly > identify multiple IP address/port combinations for the same SCTP > association. Perhaps if the c-line has a DNS name, and that can be > resolved to multiple IP addresses? > > ISTM that, absent some additional bundle extensions, every SCTP m-line > in an SDP offer/answer should be considered to be bound to a separate > SCTP association. > > Thanks, > Paul > > On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote: >> To SCTP (RFC 4960), - and without consideration of SCTP protocol object >> represenation in SDP: >> >> RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (using >> OSI-BRM terminology), equated as SCTP endpoint. >> >> Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol >> implementation/ in an open system (terminal, gateway, etc). >> >> An (SCTP)-endpoint is always able to /instantiate multiple >> (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint >> objects/ (given that the open systems provides multihomed IP host suppor= t). >> >> Hence, there=92s a 1:N relation between (SCTP)-endpoint and >> (SCTP)-(transport)-connection-endpoints. >> >> Consequently, an SDP media description ( c/m lines) indicates an >> (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint. >> >> Fairly precise and clear in OSI-BRM terms (but you might be in trouble >> if you equate both). >> >> -Albrecht >> >> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer >> Holmberg >> *Sent:* Dienstag, 25. November 2014 15:04 >> *To:* Makaraju, Maridi Raju (Raju); mmusic@ietf.org >> *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session? >> >> Hi, >> >> / This was discussed in Honolulu, and the agreement was that t= he setup attribute will NOT be used to determine who initiates the SCTP ass= ociation. Instead BOTH endpoints are supposed to trigger the initiation. Th= e setup attribute will only be used to determine the TLS role./ >> >> *//* >> >> /2 use cases:/ >> >> /1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS./ >> >> / The sctp port usage needs be clarified indicating it is the server p= ort, not the client port./ >> >> / / >> >> / Yes./ >> >> / / >> >> / / >> >> /2.Native SCTP: I believe a=3Dsetup is for SCTP association./ >> >> /When a=3Dsetup:passive/actpass is used the sctp port usage needs to be = clarified indicating it is the server port. When a=3Dsetup:active is used p= ort must be 9 (discard port). This needs clarification as well./ >> >> /Both sides trying to open SCTP simultaneously is probably ok because SC= TP allows them to be converted into single association if there are simulta= neous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tup= le. This is per RFC 4960 section5.2.1 and5.2.2 > ./ >> >> /But the key here is same 4-tuple, which means the client must use same = **server port** to initiate an outgoing association. If this is not done th= en, the end result will be 2 SCTP associations setup and/or one of them may= be rejected and may depend on implementation./ >> >> /So, I believe some clarifications are needed in this area./ >> >> / / >> >> / So, assuming we don=92t use (per the agreement in Honolulu)= a=3Dsetup for the SCTP association, we would need to mandate (or, at least= say SHOULD) usage of the server port also to initiate an outgoing associat= ion, in order to avoid 2 SCTP associations./ >> >> / / >> >> /But, that also applies to SCTP over DTLS, doesn=92t it?/ >> >> *//* >> >> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the abo= ve description under =93native SCTP=94 instead of =93SCTP over DTLS=94. For= native SCTP, as discussed, a=3Dsetup negotiation determines which side ini= tiates SCTP association, so the semantics are very clear here./* >> >> */ /* >> >> / The idea was to not use a=3Dsetup for any =93type=94 of SCT= P, including native SCTP./ >> >> / / >> >> /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 --_000_7594FB04B1934943A5C02806D1A2204B1D53677AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Whether multiple SCTP associations, with different SCTP port values, are al= lowed depends on whether they are considered to belong to different SCTP en= dpoints or not.

Perhaps this is the wrong WG to ask this question:)

Regards,

Christet

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD25= /=FD11/=FD2014 21:30
To: Christer Holmberg; mmusic@ietf.org
Subject: Re: [= MMUSIC] Single SCTP usage per SDP session?

On 11/25/14 2:13 PM, Christer Holmberg wrote:
> Hi Paul,
>
> My question was not about multihoming, about the fact that an SCTP
> endpoint is only allowed to create a single association, which would > mean that we could only have one SCTP usage per SDP session.

I know your question wasn't about multihoming. I brought it up because
of an inference on my part that the restriction you reference is
probably related to multihoming - that different addresses will be bound to the same association rather than to different ones. That assumes
there is isn't any way to distinguish the differing usages and allow
them to coexist in some sensible way.

> ...unless, "SCTP device" is bound to a specific address:port= , in which
> case an SDP body could contain multiple SCTP associations - at least i= f
> they were un-bundled. Within a BUNDLE group, however, it would mean th= at
> only one SCTP association is allowed.

In a bundle group, with SCTPoDTLS, ISTM you could have multiple SCTP
associations, each on a distinct SCTP port. I don't see any ambiguity
there. But it will require added specification of how bundle works in
that case. Clearly they won't be multihomed - SCTPoDTLS can't be.

        Thanks,
        Paul

> Regards,
>
> Christer
>
>
> Sent from my Windows Phone
> ----------------------------------------------------------------------= --
> From: Paul Kyzivat <mailto= :pkyzivat@alum.mit.edu>
> Sent: =FD25/=FD11/=FD2014 21:05
> To: mmusic@ietf.org <mailto:mmus= ic@ietf.org>
> Subject: Re: [MMUSIC] Single SCTP usage per SDP session?
>
> I've been trying to follow this thread, without much success. But I > hadn't seen much said that seemed to be authoritative about SCTP until= I
> got to this message. But without going to study 4960 I don't find the<= br> > quote below to be very enlightening either.
>
> It does seem like it must be important to identify exactly what an SCT= P
> endpoint is. It may well be that an SDP offerer or answerer might be > allowed to be managing multiple SCTP endpoints.
>
> I will guess that the constraint Christer is asking about has somethin= g
> to do with multihomed SCTP associations, and the need to recognize tha= t
> all of those are tied together. I don't know how that is expected to b= e
> done in SDP, if at all. I don't see any way within SDP to explicitly > identify multiple IP address/port combinations for the same SCTP
> association. Perhaps if the c-line has a DNS name, and that can be
> resolved to multiple IP addresses?
>
> ISTM that, absent some additional bundle extensions, every SCTP m-line=
> in an SDP offer/answer should be considered to be bound to a separate<= br> > SCTP association.
>
>          Thanks,
>          Paul
>
> On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote:
>> To SCTP (RFC 4960), - and without consideration of SCTP protocol o= bject
>> represenation in SDP:
>>
>> RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ = (using
>> OSI-BRM terminology), equated as SCTP endpoint.
>>
>> Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol=
>> implementation/ in an open system (terminal, gateway, etc).
>>
>> An (SCTP)-endpoint is always able to /instantiate multiple
>> (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoi= nt
>> objects/ (given that the open systems provides multihomed IP host = support).
>>
>> Hence, there=92s a 1:N relation between (SCTP)-endpoint and
>> (SCTP)-(transport)-connection-endpoints.
>>
>> Consequently, an SDP media description ( c/m lines) indicates an >> (SCTP)-transport-connection-endpoint object, but not an (SCTP)-end= point.
>>
>> Fairly precise and clear in OSI-BRM terms (but you might be in tro= uble
>> if you equate both).
>>
>> -Albrecht
>>
>> *From:*mmusic [mailto:m= music-bounces@ietf.org] *On Behalf Of *Christer
>> Holmberg
>> *Sent:* Dienstag, 25. November 2014 15:04
>> *To:* Makaraju, Maridi Raju (Raju); mmusic@ietf.org
>> *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session?
>>
>> Hi,
>>
>> /<Christer> This was discussed in Honolulu, and the agreemen= t was that the setup attribute will NOT be used to determine who initiates = the SCTP association. Instead BOTH endpoints are supposed to trigger the in= itiation. The setup attribute will only be used  to determine the TLS role./
>>
>> */<Raju2>/*
>>
>> /2 use cases:/
>>
>> /1.SCTP over DTLS: For this yes, a=3Dsetup is for DTLS./
>>
>> /   The sctp port usage needs be clarified indicating it= is the server port, not the client port./
>>
>> /  /
>>
>> /<Christer2> Yes./
>>
>> /  /
>>
>> /  /
>>
>> /2.Native SCTP: I believe a=3Dsetup is for SCTP association./
>>
>> /When a=3Dsetup:passive/actpass is used the sctp port usage needs = to be clarified indicating it is the server port. When a=3Dsetup:active is = used port must be 9 (discard port). This needs clarification as well./
>>
>> /Both sides trying to open SCTP simultaneously is probably ok beca= use SCTP allows them to be converted into single association if there are s= imultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same= 4-tuple. This is per RFC 4960 section5.2.1<http://tools.ietf.org/html/rfc4960#section= -5.2.1>  and5.2.2
> <http:= //tools.ietf.org/html/rfc4960#section-5.2.2>  ./
>>
>> /But the key here is same 4-tuple, which means the client must use= same **server port** to initiate an outgoing association. If this is not d= one then, the end result will be 2 SCTP associations setup and/or one of th= em may be rejected and may depend on implementation./
>>
>> /So, I believe some clarifications are needed in this area./
>>
>> /  /
>>
>> /<Christer2> So, assuming we don=92t use (per the agreement = in Honolulu) a=3Dsetup for the SCTP association, we would need to mandate (= or, at least say SHOULD) usage of the server port also to initiate an outgo= ing association, in order to avoid 2 SCTP associations./
>>
>> /  /
>>
>> /But, that also applies to SCTP over DTLS, doesn=92t it?/
>>
>> */<Raju3>/*
>>
>> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced t= he above description under =93native SCTP=94 instead of =93SCTP over DTLS= =94. For native SCTP, as discussed, a=3Dsetup negotiation determines which = side initiates SCTP association, so the semantics are  very clear here./*
>>
>> */  /*
>>
>> /<Christer3> The idea was to not use a=3Dsetup for any =93ty= pe=94 of SCTP, including native SCTP./
>>
>> /  /
>>
>> /Regards,/
>>
>> /  /
>>
>> /Christer/
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>>https://ww= w.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

 --_000_7594FB04B1934943A5C02806D1A2204B1D53677AESESSMB209erics_-- From nobody Tue Nov 25 12:03:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC11A701A for ; Tue, 25 Nov 2014 12:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py_xipe4OBQn for ; Tue, 25 Nov 2014 12:02:14 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1824F1A875C for ; Tue, 25 Nov 2014 12:02:13 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-08v.sys.comcast.net with comcast id Kw1n1p0075BUCh401w2DsS; Tue, 25 Nov 2014 20:02:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id Kw2C1p00R3Ge9ey01w2Dp3; Tue, 25 Nov 2014 20:02:13 +0000 Message-ID: <5474E044.5030108@alum.mit.edu> Date: Tue, 25 Nov 2014 15:02:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53595D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535B26@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D535BB7@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC36940A@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <5474D2D0.3010509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D53663A@ESESSMB209.ericsson.se>, <5474D8EB.5030209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D53677A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53677A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416945733; bh=fAu8zpW/qs2+wkRk86+T9zp7eCR2aB75YAlMbpABrfo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ss97jOGyfRT/Ja8PDtzKdt1/RfD/BuquTGKMEEdwtpuFjCKjVyPtvmWtOXwuwRiZr FQwdJYhgQTAZLA1GTAdnSREFxub8pYftSgzigeqUGZKyEx346F+KLr/mqrMC5aszM4 AEgg2nRw1ncIaBw9lBJk+DyZao+IXgaihkqL82i9pgwcJeeliQfWSwTBbsROT0hv+T Hziog6EpZjJbFniQrbIlPcjusgMCZVMCqUWOnuNNKGtiv2DxPAm71DiDgm4nOCpRhh ZqmKJhKQkAtBQr2CySIHCnDc05IBd+2idxyHLD1UO93NXHZxvk9Qa5+8vKrQKIcR0c otBp2tvIdtHvQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/WhbWYkVY3PU9Dpu5HF_84CNp5Wo Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 20:02:16 -0000 On 11/25/14 2:42 PM, Christer Holmberg wrote: > Hi Paul, > > Whether multiple SCTP associations, with different SCTP port values, are > allowed depends on whether they are considered to belong to different > SCTP endpoints or not. > > Perhaps this is the wrong WG to ask this question:) Probably. Thanks, Paul > Regards, > > Christet > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý25/ý11/ý2014 21:30 > To: Christer Holmberg ; > mmusic@ietf.org > Subject: Re: [MMUSIC] Single SCTP usage per SDP session? > > On 11/25/14 2:13 PM, Christer Holmberg wrote: >> Hi Paul, >> >> My question was not about multihoming, about the fact that an SCTP >> endpoint is only allowed to create a single association, which would >> mean that we could only have one SCTP usage per SDP session. > > I know your question wasn't about multihoming. I brought it up because > of an inference on my part that the restriction you reference is > probably related to multihoming - that different addresses will be bound > to the same association rather than to different ones. That assumes > there is isn't any way to distinguish the differing usages and allow > them to coexist in some sensible way. > >> ...unless, "SCTP device" is bound to a specific address:port, in which >> case an SDP body could contain multiple SCTP associations - at least if >> they were un-bundled. Within a BUNDLE group, however, it would mean that >> only one SCTP association is allowed. > > In a bundle group, with SCTPoDTLS, ISTM you could have multiple SCTP > associations, each on a distinct SCTP port. I don't see any ambiguity > there. But it will require added specification of how bundle works in > that case. Clearly they won't be multihomed - SCTPoDTLS can't be. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> >> Sent from my Windows Phone >> ------------------------------------------------------------------------ >> From: Paul Kyzivat >> Sent: ý25/ý11/ý2014 21:05 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] Single SCTP usage per SDP session? >> >> I've been trying to follow this thread, without much success. But I >> hadn't seen much said that seemed to be authoritative about SCTP until I >> got to this message. But without going to study 4960 I don't find the >> quote below to be very enlightening either. >> >> It does seem like it must be important to identify exactly what an SCTP >> endpoint is. It may well be that an SDP offerer or answerer might be >> allowed to be managing multiple SCTP endpoints. >> >> I will guess that the constraint Christer is asking about has something >> to do with multihomed SCTP associations, and the need to recognize that >> all of those are tied together. I don't know how that is expected to be >> done in SDP, if at all. I don't see any way within SDP to explicitly >> identify multiple IP address/port combinations for the same SCTP >> association. Perhaps if the c-line has a DNS name, and that can be >> resolved to multiple IP addresses? >> >> ISTM that, absent some additional bundle extensions, every SCTP m-line >> in an SDP offer/answer should be considered to be bound to a separate >> SCTP association. >> >> Thanks, >> Paul >> >> On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote: >>> To SCTP (RFC 4960), - and without consideration of SCTP protocol object >>> represenation in SDP: >>> >>> RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (using >>> OSI-BRM terminology), equated as SCTP endpoint. >>> >>> Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol >>> implementation/ in an open system (terminal, gateway, etc). >>> >>> An (SCTP)-endpoint is always able to /instantiate multiple >>> (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint >>> objects/ (given that the open systems provides multihomed IP host support). >>> >>> Hence, there’s a 1:N relation between (SCTP)-endpoint and >>> (SCTP)-(transport)-connection-endpoints. >>> >>> Consequently, an SDP media description ( c/m lines) indicates an >>> (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint. >>> >>> Fairly precise and clear in OSI-BRM terms (but you might be in trouble >>> if you equate both). >>> >>> -Albrecht >>> >>> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer >>> Holmberg >>> *Sent:* Dienstag, 25. November 2014 15:04 >>> *To:* Makaraju, Maridi Raju (Raju); mmusic@ietf.org >>> *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session? >>> >>> Hi, >>> >>> / This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be usedto determine the TLS role./ >>> >>> *//* >>> >>> /2 use cases:/ >>> >>> /1.SCTP over DTLS: For this yes, a=setup is for DTLS./ >>> >>> / The sctp port usage needs be clarified indicating it is the server port, not the client port./ >>> >>> / / >>> >>> / Yes./ >>> >>> / / >>> >>> / / >>> >>> /2.Native SCTP: I believe a=setup is for SCTP association./ >>> >>> /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./ >>> >>> /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1 and5.2.2 >> ./ >>> >>> /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./ >>> >>> /So, I believe some clarifications are needed in this area./ >>> >>> / / >>> >>> / So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./ >>> >>> / / >>> >>> /But, that also applies to SCTP over DTLS, doesn’t it?/ >>> >>> *//* >>> >>> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP” instead of “SCTP over DTLS”. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here./* >>> >>> */ /* >>> >>> / The idea was to not use a=setup for any “type” of SCTP, including native SCTP./ >>> >>> / / >>> >>> /Regards,/ >>> >>> / / >>> >>> /Christer/ >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>>https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Nov 25 14:06:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FA71A7003 for ; Tue, 25 Nov 2014 14:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OatiIf5FVJFV for ; Tue, 25 Nov 2014 14:03:51 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD29E1A6FD2 for ; Tue, 25 Nov 2014 14:03:50 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-03v.sys.comcast.net with comcast id Ky3M1p00452QWKC01y3qsU; Tue, 25 Nov 2014 22:03:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id Ky3p1p00j3Ge9ey01y3qxE; Tue, 25 Nov 2014 22:03:50 +0000 Message-ID: <5474FCC5.9000401@alum.mit.edu> Date: Tue, 25 Nov 2014 17:03:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5474A3BD.6080206@alcatel-lucent.com> In-Reply-To: <5474A3BD.6080206@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416953030; bh=Y8f1hazYkybXBg13xFIeXRGqoJtvw+JfXGx19zPUPqM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LTWEFJV/Mt5l71q3lIoVdtuTuSNw8cWOb+1v10vSKc90p/4RUGp2ewBnG34mKcsye d48k6ZC3sikhebfMAbM8eVe1vN1azgqri2Hd68l6yXLOOAiFagn/L1rBPcB5FRYikb e2EFqo+NdUDAYqpVqDq9YX9Qk1Onbm4zH0d4Y/lXPxCISuX/o9sppV7iJP+yGXMksj sTH0n/3NKekFuz0maqp767p40m0Ijc7XZZsFC1mxxTOYWi7nm4KaMYVOFw/OmTl3fX 7JkH+dCSVx6q5UM9ywYdcaIjP8lUab13PZJiv/KRBjckxMW7v+TJFxQ9JWmHoHdNg2 6lxwc3sZRsunQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/qtA63GpobPpbIIbYX3lOJAnH_gQ Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg - "label" optional in a=dcmap? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 22:03:52 -0000 Sounds reasonable to me. On 11/25/14 10:43 AM, Juergen Stoetzer-Bradler wrote: > Hi, > > The ABNF rules in draft-ejzak-mmusic-data-channel-sdpneg-02's section > 5.1.1.1 allow the "label" parameter to _not_ being present in a=dcmap > attribute lines. > However, the "label" related description in section 5.1.1.2 says: > "...Label is a mandatory parameter. ...". > > Recent CLUE related discussions indicate that there may be use cases, > where applications may not need to convey data channel label values in > draft-ejzak-mmusic-data-channel-sdpneg based SDP offers or answers. > > Therefore we would propose to actually make the "label" parameter > optional in a=dcmap attribute lines and to replace section 5.1.1.2's > sentence "Label is a mandatory parameter" with > > "Label is an optional parameter. If the label parameter is not > present, then its value defaults to the empty string. > > Note: The empty string may also be explicitly used as "label" value, > such that label="" is equivalent to the "label" parameter not being > present at all. > [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's > "Label" value to be an empty string." > > Would this be agreeable? > > Thanks, > Juergen > JSB_email_signature > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Nov 26 01:08:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880261A6FED for ; Wed, 26 Nov 2014 01:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-NhZrZYEa_I for ; Wed, 26 Nov 2014 01:07:58 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6541A0056 for ; Wed, 26 Nov 2014 01:07:57 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-77-5475986b65f6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.AB.04231.B6895745; Wed, 26 Nov 2014 10:07:55 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.226]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 10:07:55 +0100 From: Salvatore Loreto To: Christer Holmberg Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AQHQCVh2RQ9HT1LDRYu/Q2dfZ4TTzA== Date: Wed, 26 Nov 2014 09:07:54 +0000 Message-ID: <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D534E7B@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.148] Content-Type: multipart/alternative; boundary="_000_2649C0564D864448B71FA42954E1BF49ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rjd7RmmIweIeU4upyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEro3N5F2vBhuiKmevvsjYwXvDtYuTkkBAwkVi9aj0zhC0mceHe ejYQW0jgCKPEqSvGXYxcQPYSRokL02eygiTYBMwknj/cAtYgAmRf/9zL1MXIwcEsoC5xdXEQ SFhYwELi/4WVTBAllhJzPr2HKteTWHW3hwXEZhFQlXi9+SQjSCuvgL3EprYgiLW+EnP+bQQ7 gVPAT+L15KlgrYxAp30/tQZsJLOAuMStJ/OZIE4WkFiy5zzU+aISLx//Y4WwlSQalzxhhahP llgy4zmYzSsgKHFy5hOWCYyis5CMmoWkbBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIbv5xlhLCt JRa/+8qOrGYBI8cqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMB4O7jlt+4OxtWvHQ8xCnAw KvHwGjiVhgixJpYVV+YeYpTmYFES5110bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsa5 x41O/fjzpeXU/2cHNLqe7ku327Xo3rdX/C9ms7IG2eXdmLpwY6+ZZ/KBJJ0n2//n66YoT3b8 UH764u2fMq8+Wv2aeODtn3tZgczzzN/91Kr+ud7rnEHst0mvxNKlAtMXf7eSySmPPLDW42mB +iMGvrP3DFkezu1ydhCa2hiz99OJ5gu8ihULlViKMxINtZiLihMBor+rY5gCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9NTd029Mv3s1ND29K6MaW5V9vLc Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 09:08:01 -0000 --_000_2649C0564D864448B71FA42954E1BF49ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi there, in order to provide a clear and readable answer I am answering directly the= first mail of the thread. See in line br Salvatore On Nov 25, 2014, at 10:33 AM, Christer Holmberg > wrote: Hi, Hopefully there are some SCTP experts in da hause that can clarify the foll= owing: Previously, in the SCTP-SDP discussions, we have agreed that for a given SC= TP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g.= a webrtc-datachannel). So, if one wants multiple usages, one needs to establish multiple associati= ons, using multiple m- lines. BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one = SCTP association between them at any given time. Not exactly sure why, but = that is what the text says=85 =93SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state infor= mation including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association = can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT = have more than one SCTP association between them at any given ti= me.=94 That is not a problem. As it has also already suggested it is enough to use a different port numbe= r on one side. Now, does that mean that, for a given SDP session, we can only have a singl= e SCTP m- line (read: single SCTP usage)? For WebRTC usage that is probably enough, as we use SCTP only for the data = channel, but in general=85 note also that in https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-en= caps-06 we already have the following text that implies that is possible to have mu= ltiple SCTP associations between two endpoints o Multiple SCTP associations MAY be multiplexed over a single DTLS connection. The SCTP port numbers are used for multiplexing and demultiplexing the SCTP associations carried over a single DTLS connection. I hope it helps to clarify the issue. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_2649C0564D864448B71FA42954E1BF49ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi there,

in order to provide a clear and readable answer I am answering directl= y the first mail of the thread.
See in line

br
Salvatore


On Nov 25, 2014, at 10:33 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrot= e:

Hi,
 
Hopefully there are some SCTP experts in da hause that can clarify the foll= owing:
 
Previously, in the SCTP-SDP discussions, we have agreed that for a given SC= TP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g.= a webrtc-datachannel).
 
So, if one wants multiple usages, one needs to establish multiple associati= ons, using multiple m- lines.
 
BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one = SCTP association between them at any given time. Not exactly sure why, but = that is what the text says=85
 
=93SCTP association: A protocol relationship between SCTP endpoints,
             &n= bsp;  composed of the two SCTP endpoints and protocol state informatio= n
             &n= bsp;  including Verification Tags and the currently active set of=
             &n= bsp;  Transmission Sequence Numbers (TSNs), etc.  An association = can be
             &n= bsp;  uniquely identified by the transport addresses used by the<= /o:p>
             &n= bsp;  endpoints in the association.  Two SCTP endpoints MUST NOT have
             = ;   more than one SCTP association between them at any given time= .=94

<Sal>
That is not a problem.
As it has also already suggested it is enough to use a different port = number on one side.
</Sal>

 
Now, does that mean that, for a given SDP session, we can only have a singl= e SCTP m- line (read: single SCTP usage)?
 
For WebRTC usage that is probably enough, as we use SCTP only for the data = channel, but in general=85


<Sal>
we already have the following text that implies that is possible to ha= ve multiple SCTP
associations between two endpoints

   o  Multiple SCTP associations MAY be multiplexed =
over a single DTLS
      connection.  The SCTP port numbers are used for multiplexing and
      demultiplexing the SCTP associations carried over a single DTLS
      connection.

I hope it helps to clarify the issue. 
</Sal>


 
Regards,
 
Christer
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/m= music

--_000_2649C0564D864448B71FA42954E1BF49ericssoncom_-- From nobody Wed Nov 26 02:36:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BED31A8A3F for ; Wed, 26 Nov 2014 02:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUE4OrSP5oOI for ; Wed, 26 Nov 2014 02:36:32 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B041A8A39 for ; Wed, 26 Nov 2014 02:36:31 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-7e-5475ad2df6bb Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.AD.24955.D2DA5745; Wed, 26 Nov 2014 11:36:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 11:36:29 +0100 From: Christer Holmberg To: Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAxes8AAAUE9XA= Date: Wed, 26 Nov 2014 10:36:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> In-Reply-To: <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja7u2tIQgy1ztSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLbVvawFa4UrJnY0sDYwvuXvYuTkkBAwkVjS2cAOYYtJXLi3 nq2LkYtDSOAIo8S1Z5fYIZwljBLHF/UwdjFycLAJWEh0/9MGMUWAmh8fyAcxmQXUJa4uDgIZ IwxUMG9XOzOILSJgKTHn03so20ri6oEuVpByFgFViYNTS0HCvAK+Eh2z3jFBLGpmlDh3bBMj SIJTwEHi4MnbTCA2I9Bp30+tAbOZBcQlbj2ZzwRxsoDEkj3nmSFsUYmXj/+BzZcQUJKYtjUN olxP4sbUKWwQtrbEsoWvmSH2CkqcnPmEZQKj2CwkU2chaZmFpGUWkpYFjCyrGEWLU4uTctON jPVSizKTi4vz8/TyUks2MQKj5OCW36o7GC+/cTzEKMDBqMTDa+BUGiLEmlhWXJl7iFGag0VJ nHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjloyQPuSpdnFQTlHv07BHO3Ue6++8s WGDSrcfXf2BO8FHHU9tZDQWkw/J3nnJhiOmYXNM4WdzAkH1J2LFz4QtLdR5/Lz1y6voy60uX rsY++Lylnqtw+hQNp3Ubrvk0q0/darozVuGMx4Rs613nVJ6rcv1/2T5V0dl9f8s2sQ9Wd/8F x7NfyT+kxFKckWioxVxUnAgAAKybrXMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PRkE4HLWoMwVuCBPYsyfQvCEE68 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 10:36:34 -0000 Hi, =A0 >Hopefully there are some SCTP experts in da hause that can clarify the fol= lowing: >=A0 >Previously, in the SCTP-SDP discussions, we have agreed that for a given S= CTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g= . a webrtc-datachannel). >=A0 >So, if one wants multiple usages, one needs to establish multiple associat= ions, using multiple m- lines. > >BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one= SCTP association between them at any given time. Not exactly sure why, but= that is what the text says. >=A0 > "SCTP association: A protocol relationship between SCTP endpoints, >=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 composed of the two SCTP endpo= ints and protocol state information >=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 including Verification Tags an= d the currently active set of >=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 Transmission Sequence Numbers = (TSNs), etc.=A0 An association can be >=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 uniquely identified by the tra= nsport addresses used by the >=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 endpoints in the association.= =A0=A0Two SCTP endpoints MUST NOT have >=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 more than one SCTP association= between them at any given time." > > >That is not a problem. >As it has also already suggested it is enough to use a different port numb= er on one side. > After discussing with an SCTP expert, my understanding is that it is enough= to have a unique 4-tuple for each SCTP association. So, that means that SDP can contain multiple m- lines describing an SCTP as= sociation, as long as each use unique 4-tuples. However, afaik, that means that a BUNDLE group CANNOT contain multiple SCTP= associations, as they would all share the same 4-tuple. > >note also that in=A0https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls= -encaps-06 >we already have the following text that implies that is possible to have m= ultiple SCTP >associations between two endpoints > > o Multiple SCTP associations MAY be multiplexed over a single DTLS > connection. The SCTP port numbers are used for multiplexing and > demultiplexing the SCTP associations carried over a single DTLS > connection. Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that text wr= ong?=20 Regards, Christer From nobody Wed Nov 26 02:42:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E41A8A3F for ; Wed, 26 Nov 2014 02:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 750jbne_SVJC for ; Wed, 26 Nov 2014 02:42:21 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B52A1A8A43 for ; Wed, 26 Nov 2014 02:42:17 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-69-5475ae87fe6a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.CB.04076.78EA5745; Wed, 26 Nov 2014 11:42:15 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.226]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 11:42:14 +0100 From: Salvatore Loreto To: Christer Holmberg Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AQHQCVh2RQ9HT1LDRYu/Q2dfZ4TTzJxypjYAgAABnQA= Date: Wed, 26 Nov 2014 10:42:14 +0000 Message-ID: <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <69BACC523E9E1849A015620E6A1DF3E3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+JvjW77utIQg21PdSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIWLbjEVbBGtuNm+gK2Bcb9AFyMnh4SAicT3loNMELaYxIV7 69m6GLk4hASOMEoc7NrGDuEsYZS4vPkiWBWbgJnE84dbmEFsESD7+udeoDgHB7OAusTVxUEg YWEBC4n/F1YyQZRYSsz59B6q3Eri3almNhCbRUBV4sSft6wgNq+AvcShK/8YIXYdZ5Tom3sZ rIhTwE/i35NNYEWMQNd9P7UGbCizgLjErSfzoa4WkFiy5zwzhC0q8fLxP1YIW0lixfZLjBD1 ehI3pk5hg7CtJTZ/e8IMYWtLLFv4mhniCEGJkzOfsExgFJ+FZMUsJO2zkLTPQtI+C0n7AkbW VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiB0XVwy2+rHYwHnzseYhTgYFTi4TVwKg0RYk0s K67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Ma0X/5K6d+ElIf/1G hVbhl5qPnG0yrj4p2xNc2CN7TD/l8CxxpWVffLiKGtkqNs7Xmda90vyryFZ1N+ELf0pvX/im kpW+0vOsYmno0jNH1gtX7U3ecvzz6XtJSnOe/r7p19OUsmRNccE05k1i9RcqpbafVQ59f6+1 f1HgvC2i2qcs3hXPv/PQR4mlOCPRUIu5qDgRAMGp3g6PAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XuRqVK5oGCSvCU9yNfIDrAh3Als Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 10:42:26 -0000 On Nov 26, 2014, at 12:36 PM, Christer Holmberg wrote: > Hi, > =20 >> Hopefully there are some SCTP experts in da hause that can clarify the f= ollowing: >> =20 >> Previously, in the SCTP-SDP discussions, we have agreed that for a given= SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e= .g. a webrtc-datachannel). >> =20 >> So, if one wants multiple usages, one needs to establish multiple associ= ations, using multiple m- lines. >>=20 >> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than o= ne SCTP association between them at any given time. Not exactly sure why, b= ut that is what the text says. >> =20 >> "SCTP association: A protocol relationship between SCTP endpoints, >> composed of the two SCTP endpoints and protocol state in= formation >> including Verification Tags and the currently active set= of >> Transmission Sequence Numbers (TSNs), etc. An associati= on can be >> uniquely identified by the transport addresses used by t= he >> endpoints in the association. Two SCTP endpoints MUST N= OT have >> more than one SCTP association between them at any given= time." >>=20 >> >> That is not a problem. >> As it has also already suggested it is enough to use a different port nu= mber on one side. >> >=20 > After discussing with an SCTP expert, my understanding is that it is enou= gh to have a unique 4-tuple for each SCTP association. >=20 > So, that means that SDP can contain multiple m- lines describing an SCTP = association, as long as each use unique 4-tuples. >=20 > However, afaik, that means that a BUNDLE group CANNOT contain multiple SC= TP associations, as they would all share the same 4-tuple. >=20 >=20 >> >> note also that in https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls= -encaps-06 >> we already have the following text that implies that is possible to have= multiple SCTP >> associations between two endpoints >>=20 >> o Multiple SCTP associations MAY be multiplexed over a single DTLS >> connection. The SCTP port numbers are used for multiplexing and >> demultiplexing the SCTP associations carried over a single DTLS >> connection. >=20 > Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that text = wrong?=20 the text is correct! because it implies that different SCTP associations use different ports (i.= e. each of them use an unique 4-tuples) -> "The SCTP port numbers are used for multiplexing and demultiplexing..." >=20 > Regards, >=20 > Christer From nobody Wed Nov 26 03:29:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5D1A8A4B for ; Wed, 26 Nov 2014 03:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf7OSacXy0hH for ; Wed, 26 Nov 2014 03:29:34 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F5A1A00B1 for ; Wed, 26 Nov 2014 03:29:33 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-dd-5475b99b501e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 11.F6.24955.B99B5745; Wed, 26 Nov 2014 12:29:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 12:29:31 +0100 From: Christer Holmberg To: Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAxes8AAAUE9XD///IzAP//5OAw Date: Wed, 26 Nov 2014 11:29:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> In-Reply-To: <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje7snaUhBkdnqFtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGV0PfzEXTJKq2PRxJ2sD43qRLkZODgkBE4kXZ3axQNhiEhfu rWfrYuTiEBI4wigxfc1mZghnCaPEpead7F2MHBxsAhYS3f+0QUwRoObHB/JBTGYBdYmri4NA xggDFczb1c4MYosIWErM+fSeGaLaTWL6AUMQk0VAVWL5hVqQCl4BX4k739eyQ+z5yyjRfP0C E0gNp4CDRPdaG5AaRqDDvp9awwRiMwuIS9x6Mp8J4mABiSV7zjND2KISLx//YwVplRBQkpi2 NQ2iXEdiwe5PbBC2tsSyha+ZIdYKSpyc+YRlAqPYLCRTZyFpmYWkZRaSlgWMLKsYRYtTi5Ny 042M9VKLMpOLi/Pz9PJSSzYxAiPk4JbfqjsYL79xPMQowMGoxMNr4FQaIsSaWFZcmXuIUZqD RUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGMvjby3Qf39UIJezaTdfQq3SlqnG jAfYDEqWqpnvbrrgvp8naY/bCvW0jz9+VLm2ZDn6cF+pq5MUnCCxIlnhv9bNbQ/XZt8zj53V +erE2nnfzJOv+Wol3KiYK38zLO2eYcWPdW7TbyxwSKw/HGN8uGXH269a/S2OrtaamkvuaN3e nOhW/W/jKiWW4oxEQy3mouJEALi2iIpxAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rSLfatNo6bhPxoK-j9_1jo1klhg Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 11:29:36 -0000 Hi, =20 >>> Hopefully there are some SCTP experts in da hause that can clarify the = following: >>> =20 >>> Previously, in the SCTP-SDP discussions, we have agreed that for a give= n SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (= e.g. a webrtc-datachannel). >>> =20 >>> So, if one wants multiple usages, one needs to establish multiple assoc= iations, using multiple m- lines. >>>=20 >>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than = one SCTP association between them at any given time. Not exactly sure why, = but that is what the text says. >>> =20 >>> "SCTP association: A protocol relationship between SCTP endpoints, >>> composed of the two SCTP endpoints and protocol state i= nformation >>> including Verification Tags and the currently active se= t of >>> Transmission Sequence Numbers (TSNs), etc. An associat= ion can be >>> uniquely identified by the transport addresses used by = the >>> endpoints in the association. Two SCTP endpoints MUST = NOT have >>> more than one SCTP association between them at any give= n time." >>>=20 >>> >>> That is not a problem. >>> As it has also already suggested it is enough to use a different port n= umber on one side. >>> >>=20 >> After discussing with an SCTP expert, my understanding is that it is eno= ugh to have a unique 4-tuple for each SCTP association. >>=20 >> So, that means that SDP can contain multiple m- lines describing an SCTP= association, as long as each use unique 4-tuples. >>=20 >> However, afaik, that means that a BUNDLE group CANNOT contain multiple S= CTP associations, as they would all share the same 4-tuple. >>=20 >>=20 >>> >>> note also that in=20 >>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06 >>> we already have the following text that implies that is possible to=20 >>> have multiple SCTP associations between two endpoints >>>=20 >>> o Multiple SCTP associations MAY be multiplexed over a single DTLS >>> connection. The SCTP port numbers are used for multiplexing and >>> demultiplexing the SCTP associations carried over a single DTLS >>> connection. >>=20 >> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that text= wrong?=20 > > > the text is correct! > because it implies that different SCTP associations use different ports (= i.e. each of them use an unique 4-tuples) > -> "The SCTP port numbers are used for multiplexing and demultiplexing...= " > Well, in case of SCTPoDTLS one could claim that the SCTP port is not really= part of the 4-tuple. But, if the tsvwg folks are ok to multiplex multiple = SCTP associations using a single UDP/TCP port, then fine... I don't have an= y strong opinion - I just want to clarify :) However, in the SCTP-SDP discussions in Honolulu it was agreed to only allo= w a single SCTP association in the case of SCTPoDTLS (even if draft-ietf-ts= vwg-sctp-dtls-encaps allows multiple). The reason is that you would otherwi= se have multiple m- lines with the same port value (even if you don't use B= UNDLE), as the port indicates the UDP/TCP port - not the SCTP port. Regards, Christer From nobody Wed Nov 26 06:02:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEB41A0144; Wed, 26 Nov 2014 06:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OdXNxMvTePg; Wed, 26 Nov 2014 06:02:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9861A0130; Wed, 26 Nov 2014 06:02:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141126140229.31432.80074.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 06:02:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/y--tRlHEkU2BGEQ9-rv91eyMrTQ Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 14:02:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-05.txt Pages : 88 Date : 2014-11-26 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWEB WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. This specification also categorizes the existing SDP attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 26 06:59:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CEC1A01A8 for ; Wed, 26 Nov 2014 06:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEFDOhoSGdGm for ; Wed, 26 Nov 2014 06:59:17 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFB31A0199 for ; Wed, 26 Nov 2014 06:59:17 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-01v.sys.comcast.net with comcast id LEvV1p0024tLnxL01EzGn1; Wed, 26 Nov 2014 14:59:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id LEzG1p0013Ge9ey01EzGUC; Wed, 26 Nov 2014 14:59:16 +0000 Message-ID: <5475EAC3.5030304@alum.mit.edu> Date: Wed, 26 Nov 2014 09:59:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417013956; bh=0zAxGsUxQL3ydYqwEO3YJ1Lf1VqcyF7Dd7dNjHxKSng=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HBEKj3KJsxiNfSBh2apR0auvJ028TyR74ksqYOzvWl+/ym3gVqfE73Yyriniiv0jU U4/xJHnCOXCI0Do99I2UFsLH8E7jfWG8RfmvFkAbEUzyhxKD1ubJ4M2XVgzOFfr+TE z4SfVlBpkW7sO17mVug5ryc4XAgMchcaasIeCrRFqJlfyppBet+w/5J0PBJAQqq4Po 2TQ9yZFDaGUFVBBK2DU5sM9KBjV7h3DPt3HvlwPy1mxrwzM+XMH5t95q0RBXmZI6mF h00kGitT2BHHLOQkWzDuA4aVN64XOVSPEUiY0qvV4Gy8P0yR3eE17aN1BLXCB/riqb dJS70qb4m1lKQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nm9ted7VmiWHNDuh7tLCcdDtXnI Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 14:59:19 -0000 On 11/26/14 6:29 AM, Christer Holmberg wrote: > Hi, > >>>> Hopefully there are some SCTP experts in da hause that can clarify the following: >>>> >>>> Previously, in the SCTP-SDP discussions, we have agreed that for a given SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g. a webrtc-datachannel). >>>> >>>> So, if one wants multiple usages, one needs to establish multiple associations, using multiple m- lines. >>>> >>>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. Not exactly sure why, but that is what the text says. >>>> >>>> "SCTP association: A protocol relationship between SCTP endpoints, >>>> composed of the two SCTP endpoints and protocol state information >>>> including Verification Tags and the currently active set of >>>> Transmission Sequence Numbers (TSNs), etc. An association can be >>>> uniquely identified by the transport addresses used by the >>>> endpoints in the association. Two SCTP endpoints MUST NOT have >>>> more than one SCTP association between them at any given time." >>>> >>>> >>>> That is not a problem. >>>> As it has also already suggested it is enough to use a different port number on one side. >>>> >>> >>> After discussing with an SCTP expert, my understanding is that it is enough to have a unique 4-tuple for each SCTP association. >>> >>> So, that means that SDP can contain multiple m- lines describing an SCTP association, as long as each use unique 4-tuples. >>> >>> However, afaik, that means that a BUNDLE group CANNOT contain multiple SCTP associations, as they would all share the same 4-tuple. >>> >>> >>>> >>>> note also that in >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06 >>>> we already have the following text that implies that is possible to >>>> have multiple SCTP associations between two endpoints >>>> >>>> o Multiple SCTP associations MAY be multiplexed over a single DTLS >>>> connection. The SCTP port numbers are used for multiplexing and >>>> demultiplexing the SCTP associations carried over a single DTLS >>>> connection. >>> >>> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that text wrong? >> >> >> the text is correct! >> because it implies that different SCTP associations use different ports (i.e. each of them use an unique 4-tuples) >> -> "The SCTP port numbers are used for multiplexing and demultiplexing..." >> > > Well, in case of SCTPoDTLS one could claim that the SCTP port is not really part of the 4-tuple. But, if the tsvwg folks are ok to multiplex multiple SCTP associations using a single UDP/TCP port, then fine... I don't have any strong opinion - I just want to clarify :) > > However, in the SCTP-SDP discussions in Honolulu it was agreed to only allow a single SCTP association in the case of SCTPoDTLS (even if draft-ietf-tsvwg-sctp-dtls-encaps allows multiple). The reason is that you would otherwise have multiple m- lines with the same port value (even if you don't use BUNDLE), as the port indicates the UDP/TCP port - not the SCTP port. IMO when considering SCTPoDTLS we need to be talking about a unique 6-tuple, not a 4-tuple: 2 IP addresses, 2 UDP ports, 2 SCTP ports. Thanks, Paul From nobody Wed Nov 26 07:03:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5B21A01A5 for ; Wed, 26 Nov 2014 07:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsdgtKIcwgC9 for ; Wed, 26 Nov 2014 07:03:35 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1F81A014A for ; Wed, 26 Nov 2014 07:03:34 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-1b-5475ebc40272 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A3.2C.24955.4CBE5745; Wed, 26 Nov 2014 16:03:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 16:03:32 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAxes8AAAUE9XD///IzAP//5OAwgABi74D//+6qIA== Date: Wed, 26 Nov 2014 15:03:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5397F4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> <5475EAC3.5030304@alum.mit.edu> In-Reply-To: <5475EAC3.5030304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje7R16UhBtMnsVhMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGw5dXmAumyVX0zapuYLwt3sXIySEhYCIx 6exiNghbTOLCvfVANheHkMARRone5pmsEM4SRon98zqAHA4ONgELie5/2iANIgK+Es8e3wZr FgYKz9vVzgwRt5SY8+k9lB0mMaP/GguIzSKgKnHv7XRWEJsXqPfuw7fMEPMfM0ncOLWMESTB KaAjcefDTrAiRqCLvp9awwRiMwuIS9x6Mp8J4lIBiSV7zjND2KISLx//A7tNQkBJYtrWNIhy HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkEydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLW Sy3KTC4uzs/Ty0st2cQIjJKDW36r7mC8/MbxEKMAB6MSD6+BU2mIEGtiWXFl7iFGaQ4WJXHe hefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgbNwi5NH24alS9pOvZ6Ln9Z+ZmbdLeGmO oc1dq3uVS/g81u6IEVmna7KrmHnXqZOr+G8+Yyje/HNutF/ZhtSFInf+W8nOTnYKSk5ZolGX vGtbbNM0m3XLN10r8JdWY7F79ITtQuWzzz7O0zZe2Oq+tTckZbbEUeGEecL/aw7FBoY6L+X7 0LPRUYmlOCPRUIu5qDgRAJ6WkCVzAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jyj9uiI-gaART4UsJnti7QtdpOU Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 15:03:37 -0000 Hi, >>>>> Hopefully there are some SCTP experts in da hause that can clarify th= e following: >>>>> >>>>> Previously, in the SCTP-SDP discussions, we have agreed that for a gi= ven SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage= (e.g. a webrtc-datachannel). >>>>> >>>>> So, if one wants multiple usages, one needs to establish multiple ass= ociations, using multiple m- lines. >>>>> >>>>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more tha= n one SCTP association between them at any given time. Not exactly sure why= , but that is what the text says. >>>>> >>>>> "SCTP association: A protocol relationship between SCTP endpoin= ts, >>>>> composed of the two SCTP endpoints and protocol stat= e information >>>>> including Verification Tags and the currently active= set of >>>>> Transmission Sequence Numbers (TSNs), etc. An assoc= iation can be >>>>> uniquely identified by the transport addresses used = by the >>>>> endpoints in the association. Two SCTP endpoints MU= ST NOT have >>>>> more than one SCTP association between them at any g= iven time." >>>>> >>>>> >>>>> That is not a problem. >>>>> As it has also already suggested it is enough to use a different port= number on one side. >>>>> >>>> >>>> After discussing with an SCTP expert, my understanding is that it is e= nough to have a unique 4-tuple for each SCTP association. >>>> >>>> So, that means that SDP can contain multiple m- lines describing an SC= TP association, as long as each use unique 4-tuples. >>>> >>>> However, afaik, that means that a BUNDLE group CANNOT contain multiple= SCTP associations, as they would all share the same 4-tuple. >>>> >>>> >>>>> >>>>> note also that in >>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06 >>>>> we already have the following text that implies that is possible to=20 >>>>> have multiple SCTP associations between two endpoints >>>>> >>>>> o Multiple SCTP associations MAY be multiplexed over a single DTLS >>>>> connection. The SCTP port numbers are used for multiplexing and >>>>> demultiplexing the SCTP associations carried over a single DTLS >>>>> connection. >>>> >>>> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that te= xt wrong? >>> >>> >>> the text is correct! >>> because it implies that different SCTP associations use different ports= (i.e. each of them use an unique 4-tuples) >>> -> "The SCTP port numbers are used for multiplexing and demultiplexing= ..." >>> >> >> Well, in case of SCTPoDTLS one could claim that the SCTP port is not=20 >> really part of the 4-tuple. But, if the tsvwg folks are ok to=20 >> multiplex multiple SCTP associations using a single UDP/TCP port, then=20 >> fine... I don't have any strong opinion - I just want to clarify :) >> >> However, in the SCTP-SDP discussions in Honolulu it was agreed to only a= llow a single SCTP association in the case of=20 >> SCTPoDTLS (even if draft-ietf-tsvwg-sctp-dtls-encaps allows multiple). T= he reason is that you would otherwise have=20 >> multiple m- lines with the same port value (even if you don't use BUNDLE= ), as the port indicates the UDP/TCP port - not the SCTP port. > > IMO when considering SCTPoDTLS we need to be talking about a unique 6-tup= le, not a 4-tuple: 2 IP addresses, 2 UDP ports, 2 SCTP ports. Perhaps it would be a good idea to add some clarification text regarding th= is in the draft-ietf-tsvwg-sctp-dtls-encaps. Regards, Christer Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Nov 26 07:30:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3331A01D6 for ; Wed, 26 Nov 2014 07:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2L3MyIXWp6w for ; Wed, 26 Nov 2014 07:30:32 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088891A0145 for ; Wed, 26 Nov 2014 07:30:32 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6AFBD3E3DE2C7; Wed, 26 Nov 2014 15:30:26 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sAQFUREd021557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 10:30:28 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 10:30:27 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AQHQCVh2RQ9HT1LDRYu/Q2dfZ4TTzJxzCswAgAABnACAAA02gP//08kQ Date: Wed, 26 Nov 2014 15:30:27 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tS4VsVflxfVNNHo87s39kqA4mcU Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 15:30:34 -0000 >=20 > >>> Hopefully there are some SCTP experts in da hause that can clarify th= e > following: > >>> > >>> Previously, in the SCTP-SDP discussions, we have agreed that for a gi= ven > SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage > (e.g. a webrtc-datachannel). > >>> > >>> So, if one wants multiple usages, one needs to establish multiple > associations, using multiple m- lines. > >>> > >>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more tha= n > one SCTP association between them at any given time. Not exactly sure why= , > but that is what the text says. > >>> > >>> "SCTP association: A protocol relationship between SCTP endpoint= s, > >>> composed of the two SCTP endpoints and protocol state > information > >>> including Verification Tags and the currently active = set > of > >>> Transmission Sequence Numbers (TSNs), etc. An > association can be > >>> uniquely identified by the transport addresses used b= y > the > >>> endpoints in the association. Two SCTP endpoints MUS= T > NOT have > >>> more than one SCTP association between them at any gi= ven > time." > >>> > >>> > >>> That is not a problem. > >>> As it has also already suggested it is enough to use a different port > number on one side. > >>> > >> > >> After discussing with an SCTP expert, my understanding is that it is > enough to have a unique 4-tuple for each SCTP association. > >> > >> So, that means that SDP can contain multiple m- lines describing an SC= TP > association, as long as each use unique 4-tuples. > >> > >> However, afaik, that means that a BUNDLE group CANNOT contain multiple > SCTP associations, as they would all share the same 4-tuple. > >> > >> > >>> > >>> note also that in > >>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06 > >>> we already have the following text that implies that is possible to > >>> have multiple SCTP associations between two endpoints > >>> > >>> o Multiple SCTP associations MAY be multiplexed over a single DTLS > >>> connection. The SCTP port numbers are used for multiplexing and > >>> demultiplexing the SCTP associations carried over a single DTLS > >>> connection. > >> > >> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that te= xt > wrong? > > > > > > the text is correct! > > because it implies that different SCTP associations use different ports > (i.e. each of them use an unique 4-tuples) > > -> "The SCTP port numbers are used for multiplexing and > demultiplexing..." > > >=20 > Well, in case of SCTPoDTLS one could claim that the SCTP port is not real= ly > part of the 4-tuple. But, if the tsvwg folks are ok to multiplex multiple > SCTP associations using a single UDP/TCP port, then fine... I don't have = any > strong opinion - I just want to clarify :) >=20 > However, in the SCTP-SDP discussions in Honolulu it was agreed to only al= low > a single SCTP association in the case of SCTPoDTLS (even if draft-ietf- > tsvwg-sctp-dtls-encaps allows multiple). The reason is that you would > otherwise have multiple m- lines with the same port value (even if you do= n't > use BUNDLE), as the port indicates the UDP/TCP port - not the SCTP port. Per my understanding, draft-ietf-tsvwg-sctp-dtls-encaps just talks about SC= TP over DTLS and allowing multiple SCTP associations, which is perfectly fi= ne. Then it is possible to come up with SCTP-SDP semantics to use that capabili= ty. One m=3D line allowing one SCTP over DTLS limit is fine. Using BUNDLE you c= an replicate same 4-tuple in multiple m=3D lines. Then there is only one DT= LS association established and multiple SCTP associations over that is poss= ible (one per m=3D line). If BUNDLE is not used then I believe same 4-tuple on multiple m=3D lines ar= e NOT possible. This is because, per my understanding, unlike TCP/native-SC= TP used under non-ICE environments, in ICE-environments the TCP/UDP port sp= ecified is used both as client and server port for DTLS.=20 I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction between u= se of ICE or not. I believe the semantics for port in m=3D line are differe= nt when ICE is used vs. ICE is not used. - When ICE is used it is the client as well as the server port. - When ICE is not used, the port is the server port and not the client port= . For a=3Dsetup:active cases discard port 9 is used per RFC 4145, which dra= ft-ietf-mmusic-sctp-sdp refers. BR Raju From nobody Wed Nov 26 08:16:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7838F1A01D6 for ; Wed, 26 Nov 2014 08:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGR0NQxzn2qc for ; Wed, 26 Nov 2014 08:16:32 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C8F1A026A for ; Wed, 26 Nov 2014 08:16:32 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-b6-5475fcde193f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 71.47.29772.EDCF5745; Wed, 26 Nov 2014 17:16:30 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.226]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 17:16:30 +0100 From: Salvatore Loreto To: Christer Holmberg Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AQHQCVh2RQ9HT1LDRYu/Q2dfZ4TTzJxypjYAgAABnQCAAA02gIAAOpmAgAABMYCAABRjgA== Date: Wed, 26 Nov 2014 16:16:28 +0000 Message-ID: <540EAE03-6412-4E56-B803-288505F653CE@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> <5475EAC3.5030304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5397F4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5397F4@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <40482D12F60A2E4AB7886021B82DDB7E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rvfen9IQg5MbZCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj9V/bgptKFa+fnWVpYLwk3cXIySEhYCKx 4sR1ZghbTOLCvfVsXYxcHEICRxglZkz6ywrhLGGUWPjhAlgVm4CZxPOHW8BsESD7+udeJhCb WcBX4uWCL2BxYQELif8XVjJB1FhKzPn0Hqo+TGLVorusIDaLgKrEyQmbwOK8AvYS7X//M0Is W84s0bnsNViCU8BPouXVRTCbEei876fWQC0Tl7j1ZD4TxNkCEkv2nId6QVTi5eN/rBC2ksSi 25+h6nUkFuz+xAZhW0tsv/qDEcLWlli28DXUEYISJ2c+YZnAKD4LyYpZSNpnIWmfhaR9FpL2 BYysqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECI+7glt8GOxhfPnc8xCjAwajEw2vgVBoi xJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYRfxeOtVestBe 9PLL6rwf3iwifwrcRFZO0Tw+1XorT/ilNeuPztk/QXKy3HtJrfDFLaU/c4+lFtYVL6nasGrv pINT2OeuXP2mXmifgcY/ngS7gjbrFb0a04oPxJQUKk1nsfux0Sam3/vnCsurS1inWRtNt6s+ fnr5Rdu4Y3fOtkwoFp3+d1FcsRJLcUaioRZzUXEiAD4rMXyZAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rnB6g_naiURsovYDByxlZEefZhA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 16:16:35 -0000 On Nov 26, 2014, at 5:03 PM, Christer Holmberg wrote: > Hi, >=20 >>>>>> Hopefully there are some SCTP experts in da hause that can clarify t= he following: >>>>>>=20 >>>>>> Previously, in the SCTP-SDP discussions, we have agreed that for a g= iven SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usag= e (e.g. a webrtc-datachannel). >>>>>>=20 >>>>>> So, if one wants multiple usages, one needs to establish multiple as= sociations, using multiple m- lines. >>>>>>=20 >>>>>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more th= an one SCTP association between them at any given time. Not exactly sure wh= y, but that is what the text says. >>>>>>=20 >>>>>> "SCTP association: A protocol relationship between SCTP endpoin= ts, >>>>>> composed of the two SCTP endpoints and protocol stat= e information >>>>>> including Verification Tags and the currently active= set of >>>>>> Transmission Sequence Numbers (TSNs), etc. An assoc= iation can be >>>>>> uniquely identified by the transport addresses used = by the >>>>>> endpoints in the association. Two SCTP endpoints MU= ST NOT have >>>>>> more than one SCTP association between them at any g= iven time." >>>>>>=20 >>>>>> >>>>>> That is not a problem. >>>>>> As it has also already suggested it is enough to use a different por= t number on one side. >>>>>> >>>>>=20 >>>>> After discussing with an SCTP expert, my understanding is that it is = enough to have a unique 4-tuple for each SCTP association. >>>>>=20 >>>>> So, that means that SDP can contain multiple m- lines describing an S= CTP association, as long as each use unique 4-tuples. >>>>>=20 >>>>> However, afaik, that means that a BUNDLE group CANNOT contain multipl= e SCTP associations, as they would all share the same 4-tuple. >>>>>=20 >>>>>=20 >>>>>> >>>>>> note also that in >>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06 >>>>>> we already have the following text that implies that is possible to= =20 >>>>>> have multiple SCTP associations between two endpoints >>>>>>=20 >>>>>> o Multiple SCTP associations MAY be multiplexed over a single DTLS >>>>>> connection. The SCTP port numbers are used for multiplexing and >>>>>> demultiplexing the SCTP associations carried over a single DTLS >>>>>> connection. >>>>>=20 >>>>> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that t= ext wrong? >>>>=20 >>>> >>>> the text is correct! >>>> because it implies that different SCTP associations use different port= s (i.e. each of them use an unique 4-tuples) >>>> -> "The SCTP port numbers are used for multiplexing and demultiplexin= g..." >>>> >>>=20 >>> Well, in case of SCTPoDTLS one could claim that the SCTP port is not=20 >>> really part of the 4-tuple. But, if the tsvwg folks are ok to=20 >>> multiplex multiple SCTP associations using a single UDP/TCP port, then= =20 >>> fine... I don't have any strong opinion - I just want to clarify :) >>>=20 >>> However, in the SCTP-SDP discussions in Honolulu it was agreed to only = allow a single SCTP association in the case of=20 >>> SCTPoDTLS (even if draft-ietf-tsvwg-sctp-dtls-encaps allows multiple). = The reason is that you would otherwise have=20 >>> multiple m- lines with the same port value (even if you don't use BUNDL= E), as the port indicates the UDP/TCP port - not the SCTP port. >>=20 >> IMO when considering SCTPoDTLS we need to be talking about a unique 6-tu= ple, not a 4-tuple: 2 IP addresses, 2 UDP ports, 2 SCTP ports. >=20 > Perhaps it would be a good idea to add some clarification text regarding = this in the draft-ietf-tsvwg-sctp-dtls-encaps. I completely disagree. The uniqueness SCTP rfc 4960 is referring to is the "classic" transport lev= el 4-tuple=20 and this respected in the sctp-dtls-encaps draft. br Salvatore >=20 > Regards, >=20 > Christer >=20 >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Nov 26 10:53:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915201A1ABC for ; Wed, 26 Nov 2014 10:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tiSwe5zmLfM for ; Wed, 26 Nov 2014 10:53:39 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BC21A1A91 for ; Wed, 26 Nov 2014 10:53:38 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-b7-547621b060ce Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.C6.24955.0B126745; Wed, 26 Nov 2014 19:53:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 19:53:36 +0100 From: Christer Holmberg To: Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAxes8AAAUE9XD///IzAP//5OAwgABi74D//+6qIIAAJukA///EFUA= Date: Wed, 26 Nov 2014 18:53:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D539F00@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> <5475EAC3.5030304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5397F4@ESESSMB209.ericsson.se> <540EAE03-6412-4E56-B803-288505F653CE@ericsson.com> In-Reply-To: <540EAE03-6412-4E56-B803-288505F653CE@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje4GxbIQgzn3jCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj1rFj7AXruCu+HdjL3sDYx9nFyMEhIWAi sfOTTxcjJ5ApJnHh3nq2LkYuDiGBI4wSqza2MkM4Sxglvu2azw7SwCZgIdH9TxvEFAHqfXwg H6SXWcBX4uWCL8wgtjBQxbxd7WC2iIClxJxP76HsJImGi+9YQWwWAVWJxkcvGEFsXqDeJ9e/ QK26yyzR+2cmI8h8TgEHiT+Ta0BqGIFu+35qDRPELnGJW0/mM0HcLCCxZM95ZghbVOLl43+s ELaSROOSJ6wQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnF KFqcWpyUm25krJdalJlcXJyfp5eXWrKJERg7B7f8Vt3BePmN4yFGAQ5GJR5eA6fSECHWxLLi ytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCiv6pdkbnnvUVbItEjN 2ieuz3Ta7/X9ujvzUb50zdRZX+bNWrf8+c5Of4n0fXsUok08VwjIGi4sL1ddo5tx/GnIA03l 8kWh343ML2iJP+bptDmzRcj8+mNjxQUlG9YHsQtt+rHjgoHb7S8lv3LLef+lBhxdd3hN0Sn/ pbfsjkya8dVVP3BiroMSS3FGoqEWc1FxIgBspyiBfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rjKh0iFxbNidgS2vwpJlEC8o2NY Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 18:53:40 -0000 Hi, ... =20 >>>> Well, in case of SCTPoDTLS one could claim that the SCTP port is not=20 >>>> really part of the 4-tuple. But, if the tsvwg folks are ok to=20 >>>> multiplex multiple SCTP associations using a single UDP/TCP port,=20 >>>> then fine... I don't have any strong opinion - I just want to=20 >>>> clarify :) >>>>=20 >>>> However, in the SCTP-SDP discussions in Honolulu it was agreed to=20 >>>> only allow a single SCTP association in the case of SCTPoDTLS (even=20 >>>> if draft-ietf-tsvwg-sctp-dtls-encaps allows multiple). The reason is t= hat you would otherwise=20 >>>> have multiple m- lines with the same port value (even if you don't use= BUNDLE), as the port indicates the UDP/TCP port - not the SCTP port. >>>=20 >>> IMO when considering SCTPoDTLS we need to be talking about a unique 6-t= uple, not a 4-tuple: 2 IP addresses, 2 UDP ports, 2 SCTP ports. >>=20 >> Perhaps it would be a good idea to add some clarification text regarding= this in the draft-ietf-tsvwg-sctp-dtls-encaps. > > I completely disagree. > The uniqueness SCTP rfc 4960 is referring to is the "classic" transport l= evel 4-tuple and this respected in the sctp-dtls-encaps draft. That's fine. But, the fact is that each SCTP association will be transported on a single= UDP/TCP 4-tuple (the SCTP port will only be used for de-multiplexing by th= e endpoints), and I see no harm in mentioning that. Regards, Christer From nobody Wed Nov 26 11:00:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F101A038E for ; Wed, 26 Nov 2014 11:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E71wJAIIz0pg for ; Wed, 26 Nov 2014 11:00:41 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6831A0166 for ; Wed, 26 Nov 2014 11:00:40 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-12-547623569547 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.83.04076.65326745; Wed, 26 Nov 2014 20:00:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 20:00:38 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAxes8AAAUE9XD///IzAP//5OAwgABrp4D//7ZsQA== Date: Wed, 26 Nov 2014 19:00:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D539F4F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW6YclmIweMjRhZTlz9msWjYeIXV gcmj9dleVo8lS34yBTBFcdmkpOZklqUW6dslcGX03/vCVLBLp2Jnw0mWBsYnSl2MnBwSAiYS O3Y1MULYYhIX7q1n62Lk4hASOMIocX76SihnCaNEy4NVQFUcHGwCFhLd/7RBGkQEKiXOzF0E FmYWUJe4ujgIJCwMVDFvVzszRImlxJxP76HsMIkzWzvAdrEIqEqce9jJCtLKK+ArMXNVAcSm KcwSfyftYgWp4RSIlbjwqAGsnhHotu+n1jCB2MwC4hK3nsxngrhZQGLJnvPMELaoxMvH/1gh bCWJxiVPWCHqdSQW7P7EBmFrSyxb+BqsnldAUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnF KFqcWlycm25kpJdalJlcXJyfp5eXWrKJERg9B7f8ttrBePC54yFGAQ5GJR5eA6fSECHWxLLi ytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwGiowOytEXk05dWzLJ6b VssenYz+lH9oQ5rL7KWLIx5F+MZsPtT1dlZpwHZ5M0P5d2vq1+f7dm2feHzVzqrbKuYH1IPn rv7+MDDIce3avT++fD3zzGyZYvmLr0uMf9Q+yBHsllga2Ha9xzGj8luOrY1aq8uE5IsGgv9c pRYGKZy/tnKXvkTTcRUlluKMREMt5qLiRACZ0FVFfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vlOwxN36h9qOjDptL3zGUaTdVpg Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 19:00:43 -0000 -----Original Message----- From: Makaraju, Maridi Raju (Raju) [mailto:Raju.Makaraju@alcatel-lucent.com= ]=20 Sent: 26 November 2014 17:30 To: Christer Holmberg; Salvatore Loreto Cc: mmusic@ietf.org Subject: RE: [MMUSIC] Single SCTP usage per SDP session? >=20 > >>> Hopefully there are some SCTP experts in da hause that can clarify=20 > >>> the > following: > >>> > >>> Previously, in the SCTP-SDP discussions, we have agreed that for a=20 > >>> given > SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single=20 > usage (e.g. a webrtc-datachannel). > >>> > >>> So, if one wants multiple usages, one needs to establish multiple > associations, using multiple m- lines. > >>> > >>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more=20 > >>> than > one SCTP association between them at any given time. Not exactly sure=20 > why, but that is what the text says. > >>> > >>> "SCTP association: A protocol relationship between SCTP endpoint= s, > >>> composed of the two SCTP endpoints and protocol=20 > >>> state > information > >>> including Verification Tags and the currently=20 > >>> active set > of > >>> Transmission Sequence Numbers (TSNs), etc. An > association can be > >>> uniquely identified by the transport addresses=20 > >>> used by > the > >>> endpoints in the association. Two SCTP endpoints=20 > >>> MUST > NOT have > >>> more than one SCTP association between them at any=20 > >>> given > time." > >>> > >>> > >>> That is not a problem. > >>> As it has also already suggested it is enough to use a different=20 > >>> port > number on one side. > >>> > >> > >> After discussing with an SCTP expert, my understanding is that it=20 > >> is > enough to have a unique 4-tuple for each SCTP association. > >> > >> So, that means that SDP can contain multiple m- lines describing an=20 > >> SCTP > association, as long as each use unique 4-tuples. > >> > >> However, afaik, that means that a BUNDLE group CANNOT contain=20 > >> multiple > SCTP associations, as they would all share the same 4-tuple. > >> > >> > >>> > >>> note also that in > >>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06 > >>> we already have the following text that implies that is possible=20 > >>> to have multiple SCTP associations between two endpoints > >>> > >>> o Multiple SCTP associations MAY be multiplexed over a single DTLS > >>> connection. The SCTP port numbers are used for multiplexing and > >>> demultiplexing the SCTP associations carried over a single DTLS > >>> connection. > >> > >> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that=20 > >> text > wrong? > > > > > > the text is correct! > > because it implies that different SCTP associations use different=20 > > ports > (i.e. each of them use an unique 4-tuples) > > -> "The SCTP port numbers are used for multiplexing and > demultiplexing..." > > >=20 > Well, in case of SCTPoDTLS one could claim that the SCTP port is not=20 > really part of the 4-tuple. But, if the tsvwg folks are ok to=20 > multiplex multiple SCTP associations using a single UDP/TCP port, then=20 > fine... I don't have any strong opinion - I just want to clarify :) >=20 > However, in the SCTP-SDP discussions in Honolulu it was agreed to only=20 > allow a single SCTP association in the case of SCTPoDTLS (even if=20 > draft-ietf- tsvwg-sctp-dtls-encaps allows multiple). The reason is=20 > that you would otherwise have multiple m- lines with the same port=20 > value (even if you don't use BUNDLE), as the port indicates the UDP/TCP p= ort - not the SCTP port. > Per my understanding, draft-ietf-tsvwg-sctp-dtls-encaps just talks about = SCTP over DTLS and allowing multiple SCTP associations, which is perfectly = fine. > Then it is possible to come up with SCTP-SDP semantics to use that capabi= lity. > One m=3D line allowing one SCTP over DTLS limit is fine. Using BUNDLE you= can replicate same 4-tuple in multiple m=3D lines. Then there is only one = DTLS association=20 > established and multiple SCTP associations over that is possible (one per= m=3D line). > If BUNDLE is not used then I believe same 4-tuple on multiple m=3D lines = are NOT possible. This is because, per my understanding, unlike TCP/native-= SCTP used under non- > ICE environments, in ICE-environments the TCP/UDP port specified is used = both as client and server port for DTLS.=20 Even with BUNDLE, you would have to use the same m=3D line port value from = the beginning, which is not allowed. So, you basically would have to add th= e additional SCTPoDTLS m=3D lines once the usage of BUNDLE has been negotia= ted. > I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction between= use of ICE or not. I believe the semantics for port in m=3D line are diffe= rent when ICE is used vs. ICE > is not used. > - When ICE is used it is the client as well as the server port. >- When ICE is not used, the port is the server port and not the client po= rt. For a=3Dsetup:active cases discard port 9 is used per RFC 4145, which d= raft-ietf-mmusic-sctp-sdp=20 > refers. Per the agreement in Honolulu, there will be no port 9 for SCTP, as the agr= eement was that both endpoints will initiate the SCTP association. And, in order to prevent two separate SCTP associations to be established, = the m=3D line port needs to indicate both the client and server port also w= ithout ICE. Regards, Christer From nobody Wed Nov 26 11:58:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD801A1B35 for ; Wed, 26 Nov 2014 11:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1KumXAu9f12 for ; Wed, 26 Nov 2014 11:58:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FFF1A1B32 for ; Wed, 26 Nov 2014 11:58:52 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id D7D7A2303FCC5; Wed, 26 Nov 2014 19:58:45 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id sAQJwmMB032253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 14:58:48 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 14:58:48 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AQHQCVh2RQ9HT1LDRYu/Q2dfZ4TTzJxzCswAgAABnACAAA02gP//08kQgACqQID//7NDoA== Date: Wed, 26 Nov 2014 19:58:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D539F4F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D539F4F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uXbh7Q8PRMldL7T4ok6-c1Kwpr8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 19:58:55 -0000 > > However, in the SCTP-SDP discussions in Honolulu it was agreed to only > > allow a single SCTP association in the case of SCTPoDTLS (even if > > draft-ietf- tsvwg-sctp-dtls-encaps allows multiple). The reason is > > that you would otherwise have multiple m- lines with the same port > > value (even if you don't use BUNDLE), as the port indicates the UDP/TCP > port - not the SCTP port. >=20 > > > Per my understanding, draft-ietf-tsvwg-sctp-dtls-encaps just talks abou= t > SCTP over DTLS and allowing multiple SCTP associations, which is perfectl= y > fine. > > Then it is possible to come up with SCTP-SDP semantics to use that > capability. > > One m=3D line allowing one SCTP over DTLS limit is fine. Using BUNDLE y= ou > can replicate same 4-tuple in multiple m=3D lines. Then there is only one= DTLS > association > > established and multiple SCTP associations over that is possible (one p= er > m=3D line). > > If BUNDLE is not used then I believe same 4-tuple on multiple m=3D line= s are > NOT possible. This is because, per my understanding, unlike TCP/native-SC= TP > used under non- > > ICE environments, in ICE-environments the TCP/UDP port specified is use= d > both as client and server port for DTLS. >=20 > Even with BUNDLE, you would have to use the same m=3D line port value fro= m the > beginning, which is not allowed. So, you basically would have to add the > additional SCTPoDTLS m=3D lines once the usage of BUNDLE has been negotia= ted. You are right. Section 8.2.1 of draft-ietf-mmusic-sdp-bundle-negotiation says the m=3D line should have unique 4-tuple to allow possibility of=20 BUNDLE rejection. Very valid. However, to facilitate multiple SCTP over same bundled SCTP,=20 won't the following work? - Offerer adds one m=3D line for each SCTP association needed. - If the answerer selects BUNDLE then all the SCTP m=3D lines now map and use the same DTLS association. - If the answerer does not accept BUNDLE then we don't have the option of negotiating multiple SCTPs over same DTLS anyway; so it will result in multiple DTLS, which still gives you a way to get multiple SCTPs. With this approach a new subsequent SDP offer is not needed to=20 add SCTP m=3D lines. >=20 > > I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction betwe= en > use of ICE or not. I believe the semantics for port in m=3D line are diff= erent > when ICE is used vs. ICE > is not used. > > - When ICE is used it is the client as well as the server port. > >- When ICE is not used, the port is the server port and not the client > port. For a=3Dsetup:active cases discard port 9 is used per RFC 4145, whi= ch > draft-ietf-mmusic-sctp-sdp > > refers. >=20 > Per the agreement in Honolulu, there will be no port 9 for SCTP, as the > agreement was that both endpoints will initiate the SCTP association. >=20 > And, in order to prevent two separate SCTP associations to be established= , > the m=3D line port needs to indicate both the client and server port also > without ICE. So, these 2 clarifications are needed in draft-ietf-mmusic-sctp-sdp as it deviates from referred RFC 4145. BR Raju From nobody Thu Nov 27 01:12:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789DE1A88A9 for ; Thu, 27 Nov 2014 01:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.411 X-Spam-Level: X-Spam-Status: No, score=-4.411 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhQkrMUFb0nM for ; Thu, 27 Nov 2014 01:12:17 -0800 (PST) Received: from mailout1.thls.bbc.co.uk (mailout1.thls.bbc.co.uk [132.185.240.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366D91A0065 for ; Thu, 27 Nov 2014 01:12:16 -0800 (PST) Received: from BGB01XI1004.national.core.bbc.co.uk ([10.184.50.54]) by mailout1.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id sAR9C9T0026496 for ; Thu, 27 Nov 2014 09:12:11 GMT Received: from BGB01XI1015.national.core.bbc.co.uk (10.161.14.78) by BGB01XI1004.national.core.bbc.co.uk (10.184.50.54) with Microsoft SMTP Server (TLS) id 14.2.342.4; Thu, 27 Nov 2014 09:12:09 +0000 Received: from BGB01XUD1002.national.core.bbc.co.uk ([169.254.11.132]) by BGB01XI1015.national.core.bbc.co.uk ([10.161.14.78]) with mapi id 14.02.0342.004; Thu, 27 Nov 2014 09:12:09 +0000 From: Peter Stevens To: "mmusic@ietf.org" Thread-Topic: Comments on ABNF in 4566bis Thread-Index: AdAJlfXIgJ06mXorTPWRVKVHzEMA8w== Date: Thu, 27 Nov 2014 09:12:08 +0000 Message-ID: <2F938AAE444ADB47AFEE6307955A30CE2EB86B81@BGB01XUD1002.national.core.bbc.co.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] Content-Type: multipart/alternative; boundary="_000_2F938AAE444ADB47AFEE6307955A30CE2EB86B81BGB01XUD1002nat_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/U5irf4zWnnZ8f3KK3wOx5CymwMg Subject: Re: [MMUSIC] Comments on ABNF in 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 09:12:21 -0000 --_000_2F938AAE444ADB47AFEE6307955A30CE2EB86B81BGB01XUD1002nat_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Colin has commented on this particular attribute: > a=3Dptime: and a=3Dmaxptime: > - Are these always integers? This is a question within the EBU Audio Contribution over IP (ACIP) group h= ave noted that the ptime units are not specified within RFC4566. If you were not already aware, within the AES, the AES67-2013 AES Standard = for audio applications of networks - High-performance streaming audio-over-= ip interoperability, packet time is defined with decimal values as follows: a-ptime [.] a=3Dmaxptime [.] Do ptime integers possibly conflict with decimal values? It is unknown how manufacturers of products define their value of ptime int= ernally, such as 20ms, as either an integer of 20 (ms) or as 0.020 Best regards, Peter Stevens BBC R&D --_000_2F938AAE444ADB47AFEE6307955A30CE2EB86B81BGB01XUD1002nat_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Colin has commented on this particular attribute:

> a=3Dptime: and a=3Dmaxptime:
> - Are these always integers?

This is a question within the EBU Audio Contribution over IP (ACIP) group h= ave noted that the ptime units are not specified within RFC4566.
If you were not already aware, within the AES, the AES67-2013 AES Standard = for audio applications of networks - High-performance streaming audio-over-= ip interoperability, packet time is defined with decimal values as follows:=

a-ptime <milliseconds>[.<milliseconds decimal>]
a=3Dmaxptime <milliseconds>[.<milliseconds decimal>]

Do ptime integers possibly conflict with decimal values?
It is unknown how manufacturers of products define their value of ptime int= ernally, such as 20ms, as either an integer of 20 (ms) or as 0.020

 

 

Best regards,

 

 

Peter Stevens

BBC R&D

 

--_000_2F938AAE444ADB47AFEE6307955A30CE2EB86B81BGB01XUD1002nat_-- From nobody Thu Nov 27 02:19:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81791A88C9 for ; Thu, 27 Nov 2014 02:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTsaHSt1JGHx for ; Thu, 27 Nov 2014 02:19:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730A51A88C8 for ; Thu, 27 Nov 2014 02:19:21 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-8a-5476faa79a55 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.F6.04231.7AAF6745; Thu, 27 Nov 2014 11:19:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 11:19:19 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAxes8AAAUE9XD///IzAP//5OAwgABrp4D//7ZsQIAAlI2A//8E+PA= Date: Thu, 27 Nov 2014 10:19:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53B3DC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D539F4F@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7yX2UhBntaNC2mLn/MYtGw8Qqr A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYcmEPS8EE4YovU++yNjBO4+9i5OSQEDCR eDZlJxuELSZx4d56IJuLQ0jgCKPE9M0LmSCcJYwSyz40A2U4ONgELCS6/2mDNIgIVEqcmbuI ESTMLKAucXVxEEhYGKhi3q52ZogSS4k5n95D2UkSxx5/YwWxWQRUJaasXwoW5xXwlbj5aioz xKrVLBL9TfdYQBKcArESExZeZQSxGYGO+35qDROIzSwgLnHryXwmiKMFJJbsOc8MYYtKvHz8 jxXCVpTYeRbiCGYBHYkFuz+xQdjaEssWvoZaLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKs YhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMn4NbfuvuYFz92vEQowAHoxIP74fTZSFCrIll xZW5hxilOViUxHkXnZsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoEx/PajB+JVxzr83Kc+ 4u24+L+VbeLf5p69Jyb/62AS+Voz635GvNStoqNCmye7fGq+teGAjWVl2tJ5S7YWHTlto143 Pcv84ZSeL52nK7kEqm8enayTUhbeXrLYpkg+Uab7jZFaXRBvfr+pxfXF8ysP9kuwhQTui07k lJDMtKiakHwoamvNvGtKLMUZiYZazEXFiQBNo7eVgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/bYssezR1qweJi8-aAMQBHc0rYx8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 10:19:27 -0000 Hi, >> Even with BUNDLE, you would have to use the same m=3D line port value=20 >> from the beginning, which is not allowed. So, you basically would have=20 >> to add the additional SCTPoDTLS m=3D lines once the usage of BUNDLE has = been negotiated. > > > You are right. Section 8.2.1 of draft-ietf-mmusic-sdp-bundle-negotiation > says the m=3D line should have unique 4-tuple to allow possibility of BUN= DLE rejection. Very valid. > However, to facilitate multiple SCTP over same bundled SCTP, won't the fo= llowing work? > - Offerer adds one m=3D line for each SCTP association needed. > - If the answerer selects BUNDLE then all the SCTP m=3D lines now map > and use the same DTLS association. > - If the answerer does not accept BUNDLE then we don't have the option > of negotiating multiple SCTPs over same DTLS anyway; so it will result > in multiple DTLS, which still gives you a way to get multiple SCTPs. > > With this approach a new subsequent SDP offer is not needed to add SCTP m= =3D lines. > Correct. But, still, without BUNDLE you will only be able to negotiate a single SCTP= association per DTLS connection. >>> I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction=20 >>> between use of ICE or not. I believe the semantics for port in m=3D lin= e are=20 >>> different when ICE is used vs. ICE > is not used. >>> - When ICE is used it is the client as well as the server port. >>> - When ICE is not used, the port is the server port and not the=20 >>> client port. For a=3Dsetup:active cases discard port 9 is used per RFC = 4145,=20 >>> which draft-ietf-mmusic-sctp-sdp refers. >>=20 >> Per the agreement in Honolulu, there will be no port 9 for SCTP, as=20 >> the agreement was that both endpoints will initiate the SCTP association= . >>=20 >> And, in order to prevent two separate SCTP associations to be=20 >> established, the m=3D line port needs to indicate both the client and=20 >> server port also without ICE. > > > So, these 2 clarifications are needed in draft-ietf-mmusic-sctp-sdp as it= deviates from referred RFC 4145. > Yes, it will be covered in the next version. But, I also want to be sure that people are ok with such approach. So, if s= omeone thinks we should use the setup attribute to negotiate which endpoint= initiates the SCTP association, please speak up now :) Regards, Christer From nobody Thu Nov 27 05:10:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6B1A88F4 for ; Thu, 27 Nov 2014 05:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4IiEg5ZiUbU for ; Thu, 27 Nov 2014 05:10:34 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E691A88FF for ; Thu, 27 Nov 2014 05:10:33 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 1FD5FCE4CCED6; Thu, 27 Nov 2014 13:10:28 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id sARDATEO026878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Nov 2014 08:10:29 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 08:10:29 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AQHQCVh2RQ9HT1LDRYu/Q2dfZ4TTzJxzCswAgAABnACAAA02gP//08kQgACqQID//7NDoIABTWsA///OI/A= Date: Thu, 27 Nov 2014 13:10:28 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D539F4F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53B3DC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53B3DC@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ak2wenMRRpwZJIoG3MH2yvwpCXA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 13:10:36 -0000 > Hi, >=20 > >> Even with BUNDLE, you would have to use the same m=3D line port value > >> from the beginning, which is not allowed. So, you basically would have > >> to add the additional SCTPoDTLS m=3D lines once the usage of BUNDLE ha= s > been negotiated. > > > > > > You are right. Section 8.2.1 of draft-ietf-mmusic-sdp-bundle-negotiatio= n > > says the m=3D line should have unique 4-tuple to allow possibility of B= UNDLE > rejection. Very valid. > > However, to facilitate multiple SCTP over same bundled SCTP, won't the > following work? > > - Offerer adds one m=3D line for each SCTP association needed. > > - If the answerer selects BUNDLE then all the SCTP m=3D lines now map > > and use the same DTLS association. > > - If the answerer does not accept BUNDLE then we don't have the option > > of negotiating multiple SCTPs over same DTLS anyway; so it will result > > in multiple DTLS, which still gives you a way to get multiple SCTPs. > > > > With this approach a new subsequent SDP offer is not needed to add SCTP= m=3D > lines. > > >=20 > Correct. >=20 > But, still, without BUNDLE you will only be able to negotiate a single SC= TP > association per DTLS connection. This is also apparent from the fact that only one a=3Dsctp-port allowed per= m=3D line. Mandating the use of BUNDLE to allow multiple SCTP associations seems reaso= nable to me. >=20 > >>> I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction > >>> between use of ICE or not. I believe the semantics for port in m=3D l= ine > are > >>> different when ICE is used vs. ICE > is not used. > >>> - When ICE is used it is the client as well as the server port. > >>> - When ICE is not used, the port is the server port and not the > >>> client port. For a=3Dsetup:active cases discard port 9 is used per RF= C > 4145, > >>> which draft-ietf-mmusic-sctp-sdp refers. > >> > >> Per the agreement in Honolulu, there will be no port 9 for SCTP, as > >> the agreement was that both endpoints will initiate the SCTP associati= on. > >> > >> And, in order to prevent two separate SCTP associations to be > >> established, the m=3D line port needs to indicate both the client and > >> server port also without ICE. > > > > > > So, these 2 clarifications are needed in draft-ietf-mmusic-sctp-sdp as = it > deviates from referred RFC 4145. > > >=20 > Yes, it will be covered in the next version. >=20 > But, I also want to be sure that people are ok with such approach. So, if > someone thinks we should use the setup attribute to negotiate which endpo= int > initiates the SCTP association, please speak up now :) I see that the NAT traversal as a big advantage of both peers attempt to op= en SCTP association. SCTP INIT chunk will punch holes in NAT box which will= then allows incoming INIT CHUNK or INT ACK. All this is possible because S= CTP RFC http://tools.ietf.org/html/rfc4960#section-5.2.1 allows such INIT c= ollisions and converts them into a single SCTP association; however the 4-t= uple (+additional IPs) should match though. This is the issue with a=3Dsetup usage for TCP and SDP descriptions (withou= t ICE) specifying only the server port; though TCP allows simultaneous open= , per a=3Dsetup only one side can initiate TCP conn which will not punch a = hole in other end's NAT and results in TCP SYN being dropped.=20 How about the concern of NATs and hosts not supporting simultaneous SCTP op= en? there by limiting the success rate? Similar concerns were voiced here at http://tools.ietf.org/html/rfc6544#app= endix-A for TCP. BR Raju From nobody Thu Nov 27 09:30:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64F71A00C5 for ; Thu, 27 Nov 2014 09:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_As2a6h8EJM for ; Thu, 27 Nov 2014 09:30:07 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CB01A0117 for ; Thu, 27 Nov 2014 09:30:06 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-77-54775f9c5e57 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5E.89.29772.C9F57745; Thu, 27 Nov 2014 18:30:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 18:30:04 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , Salvatore Loreto Thread-Topic: [MMUSIC] Single SCTP usage per SDP session? Thread-Index: AdAIiilGRQ9HT1LDRYu/Q2dfZ4TTzAAxes8AAAUE9XD///IzAP//5OAwgABrp4D//7ZsQIAAlI2A//8E+PAAQ2j9AP//qQ+A Date: Thu, 27 Nov 2014 17:30:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53C0A4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D534E7B@ESESSMB209.ericsson.se> <2649C056-4D86-4448-B71F-A42954E1BF49@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D538EF9@ESESSMB209.ericsson.se> <07B6DC62-93DB-4C15-BECE-68BB70B663FB@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D5390C0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D539F4F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53B3DC@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje6c+PIQg7MvDCymLn/MYtGw8Qqr A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYvWMTa8Fz7oqF+6cwNjBu5uxi5OSQEDCR OL34DyuELSZx4d56ti5GLg4hgSOMEntftLNAOEsYJY79PszYxcjBwSZgIdH9TxukQUSgUuLM 3EVgYWYBdYmri4NAwsJAFfN2tTNDlFhKzPn0HsrOk+jY18ICYrMIqErseHCZCcTmFfCV2Ltu ATPEqkOsEh0Nn8EaOAViJfb8/8kIYjMCHff91BqwBmYBcYlbT+YzQRwtILFkz3lmCFtU4uXj f1DPKEk0LnnCClGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB8XNwy2+DHYwvnzseYhTgYFTi4f1wuixEiDWx rLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwBommWQUHTFCuWHpI 1jT3YebqbR8ip1yMDpi0wvkZX4BDupQwC4Pj38yj07oXG3cmyrucZNsk8+SH8N5bnWnakZk5 H1OW9BzXdD/RfaXow4WlryembTdjmlYwYdb+tsMT58QpCW67Ot07WEbknCmXrWP8Envm54sT 1OymcHcqfMrUTuxyMLukxFKckWioxVxUnAgAjzDGmIACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YFznM04DD1DosMmQVrgLa3MdQKg Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Single SCTP usage per SDP session? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 17:30:09 -0000 Hi, ... >> But, I also want to be sure that people are ok with such approach. So,=20 >> if someone thinks we should use the setup attribute to negotiate which=20 >> endpoint initiates the SCTP association, please speak up now :) > > > I see that the NAT traversal as a big advantage of both peers attempt to = open SCTP association.=20 > SCTP INIT chunk will punch holes in NAT box which will then allows incomi= ng INIT CHUNK or INT=20 > ACK. All this is possible because SCTP RFC http://tools.ietf.org/html/rfc= 4960#section-5.2.1 allows=20 > such INIT collisions and converts them into a single SCTP association; ho= wever the 4-tuple=20 > (+additional IPs) should match though. > This is the issue with a=3Dsetup usage for TCP and SDP descriptions (with= out ICE) specifying only the server=20 > port; though TCP allows simultaneous open, per a=3Dsetup only one side ca= n initiate TCP conn which will > not punch a hole in other end's NAT and results in TCP SYN being dropped.= =20 Not that, in case of 'DTLS/SCTP', the transport layer protocol will be UDP = or TCP, and in case of TCP I assume the setup attribute WILL be used as defined in RFC 4145 when establishing the TCP connection.=20 > How about the concern of NATs and hosts not supporting simultaneous SCTP = open? there by limiting the success rate? I have no idea. (In case of 'DTLS/SCTP' it doesn't matter, though, as the transport layer p= rotocol will be UDP or TCP.) Regards, Christer From nobody Thu Nov 27 12:55:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD961A01D6 for ; Thu, 27 Nov 2014 12:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvIcIXnRFHg2 for ; Thu, 27 Nov 2014 12:55:00 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFF11A01C6 for ; Thu, 27 Nov 2014 12:54:59 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-b2-54778fa17bc6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9A.75.04076.1AF87745; Thu, 27 Nov 2014 21:54:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 21:54:57 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: SCTP-SDP: SDP connection attribute considerations Thread-Index: AdAKgkYeRp59/KWiSPW7X4BmEjVKXw== Date: Thu, 27 Nov 2014 20:54:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53C625@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53C625ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje7C/vIQg5NnlCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP4nHxgL7rlVbL+0haWB8YhtFyMnh4SAicSWbQuYIWwxiQv3 1rN1MXJxCAkcYZSYtuYuI4SzhFFi9a4HQFUcHGwCFhLd/7RBGkQE1CW+7u0Ba2YWyJK4t3IO K0iJsICVxP9LrBAl9hKL1h9gg7D1JK5dXsACYrMIqErsmrmXHcTmFfCVeHrjF1icEeiG76fW MEGMFJe49WQ+E8RtAhJL9pyHulNU4uXjf6wQtpJE45InYGuZBfIlHt5ShxgpKHFy5hOWCYzC s5BMmoVQNQtJFUSJjsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4N93ISC+1KDO5 uDg/Ty8vtWQTIzBKDm75bbWD8eBzx0OMAhyMSjy8H06XhQixJpYVV+YeYpTmYFES5114bl6w kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZHp/chwQ+txE77dD4Iq2E4JfP1/7LM2/U7fAN/ l/jklRmvWSEcqD3n0nm/IC4/71z/t8Kyfz/X6D7X+Sd0S/Ycv4ZZW3OHvcr6x9Pncd1RqLwS t1ezwHTWuQ1zH3x7l6i0+Y9HoXKpeIra9kdGlW2K2p++Nlmenj3vVMVLTpE9D39kc8zYekWJ pTgj0VCLuag4EQDzU5vxcwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hd6IfHO5i6wU7pku2hD_6y6qVok Cc: Gonzalo Camarillo Subject: [MMUSIC] SCTP-SDP: SDP connection attribute considerations X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 20:55:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53C625ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For SCTP-SDP, the general idea is that the SDP connection attribute is used= in the same way as for TCP, i.e. an attribute 'new' value means that a new SCTP association shall be cr= eated. For 'SCTP' there should be no issues. The procedures are more or less ident= ical as for TCP (the difference being that both endpoints initiate the SCTP= association). --- For 'DTLS/SCTP', there are some decisions to make: - If the transport layer protocol is UDP, I assume a 'new' value w= ill not automatically re-establish the DTLS connection - only the SCTP asso= ciation will be re-established. - However, if the transport layer protocol is TCP, does that mean = that a 'new' value will mean that BOTH the TCP connection, AND the SCTP ass= ociation, will be re-established? IF the TCP connection is also re-establis= hed, then I guess the DTLS connection will be re-established. I did not find any text in draft-ietf-tsvwg-sctp-dtls-encaps regarding this= - which probably is because the transport layer protocol is outside the sc= ope of the draft. --- For 'SCTP/DTLS', I assume that 'new' means that the DTLS connection will al= so be re-established, as the underlying SCTP association is re-established.= Also, RFC 6083 says: "Each DTLS connection MUST be established and terminated wi= thin the same SCTP association." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D53C625ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

For SCTP-SDP, the general idea is that the SDP conne= ction attribute is used in the same way as for TCP,

i.e. an attribute ‘new’ value means that= a new SCTP association shall be created.

 

For ‘SCTP’ there should be no issues. Th= e procedures are more or less identical as for TCP (the difference being th= at both endpoints initiate the SCTP association).

 

---

 

For ‘DTLS/SCTP’, there are some decision= s to make:

 

-     &= nbsp;    If the transport layer protocol is UDP, I assume a = ‘new’ value will not automatically re-establish the DTLS connec= tion – only the SCTP association will be re-established.

-     &= nbsp;    However, if the transport layer protocol is TCP, do= es that mean that a ‘new’ value will mean that BOTH the TCP con= nection, AND the SCTP association, will be re-established? IF the TCP conne= ction is also re-established, then I guess the DTLS connection will be re-established.

 

I did not find any text= in draft-ietf-tsvwg-sctp-dtls-encaps regarding this – which probably= is because the transport layer protocol is outside the scope of the draft.=

 

---

 

For ‘SCTP/DTLS’, I assume that ‘ne= w’ means that the DTLS connection will also be re-established, as the= underlying SCTP association is re-established. Also, RFC 6083 says:

 

        &nbs= p;       “Each DTLS connection MUST be estab= lished and terminated within the same SCTP association.”

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D53C625ESESSMB209erics_-- From nobody Fri Nov 28 06:05:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB5F1A1B6C; Fri, 28 Nov 2014 06:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9G55YHOoyhe; Fri, 28 Nov 2014 06:05:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3956F1A1B5A; Fri, 28 Nov 2014 06:05:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141128140523.13879.56557.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 06:05:23 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xkgYfPgDzaqF0mdfvf_xLzmMWGc Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:05:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) Authors : Christer Holmberg Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-08.txt Pages : 16 Date : 2014-11-28 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 28 06:07:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD31A1B4E for ; Fri, 28 Nov 2014 06:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvXtBIJklcuC for ; Fri, 28 Nov 2014 06:07:07 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F281A1A6D for ; Fri, 28 Nov 2014 06:07:06 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-31-547881885d6c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.0C.04076.88188745; Fri, 28 Nov 2014 15:07:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 15:07:04 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-sctp-sdp-08 Thread-Index: AdALFJYLwCZg+j5sQF22m75SsfBMZg== Date: Fri, 28 Nov 2014 14:07:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53F54A@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.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53F54AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW5nY0WIwdFJLBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtm7d9gK1shW7D/UwdjAeEeyi5GTQ0LAROLx4dWMELaYxIV7 69m6GLk4hASOMEqsfbaUHcJZwihx6e9y5i5GDg42AQuJ7n/aIA0iAuoSX/f2MIPYwgKWEk8O b2GBiNtJnF6+FsrWk3g78Q4TiM0ioCrxef50VhCbV8BX4sbX82BxRqDF30+tAbOZBcQlbj2Z zwRxkIDEkj3nmSFsUYmXj/+xQthKEj82XGKBqM+X+D/xAzPETEGJkzOfsExgFJqFZNQsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eakl mxiBMXFwy2+rHYwHnzseYhTgYFTi4S2QrQgRYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MSffvZvj/03xwfNqu+bdmzXE0LN6ucltVZoOQmcVN/4g9s1zj 2VeFTZosbbVqqqGr/pl/GwX5I15XiU2rWbKlqf7tz8eCseY9ySy996deZKrcfurL9xWxiXsa C022vhfw1u//drj89+/cfF8l98OP9qXucD03qfSklkzzloVHV5pWCFft/5j+WomlOCPRUIu5 qDgRAFNS1wNqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3LazR1CSji4EA9f7kacethl85Ns Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:07:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53F54AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the SCTP-SDP draft. There has been quite bi= g editorial changes from the previous version. New stuff, including the SDP= Offer/Answer procedures, have been added. I have yet NOT changed the proto values (e.g 'DTLS/SCTP' -> 'UDP/DTLS/SCTP'= ). In Honolulu there was a generic discussion regarding that, whether to us= e "DTLS" or "TLS" etc, and I'd like to see some documented outcome regardin= g that before changing. There are currently two open issue (of which one is related to the proto va= lues) documented in the draft. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D53F54AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of the SCTP-SDP d= raft. There has been quite big editorial changes from the previous version.= New stuff, including the SDP Offer/Answer procedures, have been added.

 

I have yet NOT changed the proto values (e.g ‘= DTLS/SCTP’ -> ‘UDP/DTLS/SCTP’). In Honolulu there was = a generic discussion regarding that, whether to use “DTLS” or &= #8220;TLS” etc, and I’d like to see some documented outcome reg= arding that before changing.

 

There are currently two open issue (of which one is = related to the proto values) documented in the draft.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D53F54AESESSMB209erics_--