From nobody Wed Apr 1 03:47:31 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177E01A0141 for ; Wed, 1 Apr 2015 03:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idrxWAQgaM2K for ; Wed, 1 Apr 2015 03:47:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270AA1A00CD for ; Wed, 1 Apr 2015 03:47:26 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-b4-551bccbcc96b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.15.28347.CBCCB155; Wed, 1 Apr 2015 12:47:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 12:47:24 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UA== Date: Wed, 1 Apr 2015 10:47:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7eM9KhBhPO81lMXf6YxWLGhanM DkweS5b8ZPK4NaUggCmKyyYlNSezLLVI3y6BK+PW5dyCLumK/llv2BoYN0h1MXJySAiYSMw7 28oCYYtJXLi3nq2LkYtDSOAoo0Tfx4tQzmJGiW1XVjJ1MXJwsAlYSHT/0wZpEBFQlfj7fTIT iM0sICMx42wjmC0sYCnxbcMUJogaK4neCUuYIewwiUMz7rCC2CwCKhIrz61jA7F5BXwljizb ygixaxWzxMppe8GKOAUCJXbdewM2iBHouu+n1kAtE5e49WQ+E8TVAhJL9pxnhrBFJV4+/scK YStKfHy1jxHkZmYBTYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F0DELSccsJB0LGFlW MYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRGzsEtvw12ML587niIUYCDUYmHN6FTOlSINbGs uDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyZJt/MnaZm3NNLVy7p eCNXs64nTelGuaeMYkHPTEnd1ebMof0+Pzbc9lrscE+3a/XM5wtrC5iDO93XzJjzKuZN+xa9 WVvOnLSa1Kb1evarqRKzLl45GrvkR7dQ7YXLDzLenzqwteMAR4p29IObjBYW0Wbm51oMtzEX Xz7JLremQ59P//rK6eZKLMUZiYZazEXFiQBmR8EsfQIAAA== Archived-At: Cc: mmusic Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 10:47:30 -0000 SGkgUm9tYW4sDQoNCj4+PiBUaGUgbm90ZSB0ZWxscyB3aGF0IGRvZXMgbm90IHRyaWdnZXIgc2V0 dXAgb2YgdGhlIG5ldyBEVExTIGNvbm5lY3Rpb24gaW4gY2FzZSBvZiBJQ0UuIEl0IGRvZXMgbm90 IHNwZWNpZnkgd2hhdCBkb2VzLiBJIGFsc28gDQo+Pj4gdGhpbmsgaXQgaXPCoGFtYmlndW91cy4g Q3VycmVudCBsYW5ndWFnZSBpbXBsaWVzIHRoYXQgYWxsIGNhbmRpZGF0ZSBwYWlycyBhc3NvY2lh dGVkIHdpdGggU0NUUMKgYXNzb2NpYXRpb24gYXJlIHRoZSBzYW1lIA0KPj4+IHRyYW5zcG9ydC7C oCBEb2VzIHRoaXMgbWVhbiB0aGF0IGlmIFNDVFAgY29ubmVjdGlvbiBpcyBub3QgcmUtZXN0YWJs aXNoZWQgYW5kIElDRSBpcyB1c2VkLCBuZXcgRFRMUyBzZXNzaW9uIGlzIG5vdCBzdGFydGVkPyAN Cj4+PiBPcsKgZG9lcyBpdCBtZWFuIHRoYXQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGlzIHNldHVw IGZvciBlYWNoIG5ldyBJQ0Ugc2Vzc2lvbj8gV2hhdCBhYm91dCBJQ0UgcmVzdGFydCAoaS5lLiB1 ZnJhZyBjaGFuZ2UgDQo+Pj4gYmV0d2VlbiB0aGUgc2FtZSBlbmQgcG9pbnRzIHdoZW4gdGhlIHNh bWUgY2FuZGlkYXRlIHNldHMgYXJlIHJldXNlZCBvbiBib3RoIHNpZGVzKT8NCj4+wqANCj4+IFRo ZSBpZGVhIGlzIHRoYXQgYSBjaGFuZ2Ugb2YgdGhlIGZpbmdlcnByaW50IHdvdWxkIHRyaWdnZXIg YSBuZXcgRFRMUyBjb25uZWN0aW9uLg0KPj4NCj4+QnV0LCBpbiBvcmRlciB0byBhdm9pZCB0aGUg cmVjZWl2aW5nLXBhY2tldHMtYXNzb2NpYXRlZC13aXRoLW9sZC1rZXlzIGlzc3VlIChyYWlzZWQg YnkgeW91cnNlbGYgZWFybGllcikgdGhlIHN1Z2dlc3Rpb24gd2FzIHRoYXQgdGhlIHRyYW5zcG9y dCA1LXR1cGxlIGFsc28gbmVlZHMgdG8gY2hhbmdlLg0KPj7CoA0KPj4gSSBhZ3JlZSBzb21lIHdv cmRpbmcgaXMgbmVlZGVkIGFib3V0IHRoYXQuDQo+DQo+IFRoZSBpZGVhIHdhcyBhbHNvIHRoYXQg ZmluZ2VycHJpbnQgY2FuIG9ubHkgY2hhbmdlIGlmIHVuZGVybHlpbmcgdHJhbnNwb3J0IGNoYW5n ZXMgYXMgd2VsbC4gSSB0aGluayB3ZSBuZWVkIHRvIGRlZmluZSB3aGF0IHRoaXMgbWVhbnMgaW4g Y2FzZSBvZiBJQ0UsIHNpbmNlIDUtdHVwbGUNCj4gY2hhbmdlLCB3aGVuIElDRSBpcyB1c2VkLCBp cyBub3QgbmVjZXNzYXJpbHkgYSB0cmFuc3BvcnQgY2hhbmdlIChhcyBpbiBjYXNlcyB3aGVuIGl0 IGlzIGEgY2hhbmdlIGJldHdlZW4gdGhlIGNhbmRpZGF0ZSBwYWlycykuDQoNCkNvcnJlY3QsIGFu ZCB0aGF0IGlzIHdoYXQgdGhlICJ2aXJ0dWFsIGNvbm5lY3Rpb24iIGlzIGFsbCBhYm91dC4gQSBj aGFuZ2UgdG8gYW5vdGhlciBjYW5kaWRhdGUgcGFpciBpcyBOT1QgY29uc2lkZXJlZCBhIHRyYW5z cG9ydCBjaGFuZ2UuIA0KDQpJbiBmYWN0LCBKdXN0aW4gZm91bmQgdGV4dCBpbiBSRkMgNTc2MyAo c2VjdGlvbiA2LjcuMSkgd2hpY2ggYWxyZWFkeSBkZWZpbmVzIHRoYXQ6DQoNCgkiSW1wbGVtZW50 YXRpb25zIE1VU1QgdHJlYXQgYWxsIElDRSBjYW5kaWRhdGUgcGFpcnMgYXNzb2NpYXRlZCB3aXRo IGEgc2luZ2xlIGNvbXBvbmVudCBhcyBwYXJ0IG9mIHRoZQ0KCXNhbWUgRFRMUyBhc3NvY2lhdGlv bi4gVGh1cywgdGhlcmUgd2lsbCBiZSBvbmx5IG9uZSBEVExTIGhhbmRzaGFrZSBldmVuIGlmIHRo ZXJlIGFyZSBtdWx0aXBsZSB2YWxpZCANCgljYW5kaWRhdGUgcGFpcnMuIg0KDQpJIHVzZWQgdGhp cyB0ZXh0ICh3aXRoIHNvbWUgbWlub3IgY2hhbmdlcykgaW4gbXkgc3VnZ2VzdGVkIHRleHQgZm9y IHRoZSBTQ1RQLVNEUCBkcmFmdC4gSSB3YXMgc3VwcG9zZWQgdG8gYWxzbyByZWZlcmVuY2UgNTc2 MywgYnV0IEkgc2VlIHRoYXQgSSBmb3Jnb3QgdG8gcmVwbGFjZSAiW2FkZC1yZWZlcmVuY2VdIiB3 aXRoICJbUkZDNTc2M10iLg0KDQo+IEkgdGhpbmsgdGhlIGludGVudCBpcywgdGhhdCBpbiBjYXNl IG9mIElDRSwgRFRMUyBmaW5nZXJwcmludCBjYW4gY2hhbmdlIG9ubHkgaWYgbmV3IHVmcmFnIGlz IHVzZWQgKG5ldyBJQ0Ugc2Vzc2lvbikgYW5kIGVudGlyZSBjYW5kaWRhdGUgbGlzdCANCj4gY2hh bmdlcyAobm90IGFuIElDRSByZXN0YXJ0IG9uIGV4aXN0aW5nIGNhbmRpZGF0ZXMpLiBJIHdvdWxk IHJlYWxseSBsaWtlIHRvIHNlZSBpZiB0aGUgcmVzdCBvZiB0aGUgcGVvcGxlIG9uIHRoZSBsaXN0 IGFncmVlIGFuZCB0aGlzIGRlY2lzaW9uIGlzIGRvY3VtZW50ZWQgc29tZXdoZXJlLg0KDQpXaXRo IG9yIHdpdGhvdXQgSUNFLCB0aGUgaWRlYSBpcyB0aGF0IGEgZmluZ2VycHJpbnQgY2hhbmdlIGlz ICpvbmx5KiBhbGxvd2VkIGlmIHRoZSBEVExTIGNvbm5lY3Rpb24gaXMgbW92ZWQgdG8gYW5vdGhl ciBkZXZpY2Uvc3RhY2ssIGUuZy4gaW4gdGhlIGNhc2Ugb2YgM3BjYy4NCg0KQmVsb3cgaXMgdGhl IGxpbmsgdG8gdGhlIHNsaWRlcyBKdXN0aW4gcHJlcGFyZWQ6DQoNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1tbXVzaWMtOC5wZGYNCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KwqANCg== From nobody Wed Apr 1 08:29:28 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0301C1ACD86 for ; Wed, 1 Apr 2015 08:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T10orjxtT0N for ; Wed, 1 Apr 2015 08:29:25 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFAB1ACD80 for ; Wed, 1 Apr 2015 08:29:24 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so49409202igc.0 for ; Wed, 01 Apr 2015 08:29:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8rBEf5troIuZ3jQNbzp1JM20gDi0dk672wBv8pAqBi4=; b=G5QboavsrhlpsIrpORbPAnahoAnavRKuXKGGO4fupyHD8ZXaqlzudhQtXENUwTH2S8 jxs82m6tdIKw/xQpYpEXg/EssgO2WDApWJsNO6yJAvrlWaWEET9a7TpFVD3GJoqMaT8s 4EolN9R2Ptkg6CrpF75cCxAPm6cFn1RS5Nv3UwKF4ROg55BXRXjRNmk1bUG2iReWg9f+ I0DNQ+dq70e3a16xHiDA+nooNuXZh+VZHzoW6+BG+jmHJS35ulWOkkDub1iplW5Tp3rA Vr98TvGEyXDV7tHXodoL+Mvppi5cB87/LtI7W7vio9kKCppRH39ELtBkV34+OFypSrLK FLig== X-Gm-Message-State: ALoCoQkA6Z6QHgl2aQMEU7SGCmS/1RtO+10tvgIwd/piyg4S0jXe9T6AbzXHXxCokxop0HYVIoUA X-Received: by 10.42.119.202 with SMTP id c10mr74662630icr.4.1427902164316; Wed, 01 Apr 2015 08:29:24 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com. [209.85.223.170]) by mx.google.com with ESMTPSA id u19sm1368137iou.18.2015.04.01.08.29.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 08:29:23 -0700 (PDT) Received: by ierf6 with SMTP id f6so45996148ier.2 for ; Wed, 01 Apr 2015 08:29:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.69.68 with SMTP id yb4mr73861646icb.96.1427902162130; Wed, 01 Apr 2015 08:29:22 -0700 (PDT) Received: by 10.36.124.86 with HTTP; Wed, 1 Apr 2015 08:29:22 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> Date: Wed, 1 Apr 2015 11:29:22 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec51b1be925eb450512ab614b Archived-At: Cc: mmusic Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:29:27 -0000 --bcaec51b1be925eb450512ab614b Content-Type: text/plain; charset=UTF-8 Hi Christer, I have looked through the slides and I think they are misleading. To me they seem to imply that DTLS association is orthogonal to transport and only gets re-established when fingerprint changes. In other words, even if the underlying transport changes, but fingerprint stays the same, the slides imply that existing DTLS association continues to be used with the new transport. BTW, I think this is what Chrome is currently doing. This behavior is against the proposed specification language ("If the underlying transport protocol is modified, the endpoints MUST establish a new DTLS connection"). This also presents a serious problem in the use case where third party call control is used to move the call between the several end point that use the same site-wide certificate. All of those end points will present the same fingerprint, but the DTLS connection will need to be re-established since the media connection is moved to a different device. This also shows that fingerprint alone cannot be used to determine that connection moved to the new device. I thought the logic that made sense was: 1. DTLS connection is re-established whenever underlying transport changes (already in the specification). 2. Fingerprint and setup role MUST not change unless underlying transport changes as well (already in the specification). 3. Unless ICE is used, underlying transport is considered changed if 5-tuple for connection changes (already in the specification) 4. In case of ICE, the underlying transport is considered changed if ufrag and entire candidate list changed on either side of the call (missing from the current specification). In the proposed text, the issue that I have is with the phrase "Implementations MUST treat all ICE candidate pairs associated with a an SCTP association on top of a DTLS connection as part of the same DTLS connection". I am not 100% sure what this means and even if this is accurate. "All ICE candidate pairs associated with a an SCTP association" is unclear to me. Does this refer only to the candidate pairs for the current ICE session or to the candidate pairs for any future ICE sessions associated with this SCTP association? Original text from RFC 5763 ("Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association") is more accurate but suffers from the fact that "single component" is not well defined and because of this runs into similar issues. Does ICE re-start creates a new component or is old component considered to be re-used? If component is specific to ICE session (ufrag pair), can candidates from the previous session be re-used for negotiating a new component? If they can, how do you de-mux packets received between old and new component if candidates were reused on both sides. _____________ Roman Shpount --bcaec51b1be925eb450512ab614b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Christer,

I have looked through the slides and I think they are = misleading. To me they seem to imply that DTLS association is orthogonal to= transport and only gets re-established when fingerprint changes. In other = words, even if the underlying transport changes, but fingerprint stays the = same, the slides imply that existing DTLS association continues to be used = with the new transport. BTW, I think this is what Chrome is currently doing= . This behavior is against the proposed specification language ("If th= e underlying transport protocol is modified, the endpoints MUST establish a= new DTLS connection"). This also presents a serious problem in the us= e case where third party call control is used to move the call between the = several end point that use the same site-wide certificate. All of those end= points will present the same fingerprint, but the DTLS connection will nee= d to be re-established since the media connection is moved to a different d= evice. This also shows that fingerprint alone cannot be used to determine t= hat connection moved to the new device.
I thought the logic that made sense was:<= /div>
1. DTLS connection is re-established whenev= er underlying transport changes (already in the specification).
2. Fingerprint and setup role MUST not change unless u= nderlying transport changes as well (already in the specification).
3. Unless ICE is used, underlying transport is con= sidered changed if 5-tuple for connection changes=C2=A0=C2=A0(already in th= e specification)
4. In case of ICE, the und= erlying transport is considered changed if ufrag and entire candidate list = changed on either side of the call (missing from the current specification)= .

In t= he proposed text, the issue that I have is with the phrase "Implementa= tions MUST treat all ICE candidate pairs associated with a=C2=A0an SCTP ass= ociation on top of a DTLS connection as part of the same=C2=A0DTLS connecti= on". I am not 100% sure what this means and even if this is accurate. = "All ICE candidate pairs associated with a=C2=A0an SCTP association&qu= ot; is unclear to me. Does this refer only to the candidate pairs for the c= urrent ICE session or to the candidate pairs for any future ICE sessions as= sociated with this SCTP association?

Original text from RFC 5763 ("Implement= ations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association") is more accurate but suffers from the fact th= at "single component" is not well defined and because of this run= s into similar issues. Does ICE re-start creates a new component or is old = component considered to be re-used? If=C2=A0component=C2=A0is specific to I= CE session=C2=A0(ufrag pair), can candidates from the previous session be r= e-used for negotiating a new component? If they can, how do you de-mux pack= ets received between old and new component if candidates were reused on bot= h sides.
_____________
Roman Shpount

--bcaec51b1be925eb450512ab614b-- From nobody Wed Apr 1 12:42:34 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B701A3B9C for ; Wed, 1 Apr 2015 12:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1OxgAWAjBZo for ; Wed, 1 Apr 2015 12:42:32 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96011A1A7C for ; Wed, 1 Apr 2015 12:42:30 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-15-551c4a2436a1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.18.28347.42A4C155; Wed, 1 Apr 2015 21:42:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 21:42:28 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnA= Date: Wed, 1 Apr 2015 19:42:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@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_7594FB04B1934943A5C02806D1A2204B1D788924ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3RlfFSybUYNJpE4upyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZazpP8VacGUWY8Wm7U+YGxiPTGPsYuTkkBAw kXj/ZhoLhC0mceHeerYuRi4OIYGjjBJrnh9nhHAWM0oc3tPC1MXIwcEmYCHR/U8bpEFEQFXi 7/fJTCA2s4CMxIyzjWC2sIClxLcNU5ggaqwkeicsYYawkyTunDzACmKzCKhIPGxaDLaYV8BX 4sSsw8wQu7aySJxqvcYOkuAUCJToXHoDbBAj0HXfT62BWiYucevJfCaIqwUkluw5zwxhi0q8 fPyPFcJWklh0+zNUfb7E/Zcn2CGWCUqcnPmEZQKj6Cwko2YhKZuFpGwW0MvMApoS63fpQ5Qo SkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYMQd3PLbYAfj y+eOhxgFOBiVeHgTOqVDhVgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAKPn8w4q3tm9X3ZJfsGnFRouWVTvNb6kf/OX7qknlw1+ReMtV+//9CJAMeDsxQu7t X2+vQlv/Fr3V9xcfuCqxr0jUIp3F0eDKjEi7aZrKRo8WVzxap8nFwr5F4HCkbpuqkGXy+fZ3 ppfC6/ULZ3/8UtT8yfr7r7lPRYv+uueYRl86ePPpwysbZJRYijMSDbWYi4oTAWFjyPuZAgAA Archived-At: Cc: mmusic Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:42:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D788924ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCj5JIGhhdmUgbG9va2VkIHRocm91Z2ggdGhlIHNsaWRlcyBhbmQgSSB0aGlu ayB0aGV5IGFyZSBtaXNsZWFkaW5nLiBUbyBtZSB0aGV5IHNlZW0gdG8gaW1wbHkgdGhhdCBEVExT ID5hc3NvY2lhdGlvbiBpcyBvcnRob2dvbmFsIHRvIHRyYW5zcG9ydCBhbmQgb25seSBnZXRzIHJl LWVzdGFibGlzaGVkIHdoZW4gZmluZ2VycHJpbnQgY2hhbmdlcy4NCg0KVGhhdCB3YXMgbW9yZSBv ciBsZXNzIHRoZSBhcHByb2FjaCBwZW9wbGUgd2FudGVkIHRvIHRha2UsIHdoZW4gdGhpcyB3YXMg ZGlzY3Vzc2VkIGluIERhbGxhcy4NCg0KPkluIG90aGVyIHdvcmRzLCBldmVuIGlmIHRoZSB1bmRl cmx5aW5nIHRyYW5zcG9ydCBjaGFuZ2VzLCBidXQgZmluZ2VycHJpbnQgc3RheXMgdGhlIHNhbWUs IHRoZSBzbGlkZXMgaW1wbHkgdGhhdCA+ZXhpc3RpbmcgRFRMUyBhc3NvY2lhdGlvbiBjb250aW51 ZXMgdG8gYmUgdXNlZCB3aXRoIHRoZSBuZXcgdHJhbnNwb3J0LiBCVFcsIEkgdGhpbmsgdGhpcyBp cyB3aGF0IENocm9tZSBpcyA+Y3VycmVudGx5IGRvaW5nLiBUaGlzIGJlaGF2aW9yIGlzIGFnYWlu c3QgdGhlIHByb3Bvc2VkIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UgKCJJZiB0aGUgdW5kZXJseWlu ZyB0cmFuc3BvcnQgPnByb3RvY29sIGlzIG1vZGlmaWVkLCB0aGUgZW5kcG9pbnRzIE1VU1QgZXN0 YWJsaXNoIGEgbmV3IERUTFMgY29ubmVjdGlvbiIpLiBUaGlzIGFsc28gcHJlc2VudHMgYSBzZXJp b3VzID5wcm9ibGVtIGluIHRoZSB1c2UgY2FzZSB3aGVyZSB0aGlyZCBwYXJ0eSBjYWxsIGNvbnRy b2wgaXMgdXNlZCB0byBtb3ZlIHRoZSBjYWxsIGJldHdlZW4gdGhlIHNldmVyYWwgZW5kIHBvaW50 ID50aGF0IHVzZSB0aGUgc2FtZSBzaXRlLXdpZGUgY2VydGlmaWNhdGUuIEFsbCBvZiB0aG9zZSBl bmQgcG9pbnRzIHdpbGwgcHJlc2VudCB0aGUgc2FtZSBmaW5nZXJwcmludCwgYnV0IHRoZSBEVExT ID5jb25uZWN0aW9uIHdpbGwgbmVlZCB0byBiZSByZS1lc3RhYmxpc2hlZCBzaW5jZSB0aGUgbWVk aWEgY29ubmVjdGlvbiBpcyBtb3ZlZCB0byBhIGRpZmZlcmVudCBkZXZpY2UuIFRoaXMgYWxzbyA+ c2hvd3MgdGhhdCBmaW5nZXJwcmludCBhbG9uZSBjYW5ub3QgYmUgdXNlZCB0byBkZXRlcm1pbmUg dGhhdCBjb25uZWN0aW9uIG1vdmVkIHRvIHRoZSBuZXcgZGV2aWNlLg0KDQpJIHRoaW5rIHRoZSBh c3N1bXB0aW9uIHBlb3BsZSBoYWQgd2FzIHRoYXQsIGlmIHRoZSBkZXZpY2UgY2hhbmdlcywgdGhl IGZpbmdlcnByaW50IHdpbGwgYWxzbyBjaGFuZ2UuDQoNCk5vdywgaWYgd2UgY2Fubm90IG1ha2Ug dGhhdCBhc3N1bXB0aW9uLCB3ZSBuZWVkIHRvIHJlLXZpc2l0IGl0Lg0KDQo+SSB0aG91Z2h0IHRo ZSBsb2dpYyB0aGF0IG1hZGUgc2Vuc2Ugd2FzOg0KPjEuIERUTFMgY29ubmVjdGlvbiBpcyByZS1l c3RhYmxpc2hlZCB3aGVuZXZlciB1bmRlcmx5aW5nIHRyYW5zcG9ydCBjaGFuZ2VzIChhbHJlYWR5 IGluIHRoZSBzcGVjaWZpY2F0aW9uKS4NCj4yLiBGaW5nZXJwcmludCBhbmQgc2V0dXAgcm9sZSBN VVNUIG5vdCBjaGFuZ2UgdW5sZXNzIHVuZGVybHlpbmcgdHJhbnNwb3J0IGNoYW5nZXMgYXMgd2Vs bCAoYWxyZWFkeSBpbiB0aGUgPnNwZWNpZmljYXRpb24pLg0KPjMuIFVubGVzcyBJQ0UgaXMgdXNl ZCwgdW5kZXJseWluZyB0cmFuc3BvcnQgaXMgY29uc2lkZXJlZCBjaGFuZ2VkIGlmIDUtdHVwbGUg Zm9yIGNvbm5lY3Rpb24gY2hhbmdlcyAgKGFscmVhZHkgPmluIHRoZSBzcGVjaWZpY2F0aW9uKQ0K DQpDb3JyZWN0Lg0KDQo+NC4gSW4gY2FzZSBvZiBJQ0UsIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9y dCBpcyBjb25zaWRlcmVkIGNoYW5nZWQgaWYgdWZyYWcgYW5kIGVudGlyZSBjYW5kaWRhdGUgbGlz dCBjaGFuZ2VkIG9uID5laXRoZXIgc2lkZSBvZiB0aGUgY2FsbCAobWlzc2luZyBmcm9tIHRoZSBj dXJyZW50IHNwZWNpZmljYXRpb24pLg0KDQpXZSBuZWVkIHRvIGJlIGNsZWFyIHdoYXQgd2UgbWVh biBieSDigJxlbnRpcmUgY2FuZGlkYXRlIGxpc3TigJ0uIERvIHlvdSBtZWFuIGEgbmV3IFNEUCwg d2hpY2ggb25seSBjb250YWlucyBjYW5kaWRhdGVzIHRoYXQgaGF2ZSBuZXZlciBiZWVuIHVzZWQg YmVmb3JlIGR1cmluZyB0aGUgc2Vzc2lvbj8NCg0KT2J2aW91c2x5LCB0aGUgSVAgYWRkcmVzczpw b3J0IHByb3BlcnRpZXMgbWF5IHN0aWxsIGJlIHRoZSBzYW1lLCBzbyBJIGd1ZXNzIHRoZSB1ZnJh ZyB3b3VsZCBoYXZlIHRvIGJlIGRpZmZlcmVudCDigJMgYXMgeW91IHNheS4NCg0KQlVULCBJIHRo aW5rIHNvbWVvbmUgaW4gRGFsbGFzIGhhZCBhIGNvbW1lbnQgb24gd2h5IHVmcmFnIGNhbuKAmXQg YmUgdXNlZC4gSnVzdGluPyBFa3I/DQoNCj5JbiB0aGUgcHJvcG9zZWQgdGV4dCwgdGhlIGlzc3Vl IHRoYXQgSSBoYXZlIGlzIHdpdGggdGhlIHBocmFzZSAiSW1wbGVtZW50YXRpb25zIE1VU1QgdHJl YXQgYWxsIElDRSBjYW5kaWRhdGUgPnBhaXJzIGFzc29jaWF0ZWQgd2l0aCBhIGFuIFNDVFAgYXNz b2NpYXRpb24gb24gdG9wIG9mIGEgRFRMUyBjb25uZWN0aW9uIGFzIHBhcnQgb2YgdGhlIHNhbWUg RFRMUyA+Y29ubmVjdGlvbiIuIEkgYW0gbm90IDEwMCUgc3VyZSB3aGF0IHRoaXMgbWVhbnMgYW5k IGV2ZW4gaWYgdGhpcyBpcyBhY2N1cmF0ZS4gIkFsbCBJQ0UgY2FuZGlkYXRlIHBhaXJzID5hc3Nv Y2lhdGVkIHdpdGggYSBhbiBTQ1RQIGFzc29jaWF0aW9uIiBpcyB1bmNsZWFyIHRvIG1lLiBEb2Vz IHRoaXMgcmVmZXIgb25seSB0byB0aGUgY2FuZGlkYXRlIHBhaXJzIGZvciB0aGUgPmN1cnJlbnQg SUNFIHNlc3Npb24gb3IgdG8gdGhlIGNhbmRpZGF0ZSBwYWlycyBmb3IgYW55IGZ1dHVyZSBJQ0Ug c2Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgU0NUUCA+YXNzb2NpYXRpb24/DQoNCkN1cnJl bnQgQU5EIGZ1dHVyZS4gVGhlcmUgYXJlIHByb3Bvc2FscyBhYm91dCB0aGUgcG9zc2liaWxpdHkg b2YgZHluYW1pY2FsbHkgYWRkaW5nIG5ldyBjYW5kaWRhdGVzIGR1cmluZyB0aGUgc2Vzc2lvbiwg YW5kIHRoZXkgd291bGQgYmUgcGFydCBvZiB0aGUgc2FtZSBEVExTIGNvbm5lY3Rpb24uDQoNCj5P cmlnaW5hbCB0ZXh0IGZyb20gUkZDIDU3NjMgKCJJbXBsZW1lbnRhdGlvbnMgTVVTVCB0cmVhdCBh bGwgSUNFIGNhbmRpZGF0ZSBwYWlycyBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUgPmNvbXBvbmVu dCBhcyBwYXJ0IG9mIHRoZSBzYW1lIERUTFMgYXNzb2NpYXRpb24iKSBpcyBtb3JlIGFjY3VyYXRl IGJ1dCBzdWZmZXJzIGZyb20gdGhlIGZhY3QgdGhhdCAic2luZ2xlID5jb21wb25lbnQiIGlzIG5v dCB3ZWxsIGRlZmluZWQgYW5kIGJlY2F1c2Ugb2YgdGhpcyBydW5zIGludG8gc2ltaWxhciBpc3N1 ZXMuIERvZXMgSUNFIHJlLXN0YXJ0IGNyZWF0ZXMgYSBuZXcgPmNvbXBvbmVudCBvciBpcyBvbGQg Y29tcG9uZW50IGNvbnNpZGVyZWQgdG8gYmUgcmUtdXNlZD8gSWYgY29tcG9uZW50IGlzIHNwZWNp ZmljIHRvIElDRSBzZXNzaW9uICh1ZnJhZyBwYWlyKSwgPmNhbiBjYW5kaWRhdGVzIGZyb20gdGhl IHByZXZpb3VzIHNlc3Npb24gYmUgcmUtdXNlZCBmb3IgbmVnb3RpYXRpbmcgYSBuZXcgY29tcG9u ZW50PyBJZiB0aGV5IGNhbiwgaG93IGRvID55b3UgZGUtbXV4IHBhY2tldHMgcmVjZWl2ZWQgYmV0 d2VlbiBvbGQgYW5kIG5ldyBjb21wb25lbnQgaWYgY2FuZGlkYXRlcyB3ZXJlIHJldXNlZCBvbiBi b3RoIHNpZGVzLg0KDQpQZW9wbGUgaGFkIGlzc3VlcyB3aXRoIHRoZSB1c2FnZSBvZiDigJxjb21w b25lbnTigJ0gdG9vLCBidXQgSeKAmWQgbmVlZCB0byBkb3VibGUgY2hlY2sgd2l0aCB0aGUgbWlu dXRlcy9yZWNvcmRpbmcgZm9yIHRoZSBkZXRhaWxzLg0KDQpBbmQsIG15IGludGVudGlvbiB3YXMg bm90IHRvIGRldmlhdGUgZnJvbSB0aGUgNTc2MyB0ZXh0IG9uIHB1cnBvc2UuIEkgZm9yIHN1cmUg Y2FuIHVzZSB0aGF0IHRleHQsIGlmIHlvdSB0aGluayBpdCBpcyBtb3JlIGFjY3VyYXRlIChhc3N1 bWluZyB0aGF0IHRoZXJlIGFyZSBubyBpc3N1ZXMgd2l0aCB1c2FnZSBvZiDigJxjb21wb25lbnTi gJ0pLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D788924ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSb21hbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0kg aGF2ZSBsb29rZWQgdGhyb3VnaCB0aGUgc2xpZGVzIGFuZCBJIHRoaW5rIHRoZXkgYXJlIG1pc2xl YWRpbmcuIFRvIG1lIHRoZXkgc2VlbSB0byBpbXBseSB0aGF0IERUTFMgJmd0O2Fzc29jaWF0aW9u IGlzIG9ydGhvZ29uYWwgdG8gdHJhbnNwb3J0IGFuZCBvbmx5IGdldHMgcmUtZXN0YWJsaXNoZWQg d2hlbiBmaW5nZXJwcmludCBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYXQgd2FzIG1vcmUgb3IgbGVzcyB0 aGUgYXBwcm9hY2ggcGVvcGxlIHdhbnRlZCB0byB0YWtlLCB3aGVuIHRoaXMgd2FzIGRpc2N1c3Nl ZCBpbiBEYWxsYXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7SW4gb3RoZXIgd29yZHMsIGV2ZW4gaWYgdGhlIHVuZGVybHlpbmcgdHJh bnNwb3J0IGNoYW5nZXMsIGJ1dCBmaW5nZXJwcmludCBzdGF5cyB0aGUgc2FtZSwgdGhlIHNsaWRl cyBpbXBseSB0aGF0ICZndDtleGlzdGluZyBEVExTIGFzc29jaWF0aW9uIGNvbnRpbnVlcyB0byBi ZSB1c2VkIHdpdGggdGhlIG5ldyB0cmFuc3BvcnQuIEJUVywgSSB0aGluayB0aGlzIGlzIHdoYXQg Q2hyb21lIGlzICZndDtjdXJyZW50bHkgZG9pbmcuDQogVGhpcyBiZWhhdmlvciBpcyBhZ2FpbnN0 IHRoZSBwcm9wb3NlZCBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlICgmcXVvdDtJZiB0aGUgdW5kZXJs eWluZyB0cmFuc3BvcnQgJmd0O3Byb3RvY29sIGlzIG1vZGlmaWVkLCB0aGUgZW5kcG9pbnRzIE1V U1QgZXN0YWJsaXNoIGEgbmV3IERUTFMgY29ubmVjdGlvbiZxdW90OykuIFRoaXMgYWxzbyBwcmVz ZW50cyBhIHNlcmlvdXMgJmd0O3Byb2JsZW0gaW4gdGhlIHVzZSBjYXNlIHdoZXJlIHRoaXJkIHBh cnR5IGNhbGwgY29udHJvbCBpcw0KIHVzZWQgdG8gbW92ZSB0aGUgY2FsbCBiZXR3ZWVuIHRoZSBz ZXZlcmFsIGVuZCBwb2ludCAmZ3Q7dGhhdCB1c2UgdGhlIHNhbWUgc2l0ZS13aWRlIGNlcnRpZmlj YXRlLiBBbGwgb2YgdGhvc2UgZW5kIHBvaW50cyB3aWxsIHByZXNlbnQgdGhlIHNhbWUgZmluZ2Vy cHJpbnQsIGJ1dCB0aGUgRFRMUyAmZ3Q7Y29ubmVjdGlvbiB3aWxsIG5lZWQgdG8gYmUgcmUtZXN0 YWJsaXNoZWQgc2luY2UgdGhlIG1lZGlhIGNvbm5lY3Rpb24gaXMgbW92ZWQgdG8gYSBkaWZmZXJl bnQNCiBkZXZpY2UuIFRoaXMgYWxzbyAmZ3Q7c2hvd3MgdGhhdCBmaW5nZXJwcmludCBhbG9uZSBj YW5ub3QgYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhhdCBjb25uZWN0aW9uIG1vdmVkIHRvIHRoZSBu ZXcgZGV2aWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkkgdGhpbmsgdGhlIGFzc3VtcHRpb24gcGVvcGxlIGhhZCB3YXMgdGhhdCwgaWYg dGhlIGRldmljZSBjaGFuZ2VzLCB0aGUgZmluZ2VycHJpbnQgd2lsbCBhbHNvIGNoYW5nZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Tm93LCBpZiB3ZSBjYW5ub3QgbWFrZSB0aGF0IGFzc3VtcHRpb24sIHdlIG5l ZWQgdG8gcmUtdmlzaXQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SSB0aG91Z2h0IHRoZSBsb2dpYyB0 aGF0IG1hZGUgc2Vuc2Ugd2FzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OzEuIERUTFMgY29ubmVjdGlvbiBpcyByZS1lc3RhYmxpc2hlZCB3 aGVuZXZlciB1bmRlcmx5aW5nIHRyYW5zcG9ydCBjaGFuZ2VzIChhbHJlYWR5IGluIHRoZSBzcGVj aWZpY2F0aW9uKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsyLiBGaW5nZXJwcmludCBhbmQgc2V0dXAgcm9sZSBNVVNUIG5vdCBjaGFuZ2Ug dW5sZXNzIHVuZGVybHlpbmcgdHJhbnNwb3J0IGNoYW5nZXMgYXMgd2VsbCAoYWxyZWFkeSBpbiB0 aGUgJmd0O3NwZWNpZmljYXRpb24pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzMuIFVubGVzcyBJQ0UgaXMgdXNlZCwgdW5kZXJseWluZyB0 cmFuc3BvcnQgaXMgY29uc2lkZXJlZCBjaGFuZ2VkIGlmIDUtdHVwbGUgZm9yIGNvbm5lY3Rpb24g Y2hhbmdlcyZuYnNwOyZuYnNwOyhhbHJlYWR5ICZndDtpbiB0aGUgc3BlY2lmaWNhdGlvbik8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Db3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzQuIEluIGNhc2Ugb2YgSUNFLCB0aGUgdW5k ZXJseWluZyB0cmFuc3BvcnQgaXMgY29uc2lkZXJlZCBjaGFuZ2VkIGlmIHVmcmFnIGFuZCBlbnRp cmUgY2FuZGlkYXRlIGxpc3QgY2hhbmdlZCBvbiAmZ3Q7ZWl0aGVyIHNpZGUgb2YgdGhlIGNhbGwg KG1pc3NpbmcgZnJvbSB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBuZWVkIHRvIGJlIGNs ZWFyIHdoYXQgd2UgbWVhbiBieSDigJxlbnRpcmUgY2FuZGlkYXRlIGxpc3TigJ0uIERvIHlvdSBt ZWFuIGEgbmV3IFNEUCwgd2hpY2ggb25seSBjb250YWlucyBjYW5kaWRhdGVzIHRoYXQgaGF2ZSBu ZXZlciBiZWVuIHVzZWQgYmVmb3JlIGR1cmluZyB0aGUgc2Vzc2lvbj88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ T2J2aW91c2x5LCB0aGUgSVAgYWRkcmVzczpwb3J0IHByb3BlcnRpZXMgbWF5IHN0aWxsIGJlIHRo ZSBzYW1lLCBzbyBJIGd1ZXNzIHRoZSB1ZnJhZyB3b3VsZCBoYXZlIHRvIGJlIGRpZmZlcmVudCDi gJMgYXMgeW91IHNheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QlVULCBJIHRoaW5rIHNvbWVvbmUgaW4gRGFs bGFzIGhhZCBhIGNvbW1lbnQgb24gd2h5IHVmcmFnIGNhbuKAmXQgYmUgdXNlZC4gSnVzdGluPyBF a3I/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SW4gdGhlIHByb3Bvc2VkIHRleHQsIHRoZSBpc3N1ZSB0aGF0 IEkgaGF2ZSBpcyB3aXRoIHRoZSBwaHJhc2UgJnF1b3Q7SW1wbGVtZW50YXRpb25zIE1VU1QgdHJl YXQgYWxsIElDRSBjYW5kaWRhdGUgJmd0O3BhaXJzIGFzc29jaWF0ZWQgd2l0aCBhJm5ic3A7YW4g U0NUUCBhc3NvY2lhdGlvbiBvbiB0b3Agb2YgYSBEVExTIGNvbm5lY3Rpb24gYXMgcGFydCBvZiB0 aGUgc2FtZSZuYnNwO0RUTFMgJmd0O2Nvbm5lY3Rpb24mcXVvdDsuIEkgYW0gbm90IDEwMCUNCiBz dXJlIHdoYXQgdGhpcyBtZWFucyBhbmQgZXZlbiBpZiB0aGlzIGlzIGFjY3VyYXRlLiAmcXVvdDtB bGwgSUNFIGNhbmRpZGF0ZSBwYWlycyAmZ3Q7YXNzb2NpYXRlZCB3aXRoIGEmbmJzcDthbiBTQ1RQ IGFzc29jaWF0aW9uJnF1b3Q7IGlzIHVuY2xlYXIgdG8gbWUuIERvZXMgdGhpcyByZWZlciBvbmx5 IHRvIHRoZSBjYW5kaWRhdGUgcGFpcnMgZm9yIHRoZSAmZ3Q7Y3VycmVudCBJQ0Ugc2Vzc2lvbiBv ciB0byB0aGUgY2FuZGlkYXRlIHBhaXJzIGZvciBhbnkgZnV0dXJlIElDRSBzZXNzaW9ucw0KIGFz c29jaWF0ZWQgd2l0aCB0aGlzIFNDVFAgJmd0O2Fzc29jaWF0aW9uPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkN1cnJlbnQgQU5EIGZ1dHVy ZS4gVGhlcmUgYXJlIHByb3Bvc2FscyBhYm91dCB0aGUgcG9zc2liaWxpdHkgb2YgZHluYW1pY2Fs bHkgYWRkaW5nIG5ldyBjYW5kaWRhdGVzIGR1cmluZyB0aGUgc2Vzc2lvbiwgYW5kIHRoZXkgd291 bGQgYmUgcGFydCBvZiB0aGUgc2FtZSBEVExTIGNvbm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 T3JpZ2luYWwgdGV4dCBmcm9tIFJGQyA1NzYzICgmcXVvdDtJbXBsZW1lbnRhdGlvbnMgTVVTVCB0 cmVhdCBhbGwgSUNFIGNhbmRpZGF0ZSBwYWlycyBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUgJmd0 O2NvbXBvbmVudCBhcyBwYXJ0IG9mIHRoZSBzYW1lIERUTFMgYXNzb2NpYXRpb24mcXVvdDspIGlz IG1vcmUgYWNjdXJhdGUgYnV0IHN1ZmZlcnMgZnJvbSB0aGUgZmFjdCB0aGF0ICZxdW90O3Npbmds ZSAmZ3Q7Y29tcG9uZW50JnF1b3Q7IGlzIG5vdCB3ZWxsDQogZGVmaW5lZCBhbmQgYmVjYXVzZSBv ZiB0aGlzIHJ1bnMgaW50byBzaW1pbGFyIGlzc3Vlcy4gRG9lcyBJQ0UgcmUtc3RhcnQgY3JlYXRl cyBhIG5ldyAmZ3Q7Y29tcG9uZW50IG9yIGlzIG9sZCBjb21wb25lbnQgY29uc2lkZXJlZCB0byBi ZSByZS11c2VkPyBJZiZuYnNwO2NvbXBvbmVudCZuYnNwO2lzIHNwZWNpZmljIHRvIElDRSBzZXNz aW9uJm5ic3A7KHVmcmFnIHBhaXIpLCAmZ3Q7Y2FuIGNhbmRpZGF0ZXMgZnJvbSB0aGUgcHJldmlv dXMgc2Vzc2lvbiBiZSByZS11c2VkIGZvciBuZWdvdGlhdGluZw0KIGEgbmV3IGNvbXBvbmVudD8g SWYgdGhleSBjYW4sIGhvdyBkbyAmZ3Q7eW91IGRlLW11eCBwYWNrZXRzIHJlY2VpdmVkIGJldHdl ZW4gb2xkIGFuZCBuZXcgY29tcG9uZW50IGlmIGNhbmRpZGF0ZXMgd2VyZSByZXVzZWQgb24gYm90 aCBzaWRlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5QZW9wbGUgaGFkIGlzc3VlcyB3aXRoIHRoZSB1c2FnZSBvZiDigJxj b21wb25lbnTigJ0gdG9vLCBidXQgSeKAmWQgbmVlZCB0byBkb3VibGUgY2hlY2sgd2l0aCB0aGUg bWludXRlcy9yZWNvcmRpbmcgZm9yIHRoZSBkZXRhaWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQsIG15 IGludGVudGlvbiB3YXMgbm90IHRvIGRldmlhdGUgZnJvbSB0aGUgNTc2MyB0ZXh0IG9uIHB1cnBv c2UuIEkgZm9yIHN1cmUgY2FuIHVzZSB0aGF0IHRleHQsIGlmIHlvdSB0aGluayBpdCBpcyBtb3Jl IGFjY3VyYXRlIChhc3N1bWluZyB0aGF0IHRoZXJlIGFyZSBubyBpc3N1ZXMgd2l0aCB1c2FnZQ0K IG9mIOKAnGNvbXBvbmVudOKAnSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D788924ESESSMB209erics_-- From nobody Wed Apr 1 14:21:50 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E131A1B1F for ; Wed, 1 Apr 2015 14:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLYlLtP9LXIZ for ; Wed, 1 Apr 2015 14:21:45 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF711A1AE8 for ; Wed, 1 Apr 2015 14:21:43 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so58134548igc.0 for ; Wed, 01 Apr 2015 14:21:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dYa/NoTvMsdR/K3zabd8EY4A/1x9LpdyMJhaj5B1NH4=; b=bc/fOiHQCq+pqiOPn8MQDsn95GcwHP/ReTvQawNh8kHhAV6ku7TdwgIpE63/yA5RE7 zPTFerbD8EXwsloZiBEEID0OiX8AjUyMKtJKKQS01m6xrK30AK2UuSvLGefGJr2EEsIz Ylu+KSTxQue+2Fb5cmTz7nYHsBh92ioHU6UY/tda/eZh4MdRkxLPWRjxq16etjkHxwBs E9MHsNbOx5Q/sGo6eCxNNXtj1U+GPx9Rz4tTSMdtyORvBNSi1m7/yEJFpmF03URrG658 FCKR497tPH54ED+eg5zC0LOrtYR8qBYc3vH6uMhMMzYrdNr5MaqAiYmSYO+MRPzTRQ7q Artw== X-Gm-Message-State: ALoCoQkjRXYum+EhardGAnqHROa7wfm3LJAX9WlwFWo7Tztk+DYk46BED2NYbm4H3waZ+j6z33jn X-Received: by 10.50.35.195 with SMTP id k3mr15342505igj.11.1427923303075; Wed, 01 Apr 2015 14:21:43 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com. [209.85.223.169]) by mx.google.com with ESMTPSA id t1sm13676011igs.0.2015.04.01.14.21.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 14:21:41 -0700 (PDT) Received: by iedm5 with SMTP id m5so54581439ied.3 for ; Wed, 01 Apr 2015 14:21:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.91.142 with SMTP id p14mr1962087icm.24.1427923300641; Wed, 01 Apr 2015 14:21:40 -0700 (PDT) Received: by 10.36.110.141 with HTTP; Wed, 1 Apr 2015 14:21:40 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> Date: Wed, 1 Apr 2015 17:21:40 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=90e6ba61500619f9fa0512b04def Archived-At: Cc: mmusic Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:21:48 -0000 --90e6ba61500619f9fa0512b04def Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Christer, On Wed, Apr 1, 2015 at 3:42 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > > >I have looked through the slides and I think they are misleading. To > me they seem to imply that DTLS >association is orthogonal to transport a= nd > only gets re-established when fingerprint changes. > > > > That was more or less the approach people wanted to take, when this was > discussed in Dallas. > *If this is the approach, then the specification language will need to change. It says something different now where DTLS connection gets re-established every time underlying transport changes, not when fingerprint changes. In particular, the case when fingerprint stays the same but the transport changes is treated differently.* >In other words, even if the underlying transport changes, but > fingerprint stays the same, the slides imply that >existing DTLS > association continues to be used with the new transport. BTW, I think thi= s > is what Chrome is >currently doing. This behavior is against the proposed > specification language ("If the underlying transport >protocol is modifie= d, > the endpoints MUST establish a new DTLS connection"). This also presents = a > serious >problem in the use case where third party call control is used t= o > move the call between the several end point >that use the same site-wide > certificate. All of those end points will present the same fingerprint, b= ut > the DTLS >connection will need to be re-established since the media > connection is moved to a different device. This also >shows that > fingerprint alone cannot be used to determine that connection moved to th= e > new device. > > > > I think the assumption people had was that, if the device changes, the > fingerprint will also change. > > > > Now, if we cannot make that assumption, we need to re-visit it. > *Per the provided use case this assumption is incorrect. There needs to be a way to detect that device changed. Neither fingerprint no IP/port change in case of ICE provides the accurate indication of the device change.* > >I thought the logic that made sense was: > > >1. DTLS connection is re-established whenever underlying transport > changes (already in the specification). > > >2. Fingerprint and setup role MUST not change unless underlying transpor= t > changes as well (already in the >specification). > > >3. Unless ICE is used, underlying transport is considered changed if > 5-tuple for connection changes (already >in the specification) > > > > Correct. > *Once again, if the logic from the slides is to be followed this will need to change.* > >4. In case of ICE, the underlying transport is considered changed if > ufrag and entire candidate list changed on >either side of the call > (missing from the current specification). > > > > We need to be clear what we mean by =E2=80=9Centire candidate list=E2=80= =9D. Do you mean a > new SDP, which only contains candidates that have never been used before > during the session? > > > > Obviously, the IP address:port properties may still be the same, so I > guess the ufrag would have to be different =E2=80=93 as you say. > > > > BUT, I think someone in Dallas had a comment on why ufrag can=E2=80=99t b= e used. > Justin? Ekr? > *Ufrag change can be due to iCE re-start (which means fingerprint cannot change) or due to device change (fingerprint can change). There is no easy way to distinguish the two.* > >In the proposed text, the issue that I have is with the phrase > "Implementations MUST treat all ICE candidate >pairs associated with a an > SCTP association on top of a DTLS connection as part of the same DTLS > >connection". I am not 100% sure what this means and even if this is > accurate. "All ICE candidate pairs >associated with a an SCTP association= " > is unclear to me. Does this refer only to the candidate pairs for the > >current ICE session or to the candidate pairs for any future ICE session= s > associated with this SCTP >association? > > > > Current AND future. There are proposals about the possibility of > dynamically adding new candidates during the session, and they would be > part of the same DTLS connection. > *I was not talking about candidates here. I was talking about ICE sessions. Do you mean the current ICE session (and all the current and future candidates) or current and future ICE sessions?* >Original text from RFC 5763 ("Implementations MUST treat all ICE > candidate pairs associated with a single >component as part of the same > DTLS association") is more accurate but suffers from the fact that "singl= e > >component" is not well defined and because of this runs into similar > issues. Does ICE re-start creates a new >component or is old component > considered to be re-used? If component is specific to ICE session (ufrag > pair), >can candidates from the previous session be re-used for negotiati= ng > a new component? If they can, how do >you de-mux packets received between > old and new component if candidates were reused on both sides. > > > > People had issues with the usage of =E2=80=9Ccomponent=E2=80=9D too, but = I=E2=80=99d need to > double check with the minutes/recording for the details. > > > > And, my intention was not to deviate from the 5763 text on purpose. I for > sure can use that text, if you think it is more accurate (assuming that > there are no issues with usage of =E2=80=9Ccomponent=E2=80=9D). > > *Neither text is ideal. I think we are dealing with fundamental problem here and this problem get sidestepped by using fuzzy terms. The problem is figuring out if the end point communicates with the new device or with the existing one in cases when ICE is used. Right now the mechanism for this is only defined for non-ICE case, with some guidelines for ICE, which are, from my point of view, are insufficient.* _____________ Roman Shpount --90e6ba61500619f9fa0512b04def Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christer,


On Wed, Apr 1, 2015= at 3:42 PM, Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:

=C2=A0

>I have looked through the slides and I think the= y are misleading. To me they seem to imply that DTLS >association is ort= hogonal to transport and only gets re-established when fingerprint changes.=

=C2=A0

That was more or less the approach people wanted to take, = when this was discussed in Dallas.


If this is the approach, then the specificati= on language will need to change. It says something different now where DTLS= connection gets re-established every time underlying transport changes, no= t when fingerprint changes. In particular, the case when fingerprint stays = the same but the transport changes is treated differently.

=C2=A0>In other words, even if the underlying tr= ansport changes, but fingerprint stays the same, the slides imply that >= existing DTLS association continues to be used with the new transport. BTW,= I think this is what Chrome is >currently doing. This behavior is against the proposed specification language ("If the= underlying transport >protocol is modified, the endpoints MUST establis= h a new DTLS connection"). This also presents a serious >problem in= the use case where third party call control is used to move the call between the several end point >that use the same = site-wide certificate. All of those end points will present the same finger= print, but the DTLS >connection will need to be re-established since the= media connection is moved to a different device. This also >shows that fingerprint alone cannot be used to deter= mine that connection moved to the new device.

=

=C2=A0

I think the assumption people had was that, if the device changes= , the fingerprint will also change.

=C2=A0

Now, if we cannot make that assumption, we need to re-visit it.


Per th= e provided use case this assumption is incorrect. There needs to be a way t= o detect that device changed. Neither fingerprint no IP/port change in case= of ICE provides the accurate indication of the device change.
=C2=A0

>I thought the logic that made sense was:

=

>1. DTLS connection is re-established whenever un= derlying transport changes (already in the specification).

>2. Fingerprint and setup role MUST not change un= less underlying transport changes as well (already in the >specification= ).

>3. Unless ICE is used, underlying transport is c= onsidered changed if 5-tuple for connection changes=C2=A0=C2=A0(already >= ;in the specification)

=C2=A0

Correct.


Once again, if the logic from the slides is to be foll= owed this will need to change.
=C2=A0
=

>4. In case of ICE, the underlying transport is c= onsidered changed if ufrag and entire candidate list changed on >either = side of the call (missing from the current specification).

=C2=A0

We need to be clear what we mean by =E2=80=9Centire candidate lis= t=E2=80=9D. Do you mean a new SDP, which only contains candidates that have= never been used before during the session?

=C2=A0

Obviously, the IP address:port properties may still be the same, = so I guess the ufrag would have to be different =E2=80=93 as you say.

=C2=A0

BUT, I think someone in Dallas had a comment on why ufrag can=E2= =80=99t be used. Justin? Ekr?


<= /div>
Ufrag change can be due to iCE re-start (which means fingerpri= nt cannot change) or due to device change (fingerprint can change). There i= s no easy way to distinguish the two.

= =C2=A0

=C2=A0>In the proposed text, the issue that I ha= ve is with the phrase "Implementations MUST treat all ICE candidate &g= t;pairs associated with a=C2=A0an SCTP association on top of a DTLS connect= ion as part of the same=C2=A0DTLS >connection". I am not 100% sure what this means and even if this is accurate. "All ICE candidate= pairs >associated with a=C2=A0an SCTP association" is unclear to m= e. Does this refer only to the candidate pairs for the >current ICE sess= ion or to the candidate pairs for any future ICE sessions associated with this SCTP >association?

=C2=A0

Current AND future. There are proposals about the possibility of = dynamically adding new candidates during the session, and they would be par= t of the same DTLS connection.


=
I was not talking about candidates here. I was talking about = ICE sessions.=C2=A0 Do you mean the current ICE session (and all the curren= t and future candidates) or current and future ICE sessions?
=

>Original text from RFC 5763 ("Implementatio= ns MUST treat all ICE candidate pairs associated with a single >componen= t as part of the same DTLS association") is more accurate but suffers = from the fact that "single >component" is not well defined and because of this runs into similar issues. Does ICE re-start cr= eates a new >component or is old component considered to be re-used? If= =C2=A0component=C2=A0is specific to ICE session=C2=A0(ufrag pair), >can = candidates from the previous session be re-used for negotiating a new component? If they can, how do >you de-mux packets received betwe= en old and new component if candidates were reused on both sides.

=C2=A0

People had issues with the usage of =E2=80=9Ccomponent=E2= =80=9D too, but I=E2=80=99d need to double check with the minutes/recording= for the details.

=C2=A0

And, my intention was not to deviate from the 5763 text on purpos= e. I for sure can use that text, if you think it is more accurate (assuming= that there are no issues with usage of =E2=80=9Ccomponent=E2=80=9D).

<= br>
Neither text is ideal. I think we are dealing with fundame= ntal problem here and this problem get sidestepped by using fuzzy terms. Th= e problem is figuring out if the end point communicates with the new device= or with the existing one in cases when ICE is used. Right now the mechanis= m for this is only defined for non-ICE case, with some guidelines for ICE, = which are, from my point of view, are insufficient.
_____________
Roman Shpount

--90e6ba61500619f9fa0512b04def-- From nobody Thu Apr 2 01:43:23 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D791A90C9 for ; Thu, 2 Apr 2015 01:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG6SZ2hKU_-Z for ; Thu, 2 Apr 2015 01:43:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1A81A8AAF for ; Thu, 2 Apr 2015 01:43:19 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-c9-551d0125f66d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E2.A7.01716.5210D155; Thu, 2 Apr 2015 10:43:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Thu, 2 Apr 2015 10:43:16 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA Date: Thu, 2 Apr 2015 08:43:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja4qo2yoQd9tEYupyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZXz/3s1c0GRWMa/nGVMD4wWTLkZODgkBE4mJ j+4yQthiEhfurWfrYuTiEBI4yiixctF+RghnMaNE16UJrF2MHBxsAhYS3f+0QRpEBFQl/n6f zARiMwvISMw42whmCwtYSnzbMIUJosZKonfCEmYIO09iQdN5NhCbRUBFYsLGVWA1vAK+EmfP dzJD7DrAKrFs9lKwIk6BQImPzVvArmMEuu77qTVQy8Qlbj2ZzwRxtYDEkj3nmSFsUYmXj/+x QtiKEjvPtjOD3MwsoCmxfpc+RKuixJTuh+wQewUlTs58wjKBUWwWkqmzEDpmIemYhaRjASPL KkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzA2Dm45bfuDsbVrx0PMQpwMCrx8D64JRMqxJpY VlyZe4hRmoNFSZzXzvhQiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGy7iw39pblu0pP99s xcO1c5rk0rd7JQ+2OTlfWLVpzRH34/XTuf6XL9375pvMtHih63uY/t84a/PsWJX016+J0toB O9LK5s38lNy9/+iXXyx7Xi16Ei4b/ykjTmoWk4PVV9HOByyfrF/c7ZbPcrhgputaI3bWpvPy LMHfiq9mSXWtLP8fmHz+phJLcUaioRZzUXEiAGqTCsB+AgAA Archived-At: Cc: mmusic Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 08:43:22 -0000 SGkgUm9tYW4sDQoNCj4gUGVyIHRoZSBwcm92aWRlZCB1c2UgY2FzZSB0aGlzIGFzc3VtcHRpb24g aXMgaW5jb3JyZWN0LiBUaGVyZSBuZWVkcyB0byBiZSBhIHdheSB0byBkZXRlY3QgdGhhdCBkZXZp Y2UgY2hhbmdlZC4gTmVpdGhlciBmaW5nZXJwcmludCBubyBJUC9wb3J0IGNoYW5nZSBpbiBjYXNl IG9mIElDRSBwcm92aWRlcyB0aGUgYWNjdXJhdGUgaW5kaWNhdGlvbiBvZiB0aGUgZGV2aWNlIGNo YW5nZS4NCg0KT2suDQoNCj4+PkkgdGhvdWdodCB0aGUgbG9naWMgdGhhdCBtYWRlIHNlbnNlIHdh czoNCj4+PjEuIERUTFMgY29ubmVjdGlvbiBpcyByZS1lc3RhYmxpc2hlZCB3aGVuZXZlciB1bmRl cmx5aW5nIHRyYW5zcG9ydCBjaGFuZ2VzIChhbHJlYWR5IGluIHRoZSBzcGVjaWZpY2F0aW9uKS4N Cj4+PjIuIEZpbmdlcnByaW50IGFuZCBzZXR1cCByb2xlIE1VU1Qgbm90IGNoYW5nZSB1bmxlc3Mg dW5kZXJseWluZyB0cmFuc3BvcnQgY2hhbmdlcyBhcyB3ZWxsIChhbHJlYWR5IGluIHRoZSA+c3Bl Y2lmaWNhdGlvbikuDQo+Pj4zLiBVbmxlc3MgSUNFIGlzIHVzZWQsIHVuZGVybHlpbmcgdHJhbnNw b3J0IGlzIGNvbnNpZGVyZWQgY2hhbmdlZCBpZiA1LXR1cGxlIGZvciBjb25uZWN0aW9uIGNoYW5n ZXPCoMKgKGFscmVhZHkgPmluIHRoZSBzcGVjaWZpY2F0aW9uKQ0KPj4NCj4+IENvcnJlY3QuDQo+ DQo+IE9uY2UgYWdhaW4sIGlmIHRoZSBsb2dpYyBmcm9tIHRoZSBzbGlkZXMgaXMgdG8gYmUgZm9s bG93ZWQgdGhpcyB3aWxsIG5lZWQgdG8gY2hhbmdlLg0KDQpUaGUgdGV4dCB3aWxsIGJlIGZpeGVk Lg0KDQpPZiBjb3Vyc2UsIHdoYXRldmVyIHNvbHV0aW9uIHdpbGwgYmUgZm9yIHRoZSBJQ0UgY2Fz ZSwgaXQgY291bGQgYWxzbyBiZSBhcHBsaWNhYmxlIGZvciB0aGUgbm9uLUlDRSBjYXNlLiBCdXQs IHRoZSBub24tSUNFIGNhc2UgaXMgZWFzaWVyLCBiZWNhdXNlIHdlIGtub3cgYSBjaGFuZ2UgaW4g dGhlIDUtdHVwbGUgd2lsbCB0cmlnZ2VyIGEgbmV3IERUTFMgY29ubmVjdGlvbiAtIG5vIG1hdHRl ciBpZiB0aGUgZmluZ2VycHJpbnQgZXRjIGNoYW5nZSBvciBub3QuDQoNCg0KPj4+NC4gSW4gY2Fz ZSBvZiBJQ0UsIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBpcyBjb25zaWRlcmVkIGNoYW5nZWQg aWYgdWZyYWcgYW5kIGVudGlyZSBjYW5kaWRhdGUgbGlzdCBjaGFuZ2VkIG9uID5laXRoZXIgc2lk ZSBvZiB0aGUgY2FsbCAobWlzc2luZyBmcm9tIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24pLg0K Pj7CoA0KPj4gV2UgbmVlZCB0byBiZSBjbGVhciB3aGF0IHdlIG1lYW4gYnkg4oCcZW50aXJlIGNh bmRpZGF0ZSBsaXN04oCdLiBEbyB5b3UgbWVhbiBhIG5ldyBTRFAsIHdoaWNoIG9ubHkgY29udGFp bnMgY2FuZGlkYXRlcyB0aGF0IGhhdmUgbmV2ZXIgYmVlbiB1c2VkIGJlZm9yZSBkdXJpbmcgdGhl IHNlc3Npb24/DQo+PsKgDQo+PiBPYnZpb3VzbHksIHRoZSBJUCBhZGRyZXNzOnBvcnQgcHJvcGVy dGllcyBtYXkgc3RpbGwgYmUgdGhlIHNhbWUsIHNvIEkgZ3Vlc3MgdGhlIHVmcmFnIHdvdWxkIGhh dmUgdG8gYmUgZGlmZmVyZW50IOKAkyBhcyB5b3Ugc2F5Lg0KPg0KPiBCVVQsIEkgdGhpbmsgc29t ZW9uZSBpbiBEYWxsYXMgaGFkIGEgY29tbWVudCBvbiB3aHkgdWZyYWcgY2Fu4oCZdCBiZSB1c2Vk LiBKdXN0aW4/IEVrcj8NCj4NCj4gVWZyYWcgY2hhbmdlIGNhbiBiZSBkdWUgdG8gaUNFIHJlLXN0 YXJ0ICh3aGljaCBtZWFucyBmaW5nZXJwcmludCBjYW5ub3QgY2hhbmdlKSBvciBkdWUgdG8gZGV2 aWNlIGNoYW5nZSAoZmluZ2VycHJpbnQgY2FuIGNoYW5nZSkuIFRoZXJlIGlzIG5vIGVhc3kgd2F5 IHRvIGRpc3Rpbmd1aXNoIHRoZSB0d28uDQoNCkNvcnJlY3QuDQoNCk9uZSBwb3NzaWJsZSB3YXkg d291bGQgYmUgdG8gdXNlIHRoZSBTRFAgY29ubmVjdGlvbiBhdHRyaWJ1dGUsIHdpdGggYSAibmV3 IiB2YWx1ZS4gSG93ZXZlciwgdXNhZ2Ugb2YgdGhlIGF0dHJpYnV0ZSBpcyBjdXJyZW50bHkgbm90 IGFsbG93ZWQgZm9yIFNSVFAtRFRMUy4NCg0KVGhlcmUgd2FzIGFsc28gYSBzdWdnZXN0aW9uIHRv IHVzZSBTSVAgcmVwbGFjZSwgYnV0IHdlIG5lZWQgdG8gZGVmaW5lIGFuIFNEUCBtZWNoYW5pc20u DQoNCj4+PkluIHRoZSBwcm9wb3NlZCB0ZXh0LCB0aGUgaXNzdWUgdGhhdCBJIGhhdmUgaXMgd2l0 aCB0aGUgcGhyYXNlICJJbXBsZW1lbnRhdGlvbnMgTVVTVCB0cmVhdCBhbGwgSUNFIGNhbmRpZGF0 ZSANCj4+PnBhaXJzIGFzc29jaWF0ZWQgd2l0aCBhwqBhbiBTQ1RQIGFzc29jaWF0aW9uIG9uIHRv cCBvZiBhIERUTFMgY29ubmVjdGlvbiBhcyBwYXJ0IG9mIHRoZSBzYW1lwqBEVExTIA0KPj4+Y29u bmVjdGlvbiIuIEkgYW0gbm90IDEwMCUgc3VyZSB3aGF0IHRoaXMgbWVhbnMgYW5kIGV2ZW4gaWYg dGhpcyBpcyBhY2N1cmF0ZS4gIkFsbCBJQ0UgY2FuZGlkYXRlIHBhaXJzIA0KPj4+YXNzb2NpYXRl ZCB3aXRoIGHCoGFuIFNDVFAgYXNzb2NpYXRpb24iIGlzIHVuY2xlYXIgdG8gbWUuIERvZXMgdGhp cyByZWZlciBvbmx5IHRvIHRoZSBjYW5kaWRhdGUgcGFpcnMgZm9yIA0KPj4+dGhlIGN1cnJlbnQg SUNFIHNlc3Npb24gb3IgdG8gdGhlIGNhbmRpZGF0ZSBwYWlycyBmb3IgYW55IGZ1dHVyZSBJQ0Ug c2Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgU0NUUCBhc3NvY2lhdGlvbj8NCj4+DQo+PiBD dXJyZW50IEFORCBmdXR1cmUuIFRoZXJlIGFyZSBwcm9wb3NhbHMgYWJvdXQgdGhlIHBvc3NpYmls aXR5IG9mIGR5bmFtaWNhbGx5IGFkZGluZyBuZXcgY2FuZGlkYXRlcyBkdXJpbmcgdGhlIHNlc3Np b24sIGFuZCB0aGV5IHdvdWxkIGJlIHBhcnQgb2YgdGhlIHNhbWUgRFRMUyBjb25uZWN0aW9uLg0K Pg0KPiBJIHdhcyBub3QgdGFsa2luZyBhYm91dCBjYW5kaWRhdGVzIGhlcmUuIEkgd2FzIHRhbGtp bmcgYWJvdXQgSUNFIHNlc3Npb25zLsKgIERvIHlvdSBtZWFuIHRoZSBjdXJyZW50IElDRSBzZXNz aW9uIChhbmQgYWxsIHRoZSBjdXJyZW50IGFuZCBmdXR1cmUgY2FuZGlkYXRlcykgb3IgY3VycmVu dCBhbmQgZnV0dXJlIElDRSBzZXNzaW9ucz8NCg0KSSBjb3VsZCBub3QgZmluZCBhIGNsZWFyIGRl ZmluaXRpb24gb2YgIklDRSBzZXNzaW9uIiwgYnV0IEkgd291bGQgYXNzdW1lIGl0IGFwcGxpZXMg dG8gY3VycmVudCBhbmQgZnV0dXJlIElDRSBzZXNzaW9ucyAtIGFzc3VtaW5nIGUuZy4gYW4gSUNF IHJlc3RhcnQgdHJpZ2dlcnMgYSBuZXcgSUNFIHNlc3Npb24uDQoNCg0KPj4+IE9yaWdpbmFsIHRl eHQgZnJvbSBSRkMgNTc2MyAoIkltcGxlbWVudGF0aW9ucyBNVVNUIHRyZWF0IGFsbCBJQ0UgY2Fu ZGlkYXRlIHBhaXJzIGFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZSBjb21wb25lbnQgYXMgcGFydCBv ZiB0aGUgc2FtZSANCj4+PiBEVExTIGFzc29jaWF0aW9uIikgaXMgbW9yZSBhY2N1cmF0ZSBidXQg c3VmZmVycyBmcm9tIHRoZSBmYWN0IHRoYXQgInNpbmdsZSBjb21wb25lbnQiIGlzIG5vdCB3ZWxs IGRlZmluZWQgYW5kIGJlY2F1c2Ugb2YgdGhpcyBydW5zIGludG8gDQo+Pj4gc2ltaWxhciBpc3N1 ZXMuIERvZXMgSUNFIHJlLXN0YXJ0IGNyZWF0ZXMgYSBuZXcgY29tcG9uZW50IG9yIGlzIG9sZCBj b21wb25lbnQgY29uc2lkZXJlZCB0byBiZSByZS11c2VkPyBJZsKgY29tcG9uZW50wqBpcyBzcGVj aWZpYyB0byANCj4+PiBJQ0Ugc2Vzc2lvbsKgKHVmcmFnIHBhaXIpLCA+Y2FuIGNhbmRpZGF0ZXMg ZnJvbSB0aGUgcHJldmlvdXMgc2Vzc2lvbiBiZSByZS11c2VkIGZvciBuZWdvdGlhdGluZyBhIG5l dyBjb21wb25lbnQ/IElmIHRoZXkgY2FuLCBob3cgZG8gDQo+Pj4geW91IGRlLW11eCBwYWNrZXRz IHJlY2VpdmVkIGJldHdlZW4gb2xkIGFuZCBuZXcgY29tcG9uZW50IGlmIGNhbmRpZGF0ZXMgd2Vy ZSByZXVzZWQgb24gYm90aCBzaWRlcy4NCj4+wqANCj4+IFBlb3BsZSBoYWQgaXNzdWVzIHdpdGgg dGhlIHVzYWdlIG9mIOKAnGNvbXBvbmVudOKAnSB0b28sIGJ1dCBJ4oCZZCBuZWVkIHRvIGRvdWJs ZSBjaGVjayB3aXRoIHRoZSBtaW51dGVzL3JlY29yZGluZyBmb3IgdGhlIGRldGFpbHMuDQo+PsKg DQo+PiBBbmQsIG15IGludGVudGlvbiB3YXMgbm90IHRvIGRldmlhdGUgZnJvbSB0aGUgNTc2MyB0 ZXh0IG9uIHB1cnBvc2UuIEkgZm9yIHN1cmUgY2FuIHVzZSB0aGF0IHRleHQsIGlmIHlvdSB0aGlu ayBpdCBpcyBtb3JlIGFjY3VyYXRlIChhc3N1bWluZyB0aGF0IHRoZXJlIGFyZSBubyBpc3N1ZXMg d2l0aCB1c2FnZSBvZiDigJxjb21wb25lbnTigJ0pLg0KPg0KPiBOZWl0aGVyIHRleHQgaXMgaWRl YWwuIEkgdGhpbmsgd2UgYXJlIGRlYWxpbmcgd2l0aCBmdW5kYW1lbnRhbCBwcm9ibGVtIGhlcmUg YW5kIHRoaXMgcHJvYmxlbSBnZXQgc2lkZXN0ZXBwZWQgYnkgdXNpbmcgZnV6enkgdGVybXMuIFRo ZSBwcm9ibGVtIGlzIGZpZ3VyaW5nIG91dCBpZiB0aGUgZW5kIHBvaW50IA0KPiBjb21tdW5pY2F0 ZXMgd2l0aCB0aGUgbmV3IGRldmljZSBvciB3aXRoIHRoZSBleGlzdGluZyBvbmUgaW4gY2FzZXMg d2hlbiBJQ0UgaXMgdXNlZC4gUmlnaHQgbm93IHRoZSBtZWNoYW5pc20gZm9yIHRoaXMgaXMgb25s eSBkZWZpbmVkIGZvciBub24tSUNFIGNhc2UsIHdpdGggc29tZSBndWlkZWxpbmVzIA0KPiBmb3Ig SUNFLCB3aGljaCBhcmUsIGZyb20gbXkgcG9pbnQgb2YgdmlldywgYXJlIGluc3VmZmljaWVudC4N Cg0KU28sIHRoZSBxdWVzdGlvbiBpczogaG93IGRvIHdlIGtub3cgd2hldGhlciB3ZSBhcmUgY29t bXVuaWNhdGluZyB3aXRoIGEgbmV3IGRldmljZT8NCg0KQWdhaW4sIGZvciB0aGUgbm9uLUlDRSBj YXNlIEkgdGhpbmsgd2UgY2FuIHVzZSBhIDUtdHVwbGUgY2hhbmdlIGFzIGluZGljYXRvci4NCg0K Rm9yIElDRSwgaXQgc2VlbXMgbGlrZSB3ZSBjYW4ndCB1c2UgZmluZ2VycHJpbnQsIGFuZCB3ZSBj YW4ndCB1c2UgdWZyYWcuIFdoYXQgYWJvdXQgaWYgQk9USCB0aGUgZmluZ2VycHJpbnQgYW5kIHVm cmFnIGNoYW5nZT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== From nobody Thu Apr 2 12:09:36 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819C31A873D for ; Thu, 2 Apr 2015 12:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRivx-B8UByC for ; Thu, 2 Apr 2015 12:09:32 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3411A1B3C for ; Thu, 2 Apr 2015 12:09:32 -0700 (PDT) Received: by ierf6 with SMTP id f6so76365016ier.2 for ; Thu, 02 Apr 2015 12:09:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vdxxncT2rs3GvDTD7Bs1TTr9MdfwQBIoGVra0a9kjA4=; b=bDK0PePp3VvZteBPYr5gvOjwOd5rqmZlXa0UzjRhUxlg8MMKw8dzh1Iw3TDRFmd98S 0VQcCl9+A4Hp69BIWCUDnQpLkhjnfj86Q6rEVuAEJBltUrrbvnqLWsU50C4kx0ValQUz qNOg7bAqnaFlUNLcDZuvXRNwdMJiRTTdU6IkuCZAFco4ziTYNkyL88kIMBCkdAbmOemg f3LAZulp+CnUQ04HLdb0npfPyj/V/+3iXSC8Il0yqr4d5GoVU5OV2NfgAg4hhndJmXUu LTazm1/BVIEoy7Z7p4to7PwFS3XUqnP0bmug8TIhyQe3H6y0iAq+0x2WP04WUblo2MpD NasQ== X-Gm-Message-State: ALoCoQmLk2MA9PBCnrkPWTJ9Uhe/I2qfVx4eQCN5j6+MV35RaSTAzUMSvcovkeNHXpxvMCyQsXL8 X-Received: by 10.42.240.4 with SMTP id ky4mr81336109icb.70.1428001772103; Thu, 02 Apr 2015 12:09:32 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com. [209.85.223.178]) by mx.google.com with ESMTPSA id 130sm3848610ioz.10.2015.04.02.12.09.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 12:09:30 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so85902319ied.1 for ; Thu, 02 Apr 2015 12:09:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.107.36 with SMTP id gz4mr22492939igb.25.1428001769695; Thu, 02 Apr 2015 12:09:29 -0700 (PDT) Received: by 10.36.110.141 with HTTP; Thu, 2 Apr 2015 12:09:29 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> Date: Thu, 2 Apr 2015 15:09:29 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b1117bf38b1d80512c2922a Archived-At: Cc: mmusic Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 19:09:34 -0000 --047d7b1117bf38b1d80512c2922a Content-Type: text/plain; charset=UTF-8 Hi Christer, On Thu, Apr 2, 2015 at 4:43 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Of course, whatever solution will be for the ICE case, it could also be > applicable for the non-ICE case. But, the non-ICE case is easier, because > we know a change in the 5-tuple will trigger a new DTLS connection - no > matter if the fingerprint etc change or not. > We still have ambiguity here. The slides seem to imply that if the fingerprint stayed the same but 5-tuple changed, this is the same DTLS connection. The current proposed text says that this a new connection. > One possible way would be to use the SDP connection attribute, with a > "new" value. However, usage of the attribute is currently not allowed for > SRTP-DTLS. > > I would be fine with this. For instance new DTLS connection is only established when connection "new" attribute is present or if fingerprint or setup role changes. Connection "new", or fingerprint and setup role changes are only allowed if underlying transport changes as well in such a way that packets for the new connection can be demuxed from the packets for the old DTLS connection based on the transport. This should be backwards compatible and will address all of my issues. Do you know why connection attribute was disallowed in SRTP-DTLS? > There was also a suggestion to use SIP replace, but we need to define an > SDP mechanism. > Agreed. This problem should be orthogonal to SIP signaling and should be resolved within SDP. > So, the question is: how do we know whether we are communicating with a > new device? > > Again, for the non-ICE case I think we can use a 5-tuple change as > indicator. > > For ICE, it seems like we can't use fingerprint, and we can't use ufrag. > What about if BOTH the fingerprint and ufrag change? > > The problem we are dealing with is when several devices use a pre-provisioned site-wide certificate. For instance we typically use domain certificates for SIPS on multiple servers and would like to use them for DTLS as well. Since the certificate is the same, the fingerprint is the same across multiple devices. When third party call control is used in such deployment, the connection can move from one device to another, but the fingerprint will stay the same. So we have a situation where fingerprint stays the same, but ufrag changes. The problem is how to distinguish this from ICE-restart, where fingerprint stays the same but ufrag changes. One option is to examine the candidate list and apply see that it does not intersect with the currently used candidates, but this seems extremely brittle. The other option is to add something like connection new attribute and to make sure new DTLS connection is set. Regards, _____________ Roman Shpount --047d7b1117bf38b1d80512c2922a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christer,

On Thu, Apr 2, 2015 at 4:43 AM, Chri= ster Holmberg <christer.holmberg@ericsson.com> = wrote:
Of course= , whatever solution will be for the ICE case, it could also be applicable f= or the non-ICE case. But, the non-ICE case is easier, because we know a cha= nge in the 5-tuple will trigger a new DTLS connection - no matter if the fi= ngerprint etc change or not.

We still h= ave ambiguity here. The slides seem to imply that if the fingerprint stayed= the same but 5-tuple changed, this is the same DTLS connection. The curren= t proposed text says that this a new connection.
=C2=A0
One possible way would be to use the SDP connection attribute,= with a "new" value. However, usage of the attribute is currently= not allowed for SRTP-DTLS.


I would be fine with this. For instanc= e new DTLS connection is only established when connection "new" a= ttribute is present or if fingerprint or setup role changes. Connection &qu= ot;new", or fingerprint and setup role changes are only allowed if und= erlying transport changes as well in such a way that packets for the new co= nnection can be demuxed from the packets for the old DTLS connection based = on the transport. This should be backwards compatible and will address all = of my issues.

Do you know why connection attribute= was disallowed in SRTP-DTLS?
=C2=A0
There was also a suggestion to use SIP replace, but we need to define an SD= P mechanism.

Agreed. This problem shoul= d be orthogonal to SIP signaling and should be resolved within SDP.
=C2=A0
So, the question is: how do we know whether= we are communicating with a new device?

Again, for the non-ICE case I think we can use a 5-tuple change as indicato= r.

For ICE, it seems like we can't use fingerprint, and we can't use u= frag. What about if BOTH the fingerprint and ufrag change?


The problem we are dealing with is whe= n several devices use a pre-provisioned site-wide certificate. For instance= we typically use domain certificates for SIPS on multiple servers and woul= d like to use them for DTLS as well. Since the certificate is the same, the= fingerprint is the same across multiple devices. When third party call con= trol is used in such deployment, the connection can move from one device to= another, but the fingerprint will stay the same. So we have a situation wh= ere fingerprint stays the same, but ufrag changes. The problem is how to di= stinguish this from ICE-restart, where fingerprint stays the same but ufrag= changes. One option is to examine the candidate list and apply see that it= does not intersect with the currently used candidates, but this seems extr= emely brittle. The other option is to add something like connection new att= ribute and to make sure new DTLS connection is set.=C2=A0

Regards,
_____________
= Roman Shpount

=C2=A0
--047d7b1117bf38b1d80512c2922a-- From nobody Thu Apr 2 13:57:34 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390E31A1B18 for ; Thu, 2 Apr 2015 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GooVjTlP0y99 for ; Thu, 2 Apr 2015 13:57:30 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3999B1A1B0E for ; Thu, 2 Apr 2015 13:57:30 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with comcast id B8wV1q0042GyhjZ018xVAS; Thu, 02 Apr 2015 20:57:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id B8xU1q00T3Ge9ey018xVsL; Thu, 02 Apr 2015 20:57:29 +0000 Message-ID: <551DAD38.5000605@alum.mit.edu> Date: Thu, 02 Apr 2015 16:57:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> 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=1428008249; bh=dQ2MsAfNqgh5ma2fa43TLDuNsobpEZxKLV2mpghCJOs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EG4tLtGYM6wrCUMU0rDjtec6okDI4i93QQLkV7+eHphIVFUoiwSwR5xFpq/+mgYqM 3JVJVzpw8Z4sqer5RlBCFT8zLq7j2g7fc5CvZm9lR381jPXAu+zY2GzGIlWMR1Anwg KGVD0N0PhebqeyUDR6IeQA/CT+WhTcfu9S9N0JD8KT8REzsVg7iXaCsBdNVaC9OUzA XoqrczH7FTsrmQ1K5sEqi6dZYwrx/x4G9OE9lybZ9zHqaA2tkLQa4Z+sSZEgKSonpw I+p9Se4d8mUASdnPzgCbwusJlVbnhl2NAFLyAa/Tp6O7fERH3nDfNuEPc+9sJVvIMU /rvQ2GsUCRm1Q== Archived-At: Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 20:57:31 -0000 On 4/2/15 4:43 AM, Christer Holmberg wrote: >>>> 4. In case of ICE, the underlying transport is considered changed if ufrag and entire candidate list changed on >either side of the call (missing from the current specification). >>> >>> We need to be clear what we mean by “entire candidate list”. Do you mean a new SDP, which only contains candidates that have never been used before during the session? >>> >>> Obviously, the IP address:port properties may still be the same, so I guess the ufrag would have to be different – as you say. >> >> BUT, I think someone in Dallas had a comment on why ufrag can’t be used. Justin? Ekr? >> >> Ufrag change can be due to iCE re-start (which means fingerprint cannot change) or due to device change (fingerprint can change). There is no easy way to distinguish the two. > > Correct. > > One possible way would be to use the SDP connection attribute, with a "new" value. However, usage of the attribute is currently not allowed for SRTP-DTLS. > > There was also a suggestion to use SIP replace, but we need to define an SDP mechanism. Well, when using SIP replace the session-id (o-line) should change. And it is supposed to remain unchanged within a dialog. So from an SDP perspective a totally new session-id value can be taken as an indication. But this affects the complete SDP session, not just a single m-line or bundle. ISTM that a=connection:new is the better answer. The forbidding of this for SRTP-DTLS seems like a bug rather than a feature. Does anyone know the reason for it? Thanks, Paul From nobody Thu Apr 2 14:49:17 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF5A1A702E for ; Thu, 2 Apr 2015 14:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpNbyDhAS7S2 for ; Thu, 2 Apr 2015 14:49:12 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161B01A1AC6 for ; Thu, 2 Apr 2015 14:49:12 -0700 (PDT) Received: by igcau2 with SMTP id au2so87853529igc.0 for ; Thu, 02 Apr 2015 14:49:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5EvLB38gZtuSxHtF8B0z6OlNrmsqNGx4Bw8ca6L4H2Y=; b=HIopIIPCK2HEPCgTrudPZIS+i89qJ/jD3EJP+2p0Ucp0MGAdS2VAUnQr8UCIqXN3If gqv3QSmnNS1OLnlUThORn735ND5g4OJx9Uj90XaRzt67jRl5ihb1mgHnS2GsWedCjRMn tZKhm+T+WJgkJrGKp0rbAw6tgv6GOWlPVU3n8S7V12/8KJPoO/CDXiflqWdE+spIpQ3N H7I6MknsU/Lhxj4b1Epghqa3TO6jDU1bSSvSmC35RQzxW6veXg902ei4a3eZP2mgmLzr eLXGy48bAEOyQQi9XT76iLA38Qob0R7ZwXLm8QjpzC6LXtQDBQ+qtXrNJn4Jm1ImakoY 9AWg== X-Gm-Message-State: ALoCoQnLi8/SMA9GBmwV79rd1Kwrds7TQvVum/sa0kT+O2dFluU1yINZqvOzZeEBRjpw1XiX9FWg X-Received: by 10.50.79.132 with SMTP id j4mr23164660igx.33.1428011351527; Thu, 02 Apr 2015 14:49:11 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com. [209.85.213.181]) by mx.google.com with ESMTPSA id gz4sm83143igb.19.2015.04.02.14.49.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 14:49:10 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so84236370igb.1 for ; Thu, 02 Apr 2015 14:49:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.151.73 with SMTP id z70mr78171127iod.41.1428011349282; Thu, 02 Apr 2015 14:49:09 -0700 (PDT) Received: by 10.36.110.141 with HTTP; Thu, 2 Apr 2015 14:49:09 -0700 (PDT) In-Reply-To: <551DAD38.5000605@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> Date: Thu, 2 Apr 2015 17:49:09 -0400 Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140f04a3594300512c4cd05 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 21:49:14 -0000 --001a1140f04a3594300512c4cd05 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 4:57 PM, Paul Kyzivat wrote: > Well, when using SIP replace the session-id (o-line) should change. And it > is supposed to remain unchanged within a dialog. > > So from an SDP perspective a totally new session-id value can be taken as > an indication. But this affects the complete SDP session, not just a single > m-line or bundle. > There are also third party call control scenarios where media from several different agents is aggregated into a single SDP session. One example would be a solution where audio conferencing server and video SFU are aggregated to appear as a single solution using a separate signaling agent. Using entire new session id will not work in such case, since DTLS connection for only one of the media lines might need to be re-established with the other m= lines reusing existing connections. > ISTM that a=connection:new is the better answer. The forbidding of this > for SRTP-DTLS seems like a bug rather than a feature. Does anyone know the > reason for it? > I do agree a=connection:new is the better answer. One problem that I see with it, that it re-establishes all the protocols running on the same m= line which support it. For instance if you have SCTP and DTLS used on the same m= line, both will be reset when a=connection:new is specified. I am not sure how big of the problem this is for SCTP or other protocols and if you would ever need to re-start SCTP without restarting DTLS or vice verse. _____________ Roman Shpount --001a1140f04a3594300512c4cd05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 2, 2015 at 4:57 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>= ; wrote:
Well, when using SIP replace the sessio= n-id (o-line) should change. And it is supposed to remain unchanged within = a dialog.

So from an SDP perspective a totally new session-id value can be taken as a= n indication. But this affects the complete SDP session, not just a single = m-line or bundle.

There are also third = party call control scenarios where media from several different agents is a= ggregated into a single SDP session. One example would be a solution where = audio conferencing server and video SFU are aggregated to appear as a singl= e solution using a separate signaling agent. Using entire new session id wi= ll not work in such case, since DTLS connection for only one of the media l= ines might need to be re-established with the other m=3D lines reusing exis= ting connections.


ISTM that a=3Dconnection:new is the better answer. The forbidding of this f= or SRTP-DTLS seems like a bug rather than a feature. Does anyone know the r= eason for it?

I do agree a=3Dconnection= :new is the better answer. One problem that I see with it, that it re-estab= lishes all the protocols running on the same m=3D line which support it. Fo= r instance if you have SCTP and DTLS used on the same m=3D line, both will = be reset when a=3Dconnection:new is specified. I am not sure how big of the= problem this is for SCTP or other protocols and if you would ever need to = re-start SCTP without restarting DTLS or vice verse.
_____________
Roman Shpount
=C2=A0<= /div>
--001a1140f04a3594300512c4cd05-- From nobody Fri Apr 3 07:37:34 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700651A902E for ; Fri, 3 Apr 2015 07:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erU27gTe4QMG for ; Fri, 3 Apr 2015 07:37:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D720A1A9057 for ; Fri, 3 Apr 2015 07:37:30 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-fc-551ea5a8ca5d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.39.28347.8A5AE155; Fri, 3 Apr 2015 16:37:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Fri, 3 Apr 2015 16:37:28 +0200 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA//2gvgD/+zMLgP/1Lbrw Date: Fri, 3 Apr 2015 14:37:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D78A17F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvje6KpXKhBhs+GltMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKmPJjJ2PBF+6KdWs2sjQw nuHuYuTgkBAwkXj1k6OLkRPIFJO4cG89WxcjF4eQwFFGiasnZ7JCOIsZJToX/2YGaWATsJDo /qcN0iAi4C3R19fBDhJmFlCXuLo4CCQsLGAp8W3DFCaIEiuJ3glLmEHGiAg0MUr8W3WXGSTB IqAisfH4SzCbV8BX4s3WO+wgtpDAWzaJswejQWxOgUCJvd0djCA2I9Bx30+tARvKLCAucevJ fCaIowUkluw5zwxhi0q8fPyPFcJWklh7eDsLxG2aEut36UO0KkpM6X7IDrFWUOLkzCcsExjF ZiGZOguhYxaSjllIOhYwsqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIylg1t+G+xgfPnc 8RCjAAejEg/vghS5UCHWxLLiytxDjNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosPMTJx cEo1MHYwSfn+VDOK3clm/83I6t1edyP7nhKVGUX/PpjfXVTT1LhV7Yil8vVUJbNpM9p9s89/ EGFTEzrvYenGWaG12OzNcuvAXvkgltwHxtbbp3h7G97re7j2ysGg+McfUnNybveeTd08r/1O ygkFPRP1m/NmVctOXMY/zUzMsb3a69rcM+dMZks+VGIpzkg01GIuKk4EABtbs5qGAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 03 Apr 2015 14:37:32 -0000 SGksDQrigKYNCg0KPkkgZG8gYWdyZWUgYT1jb25uZWN0aW9uOm5ldyBpcyB0aGUgYmV0dGVyIGFu c3dlci4gT25lIHByb2JsZW0gdGhhdCBJIHNlZSB3aXRoIGl0LCB0aGF0IGl0IHJlLWVzdGFibGlz aGVzIGFsbCB0aGUgcHJvdG9jb2xzID5ydW5uaW5nIG9uIHRoZSBzYW1lIG09IGxpbmUgd2hpY2gg c3VwcG9ydCBpdC4gRm9yIGluc3RhbmNlIGlmIHlvdSBoYXZlIFNDVFAgYW5kIERUTFMgdXNlZCBv biB0aGUgc2FtZSBtPSBsaW5lLCBib3RoIHdpbGwgPmJlIHJlc2V0IHdoZW4gYT1jb25uZWN0aW9u Om5ldyBpcyBzcGVjaWZpZWQuIEkgYW0gbm90IHN1cmUgaG93IGJpZyBvZiB0aGUgcHJvYmxlbSB0 aGlzIGlzIGZvciBTQ1RQIG9yIG90aGVyIHByb3RvY29scyBhbmQgPmlmIHlvdSB3b3VsZCBldmVy IG5lZWQgdG8gcmUtc3RhcnQgU0NUUCB3aXRob3V0IHJlc3RhcnRpbmcgRFRMUyBvciB2aWNlIHZl cnNlLg0KDQpBc3N1bWluZyB0aGUgRFRMUyBjb25uZWN0aW9uIGlzIHJlLWVzdGFibGlzaGVkIGR1 ZSB0byBjaGFuZ2Ugb2YgZGV2aWNlLCB0aGUgU0NUUCBhc3NvY2lhdGlvbiB3b3VsZCBvYnZpb3Vz bHkgYWxzbyBoYXZlIHRvIGJlIHJlLWVzdGFibGlzaGVkLiANCg0KKEluIGZhY3QsIEkgYmVsaWV2 ZSByZS1lc3RhYmxpc2hpbmcgdGhlIFNDVFAgYXNzb2NpYXRpb24gd291bGQgbW9yZSBvciBsZXNz IGVsaW1pbmF0ZSB0aGUgcmlzayBvZiByZWNlaXZpbmcgcGFja2V0cyBhc3NvY2lhdGVkIHdpdGgg dGhlIG9sZCBEVExTIGNvbm5lY3Rpb24uKQ0KDQpQZXJoYXBzIHRoZXJlIGNvdWxkIGJlIGNhc2Vz IHdoZXJlIHRoZSBTQ1RQIGFzc29jaWF0aW9uIG5lZWRzIHRvIGJlIHJlLWVzdGFibGlzaGVkLCBi dXQgbm90IHRoZSBEVExTIGNvbm5lY3Rpb24uIEFuZCwgdGhlIFNDVFAgc3RhY2sgaXRzZWxmIGNv dWxkIG9mIGNvdXJzZSBkbyB0aGF0LCB3aXRob3V0IHRvdWNoaW5nIHRoZSBEVExTIGNvbm5lY3Rp b24sIGJ1dCBJIHRoaW5rIHdlIHdvdWxkIHNpbXBseSBzYXkgdGhhdCB0aGUgZHJhZnQgbWVjaGFu aXNtIGRvZXNuJ3Qgc3VwcG9ydCBleHBsaWNpdCBPL0EgbmVnb3RpYXRpb24gb2Ygc3VjaCBhY3Rp b24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Fri Apr 3 07:40:58 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E747F1A905A for ; Fri, 3 Apr 2015 07:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufCZA1RJlPyA for ; Fri, 3 Apr 2015 07:40:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D3D1A9057 for ; Fri, 3 Apr 2015 07:40:55 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-d7-551ea6758887 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.DE.19337.576AE155; Fri, 3 Apr 2015 16:40:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Fri, 3 Apr 2015 16:40:53 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA//2gvgD/+fe8oA== Date: Fri, 3 Apr 2015 14:40:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> In-Reply-To: <551DAD38.5000605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW7pMrlQg955OhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRdeENS8EPtoo7ky+yNzA+YOti5OSQEDCR +L3+AyuELSZx4d56oDgXh5DAUUaJVwuuMEM4ixklfl86AVTFwcEmYCHR/U8bpEFEwFfi2ePb YIOEBSwlvm2YwgQRt5LonbCEGcKukzjw8SILiM0ioCJx5v1xsBpeoN5tW9+xQsxfxiYxr6ef HSTBKaAj8fD5XbAiRqCLvp9aA2YzC4hL3HoynwniUgGJJXvOM0PYohIvH/+D+kBJYu3h7Swg dzILaEqs36UP0aooMaX7ITvEXkGJkzOfsExgFJ2FZOoshI5ZSDpmIelYwMiyilG0OLU4KTfd yFgvtSgzubg4P08vL7VkEyMwSg5u+a26g/HyG8dDjAIcjEo8vAtS5EKFWBPLiitzDzFKc7Ao ifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDIcujqkZ1cs7qs1r+qchB1ebPyOYte +zeL2H+3ZiX02xq1G615rpX546eXrbNB0tss5kfpE8zipnSuDil6PXVBya3f0aa1XMs/+vjF h6rk39g82yMmimVl/VwdjnrlZ75hC/rX8jBoKcQ7GezZLsNkWpp+MTKA73Np3dZuiY5X02o6 jHKZ6pRYijMSDbWYi4oTAQT31GVzAgAA Archived-At: Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 03 Apr 2015 14:40:57 -0000 SGksDQoNCj5JU1RNIHRoYXQgYT1jb25uZWN0aW9uOm5ldyBpcyB0aGUgYmV0dGVyIGFuc3dlci4g VGhlIGZvcmJpZGRpbmcgb2YgdGhpcyBmb3IgU1JUUC1EVExTIHNlZW1zIGxpa2UgYSBidWcgcmF0 aGVyIHRoYW4gYSA+ZmVhdHVyZS4gRG9lcyBhbnlvbmUga25vdyB0aGUgcmVhc29uIGZvciBpdD8N Cg0KSSBkb24ndCBrbm93IHRoZSByZWFzb24sIGJ1dCBJIEFTU1VNRSB0aGUgcmVhc29uIHdhcyBi ZWNhdXNlIHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSB3YXMgZGVmaW5lZCBmb3IgYSBjb25uZWN0 aW9uIG9yaWVudGVkIHRyYW5zcG9ydCAoVENQKSwgd2hpY2ggU1JUUC1EVExTIGlzIG5vdCAod2Vs bCwgYXQgbGVhc3QgaXQgd2Fzbid0IHdoZW4gU1JUUC1EVExTIHdhcyBkZWZpbmVkIC0gYWZ0ZXIg dGhhdCB3ZSBnb3QgVENQLUlDRSBldGMpLg0KDQpJbiBhbnkgY2FzZSwgSSBkb24ndCB0aGluayBp dCB3b3VsZCBiZSB0b28gbGF0ZSB0byBhbGxvdyB1c2FnZSBvZiB0aGUgYXR0cmlidXRlIGZvciBT UlRQLURUTFMuIEl0IHdvdWxkIGJlIGEgc3RyYWlnaHQgZm9yd2FyZCBtZWNoYW5pc20sIHdoaWNo IGNvdWxkIGJlIHVzZWQgYm90aCBpbiB0aGUgSUNFIGFuZCBub24tSUNFIGNhc2UuIA0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Fri Apr 3 09:52:17 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801771ACD6D for ; Fri, 3 Apr 2015 09:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMZKHJfbXXAZ for ; Fri, 3 Apr 2015 09:52:14 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3144D1ACD4C for ; Fri, 3 Apr 2015 09:52:14 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so98487207igb.1 for ; Fri, 03 Apr 2015 09:52:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Dkj9w6HZkGfd5ecvT2AzXxSHqQWyQmBVNJPpHnWN9xM=; b=cOIJTsAgIQ8vrNJMN1+JcsWULWjEOdZ5K/zLOyAZ4Vy8d9e/XB+SwrfxR5t3cZCFPF kZe6C6Tt/r12qsXiGxjDGFsUcDr9xdcLABPY/tdoSLR2mzMKjVRVdcj2BNXOqqtrjnkO l861aUIIfwsTgXZcU8J77Zg1e4cbWotyZBiQEyv/hedyz+RxGT2MghyH95oWzD2GO7Kj AiIngkTUPHJGCq9dBTQAvBeno/Dfnt5Vvnzlri6s4d1OdmLQpdSRkA6WXDs0k19mPOYc k+7F1y3JhL0o0n941+ifk7pEtjM6EqVcCcIhFqhu+Z+5p8p7giOLYvR+hxaEoONtGYGo zU+g== X-Gm-Message-State: ALoCoQngGfz5Ogjv/VTYwaLPXg10ww9beE0V2pYRUhCMKMJVOWGrJuBnNMNqiXb1FcEBpWQUTSln X-Received: by 10.107.5.15 with SMTP id 15mr5224691iof.57.1428079933703; Fri, 03 Apr 2015 09:52:13 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com. [209.85.223.172]) by mx.google.com with ESMTPSA id i1sm1795425igh.5.2015.04.03.09.52.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 09:52:12 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so87463601ieb.0 for ; Fri, 03 Apr 2015 09:52:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.89.133 with SMTP id be5mr2043668icc.2.1428079931640; Fri, 03 Apr 2015 09:52:11 -0700 (PDT) Received: by 10.36.110.141 with HTTP; Fri, 3 Apr 2015 09:52:11 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78A17F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A17F@ESESSMB209.ericsson.se> Date: Fri, 3 Apr 2015 12:52:11 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec5196a2d0953b60512d4c53b Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 03 Apr 2015 16:52:16 -0000 --bcaec5196a2d0953b60512d4c53b Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 10:37 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > (In fact, I believe re-establishing the SCTP association would more or > less eliminate the risk of receiving packets associated with the old DTLS > connection.) > I think you have the layering wrong, if SCTP is running on top of DTLS, then you can still receive DTLS packets for the old DTLS session. It should not be relevant to the current discussion since in case of device change both should be reset. Without device change both should stay connected. _____________ Roman Shpount --bcaec5196a2d0953b60512d4c53b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 10:37 AM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:
(In fact, I bel= ieve re-establishing the SCTP association would more or less eliminate the = risk of receiving packets associated with the old DTLS connection.)

I think you have the layering wrong, if SCTP i= s running on top of DTLS, then you can still receive DTLS packets for the o= ld DTLS session. It should not be relevant to the current discussion since = in case of device change both should be reset. Without device change both s= hould stay connected.
____________= _
Roman Shpount
=C2=A0
--bcaec5196a2d0953b60512d4c53b-- From nobody Fri Apr 3 10:00:57 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45961ACDA6 for ; Fri, 3 Apr 2015 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg6CLkS9phoE for ; Fri, 3 Apr 2015 10:00:51 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517931ACDA4 for ; Fri, 3 Apr 2015 10:00:51 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so98621719igb.1 for ; Fri, 03 Apr 2015 10:00:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zx2uUVNW/dQEpcF6SMOty63vzUMCDwSbiI1ONgfr7Fk=; b=AEB2Iy5yShbbyh/1bV6z/PJdeZ2fsR/nAe//hR3NRL928FZ0MkE1OUAb5Yzq5jL5Bu caf71Ph3ImFm72sEL9XXmSpngp0Ft86XHP6/a9/+/8PLdQN9PDPtvkLeoJ3YNgUMKhOU AP4RcxivrODj6BfEcVkbIx0/e+sn2P8zqILZ4QX0YTT8SGwpcjsN6vaL7U2yPUlUwpsV 9BC5EoxXQqyllRVu++zLzQB1sb2n11BEeLkKLiT5v34vqD5oWNMj/HN1yezjupfbYP4i AaJ+Lmyyy1ySdB0V92aQoKXRmAYliWbeHJPVqFAr+r6wc8ADZOFoXpx1rA6Wdq3grTgS rOXA== X-Gm-Message-State: ALoCoQk6PyXRnG1kzVi7l5wQ8hu1jeskDNNMxJO6s92wDB/oUHkWBPeFAbXhrj8Baux+dztAXlee X-Received: by 10.42.44.132 with SMTP id b4mr4925916icf.73.1428080450844; Fri, 03 Apr 2015 10:00:50 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com. [209.85.223.177]) by mx.google.com with ESMTPSA id q191sm5800334ioe.39.2015.04.03.10.00.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 10:00:50 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so87609810ieb.0 for ; Fri, 03 Apr 2015 10:00:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.167.3 with SMTP id q3mr5222115ioe.18.1428080448820; Fri, 03 Apr 2015 10:00:48 -0700 (PDT) Received: by 10.36.110.141 with HTTP; Fri, 3 Apr 2015 10:00:48 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> Date: Fri, 3 Apr 2015 13:00:48 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1141ca9edcdf900512d4e3a8 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 03 Apr 2015 17:00:54 -0000 --001a1141ca9edcdf900512d4e3a8 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > In any case, I don't think it would be too late to allow usage of the > attribute for SRTP-DTLS. It would be a straight forward mechanism, which > could be used both in the ICE and non-ICE case. > I agree this is not too late to allow usage of the attribute for SRTP-DTLS or any other protocol running on top of DTLS, but there are several backward compatibility questions: First of all, should the DTLS connection be reset on the transport (5-tuple) change in the non-ICE case if fingerprint stayed the same and the connection attribute is not present? Current specification says that it should, so this needs to be preserved for backwards compatibility. Also, should sending connection attribute set to "existing" and changing the underlying transport be allowed? If backwards compatibility to be maintained, it should not. _____________ Roman Shpount --001a1141ca9edcdf900512d4e3a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 10:40 AM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:

In any case, I don't think it would be too late to allow usage of the a= ttribute for SRTP-DTLS. It would be a straight forward mechanism, which cou= ld be used both in the ICE and non-ICE case.

I agree this is not too late to allow usage of the attribute for SRTP= -DTLS or any other protocol running on top of DTLS, but there are several b= ackward compatibility questions:=C2=A0

First of al= l, should the DTLS connection be reset on the transport (5-tuple) change in= the non-ICE case if fingerprint stayed the same and the connection attribu= te is not present? Current specification says that it should, so this needs= to be preserved for backwards compatibility.

Also= , should sending connection attribute set to "existing" and chang= ing the underlying transport be allowed? If backwards compatibility to be m= aintained, it should not.
_____________
Roman Shpount
=C2=A0
=
--001a1141ca9edcdf900512d4e3a8-- From nobody Fri Apr 3 11:00:13 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C141ACE9C for ; Fri, 3 Apr 2015 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTavqRz2Il_Y for ; Fri, 3 Apr 2015 11:00:09 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B441ACE95 for ; Fri, 3 Apr 2015 11:00:08 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-e8-551ed526c9cf Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B4.5B.28835.625DE155; Fri, 3 Apr 2015 20:00:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Fri, 3 Apr 2015 20:00:06 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA//2gvgD/+fe8oP/z6QIA/+ef7Tg= Date: Fri, 3 Apr 2015 18:00:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@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_7594FB04B1934943A5C02806D1A2204B1D78A6B6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rlftqlyowde5lhZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgy9h2+zFLwWrvi9Jlm9gbG B6pdjJwcEgImEjf/TWaBsMUkLtxbz9bFyMUhJHCUUeLNon3sEM5iRonlU2cBZTg42AQsJLr/ aYM0iAioSvz9PpkJxGYW8JV4ueALM4gtLGAp8W3DFCaIGiuJ3glLmEHmiAh0MUq0TvsGNodF QEVi+0MOkBpeoN5b3TPB6oUE1rNLnGwrBrE5BQIldl3dDHYcI9Bx30+tgdolLtH0ZSUrxNEC Ekv2nGeGsEUlXj7+xwpRky+xePE8Roj5ghInZz5hmcAoMgtJ+ywkZbOQlEHEDSS+vL8NZWtL LFv4mhnC1pfofn+aCVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzASDu45bfVDsaD zx0PMQpwMCrx8C5IkQsVYk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAj EwenVAOj+6G95W7b7VZP89tpJzR70suwq1x9HEZcT0KsfM9cYAl4G2uu/T7y65TARdu/Tq06 JG/7UOKDwc7YS9Pyjx/5UNOUePTdfxENL5fZGmsOKsauZGhvvBPD472s7uf5HMm3GX4zA90X PH0z7d66uqtnbubIzp3D6x5U//X8fqVpnUF/NS1lPxXVKrEUZyQaajEXFScCAF0o1UWVAgAA Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 03 Apr 2015 18:00:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D78A6B6ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, There are obviously "combinations" that are ambiguous, but you'll find that= elsewhere too. Or, we simply define an order in which things (5-tuple changes, attribute v= alues etc) are checked. Or, we do NOT use the attribute for non-ICE. Or, we do something else - but we DO need to solve this. Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD03/=FD04/=FD2015 20:00 To: Christer Holmberg Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg > wrote: In any case, I don't think it would be too late to allow usage of the attri= bute for SRTP-DTLS. It would be a straight forward mechanism, which could b= e used both in the ICE and non-ICE case. I agree this is not too late to allow usage of the attribute for SRTP-DTLS = or any other protocol running on top of DTLS, but there are several backwar= d compatibility questions: First of all, should the DTLS connection be reset on the transport (5-tuple= ) change in the non-ICE case if fingerprint stayed the same and the connect= ion attribute is not present? Current specification says that it should, so= this needs to be preserved for backwards compatibility. Also, should sending connection attribute set to "existing" and changing th= e underlying transport be allowed? If backwards compatibility to be maintai= ned, it should not. _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B1D78A6B6ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

There are obviously "combinations" that are ambiguous, but you'll= find that elsewhere too.

Or, we simply define an order in which things (5-tuple changes, attribute v= alues etc) are checked.

Or, we do NOT use the attribute for non-ICE.

Or, we do something else - but we DO need to solve this.

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount
Sent: =FD03= /=FD04/=FD2015 20:00
To: Christer Holmberg Cc: Paul Kyzivat; mmusic@ietf.org
Subject: Re: [= MMUSIC] SCTP-SDP: Virtual Connection impact

On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

In any case, I don't think it would be too late to allow usage of the attri= bute for SRTP-DTLS. It would be a straight forward mechanism, which could b= e used both in the ICE and non-ICE case.

I agree this is not too late to allow usage of the attribute for SRTP-= DTLS or any other protocol running on top of DTLS, but there are several ba= ckward compatibility questions: 

First of all, should the DTLS connection be reset on the transport (5-= tuple) change in the non-ICE case if fingerprint stayed the same and the co= nnection attribute is not present? Current specification says that it shoul= d, so this needs to be preserved for backwards compatibility.

Also, should sending connection attribute set to "existing" = and changing the underlying transport be allowed? If backwards compatibilit= y to be maintained, it should not.
_____________
Roman Shpount
 
--_000_7594FB04B1934943A5C02806D1A2204B1D78A6B6ESESSMB209erics_-- From nobody Tue Apr 7 04:13:30 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99F71B3460 for ; Tue, 7 Apr 2015 04:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnQ1qxLJzhkq for ; Tue, 7 Apr 2015 04:13:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361531A6F04 for ; Tue, 7 Apr 2015 04:13:26 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-1a-5523bbd470b6 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 41.B4.19337.4DBB3255; Tue, 7 Apr 2015 13:13:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 7 Apr 2015 13:13:23 +0200 From: Christer Holmberg To: Christer Holmberg , Roman Shpount Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA//2gvgD/+fe8oP/z6QIA/+ef7Tj/yWkAUA== Date: Tue, 7 Apr 2015 11:13:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78A6B6@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D78D4F3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RvfKbuVQg4e35CymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlrJjLV3AxrOJez1/mBsZj Pl2MnBwSAiYSbXPXsUDYYhIX7q1n62Lk4hASOMoosen6fnYIZzGjxKfti4AcDg42AQuJ7n/a IA0iAtESHz4sYAKxmQV8Jd7/nM4OYgsLWEp82zCFCaLGSqJ3whJmCHsSo0RPjzKIzSKgItG8 fTojiM0L1Pv9+C0miF3f2CX2HTgHNohTwE/i/p2VrCA2I9B130+tgVomLnHryXwmiKsFJJbs Oc8MYYtKvHz8jxXCVpS4On05E8jNzAL5ErdXVUDsEpQ4OfMJywRG0VlIJs1CqJqFpAqixEDi 3PaN7BC2tsSyha+ZIWx9ie23Z7Iiiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERh9 B7f8Vt3BePmN4yFGAQ5GJR5eBSvlUCHWxLLiytxDjNIcLErivHbGh0KEBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MHK937OHe9Ucru4eiU6jad8dC9XlDUvfMrP9KbNIUb3wcN6FtM4z1k4W 4gV7ns17q56j+lxw9Y4pGbJbPpo7cuzM8lrkflved+vCs3ZyN289fGxqsKniitOVP+76js46 NfftJvw9U7jRhKnVdTLHqZ2KDAVPb9b/l9MJu+/jfXxiouMKUZEHZkosxRmJhlrMRcWJAPXh et2fAgAA Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 11:13:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D78D4F3ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Any comments on this from others? We need to solve it. Anyone has issues with allowing connection:new for SRTP-DTLS and SCTP-DTLS,= and use that as a trigger to re-negotiate DTLS? Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 3. huhtikuuta 2015 21:00 To: Roman Shpount Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact Hi, There are obviously "combinations" that are ambiguous, but you'll find that= elsewhere too. Or, we simply define an order in which things (5-tuple changes, attribute v= alues etc) are checked. Or, we do NOT use the attribute for non-ICE. Or, we do something else - but we DO need to solve this. Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD03/=FD04/=FD2015 20:00 To: Christer Holmberg Cc: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg > wrote: In any case, I don't think it would be too late to allow usage of the attri= bute for SRTP-DTLS. It would be a straight forward mechanism, which could b= e used both in the ICE and non-ICE case. I agree this is not too late to allow usage of the attribute for SRTP-DTLS = or any other protocol running on top of DTLS, but there are several backwar= d compatibility questions: First of all, should the DTLS connection be reset on the transport (5-tuple= ) change in the non-ICE case if fingerprint stayed the same and the connect= ion attribute is not present? Current specification says that it should, so= this needs to be preserved for backwards compatibility. Also, should sending connection attribute set to "existing" and changing th= e underlying transport be allowed? If backwards compatibility to be maintai= ned, it should not. _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B1D78D4F3ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Any commen= ts on this from others? We need to solve it.

 = ;

Anyone has= issues with allowing connection:new for SRTP-DTLS and SCTP-DTLS, and use t= hat as a trigger to re-negotiate DTLS?

 = ;

Regards,

 = ;

Christer

 = ;

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 3. huhtikuuta 2015 21:00
To: Roman Shpount
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact=

 

Hi,

There are obviously "combinations" that are ambiguous, but you'll= find that elsewhere too.

Or, we simply define an order in which things (5-tuple changes, attribute v= alues etc) are checked.

Or, we do NOT use the attribute for non-ICE.

Or, we do something else - but we DO need to solve this.

Regards,

Christer

Sent from my Windows Phone

From: Roman Shpount<= /a>
Sent: =FD03/=FD04/=FD2015 20:00
To: Christer Holmberg
Cc: Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:


In any case, I don't think it would be too late to allow usage of the attri= bute for SRTP-DTLS. It would be a straight forward mechanism, which could b= e used both in the ICE and non-ICE case.

 

I agree this is not too late to allow usage of the a= ttribute for SRTP-DTLS or any other protocol running on top of DTLS, but th= ere are several backward compatibility questions: 

 

First of all, should the DTLS connection be reset on= the transport (5-tuple) change in the non-ICE case if fingerprint stayed t= he same and the connection attribute is not present? Current specification = says that it should, so this needs to be preserved for backwards compatibility.

 

Also, should sending connection attribute set to &qu= ot;existing" and changing the underlying transport be allowed? If back= wards compatibility to be maintained, it should not.

_____________

Roman Shpount

 

--_000_7594FB04B1934943A5C02806D1A2204B1D78D4F3ESESSMB209erics_-- From nobody Wed Apr 8 10:01:25 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502421B3485 for ; Wed, 8 Apr 2015 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y64EjD2pUgXw for ; Wed, 8 Apr 2015 10:01:21 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459741B3482 for ; Wed, 8 Apr 2015 10:01:21 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-04v.sys.comcast.net with comcast id DV0V1q0032VvR6D01V1L6z; Wed, 08 Apr 2015 17:01:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id DV1K1q00f3Ge9ey01V1Kvf; Wed, 08 Apr 2015 17:01:20 +0000 Message-ID: <55255EDF.3030903@alum.mit.edu> Date: Wed, 08 Apr 2015 13:01:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1428512480; bh=EwOvUJUvjrrx6uY2eCncA1nVGd8WjWXaWAex7cbtYLM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mFMXG0Ytc8pVUMNDIhiyNDXtCz/JA5M9S2ND0Nh95QxdLEuxMlhTAgleOX5Txa3Ar NIuzKc+nb34r+QGKWd2Je+Pknc1HrAIdKC5LMh5lrZBXSbXO95vTj4VOL+HUhwgbft WdzbAywBRt3fu+aWY0v5r9wYmB7a0ugaJq+wyZ7Gf4BNSFIW67v8xtMDc/iFA49QhR oyLERzcO+Yo0K2ukz5wOItSE1ETC7Blo7sdBH9BYiPFWJHpZ1BpNdPj0Msq19MD4jN aC/sda8gk0SUoAwK1/MbNyCWC7ub6TqCvDJ6ZeLhySPzrzKeKmyoEJ5X6ywi/xAYss W+Yx1g08Q6Llw== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:01:23 -0000 On 4/7/15 7:13 AM, Christer Holmberg wrote: > Hi, > > Any comments on this from others? We need to solve it. > > Anyone has issues with allowing connection:new for SRTP-DTLS and > SCTP-DTLS, and use that as a trigger to re-negotiate DTLS? ISTM that this is being considered tactically. Maybe that is the best for now, but perhaps there should be consideration of a strategic approach to this as well. What I mean is that this seems to be a back handed way to introduce multipath support into protocols (specifically DTLS) that don't support it. Perhaps multipath ought to be officially added to all the protocols that potentially need ICE, and then ICE would simply be one way to populate the paths. Thanks, Paul > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 3. huhtikuuta 2015 21:00 > *To:* Roman Shpount > *Cc:* mmusic@ietf.org; Paul Kyzivat > *Subject:* Re: [MMUSIC] SCTP-SDP: Virtual Connection impact > > Hi, > > There are obviously "combinations" that are ambiguous, but you'll find > that elsewhere too. > > Or, we simply define an order in which things (5-tuple changes, > attribute values etc) are checked. > > Or, we do NOT use the attribute for non-ICE. > > Or, we do something else - but we DO need to solve this. > > Regards, > > Christer > > Sent from my Windows Phone > > ------------------------------------------------------------------------ > > *From: *Roman Shpount > *Sent: *03/04/2015 20:00 > *To: *Christer Holmberg > *Cc: *Paul Kyzivat ; mmusic@ietf.org > > *Subject: *Re: [MMUSIC] SCTP-SDP: Virtual Connection impact > > On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg > > > wrote: > > > In any case, I don't think it would be too late to allow usage of the > attribute for SRTP-DTLS. It would be a straight forward mechanism, which > could be used both in the ICE and non-ICE case. > > I agree this is not too late to allow usage of the attribute for > SRTP-DTLS or any other protocol running on top of DTLS, but there are > several backward compatibility questions: > > First of all, should the DTLS connection be reset on the transport > (5-tuple) change in the non-ICE case if fingerprint stayed the same and > the connection attribute is not present? Current specification says that > it should, so this needs to be preserved for backwards compatibility. > > Also, should sending connection attribute set to "existing" and changing > the underlying transport be allowed? If backwards compatibility to be > maintained, it should not. > > _____________ > > Roman Shpount > From nobody Wed Apr 8 10:21:22 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65091B34C1 for ; Wed, 8 Apr 2015 10:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKyDjmexSj0Z for ; Wed, 8 Apr 2015 10:21:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FF21B34C9 for ; Wed, 8 Apr 2015 10:21:16 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t38HL7vq051431 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 12:21:09 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55256383.9050708@nostrum.com> Date: Wed, 08 Apr 2015 12:21:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Flemming Andreasen , mmusic References: <5519B9B2.9090701@cisco.com> In-Reply-To: <5519B9B2.9090701@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:21:21 -0000 On 3/30/15 16:01, Flemming Andreasen wrote: > Please review and provide any comments you may have on the document > changes by Monday, April 13, 2015. Comments should be sent to the > document authors and the MMUSIC WG list. If you review the document > but do not have any comments, please send a note to that effect as well. I have reviewed the body of the document, and have a number of comments. These are of varying severity, ranging from editorial suggestions to proposed normative changes. They appear in document order. --------------------------------------------------------------------------- In the Abstract: "This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to allow an answerer to assign a non-zero port value to an "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port values. This seems to be a bit of a deep dive for the abstract, and I would propose removing it. If it does remain, it needs to include something like "under certain circumstances." But I think removal is the better option. The introduction should also qualify the similar statement in this paragraph: This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 [RFC3264]. The update allows an answerer to assign a non-zero port value to an "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port value. --------------------------------------------------------------------------- Especially because the term is overloaded, you should expand the meaning of "SDES" on first use; something like: "This specification also defines a new Real-time Transport Protocol (RTP) [RFC3550] Source Description (SDES) item..." --------------------------------------------------------------------------- Terminology: Since we are using '"m=" line' in a way that isn't (to my knowledge) defined in another document, this section should include a definition for that term. Yes, it's in the introduction, but that's not where people look for definitions of terms. --------------------------------------------------------------------------- Section 5 should cite RFC 4961 for the definition of "symmetric RTP." --------------------------------------------------------------------------- Section 5 has this normative requirement: A given address:port combination MUST NOT be used for sending media associated with multiple BUNDLE groups. It's not clear what this gains us. Everywhere else, we only require a unique 5-tuple per bundle. That seems like the correct restriction to impose. (If we change this, it also has impacts on section 8.3.3) --------------------------------------------------------------------------- Section 5: Each "m=" line, whose identification-tag is listed in the identification-tag list, is associated with a given BUNDLE group. Repunctuate as: Each "m=" line whose identification-tag is listed in the identification-tag list is associated with a given BUNDLE group. (cf. ) --------------------------------------------------------------------------- Section 6: This whole section feels really out of place here; it's assuming that the reader has knowledge about BUNDLE offer/answer handling that he won't learn until reading section 8. I would propose that you leave the attribute definition in section 14.3, and move the semantics into section 8. --------------------------------------------------------------------------- Section 6: "In order to ensure that an answerer that does not supports the BUNDLE" s/supports/support/ --------------------------------------------------------------------------- Section 6: NOTE: Once an offerer BUNDLE address has been selected, the offerer can ensure that an bundled "m=" line is accepted by the answerer only if the answerer keeps the "m=" line within the associated BUNDLE group by assigning the offerer BUNDLE address to the "m=" line. If the answerer does not keep that "m=" line within the BUNDLE group, the answerer will reject it. Therefore, the SDP 'bundle-only' attribute is not needed in such cases I can't make any sense of that paragraph, and it's only partially because the passive "has been selected" doesn't indicate who is performing the selection. In particular, it doesn't sound like the offerer is *ensuring* anything. Maybe we're trying to say he can detect something? But even with that interpretation, it's not clear what circumstances it's trying to say don't require the use of 'bundle-only.' Or is this trying to say that subsequent offers (as defined in section 2) don't need to use 'bundle-only' because you know whether the peer supports bundle? That makes some sense, but it's really hard to get that meaning out of the text. Let me take a stab at something. NOTE: Subsequent offers do not need to include the 'bundle-only' attribute, since the offerer will already know whether its peer supports the BUNDLE mechanism. With that knowledge, the offerer can assign a new 'm=' line to an existing BUNDLE address. By doing so, they ensure that the answerer either accepts the line into the BUNDLE, or completely rejects it. If that's what we mean, I propose replacing the paragraph with it. If it's not, then the paragraph needs to be rewritten. Also, if that's what we mean, then it needs corresponding text in section 8.3.1 (although if you take the suggestion to move the semantics from section 6 into section 8, it might make more sense to just put it there only rather than describe it in two places). --------------------------------------------------------------------------- Section 8.1: The offerer and answerer MUST follow the rules and restrictions defined in Section 7 when creating offers and answers. This adds nothing. I would propose removing it (or, if you don't want to remove it, I would propose that consistency calls for having every section normatively require that implementors follow the normative statements of every other section in the document). --------------------------------------------------------------------------- Section 8.2.1: o Add an SDP 'group:BUNDLE' attribute to the offer; Replace with: o Add an SDP 'group:BUNDLE' attribute to the offer at the session level; --------------------------------------------------------------------------- Section 8.3.1: When an answerer generates an answer, which contains a BUNDLE group, Replace with: When an answerer generates an answer that contains a BUNDLE group, (cf. ) --------------------------------------------------------------------------- The procedure described in Section 8.3.2 has a rather unfortunate property that I'm not sure we want. If I were to offer something like: a=group:BUNDLE foo bar m=video 20002 RTP/AVP 97 a=rtpmap:97 H261/90000 a=mid:foo m=video 0 RTP/AVP 97 98 a=rtpmap:97 H261/90000 a=rtpmap:98 VP8/90000 a=bundle-only a=mid:bar And the remote endpoint wanted to reject the first stream, it would be forced to also reject the second. The historical intention of using "bundle-only" was as a mechanism for UDP port preservation on the offerer's side. This procedure unintentionally turns it into a semantic binding among streams in bundle. I think we could restore the original purpose of the bundle-only handling if we used the port from the rejected 'm=' line containing the BUNDLE-tag for any 'bundle-only' lines. -------------------------------------------------------------------------- Section 8.3.4 is structured very awkwardly. It calls out two conditions that preclude moving an m= line out of a bundle (shared address, bundle-only), and one that allows it. It would be much clearer if it were stated in those terms rather than describing the rejection of a media stream as if it were the same thing as accepting a media stream with different addressing information. -------------------------------------------------------------------------- Section 8.4.1: When an offerer receives an answer, if the answer contains a BUNDLE group, the offerer MUST check that any bundled "m=" line in the answer was indicated as bundled in the associated offer. This is backwards as compared to the logic described in the section. The remainder of the text talks about checking whether that bundled "m=" lines in the *offer* appear in the *answer* (and, if they don't, moving them out of the bundle). If the answer has a bundle that contains an m-line that wasn't bundled in the offer, it's an error. Also, 8.4.1 is the only subsection in 8.4, which is otherwise empty. I suggest removing 8.4.1, and putting its contents directly in 8.4. -------------------------------------------------------------------------- The optionality in section 8.5.2 seems unnecessarily complex, and it's difficult to see what it gains us. Why don't we simply specify that each pre-existing m= line MUST have a single shared address? To be clear: if we keep this behavior, then I think we want the answer to that question in the document. -------------------------------------------------------------------------- Section 8.5.4 should explicitly mention the case in which the line being moved out is the one identified by the BUNDLE-tag. I think all we need to say is that the BUNDLE-tag for a bundle changes if the corresponding m= line is removed from the bundle. -------------------------------------------------------------------------- Section 9.1: "publically" is more conventionally spelled "publicly" -------------------------------------------------------------------------- Section 10.2: An offerer and answerer can in an offer and answer inform each other which SSRC values they will use inside sent RTP/RTCP packets, by associating one or more SDP 'ssrc' attributes [RFC5576] with each bundled "m=" line which contains a payload type value that is also used inside another bundled "m=" line. That's really hard to follow. I propose reformulating along the lines of: Peers to a session can inform each other which SSRC values they will use for RTP and RTCP through the use of the SDP 'ssrc' attribute [RFC5576]. To allow for proper association with this mechanism, the 'ssrc' attribute needs to appear in each "m=" line that shares a payload type with any other "m=" line in the same bundle. Also, doesn't the final paragraph of this section kind of make the rest of the section a waste of space? -------------------------------------------------------------------------- Section 10.3.1: When a BUNDLE group, which contains RTP based media, is created,... Change to: When a BUNDLE group that contains RTP based media is created,... -------------------------------------------------------------------------- Section 10.3 (and its subsections) doesn't clearly explain where RTCP will be received in the various described scenarios. In particular, I believe we need to clarify that, while users might indicate a bunch of different rtcp ports (using the 'rtcp' attribute) in bundled "m=" lines, if the answer accepts an "m=" line into a bundle, then the rtcp port indicated in the section associated with the selected BUNDLE address will be used. -------------------------------------------------------------------------- 11.2.3: When an answerer generates an answer, which contains a BUNDLE group, Replace with: When an answerer generates an answer that contains a BUNDLE group, -------------------------------------------------------------------------- Section 12, general: Figuring out what changed in these rather large swaths of text is difficult. It would be very helpful if these were broken down like: 12.2 Changes to section 5.1 (2nd paragraph) of RFC 3264 The final sentence of the paragraph is modified to change the meaning of port zero. 12.2.1 Original Text ... 12.2.2 New Text ... 12.3 Changes to section 8.2 (2nd paragraph) of RFC 3264 ... 12.3.1 Original Text ... 12.3.2 New Text ... etc. -------------------------------------------------------------------------- Section 13.1: The endpoint informs the remote endpoint about the identification-tag using the procedures in [RFC5888], and the remote endpoint then inserts the identification-tag in RTCP- and RTP packets sent towards the other endpoint. It's really hard to follow which endpoint is doing what. Perhaps something like this would be clearer: A media recipient informs the media sender about the identification-tag associated with an "m=" line through the use of an 'mid' attribute [RFC5888]. The media sender then inserts the identification-tag in RTCP and RTP packets sent to the media recipient. -------------------------------------------------------------------------- Section 14: There is no IANA section that registers the "BUNDLE" token for this registry: http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-13 For sections 14.2 and 14.3, I believe it is traditional for WG items to list the WG as contact for IANA registrations rather than individual document authors. -------------------------------------------------------------------------- I have not reviewed the examples or the appendix. /a From nobody Wed Apr 8 11:44:32 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B5C1ACE1F for ; Wed, 8 Apr 2015 11:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1okckwDEw7p for ; Wed, 8 Apr 2015 11:44:29 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393B01A8BC0 for ; Wed, 8 Apr 2015 11:44:29 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so92654349ied.1 for ; Wed, 08 Apr 2015 11:44:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=stvBjewqKA7CdSQ/C47QisOTSAax8HUUm8a00Fy/OT8=; b=CIGT1mWDFHFdJYLWsqywKtXzSy9J18PUL35PPmmED1e5hgFn1lOYil+ojYbJb+JtNJ qajoaLC6kGjvufEHIqbjnmcOjNoVDEHLApkxfghHGCQCVrx6JJpgwCcGJzjliylfyWsP jTkBZ3blhmz4sBTfG9a3lfFX8Y55b28dkzYEhWVbYJ7etkC1DOUQ6/6xRZwrJrcUict2 gKxz+kDGQ89kmd/NGt3kys4u8Ilr6InxZ19KTQCkkzAf8ZPxRqMe0gopynsVOjloyKMr N/ywsbc+s2cdprhDR0OBX4a6IWaZ3Pvh15Uo0pLb1ypiyNJmYW+rl2ZJwpx/JoVpahfT Cnww== X-Gm-Message-State: ALoCoQniImUD9qoOmp03Oxn2eUR95o9SdevxglMYQwDcWYH9M/CzcG6QnvzwWxUNIhIXFhDDmai8 X-Received: by 10.107.129.22 with SMTP id c22mr31676433iod.81.1428518668652; Wed, 08 Apr 2015 11:44:28 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by mx.google.com with ESMTPSA id f11sm702057iod.7.2015.04.08.11.44.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 11:44:27 -0700 (PDT) Received: by iggg4 with SMTP id g4so47765164igg.0 for ; Wed, 08 Apr 2015 11:44:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.11.211 with SMTP id 80mr3914517iol.18.1428518665453; Wed, 08 Apr 2015 11:44:25 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Wed, 8 Apr 2015 11:44:25 -0700 (PDT) In-Reply-To: <55255EDF.3030903@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> Date: Wed, 8 Apr 2015 14:44:25 -0400 Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113f8f5a9c08f005133aeb61 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:44:31 -0000 --001a113f8f5a9c08f005133aeb61 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 1:01 PM, Paul Kyzivat wrote: > On 4/7/15 7:13 AM, Christer Holmberg wrote: > >> Hi, >> >> Any comments on this from others? We need to solve it. >> >> Anyone has issues with allowing connection:new for SRTP-DTLS and >> SCTP-DTLS, and use that as a trigger to re-negotiate DTLS? >> > > ISTM that this is being considered tactically. Maybe that is the best for > now, but perhaps there should be consideration of a strategic approach to > this as well. > > What I mean is that this seems to be a back handed way to introduce > multipath support into protocols (specifically DTLS) that don't support it. > Perhaps multipath ought to be officially added to all the protocols that > potentially need ICE, and then ICE would simply be one way to populate the > paths. > > This will still leave the question of how to determine when the multipath protocol running over ICE communicates with the new end point (i.e. connection needs to be re-established) or when this is a path update and the connection needs to be preserved. For ICE there is no easy way to determine if what currently is happening is ICE-restart on the existing connection which should allow existing mutlipath protocol session to continue vs setting up ICE to a new end point which would require new connection setup. This problem currently affects DTLS, but I assume this will apply also to other multipath protocols which require externally initiated connection handshake when running over ICE. This can be addressed on the protocol side (connection new attribute which will apply to DTLS) or on ICE side (some sort of indication if this is a new end-point or re-start). Protocol side change seemed to be the less disruptive and more backwards compatible option in case of DTLS. The reason DTLS is running into problems with ICE, is due to the fact that it was not design to run multiple sessions over the same connection and does not allow setting up a new session unsolicited using transport messages only, which are properties of RTP for which ICE was originally designed. Extending DTLS so that it is possible to multiplex several DTLS sessions over the same connection, and initiate new session setup using transport level messages, would be a better strategic solution. Unfortunately this is not going to be backwards compatible and would further complicate design and implementation. >From my personal point of view, DTLS in combination with ICE is a design mess. It would be much cleaner and strategic if instead two separate protocols this was a single protocol which was responsible for authentication, encryption negotiation, connection path discovery, path updates, and communication consent. These are closely related tasks and ideally they should be handled together instead of one on top of the other. _____________ Roman Shpount --001a113f8f5a9c08f005133aeb61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 8, 2015 at 1:01 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>= ; wrote:
On 4/7/15 7:13 AM, Chr= ister Holmberg wrote:
Hi,

Any comments on this from others? We need to solve it.

Anyone has issues with allowing connection:new for SRTP-DTLS and
SCTP-DTLS, and use that as a trigger to re-negotiate DTLS?

 ISTM that this is being considered tactically. Maybe that is the best for n= ow, but perhaps there should be consideration of a strategic approach to th= is as well.

What I mean is that this seems to be a back handed way to introduce multipa= th support into protocols (specifically DTLS) that don't support it. Pe= rhaps multipath ought to be officially added to all the protocols that pote= ntially need ICE, and then ICE would simply be one way to populate the path= s.


This will still leave the question of = how to determine when the multipath protocol running over ICE communicates = with the new end point (i.e. connection needs to be re-established) or when= this is a path update and the connection needs to be preserved. For ICE th= ere is no easy way to determine if what currently is happening is ICE-resta= rt on the existing connection which should allow existing mutlipath protoco= l session to continue vs setting up ICE to a new end point which would requ= ire new connection setup. This problem currently affects DTLS, but I assume= this will apply also to other multipath protocols which require externally= initiated connection handshake when running over ICE. This can be addresse= d on the protocol side (connection new attribute which will apply to DTLS) = or on ICE side (some sort of indication if this is a new end-point or re-st= art). Protocol side change seemed to be the less disruptive and more backwa= rds compatible option in case of DTLS.=C2=A0

The r= eason DTLS is running into problems with ICE, is due to the fact that it wa= s not design to run multiple sessions over the same connection and does not= allow setting up a new session unsolicited using transport messages only, = which are properties of RTP for which ICE was originally designed. Extendin= g DTLS so that it is possible to multiplex several DTLS sessions over the s= ame connection, and initiate new session setup using transport level messag= es, would be a better strategic solution. Unfortunately this is not going t= o be backwards compatible and would further complicate design and implement= ation.

From my personal point of view, DTLS in com= bination with ICE is a design mess. It would be much cleaner and strategic = if instead two separate protocols this was a single protocol which was resp= onsible for=C2=A0authentication,=C2=A0encryption negotiation, connection pa= th discovery, path updates, and communication consent. These are closely re= lated tasks and ideally they should be handled together instead of one on t= op of the other.
_____________
= Roman Shpount
=C2=A0
--001a113f8f5a9c08f005133aeb61-- From nobody Fri Apr 10 06:41:56 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AEE1B35CF for ; Fri, 10 Apr 2015 06:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7i0qcSa47Fo for ; Fri, 10 Apr 2015 06:41:52 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E131B35C8 for ; Fri, 10 Apr 2015 06:41:49 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-ec-5527d31cdc9d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.2D.19337.C13D7255; Fri, 10 Apr 2015 15:41:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 15:41:47 +0200 Message-ID: <5527D319.1010607@ericsson.com> Date: Fri, 10 Apr 2015 15:41:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Flemming Andreasen , mmusic References: <5519B9B2.9090701@cisco.com> In-Reply-To: <5519B9B2.9090701@cisco.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvja7MZfVQg1WzhS0+dW9gs3h/Qdfi 394ki6nLH7M4sHhM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyvjz9hNzwX35iuuz jjE3MG6X6GLk4JAQMJGYslevi5ETyBSTuHBvPRuILSRwlFHixmvlLkYuIHs5o8T9uRNYQRK8 AtoSuxqus4DYLAKqEgu2PwCLswlYSNz80QjWLCoQLNH0opEdol5Q4uTMJ2D1IgKuEkcW3mUC GcossItR4t22lWDNwgJeEus/rGWC2Kwhsax5BhvIcZwCmhLfToqDhJkFDCSOLJrDCmHLSzRv nc0MUa4t0dDUwTqBUXAWknWzkLTMQtKygJF5FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg GB/c8lt1B+PlN46HGAU4GJV4eB+kqYcKsSaWFVfmHmKU5mBREue1Mz4UIiSQnliSmp2aWpBa FF9UmpNafIiRiYNTqoFRm+/fP73L1R0nzjUXfWf6WX/99Yb+HJdjyWESVr56Iv+srbPl5239 sUHXbXHJ+XMLo3+HO3sY39rR+uOf2m6p80VOPX0F8fMi385L9WLedsHz1Psb7DkBQT7Llq/X 1l246rQ1091TE9ytbJY3rvU2si17ID1Vfmvjj1vWev4G9hF3NifdL/RTYinOSDTUYi4qTgQA tvtrPEQCAAA= Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 13:41:54 -0000 Hi, I have reviewed the changes once more and have not additional comments. I support requesting publication of this document. Cheers Magnus On 2015-03-30 23:01, Flemming Andreasen wrote: > This is to announce a 2 week Working Group Last Call for > > draft-ietf-mmusic-sdp-bundle-negotiation-19 > > as Proposed Standard. Note that we previously issued a WGLC on the -12 > version (back in October 2014), and since there has been a number of > changes to the draft since then, we want to give people a change to > properly review those changes. > > Please review and provide any comments you may have on the document > changes by Monday, April 13, 2015. Comments should be sent to the > document authors and the MMUSIC WG list. If you review the document but > do not have any comments, please send a note to that effect as well. > > Thanks > > Flemming (MMUSIC co-chair) > > > > Draft Info: > > This draft is a work item of the Multiparty Multimedia Session Control > Working Group of the IETF. > > Title : Negotiating Media Multiplexing Using the > Session Description Protocol (SDP) > Authors : Christer Holmberg > Harald Tveit Alvestrand > Cullen Jennings > Filename : draft-ietf-mmusic-sdp-bundle-negotiation-19.txt > Pages : 48 > Date : 2015-03-26 > > Abstract: > This specification defines a new Session Description Protocol (SDP) > Grouping Framework extension, 'BUNDLE'. The extension can be used > with the SDP Offer/Answer mechanism to negotiate the usage of a > single address:port combination (BUNDLE address) for receiving media, > referred to as bundled media, associated with multiple SDP media > descriptions ("m=" lines). > > To assist endpoints in negotiating the use of bundle this > specification defines a new SDP attribute, 'bundle-only', which can > be used to request that specific media is only used if bundled. This > specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to > allow an answerer to assign a non-zero port value to an "m=" line in > an SDP answer, even if the "m=" line in the associated SDP offer > contained a zero port value. > > There are multiple ways to correlate the bundled RTP packets with the > appropriate media descriptions. This specification defines a new > RTCP source description (SDES) item and a new RTP header extension > that provides an additional way to do this correlation by using them > to carry a value that associates the RTP/RTCP packets with a specific > media description. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-19 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-19 > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Apr 10 07:36:21 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3C11A0266; Fri, 10 Apr 2015 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxt8NVBxskH7; Fri, 10 Apr 2015 07:36:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4461A015F; Fri, 10 Apr 2015 07:36:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410143615.11648.26445.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 07:36:15 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-02.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, 10 Apr 2015 14:36:17 -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 : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-data-channel-sdpneg-02.txt Pages : 30 Date : 2015-04-10 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) 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-02 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 Apr 10 07:44:05 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8011A0371 for ; Fri, 10 Apr 2015 07:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MANGLED_TOOL=2.3, 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 hcu9cyEtYeHm for ; Fri, 10 Apr 2015 07:43:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F5D1A0267 for ; Fri, 10 Apr 2015 07:43:56 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 221BBEF9BE160 for ; Fri, 10 Apr 2015 14:43:52 +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 t3AEhsO2014180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 Apr 2015 16:43:54 +0200 Received: from [149.204.68.136] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 10 Apr 2015 16:43:53 +0200 Message-ID: <5527E1A8.6090608@alcatel-lucent.com> Date: Fri, 10 Apr 2015 16:43:52 +0200 From: Juergen Stoetzer-Bradler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: References: <20150410143615.11648.26445.idtracker@ietfa.amsl.com> In-Reply-To: <20150410143615.11648.26445.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-02.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, 10 Apr 2015 14:44:03 -0000 Hello, The changes of this new version -02 as compared to -01 are listed below and are related to corresponding email list discussions and the discussions in Dallas. Below list is also copied to the change log section 10.1. Thanks, Juergen o New Section 4 regarding applicability to SDP offer/answer only. o Addition of new Section 9.1 "Subprotocol identifiers" as subsection of the "IANA Considerations" related Section 9. Also removal of the temporary note "To be completed. As [I-D.ietf- rtcweb-data-protocol] this document should refer to IANA's WebSocket Subprotocol Name Registry defined in [RFC6455]." o In Section 6.2.2: * In the first paragraph replacement of the sentence "If an SDP offer contains both of these parameters then such an SDP offer will be rejected." with "If an SDP offer contains both of these parameters then the receiver of such an SDP offer MUST reject the SDP offer." * In the second paragraph capitalization of "shall" and "may" such that both sentences now read: "The SDP answer SHALL echo the same subprotocol, max-retr, max-time, ordered parameters, if those were present in the offer, and MAY include a label parameter. They MAY appear in any order, which could be different from the SDP offer, in the SDP answer." * In the third paragraph replacement of the sentence "The same information MUST be replicated without changes in any subsequent offer or answer, as long as the data channel is still opened at the time of offer or answer generation." with "When sending a subsequent offer or an answer, and for as long as the data channel is still open, the sender MUST replicate the same information.". o In Section 6.2.2 the mapping of data channel types defined in [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute parameters were illustrated using example "a=dcmap" attribute lines. Replacement of these example "a=dcmap" attribute lines with just the "a=dcmap" attribute parameters being relevant for the channel type. o In Section 6.2.5 the description of bullet point "SDP offer has no a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: No data channel negotiated yet." Replacement of this description with "Initial SDP offer: No data channel is negotiated yet. The DTLS connection and SCTP association is negotiated and, if agreed, established as per [I-D.ietf-mmusic-sctp-sdp]." o In Section 6.2.5 in both bullet points related to "Subsequent SDP offer" and "Subsequent SDP answer" replacement of "All the externally negotiated data channels must be closed now." with "All the externally negotiated data channels are expected be closed now.". o In Section 5.2.2's sixth paragraph beginning with "[ASSUMPTION]" replacement of the two occurrences of "must" with "MUST". o In Section 6.1.1.1 in the definition of the ABNF rule "dcmap-opt" there was a comment saying that "Either only maxretr-opt or maxtime-opt is present. Both MUST not be present." Removal of the second normative sentence and instead addition of following new paragraph to the end of this section: "Within an 'a=dcmap' attribute line's 'dcmap-opt' value either only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter is present. Both MUST NOT be present." o In Section 6.1.1.7 replacement of the first sentence "The 'ordered' parameter with value "true" indicates that DATA chunks in the channel MUST be dispatched to the upper layer by the receiver while preserving the order." with "The 'ordered' parameter with value "true" indicates that the receiver MUST dispatch DATA chunks in the data channel to the upper layer while preserving the order.". o In Section 6.2.3's first paragraph replacement of the one occurrence of "must" with "..., it MUST wait until ...". o In Section 6.2.4: * In the second paragraph replacement of "must" with "... whether this closing MUST in addition ..." * In the third paragraph replacement of the sentence "The port value for the "m" line SHOULD not be changed (e.g., to zero) when closing a data channel ..." with "The offerer SHOULD NOT change the port value for the "m" line (e.g., to zero) when closing a data channel ...". * In the last but two paragraph replacement of the sentence "... then an SDP offer which excludes this closed data channel SHOULD be generated." with "... then the client SHOULD generate an SDP offer which excludes this closed data channel.". * In the last but one paragraph replacement of "must" with "The application MUST also close...". o In Section 6.1.2 addition of following note after the formal definition of the 'a=dcsa' attribute: "Note that the above reference to RFC 4566 defines were the attribute definition can be found; it does not provide any limitation on support of attributes defined in other documents in accordance with this attribute definition." On 10.04.2015 16:36, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : SDP-based Data Channel Negotiation > Authors : Keith Drage > Maridi R. Makaraju > Juergen Stoetzer-Bradler > Richard Ejzak > Jerome Marcon > Filename : draft-ietf-mmusic-data-channel-sdpneg-02.txt > Pages : 30 > Date : 2015-04-10 > > 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) 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Apr 15 01:23:04 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B8E1B32EB for ; Wed, 15 Apr 2015 01:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khq4-Ol2fO8z for ; Wed, 15 Apr 2015 01:22:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8031B32C0 for ; Wed, 15 Apr 2015 01:22:56 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-1f-552e1fde82a0 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.59.19337.EDF1E255; Wed, 15 Apr 2015 10:22:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Wed, 15 Apr 2015 10:22:54 +0200 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA//2gvgD/+fe8oP/z6QIA/+ef7Tj/yWkAUP+Q/ySA/yHheoD+OU9z8A== Date: Wed, 15 Apr 2015 08:22:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78511C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D786CD9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvje49eb1Qg7U/LS2mLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlLJm6nK3gmmxFe8NPlgbG LzJdjBwcEgImEnMv1ncxcgKZYhIX7q1n62Lk4hASOMoo8W1yPyuEs4RRou/kJ1aQBjYBC4nu f9ogDSIC3hJ9fR3sIGFmAXWJq4uDQMLCApYS3zZMYYIosZLonbCEGWSMiMAyRokNr++ygiRY BFQl/q45xQZi8wr4SpyfvwRq120Oib2TmhlBhnIKBEpcv+UDUsMIdNz3U2vAhjILiEvcejKf CeJoAYkle84zQ9iiEi8f/2OF+EtJYtrWNIjTNCXW79KH6FSUmNL9kB1iq6DEyZlPWCYwis1C MnQWQscsJB2zkHQsYGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYSQe3/FbdwXj5jeMh RgEORiUeXoVjuqFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amAUMjoo0L968u6TjVNOXJRtV9ggkHZEY36x0IN3Iu9Et5j2HvgQaWdkcrb8+C0Ri08Cd3az lHX9mnQh7Jv3+ohH12sesMzl7T0rx7h1zemXfxwdFvc/8LW7fH9q849Ll28afTxfuKu532lZ dSdXAG9d/ra3mkL2K27wbQy3XPhz1dZ/OyJff5d7osRSnJFoqMVcVJwIAKXvCImFAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 08:23:02 -0000 SGksDQoNCj5BbnkgY29tbWVudHMgb24gdGhpcyBmcm9tIG90aGVycz8gV2UgbmVlZCB0byBzb2x2 ZSBpdC4NCj4NCj5BbnlvbmUgaGFzIGlzc3VlcyB3aXRoIGFsbG93aW5nIGNvbm5lY3Rpb246bmV3 IGZvciBTUlRQLURUTFMgYW5kDQo+U0NUUC1EVExTLCBhbmQgdXNlIHRoYXQgYXMgYSB0cmlnZ2Vy IHRvIHJlLW5lZ290aWF0ZSBEVExTPw0KPg0KPklTVE0gdGhhdCB0aGlzIGlzIGJlaW5nIGNvbnNp ZGVyZWQgdGFjdGljYWxseS4gTWF5YmUgdGhhdCBpcyB0aGUgYmVzdCBmb3Igbm93LCBidXQgcGVy aGFwcyB0aGVyZSBzaG91bGQgYmUgY29uc2lkZXJhdGlvbiBvZiBhIHN0cmF0ZWdpYyBhcHByb2Fj aCB0byB0aGlzIGFzIHdlbGwuDQo+DQo+V2hhdCBJIG1lYW4gaXMgdGhhdCB0aGlzIHNlZW1zIHRv IGJlIGEgYmFjayBoYW5kZWQgd2F5IHRvIGludHJvZHVjZSBtdWx0aXBhdGggc3VwcG9ydCBpbnRv IHByb3RvY29scyAoc3BlY2lmaWNhbGx5IERUTFMpIHRoYXQgZG9uJ3Qgc3VwcG9ydCBpdC4gUGVy aGFwcyBtdWx0aXBhdGggb3VnaHQgdG8gYmUgb2ZmaWNpYWxseSBhZGRlZCB0byBhbGwgdGhlIHBy b3RvY29scyB0aGF0IHBvdGVudGlhbGx5IG5lZWQgSUNFLCBhbmQgdGhlbiBJQ0Ugd291bGQgc2lt cGx5IGJlIG9uZSB3YXkgdG8gcG9wdWxhdGUgPnRoZSBwYXRocy4NCj4NCj4gVGhpcyB3aWxsIHN0 aWxsIGxlYXZlIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8gZGV0ZXJtaW5lIHdoZW4gdGhlIG11bHRp cGF0aCBwcm90b2NvbCBydW5uaW5nIG92ZXIgSUNFIGNvbW11bmljYXRlcyB3aXRoIHRoZSBuZXcg ZW5kIHBvaW50IChpLmUuIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgcmUtZXN0YWJsaXNoZWQpIG9y IHdoZW4gdGhpcyBpcyBhIHBhdGggdXBkYXRlIGFuZCB0aGUgY29ubmVjdGlvbiBuZWVkcyB0byBi ZSBwcmVzZXJ2ZWQuIEZvciBJQ0UgdGhlcmUgaXMgbm8gZWFzeSB3YXkgdG8gZGV0ZXJtaW5lIGlm IHdoYXQgPmN1cnJlbnRseSBpcyBoYXBwZW5pbmcgaXMgSUNFLXJlc3RhcnQgb24gdGhlIGV4aXN0 aW5nIGNvbm5lY3Rpb24gd2hpY2ggc2hvdWxkIGFsbG93IGV4aXN0aW5nIG11dGxpcGF0aCBwcm90 b2NvbCBzZXNzaW9uIHRvIGNvbnRpbnVlIHZzIHNldHRpbmcgdXAgSUNFIHRvIGEgbmV3IGVuZCBw b2ludCB3aGljaCB3b3VsZCByZXF1aXJlIG5ldyBjb25uZWN0aW9uIHNldHVwLiBUaGlzIHByb2Js ZW0gY3VycmVudGx5IGFmZmVjdHMgRFRMUywgYnV0IEkgYXNzdW1lIHRoaXMgd2lsbCBhcHBseSBh bHNvIHRvIG90aGVyIG11bHRpcGF0aCA+cHJvdG9jb2xzIHdoaWNoIHJlcXVpcmUgZXh0ZXJuYWxs eSBpbml0aWF0ZWQgY29ubmVjdGlvbiBoYW5kc2hha2Ugd2hlbiBydW5uaW5nIG92ZXIgSUNFLiBU aGlzIGNhbiBiZSBhZGRyZXNzZWQgb24gdGhlIHByb3RvY29sIHNpZGUgKGNvbm5lY3Rpb24gbmV3 IGF0dHJpYnV0ZSB3aGljaCB3aWxsIGFwcGx5IHRvIERUTFMpIG9yIG9uIElDRSBzaWRlIChzb21l IHNvcnQgb2YgaW5kaWNhdGlvbiBpZiB0aGlzIGlzIGEgbmV3IGVuZC1wb2ludCBvciByZS1zdGFy dCkuIFByb3RvY29sIHNpZGUgY2hhbmdlIHNlZW1lZCB0byBiZSB0aGUgbGVzcyA+ZGlzcnVwdGl2 ZSBhbmQgbW9yZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBvcHRpb24gaW4gY2FzZSBvZiBEVExTLsKg DQo+DQo+VGhlIHJlYXNvbiBEVExTIGlzIHJ1bm5pbmcgaW50byBwcm9ibGVtcyB3aXRoIElDRSwg aXMgZHVlIHRvIHRoZSBmYWN0IHRoYXQgaXQgd2FzIG5vdCBkZXNpZ24gdG8gcnVuIG11bHRpcGxl IHNlc3Npb25zIG92ZXIgdGhlIHNhbWUgY29ubmVjdGlvbiBhbmQgZG9lcyBub3QgYWxsb3cgc2V0 dGluZyB1cCBhIG5ldyBzZXNzaW9uIHVuc29saWNpdGVkIHVzaW5nIHRyYW5zcG9ydCBtZXNzYWdl cyBvbmx5LCB3aGljaCBhcmUgcHJvcGVydGllcyBvZiBSVFAgZm9yIHdoaWNoIElDRSB3YXMgb3Jp Z2luYWxseSBkZXNpZ25lZC4gRXh0ZW5kaW5nID5EVExTIHNvIHRoYXQgaXQgaXMgcG9zc2libGUg dG8gbXVsdGlwbGV4IHNldmVyYWwgRFRMUyBzZXNzaW9ucyBvdmVyIHRoZSBzYW1lIGNvbm5lY3Rp b24sIGFuZCBpbml0aWF0ZSBuZXcgc2Vzc2lvbiBzZXR1cCB1c2luZyB0cmFuc3BvcnQgbGV2ZWwg bWVzc2FnZXMsIHdvdWxkIGJlIGEgYmV0dGVyIHN0cmF0ZWdpYyBzb2x1dGlvbi4gVW5mb3J0dW5h dGVseSB0aGlzIGlzIG5vdCBnb2luZyB0byBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBhbmQgd291 bGQgZnVydGhlciBjb21wbGljYXRlIGRlc2lnbiBhbmQgaW1wbGVtZW50YXRpb24uDQo+DQo+RnJv bSBteSBwZXJzb25hbCBwb2ludCBvZiB2aWV3LCBEVExTIGluIGNvbWJpbmF0aW9uIHdpdGggSUNF IGlzIGEgZGVzaWduIG1lc3MuIEl0IHdvdWxkIGJlIG11Y2ggY2xlYW5lciBhbmQgc3RyYXRlZ2lj IGlmIGluc3RlYWQgdHdvIHNlcGFyYXRlIHByb3RvY29scyB0aGlzIHdhcyBhIHNpbmdsZSBwcm90 b2NvbCB3aGljaCB3YXMgcmVzcG9uc2libGUgZm9ywqBhdXRoZW50aWNhdGlvbizCoGVuY3J5cHRp b24gbmVnb3RpYXRpb24sIGNvbm5lY3Rpb24gcGF0aCBkaXNjb3ZlcnksIHBhdGggdXBkYXRlcywg YW5kIGNvbW11bmljYXRpb24gPmNvbnNlbnQuIFRoZXNlIGFyZSBjbG9zZWx5IHJlbGF0ZWQgdGFz a3MgYW5kIGlkZWFsbHkgdGhleSBzaG91bGQgYmUgaGFuZGxlZCB0b2dldGhlciBpbnN0ZWFkIG9m IG9uZSBvbiB0b3Agb2YgdGhlIG90aGVyLg0KDQpTbywgd2hhdCBpcyB5b3VyIHN1Z2dlc3Rpb24/ IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KwqANCg== From nobody Wed Apr 15 06:32:30 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8821B34A7 for ; Wed, 15 Apr 2015 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4XQT8GvHN-j for ; Wed, 15 Apr 2015 06:32:23 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0261B34A4 for ; Wed, 15 Apr 2015 06:32:23 -0700 (PDT) Received: by oblw8 with SMTP id w8so20232323obl.0 for ; Wed, 15 Apr 2015 06:32:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pIB6o3QzJtBRkWvWq7vXU3/YCNXS+yNZhMh7Jkz5k60=; b=L9CWq/eepdPlq0CIKZoLBk4tKGTFWWE5kKctujdVk+0FLe77N64tZlgXhRnCyt7Nbn EgPcwz2pybhvRzKrbYgXZH+A3QqppU6lzqBs+ELuxuZe9Ay2PKG6DbRaYg5QLuG6JZ1y gAckgCzeHUofjuGs+Cx3Sp6mYUYeeW6Dx5DEZfhVBXFkcXG5yS96QQIcWQQBglTex1+J hX6Doav30f1I2b5LcOW1t3I7ZWvcogeeeLNvXl2Uw56I6x3ZJqm92lIZli9gzFRxX0YW 7vSWLapOIGyTaxnoCP+lWMZQ/i5GdbmP0nZSFdEXM0JJZglp9VdL12K27K+AlCq+mie8 GBwg== X-Gm-Message-State: ALoCoQmCmu51tP6jsUFM3LZUhl1fnpAJ2HCFu/6/t8PsNwxr3Wgp1p2B1OF7gyKp8Ypn1oMw6Xzw X-Received: by 10.182.24.5 with SMTP id q5mr20487399obf.8.1429104731613; Wed, 15 Apr 2015 06:32:11 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id u83sm2328862oif.25.2015.04.15.06.32.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 06:32:10 -0700 (PDT) Message-ID: <552E6858.2040000@jive.com> Date: Wed, 15 Apr 2015 09:32:08 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christer Holmberg , Roman Shpount , Paul Kyzivat References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 13:32:28 -0000 Le 2015-04-15 04:22, Christer Holmberg a écrit : >>From my personal point of view, DTLS in combination with ICE is a design mess. It would be much cleaner and strategic if instead two separate protocols this was a single protocol which was responsible for authentication, encryption negotiation, connection path discovery, path updates, and communication >consent. These are closely related tasks and ideally they should be handled together instead of one on top of the other. > > So, what is your suggestion? :) I feel Christer's pain. This has been discussed to death. We have reached the point where it's "text or STFU". I don't care about this anymore so I'll STFU. Simon From nobody Wed Apr 15 06:41:46 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275021B34E3 for ; Wed, 15 Apr 2015 06:41:45 -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 dCPASMekWBuN for ; Wed, 15 Apr 2015 06:41:42 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7C1A905E for ; Wed, 15 Apr 2015 06:41:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 417457C4B7C; Wed, 15 Apr 2015 15:41:41 +0200 (CEST) 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 GzpQByiaO_Yt; Wed, 15 Apr 2015 15:41:39 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7988:3ea7:901d:b22f]) by mork.alvestrand.no (Postfix) with ESMTPSA id D10C17C0336; Wed, 15 Apr 2015 15:41:39 +0200 (CEST) Message-ID: <552E6A92.4020801@alvestrand.no> Date: Wed, 15 Apr 2015 15:41:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Thomson , Magnus Westerlund References: <5517AAE4.5070800@alvestrand.no> <551A63D2.1030006@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remove msid-semantic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 13:41:45 -0000 On 03/31/2015 06:32 PM, Martin Thomson wrote: > On 31 March 2015 at 02:07, Magnus Westerlund > wrote: >> Just to be clear here and ensure that I haven't missed anything. RTP >> usage requires all WebRTC endpoint to provide synchronization >> information when sending. However, it is up to the receiver to decide if >> they want to synchronize the playout. Thus this LS group would only be >> there to indicate a strong preference by the sender that the receiver >> should/shall playout in synchronization? > > Correct, the information in RTP will make it possible to synchronize > tracks, but whether that is acted upon will ultimately depend on > whether the tracks are rendered in the same stream. I think that the > intent with the LS groups is to make this clear, not just to a WebRTC > receiver, but to legacy receivers as well. OK, here is how the section on handing unsignalled tracks looks when I've removed msid-semantic. Note that depending on exactly how we do early media, this may cause trouble in delivering it. 3.1. Handling of non-signalled tracks Entities that do not use msid will not send msid. This means that there will be some incoming RTP packets that the recipient has no predefined MediaStream id value for. Note that this handling is triggered by incoming RTP packets, not by SDP negotiation. When MSID is used, the only time this can happen is when, at a time subsequent to the initial negotiation, a negotiation is performed where the answerer adds a MediaStreamTrack to an already established connection and starts sending data before the answer is received by the offerer. For initial negotiation, packets won't flow until the ICE candidates and fingerprints have been exchanged, so this is not an issue. The recipient of those packets will perform the following steps: o When RTP packets are initially received, it will create an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType), and use the mid RTP attribute (if present) to associate the RTP packets with a specific media section. If the connection is not in the RTCSignalingState "stable", it will wait at this point. o When the connection is in the RTCSignalingState "stable", it will look at the relevant media section to find the msid attribute. o If there is an msid attribute, it will use that attribute to populate the "id" field of the MediaStreamTrack and associated MediaStreams, as described above. o If there is no msid attribute, the identifier of the MediaStreamTrack will be set to a randomly generated string, and it will be signalled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". o After deciding on the "id" field to be applied to the MediaStreamTrack, the track will be signalled to the user. The process above may involve a considerable amount of buffering before the stable state is entered, If the implementation wishes to limit this buffering, it MUST send a "mediadiscarded" event to the user, as described in [????]. From nobody Wed Apr 15 11:16:36 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A41A0143 for ; Wed, 15 Apr 2015 11:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saN0KzkbUybT for ; Wed, 15 Apr 2015 11:16:33 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243F71A0140 for ; Wed, 15 Apr 2015 11:16:33 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so29778700obb.2 for ; Wed, 15 Apr 2015 11:16:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uwRj4lpqlI93WxYwhmvymU1z3I10ZHq/9CeD35DtxwQ=; b=e5X43fpEujVF8SG1KpfFImPAjLSJWJUbrr/YTbCPIIHU5lzFo4PS4gnRWJjHMsVh2Y NGSnsrPfbrum8ciNmPnKVt7bKGlClslGUPTIbsT2oPcaOB/+VD7Ct9qHb8I76n/rxbJB J6OjvR7dqqpN1kWoCc97pJeG24ubund2KD/KrJ6uZLqv9wOctC/mp6WBbhvuRrRGPEmt idwOfncv0But9WYKEEHVX/fO2wYB3jTvxijVMNwrJ95Kf/tJaoj1P8rm6bMJvTDYi3Pr 3eLpooKLXjxxxTqDaHJr8MRmI9UV72TNvV+IVGrKU7bX/bLiSvrp1yFJoulpJyjo5Puf RPpw== X-Gm-Message-State: ALoCoQl3+kdMVoBjZyvHWIvekkp2pAoq9X+XcBhoB7qGP5RNbPwrGsMxvahTgxUeIF18jXpmTYIR X-Received: by 10.182.92.165 with SMTP id cn5mr22148367obb.10.1429121791011; Wed, 15 Apr 2015 11:16:31 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com. [209.85.214.172]) by mx.google.com with ESMTPSA id dy9sm2789355obb.6.2015.04.15.11.16.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 11:16:29 -0700 (PDT) Received: by oblw8 with SMTP id w8so31939777obl.0 for ; Wed, 15 Apr 2015 11:16:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.161.81 with SMTP id k78mr35215884ioe.41.1429121788624; Wed, 15 Apr 2015 11:16:28 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Wed, 15 Apr 2015 11:16:28 -0700 (PDT) In-Reply-To: <552E6858.2040000@jive.com> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> <552E6858.2040000@jive.com> Date: Wed, 15 Apr 2015 14:16:28 -0400 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=001a1140fa128d497e0513c758c7 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 18:16:35 -0000 --001a1140fa128d497e0513c758c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2015 at 9:32 AM, Simon Perreault wrote: > Le 2015-04-15 04:22, Christer Holmberg a =C3=A9crit : > >>From my personal point of view, DTLS in combination with ICE is a desig= n > mess. It would be much cleaner and strategic if instead two separate > protocols this was a single protocol which was responsible for > authentication, encryption negotiation, connection path discovery, path > updates, and communication >consent. These are closely related tasks and > ideally they should be handled together instead of one on top of the othe= r. > > > > So, what is your suggestion? :) > > I feel Christer's pain. This has been discussed to death. We have > reached the point where it's "text or STFU". I don't care about this > anymore so I'll STFU. > For the sake of history, Christer suggested using connection:new with DTLS in offer/answer. Paul asked if this is "strategic" enough. I sent the response that strategic solution would be to fix DTLS/ICE combo and make it a single multi-path secure protocol. If needed, I can try to write a draft for such protocol which combines DTLS and ICE functionality. This is not the hard part. The hard part is convincing others (primarily browser vendors) that they should adopt this. So, if anybody is interested in such new protocol, let me know. Otherwise I would shut up and wait for ICE/DTLS problems either get resolved or become so bad that the new protocol would be unavoidable. Regards, _____________ Roman Shpount --001a1140fa128d497e0513c758c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 15, 2015 at 9:32 AM, Simon Perreault <sperreault@jive.com&g= t; wrote:
Le 2015-04-15 04:22, = Christer Holmberg a =C3=A9crit :
>>From my personal point of view, DTLS in combination with ICE is a d= esign mess. It would be much cleaner and strategic if instead two separate = protocols this was a single protocol which was responsible for authenticati= on, encryption negotiation, connection path discovery, path updates, and co= mmunication >consent. These are closely related tasks and ideally they s= hould be handled together instead of one on top of the other.
>
> So, what is your suggestion? :)

I feel Christer's pain. This has been discussed to death. We hav= e
reached the point where it's "text or STFU". I don't care= about this
anymore so I'll STFU.

For the sake = of history, Christer suggested using connection:new with DTLS in offer/answ= er. Paul asked if this is "strategic" enough. I sent the response= that strategic solution would be to fix DTLS/ICE combo and make it a singl= e multi-path secure protocol. If needed, I can try to write a draft for suc= h protocol which combines DTLS and ICE functionality. This is not the hard = part. The hard part is convincing others (primarily browser vendors) that t= hey should adopt this. So, if anybody is interested in such new protocol, l= et me know. Otherwise I would shut up and wait for ICE/DTLS problems either= get resolved or become so bad that the new protocol would be unavoidable.<= br>

Regards,
_____________
Roman Shpount
=C2=A0
=
--001a1140fa128d497e0513c758c7-- From nobody Wed Apr 15 13:18:32 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321CB1A8728 for ; Wed, 15 Apr 2015 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XkqQfaF_i7h for ; Wed, 15 Apr 2015 13:18:30 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFAA1A8726 for ; Wed, 15 Apr 2015 13:18:30 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-06v.sys.comcast.net with comcast id GLJC1q0022Qkjl901LJVp7; Wed, 15 Apr 2015 20:18:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-15v.sys.comcast.net with comcast id GLJU1q00L3Ge9ey01LJU72; Wed, 15 Apr 2015 20:18:29 +0000 Message-ID: <552EC794.2010001@alum.mit.edu> Date: Wed, 15 Apr 2015 16:18:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Roman Shpount , Simon Perreault References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> <552E6858.2040000@jive.com> 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=1429129109; bh=lwTXp97sOYYYfU3P1XRYUKpTRLggPE5pSwsTULRpjjM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hnqWXKfGJSlGKS7y4wrUjlhhDb5cO6OdmM9sbhoePEutyQ51X7aH31r2oClkvsSVw UpxLfg70tu+FEtVnp5BajbpPr4XQno78wvqX7pPwwXWloUDCUxbBQIZ1wb/59txkAk BRiTKzV30waboistbh/z49wLlmBWz9iQKuyHhGVDj7qZjcwUXMy0E4SQoOy3Q576wB lMShodyqe0/cSeV905g4Uyvg+hqncIkwDppFywSY5teXkPnDmQHH/qxp+afIKl7wMf R+ir/e187covQ2CuarW6Qf5Xmw4Y/ivex3or+6DddQzOwnxajy0e3M2DB7SsOf03gk LDltNssLruMiQ== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 20:18:31 -0000 On 4/15/15 2:16 PM, Roman Shpount wrote: > On Wed, Apr 15, 2015 at 9:32 AM, Simon Perreault > wrote: > > Le 2015-04-15 04:22, Christer Holmberg a écrit : > >>From my personal point of view, DTLS in combination with ICE is a design mess. It would be much cleaner and strategic if instead two separate protocols this was a single protocol which was responsible for authentication, encryption negotiation, connection path discovery, path updates, and communication >consent. These are closely related tasks and ideally they should be handled together instead of one on top of the other. > > > > So, what is your suggestion? :) > > I feel Christer's pain. This has been discussed to death. We have > reached the point where it's "text or STFU". I don't care about this > anymore so I'll STFU. > > > For the sake of history, Christer suggested using connection:new with > DTLS in offer/answer. Paul asked if this is "strategic" enough. I sent > the response that strategic solution would be to fix DTLS/ICE combo and > make it a single multi-path secure protocol. If needed, I can try to > write a draft for such protocol which combines DTLS and ICE > functionality. This is not the hard part. The hard part is convincing > others (primarily browser vendors) that they should adopt this. So, if > anybody is interested in such new protocol, let me know. Otherwise I > would shut up and wait for ICE/DTLS problems either get resolved or > become so bad that the new protocol would be unavoidable. I didn't intend to propose that the tactical solution not be done. A strategic one will take longer than people want to wait. But I did mean to suggest that we ought to start looking at the strategic solution - that ICE ought to simply be one way to discover multiple paths for a multipath transport, rather than being used in lieu of defining multipath versions of those transports. Thanks, Paul Thanks, Paul From nobody Wed Apr 15 14:32:47 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08601A90AB for ; Wed, 15 Apr 2015 14:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb_6yIV7ZwhJ for ; Wed, 15 Apr 2015 14:32:44 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00EB1A90AA for ; Wed, 15 Apr 2015 14:32:43 -0700 (PDT) Received: by iejt8 with SMTP id t8so37945933iej.2 for ; Wed, 15 Apr 2015 14:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w4Tq3zL5iQhXxNH86jfZuFDrRxM2T6XyR1ELdF6qUZo=; b=EFITon0s6n9+Jq2LiZ3SMyp25XiQjblivY6VT+VuUSw9yP9xO/JLDKjAOWAnLIgRO4 4hnGO5TfHHobiWbfAH7cT/sl1QE5Z6qsyAtrWOHUXs2Ywy+3KvRoNZ8pc+WjAfKSus/O A4A1YKLt0LqzqfhgqjnCOvHQrL9CXAgHiabeT2DDHBrk9uZ972nO2OtrHhg6T9fdzFpc m7iNy9HHNVjan81tWzAC+bLiUHxHY6GZ3akWkxMfu771n63mC9yDYzyT1i5JMK828Y4a JbhewjKUYXEOuZ6vmNPaDEjMCltFCzfwAkVYEaPU4DjFcG95u7zBIGlf7aKvl0nFRZ2R JiaQ== X-Gm-Message-State: ALoCoQlz6ql6O4B1YlJ52DODyC23fnf8mL3muKYdeo8ROnFktvuGulxhAEHDEu1V+WkV38xMGZAT X-Received: by 10.107.157.135 with SMTP id g129mr38603432ioe.72.1429133563247; Wed, 15 Apr 2015 14:32:43 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by mx.google.com with ESMTPSA id a139sm1148519ioa.14.2015.04.15.14.32.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 14:32:42 -0700 (PDT) Received: by igblo3 with SMTP id lo3so36497520igb.0 for ; Wed, 15 Apr 2015 14:32:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.254.4 with SMTP id ae4mr1253159igd.10.1429133561163; Wed, 15 Apr 2015 14:32:41 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Wed, 15 Apr 2015 14:32:40 -0700 (PDT) In-Reply-To: <552EC794.2010001@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> <552E6858.2040000@jive.com> <552EC794.2010001@alum.mit.edu> Date: Wed, 15 Apr 2015 17:32:40 -0400 Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11343b923ff7920513ca16b9 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 21:32:45 -0000 --001a11343b923ff7920513ca16b9 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 15, 2015 at 4:18 PM, Paul Kyzivat wrote: > > I didn't intend to propose that the tactical solution not be done. > A strategic one will take longer than people want to wait. > Agreed. > > But I did mean to suggest that we ought to start looking at the strategic > solution - that ICE ought to simply be one way to discover multiple paths > for a multipath transport, rather than being used in lieu of defining > multipath versions of those transports. > As far as strategic directions are concerned, ICE has no reason to exist on its own. It would always needs to be paired with security and this implies DTLS. DTLS on the other hand, can benefit greatly from ICE functionality so that it can traverse NAT environments and recover from path failures. If ICE and DTLS handshakes are unified, then connection setup can be accelerated. Finally, ICE and DTLS implement a lot of common functionality in different ways, so there two implementation of mutual party authentication, keep-alive, role determination, structured data encapsulation and parsing. Having a single implementation of all of those would make protocol more reliable and secure. What I am trying to say is that I do not see future versions of ICE running without DTLS, so strategically it would be better to extend DTLS to include ICE functionality and end up with a single consistent secure protocol. One more thing: DTLS would also need to be extended to work well with offer/answer and bundle. This would means some sort of ID field, similar to RTP SSRC in all DTLS packets to allow to multiplex multiple DTLS sessions over the same transport channel both during setup and normal operations. _____________ Roman Shpount --001a11343b923ff7920513ca16b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2015 at 4:18 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

I didn't intend to propose that the tactical solution not be done.
A strategic one will take longer than people want to wait.
=

Agreed.
=C2=A0

But I did mean to suggest that we ought to start looking at the strategic s= olution - that ICE ought to simply be one way to discover multiple paths fo= r a multipath transport, rather than being used in lieu of defining multipa= th versions of those transports.

As far= as strategic directions are concerned, ICE has no reason to exist on its o= wn. It would always needs to be paired with security and this implies DTLS.= DTLS on the other hand, can benefit greatly from ICE functionality so that= it can traverse NAT environments and recover from path failures. If ICE an= d DTLS handshakes are unified, then connection setup can be accelerated. Fi= nally, ICE and DTLS implement a lot of common functionality in different wa= ys, so there two implementation of mutual party authentication, keep-alive,= role determination, structured data encapsulation and parsing. Having a si= ngle implementation of all of those would make protocol more reliable and s= ecure.

What I am trying to say is that I do not se= e future versions of ICE running without DTLS, so strategically it would be= better to extend DTLS to include ICE functionality and end up with a singl= e consistent secure protocol.

One more thing: DTLS= would also need to be extended to work well with offer/answer and bundle. = This would means some sort of ID field, similar to RTP SSRC in all DTLS pac= kets to allow to multiplex multiple DTLS sessions over the same transport c= hannel both during setup and normal operations.
_____________
Roman Shpount
<= br>
--001a11343b923ff7920513ca16b9-- From nobody Thu Apr 16 05:57:37 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA69A1A88D0 for ; Thu, 16 Apr 2015 05:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxYPjq7djUpb for ; Thu, 16 Apr 2015 05:57:34 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC681A889D for ; Thu, 16 Apr 2015 05:57:33 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-bc-552fb1bbebe0 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 34.33.28347.BB1BF255; Thu, 16 Apr 2015 14:57:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 14:57:31 +0200 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] SCTP-SDP: Virtual Connection impact Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4agBp9w8AAAlD9G3//+elAP/+UhxQgANE4ID//sK9UIACrDAA//+bfnAAGN4gAP//LFCA//2gvgD/+fe8oP/z6QIA/+ef7Tj/yWkAUP+Q/ySA/yHheoD+OU9z8PxyaVYA+OSDOgDxyOReAOORtAEAxyJFcDA= Date: Thu, 16 Apr 2015 12:57:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D79CFF3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> <552E6858.2040000@jive.com> <552EC794.2010001@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM+Jvje7ujfqhBnNPaVhMXf6YxWLFhgOs FjMuTGW2uH4l1IHF4+/7D0weS5b8ZPL4N+cps8etKQUBLFFcNimpOZllqUX6dglcGac+PGAt 6BKp2PDuGWMD4wnhLkZODgkBE4mXK9pZIGwxiQv31rN1MXJxCAkcZZSY3n6QCcJZwihx/M9X 5i5GDg42AQuJ7n/aIA0iAt4SfX0d7CA2s4CfxN2528BsYQFLiW8bpjBB1FhJ9E5YwgwyR0Tg GKPE2pNrmEESLAKqEocef2IFsXkFfCWeb3jHCLHsOofEzu+PwU7iFAiU+D6nnQ3EZgQ67/up NUwQ28Qlbj2ZzwRxtoDEkj3nmSFsUYmXj/+xghwqIaAosbxfDsRkFtCUWL9LH6JTUWJK90N2 iLWCEidnPmGZwCg2C8nQWQgds5B0zELSsYCRZRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZG YIQd3PLbYAfjy+eOhxgFOBiVeHgVOvRDhVgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAKH6jUMyH0f1BmgJj/NWu9iPcd7c4RB9rYZ+ktXPGT22frYvlOrcV LODk+P7c5OGk/xf0ORmSs3vNfvlKVRm0r+R/s0Jphmvsve7EcNvcUxUfFKYeDlX9xRF2syH9 3OXeD+8VxPc3B11dzqj7VL3hg3OFpp1xgcNG8dYwy3BPo4/zLvwWC7FXYinOSDTUYi4qTgQA 6ggW+ZECAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 12:57:36 -0000 SGksDQrCoA0KPkJ1dCBJIGRpZCBtZWFuIHRvIHN1Z2dlc3QgdGhhdCB3ZSBvdWdodCB0byBzdGFy dCBsb29raW5nIGF0IHRoZSBzdHJhdGVnaWMgc29sdXRpb24gLSB0aGF0IElDRSBvdWdodCB0byBz aW1wbHkgYmUgb25lIHdheSB0byBkaXNjb3ZlciBtdWx0aXBsZSBwYXRocyBmb3IgYSBtdWx0aXBh dGggdHJhbnNwb3J0LCByYXRoZXIgdGhhbiBiZWluZyB1c2VkIGluIGxpZXUgb2YgZGVmaW5pbmcg bXVsdGlwYXRoIHZlcnNpb25zIG9mIHRob3NlIHRyYW5zcG9ydHMuDQo+DQo+QXMgZmFyIGFzIHN0 cmF0ZWdpYyBkaXJlY3Rpb25zIGFyZSBjb25jZXJuZWQsIElDRSBoYXMgbm8gcmVhc29uIHRvIGV4 aXN0IG9uIGl0cyBvd24uIEl0IHdvdWxkIGFsd2F5cyBuZWVkcyB0byBiZSBwYWlyZWQgd2l0aCBz ZWN1cml0eSBhbmQgdGhpcyBpbXBsaWVzIERUTFMuIERUTFMgb24gdGhlIG90aGVyIGhhbmQsIGNh biBiZW5lZml0IGdyZWF0bHkgZnJvbSBJQ0UgZnVuY3Rpb25hbGl0eSBzbyB0aGF0IGl0IGNhbiB0 cmF2ZXJzZSBOQVQgZW52aXJvbm1lbnRzIGFuZCByZWNvdmVyIGZyb20gcGF0aCBmYWlsdXJlcy4g SWYgSUNFIGFuZCBEVExTID5oYW5kc2hha2VzIGFyZSB1bmlmaWVkLCB0aGVuIGNvbm5lY3Rpb24g c2V0dXAgY2FuIGJlIGFjY2VsZXJhdGVkLiBGaW5hbGx5LCBJQ0UgYW5kIERUTFMgaW1wbGVtZW50 IGEgbG90IG9mIGNvbW1vbiBmdW5jdGlvbmFsaXR5IGluIGRpZmZlcmVudCB3YXlzLCBzbyB0aGVy ZSB0d28gaW1wbGVtZW50YXRpb24gb2YgbXV0dWFsIHBhcnR5IGF1dGhlbnRpY2F0aW9uLCBrZWVw LWFsaXZlLCByb2xlIGRldGVybWluYXRpb24sIHN0cnVjdHVyZWQgZGF0YSBlbmNhcHN1bGF0aW9u IGFuZCBwYXJzaW5nLiBIYXZpbmcgYSBzaW5nbGUgPmltcGxlbWVudGF0aW9uIG9mIGFsbCBvZiB0 aG9zZSB3b3VsZCBtYWtlIHByb3RvY29sIG1vcmUgcmVsaWFibGUgYW5kIHNlY3VyZS4NCj4NCj5X aGF0IEkgYW0gdHJ5aW5nIHRvIHNheSBpcyB0aGF0IEkgZG8gbm90IHNlZSBmdXR1cmUgdmVyc2lv bnMgb2YgSUNFIHJ1bm5pbmcgd2l0aG91dCBEVExTLCBzbyBzdHJhdGVnaWNhbGx5IGl0IHdvdWxk IGJlIGJldHRlciB0byBleHRlbmQgRFRMUyB0byBpbmNsdWRlIElDRSBmdW5jdGlvbmFsaXR5IGFu ZCBlbmQgdXAgd2l0aCBhIHNpbmdsZSBjb25zaXN0ZW50IHNlY3VyZSBwcm90b2NvbC4NCg0KRFRM UyAxLjQgOikNCg0KRm9yIG5vdywgbXkgc3VnZ2VzdGlvbiBpcyBzdGlsbCB0byB1c2UgdGhlIFNE UCBjb25uZWN0aW9uOm5ldyBhdHRyaWJ1dGUuIEl0J3MgYSByZWxhdGl2ZWx5IHNpbXBsZSB0aGlu ZyB0byBkbywgYW5kIGl0IGRvZXMgbm90IHJlcXVpcmUgYmlnIHJlLXdvcmsgb2YgdGhlIERUTFMg YW5kIElDRS4gDQoNClVubGVzcyBJJ3ZlIG1pc3NlZCBpdCwgSSBoYXZlIG5vdCBzZWVuIGFueSBp bnB1dCB3aHkgaXQgd291bGQgbm90IHdvcmsuDQoNCj5PbmUgbW9yZSB0aGluZzogRFRMUyB3b3Vs ZCBhbHNvIG5lZWQgdG8gYmUgZXh0ZW5kZWQgdG8gd29yayB3ZWxsIHdpdGggb2ZmZXIvYW5zd2Vy IGFuZCBidW5kbGUuIFRoaXMgd291bGQgbWVhbnMgc29tZSBzb3J0IG9mIElEIGZpZWxkLCBzaW1p bGFyIHRvIFJUUCBTU1JDIGluIGFsbCBEVExTIHBhY2tldHMgdG8gYWxsb3cgdG8gbXVsdGlwbGV4 IG11bHRpcGxlIERUTFMgc2Vzc2lvbnMgb3ZlciB0aGUgc2FtZSB0cmFuc3BvcnQgY2hhbm5lbCBi b3RoIGR1cmluZyBzZXR1cCBhbmQgbm9ybWFsIG9wZXJhdGlvbnMuDQoNCk5vdCBzdXJlIEkgdW5k ZXJzdGFuZC4gQlVORExFIHVzZXMgYSBzaW5nbGUgRFRMUyBzZXNzaW9uIGZvciBhbGwgbWVkaWEg YXNzb2NpYXRlZCB3aXRoIGEgNS10dXBsZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Thu Apr 16 10:34:20 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AEB1B2E08 for ; Thu, 16 Apr 2015 10:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ3ssRjhMzYN for ; Thu, 16 Apr 2015 10:34:17 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDA81B334A for ; Thu, 16 Apr 2015 10:34:17 -0700 (PDT) Received: by igblo3 with SMTP id lo3so119462687igb.1 for ; Thu, 16 Apr 2015 10:34:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tQDoyEXXY2bQYbsOf484ZJTBxJ50QSbFGx7ofypFmEw=; b=mMQ9uYt0zTx64JWZkH7RaAyi7y5ZCKVE+kBIDlbbonw/tXHKz0UHiEvvptfYnv3w4h mh3kcqkXcHVMIa0Cp3iEdV3JDLlTq7x6Tj48bacTmoUDbauqw9I0f1MVHe65Y7ArWGzm 7bPhzPdAcTK6z1dXUFze1LvdI8EzX+GvPN53v7UPxiv+jl2j/qp5pe8TUCU5YGDAsODh ap228jDVKdGn6rJcIGSIibictjL4xB8wdNUMlJVBhvJbqh2Qdit5Y0gyDU/w7mTDziQe d8TpSxC/5SuSfr8Ba9vgUMDrk7CbMtR7iu0ZwTMiA5l3n4JEVacsOqoCG/970SsjJBqU d7SQ== X-Gm-Message-State: ALoCoQl3wV/CNTQL7wy0TS/hSUXH4rtzRUXUu7LzbaiCMojC6Fj4icN0kAA/SZzhL1SE9eABSO7J X-Received: by 10.50.36.104 with SMTP id p8mr7267721igj.16.1429205653071; Thu, 16 Apr 2015 10:34:13 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com. [209.85.223.177]) by mx.google.com with ESMTPSA id o80sm4781120ioi.3.2015.04.16.10.34.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2015 10:34:11 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so64262758ied.1 for ; Thu, 16 Apr 2015 10:34:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.161.81 with SMTP id k78mr42523942ioe.41.1429205650635; Thu, 16 Apr 2015 10:34:10 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Thu, 16 Apr 2015 10:34:10 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D79CFF3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D787E27@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D788924@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> <552E6858.2040000@jive.com> <552EC794.2010001@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79CFF3@ESESSMB209.ericsson.se> Date: Thu, 16 Apr 2015 13:34:10 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140fa121e0f7e0513dadfa8 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 17:34:19 -0000 --001a1140fa121e0f7e0513dadfa8 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 16, 2015 at 8:57 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >What I am trying to say is that I do not see future versions of ICE > running without DTLS, so strategically it would be better to extend DTLS to > include ICE functionality and end up with a single consistent secure > protocol. > > DTLS 1.4 :) > Or DTLS 2.0. In any case not now, but may be in the future. > For now, my suggestion is still to use the SDP connection:new attribute. > It's a relatively simple thing to do, and it does not require big re-work > of the DTLS and ICE. > > Unless I've missed it, I have not seen any input why it would not work. > I agree. I cannot see any reason why "connection:new" should not work for now. Furthermore, at least for me, it would solve some real implementation problems. > >One more thing: DTLS would also need to be extended to work well with > offer/answer and bundle. This would means some sort of ID field, similar to > RTP SSRC in all DTLS packets to allow to multiplex multiple DTLS sessions > over the same transport channel both during setup and normal operations. > > Not sure I understand. BUNDLE uses a single DTLS session for all media > associated with a 5-tuple. > BUNDLE was designed around the DTLS limitations so it is using a single DTLS session. This means, for instance, that you cannot BUNDLE data channel and BFCP. This is fine for now, but not ideal from long-term, "strategic", point of view. _____________ Roman Shpount --001a1140fa121e0f7e0513dadfa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 16, 2015 at 8:57 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>What I am trying to say is that I do not see future ve= rsions of ICE running without DTLS, so strategically it would be better to = extend DTLS to include ICE functionality and end up with a single consisten= t secure protocol.

DTLS 1.4 :)

Or DTLS 2.0. In any = case not now, but may be in the future.
=C2=A0
For now, my suggestion is still to use the SDP connection:new attribute= . It's a relatively simple thing to do, and it does not require big re-= work of the DTLS and ICE.

Unless I've missed it, I have not seen any input why it would not work.=

I agree. I cannot see any reason why &= quot;connection:new" should not work for now. Furthermore, at least fo= r me, it would solve some real implementation problems.
=C2=A0
>One more thing: DTLS would also need to be ex= tended to work well with offer/answer and bundle. This would means some sor= t of ID field, similar to RTP SSRC in all DTLS packets to allow to multiple= x multiple DTLS sessions over the same transport channel both during setup = and normal operations.

Not sure I understand. BUNDLE uses a single DTLS session for all med= ia associated with a 5-tuple.

BUNDLE wa= s designed around the DTLS limitations so it is using a single DTLS session= . This means, for instance, that you cannot BUNDLE data channel and=C2=A0BFCP. This is f= ine for now, but not ideal from long-term, "strategic", point of = view.=C2=A0
_____________
Roman Shpount=

--001a1140fa121e0f7e0513dadfa8-- From nobody Thu Apr 16 11:13:57 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1061B2EF5 for ; Thu, 16 Apr 2015 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FXLAejLNEwQ9 for ; Thu, 16 Apr 2015 11:13:55 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id E15401B2EF4 for ; Thu, 16 Apr 2015 11:13:54 -0700 (PDT) X-AuditID: 12074413-f79f26d0000030e7-ba-552ffbe2d0a2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id F5.30.12519.2EBFF255; Thu, 16 Apr 2015 14:13:54 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t3GIDo9A006609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2015 14:13:52 -0400 Message-ID: <552FFBDD.7030204@alum.mit.edu> Date: Thu, 16 Apr 2015 14:13:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78931C@ESESSMB209.ericsson.se> <551DAD38.5000605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D78A1DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78A6B6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D78D4F3@ESESSMB209.ericsson.se> <55255EDF.3030903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79A05D@ESESSMB209.ericsson.se> <552E6858.2040000@jive.com> <552EC794.2010001@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79CFF3@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixO6iqPvot36owZ9+LosLMw8zWkxd/pjF YsaFqcwW16+EOrB4/Pp6lc1jyZKfTB7/5jxl9rg1pSCAJYrbJimxpCw4Mz1P3y6BO2Pmsgns BS+ZKj4evcnWwDiTqYuRk0NCwERiw9KZLBC2mMSFe+vZuhi5OIQELjNKzN2yCcp5ziSx5X8T M0gVr4C2xKEnx8A6WARUJZ7fOAUWZxPQkphz6D9YXFQgWaLl1S0WiHpBiZMzn4DZIgJJEiev rAOrZxbwk7g7dxt7FyMHh7CApcS0c9kQu9axS9xrnghWwykQKPF3yQMWiHoziXmbH0L1ykts fzuHeQKjwCwkK2YhKZuFpGwBI/MqRrnEnNJc3dzEzJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJN jJCAFt7BuOuk3CFGAQ5GJR5ejwT9UCHWxLLiytxDjJIcTEqivJ82AIX4kvJTKjMSizPii0pz UosPMUpwMCuJ8Dp8BcrxpiRWVqUW5cOkpDlYlMR51Zao+wkJpCeWpGanphakFsFkZTg4lCR4 c34BNQoWpaanVqRl5pQgpJk4OEGGc0mJFKfmpaQWJZaWZMSDYjW+GBitICkeoL28v0H2Fhck 5gJFIVpPMepy3JnyfxGTEEtefl6qlDivFEiRAEhRRmke3ApY+nrFKA70sTDvVJBLeICpD27S K6AlTEBLjgfqgiwpSURISTUwKi1y2Mq0VPcG+/m6GTN4NVisnhtWqOz7FamyRGaiphvv/r8z bnUVT7l6TXSubOllX5FPli6LL0/6nT7rXXLa1V3Wwbv3Od40kiv9f0Pf+cD0PZ8aPuY/dthR rJv9ZU7Asm0vr0r3dB9hVdld9XdT5Zq87Wc6/m/0rHscyNnwjf/6F6WVNkrzfimxFGckGmox FxUnAgByxsRPOgMAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:13:56 -0000 On 4/16/15 1:34 PM, Roman Shpount wrote: > BUNDLE was designed around the DTLS limitations so it is using a single > DTLS session. This means, for instance, that you cannot BUNDLE data > channel and BFCP. This is fine for now, but not ideal from long-term, > "strategic", point of view. But you could with bfcp over data channel. Thanks, Paul From nobody Fri Apr 17 02:58:54 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7041AD277 for ; Fri, 17 Apr 2015 02:58:52 -0700 (PDT) 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 xdbZLPrdhDjL for ; Fri, 17 Apr 2015 02:58:50 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533971AD272 for ; Fri, 17 Apr 2015 02:58:50 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-c4-5530d9581f61 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 83.66.01716.859D0355; Fri, 17 Apr 2015 11:58:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Fri, 17 Apr 2015 11:58:48 +0200 From: Christer Holmberg To: Adam Roach , Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments Thread-Index: AdB48sRiP9lfe1IKQ6C6VGl4ysyW2A== Date: Fri, 17 Apr 2015 09:58:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D79F956@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW7ETYNQg8bXahZ7/i5it/jUvYHN 4v0FXYt/e5Mspi5/zOLA6jHl90ZWjyVLfjJ5zNr5hMXjy+XPbAEsUVw2Kak5mWWpRfp2CVwZ aya1shfMEav48DmqgfGrYBcjJ4eEgIlE19w1TBC2mMSFe+vZuhi5OIQEjjJKzJi/mAnCWcIo 8er/JyCHg4NNwEKi+582SIOIQJrEnfMbWEBqmAV2MUq827aSFSQhLJAhcXP7W0aIokyJy0/m MEHYehIz17xgB7FZBFQlembfA6vhFfCV2NJ4jw3EZgS64vspiIuYBcQlbj2ZD3WdgMSSPeeZ IWxRiZeP/7FC2IoSV6cvh6rXkViw+xMbhK0tsWzha2aI+YISJ2c+YZnAKDILydhZSFpmIWmZ haRlASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzA6Dm45bfuDsbVrx0PMQpwMCrx8Cpk GoQKsSaWFVfmHmKU5mBREue1Mz4UIiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGRw4eX7y6r 3uFVlateVAc+9TycVzxtptU7ufMPjsQEhH3ZV/UtuOhmVmf5qS/aXclBlyOz/Msq2JmMCkKn i1lpabJtjp4RlnJ2pXmSlNuVJfseKO3bclxOXMpA/ki61aN1W6cd9T33VNkptGelZJPQu8a6 L6caXf2Nd+zfqyx7ec8HWVtVszglluKMREMt5qLiRACk6O8FfwIAAA== Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 09:58:52 -0000 Hi Adam, Most of your editorial comments seem ok. I'll comment them later. However, at least a couple (please let me know if you think there are more = non-editorial ones) of your comments was technical, and I'll focus on those= in this reply. --------------------------------------------------------------------------- > The procedure described in Section 8.3.2 has a rather unfortunate propert= y that I'm not sure we want. If I were to offer something like: > > a=3Dgroup:BUNDLE foo bar > m=3Dvideo 20002 RTP/AVP 97 > a=3Drtpmap:97 H261/90000 > a=3Dmid:foo > m=3Dvideo 0 RTP/AVP 97 98 > a=3Drtpmap:97 H261/90000 > a=3Drtpmap:98 VP8/90000 > a=3Dbundle-only > a=3Dmid:bar > > And the remote endpoint wanted to reject the first stream, it would be fo= rced to also reject the second. The historical intention of using "bundle-o= nly" was as a mechanism=20 > for UDP port preservation on the offerer's side. This procedure unintenti= onally turns it into a semantic binding among streams in bundle. > > I think we could restore the original purpose of the bundle-only handling= if we used the port from the rejected 'm=3D' line containing the BUNDLE-ta= g for any 'bundle-only' lines. So, I guess that means we would *always* use the BUNDLE-tag m- line port - = even if the m- line is rejected, AND even if there are other non-bundle-onl= y m- lines that are NOT rejected. Example: a=3Dgroup:BUNDLE foo bar zoo m=3Dvideo 20002 RTP/AVP 97 a=3Drtpmap:97 H261/90000 a=3Dmid:foo m=3Dvideo 40002 RTP/AVP 97 a=3Drtpmap:99 H264/99999 a=3Dmid:zoo m=3Dvideo 0 RTP/AVP 97 98 a=3Drtpmap:97 H261/90000 a=3Drtpmap:98 VP8/90000 a=3Dbundle-only a=3Dmid:bar Now, if the UAS rejects the "foo" m- line, it would still select port 20002= for the offerer. The UAS would NOT select port 40002, even if it accepts t= he "zoo" m- line. -------------------------------------------------------------------------- > The optionality in section 8.5.2 seems unnecessarily complex, and it's di= fficult to see what it gains us. Why don't we simply specify that each pre-= existing m=3D line MUST have a single shared address? > >To be clear: if we keep this behavior, then I think we want the answer to = that question in the document. Personally, I would be happy to always mandating a shared address. I think the main reason for not mandating a shared address is if a new m- l= ine is added to the BUNDLE group. If you assign the shared address to the n= ew m- line, and the UAS does not accept it into the BUNDLE group, it has to= reject it. Of course, we COULD say that one cannot add a new m- line, and suggest a ne= w BUNDLE address, within the same offer... -------------------------------------------------------------------------- Thanks! Regards, Christer From nobody Fri Apr 17 06:52:24 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD031B2D01 for ; Fri, 17 Apr 2015 06:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFaHooAKaDms for ; Fri, 17 Apr 2015 06:52:21 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275E61B2D00 for ; Fri, 17 Apr 2015 06:52:20 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-12v.sys.comcast.net with comcast id H1rN1q0052AWL2D011sLt2; Fri, 17 Apr 2015 13:52:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id H1sK1q00K3Ge9ey011sKqK; Fri, 17 Apr 2015 13:52:20 +0000 Message-ID: <55311011.9090908@alum.mit.edu> Date: Fri, 17 Apr 2015 09:52:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D79F956@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D79F956@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429278740; bh=frZhUv1PsP4NpFaYWi+9fFqUgC1+bPAguRKfZiWxbGI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=v4SIb4i1bAwiL+LaNiL03JBN865xjFcgqJfQPLz/G3LM3i+KFOa1c500ep9BuSf67 aMZW5IOjwhuM5NzBZlkehuOAXCwzisX2mM3dFcpm1/s1QkaZKgi0+zeT4UU711msV2 Xe1ifQgSQCEK5BYOyyNLoD8Zir+jCQ4PhqgXcZEBoVk/TEXqx8Luw3nGqzLNHONlUq 5NUo0fesg1QRkg+ZtIg61Y0Yp038Wf2Ie3/m8kwsLNeiYG+rcy4pBC5+MbqTEBHoSS C6CLRQnTaf1VK2iRbPYEjEyCTCldbmusxKlzldx9EsUMhT1hT3+haAFGiV9Sn+E9fB 0V8fME4lvo3Qg== Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 13:52:22 -0000 Comment at end. On 4/17/15 5:58 AM, Christer Holmberg wrote: > Hi Adam, > > Most of your editorial comments seem ok. I'll comment them later. > > However, at least a couple (please let me know if you think there are more non-editorial ones) of your comments was technical, and I'll focus on those in this reply. > > --------------------------------------------------------------------------- > >> The procedure described in Section 8.3.2 has a rather unfortunate property that I'm not sure we want. If I were to offer something like: >> >> a=group:BUNDLE foo bar >> m=video 20002 RTP/AVP 97 >> a=rtpmap:97 H261/90000 >> a=mid:foo >> m=video 0 RTP/AVP 97 98 >> a=rtpmap:97 H261/90000 >> a=rtpmap:98 VP8/90000 >> a=bundle-only >> a=mid:bar >> >> And the remote endpoint wanted to reject the first stream, it would be forced to also reject the second. The historical intention of using "bundle-only" was as a mechanism >> for UDP port preservation on the offerer's side. This procedure unintentionally turns it into a semantic binding among streams in bundle. >> >> I think we could restore the original purpose of the bundle-only handling if we used the port from the rejected 'm=' line containing the BUNDLE-tag for any 'bundle-only' lines. > > So, I guess that means we would *always* use the BUNDLE-tag m- line port - even if the m- line is rejected, AND even if there are other non-bundle-only m- lines that are NOT rejected. > > Example: > > a=group:BUNDLE foo bar zoo > m=video 20002 RTP/AVP 97 > a=rtpmap:97 H261/90000 > a=mid:foo > m=video 40002 RTP/AVP 97 > a=rtpmap:99 H264/99999 > a=mid:zoo > m=video 0 RTP/AVP 97 98 > a=rtpmap:97 H261/90000 > a=rtpmap:98 VP8/90000 > a=bundle-only > a=mid:bar > > Now, if the UAS rejects the "foo" m- line, it would still select port 20002 for the offerer. The UAS would NOT select port 40002, even if it accepts the "zoo" m- line. There are more implications. If you are going to do this for the port, then you need to do it for the address (c=) too. While most likely you would see the same address used for each, it is possible that when getting a unique address/port pairs that you can't (or at least don't) get the same address for each. We don't require them to be the same. Thanks, Paul From nobody Fri Apr 17 08:07:26 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB7C1B2DF5 for ; Fri, 17 Apr 2015 08:07:25 -0700 (PDT) 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 c_rzG-ORgojY for ; Fri, 17 Apr 2015 08:07:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F091B2DF2 for ; Fri, 17 Apr 2015 08:07:22 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-62-553121a8d147 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.E4.19337.8A121355; Fri, 17 Apr 2015 17:07:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Fri, 17 Apr 2015 17:07:19 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments Thread-Index: AdB48sRiP9lfe1IKQ6C6VGl4ysyW2AAEi9eAAAbPvjE= Date: Fri, 17 Apr 2015 15:07:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D79FC5A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D79F956@ESESSMB209.ericsson.se>, <55311011.9090908@alum.mit.edu> In-Reply-To: <55311011.9090908@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_7594FB04B1934943A5C02806D1A2204B1D79FC5AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje4KRcNQgzs9khZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx+e8C5oLV9hUne8MbGPebdjFyckgImEhc /dzBBGGLSVy4t54NxBYSOMoocb2br4uRC8hewiix5EYLUBEHB5uAhUT3P22QGhEBX4lnj2+D 1QsLZEjc3P6WESKeKXH5yRwmCNtKYsPvG8wgNouAqsSeczvAbF6g3sNnTrNA7MqVmLXgClic U0BHYlPfejCbEeie76fWgM1hFhCXaPqykhXiTgGJJXvOM0PYohIvH/9jhajJl5j75AIjxHxB iZMzn7BMYBSehaR9FpKyWUjKIOIGEl/e34aytSWWLXzNDGHrS3S/P82ELL6AkX0Vo2hxanFS brqRsV5qUWZycXF+nl5easkmRmDsHNzyW3UH4+U3jocYBTgYlXh4FTINQoVYE8uKK3MPMUpz sCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwChyc5cKW6TUcQs7kxfPBJlrH5ss Zzr741F52IHYbsckJkXX/c5PtYyVHc6fF8lX76iNt0qf5L1jQnDCwRvL3b+F223dWK6QF+Ns E8ay6/uB1OXF233SLjm7VQQW7VsXeCqCb/3HmZEXZtxuWCRY7efzoaQsIlMn1aZJWPCEtOrG FZynM4wnKLEUZyQaajEXFScCAOzWVPp+AgAA Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 15:07:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D79FC5AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Paul, Correct, it would also apply to the address. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD17/=FD04/=FD2015 16:52 To: mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 = - Adam's technical comments Comment at end. On 4/17/15 5:58 AM, Christer Holmberg wrote: > Hi Adam, > > Most of your editorial comments seem ok. I'll comment them later. > > However, at least a couple (please let me know if you think there are mor= e non-editorial ones) of your comments was technical, and I'll focus on tho= se in this reply. > > -------------------------------------------------------------------------= -- > >> The procedure described in Section 8.3.2 has a rather unfortunate proper= ty that I'm not sure we want. If I were to offer something like: >> >> a=3Dgroup:BUNDLE foo bar >> m=3Dvideo 20002 RTP/AVP 97 >> a=3Drtpmap:97 H261/90000 >> a=3Dmid:foo >> m=3Dvideo 0 RTP/AVP 97 98 >> a=3Drtpmap:97 H261/90000 >> a=3Drtpmap:98 VP8/90000 >> a=3Dbundle-only >> a=3Dmid:bar >> >> And the remote endpoint wanted to reject the first stream, it would be f= orced to also reject the second. The historical intention of using "bundle-= only" was as a mechanism >> for UDP port preservation on the offerer's side. This procedure unintent= ionally turns it into a semantic binding among streams in bundle. >> >> I think we could restore the original purpose of the bundle-only handlin= g if we used the port from the rejected 'm=3D' line containing the BUNDLE-t= ag for any 'bundle-only' lines. > > So, I guess that means we would *always* use the BUNDLE-tag m- line port = - even if the m- line is rejected, AND even if there are other non-bundle-o= nly m- lines that are NOT rejected. > > Example: > > a=3Dgroup:BUNDLE foo bar zoo > m=3Dvideo 20002 RTP/AVP 97 > a=3Drtpmap:97 H261/90000 > a=3Dmid:foo > m=3Dvideo 40002 RTP/AVP 97 > a=3Drtpmap:99 H264/99999 > a=3Dmid:zoo > m=3Dvideo 0 RTP/AVP 97 98 > a=3Drtpmap:97 H261/90000 > a=3Drtpmap:98 VP8/90000 > a=3Dbundle-only > a=3Dmid:bar > > Now, if the UAS rejects the "foo" m- line, it would still select port 200= 02 for the offerer. The UAS would NOT select port 40002, even if it accepts= the "zoo" m- line. There are more implications. If you are going to do this for the port, then you need to do it for the address (c=3D) too. While most likely you would see the same address used for each, it is possible that when getting a unique address/port pairs that you can't (or at least don't) get the same address for each. We don't require them to be the same. Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D79FC5AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Correct, it would also apply to the address.

Regards,

Christer



Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD17= /=FD04/=FD2015 16:52
To: mmusic@ietf.org
Subject: Re: [= MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's techn= ical comments

Comment at end.

On 4/17/15 5:58 AM, Christer Holmberg wrote:
> Hi Adam,
>
> Most of your editorial comments seem ok. I'll comment them later.
>
> However, at least a couple (please let me know if you think there are = more non-editorial ones) of your comments was technical, and I'll focus on = those in this reply.
>
> ----------------------------------------------------------------------= -----
>
>> The procedure described in Section 8.3.2 has a rather unfortunate = property that I'm not sure we want. If I were to offer something like:
>>
>> a=3Dgroup:BUNDLE foo bar
>> m=3Dvideo 20002 RTP/AVP 97
>> a=3Drtpmap:97 H261/90000
>> a=3Dmid:foo
>> m=3Dvideo 0 RTP/AVP 97 98
>> a=3Drtpmap:97 H261/90000
>> a=3Drtpmap:98 VP8/90000
>> a=3Dbundle-only
>> a=3Dmid:bar
>>
>> And the remote endpoint wanted to reject the first stream, it woul= d be forced to also reject the second. The historical intention of using &q= uot;bundle-only" was as a mechanism
>> for UDP port preservation on the offerer's side. This procedure un= intentionally turns it into a semantic binding among streams in bundle.
>>
>> I think we could restore the original purpose of the bundle-only h= andling if we used the port from the rejected 'm=3D' line containing the BU= NDLE-tag for any 'bundle-only' lines.
>
> So, I guess that means we would *always* use the BUNDLE-tag m- line po= rt - even if the m- line is rejected, AND even if there are other non-bundl= e-only m- lines that are NOT rejected.
>
> Example:
>
> a=3Dgroup:BUNDLE foo bar zoo
> m=3Dvideo 20002 RTP/AVP 97
> a=3Drtpmap:97 H261/90000
> a=3Dmid:foo
> m=3Dvideo 40002 RTP/AVP 97
> a=3Drtpmap:99 H264/99999
> a=3Dmid:zoo
> m=3Dvideo 0 RTP/AVP 97 98
> a=3Drtpmap:97 H261/90000
> a=3Drtpmap:98 VP8/90000
> a=3Dbundle-only
> a=3Dmid:bar
>
> Now, if the UAS rejects the "foo" m- line, it would still se= lect port 20002 for the offerer. The UAS would NOT select port 40002, even = if it accepts the "zoo" m- line.

There are more implications. If you are going to do this for the port,
then you need to do it for the address (c=3D) too. While most likely you would see the same address used for each, it is possible that when
getting a unique address/port pairs that you can't (or at least don't)
get the same address for each. We don't require them to be the same.

        Thanks,
        Paul

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1D79FC5AESESSMB209erics_-- From nobody Fri Apr 17 09:22:02 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB33B1A00FF for ; Fri, 17 Apr 2015 09:21:59 -0700 (PDT) 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 ayyb7CqTqdLB for ; Fri, 17 Apr 2015 09:21:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38A91A005F for ; Fri, 17 Apr 2015 09:21:56 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-7c-553133228444 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 09.5D.19337.22331355; Fri, 17 Apr 2015 18:21:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Fri, 17 Apr 2015 18:21:54 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments Thread-Index: AdB48sRiP9lfe1IKQ6C6VGl4ysyW2AAEi9eAAAbPvjEAAoTd8A== Date: Fri, 17 Apr 2015 16:21:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D79FDA0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D79F956@ESESSMB209.ericsson.se>, <55311011.9090908@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79FC5A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D79FC5A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D79FDA0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvja6ysWGoQdtGDoupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4vPcSS8Gc7IpdF68xNjBOie1i5OSQEDCR eLl7GxuELSZx4d56IJuLQ0jgKKPE7Y03WSCcJYwSd282sXYxcnCwCVhIdP/TBomLCDQzSlw7 v5wFpFtYIEPi5va3jCC2iECmxOUnc5ggbCeJlj9NYHEWAVWJ9803wObwCvhKvNzLDjF/K6PE hvct7CA1nAJ+Emf3vWMFsRmBLvp+ag3YHGYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQtpLE iu2XGCHq8yW2rz0E9hmvgKDEyZlPWCYwisxCMmoWkrJZSMog4gYS57ZvZIewtSWWLXzNDGHr S2y/PZMVWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMDIOrjlt+oOxstvHA8xCnAw KvHwKmQahAqxJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTH+ j5FL8Kovh9WkFlVe6c7Z7/H+wfaV0gwzHsTGcP7In/nBICT8R4703guJOofrrTatPivbMP9y b+GEzXf+Bh6aWy4lyB+31vDhhh+rTWSEPBSLVD/PfCkSItez8w/zpMMllgkdl+e0HP99j+V+ RtrBraYsVfP3fmBJmc3ZJZraMbtWd31j/lclluKMREMt5qLiRADSGzFrjQIAAA== Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 16:22:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D79FDA0ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, One issue related to this: if the answerer rejects the m- line, by setting = the port value to zero, how will it provide the port value associated with = the answerer BUNDLE address? The answerer BUNDLE port will of course be assigned to the other =93m=3D=94= lines within the BUNDLE group, but the port value associated with the answ= erer BUNDLE tag will be zero. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 17 April 2015 18:07 To: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 = - Adam's technical comments Hi Paul, Correct, it would also apply to the address. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD17/=FD04/=FD2015 16:52 To: mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 = - Adam's technical comments Comment at end. On 4/17/15 5:58 AM, Christer Holmberg wrote: > Hi Adam, > > Most of your editorial comments seem ok. I'll comment them later. > > However, at least a couple (please let me know if you think there are mor= e non-editorial ones) of your comments was technical, and I'll focus on tho= se in this reply. > > -------------------------------------------------------------------------= -- > >> The procedure described in Section 8.3.2 has a rather unfortunate proper= ty that I'm not sure we want. If I were to offer something like: >> >> a=3Dgroup:BUNDLE foo bar >> m=3Dvideo 20002 RTP/AVP 97 >> a=3Drtpmap:97 H261/90000 >> a=3Dmid:foo >> m=3Dvideo 0 RTP/AVP 97 98 >> a=3Drtpmap:97 H261/90000 >> a=3Drtpmap:98 VP8/90000 >> a=3Dbundle-only >> a=3Dmid:bar >> >> And the remote endpoint wanted to reject the first stream, it would be f= orced to also reject the second. The historical intention of using "bundle-= only" was as a mechanism >> for UDP port preservation on the offerer's side. This procedure unintent= ionally turns it into a semantic binding among streams in bundle. >> >> I think we could restore the original purpose of the bundle-only handlin= g if we used the port from the rejected 'm=3D' line containing the BUNDLE-t= ag for any 'bundle-only' lines. > > So, I guess that means we would *always* use the BUNDLE-tag m- line port = - even if the m- line is rejected, AND even if there are other non-bundle-o= nly m- lines that are NOT rejected. > > Example: > > a=3Dgroup:BUNDLE foo bar zoo > m=3Dvideo 20002 RTP/AVP 97 > a=3Drtpmap:97 H261/90000 > a=3Dmid:foo > m=3Dvideo 40002 RTP/AVP 97 > a=3Drtpmap:99 H264/99999 > a=3Dmid:zoo > m=3Dvideo 0 RTP/AVP 97 98 > a=3Drtpmap:97 H261/90000 > a=3Drtpmap:98 VP8/90000 > a=3Dbundle-only > a=3Dmid:bar > > Now, if the UAS rejects the "foo" m- line, it would still select port 200= 02 for the offerer. The UAS would NOT select port 40002, even if it accepts= the "zoo" m- line. There are more implications. If you are going to do this for the port, then you need to do it for the address (c=3D) too. While most likely you would see the same address used for each, it is possible that when getting a unique address/port pairs that you can't (or at least don't) get the same address for each. We don't require them to be the same. Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D79FDA0ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

One issue = related to this: if the answerer rejects the m- line, by setting the port v= alue to zero, how will it provide the port value associated with the answerer BUNDLE address?

 = ;

The answer= er BUNDLE port will of course be assigned to the other =93m=3D=94 lines wit= hin the BUNDLE group, but the port value associated with the answerer BUNDLE tag will be zero.

 = ;

Regards,

 = ;

Christer

 

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 17 April 2015 18:07
To: Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiat= ion-19 - Adam's technical comments

 

Hi Paul,

Correct, it would also apply to the address.

Regards,

Christer



Sent from my Windows Phone

From: Paul Kyzivat
Sent: =FD17/=FD04/=FD2015 16:52
To: mmusic@ietf.org<= /span>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Ad= am's technical comments

Comment at end.

On 4/17/15 5:58 AM, Christer Holmberg wrote:
> Hi Adam,
>
> Most of your editorial comments seem ok. I'll comment them later.
>
> However, at least a couple (please let me know if you think there are = more non-editorial ones) of your comments was technical, and I'll focus on = those in this reply.
>
> ----------------------------------------------------------------------= -----
>
>> The procedure described in Section 8.3.2 has a rather unfortunate = property that I'm not sure we want. If I were to offer something like:
>>
>> a=3Dgroup:BUNDLE foo bar
>> m=3Dvideo 20002 RTP/AVP 97
>> a=3Drtpmap:97 H261/90000
>> a=3Dmid:foo
>> m=3Dvideo 0 RTP/AVP 97 98
>> a=3Drtpmap:97 H261/90000
>> a=3Drtpmap:98 VP8/90000
>> a=3Dbundle-only
>> a=3Dmid:bar
>>
>> And the remote endpoint wanted to reject the first stream, it woul= d be forced to also reject the second. The historical intention of using &q= uot;bundle-only" was as a mechanism
>> for UDP port preservation on the offerer's side. This procedure un= intentionally turns it into a semantic binding among streams in bundle.
>>
>> I think we could restore the original purpose of the bundle-only h= andling if we used the port from the rejected 'm=3D' line containing the BU= NDLE-tag for any 'bundle-only' lines.
>
> So, I guess that means we would *always* use the BUNDLE-tag m- line po= rt - even if the m- line is rejected, AND even if there are other non-bundl= e-only m- lines that are NOT rejected.
>
> Example:
>
> a=3Dgroup:BUNDLE foo bar zoo
> m=3Dvideo 20002 RTP/AVP 97
> a=3Drtpmap:97 H261/90000
> a=3Dmid:foo
> m=3Dvideo 40002 RTP/AVP 97
> a=3Drtpmap:99 H264/99999
> a=3Dmid:zoo
> m=3Dvideo 0 RTP/AVP 97 98
> a=3Drtpmap:97 H261/90000
> a=3Drtpmap:98 VP8/90000
> a=3Dbundle-only
> a=3Dmid:bar
>
> Now, if the UAS rejects the "foo" m- line, it would still se= lect port 20002 for the offerer. The UAS would NOT select port 40002, even = if it accepts the "zoo" m- line.

There are more implications. If you are going to do this for the port,
then you need to do it for the address (c=3D) too. While most likely you would see the same address used for each, it is possible that when
getting a unique address/port pairs that you can't (or at least don't)
get the same address for each. We don't require them to be the same.

        Thanks,
        Paul

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

--_000_7594FB04B1934943A5C02806D1A2204B1D79FDA0ESESSMB209erics_-- From nobody Fri Apr 17 09:29:21 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D611A1BDE for ; Fri, 17 Apr 2015 09:29:20 -0700 (PDT) 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 1z5smRcLYM6d for ; Fri, 17 Apr 2015 09:29:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE4C1A1BDC for ; Fri, 17 Apr 2015 09:29:17 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-c9-553134da7abd Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.C4.28835.AD431355; Fri, 17 Apr 2015 18:29:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Fri, 17 Apr 2015 18:29:14 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments Thread-Index: AdB48sRiP9lfe1IKQ6C6VGl4ysyW2AAEi9eAAAbPvjEAAoTd8AAAS6Mg Date: Fri, 17 Apr 2015 16:29:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D79FE66@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D79F956@ESESSMB209.ericsson.se>, <55311011.9090908@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79FC5A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D79FDA0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D79FDA0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D79FE66ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje5tE8NQg21feCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjy4KzzAXTmhgrbje0szQwNhZ1MXJwSAiY SDx+rNfFyAlkiklcuLeerYuRi0NI4CijxKkN7UwQzhJGibN9XSwgDWwCFhLd/7RBGkQEfCWe Pb7NBmILC2RI3Nz+lhEinilx+ckcJgjbTeLQvH0sIDaLgKrE4U8L2EFsXqDe6x9esUPM/8ko Me/ra3aQ+ZwCfhJ3JymB1DACHfT91BqwOcwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbCWJ FdsvMULU50ucvHiWDWKXoMTJmU9YJjCKzEIyahaSsllIyiDiBhLntm9kh7C1JZYtfM0MYetL bL89kxVZfAEj+ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwLg6uOW31Q7Gg88dDzEKcDAq 8fAqZBqECrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcX3O p4WuNw7cWGmzUcnqC++u0Ivez2axM8or1tXc7DCfaMXC9+32tl2PGvLeyYr2+l7XPqd/edqk CrP9DoYJ8RfCnUvvM83k716+vvVcBIPhUeZTWxZOSbdY3n8vSXDOgkNn1e5a9TPWF24q2V0x 6Zsrn928JNZCFoOvaVoVMRMuNayb/OK0mxJLcUaioRZzUXEiAKNW45iMAgAA Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 16:29:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D79FE66ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable More about this: If the answerer rejects the =93m=3D=94 line, it won=92t (at least not curre= ntly) even be part of the BUNDLE group. So, how will the offerer know which= port has been selected as the offerer BUNDLE port? Regards, Christer From: Christer Holmberg Sent: 17 April 2015 19:22 To: Christer Holmberg; Paul Kyzivat; mmusic@ietf.org Subject: RE: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 = - Adam's technical comments Hi, One issue related to this: if the answerer rejects the m- line, by setting = the port value to zero, how will it provide the port value associated with = the answerer BUNDLE address? The answerer BUNDLE port will of course be assigned to the other =93m=3D=94= lines within the BUNDLE group, but the port value associated with the answ= erer BUNDLE tag will be zero. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 17 April 2015 18:07 To: Paul Kyzivat; mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 = - Adam's technical comments Hi Paul, Correct, it would also apply to the address. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD17/=FD04/=FD2015 16:52 To: mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 = - Adam's technical comments Comment at end. On 4/17/15 5:58 AM, Christer Holmberg wrote: > Hi Adam, > > Most of your editorial comments seem ok. I'll comment them later. > > However, at least a couple (please let me know if you think there are mor= e non-editorial ones) of your comments was technical, and I'll focus on tho= se in this reply. > > -------------------------------------------------------------------------= -- > >> The procedure described in Section 8.3.2 has a rather unfortunate proper= ty that I'm not sure we want. If I were to offer something like: >> >> a=3Dgroup:BUNDLE foo bar >> m=3Dvideo 20002 RTP/AVP 97 >> a=3Drtpmap:97 H261/90000 >> a=3Dmid:foo >> m=3Dvideo 0 RTP/AVP 97 98 >> a=3Drtpmap:97 H261/90000 >> a=3Drtpmap:98 VP8/90000 >> a=3Dbundle-only >> a=3Dmid:bar >> >> And the remote endpoint wanted to reject the first stream, it would be f= orced to also reject the second. The historical intention of using "bundle-= only" was as a mechanism >> for UDP port preservation on the offerer's side. This procedure unintent= ionally turns it into a semantic binding among streams in bundle. >> >> I think we could restore the original purpose of the bundle-only handlin= g if we used the port from the rejected 'm=3D' line containing the BUNDLE-t= ag for any 'bundle-only' lines. > > So, I guess that means we would *always* use the BUNDLE-tag m- line port = - even if the m- line is rejected, AND even if there are other non-bundle-o= nly m- lines that are NOT rejected. > > Example: > > a=3Dgroup:BUNDLE foo bar zoo > m=3Dvideo 20002 RTP/AVP 97 > a=3Drtpmap:97 H261/90000 > a=3Dmid:foo > m=3Dvideo 40002 RTP/AVP 97 > a=3Drtpmap:99 H264/99999 > a=3Dmid:zoo > m=3Dvideo 0 RTP/AVP 97 98 > a=3Drtpmap:97 H261/90000 > a=3Drtpmap:98 VP8/90000 > a=3Dbundle-only > a=3Dmid:bar > > Now, if the UAS rejects the "foo" m- line, it would still select port 200= 02 for the offerer. The UAS would NOT select port 40002, even if it accepts= the "zoo" m- line. There are more implications. If you are going to do this for the port, then you need to do it for the address (c=3D) too. While most likely you would see the same address used for each, it is possible that when getting a unique address/port pairs that you can't (or at least don't) get the same address for each. We don't require them to be the same. Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1D79FE66ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

More about= this:

 = ;

If the ans= werer rejects the =93m=3D=94 line, it won=92t (at least not currently) even= be part of the BUNDLE group. So, how will the offerer know which port has been selected as the offerer BUNDLE port?

 

Regards,

 = ;

Christer

 = ;

From: = Christer Holmberg
Sent: 17 April 2015 19:22
To: Christer Holmberg; Paul Kyzivat; mmusic@ietf.org
Subject: RE: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiat= ion-19 - Adam's technical comments

 

Hi,

 = ;

One issue = related to this: if the answerer rejects the m- line, by setting the port v= alue to zero, how will it provide the port value associated with the answerer BUNDLE address?

 = ;

The answer= er BUNDLE port will of course be assigned to the other =93m=3D=94 lines wit= hin the BUNDLE group, but the port value associated with the answerer BUNDLE tag will be zero.

 = ;

Regards,

 = ;

Christer

 = ;

From: = mmusic [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Christer Holmberg
Sent: 17 April 2015 18:07
To: Paul Kyzivat; mmusic@ietf.org=
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiat= ion-19 - Adam's technical comments

 

Hi Paul,

Correct, it would also apply to the address.

Regards,

Christer



Sent from my Windows Phone

From: Paul Kyzivat
Sent: =FD17/=FD04/=FD2015 16:52
To: mmusic@ietf.org<= /span>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Ad= am's technical comments

Comment at end.

On 4/17/15 5:58 AM, Christer Holmberg wrote:
> Hi Adam,
>
> Most of your editorial comments seem ok. I'll comment them later.
>
> However, at least a couple (please let me know if you think there are = more non-editorial ones) of your comments was technical, and I'll focus on = those in this reply.
>
> ----------------------------------------------------------------------= -----
>
>> The procedure described in Section 8.3.2 has a rather unfortunate = property that I'm not sure we want. If I were to offer something like:
>>
>> a=3Dgroup:BUNDLE foo bar
>> m=3Dvideo 20002 RTP/AVP 97
>> a=3Drtpmap:97 H261/90000
>> a=3Dmid:foo
>> m=3Dvideo 0 RTP/AVP 97 98
>> a=3Drtpmap:97 H261/90000
>> a=3Drtpmap:98 VP8/90000
>> a=3Dbundle-only
>> a=3Dmid:bar
>>
>> And the remote endpoint wanted to reject the first stream, it woul= d be forced to also reject the second. The historical intention of using &q= uot;bundle-only" was as a mechanism
>> for UDP port preservation on the offerer's side. This procedure un= intentionally turns it into a semantic binding among streams in bundle.
>>
>> I think we could restore the original purpose of the bundle-only h= andling if we used the port from the rejected 'm=3D' line containing the BU= NDLE-tag for any 'bundle-only' lines.
>
> So, I guess that means we would *always* use the BUNDLE-tag m- line po= rt - even if the m- line is rejected, AND even if there are other non-bundl= e-only m- lines that are NOT rejected.
>
> Example:
>
> a=3Dgroup:BUNDLE foo bar zoo
> m=3Dvideo 20002 RTP/AVP 97
> a=3Drtpmap:97 H261/90000
> a=3Dmid:foo
> m=3Dvideo 40002 RTP/AVP 97
> a=3Drtpmap:99 H264/99999
> a=3Dmid:zoo
> m=3Dvideo 0 RTP/AVP 97 98
> a=3Drtpmap:97 H261/90000
> a=3Drtpmap:98 VP8/90000
> a=3Dbundle-only
> a=3Dmid:bar
>
> Now, if the UAS rejects the "foo" m- line, it would still se= lect port 20002 for the offerer. The UAS would NOT select port 40002, even = if it accepts the "zoo" m- line.

There are more implications. If you are going to do this for the port,
then you need to do it for the address (c=3D) too. While most likely you would see the same address used for each, it is possible that when
getting a unique address/port pairs that you can't (or at least don't)
get the same address for each. We don't require them to be the same.

        Thanks,
        Paul

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

--_000_7594FB04B1934943A5C02806D1A2204B1D79FE66ESESSMB209erics_-- From nobody Sat Apr 18 12:17:20 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E781F1A1B98 for ; Sat, 18 Apr 2015 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-T6h4w_POrM for ; Sat, 18 Apr 2015 12:17:17 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A131A1B96 for ; Sat, 18 Apr 2015 12:17:16 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-05v.sys.comcast.net with comcast id HXH71q00626dK1R01XHFLc; Sat, 18 Apr 2015 19:17:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id HXHF1q00B3Ge9ey01XHFan; Sat, 18 Apr 2015 19:17:15 +0000 Message-ID: <5532ADB9.5020907@alum.mit.edu> Date: Sat, 18 Apr 2015 15:17:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D79F956@ESESSMB209.ericsson.se>, <55311011.9090908@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79FC5A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D79FDA0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D79FE66@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D79FE66@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429384635; bh=cWrFDog1NiUf3+ixyAV6YIMGyVydXdzbqlqgZcp6OsA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tt9tCOA805ETKSAom3BUNpJXfYKvkzR3Ehfky6XXs2ZhwOH/XMRWlvwNOOpaQuVmq lVoLEiLq4q+R42wLlCoutFttvE5tLPkNQmCRzXLHzjNNouSFjI7A6a/VlqlXnVBvpy BXgUGRK8jUvzUFuTP/PicUycUsKd7QJhUZpFb4z9xV1QG+Lx44yLtcRPbYDkw0JYKc fG6jFKM4jQ9L6tDNrLe1k9kvcvByOSO+MLSIycXORBBgGd2cL7nvYvf2un4lGkVAKe EOIozIFah4D42qWh8oIYxAaDeVmzEBZncxWftHQUNS3fjPg6GRd9jsbkLMDT2TLqgu rRWG5u6REQlpQ== Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 19:17:19 -0000 On 4/17/15 12:29 PM, Christer Holmberg wrote: > More about this: > > If the answerer rejects the m= line, it wont (at least not currently) > even be part of the BUNDLE group. So, how will the offerer know which > port has been selected as the offerer BUNDLE port? Another related problem: Consider Adam's example: > a=group:BUNDLE foo bar > m=video 20002 RTP/AVP 97 > a=rtpmap:97 H261/90000 > a=mid:foo > m=video 0 RTP/AVP 97 98 > a=rtpmap:97 H261/90000 > a=rtpmap:98 VP8/90000 > a=bundle-only > a=mid:bar Suppose, instead of rejecting foo, the answerer wants to accept it, but doesn't want it to be part of the bundle. Yet it still wants to accept bar as part of the bundle? That of course makes little sense, since without foo there is no bundle. But I think the same is true for Adam's case. So I think this is a "problem" that doesn't need fixing. Thanks, Paul > Regards, > > Christer > > *From:*Christer Holmberg > *Sent:* 17 April 2015 19:22 > *To:* Christer Holmberg; Paul Kyzivat; mmusic@ietf.org > *Subject:* RE: [MMUSIC] WGLC for > draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments > > Hi, > > One issue related to this: if the answerer rejects the m- line, by > setting the port value to zero, how will it provide the port value > associated with the answerer BUNDLE address? > > The answerer BUNDLE port will of course be assigned to the other m= > lines within the BUNDLE group, but the port value associated with the > answerer BUNDLE tag will be zero. > > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 17 April 2015 18:07 > *To:* Paul Kyzivat; mmusic@ietf.org > *Subject:* Re: [MMUSIC] WGLC for > draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments > > Hi Paul, > > Correct, it would also apply to the address. > > Regards, > > Christer > > > > Sent from my Windows Phone > > ------------------------------------------------------------------------ > > *From: *Paul Kyzivat > *Sent: *17/04/2015 16:52 > *To: *mmusic@ietf.org > *Subject: *Re: [MMUSIC] WGLC for > draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments > > Comment at end. > > On 4/17/15 5:58 AM, Christer Holmberg wrote: >> Hi Adam, >> >> Most of your editorial comments seem ok. I'll comment them later. >> >> However, at least a couple (please let me know if you think there are more non-editorial ones) of your comments was technical, and I'll focus on those in this reply. >> >> --------------------------------------------------------------------------- >> >>> The procedure described in Section 8.3.2 has a rather unfortunate property that I'm not sure we want. If I were to offer something like: >>> >>> a=group:BUNDLE foo bar >>> m=video 20002 RTP/AVP 97 >>> a=rtpmap:97 H261/90000 >>> a=mid:foo >>> m=video 0 RTP/AVP 97 98 >>> a=rtpmap:97 H261/90000 >>> a=rtpmap:98 VP8/90000 >>> a=bundle-only >>> a=mid:bar >>> >>> And the remote endpoint wanted to reject the first stream, it would be forced to also reject the second. The historical intention of using "bundle-only" was as a mechanism >>> for UDP port preservation on the offerer's side. This procedure unintentionally turns it into a semantic binding among streams in bundle. >>> >>> I think we could restore the original purpose of the bundle-only handling if we used the port from the rejected 'm=' line containing the BUNDLE-tag for any 'bundle-only' lines. >> >> So, I guess that means we would *always* use the BUNDLE-tag m- line port - even if the m- line is rejected, AND even if there are other non-bundle-only m- lines that are NOT rejected. >> >> Example: >> >> a=group:BUNDLE foo bar zoo >> m=video 20002 RTP/AVP 97 >> a=rtpmap:97 H261/90000 >> a=mid:foo >> m=video 40002 RTP/AVP 97 >> a=rtpmap:99 H264/99999 >> a=mid:zoo >> m=video 0 RTP/AVP 97 98 >> a=rtpmap:97 H261/90000 >> a=rtpmap:98 VP8/90000 >> a=bundle-only >> a=mid:bar >> >> Now, if the UAS rejects the "foo" m- line, it would still select port 20002 for the offerer. The UAS would NOT select port 40002, even if it accepts the "zoo" m- line. > > There are more implications. If you are going to do this for the port, > then you need to do it for the address (c=) too. While most likely you > would see the same address used for each, it is possible that when > getting a unique address/port pairs that you can't (or at least don't) > get the same address for each. We don't require them to be the same. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Apr 20 06:06:35 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF41AC407 for ; Mon, 20 Apr 2015 06:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-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 dxzC99gdk4Bi for ; Mon, 20 Apr 2015 06:06:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E9B1A92B4 for ; Mon, 20 Apr 2015 06:06:29 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-ca-5534f9d34a36 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.D7.01716.3D9F4355; Mon, 20 Apr 2015 15:06:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Mon, 20 Apr 2015 15:06:26 +0200 From: Christer Holmberg To: Adam Roach , Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's editorial comments Thread-Index: AdB7NdnGOo32qKL8RXaI/mRPAnIN7Q== Date: Mon, 20 Apr 2015 13:06:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7C064E@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7lnyahBhc+ylns+buI3eJT9wY2 i/cXdC3+7U2ymLr8MYsDq8eU3xtZPZYs+cnkMWvnExaPL5c/swWwRHHZpKTmZJalFunbJXBl LL+1gr1gzgTGipnXfzE1MC4p7mLk5JAQMJE42rWMBcIWk7hwbz1bFyMXh5DAUUaJqxNvsUI4 ixklFrw8AuRwcLAJWEh0/9MGaRARSJO4c34DC0gNs8AuRol321aygiSEBTIk2jsXM4HUiwhk Sky7LQZRryexZMNksBIWAVWJJ5fusoPYvAK+EtNWnAWLMwId8f3UGiYQm1lAXOLWk/lMEMcJ SCzZc54ZwhaVePn4HyuErSTxY8MlFoh6HYkFuz+xQdjaEssWvmaGmC8ocXLmE5YJjCKzkIyd haRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjJ+DW37r7mBc/drxEKMA B6MSD++CWJNQIdbEsuLK3EOM0hwsSuK8dsaHQoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw ChzlXSGWHH01eT1/yL2YmSJRhb27f2wN6bSa6PLhekse0/4uw42WN6RuhDP2rk+42CD55evW aUUzwr7zGJ16s0zux5pY8xtSpz7/Kltne8dfo22NFdvk0vBEjf9TlZiO7FCxFL8+3/Bbv07v /F3PVZM4n90QMP/xf9+Z0t71h3yCF7kuXHnuixJLcUaioRZzUXEiAG264oKAAgAA Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's editorial comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:06:34 -0000 Hi Adam, My reply to your editorial comments. --------------------------------------------------------------------------= - In the Abstract: > "This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264= to > allow an answerer to assign a non-zero port value to an "m=3D" line= in > an SDP answer, even if the "m=3D" line in the associated SDP offer > contained a zero port values. > > This seems to be a bit of a deep dive for the abstract, and I would propo= se removing it. If it does remain, it needs to include something like "unde= r certain circumstances." But I think removal is the better option. I suggest to remove it. The introduction should also qualify the similar statement in this paragrap= h: > This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 > [RFC3264]. The update allows an answerer to assign a non-zero port > value to an "m=3D" line in an SDP answer, even if the "m=3D" line in t= he > associated SDP offer contained a zero port value. In the Introduction, I suggest to modify the text to: "This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 [RFC3264]. The update allows an answerer, under certain circumstances described in the specification, to assign a non-zero port value to an "m=3D" line in an SDP answer, even if the "m=3D" line in th= e associated SDP offer contained a zero port value." --------------------------------------------------------------------------- > Especially because the term is overloaded, you should expand the meaning = of "SDES" on first use; something like: > > "This specification also defines a new Real-time Transport Protocol > (RTP) [RFC3550] Source Description (SDES) item..." I'll fix as suggested. --------------------------------------------------------------------------- > Terminology: Since we are using '"m=3D" line' in a way that isn't (to my > knowledge) defined in another document, this section should include a def= inition for that term. Yes, it's in the introduction, but that's not where = people look for definitions of terms. I reviewed the BFCFbis draft last week, and that uses "m line" terminology,= without any definition, and I believe it exists also in other drafts. --------------------------------------------------------------------------- > Section 5 should cite RFC 4961 for the definition of "symmetric RTP." I'll fix as suggested. --------------------------------------------------------------------------- Section 5 has this normative requirement: > A given address:port combination MUST NOT be used for sending media as= sociated with > multiple BUNDLE groups. > > It's not clear what this gains us. Everywhere else, we only require a uni= que 5-tuple per bundle. That seems like the correct restriction to impose. > (If we change this, it also has impacts on section 8.3.3) Sections 5 and 8.3.3 talk about different things: Section 5 talks about the address:port used for sending media, while sectio= n 8.3.3 talks about the address:port used for receiving media (i.e. the add= ress:port included in SDP). We could perhaps remove the restriction saying that a single address:port c= an only be used for sending media associated with a single BUNDLE group (se= ction 5).=20 But, I don't think we should allow usage of a single address:port for recei= ving media associated with multiple BUNDLE groups (and possible non-bundle = "m=3D" lines), because even without BUNDLE each "m=3D" line must have a uni= que address:port for receiving media. --------------------------------------------------------------------------- Section 5: > Each "m=3D" line, whose identification-tag is listed in the > identification-tag list, is associated with a given BUNDLE group. > > Repunctuate as: > > Each "m=3D" line whose identification-tag is listed in the > identification-tag list is associated with a given BUNDLE group. > > (cf. ) I'll fix as suggested. --------------------------------------------------------------------------- Section 6: > This whole section feels really out of place here; it's assuming that t= he > reader has knowledge about BUNDLE offer/answer handling that he won't l= earn > until reading section 8. I would propose that you leave the attribute > definition in section 14.3, and move the semantics into section 8. People have previously said that we should have a dedicated section where t= he attribute is described. And, as there has been a number of restructure changes throughout the proce= ss of the draft, so I'd like to keep it as it is. --------------------------------------------------------------------------- Section 6: =20 > "In order to ensure that an answerer that does not supports the BUNDLE" > > s/supports/support/ I'll fix as suggested. --------------------------------------------------------------------------- Section 6: > NOTE: Once an offerer BUNDLE address has been selected, the offerer > can ensure that an bundled "m=3D" line is accepted by the answerer onl= y > if the answerer keeps the "m=3D" line within the associated BUNDLE > group by assigning the offerer BUNDLE address to the "m=3D" line. If > the answerer does not keep that "m=3D" line within the BUNDLE group, > the answerer will reject it. Therefore, the SDP 'bundle-only' > attribute is not needed in such cases > > I can't make any sense of that paragraph, and it's only partially because= the passive "has been selected" doesn't indicate who is performing the sel= ection. > In particular, it doesn't sound like the offerer is *ensuring* anything.= =20 > Maybe we're trying to say he can detect something? But even with that in= terpretation, it's not clear what circumstances it's trying to say don't re= quire=20 > the use of 'bundle-only.' Or is this trying to say that subsequent offers= (as defined in section 2) don't need to use 'bundle-only' because you know= whether=20 > the peer supports bundle? That makes some sense, but it's really hard to = get that meaning out of the text. > > Let me take a stab at something. > > NOTE: Subsequent offers do not need to include the 'bundle-only'=20 > attribute, since the offerer will already know whether its peer suppor= ts the BUNDLE > mechanism. With that knowledge, the offerer can assign a new 'm=3D' li= ne to > an existing BUNDLE address. By doing so, they ensure that the answerer > either accepts the line into the BUNDLE, or completely rejects it. > > If that's what we mean, I propose replacing the paragraph with it. If it'= s not, then the paragraph needs to be rewritten. That is what we mean. > Also, if that's what we mean, then it needs corresponding text in section= 8.3.1 (although if you take the suggestion to move the semantics from sect= ion 6=20 > into section 8, it might make more sense to just put it there only rather= than describe it in two places). Are you sure you mean 8.3.1? That is about generating the answer. --------------------------------------------------------------------------- Section 8.1: > The offerer and answerer MUST follow the rules and restrictions > defined in Section 7 when creating offers and answers. > > This adds nothing. I would propose removing it (or, if you don't want to = remove it, I would propose that consistency calls for > having every section normatively require that implementors follow the nor= mative statements of every other section in the document). I suggest to remove it. --------------------------------------------------------------------------- > Section 8.2.1: > > o Add an SDP 'group:BUNDLE' attribute to the offer; > > Replace with: > > o Add an SDP 'group:BUNDLE' attribute to the offer at the session lev= el; I can fix as suggested, if it makes things more clear. However, the SDP gro= up attribute is only defined as a session-level attribute to begin with. --------------------------------------------------------------------------- > Section 8.3.1: > > When an answerer generates an answer, which contains a BUNDLE group, > > Replace with: > > When an answerer generates an answer that contains a BUNDLE group, > > (cf. ) I'll fix as suggested. --------------------------------------------------------------------------- > Section 8.3.4 is structured very awkwardly. It calls out two conditions t= hat preclude moving an m=3D line out of a bundle > (shared address, bundle-only), and one that allows it. It would be much c= learer if it were stated in those terms rather=20 > than describing the rejection of a media stream as if it were the same th= ing as accepting a media stream with different addressing information. Perhaps something like: "8.3.4. Moving A Media Description Out Of A BUNDLE Group When an answerer wants to move a "m=3D" line out of a BUNDLE group, it MUST check whether, in the associated offer, the "m=3D" line contains a unique address. If so, when the answerer moves the "m=3D" line out of the BUNDLE group, it MUST assign a unique address to the corresponding "m=3D" line in the answer. In the following cases, the "m=3D" line cannot simply be moved out of a BUNDLE group, but MUST also reject the "m=3D" line [Section 8.3.5]: o In the associated offer, if the "m=3D" line contains a shared address (e.g. a previously selected offerer BUNDLE address), the answerer MUST reject the moved "m=3D" line; or o In the associated offer, if an SDP 'bundle-only' attribute is associated with the "m=3D" line, and if the "m=3D" line contains a zero port value. In addition, in either case above, the answerer MUST NOT place the identification-tag, associated with the moved/rejected "m=3D" line, in=20 the SDP 'group' attribute identification-tag list associated with the BU= NDLE group." -------------------------------------------------------------------------- > Section 8.4.1: > > When an offerer receives an answer, if the answer contains a BUNDLE > group, the offerer MUST check that any bundled "m=3D" line in the > answer was indicated as bundled in the associated offer. > > This is backwards as compared to the logic described in the section. > The remainder of the text talks about checking whether that bundled "m=3D= " lines in the *offer* appear in the *answer* (and, if they don't, moving t= hem out of the bundle). > > If the answer has a bundle that contains an m-line that wasn't bundled in= the offer, it's an error. > > Also, 8.4.1 is the only subsection in 8.4, which is otherwise empty. > I suggest removing 8.4.1, and putting its contents directly in 8.4. I'll fix as suggested. -------------------------------------------------------------------------- > Section 8.5.4 should explicitly mention the case in which the line being = moved out is the one identified by the BUNDLE-tag. I think all we=20 > need to say is that the BUNDLE-tag for a bundle changes if the correspond= ing m=3D line is removed from the bundle. I could add the following note: "NOTE: If the offerer BUNDLE-tag represents the moved "m=3D" line, the off= erer needs=20 to select a new offerer BUNDLE-tag, which represents a "m=3D" line that is= kept within the BUNDLE group." -------------------------------------------------------------------------- > Section 9.1: "publically" is more conventionally spelled "publicly" I'll fix as suggested. -------------------------------------------------------------------------- Section 10.2: > An offerer and answerer can in an offer and answer inform each other > which SSRC values they will use inside sent RTP/RTCP packets, by > associating one or more SDP 'ssrc' attributes [RFC5576] with each > bundled "m=3D" line which contains a payload type value that is also > used inside another bundled "m=3D" line. > > That's really hard to follow. I propose reformulating along the lines of: > > Peers to a session can inform each other which SSRC values they will u= se > for RTP and RTCP through the use of the SDP 'ssrc' attribute [RFC5576]= . > To allow for proper association with this mechanism, the 'ssrc'=20 > attribute needs to appear in each "m=3D" line that shares a payload ty= pe=20 > with any other "m=3D" line in the same bundle. > > Also, doesn't the final paragraph of this section kind of make the rest o= f the section a waste of space? I have been trying hard to use consistent terminology throughout the docume= nt, so I would like to try to stick to that. So, perhaps something like: "An offerer and answerer can inform each other which SSRC values they will= use inside=20 RTP/RTCP packets sent to each other. This is done by associating one or mo= re SDP 'ssrc'=20 attributes [RFC5576] with each bundled "m=3D" line that contains a payload= type value that=20 it shares with any other "m=3D" line within the same BUNDLE group." -------------------------------------------------------------------------- > Section 10.3.1: > > When a BUNDLE group, which contains RTP based media, is created,... > > Change to: > > When a BUNDLE group that contains RTP based media is created,... I'll fix as suggested. -------------------------------------------------------------------------- > Section 10.3 (and its subsections) doesn't clearly explain where RTCP wil= l be received in the various described scenarios. In particular, I believe = we=20 > need to clarify that, while users might indicate a bunch of different rtc= p ports (using the 'rtcp' attribute) in bundled "m=3D" lines, if the answer= accepts=20 > an "m=3D" line into a bundle, then the rtcp port indicated in the section= associated with the selected BUNDLE address will be used. For the answerer, section 10.3.2.3 says: "If the answerer does not accept the usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT associate an SDP 'rtcp-mux' attribute with any bundled "m=3D" line in the answer. The answerer will use the RTP and RTCP port values associated with the selected offerer BUNDLE address for sending RTP and RTCP packets associated with each RTP-based bundled "m=3D" line towards the offerer." For the offerer, section 10.3.2.4 says: "If the answerer associated an SDP 'rtcp' attribute with the "m=3D" line representing the answerer BUNDLE address, the offerer will use the attribute port value for sending RTCP packets associated with each bundled RTP-based "m=3D" line towards the answerer. Otherwise the offerer will use the next higher port value associated with the answerer BUNDLE address for sending RTCP packets towards the answerer." So, I think it is indicated that the RTCP port is derived from the selected= BUNDLE address (offerer or answerer). -------------------------------------------------------------------------- > 11.2.3: > > When an answerer generates an answer, which contains a BUNDLE group, > > Replace with: > > When an answerer generates an answer that contains a BUNDLE group, I'll fix as suggested. -------------------------------------------------------------------------- > Section 12, general: > > Figuring out what changed in these rather large swaths of text is difficu= lt. > It would be very helpful if these were broken down like: > > 12.2 Changes to section 5.1 (2nd paragraph) of RFC 3264 > > The final sentence of the paragraph is modified to change the meaning > of port zero. > > 12.2.1 Original Text > ... > 12.2.2 New Text > ... > 12.3 Changes to section 8.2 (2nd paragraph) of RFC 3264 > ... > 12.3.1 Original Text > ... > 12.3.2 New Text > ... > > etc. People have had different opinions - and IESG will have their opinion. So, my suggestion would be to NOT change anything at this point. -------------------------------------------------------------------------- > Section 13.1: > > The endpoint informs the remote endpoint about the identification-tag > using the procedures in [RFC5888], and the remote endpoint then > inserts the identification-tag in RTCP- and RTP packets sent towards > the other endpoint. > > It's really hard to follow which endpoint is doing what. Perhaps somethin= g like this would be clearer: > > A media recipient informs the media sender about the identification-ta= g > associated with an "m=3D" line through the use of an 'mid' attribute > [RFC5888]. The media sender then inserts the identification-tag in RTC= P > and RTP packets sent to the media recipient. I am using "endpoint" terminology throughout the document.=20 But, perhaps something like: "A media receiving endpoint informs the media sending endpoint about the i= dentification-tag associated with an "m=3D" line through the use of an 'mid' attribute [RFC5888]. The sender endpoint then inserts the identification-tag in RTCP and RTP packets sent to the receiving endpoint." -------------------------------------------------------------------------- > Section 14: > > There is no IANA section that registers the "BUNDLE" token for this > registry: > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-p= arameters-13 > > For sections 14.2 and 14.3, I believe it is traditional for WG items to l= ist the WG as contact for IANA registrations rather than individual documen= t authors. I took some random attributes from the IANA SDP attribute registry list, an= d in the associated RFCs they all had individuals listed as contacts. -------------------------------------------------------------------------- > I have not reviewed the examples or the appendix. Depending on what changes we do, e.g. related to suggesting a new offerer B= UNDLE address, I'll check that the examples are still aligned. -------------------------------------------------------------------------- Regards, Christer From nobody Mon Apr 20 06:18:47 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED801B2B4A; Mon, 20 Apr 2015 06:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XloXwkQqXzB0; Mon, 20 Apr 2015 06:18:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 395451B2B50; Mon, 20 Apr 2015 06:18:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420131832.27265.31870.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 06:18:32 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:18:46 -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 : The Comparison of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) Authors : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-15.txt Pages : 44 Date : 2015-04-20 Abstract: This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 20 06:23:24 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DBD1B2B3C for ; Mon, 20 Apr 2015 06:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2aeDaQnflNA for ; Mon, 20 Apr 2015 06:23:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7131B2B41 for ; Mon, 20 Apr 2015 06:23:15 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-14-5534fdc1aa4e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BC.BA.01716.1CDF4355; Mon, 20 Apr 2015 15:23:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.210.2; Mon, 20 Apr 2015 15:23:09 +0200 Message-ID: <5534FDBD.6020708@ericsson.com> Date: Mon, 20 Apr 2015 15:23:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: References: <20150420131832.27265.31870.idtracker@ietfa.amsl.com> In-Reply-To: <20150420131832.27265.31870.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3RvfQX5NQg4/vOCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMtn1zIXvJKo+H6vrIHxvHAXIyeHhICJxM8Ld9ghbDGJC/fW s4HYQgJHGSW2LAGyuYDs5YwSM+9PAUvwCmhLrGpdwQpiswioSjxa9BMsziZgIXHzRyOYLSoQ JTHx6yEWiHpBiZMzn4DZIgKiEo8uLgLq5eAQFvCTmPtJFsQUEnCU+N4aAFLBKeAkceLBCrBq ZgEDiSOL5rBC2PISzVtnM0Ocpi3R0NTBOoFRYBaSBbOQtMxC0rKAkXkVo2hxanFxbrqRsV5q UWZycXF+nl5easkmRmDwHdzyW3cH4+rXjocYBTgYlXh4F8SahAqxJpYVV+YeYpTmYFES57Uz PhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbGw/86p/Xe1+2efluXo+vnht2DT78/x0qwx lkue+Ee6WWRXV501cO4/pG8v//vdrvzy0/8NYlcx8V7oc2gvlNyekHgiQnS1atcqJT6Zbxp7 RF5cydgsnuQhMHX942c2pxQPaMRsPZvJXbc3gyPy+S3Gi3NFHJ2cZK+/Dl0XJBF+5zv753rL O0osxRmJhlrMRcWJABqy0jofAgAA Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:23:23 -0000 Hi WG, I have done an update that attempts to address the issues raised in IETF last call by the reviewers. This may fall a bit short of the ideal. But, I am not a native English speaker, and have not therefore really given it all the editorial love that Sarah Banks requested. What is important is that the document has improved in consistency of the sections in the comparisons. Which means that some substantial new blobs of text has been created. I request that you review these and send some feedback on them. Cheers Magnus internet-drafts@ietf.org skrev den 2015-04-20 15:18: > > 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 : The Comparison of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) > Authors : Magnus Westerlund > Thomas Zeng > Filename : draft-ietf-mmusic-rtsp-nat-evaluation-15.txt > Pages : 44 > Date : 2015-04-20 > > Abstract: > This document describes several Network Address Translator (NAT) > traversal techniques that were considered to be used for establishing > the RTP media flows controlled by the Real-time Streaming Protocol > (RTSP). Each technique includes a description of how it would be > used, the security implications of using it and any other deployment > considerations it has. There are also discussions on how NAT > traversal techniques relate to firewalls and how each technique can > be applied in different use cases. These findings were used when > selecting the NAT traversal for RTSP 2.0, which is specified in a > separate document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-15 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-15 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Apr 20 06:44:01 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A721B2B8E; Mon, 20 Apr 2015 06:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLLVKjJDaMJV; Mon, 20 Apr 2015 06:43:48 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D091B2B97; Mon, 20 Apr 2015 06:43:47 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-61-553502910015 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 13.42.28835.19205355; Mon, 20 Apr 2015 15:43:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.210.2; Mon, 20 Apr 2015 15:43:42 +0200 Message-ID: <5535028E.6090502@ericsson.com> Date: Mon, 20 Apr 2015 15:43:42 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Black, David" , "thomas.zeng@gmail.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" References: <8D3D17ACE214DC429325B2B98F3AE712076FF268CF@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FF268CF@MX15A.corp.emc.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje5EJtNQg4W75Sy2Hl7LbnH11WcW i2cb57NYTF3+mMWit2kJs0Xjzs/sDmweR47MZvHYOesuu8eSJT+ZApijuGxSUnMyy1KL9O0S uDIOHVzBVNDlWPHv3mLWBsbjxl2MnBwSAiYSO+9dYYawxSQu3FvP1sXIxSEkcJRRon3LLVYI ZzmjxLbVv9lBqngFtCXO9j0Ds1kEVCVub5jNBmKzCVhI3PzRCGaLCkRJTPx6iAWiXlDi5Mwn LCCDRASOMUoc37+FCSTBLOAhserHS6AGDg5hgWCJLdtDQUwhAW+JFz21IBWcAj4SP941sUBU G0gcWTSHFcKWl2jeOhvsaCGgcxqaOlgnMArOQrJtFpKWWUhaFjAyr2IULU4tLs5NNzLSSy3K TC4uzs/Ty0st2cQIDPCDW35b7WA8+NzxEKMAB6MSD+/CWJNQIdbEsuLK3EOM0hwsSuK8dsaH QoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwRlTrhq96q3dD0bpM4lHEVps3/4PNdZfMnMwr rMYVvubf4hf6/5cv/NmhvkLFmnvG7pJ1fJ+nqcjH1N6cV7LraWJQz2aF5wLpnvfD3t4KSzgu 65C/6aGuQYNrJtO6n86CH4y9Ba7MK7jZcShnv9n5T7n/rsjPTDi1fc2V5dVrfTxUUpbN/Wkd pcRSnJFoqMVcVJwIAKMLQ8dRAgAA Archived-At: Cc: "mmusic@ietf.org" , "ietf@ietf.org" Subject: Re: [MMUSIC] Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-14 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:43:52 -0000 Hi David, I have finally gotten to do the update of this document. I thank you very much as I believe the document has gotten substantially better and more consistent due to your and Sarah Banks review comments. I will say upfront that the updated version has not become a masterpiece, but it will suck a bit less. My view is that this document contains some valuable pieces of information, but it is not worth spending tons of time in editing. I have some inline response to your comments and question below. Black, David skrev den 2014-06-15 04:56: > > Document: draft-ietf-mmusic-rtsp-nat-evaluation-14 > Reviewer: David L. Black > Review Date: June 14, 2014 > IETF LC End Date: June 13, 2014 > > > Major issues: > > [1] The abstract characterizes this draft as the evaluation that lead to > the mmusic WG's choice of the NAT traversal technique for RTSP, but > the evaluation in this draft did not drive that choice, as indicated > in Section 6: > > Looking at Figure 1 one would draw the conclusion that using TCP > Tunneling or Three-Way Latching is the solutions that best fulfill > the requirements. The different techniques were discussed in the > MMUSIC WG. It was established that the WG would pursue an ICE based > solution due to its generality and capability of handling also > servers delivering media from behind NATs. > > OTOH, there appears to be a lot of useful material in this draft that > should be published in an informational RFC, not only the comparison, of > NAT traversal techniques, but also documentation of some of those > techniques, as indicated in Section 4: > > This section includes NAT traversal techniques that > have not been formally specified anywhere else. The overview section > of this document may be the only publicly available specification of > some of the NAT traversal techniques. > > This may be fairly simple to address, as the last sentence in the > abstract and the Section 6 text quoted above are the primary sources > of this issue. It may also help to change the title of this draft > from "The Evaluation of ..." to "Comparison of ..." and do something > analogous to other occurrences of the word "evaluation" in this draft. > Yes, I have attempted to do what your suggest. I think it mostly resolves the issue. > > [2] Section 4 says: > > Some other techniques have been recommended against or are no longer > possible due to standardization works' outcome or their failure to > progress within IETF after the initial evaluation in this document, > e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op]. > > That's too vague, an explicit list should be provided of techniques in > Section 4 that should not or cannot currently be used, starting with RTP > No-Op including an explanation of why that is the case for each technique. > There's also an important editorial clarification needed - these > "other techniques" are not NAT traversal techniques; they are possible > elements of some NAT traversal techniques. > > This text is 4.1.1 is part of this issue: > > The first version of STUN [RFC3489] included categorization and > parameterization of NATs. This was abandoned in the updated version > [RFC5389] due to it being unreliable and brittle. Some of the below > discussed methods are based on RFC3489 functionality which will be > called out and the downside of that will be part of the > characterization. I have attempted to be clearer in the text when methods are based on either deprecated or abandoned proposals. However, from my perspective, especially for abandoned work, if one would have wanted to pursue a mechanism based on abandoned work it could have been resurrected. Deprecated is worse as that usually have a good motivation behind its removal. > > Minor issues: > > -- Section 2, last paragraph. > [E] > Note that if neither RTCP packets nor RTSP > messages are received by the RTSP server for a while, the RTSP server > has the option to delete the corresponding RTP session, SSRC and RTSP > session ID, because either the client can not get through a middle > box NAT/firewall, or the client is mal-functioning. > > Is there any delay recommended before RTSP server reuse of that set of > identifying information (RTP session, SSRC and RTSP session ID)? No, to my knowledge there exist no such recommendation. However, the RTSP session is basically defined by the RTSP session context and the used 5-tuples. The SSRC are scoped by session, and should be randomly generated to minimize the risk of collision. RTSP session IDs needs to be generated with very low probability of collision with any recently used. > > [I] Still in Section 3 > > Note a simple preventative measure commonly > deployed is for the RTSP server to disallow the cases where the > client's RTP receiver has a different IP address than that of the > RTSP client. With the increased deployment of NAT middleboxes by > operators, i.e. carrier grade NAT (CGN), the reuse of an IP address > on the NAT's external side by many customers reduces the protection > provided. Also in some applications (e.g., centralized > conferencing), dual-hosted RTSP/RTP clients have valid use cases. > The key is how to authenticate the messages exchanged during the NAT > traversal process. > > Is that "measure commonly deployed" recommended? The above text chunk > feels like Security Considerations text, and this text could usefully > be moved to Section 8. In RTSP 2.0 this is well documented and recommended practice. See Section 21.2.2 in https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > > [J] Section 4.1.1 relies on STUN's abandoned NAT type classification > functionality to determine where to send the hole-punching UDP packets. > What's wrong with always sending those packets to the "server's source > address/port"? That should work for both types of NATs, thereby removing > the dependency on STUN classification of NAT types. Actually that is not the main reason. The difference between 4.1 Stand-alone STUN and 4.2 Embedded STUN is where the STUN server is. In 4.2 the STUN server is sharing the server port, thus taking care of handling the STUN requests and sending respone. For 4.1 the server can be either on its own IP or share IP but have a different port compared to the RTSP server. The classification method is basically to detect cases where the method would fail, prior to really attempting them. One could skip the classification and instead fail during SETUP. But that will result in the server starting to send media, which will not be delivered to the client. This late failure I think is desirable to avoid. But, this has been clarified: The first version of STUN [RFC3489] included categorization and parameterization of NATs. This was abandoned in the updated version [RFC5389] due to it being unreliable and brittle. This particular traversal method uses the removed RFC3489 functionality to detect the NAT type to give an early failure indication when the NAT is showing the behavior that this method can't support. This method also suggest using the RTP NO-OP payload format [I-D.ietf-avt-rtp-no-op] for key-alives of the RTP traffic in the client to server direction. This can be replaced with another form of UDP packet as will be further discussed below. > > [K] Why are ALG considerations only applicable to STUN-based techniques? They are applicable to all cases. I have corrected this in this version. In most cases the main finding about ALGs was listed in the Deployment considerations. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Apr 21 02:31:38 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647DE1A1B79 for ; Tue, 21 Apr 2015 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01nmmNdSCq3x for ; Tue, 21 Apr 2015 02:31:34 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5BB1A0068 for ; Tue, 21 Apr 2015 02:31:34 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-22-553618f4b563 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.72.28347.4F816355; Tue, 21 Apr 2015 11:31:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Apr 2015 11:31:32 +0200 Message-ID: <553618F3.1050109@ericsson.com> Date: Tue, 21 Apr 2015 11:31:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Harald Alvestrand , Martin Thomson References: <5517AAE4.5070800@alvestrand.no> <551A63D2.1030006@ericsson.com> <552E6A92.4020801@alvestrand.no> In-Reply-To: <552E6A92.4020801@alvestrand.no> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvje4XCbNQg0VH1C2O9XWxWVw784/R YuryxywOzB5XJlxh9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4MtrmbGYueKJY8fXjJ6YG xtlSXYycHBICJhI/m08yQthiEhfurWfrYuTiEBI4yihx9uQ5FghnOaNE+5fvYFW8AtoSDe13 mEBsFgFViTezz4HF2QQsJG7+aGQDsUUFoiQmfj3EAlEvKHFy5hMwW0QgUmLtwnfsXYwcHMwC 6hJXFweBhIUFtCQm9U6F2rWHSaJ7wWJ2kASngK7En6tzWCHqNSXW79IHCTMLyEs0b53NDGIL gZzT1ME6gVFwFpJtsxA6ZiHpWMDIvIpRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMIAPbvlt sIPx5XPHQ4wCHIxKPLwK601DhVgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAOOFwsl4vs3Y2h1fpLSMuvVO6lhOO7VT8+X/5K3XjvbsU6zIen56aGHdAJDzJ cHeH+M/2PUl8nYvFSkPmcv+QaGX4UvWG93lBl4SLDPfuz4osVv9lvn9aKLTMPOXbrgPv65aX fzyZtrJgThDL92h77oa1DQ7P6ntzUr4LPOMp3auVvi/LWvK5EktxRqKhFnNRcSIAl40vRUEC AAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remove msid-semantic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 09:31:36 -0000 Hi Harald, Harald Alvestrand skrev den 2015-04-15 15:41: > OK, here is how the section on handing unsignalled tracks looks when > I've removed msid-semantic. > > Note that depending on exactly how we do early media, this may cause > trouble in delivering it. > > 3.1. Handling of non-signalled tracks > > Entities that do not use msid will not send msid. This means that > there will be some incoming RTP packets that the recipient has no > predefined MediaStream id value for. > > Note that this handling is triggered by incoming RTP packets, not by > SDP negotiation. > > When MSID is used, the only time this can happen is when, at a time > subsequent to the initial negotiation, a negotiation is performed > where the answerer adds a MediaStreamTrack to an already established > connection and starts sending data before the answer is received by > the offerer. For initial negotiation, packets won't flow until the > ICE candidates and fingerprints have been exchanged, so this is not > an issue. > > The recipient of those packets will perform the following steps: > > o When RTP packets are initially received, it will create an > appropriate MediaStreamTrack based on the type of the media > (carried in PayloadType), and use the mid RTP attribute (if > present) to associate the RTP packets with a specific media > section. If the connection is not in the RTCSignalingState > "stable", it will wait at this point. > > o When the connection is in the RTCSignalingState "stable", it will > look at the relevant media section to find the msid attribute. > > o If there is an msid attribute, it will use that attribute to > populate the "id" field of the MediaStreamTrack and associated > MediaStreams, as described above. > > o If there is no msid attribute, the identifier of the > MediaStreamTrack will be set to a randomly generated string, and > it will be signalled as being part of a MediaStream with the > WebIDL "label" attribute set to "Non-WebRTC stream". > > o After deciding on the "id" field to be applied to the > MediaStreamTrack, the track will be signalled to the user. > > The process above may involve a considerable amount of buffering > before the stable state is entered, If the implementation wishes to > limit this buffering, it MUST send a "mediadiscarded" event to the > user, as described in [????]. I think there are two aspects of the buffering here that may need a bit more discussion. So one buffers to ensure that one have a good media encoding entry point. However, in most cases one can't really play out all the buffered media, unless one can play it at faster than real-time. Video fairly simple, audio a bit trickier, especially if one likes to catch up quickly with the minimal delay point. Thus, one either miss media or may end up with a significant time delay that take time to drain. Catching up is also resource demanding as one must be able to decode faster than real-time. Based on this, I wonder if you there need to be clearer recommendations what to do. For example if I discard up until the last receiver media entry point available, should I then send mediadiscarded event? Is the application happier if I play from start and then spend 15 seconds catching up? How do we know which behaviour an application prefer here? Maybe the issue and possible strategies should be highlighted, and further note that application may want to ensure that signalling has concluded before sending media. I am not happy to have to go into detail here, but it also looks like this will be one pile of inconsistent behaviour between implementations. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Apr 21 04:14:57 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6241A9171; Tue, 21 Apr 2015 04:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL_zQCiJPT8T; Tue, 21 Apr 2015 04:14:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2901A9238; Tue, 21 Apr 2015 04:14:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150421111454.32078.44420.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 04:14:54 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 11:14:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-09.txt Pages : 15 Date : 2015-04-21 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-msid-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 21 04:17:12 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD17F1A9234 for ; Tue, 21 Apr 2015 04:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES9cVBJ88ss6 for ; Tue, 21 Apr 2015 04:17:08 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6A31A9233 for ; Tue, 21 Apr 2015 04:17:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A93DE7C3B25 for ; Tue, 21 Apr 2015 13:17:07 +0200 (CEST) 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 NPphGIhLjB25 for ; Tue, 21 Apr 2015 13:17:05 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7E86E7C3B17 for ; Tue, 21 Apr 2015 13:17:05 +0200 (CEST) Message-ID: <553631B1.1050704@alvestrand.no> Date: Tue, 21 Apr 2015 13:17:05 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "mmusic@ietf.org" References: <20150421111454.32078.56417.idtracker@ietfa.amsl.com> In-Reply-To: <20150421111454.32078.56417.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150421111454.32078.56417.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] MSID draft -09 posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 11:17:11 -0000 See below - this implements the decision from Dallas to turn MSID into a single mechanism rather than a generic framework for creating new mechanisms. This saved ~2 pages; there are sure to be inconsistencies, but the core job is done. Happy reading! Harald -------- Videresendt melding -------- Emne: New Version Notification for draft-ietf-mmusic-msid-09.txt Dato: Tue, 21 Apr 2015 04:14:54 -0700 Fra: internet-drafts@ietf.org Til: Harald T. Alvestrand , Harald Alvestrand A new version of I-D, draft-ietf-mmusic-msid-09.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Name: draft-ietf-mmusic-msid Revision: 09 Title: WebRTC MediaStream Identification in the Session Description Protocol Document date: 2015-04-21 Group: mmusic Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ Htmlized: http://tools.ietf.org/html/draft-ietf-mmusic-msid-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-09 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Apr 21 09:26:03 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB641AD0BD for ; Tue, 21 Apr 2015 09:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=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 So9pUz-ap0ha for ; Tue, 21 Apr 2015 09:25:57 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF29D1AD0BE for ; Tue, 21 Apr 2015 09:25:57 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-02v.sys.comcast.net with comcast id JgRg1q0032EPM3101gRwkL; Tue, 21 Apr 2015 16:25:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-07v.sys.comcast.net with comcast id JgRw1q00S3Ge9ey01gRwiR; Tue, 21 Apr 2015 16:25:56 +0000 Message-ID: <55367A13.2060703@alum.mit.edu> Date: Tue, 21 Apr 2015 12:25:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20150421111454.32078.56417.idtracker@ietfa.amsl.com> <553631B1.1050704@alvestrand.no> In-Reply-To: <553631B1.1050704@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429633556; bh=0iG/GymwS4Er1R3E5ctSALrBHJiZ7pHad8ZCQKZdfL0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GZhsbUjMVh6j6AkIiQLGajb9+99NtNO28pz8L++AQJ73oCDSFD/OE/2NpcQLj83Cn mvMguK4lBIbGMG9LUqvSEyIXkrRC/pfROBvOLGet1x25XaH5kge7W77rsLmhUS+ONF HuQ4KElaTIz0smqowbl0LFSFvapTwIN2N2eYijgdNlnilsRe387gWEvl5W6gRnjmXm a2taEa1KVOD5yWvlx2jSu61HwcwqAyPEsfxsxjV7ebwH767vjPTgZ0FP/jFop9Nta8 7bk1PtZBS6ed5MxK7NPMjEtKnMAmDxG24J6U4S8xdwKZhjkF9C6Qs7eEfVU5UEZKUI aoEFyPd6D562A== Archived-At: Subject: Re: [MMUSIC] MSID draft -09 posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 16:25:59 -0000 This draft is a lot simpler to review with its reduced scope! I have a few comments: * Section 2: ... This new attribute allows endpoints to associate RTP media streams that are carried in *the same or* different media descriptions. ... How do you associate distinct MSIDs to media streams in *the same* media description??? AFAIK that isn't possible - each media description is a distinct media stream. * Section 3: The semantic token for this semantic is "WMS" (short for WebRTC Media Stream). The above seems to be a leftover that should be removed. IMO the following is very confusing in its use of "description". I've highlighted the points at issue with *s: The following are the rules for handling updates of the list of *media descriptions* and their msid values. o When a new msid "identifier" value occurs in *the* description the recipient can signal to its application that a new MediaStream has been added. o When *a description* is updated to have more media descriptions with the same msid "identifier" value, but different "appdata" values, the recipient can signal to its application that new MediaStreamTracks have been added to the MediaStream. o When *a description* is updated to no longer list any msid values, on a specific media description, the recipient can signal to its application that the corresponding MediaStreamTrack has ended. I *think* that in some cases you mean *session description* (the whole SDP), and in other cases you mean *media description* (m-line and the associated following non-m-lines.) Perhaps: The following are the rules for handling updates of the list of media descriptions and their msid values. o When a new msid "identifier" value occurs in a media description, the recipient can signal to its application that a new MediaStream has been added. o When a session description is updated to have more media descriptions with the same msid "identifier" value, but different "appdata" values, the recipient can signal to its application that new MediaStreamTracks have been added to the MediaStream. o When a session description is updated to no longer list any msid attribute on a specific media description, the recipient can signal to its application that the corresponding MediaStreamTrack has ended. * Section 3.2.2: For each media description in the offer, and for each "a=msid" attribute in the media description where the "msid-id" is associated with the "WMS" semantic, the receiver of the offer will perform the following steps: In the above, there is still reference to WMS semantic that should be removed. Also, this again implies that there might be multiple a=msid lines in a single media description. How about: For each media description in the offer that contains an "a=msid" attribute, the receiver of the offer will perform the following steps: Thanks, Paul On 4/21/15 7:17 AM, Harald Alvestrand wrote: > See below - this implements the decision from Dallas to turn MSID into a > single mechanism rather than a generic framework for creating new > mechanisms. > > This saved ~2 pages; there are sure to be inconsistencies, but the core > job is done. > Happy reading! > > Harald > > > -------- Videresendt melding -------- > Emne: New Version Notification for draft-ietf-mmusic-msid-09.txt > Dato: Tue, 21 Apr 2015 04:14:54 -0700 > Fra: internet-drafts@ietf.org > Til: Harald T. Alvestrand , Harald Alvestrand > > > > A new version of I-D, draft-ietf-mmusic-msid-09.txt > has been successfully submitted by Harald Alvestrand and posted to the > IETF repository. > > Name: draft-ietf-mmusic-msid > Revision: 09 > Title: WebRTC MediaStream Identification in the Session Description > Protocol > Document date: 2015-04-21 > Group: mmusic > Pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-09.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ > Htmlized: http://tools.ietf.org/html/draft-ietf-mmusic-msid-09 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-09 > > Abstract: > This document specifies a Session Description Protocol (SDP) Grouping > mechanism for RTP media streams that can be used to specify relations > between media streams. > > This mechanism is used to signal the association between the SDP > concept of "media description" and the WebRTC concept of > "MediaStream" / "MediaStreamTrack" using SDP signaling. > > This document is a work item of the MMUSIC WG, whose discussion list > is mmusic@ietf.org. > > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Apr 21 10:05:51 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60901B29BF for ; Tue, 21 Apr 2015 10:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuuI4FcymMNK for ; Tue, 21 Apr 2015 10:05:49 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536FD1A00ED for ; Tue, 21 Apr 2015 10:05:37 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so89288886igb.0 for ; Tue, 21 Apr 2015 10:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XjhIsJLIN9aQ+OM2+uHrmfqchjeId4M8JmYcmsl11kk=; b=CLalnrsMF0dSb4atxu5iGUMZQgXHyHI+6dkrw8IGwBuhzbzF0hMKd0DgrXK1RPLtrH rngcifS8ZYlsckAk7GzHZkHhjQEcwsMdQGzIA47WikKgD9jYahy+flMuyduiPNbsT/Io /Ds5eEADr/lvr8Ve6eG8FFN4yz2zYnNtZNKOwS2s4s+8JoVNhvbCRBgS2/u8jrjNVfqq Ukn1IeN66dUeGXOrmoxe5HLAAUYmuURrwR0nSGJ0pAVU2OEW9/eM5EE8fDen9ta69ZPt q9Hvr3oIr1hHc5TeMRaBCutHUBc4PryCKW6Z9oGZrJ/WGekW7ZlOt5bwJfVoGIqn2eqH 0+uw== MIME-Version: 1.0 X-Received: by 10.107.170.135 with SMTP id g7mr30918469ioj.2.1429635937212; Tue, 21 Apr 2015 10:05:37 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Tue, 21 Apr 2015 10:05:37 -0700 (PDT) In-Reply-To: <553618F3.1050109@ericsson.com> References: <5517AAE4.5070800@alvestrand.no> <551A63D2.1030006@ericsson.com> <552E6A92.4020801@alvestrand.no> <553618F3.1050109@ericsson.com> Date: Tue, 21 Apr 2015 10:05:37 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remove msid-semantic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 17:05:50 -0000 On 21 April 2015 at 02:31, Magnus Westerlund wrote: > However, in most cases one can't really play out > all the buffered media, unless one can play it at faster than real-time. I never imagined buffering being any more than a few milliseconds or tens of milliseconds. That might just be a case of allowing the audio jitter buffer to fill. From nobody Wed Apr 22 05:15:22 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02501A92B8 for ; Wed, 22 Apr 2015 05:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY8dFSJxyc02 for ; Wed, 22 Apr 2015 05:15:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BB91B3519 for ; Wed, 22 Apr 2015 05:15:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-49-553790d309d0 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.BF.28835.3D097355; Wed, 22 Apr 2015 14:15:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.210.2; Wed, 22 Apr 2015 14:15:14 +0200 Message-ID: <553790D2.5050203@ericsson.com> Date: Wed, 22 Apr 2015 14:15:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Thomson References: <5517AAE4.5070800@alvestrand.no> <551A63D2.1030006@ericsson.com> <552E6A92.4020801@alvestrand.no> <553618F3.1050109@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvje7lCeahBlNOS1kc6+tis7h25h+j xdTlj1kcmD2uTLjC6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZXT/bGEtaOCpuHT7CXMD 4z3OLkZODgkBE4nTV7+xQ9hiEhfurWcDsYUEjjJK/Lnl38XIBWQvZ5S4dn4PE0iCV0BbYuf3 CWA2i4CqxIYFjWA2m4CFxM0fjWDNogJREhO/HmKBqBeUODnzCZgtIqArsejsA7BlzALBEtce 3APrFRbQkpjUO5UFYtlCZonj9/6CJTgFAiUW97xm7GLkAGrQlFi/Sx+iV16ieetsZohDtSUa mjpYJzAKzkKybhZCxywkHQsYmVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBAbwwS2/rXYw HnzueIhRgINRiYf3gYV5qBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGDdGLd2aF7562ukjC11bg6u/6Yo9mTDF0oDh3q84r21ib0UMKhujvtnYxayJSNy7 OWRreimrV7T1xPKKDcdcDz8yZVjoNGnDyYTf6SXpYX67wvNV6hzvrXF9nbF5RlX3a7mZh+Y9 EfvJlbH2/anww0XrL1c13cz5YxSyPlVfvUBmbvO3+1rT5yixFGckGmoxFxUnAgAjZBFnQQIA AA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remove msid-semantic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 12:15:21 -0000 Martin Thomson skrev den 2015-04-21 19:05: > On 21 April 2015 at 02:31, Magnus Westerlund > wrote: >> However, in most cases one can't really play out >> all the buffered media, unless one can play it at faster than real-time. > > > I never imagined buffering being any more than a few milliseconds or > tens of milliseconds. That might just be a case of allowing the audio > jitter buffer to fill. > Well, that is fine for audio codecs which can generate good quality audio from any frame. But, for a video codec with its dependency on intra frames, then not buffering, in case the signalling arrives after the media, then discarding just the first packet will result in quality degradation or extra delay. The actual situation will be the same as a packet loss situation (without possibility to repair) and recovery form it, most likely through a FIR request. To be clear this only occurs in the situation where the signalling for a new track arrives after the actual delivery. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Apr 22 05:29:15 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BFD1B355F for ; Wed, 22 Apr 2015 05:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qdSp8-_POiX for ; Wed, 22 Apr 2015 05:29:06 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id ADBDB1B355C for ; Wed, 22 Apr 2015 05:29:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 752E77C3D90; Wed, 22 Apr 2015 14:29:05 +0200 (CEST) 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 aJpF9KDlhrg9; Wed, 22 Apr 2015 14:29:04 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 387607C3D81; Wed, 22 Apr 2015 14:29:04 +0200 (CEST) Message-ID: <5537940F.7070401@alvestrand.no> Date: Wed, 22 Apr 2015 14:29:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Magnus Westerlund , Martin Thomson References: <5517AAE4.5070800@alvestrand.no> <551A63D2.1030006@ericsson.com> <552E6A92.4020801@alvestrand.no> <553618F3.1050109@ericsson.com> <553790D2.5050203@ericsson.com> In-Reply-To: <553790D2.5050203@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remove msid-semantic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 12:29:14 -0000 Den 22. april 2015 14:15, skrev Magnus Westerlund: > Martin Thomson skrev den 2015-04-21 19:05: >> On 21 April 2015 at 02:31, Magnus Westerlund >> wrote: >>> However, in most cases one can't really play out >>> all the buffered media, unless one can play it at faster than real-time. >> >> >> I never imagined buffering being any more than a few milliseconds or >> tens of milliseconds. That might just be a case of allowing the audio >> jitter buffer to fill. >> > > Well, that is fine for audio codecs which can generate good quality > audio from any frame. But, for a video codec with its dependency on > intra frames, then not buffering, in case the signalling arrives after > the media, then discarding just the first packet will result in quality > degradation or extra delay. The actual situation will be the same as a > packet loss situation (without possibility to repair) and recovery form > it, most likely through a FIR request. > > To be clear this only occurs in the situation where the signalling for a > new track arrives after the actual delivery. There's some simplification possible ... if the codec uses some variant of pyramid encoding, where not all frames are required in order to preserve the reference chain, all frames that aren't depended on can be thrown away until the decision to show or not show can be made. When the decision to show is made, just the frames required to have a proper reference for the next incoming frame need to be encoded. Probably increases reasonable hold times from milliseconds to seconds, but not to minutes..... From nobody Wed Apr 22 10:13:18 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51F1B3885 for ; Wed, 22 Apr 2015 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdZflaHmuwba for ; Wed, 22 Apr 2015 10:13:16 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BC11B3883 for ; Wed, 22 Apr 2015 10:13:03 -0700 (PDT) Received: by yhw29 with SMTP id 29so4056098yhw.1 for ; Wed, 22 Apr 2015 10:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vCdP+gK82P7JK/Hr3vsVVZwRI2CvuI/m1ABV0xui3OQ=; b=K1P3B0ROh2lejUTAkTrSBAcguepa65IA/Ba2hDH5Z3QS8xKNo5LKtz0/wM5o92bMq+ BacvCO2qg+B3BTJQvATk1K/G5FvfQXy1vXApaMQa1POLZB9KrGJpasFh2LEeqv2mxDOO hsLT16UIiYzrNGmOe6K0kIXUSs6GV8ulXbLPY+9ansjbMTJq9GU2nQo4BKkWePW/9y3M QYN0PFOnrLMG8OZMyttSvqjCm3ZXnc5IcCNqWiPwr6YsLXD04d/fA+0tiojNfJSUxZBz KAE1gzZI1e88LfEdWR1RN3j+EiIo0DVoUpEJu7qazHtoeA1jAWzsWpPQl3NZ7ELEVTHk ZqIw== MIME-Version: 1.0 X-Received: by 10.236.208.36 with SMTP id p24mr22282891yho.1.1429722782457; Wed, 22 Apr 2015 10:13:02 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Wed, 22 Apr 2015 10:13:02 -0700 (PDT) In-Reply-To: <5537940F.7070401@alvestrand.no> References: <5517AAE4.5070800@alvestrand.no> <551A63D2.1030006@ericsson.com> <552E6A92.4020801@alvestrand.no> <553618F3.1050109@ericsson.com> <553790D2.5050203@ericsson.com> <5537940F.7070401@alvestrand.no> Date: Wed, 22 Apr 2015 10:13:02 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" Subject: Re: [MMUSIC] Remove msid-semantic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:13:17 -0000 On 22 April 2015 at 05:29, Harald Alvestrand wrote: > There's some simplification possible ... if the codec uses some variant > of pyramid encoding, where not all frames are required in order to > preserve the reference chain, all frames that aren't depended on can be > thrown away until the decision to show or not show can be made. When the > decision to show is made, just the frames required to have a proper > reference for the next incoming frame need to be encoded. > > Probably increases reasonable hold times from milliseconds to seconds, > but not to minutes..... Yep, if you can decode properly, holding the iframe - or a functional equivalent - could make the hold time indefinite. From nobody Wed Apr 22 18:26:46 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314E01A9004 for ; Wed, 22 Apr 2015 18:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFAA-hWm8kV6 for ; Wed, 22 Apr 2015 18:26:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810E71B2CAE for ; Wed, 22 Apr 2015 18:26:42 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-d4-55384a501dd7 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.4F.19337.05A48355; Thu, 23 Apr 2015 03:26:41 +0200 (CEST) Received: from aris-mbp-2.dyn.sj.us.am.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Thu, 23 Apr 2015 03:26:40 +0200 Message-ID: <55384A4E.2080006@ericsson.com> Date: Wed, 22 Apr 2015 18:26:38 -0700 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3RjfQyyLU4PVDPov3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZaxYUVCwhKniz9wLjA2Mzxm7GDk5JARMJE41 v2OBsMUkLtxbz9bFyMUhJHCUUeLIoyWsEM5+Roljs1uZQKp4BbQlfrb8BLI5OFgEVCXerNQG CbMJ2EqsfnUTbJCoQLLEkqYeZohyQYmTM5+AxUUEZCT2btoMFmcGGjP7ziywkcICRhKTV2xn hIhbSMycfx7KlpfY/nYOWL0Q0Kqr/14xTmDkn4Vk7CwkLbOQtCxgZF7FKFqcWpyUm25krJda lJlcXJyfp5eXWrKJERh6B7f8Vt3BePmN4yFGAQ5GJR7eBxbmoUKsiWXFlbmHGKU5WJTEee2M D4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCyOSA/+v+mLLTOXyJcV8Y9nFk39N8PVNJD/ 8vxHl2Ri+z+L3Xg99e/138s7ls2urdp1/OxrG/U88bLafr+K6cfVKuryj+5q7j+dI6lfc76Y NefR92034u8qGfFmJ8abvJLU8TTZdr/s33avPftWXb3EIPrdT6Vz2UnNi0apF2XsFpb3N4hl eiixFGckGmoxFxUnAgDki52xHgIAAA== Archived-At: Cc: Flemming Andreasen Subject: [MMUSIC] Draft MMUSIC Meeting Minutes from IETF 92 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 01:26:45 -0000 Hi all, The draft meeting minutes for the two MMUSIC sessions at IETF 92 are available here: http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic Please take a look and let us know if you have any questions or comments. Thanks, Ari & Flemming (MMUSIC co-chairs) From nobody Thu Apr 23 02:36:39 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A724F1A9046 for ; Thu, 23 Apr 2015 02:36:38 -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 4NoeWhC5iTKa for ; Thu, 23 Apr 2015 02:36:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 354581A9056 for ; Thu, 23 Apr 2015 02:36:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3BE897C3E94; Thu, 23 Apr 2015 11:36:32 +0200 (CEST) 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 kKbqV99MoSdE; Thu, 23 Apr 2015 11:36:31 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 31A847C3E4F; Thu, 23 Apr 2015 11:36:31 +0200 (CEST) Message-ID: <5538BD1E.1020405@alvestrand.no> Date: Thu, 23 Apr 2015 11:36:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Thomson , Magnus Westerlund References: <5517AAE4.5070800@alvestrand.no> <551A63D2.1030006@ericsson.com> <552E6A92.4020801@alvestrand.no> <553618F3.1050109@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Remove msid-semantic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 09:36:38 -0000 Den 21. april 2015 19:05, skrev Martin Thomson: > On 21 April 2015 at 02:31, Magnus Westerlund > wrote: >> However, in most cases one can't really play out >> all the buffered media, unless one can play it at faster than real-time. > > > I never imagined buffering being any more than a few milliseconds or > tens of milliseconds. That might just be a case of allowing the audio > jitter buffer to fill. > The inter-frame time of 30 fps video is 33 ms, so if you buffer 3 frames, you have 100 ms. We're always in a hurry, but not THAT much of a hurry.... From nobody Thu Apr 23 05:50:19 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222A41A90FA for ; Thu, 23 Apr 2015 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt7FUJFG3J1a for ; Thu, 23 Apr 2015 05:50:15 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 99FF31A9074 for ; Thu, 23 Apr 2015 05:49:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 714B17C3FCD for ; Thu, 23 Apr 2015 14:49:53 +0200 (CEST) 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 8Fztja87BbaC for ; Thu, 23 Apr 2015 14:49:52 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0B5837C3FC3 for ; Thu, 23 Apr 2015 14:49:52 +0200 (CEST) Message-ID: <5538EA6F.3090106@alvestrand.no> Date: Thu, 23 Apr 2015 14:49:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20150421111454.32078.56417.idtracker@ietfa.amsl.com> <553631B1.1050704@alvestrand.no> <55367A13.2060703@alum.mit.edu> In-Reply-To: <55367A13.2060703@alum.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] MSID draft -09 posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 12:50:18 -0000 Den 21. april 2015 18:25, skrev Paul Kyzivat: > This draft is a lot simpler to review with its reduced scope! Thanks for the quick review! > > I have a few comments: > > * Section 2: > > ... This new attribute allows endpoints to associate RTP > media streams that are carried in *the same or* different media > descriptions. ... > > How do you associate distinct MSIDs to media streams in *the same* media > description??? AFAIK that isn't possible - each media description is a > distinct media stream. Yes, this is a leftover from "plan b". Deleting. Also, it should be "described", not "carried" - they're carried in RTP sessions, and described in media descriptions. > > * Section 3: > > The semantic token for this semantic is "WMS" (short for WebRTC Media > Stream). > > The above seems to be a leftover that should be removed. Yep. > > IMO the following is very confusing in its use of "description". I've > highlighted the points at issue with *s: This is a result of the wholesale replacement of "m-line" with "media description" - the meanings are unchanged, but it's a bit more obvious where the grammar is convoluted. > > The following are the rules for handling updates of the list of > *media descriptions* and their msid values. > > o When a new msid "identifier" value occurs in *the* description the > recipient can signal to its application that a new MediaStream has > been added. > > o When *a description* is updated to have more media descriptions > with the same msid "identifier" value, but different "appdata" > values, the recipient can signal to its application that new > MediaStreamTracks have been added to the MediaStream. > > o When *a description* is updated to no longer list any msid > values, on a specific media description, the recipient can signal > to its application that the corresponding MediaStreamTrack has > ended. > > I *think* that in some cases you mean *session description* (the whole > SDP), and in other cases you mean *media description* (m-line and the > associated following non-m-lines.) Perhaps: > > The following are the rules for handling updates of the list of media > descriptions and their msid values. > > o When a new msid "identifier" value occurs in a media description, > the recipient can signal to its application that a new > MediaStream has been added. > > o When a session description is updated to have more media > descriptions with the same msid "identifier" value, but different > "appdata" values, the recipient can signal to its application > that new MediaStreamTracks have been added to the MediaStream. > > o When a session description is updated to no longer list any msid > attribute on a specific media description, the recipient can > signal to its application that the corresponding MediaStreamTrack > has ended. Seems much better, I adapted some more - the use of standalone "description" was a bad idea, and I think I've fixed that. > > * Section 3.2.2: > > For each media description in the offer, and for each "a=msid" > attribute in the media description where the "msid-id" is associated > with the "WMS" semantic, the receiver of the offer will perform the > following steps: > > In the above, there is still reference to WMS semantic that should be > removed. Removed! > > Also, this again implies that there might be multiple a=msid lines in a > single media description. How about: > > For each media description in the offer that contains an "a=msid" > attribute, the receiver of the offer will perform the following > steps: Actually this is intended to allow for one track being part of multiple MediaStreams. If we have: m=video a=msid stream1 track1 a=msid stream2 track1 this would say "track1 is only sent once, but it appears as part of two MediaStreams". The API for PeerConnection still allows that. So I need to allow it here too. I put up the changes I made here: https://github.com/alvestrand/rtcweb-msid/pull/4 Will leave them up there for a day or two, and submit a -10 if there aren't further comments. Thanks again! Harald From nobody Mon Apr 27 02:49:29 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1210E1B2F95 for ; Mon, 27 Apr 2015 02:49:18 -0700 (PDT) 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 sSaEqaFt8Yjj for ; Mon, 27 Apr 2015 02:49:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB761B2FA8 for ; Mon, 27 Apr 2015 02:48:51 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-ae-553e060167d5 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.1E.28096.1060E355; Mon, 27 Apr 2015 11:48:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Mon, 27 Apr 2015 11:48:48 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" , "adam@nostrum.com" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments Thread-Index: AdB48sRiP9lfe1IKQ6C6VGl4ysyW2AAEi9eAAAbPvjEAAoTd8AAAS6MgADQDfoABtOccQA== Date: Mon, 27 Apr 2015 09:48:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7D9053@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D79F956@ESESSMB209.ericsson.se>, <55311011.9090908@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D79FC5A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D79FDA0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D79FE66@ESESSMB209.ericsson.se> <5532ADB9.5020907@alum.mit.edu> In-Reply-To: <5532ADB9.5020907@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjS4jm12owbbLahZ7/i5it5i6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZUw8PIul4JFWxZIZV5ga GA8qdTFyckgImEhs2byUCcIWk7hwbz1bFyMXh5DAUUaJHwd+s0I4ixkl9v58z9LFyMHBJmAh 0f1PG6RBRKBMYtqT32wgtrBAhsTN7W8ZIeKZEpefzGGCsMMknu3qYgexWQRUJRrf7QSL8wr4 Shz5fZEdYv59JoltK/+AJTgFdCRmvZ8PZjMCXfT91Bowm1lAXOLWk/lQlwpILNlznhnCFpV4 +fgfK4StKNH+tIERot5A4tz2jewQtrbEsoWvmSEWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYF jCyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKj5+CW31Y7GA8+dzzEKMDBqMTDqzjDNlSI NbGsuDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzLnm4v2eIW+bj4 XuSfJyp9iTwOz5V+bPDce1bwcqPQEr5j/np1CsrMAs2ylpmf63etMuvQf2D5bMf3a5WaJy4u ePxCROvW6j3PkrSWtk2e/c1kqsB1vS8Xlf79Xq03Z2/epq9n5DadufVahKXVIT9jxQdz/+ep HHm35pUoSd3f5lInv4v3MfMeJZbijERDLeai4kQAIqvzdH8CAAA= Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 09:49:18 -0000 Adam, do you have any comments on this? Otherwise I will not do any technic= al changes. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 18. huhtikuuta 2015 22:17 To: Christer Holmberg; mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 = - Adam's technical comments On 4/17/15 12:29 PM, Christer Holmberg wrote: > More about this: > > If the answerer rejects the =93m=3D=94 line, it won=92t (at least not=20 > currently) even be part of the BUNDLE group. So, how will the offerer=20 > know which port has been selected as the offerer BUNDLE port? Another related problem: Consider Adam's example: > a=3Dgroup:BUNDLE foo bar > m=3Dvideo 20002 RTP/AVP 97 > a=3Drtpmap:97 H261/90000 > a=3Dmid:foo > m=3Dvideo 0 RTP/AVP 97 98 > a=3Drtpmap:97 H261/90000 > a=3Drtpmap:98 VP8/90000 > a=3Dbundle-only > a=3Dmid:bar Suppose, instead of rejecting foo, the answerer wants to accept it, but doe= sn't want it to be part of the bundle. Yet it still wants to accept bar as = part of the bundle? That of course makes little sense, since without foo there is no bundle. But I think the same is true for Adam's case. So I think this is a "problem= " that doesn't need fixing. Thanks, Paul > Regards, > > Christer > > *From:*Christer Holmberg > *Sent:* 17 April 2015 19:22 > *To:* Christer Holmberg; Paul Kyzivat; mmusic@ietf.org > *Subject:* RE: [MMUSIC] WGLC for > draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical=20 > comments > > Hi, > > One issue related to this: if the answerer rejects the m- line, by=20 > setting the port value to zero, how will it provide the port value=20 > associated with the answerer BUNDLE address? > > The answerer BUNDLE port will of course be assigned to the other =93m=3D= =94 > lines within the BUNDLE group, but the port value associated with the=20 > answerer BUNDLE tag will be zero. > > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer=20 > Holmberg > *Sent:* 17 April 2015 18:07 > *To:* Paul Kyzivat; mmusic@ietf.org > *Subject:* Re: [MMUSIC] WGLC for > draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical=20 > comments > > Hi Paul, > > Correct, it would also apply to the address. > > Regards, > > Christer > > > > Sent from my Windows Phone > > ---------------------------------------------------------------------- > -- > > *From: *Paul Kyzivat > *Sent: *=FD17/=FD04/=FD2015 16:52 > *To: *mmusic@ietf.org > *Subject: *Re: [MMUSIC] WGLC for > draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical=20 > comments > > Comment at end. > > On 4/17/15 5:58 AM, Christer Holmberg wrote: >> Hi Adam, >> >> Most of your editorial comments seem ok. I'll comment them later. >> >> However, at least a couple (please let me know if you think there are mo= re non-editorial ones) of your comments was technical, and I'll focus on th= ose in this reply. >> >> --------------------------------------------------------------------- >> ------ >> >>> The procedure described in Section 8.3.2 has a rather unfortunate prope= rty that I'm not sure we want. If I were to offer something like: >>> >>> a=3Dgroup:BUNDLE foo bar >>> m=3Dvideo 20002 RTP/AVP 97 >>> a=3Drtpmap:97 H261/90000 >>> a=3Dmid:foo >>> m=3Dvideo 0 RTP/AVP 97 98 >>> a=3Drtpmap:97 H261/90000 >>> a=3Drtpmap:98 VP8/90000 >>> a=3Dbundle-only >>> a=3Dmid:bar >>> >>> And the remote endpoint wanted to reject the first stream, it would=20 >>> be forced to also reject the second. The historical intention of using = "bundle-only" was as a mechanism for UDP port preservation on the offerer's= side. This procedure unintentionally turns it into a semantic binding amon= g streams in bundle. >>> >>> I think we could restore the original purpose of the bundle-only handli= ng if we used the port from the rejected 'm=3D' line containing the BUNDLE-= tag for any 'bundle-only' lines. >> >> So, I guess that means we would *always* use the BUNDLE-tag m- line port= - even if the m- line is rejected, AND even if there are other non-bundle-= only m- lines that are NOT rejected. >> >> Example: >> >> a=3Dgroup:BUNDLE foo bar zoo >> m=3Dvideo 20002 RTP/AVP 97 >> a=3Drtpmap:97 H261/90000 >> a=3Dmid:foo >> m=3Dvideo 40002 RTP/AVP 97 >> a=3Drtpmap:99 H264/99999 >> a=3Dmid:zoo >> m=3Dvideo 0 RTP/AVP 97 98 >> a=3Drtpmap:97 H261/90000 >> a=3Drtpmap:98 VP8/90000 >> a=3Dbundle-only >> a=3Dmid:bar >> >> Now, if the UAS rejects the "foo" m- line, it would still select port 20= 002 for the offerer. The UAS would NOT select port 40002, even if it accept= s the "zoo" m- line. > > There are more implications. If you are going to do this for the port,=20 > then you need to do it for the address (c=3D) too. While most likely you= =20 > would see the same address used for each, it is possible that when=20 > getting a unique address/port pairs that you can't (or at least don't)=20 > get the same address for each. We don't require them to be the same. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org =20 > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Apr 28 03:31:33 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800F21A8734 for ; Tue, 28 Apr 2015 03:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXMcMJTsNzpN for ; Tue, 28 Apr 2015 03:31:31 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76241A86FE for ; Tue, 28 Apr 2015 03:31:30 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-b5-553f6180f620 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F1.27.04401.0816F355; Tue, 28 Apr 2015 12:31:28 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Tue, 28 Apr 2015 12:31:28 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CB2264E9A8; Tue, 28 Apr 2015 13:35:32 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 597464E964; Tue, 28 Apr 2015 13:35:32 +0300 (EEST) Message-ID: <553F617F.5000005@ericsson.com> Date: Tue, 28 Apr 2015 12:31:27 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+JvjW5Don2owfqj1hZzO66wWLy/oGsx dfljFgdmjym/N7J6LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZU159ZC+YwlJx9lwzUwPj BuYuRg4OCQETidWr/boYOYFMMYkL99azdTFycQgJHGWUWL3+IiNIQkhgG6PE1P1CEIl1jBJH OhuZIJwVjBL7XrxiAaniFdCWuDephRVkKouAqsT3h4EgYTYBW4nVr26ClYgKpEg8/PubGaJc UOLkzCdgcREBGYm9mzaDxZkFciUer9wNFhcWSJS4dmsrC0TcQmLm/POMELa8xPa3c5ghrlaT uHpuEzPEoaoSV/+9YpzAKDQLyYpZSNpnIWlfwMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7Vk EyMwsA9u+a26g/HyG8dDjAIcjEo8vAte2oUKsSaWFVfmHmKU5mBREue1Mz4UIiSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFxcnTjRomvR/bu/zJFVuNd42SPQxuu3HTfV7Ciq3jfbuuN/ySn 3xEVd4irWSAQw8z7SeYOw+Fnn84tlAnfdumYtN6KCRv/8G/dHJvdbX7V76fQwb6rv4/MKL5z amZ6yKp9FjGJbzS6jlZFpM/zVCs79/KK6/nEm1N9gq406OddifP9mfDkxw1HdiWW4oxEQy3m ouJEAEYNvTlNAgAA Archived-At: Cc: Flemming Andreasen , draft-martinsen-mmusic-ice-dualstack-fairness@tools.ietf.org Subject: [MMUSIC] Confirming adoption of draft-martinsen-mmusic-ice-dualstack-fairness-02 as WG document X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2015 10:31:32 -0000 Hi all, At the IETF #92 MMUSIC meeting [1] in the room we had a strong consensus for adopting draft-martinsen-mmusic-ice-dualstack-fairness-02 for our milestone on Dual-stack fairness with ICE. At this point, the chairs would like to confirm adopting the draft as a WG document. If you have any concerns regarding the adoption, please let us know no later than Friday, May 8th, 2015. Thanks, Ari & Flemming (MMUSIC chairs) [1] http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu5re90f From nobody Tue Apr 28 05:45:47 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C4B1A90DA; Tue, 28 Apr 2015 05:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSOY3TCYgbB7; Tue, 28 Apr 2015 05:45:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0761A902A; Tue, 28 Apr 2015 05:45:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428124544.27972.49789.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 05:45:44 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 12:45:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-10.txt Pages : 15 Date : 2015-04-28 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-msid-10 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 28 05:46:41 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600B31A90CD for ; Tue, 28 Apr 2015 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWE7P-UhAvLu for ; Tue, 28 Apr 2015 05:46:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0F01A902A for ; Tue, 28 Apr 2015 05:46:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 17B6B7C43B1 for ; Tue, 28 Apr 2015 14:46:35 +0200 (CEST) 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 BuFYmu8-s36X for ; Tue, 28 Apr 2015 14:46:33 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:75c8:6742:75de:e918] (unknown [IPv6:2001:470:de0a:27:75c8:6742:75de:e918]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4E12F7C43AD for ; Tue, 28 Apr 2015 14:46:33 +0200 (CEST) Message-ID: <553F8128.405@alvestrand.no> Date: Tue, 28 Apr 2015 14:46:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20150421111454.32078.56417.idtracker@ietfa.amsl.com> <553631B1.1050704@alvestrand.no> <55367A13.2060703@alum.mit.edu> <5538EA6F.3090106@alvestrand.no> In-Reply-To: <5538EA6F.3090106@alvestrand.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] MSID draft -09 posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2015 12:46:39 -0000 I have now posted -10 with the changes to address Paul's review. Thanks again! Harald Den 23. april 2015 14:49, skrev Harald Alvestrand: > Den 21. april 2015 18:25, skrev Paul Kyzivat: >> This draft is a lot simpler to review with its reduced scope! > > > Thanks for the quick review! >> >> I have a few comments: >> >> * Section 2: >> >> ... This new attribute allows endpoints to associate RTP >> media streams that are carried in *the same or* different media >> descriptions. ... >> >> How do you associate distinct MSIDs to media streams in *the same* media >> description??? AFAIK that isn't possible - each media description is a >> distinct media stream. > > Yes, this is a leftover from "plan b". Deleting. > Also, it should be "described", not "carried" - they're carried in RTP > sessions, and described in media descriptions. > >> >> * Section 3: >> >> The semantic token for this semantic is "WMS" (short for WebRTC Media >> Stream). >> >> The above seems to be a leftover that should be removed. > > Yep. > >> >> IMO the following is very confusing in its use of "description". I've >> highlighted the points at issue with *s: > > This is a result of the wholesale replacement of "m-line" with "media > description" - the meanings are unchanged, but it's a bit more obvious > where the grammar is convoluted. > >> >> The following are the rules for handling updates of the list of >> *media descriptions* and their msid values. >> >> o When a new msid "identifier" value occurs in *the* description the >> recipient can signal to its application that a new MediaStream has >> been added. >> >> o When *a description* is updated to have more media descriptions >> with the same msid "identifier" value, but different "appdata" >> values, the recipient can signal to its application that new >> MediaStreamTracks have been added to the MediaStream. >> >> o When *a description* is updated to no longer list any msid >> values, on a specific media description, the recipient can signal >> to its application that the corresponding MediaStreamTrack has >> ended. >> >> I *think* that in some cases you mean *session description* (the whole >> SDP), and in other cases you mean *media description* (m-line and the >> associated following non-m-lines.) Perhaps: >> >> The following are the rules for handling updates of the list of media >> descriptions and their msid values. >> >> o When a new msid "identifier" value occurs in a media description, >> the recipient can signal to its application that a new >> MediaStream has been added. >> >> o When a session description is updated to have more media >> descriptions with the same msid "identifier" value, but different >> "appdata" values, the recipient can signal to its application >> that new MediaStreamTracks have been added to the MediaStream. >> >> o When a session description is updated to no longer list any msid >> attribute on a specific media description, the recipient can >> signal to its application that the corresponding MediaStreamTrack >> has ended. > > Seems much better, I adapted some more - the use of standalone > "description" was a bad idea, and I think I've fixed that. > >> >> * Section 3.2.2: >> >> For each media description in the offer, and for each "a=msid" >> attribute in the media description where the "msid-id" is associated >> with the "WMS" semantic, the receiver of the offer will perform the >> following steps: >> >> In the above, there is still reference to WMS semantic that should be >> removed. > > Removed! > >> >> Also, this again implies that there might be multiple a=msid lines in a >> single media description. How about: >> >> For each media description in the offer that contains an "a=msid" >> attribute, the receiver of the offer will perform the following >> steps: > > Actually this is intended to allow for one track being part of multiple > MediaStreams. If we have: > > m=video > a=msid stream1 track1 > a=msid stream2 track1 > > this would say "track1 is only sent once, but it appears as part of two > MediaStreams". > > The API for PeerConnection still allows that. So I need to allow it here > too. > > I put up the changes I made here: > > https://github.com/alvestrand/rtcweb-msid/pull/4 > > Will leave them up there for a day or two, and submit a -10 if there > aren't further comments. > > Thanks again! > > Harald > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Apr 28 07:47:54 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FE61A1A83 for ; Tue, 28 Apr 2015 07:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlO_rlGr1_oL for ; Tue, 28 Apr 2015 07:47:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CAF1A1B18 for ; Tue, 28 Apr 2015 07:47:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428144747.26993.17078.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 07:47:47 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 14:47:53 -0000 Changed milestone "Submit IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles as Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/mmusic/charter/ From nobody Tue Apr 28 23:00:56 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAB31ACD85 for ; Tue, 28 Apr 2015 23:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_qXNJww676l for ; Tue, 28 Apr 2015 23:00:53 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F081ACD90 for ; Tue, 28 Apr 2015 23:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1185; q=dns/txt; s=iport; t=1430287253; x=1431496853; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u2grauu+VPWqlNNS7TBW1s8RKC0xuQhtRqIXLvIrT8A=; b=M5h1nZgPinfq8T/1L+gsUyQA1PhGC6yv4zA1XVWUpGuwfqFeqh1KGASm uIOTnb7EC0w4wZsGbZDqGy7yLAHoG0UokAaFyeAb2o2bUV6wPJI4FoAll Mhkg1lJ4zuPGIeTSl5kRQGsxUM2Svl2cYulH/2BEHSZsd33dAaO+8c9v8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBABOckBV/5hdJa1cgwxTXAXHIAmBSQyFNE4CgTg4FAEBAQEBAQGBCoQgAQEBBAEBAWsLDAQCAQgRAwECJAsnCx0IAgQBDQUJiCINxmsBAQEBAQEBAQEBAQEBAQEBAQEBARiLOIUFBwaEJwWLNoYvij+BI4NJkQAjYIFYgTxvAYFDgQEBAQE X-IronPort-AV: E=Sophos;i="5.11,669,1422921600"; d="scan'208";a="145460600" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2015 06:00:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3T60qOw023908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 06:00:52 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.199]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 01:00:51 -0500 From: "Ram Mohan R (rmohanr)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] Confirming adoption of draft-martinsen-mmusic-ice-dualstack-fairness-02 as WG document Thread-Index: AQHQgkHYDjWYkdcuT0ycajH6JjZq5w== Date: Wed, 29 Apr 2015 06:00:51 +0000 Message-ID: References: <553F617F.5000005@ericsson.com> In-Reply-To: <553F617F.5000005@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Flemming Andreasen \(fandreas\)" , "draft-martinsen-mmusic-ice-dualstack-fairness@tools.ietf.org" Subject: Re: [MMUSIC] Confirming adoption of draft-martinsen-mmusic-ice-dualstack-fairness-02 as WG document X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 06:00:54 -0000 I support adoption of this draft. Regards, Ram -----Original Message----- From: Ari Ker=E4nen Date: Tuesday, 28 April 2015 4:01 pm To: mmusic Cc: "Flemming Andreasen (fandreas)" , "draft-martinsen-mmusic-ice-dualstack-fairness@tools.ietf.org" Subject: [MMUSIC] Confirming adoption of draft-martinsen-mmusic-ice-dualstack-fairness-02 as WG document >Hi all, > >At the IETF #92 MMUSIC meeting [1] in the room we had a strong consensus >for adopting draft-martinsen-mmusic-ice-dualstack-fairness-02 for our >milestone on Dual-stack fairness with ICE. > >At this point, the chairs would like to confirm adopting the draft as a >WG document. If you have any concerns regarding the adoption, please let >us know no later than Friday, May 8th, 2015. > > >Thanks, >Ari & Flemming >(MMUSIC chairs) > > >[1]=20 >http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu5re90 >f > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Apr 29 05:08:40 2015 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81951A88E3 for ; Wed, 29 Apr 2015 05:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_kEDE35Awqp for ; Wed, 29 Apr 2015 05:08:34 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D401A88D8 for ; Wed, 29 Apr 2015 05:08:33 -0700 (PDT) Received: from ppp118-209-154-116.lns20.mel8.internode.on.net ([118.209.154.116]:58487 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YnQl2-0007IX-3m for mmusic@ietf.org; Wed, 29 Apr 2015 22:06:28 +1000 Message-ID: <5540C9BA.4090803@nteczone.com> Date: Wed, 29 Apr 2015 22:08:26 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mmusic mailing list Content-Type: text/plain; charset=utf-8; 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: Subject: [MMUSIC] Bundling data channel and RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 12:08:39 -0000 Hello According to draft-ietf-rtcweb-data-channel-13 and draft-ietf-rtcweb-transports-08, multiplexing of DTLS and RTP over the same port pair must be supported and application layer protocol payloads over this DTLS connection are SCTP packets, i.e. RTP and datachannel share the same address:port. I assume this needs to be specified in SDP by two m-lines bundled together. E.g. one with "UDP/TLS/RTP/SAVPF" & one with "UDP/DTLS/SCTP" . However I can't find in any of the related drafts where this is stated. I would think the BUNDLE and JSEP drafts should mention something about this. Is there a draft that I've missed where this is stated? Regards, Christian