From nobody Mon Jun 2 02:46:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8351A02EB for ; Mon, 2 Jun 2014 02:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMzHifSernIj for ; Mon, 2 Jun 2014 02:45:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E771A02EA for ; Mon, 2 Jun 2014 02:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8880; q=dns/txt; s=iport; t=1401702353; x=1402911953; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LN41Dv7FgTySRdp6HE5P+DZQxhN90DidUGgd8rm4ZUs=; b=iYoPICohSX6Jhg8ng64sAnRZUmvaL3GLcpVJc70/loRz4PvYKj6ANHct HoQmx1OlU2+wltagnxpe0y680CuPyZa75ecRJURa1cQN8aPyZHDKsiJ7X EuHSU3j67q01XqPc9EABBvRx1tNFMK8ass0a5kM7ldVI9P+TyeYBnmR1m 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggJALlGjFOtJA2H/2dsb2JhbABZgwdSUQeCbLguhmhRARl5FnSCJQEBAQQBAQExOhcEAgEIEQMBAgEEKAICJQsdCAIEARIJiDkIBZNLnBgGpD8XgSSMXQEBVgaCaYFRBJoAgT6Rb4M4bIEBBwIXAiA X-IronPort-AV: E=Sophos;i="4.98,955,1392163200"; d="scan'208";a="329726024" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 02 Jun 2014 09:45:51 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s529jopk029317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Jun 2014 09:45:50 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.106]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 04:45:50 -0500 From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt Thread-Index: AQHPfkdvMAvn6ASrHUWO6QS4xLiKqg== Date: Mon, 2 Jun 2014 09:45:49 +0000 Message-ID: References: <20140519083842.21555.8626.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.41.90] Content-Type: text/plain; charset="euc-kr" Content-ID: <10926A08FB3A644B920522844C37D4BA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IlCU8hpgCGqUTFB3Y3tY2HdYrKo Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 09:45:59 -0000 SGkgQ2hhcmxlcywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBXaWxsIGZpeCB0aGVzZSBpbiB0 aGUgbmV4dCByZXZpc2lvbi4gUGxlYXNlIHNlZQ0KaW5saW5lDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiAiQ2hhcmxlcyBFY2tlbCAgIChlY2tlbGN1KSIgPGVja2VsY3VAY2lz Y28uY29tPg0KRGF0ZTogV2VkbmVzZGF5LCAyMSBNYXkgMjAxNCAxMjowMyBhbQ0KVG86IFJhbSBN b2hhbiBSYXZpbmRyYW5hdGggPHJtb2hhbnJAY2lzY28uY29tPiwgInJ0Y3dlYkBpZXRmLm9yZyIN CjxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSS1EIEFjdGlvbjoNCmRy YWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMDMudHh0DQoNCj5UaGUgdXBk YXRlZCBkcmFmdCBsb29rcyBnb29kLiBJIGhhdmUgc29tZSBtaW5vciBjb21tZW50cyBhbmQgYSBz dWdnZXN0aW9uDQo+Zm9yIHRoZSBxdWVzdGlvbi9ub3RlIGluIHNlY3Rpb24gNi4NCj4NCj5TZWN0 aW9uIDEgcmVhZHMgYXMgZm9sbG93cywNCj4iVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBuZXcg U1RVTiB1c2FnZSB3aXRoIGEgcmVxdWVzdCBhbmQgcmVzcG9uc2UNCj4gICBtZXNzYWdlcyB3aGlj aCB2ZXJpZmllcyB0aGUgcmVtb3RlIHBlZXIncyBjb25zZW50IHRvIHJlY2VpdmUgdHJhZmZpYywN Cj4gICBhbmQgY2FuIGFsc28gZGV0ZWN0IGxvc3Mgb2YgbGl2ZW5lc3MuqfcNCj4NCj5TdWdnZXN0 ZWQgdGV4dCBjb3JyZWN0cyB0eXBvcyBhbmQgcmVmbGVjdHMgdGhhdCB0aGUgcmVxdWVzdC9yZXNw b25zZQ0KPnZlcmlmeSBsaXZlbmVzcy4gTG9zcyBvZiBsaXZlbGVzcyBpcyBkZXRlY3RlZCBhcyBi eSBvdGhlciBtZWFucywgc3VjaCBhcw0KPnRoZSBleHBpcmF0aW9uIG9mIGEgdGltZXIgd2hpbGUg d2FpdGluZyB0byByZWNlaXZlIGEgZXhwZWN0ZWQgbWVzc2FnZS4NCj4NCj4iVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYSBuZXcgU1RVTiB1c2FnZSB3aXRoIGV4Y2hhbmdlIG9mIHJlcXVlc3QgYW5k DQo+cmVzcG9uc2UgbWVzc2FnZXMgdG8gdmVyaWZ5IHRoZSByZW1vdGUgcGVlcidzIGNvbnNlbnQg dG8gcmVjZWl2ZSB0cmFmZmljLA0KPmFuZCB0aGUgYWJzZW5jZSBvZiB3aGljaCBmb3IgYSBwZXJp b2Qgb2YgdGltZSBpbmRpY2F0ZXMgYSBsb3NzIG9mDQo+bGl2ZW5lc3MuqfcNCg0KV2lsbCB1cGRh dGUNCg0KPg0KPlNldmVyYWwgcGxhY2VzIHN0YXRlICJjb25zZW50IHRvIHNlbmQgdHJhZmZpY6n3 LiBJIHRoaW5rIHRoaXMgaXMgY29uZnVzaW5nLg0KPlRoZSBjb25zZW50IGlzIHRvIHJlY2VpdmUg dHJhZmZpYy4gQ29uc2VudCBpcyBwcm92aWRlZCBieSB0aGUgcmVjZWl2ZXIsDQo+YW5kIHRoaXMg Y29uc2VudCBpcyB2ZXJpZmllZCBieSB0aGUgc2VuZGVyLiBGb3IgZXhhbXBsZSwgc2VjdGlvbiA0 LjEgcmVhZHMNCj5hcyBmb2xsb3dzLCAiRXhwbGljaXQgY29uc2VudCB0byBzZW5kIGlzIGluZGlj YXRlZCBiean3LiBUaGlzIHNob3VsZCByZWFkDQo+IkV4cGxpY2l0IGNvbnNlbnQgdG8gcmVjZWl2 ZSBpcyBpbmRpY2F0ZWQgYnmp9ywgb3IgIkV4cGxpY2l0IHBlcm1pc3Npb24gdG8NCj5zZW5kIGlz IG9idGFpbmVkIGJ5qfcuIEkgcHJlZmVyIHRoZSBmb3JtZXIuIElmIHlvdSBhZ3JlZSwgdGhpcyBz aG91bGQgYmUNCj5jaGFuZ2VkIGluIHNldmVyYWwgcGxhY2VzLg0KDQpBZ3JlZSB0aGF0IGNvbnNl bnQgaXMgZm9yIHJlY2VpdmluZyB0cmFmZmljIGZyb20gYSByZWNlaXZlcnMgcGVyc3BlY3RpdmUu DQpJbiB0aGlzIGRyYWZ0LCB3ZSBhbHdheXMgdGFsayBhYm91dCBhIHNlbmRlciBvZiB0cmFmZmlj IHNlbmRpbmcgYSBDb25zZW50DQp0byBpdHMgcGVlciB0byBzZW5kIHRyYWZmaWMuDQpTbyBJIGZl ZWwgZnJvbSB0aGUgc2VuZGVycyBwZXJzcGVjdGl2ZSAgobBjb25zZW50IHRvIHNlbmQgdHJhZmZp Y6GxIGlzIHJpZ2h0Lg0KDQpIb3cgYWJvdXQgc2F5aW5nIKGwRXhwbGljaXQgY29uc2VudCB0byBz ZW5kIGlzIG9idGFpbmVkIg0KDQo+DQo+DQo+U2VjdGlvbiA1DQo+cy9hcHBsaWNhdGlvbnMgTVVT VCBOT1QgYmUgYWJsZSB0byBzZW5kIGhlYXJ0YmVhdHMgZmFzdGVyIHRoYW4gMSBwZXINCj5zZWNv bmQvYXBwbGljYXRpb25zIE1VU1QNCj4gICBOT1Qgc2VuZCBoZWFydGJlYXRzIGF0IGFuIGF2ZXJh Z2UgcmF0ZSBvZiBtb3JlIHRoYW4gMSBwZXIgc2Vjb25kDQoNCldpbGwgZml4IHRoaXMNCg0KPg0K PlNlY3Rpb24gNg0KPnMvSUNFIGNvbm5lY3Rpdml0eSBjaGVjayBkZXNjcmliZWQvSUNFIGNvbm5l Y3Rpdml0eSBjaGVja3MgZGVzY3JpYmVkDQoNCldpbGwgZml4IHRoaXMgDQoNCj4NCj5BcyBmb3Ig dGhlIERTQ1AgdG8gdXNlIHdoZW4gbWVkaWEgb24gdHJhbnNwb3J0IGFkZHJlc3NlcyB1c2UgbXVs dGlwbGUNCj5EU0NQcywgSSBhc3N1bWUgdGhpcyBiZWNhdXNlIHRoZSBtZWRpYSBzdHJlYW1zIGhh dmluZyBkaWZmZXJlbnQNCj5wcmlvcml0aWVzLiBUaGF0IGJlaW5nIHRoZSBjYXNlLCB1c2luZyB0 aGUgc2FtZSBEU0NQIGZvciB0aGUgU1RVTiBtZXNzYWdlcw0KPmFzIHRoYXQgdXNlZCBmb3IgdGhl IGhpZ2hlc3QgcHJpb3JpdHkgbWVkaWEgc3RyZWFtKHMpIHNlZW1zIGFwcHJvcHJpYXRlLg0KDQo8 Y2hhcmxlcyBzYWlkPg0KSSBzaG91bGQgaGF2ZSBhbHNvIHN0YXRlZCB0aGF0IHRoaXMgd291bGQg YXBwbHkgb25seSBmb3IgY2FzZXMgaW4gd2hpY2gNCnN1Y2ggdXNlIG9mIG11bHRpcGxlIERTQ1Bz IHdhcyBhcHByb3ByaWF0ZSwgYXMgZGV0ZXJtaW5lZCBieSBEQVJULg0KPC9jaGFybGVzPg0KDQoN CiBXZSBkaWQgZGlzY3VzcyB0aGlzIGVhcmxpZXIgYW5kIHRoZXJlIHdhcyBzb21lIHN1cHBvcnQg dG8gdXNlIGhpZ2hlc3QNCnByaW9yaXR5IERTQ1AgaW4gY2FzZSBvZiBCVU5ETEUuIEhlcmUgd2Fz IHRoZSBwcmV2aW91cyB0aHJlYWQgLQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3J0Y3dlYi9jdXJyZW50L21zZzExNzc3Lmh0bWwNCkkgZGlkIG5vdCBzZWUgYW55IGNvbmNs dXNpb24gdGhvdWdoIG9uIHRoYXQgdG9waWMuDQoNCg0KSSBhbSBvayB0byBoYXZlIFNUVU4gcGFj a2V0cyB0byBoYXZlIGhpZ2hlc3QgRFNDUCB3aGVuIG11bHRpcGxlIERTQ1ANCnZhbHVlcyBhcmUg dXNlZCBmb3IgYSBnaXZlbiA1LXR1cGxlIChsaWtlIGluIERBUlQpLiBUaGUgb25seSBpc3N1ZSBJ IHNlZQ0KaXMgd2hlbiB0aGVyZSBpcyBhIGNvbmdlc3Rpb24gdGhlbiB5b3VyIFNUVU4gY29uc2Vu dCBjaGVjayBwYWNrZXRzIHdvdWxkDQpnZXQgcHJlZmVyZW5jZSBvdmVyIHNvbWUgb2YgdGhlIG90 aGVyIHBhY2tldHMuIEkgdGhpbmsgdGhpcyBpcyBvayBhcw0KZHJvcHBpbmcgYSBjb25zZW50IG1l c3NhZ2UgbWVhbnMgdGhlIHNlbmRlciBpcyBsaWtlbHkgdG8gc3RvcCBzZW5kaW5nDQptZWRpYSBp dHNlbGYsICBpZiBpdCBkb2VzIG5vdCBzZWUgYSBjb25zZW50IHJlZnJlc2ggcmVzcG9uc2UuDQoN Ckkgd2lsbCBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0LiBEb2VzIHRoaXMgbG9vayBvayA/DQoNCiJJ dCBpcyBwb3NzaWJsZSB0aGF0IGRpZmZlcmVudCBEaWZmc2VydiBDb2RlcG9pbnRzIGFyZSB1c2Vk IGJ5DQogICBkaWZmZXJlbnQgbWVkaWEgb3ZlciB0aGUgc2FtZSB0cmFuc3BvcnQgYWRkcmVzcyBh cyBkZXNjcmliZWQgaW4NCiAgIFtJLUQuaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zXS4gIEluIHN1Y2gg Y2FzZXMsIGl0IGlzIHJlY29tbWVuZGVkIHRvIHVzZQ0KdGhlIHNhbWUgRFNDUCBmb3IgdGhlIFNU VU4gbWVzc2FnZXMNCmFzIHRoYXQgdXNlZCBmb3IgdGhlIGhpZ2hlc3QgcHJpb3JpdHkgbWVkaWEg c3RyZWFtKHMpLiINCg0KDQoNClJlZ2FyZHMsDQpSYW0NCg0KPg0KPkNoZWVycywNCj5DaGFybGVz DQo+DQo+DQo+T24gNS8xOS8xNCwgNjoyNCBBTSwgIlJhbSBNb2hhbiBSIChybW9oYW5yKSIgPHJt b2hhbnJAY2lzY28uY29tPiB3cm90ZToNCj4NCj4+VGhlIHJldmlzaW9uIGhhcyB0ZXh0IG9uDQo+ Pg0KPj4xKSBFeHBsYWluaW5nIGhvdyBjb25zZW50IGV4cGlyZXMgYW5kIGlzIHJldm9rZWQgKHNl Y3Rpb25zIDQuMSBhbmQgNC4yKS4NCj4+MikgQWRkZWQgYW4gZXhhbXBsZSAobm9uIG5vcm1hdGl2 ZSkgaW1wbGVtZW50YXRpb24gcHJvY2VkdXJlLg0KPj4NCj4+Q29tbWVudHMgYXJlIHdlbGNvbWUN Cj4+LUF1dGhvcnMNCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9t OiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K Pj5EYXRlOiBNb25kYXksIDE5IE1heSAyMDE0IDI6MDggcG0NCj4+VG86ICJpLWQtYW5ub3VuY2VA aWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+PkNjOiAicnRjd2ViQGlldGYub3Jn IiA8cnRjd2ViQGlldGYub3JnPg0KPj5TdWJqZWN0OiBbcnRjd2ViXSBJLUQgQWN0aW9uOg0KPj5k cmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTAzLnR4dA0KPj4NCj4+Pg0K Pj4+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzDQo+Pj5kaXJlY3Rvcmllcy4NCj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbiBpbg0KPj4+V0VCLWJyb3dzZXJzDQo+ Pj5Xb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4+DQo+Pj4gICAgICAgIFRpdGxlICAgICAg ICAgICA6IFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzDQo+Pj4gICAgICAgIEF1dGhv cnMgICAgICAgICA6IE11dGh1IEFydWwgTW96aGkgUGVydW1hbA0KPj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICBEYW4gV2luZw0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBSYW0gTW9o YW4gUmF2aW5kcmFuYXRoDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIFRpcnVtYWxlc3dh ciBSZWRkeQ0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gVGhvbXNvbg0KPj4+ CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5l c3MtMDMudHh0DQo+Pj4JUGFnZXMgICAgICAgICAgIDogOQ0KPj4+CURhdGUgICAgICAgICAgICA6 IDIwMTQtMDUtMTkNCj4+Pg0KPj4+QWJzdHJhY3Q6DQo+Pj4gICBUbyBwcmV2ZW50IHNlbmRpbmcg ZXhjZXNzaXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNlbnQNCj4+PiAg IG5lZWRzIHRvIGJlIG9idGFpbmVkIGZyb20gdGhhdCByZW1vdGUgZW5kcG9pbnQuDQo+Pj4NCj4+ PiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29uc2VudCBtZWNoYW5pc20gdXNpbmcgYSBu ZXcgU1RVTiB1c2FnZS4NCj4+PiAgIFRoaXMgc2FtZSBtZWNoYW5pc20gY2FuIGFsc28gZGV0ZXJt aW5lIGNvbm5lY3Rpb24gbG9zcyAoImxpdmVuZXNzIikNCj4+PiAgIHdpdGggYSByZW1vdGUgcGVl ci4NCj4+Pg0KPj4+DQo+Pj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczoNCj4+Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lcw0KPj4+cw0KPj4+Lw0KPj4+DQo+Pj5UaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3Mt MDMNCj4+Pg0KPj4+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl IGF0Og0KPj4+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydGN3 ZWItc3R1bi1jb25zZW50LWZyZXNobmVzDQo+Pj5zDQo+Pj4tDQo+Pj4wMw0KPj4+DQo+Pj4NCj4+ PlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mDQo+Pj5zdWJtaXNzaW9uDQo+Pj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4+DQo+Pj5JbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj5mdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+DQo+Pj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+cnRjd2ViIG1haWxpbmcgbGlzdA0K Pj4+cnRjd2ViQGlldGYub3JnDQo+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+cnRjd2ViIG1haWxpbmcgbGlzdA0KPj5ydGN3ZWJAaWV0Zi5vcmcNCj4+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCg0K From nobody Mon Jun 2 10:13:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52561A024D for ; Mon, 2 Jun 2014 10:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOa9_HbuRbPv for ; Mon, 2 Jun 2014 10:13:52 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3A71F1A020B for ; Mon, 2 Jun 2014 10:13:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2FD877C368A for ; Mon, 2 Jun 2014 19:13:46 +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 Bv-Z6d+c2oss for ; Mon, 2 Jun 2014 19:13:45 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 21A597C3688 for ; Mon, 2 Jun 2014 19:13:45 +0200 (CEST) Message-ID: <538CB0C7.6050700@alvestrand.no> Date: Mon, 02 Jun 2014 19:13:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------090009010206020701040405" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L8v0MzvnVq5-KlqgmX6lFERENIU Subject: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:13:55 -0000 This is a multi-part message in MIME format. --------------090009010206020701040405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I believe this has been discussed before, but I can't find the discussion...... so I'm re-raising it. (it may have happened here, or on MMUSIC, but I can't find it in either place). I believe this WG has consensus that ICE is used, that ICE-TCP candidates are permitted (indeed, required to be supported), and that TURN over TCP is permitted; in the latter two cases, RFC 4571 framing is used, but SRTP is used, not TLS. Given the nature of ICE, flows may shift back and forth between TCP candidates and UDP candidates over the lifetime of the flow, without any new SDP negotiation being invoked. A bug has been raised about what protocol field to be used in the SDP for these flows. RFC 5764 says: 8. Session Description for RTP/SAVP over DTLS This specification defines new tokens to describe the protocol used in SDP media descriptions ("m=" lines and their associated parameters). The new values defined for the proto field are: o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over DTLS with the Datagram Congestion Control Protocol (DCCP), then the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF respectively. o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF respectively. The "fmt" parameter SHALL be as defined for RTP/SAVP. See [RFC5763] for how to use offer/answer with DTLS-SRTP. This document does not specify how to protect RTP data transported over TCP. Potential approaches include carrying the RTP over TLS over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that in this document over TCP, either via TLS or DTLS, with DTLS being used for consistency between reliable and unreliable transports. In the latter case, it would be necessary to profile DTLS so that fragmentation and retransmissions no longer occurred. In either case, a new document would be required. The current implementations both send "RTP/SAVPF" in this field. But this usage is not specified by RFC 5764. Using the specified token, UDP/TLS/RTP/SAVPF, speaks a partial untruth, in that sometimes, UDP is not used. But it is a token people have seen before. What says the wisdom of the group? What shall we put in the spec? Harald --------------090009010206020701040405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I believe this has been discussed before, but I can't find the discussion...... so I'm re-raising it.
(it may have happened here, or on MMUSIC, but I can't find it in either place).

I believe this WG has consensus that ICE is used, that ICE-TCP candidates are permitted (indeed, required to be supported), and that TURN over TCP is permitted; in the latter two cases, RFC 4571 framing is used, but SRTP is used, not TLS.

Given the nature of ICE, flows may shift back and forth between TCP candidates and UDP candidates over the lifetime of the flow, without any new SDP negotiation being invoked.

A bug has been raised about what protocol field to be used in the SDP for these flows.

RFC 5764 says:


8.  Session Description for RTP/SAVP over DTLS

   This specification defines new tokens to describe the protocol used
   in SDP media descriptions ("m=" lines and their associated
   parameters).  The new values defined for the proto field are:

   o  When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over
      DTLS with the Datagram Congestion Control Protocol (DCCP), then
      the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF
      respectively.

   o  When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with
      UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF
      respectively.

   The "fmt" parameter SHALL be as defined for RTP/SAVP.

   See [RFC5763] for how to use offer/answer with DTLS-SRTP.

   This document does not specify how to protect RTP data transported
   over TCP.  Potential approaches include carrying the RTP over TLS
   over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that
   in this document over TCP, either via TLS or DTLS, with DTLS being
   used for consistency between reliable and unreliable transports.  In
   the latter case, it would be necessary to profile DTLS so that
   fragmentation and retransmissions no longer occurred.  In either
   case, a new document would be required.


The current implementations both send "RTP/SAVPF" in this field. But this usage is not specified by RFC 5764.

Using the specified token, UDP/TLS/RTP/SAVPF, speaks a partial untruth, in that sometimes, UDP is not used. But it is a token people have seen before.

What says the wisdom of the group? What shall we put in the spec?

Harald




--------------090009010206020701040405-- From nobody Mon Jun 2 11:43:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9471A03A2 for ; Mon, 2 Jun 2014 11:43:32 -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 QOzvV2j3QuYV for ; Mon, 2 Jun 2014 11:43:28 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311FB1A038C for ; Mon, 2 Jun 2014 11:43:28 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so5176024wiw.2 for ; Mon, 02 Jun 2014 11:43:21 -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=DkgrAfhkCKgQxIa2cJTRAL7SQbeQrHDsIkUrpPq8YFo=; b=iOibqhiFynq3W0krCD9jlhkD23OTMFSJvpF+BiP+Vho97tWSQx8JZFQhKAqYcBnJf9 pky9XOHQZpHIV5JGj3VxJ7Ew5UXVz/gVVf9iECLkhbjD7L+tQZ90akgj82/3aQ9//Hnk Cig8w95yOfHj4ZsrPktUPsjNAMeXJTIiH+NSp1ht/JYyAx+SvFb7oQwkxgCtPSfoGuzz DFO57k+FH5SZqDBeelJFTALqEkVIq90G5uFi4D12IRdFuiHZgtTu3OWrTfFZbkm0I50J Q6uHRIvHS2cQcxSGyJieLEK9fvUA7razw2+y7lMTrrBvmgDsqFw8DK+qK88N4pH7Shq7 zDiQ== MIME-Version: 1.0 X-Received: by 10.194.249.228 with SMTP id yx4mr40350679wjc.53.1401734601674; Mon, 02 Jun 2014 11:43:21 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Mon, 2 Jun 2014 11:43:21 -0700 (PDT) In-Reply-To: References: <20140519083842.21555.8626.idtracker@ietfa.amsl.com> Date: Mon, 2 Jun 2014 11:43:21 -0700 Message-ID: From: Martin Thomson To: "Ram Mohan R (rmohanr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F4EstJylZ0SUtZmYXpAzYGZ8Hs0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 18:43:32 -0000 On 2 June 2014 02:45, Ram Mohan R (rmohanr) wrote: > > I should have also stated that this would apply only for cases in which > such use of multiple DSCPs was appropriate, as determined by DART. > > > > We did discuss this earlier and there was some support to use highest > priority DSCP in case of BUNDLE. Here was the previous thread - > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11777.html > I did not see any conclusion though on that topic. > > > I am ok to have STUN packets to have highest DSCP when multiple DSCP > values are used for a given 5-tuple (like in DART). The only issue I see > is when there is a congestion then your STUN consent check packets would > get preference over some of the other packets. I think this is ok as > dropping a consent message means the sender is likely to stop sending > media itself, if it does not see a consent refresh response. > > I will add the following text. Does this look ok ? > > "It is possible that different Diffserv Codepoints are used by > different media over the same transport address as described in > [I-D.ietf-tsvwg-rtcweb-qos]. In such cases, it is recommended to use > the same DSCP for the STUN messages > as that used for the highest priority media stream(s)." I know that I haven't raised this point before, and I apologize for not paying enough attention, but I don't think that we should be talking about DSCP in this draft. Use of DSCP with STUN and the additional complications that BUNGLE adds are best dealt with in those contexts. This was a simple document, we should keep the scope constrained as much as possible. From nobody Mon Jun 2 11:54:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557A01A0351 for ; Mon, 2 Jun 2014 11:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM4dO5N6UmOu for ; Mon, 2 Jun 2014 11:54:06 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CACFC1A0348 for ; Mon, 2 Jun 2014 11:54:05 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so4836328wib.0 for ; Mon, 02 Jun 2014 11:53:58 -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=AM9h9kOJA8b3I7oQpLckTxILFzNJzOZ7kPT6uzYDjss=; b=LdE0yTIni5A0aleyx+Zeg5WLhNnZp8lJDTpDVqvGn3VJti6hqGKiw9NYxrc1O8/QJo q6UECzx0z0ES6ypjd9r+yVBtb6wXShsuCv7KGrxyaiWt/YV1jKzJC+x9nG2/FmGa153K vzx6QTfg3FLeDW+U0pqKoWoHFwgzo9G4RnvdfICMqeh4cBCQWDK5bHnVyK4Ca2X06O2G U7rSkeEjzzOsm8tZDHrJGBcyZHTvmG5OzIB56aVw8KAlk9bIItiDLCecNK1TAlbzQQAE KucISDDQdgmaDww1vUMhjCav9MVrNNgNF18tKPOrQeGFxH26gAJo4N4+2+ZxDXevGLIT 7/4g== MIME-Version: 1.0 X-Received: by 10.180.36.35 with SMTP id n3mr24996584wij.23.1401735237859; Mon, 02 Jun 2014 11:53:57 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Mon, 2 Jun 2014 11:53:57 -0700 (PDT) In-Reply-To: <538CB0C7.6050700@alvestrand.no> References: <538CB0C7.6050700@alvestrand.no> Date: Mon, 2 Jun 2014 11:53:57 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OgXH_5p7G_I5rDo1nirNTxdYglM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 18:54:07 -0000 On 2 June 2014 10:13, Harald Alvestrand wrote: > The current implementations both send "RTP/SAVPF" in this field. But this > usage is not specified by RFC 5764. Sounds easy to me. The SDP doesn't matter and can say anything. "RTP/SAVPF" is as good as any other sequence of octets. I'm sure that JSEP can include a requirement that is directly contradictory to an existing RFC. That happens all the time. At least this time it can be explicit. From nobody Mon Jun 2 12:51:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58AE1A021A for ; Mon, 2 Jun 2014 12:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22DnIBpWK1UX for ; Mon, 2 Jun 2014 12:51:34 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C181A0069 for ; Mon, 2 Jun 2014 12:51:34 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cm18so3361335qab.36 for ; Mon, 02 Jun 2014 12:51: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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qzrTzfKkC1qUmT7X/Jd4EZoxayJNquWtwQ1WSoRKwv4=; b=M1paQY+xYdeU7i1qZUZjefvKFqNgyNSpryOKXOkou5iETXMtnUJAc2Jti1bvszyKf+ 3m4HjTI6vCsEt/NQcBZNRrTw10q9NONcYRAfkbH+lULlSKWDD+1mlYlT0HpLApw9s0IR MDx8lyP9XaQRxr2uqhXv/5LDAixS7oshmF64Twx0CxB6pPhAzSoTKP5KmtWh0jUKtu3u a2gf90NTIu8flEV0aoCmrRmIxO/TFCZEUXpe+klkIsEmQ/gJrfQSjTrdSaoavI0mYomh DGrwVe0cWNs1cQbzFDBdG7oE9QkIQwnZ6gj6b1KhxnjvN5YNoQ0zyEha89wP62Ozd/Dn Bmxw== X-Gm-Message-State: ALoCoQl1CkY5Ownok83eEs950ZSoolSHq+Bn5ji05maEM/rln14xdfWUgrLr4qs+deWXodfBUqdO X-Received: by 10.140.40.81 with SMTP id w75mr49766763qgw.112.1401738688417; Mon, 02 Jun 2014 12:51:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Mon, 2 Jun 2014 12:51:08 -0700 (PDT) In-Reply-To: <538CB0C7.6050700@alvestrand.no> References: <538CB0C7.6050700@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 2 Jun 2014 21:51:08 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8OGF7sif-IEy_AtzeJvkwLqeOKE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:51:36 -0000 2014-06-02 19:13 GMT+02:00 Harald Alvestrand : > The current implementations both send "RTP/SAVPF" in this field. But this > usage is not specified by RFC 5764. > > Using the specified token, UDP/TLS/RTP/SAVPF, speaks a partial untruth, i= n > that sometimes, UDP is not used. But it is a token people have seen befor= e. > > What says the wisdom of the group? What shall we put in the spec? I don't think SDP is ready or enough powerful to allow this case in which different transports can be used. The "UDP/TLS/RTP/SAVPF" token is just that: a token. And there is no reason at all to mandate that the m=3D line defines the transport to use given that, at least in WebRTC, the transport is determined by the ICE candidates. The "transport" in the m=3D line is as useless as the "port" field in the m=3D line when ICE is mandated. RFC 5764 "DTLS Extension to Establish Keys for SRTP" clearly states that "there is no chance" to allow two different transports for the same media: ----------------------------- 8. Session Description for RTP/SAVP over DTLS This specification defines new tokens to describe the protocol used in SDP media descriptions ("m=3D" lines and their associated parameters). The new values defined for the proto field are: o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over DTLS with the Datagram Congestion Control Protocol (DCCP), then the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF respectively. o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF respectively. ------------------------------ So basically SDP is not valid for WebRTC, but since it has been forced to be valid we need a workaround to hide this fact. I would propose that the m=3D line "transport" for WebRTC MUST always be the token "UDP/TLS/RTP/SAVPF" regardless the nature of transports in the ICE candidates (so basically it becomes a useless but mandatory field in the SDP, as many others already). Said that I would also be happy if the chosen token is "CHICKEN". Regards. --=20 I=C3=B1aki Baz Castillo From dleonard@getjive.com Mon Jun 2 09:23:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7B31A0265 for ; Mon, 2 Jun 2014 09:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mblVF-UzSPgr for ; Mon, 2 Jun 2014 09:23:05 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A7A1A023D for ; Mon, 2 Jun 2014 09:23:05 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id sa20so5483065veb.13 for ; Mon, 02 Jun 2014 09:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=mime-version:date:message-id:subject:from:to:content-type; bh=bfdknV/y5dJ/aErYiwuFLR444spoVJdO8zP/WNwaCkM=; b=WEztElgROXIIFHCH68EGXiNkVx4HjZsLFp04fs3imxberEWWeTXRbxBR08gVHWIEN1 KEXL+KQ1WEdisEcS53hKyYOjUmwQeryGGN2sljUgen0TGHg+VzvBYrZWsaTbJLGI0r/x CJs57kMKbSrW5s5IkmHA/fnBYG3kdxxIOAbdY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=bfdknV/y5dJ/aErYiwuFLR444spoVJdO8zP/WNwaCkM=; b=ORsRP0NVGVv35owhZogATGlvIrTZRjXLWWLzgaKkqmUbnSzm4hEdKVyJSdjsQaqoGr FGxOkI0LA0jhKb1kOzOwasrmkmyEyAhP8t/ARd6M8TeBmdDf9upvN7+Ur4N4dIG3sl9e RGf5JuQhjj1nnQy4dbAGEdXsKG3eBARj0+u7W2gUdWlQ8LLQ8OGkSPqEON+m5U6tnA8s Fl7/pGmuxCk4viumax//WwxHQA9tFsSAx31I5drqwtTTK+4EbjWFyQMm3L/EdrwX8be/ olyRZWmzFKoAlT9LCbPCGL+FxTJwprT3YOZ/ymKx2imGUWiKIvzWWLh0VgAtH29cgfFb 9AIQ== X-Gm-Message-State: ALoCoQmdAO9MyyXR7LTFeEo+H/Seis5e06VCcBhIbAfyjg2cEBxxAqg+8xhe+7OW3TVox21EqWhO MIME-Version: 1.0 X-Received: by 10.221.66.131 with SMTP id xq3mr1702732vcb.43.1401726179640; Mon, 02 Jun 2014 09:22:59 -0700 (PDT) Received: by 10.220.185.71 with HTTP; Mon, 2 Jun 2014 09:22:59 -0700 (PDT) Date: Mon, 2 Jun 2014 10:22:59 -0600 Message-ID: From: Doug Leonard To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a11364632029ab404fadccfae Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/btR-sWSW7Aeh0Ex6EflkL9kAn-I X-Mailman-Approved-At: Mon, 02 Jun 2014 13:17:13 -0700 Subject: [rtcweb] Review of draft-ietf-rtcweb-data-protocol-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:24:03 -0000 --001a11364632029ab404fadccfae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A1. Section 4, 1st paragraph I think the full name of the protocol better establishes context. It should be used as a section's first reference to the protocol. Then subsequent references may be less explicit. (see A4) I would change "This protocol..." to "The Data Channel Establishment Protocol..." A2. Section 4, first bullet Should be simplified to read: Reliable or unreliable message transmission. In the case of unreliable transmissions, the same level of unreliability is used. A3. Section 4, second bullet Should be simplified to read: In-order or out-of- order message delivery. A4. Section 4, third paragraph Change the subsequent reference of "The Data Channel Establishment Protocol..." to "This protocol..." A5. Section 4, third paragraph "...uses a two way handshake to open a data channel by combining two SCTP streams, one in each direction, with the same SCTP stream identifier." For more clarity change to: "...uses a two way handshake to open a data channel. The handshake pairs one incoming and one outgoing SCTP stream, each having an identical stream identifier, into a single bidirectional channel." A6. Section 4, third paragraph I think the sentence that begins "Please note" should be separated out into a new paragraph and labeled as a note as follows: Note: The opening side can only send user messages before the DATA_CHANNEL_ACK is received. A7. Section 4, fourth paragraph I think we should formally reference the title of Internet- Drafts and then link to their location, rather than using the link as the subject of sentences. I would change the sentence that begins "When using [I-D.ietf-tsvwg-sctp-dtls-encaps], the method..." to the following: =E2=80=9CWhen using SCTP over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps], the m= ethod=E2=80=A6=E2=80=9D --=20 Doug Leonard Developer | Jive Communications, Inc. Jive.com | dleonard at getjive . com -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v0.5.1 Comment: http://openpgpjs.org wsBcBAEBCAAQBQJTjKTaCRA6BPqvovvpGQAAPwMH/2Tp1sx9diRh48WhVELN 0uA0HxU4ITI5sUbbHdpwbGZm2EmEB/enbrW74yBXdaSAk4ouXh5Kz11akFU5 r50X8shgLSeziIOxSuJNuA5re11vLcdnRZ3fMDGPKbTsFDvJgNT+kwO8buKS 6CLpQxCDxoNOyUN4KZqS1QBeUlVP49+a/ms0Pg/97oiSPAvipMknVB7KUFg6 lppN8HuqOxxAKTFrU05tuXucIW/937FL5iTcDv6cdNTW+xiKmUXOOgoTTQtN y7PfB8Bc01TnLpy2xFDAmkeKTAZ5REIXax0v80ASy8W4JFIopzCtSyS+XniG 6oyeTLz02IMv1R8lUyVbbaA=3D =3DnotY -----END PGP SIGNATURE----- --001a11364632029ab404fadccfae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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


A1. Section 4, 1st paragraph=C2=A0

I think the full name of the protocol better establishes context. = It
should be used as a section's first reference to the proto= col. Then
subsequent references may be less explicit. (see A4)=C2=A0
<= br>
I would change "This protocol..." to "The Data= Channel Establishment
Protocol..."

A2. Section 4, first bullet=C2=A0

Should be simpli= fied to read: Reliable or unreliable message
transmission. In the= case of unreliable transmissions, the same level
of unreliabilit= y is used.

A3. Section 4, second bullet=C2=A0

=
Should be simplified to read: In-order or out-of- order message
<= div>delivery.

A4. Section 4, third paragraph=C2=A0=

Change the subsequent reference of "The Data Chann= el Establishment
Protocol..." to "This protocol..."= ;

A5. Section 4, third paragraph=C2=A0
<= br>
"...uses a two way handshake to open a data channel by comb= ining two
SCTP streams, one in each direction, with the same SCTP= stream
identifier."

For more clari= ty change to:

"...uses a two way handshake to open a data channe= l. The handshake
pairs one incoming and one outgoing SCTP stream,= each having an
identical stream identifier, into a single bidire= ctional channel."

A6. Section 4, third paragraph=C2=A0

I think the sentence that begins "Please note" should be s= eparated out
into a new paragraph and labeled as a note as follow= s:

Note: The opening side can only send user messages befo= re the
DATA_CHANNEL_ACK is received.

A7.= Section 4, fourth paragraph=C2=A0

I think we shou= ld formally reference the title of Internet- Drafts
and then link to their location, rather than using the link as the
subject of sentences. I would change the sentence that begins "= When
using [I-D.ietf-tsvwg-sctp-dtls-encaps], the method..."= to the
following:

=E2=80=9CWhen using SCTP over DTLS= [I-D.ietf-tsvwg-sctp-dtls-encaps], the method=E2=80=A6=E2=80=9D
=

--
Doug Leonard
Developer =C2=A0| =C2=A0Jive Communications, Inc.
Jive.com =C2=A0| =C2=A0dleonard at getjive . com

-----BEGIN PGP SIGNATURE-----
Version: OpenPGP.js v0.5.1
Comment: http://openpgpjs.org

wsBcBAEBCAAQBQJTjKTaCRA6BPqvovvpGQAAPwMH/2Tp1sx9diRh48WhVELN
0uA0HxU= 4ITI5sUbbHdpwbGZm2EmEB/enbrW74yBXdaSAk4ouXh5Kz11akFU5
r50X8shgLSeziIOxSu= JNuA5re11vLcdnRZ3fMDGPKbTsFDvJgNT+kwO8buKS
6CLpQxCDxoNOyUN4KZqS1QBeUlVP4= 9+a/ms0Pg/97oiSPAvipMknVB7KUFg6
lppN8HuqOxxAKTFrU05tuXucIW/937FL5iTcDv6cdNTW+xiKmUXOOgoTTQtN
y7PfB8Bc01T= nLpy2xFDAmkeKTAZ5REIXax0v80ASy8W4JFIopzCtSyS+XniG
6oyeTLz02IMv1R8lUyVbba= A=3D
=3DnotY
-----END PGP SIGNATURE-----
--001a11364632029ab404fadccfae-- From nobody Mon Jun 2 23:04:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319361A00ED for ; Mon, 2 Jun 2014 23:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoAB_nqfG7EW for ; Mon, 2 Jun 2014 23:04:48 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DA01A00EA for ; Mon, 2 Jun 2014 23:04:46 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so6379896veb.17 for ; Mon, 02 Jun 2014 23:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UN4yfnyMSVag8mmNj4AojEhoypA0G8fKK6ryDE9noDE=; b=LK+txG0rCdpIJPojxms3JGA/WW8hVqEsTVqYXX+wDTVDLgRLQli/m+QWPxXjBdcoEW 0kQUiJEoKhLR0L84fa4UQEcisFyAK5gi182KWlf88skN7ajjA6MwLUf6vIC9X1dGaJJt 4IV6QTN2cBBAdrFA0liesNhTq/FPU9JcYYdInSd3fUopzFmyioI1pll3CSgnEZAJ5hjs matsdxT/lqiLLNCH/xgBm2cz80up76b2q/NWLRIbBuAa9d2qgXv2B8kMHjelu1bnOePj 8AKoPy1Grt1TrKFHd59/63KSOxcu3r4p8xn8ULwoQlOgev7q7fcpYiOAOkYXzNvehi7+ 6Kbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UN4yfnyMSVag8mmNj4AojEhoypA0G8fKK6ryDE9noDE=; b=OOwOk8/9bsxaDDSJtsnyQU+yMaYl0Sbo6El9sXlBML+CIZGoFVUmaL9QyMdS+LSEVT b5jmdOOGjYG7V6a1YfzcyWZTVKMieOvuJHI+GIX/QM/AsLYZ03fLbTiUjLrywPmdq9wO opjwp35p88qCwIdrSJM4HM7FswWmk6cH6HQj3kLvDGksjc5OW+hp0dF9JTvUZUiaO70P 0PDbUYv+gChuUhU2FWjzkc2FjFzW/D1/LM5Es4awpszwesUbDqq8b50VhgvRCiyyObi3 2B1T81MfgrIefgUPr4SLRhZCGwB/rX5DfKRjUha2pq46GGT3kjrKnVa980ujo1z2degX cv4Q== X-Gm-Message-State: ALoCoQn8YnCRzdtbdCWFtxTDJsrMD5w1x3HI8nxwWLj8bDo8WTLEmPfhr4B+v2cepp99KLNkYbgW X-Received: by 10.58.85.3 with SMTP id d3mr7715170vez.34.1401775480252; Mon, 02 Jun 2014 23:04:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Mon, 2 Jun 2014 23:04:20 -0700 (PDT) In-Reply-To: References: <538CB0C7.6050700@alvestrand.no> From: Justin Uberti Date: Mon, 2 Jun 2014 23:04:20 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b86c2668e52ae04fae849d5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LajzTV485fP3hjnnzg1fdTMBc2U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 06:04:49 -0000 --047d7b86c2668e52ae04fae849d5 Content-Type: text/plain; charset=UTF-8 I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one has to guess at this from the presence of a=fingerprint, which seems dodgy, given that endpoints are free to ignore SDP attributes they don't understand. The fact that UDP and TLS appear in the m= line is kind of unfortunate, but I think it can be interpreted as "do DTLS-SRTP". On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson wrote: > On 2 June 2014 10:13, Harald Alvestrand wrote: > > The current implementations both send "RTP/SAVPF" in this field. But this > > usage is not specified by RFC 5764. > > Sounds easy to me. The SDP doesn't matter and can say anything. > "RTP/SAVPF" is as good as any other sequence of octets. > > I'm sure that JSEP can include a requirement that is directly > contradictory to an existing RFC. That happens all the time. At > least this time it can be explicit. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b86c2668e52ae04fae849d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think there is value in specifying UDP/TLS/RTP/SAVPF, in= that it unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one= has to guess at this from the presence of a=3Dfingerprint, which seems dod= gy, given that endpoints are free to ignore SDP attributes they don't u= nderstand.

The fact that UDP and TLS appear in the m=3D line is kind of= unfortunate, but I think it can be interpreted as "do DTLS-SRTP"= .


= On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 2 June 2014 10:13, Harald= Alvestrand <harald@alvestrand.n= o> wrote:
> The current implementations both send "RTP/SAVPF" in this fi= eld. But this
> usage is not specified by RFC 5764.

Sounds easy to me. =C2=A0The SDP doesn't matter and can say anyth= ing.
"RTP/SAVPF" is as good as any other sequence of octets.

I'm sure that JSEP can include a requirement that is directly
contradictory to an existing RFC. =C2=A0That happens all the time. =C2=A0At=
least this time it can be explicit.

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

--047d7b86c2668e52ae04fae849d5-- From nobody Tue Jun 3 00:55:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9E1A0162 for ; Tue, 3 Jun 2014 00:55:22 -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 ya9BAhxHRL-1 for ; Tue, 3 Jun 2014 00:55: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 835601A015A for ; Tue, 3 Jun 2014 00:55:20 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-eb-538d7f617957 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 70.55.15680.16F7D835; Tue, 3 Jun 2014 09:55:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 09:55:12 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Continous consent when no media is sent Thread-Index: Ac9/ASUxUKyjPjBnR0yv6isP3kDHzA== Date: Tue, 3 Jun 2014 07:55:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34DB2C@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_7594FB04B1934943A5C02806D1A2204B1D34DB2CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW5ifW+wwYlOSYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eLud/aCi3IVR690MjYwfpTqYuTkkBAwkWj8eJMJwhaTuHBv PRuILSRwlFHiwGH5LkYuIHsRo8Tzxn0sXYwcHGwCFhLd/7RBakQE1CUuP7zADmILCxhINH2G 6BURMJW4dPsyM4StJ/HgyAqwOIuAisTl7l2MIDavgK/E++PTWEFsRqC930+tAbuBWUBc4taT +VD3CEgs2XOeGcIWlXj5+B8rhK0ocXX6cqj6fIldxzeyQ8wUlDg58wnLBEahWUhGzUJSNgtJ GURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJ ERgRB7f81t3BuPq14yFGAQ5GJR7eB597goVYE8uKK3MPMUpzsCiJ817SqA4WEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwJi3uMC6nqGc+9GjctXVOReb8ybubDPYoli8c6LpEQHDzY+b+V1M Yy135msbbtvtNku2KPbvqe/qvvHm9quehXcW8Kfk7ds+4du1FNkNpdeC+4zflfFfvsHycjnj 550d6549dZ+Rtv9bk5dg92b7xxfPi1oVlJQWS61sWN9vOO905qrMx3dsTimxFGckGmoxFxUn AgBhg+MyaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ndKyJpwB6PyOZ4gjBfIvEqLBgtU Subject: [rtcweb] Continous consent when no media is sent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:55:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D34DB2CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 4.1 of draft-ietf-rtcweb-stun-consent-freshness-03 says: "An endpoint that is only receiving application traffic (recvonly) does not need to obtain consent which can slightly conserve= its resources." I think it would be good to be more generic, and talk about cases where the= sender does not send media. That is obviously true in case of "recvonly", = but it could also be true in other cases. In addition, I guess the no-need-to-send-consent rule also applies to "inac= tive" streams. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D34DB2CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 4.1 of draft-ietf-rtcweb-stun-consent-freshn= ess-03 says:

 

“An endpoint that= is only receiving application traffic (recvonly)

         &nb= sp;      does not need to obtain consent which can= slightly conserve its

         &nb= sp;      resources.”

 

I think it would be good to be more generic, and tal= k about cases where the sender does not send media. That is obviously true = in case of “recvonly”, but it could also be true in other cases= .

 

In addition, I guess the no-need-to-send-consent rul= e also applies to “inactive” streams.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D34DB2CESESSMB209erics_-- From nobody Tue Jun 3 01:32:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A771A0167 for ; Tue, 3 Jun 2014 01:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srGLQ62OCScc for ; Tue, 3 Jun 2014 01:32:53 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26741A0162 for ; Tue, 3 Jun 2014 01:32:52 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so3169902lbi.37 for ; Tue, 03 Jun 2014 01:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=l/0qXYxL78rWzGDqXRP7THAMiyFdHp0lAvqil2lX2zk=; b=Dk15LXI7/Ex1tslacBYDvQ9HbouNaVpG7k9nO5N/Xy9hcCGvxjKmox9Oml+ERZXADw L4PrqJvcx9/4I3dNnbHAwlrEDO67Z3l90qKLe0evMkq+HKrY5m6aXYZivNCSKgp/fpaL 7sEx3rz/lc9WIZWokUlv5qj4eQrhZorpRk8pIBnbYe0pMD1fzATOZqGUXjAWSvLa+04+ auuKX6zyfPYsmD8Mvjs2Inwm6N1KrJuVOr3oNtJrwWVyA4vXFHlSuca+kHxG5hFC1QU2 wRLsWIp0fdE4F3wUrysasNnDDqa/ZEZPmtg1+IDju+K1WlQieSW7DoF/EkqEUOs+zRLM OUGA== X-Received: by 10.112.138.37 with SMTP id qn5mr6716438lbb.52.1401784365674; Tue, 03 Jun 2014 01:32:45 -0700 (PDT) Received: from [192.168.1.39] (207.Red-79-146-136.dynamicIP.rima-tde.net. [79.146.136.207]) by mx.google.com with ESMTPSA id i10sm13313862lah.13.2014.06.03.01.32.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 01:32:44 -0700 (PDT) Message-ID: <538D882B.5030502@gmail.com> Date: Tue, 03 Jun 2014 10:32:43 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <538CB0C7.6050700@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090302010602070801010801" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0hvgvKMVpzNeF1tYKURjfIl0pyk Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:32:55 -0000 This is a multi-part message in MIME format. --------------090302010602070801010801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On the other side, keeping "RTP/SAVFP" would have allowed a server (SBC/MCU/etc) to send an offer without knowing in advance if the other side supports SDES or DTLS, by sending both the crypto and fingerprint attributes and let the receiver choose which one to use (as chrome has done until recently). I know that it is not important for webrtc, as DTLS is mandatory and SDES is a must not, but for supporting other legacy clients it may be easier for some of us. Best regards Sergio El 03/06/2014 8:04, Justin Uberti escribió: > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one has > to guess at this from the presence of a=fingerprint, which seems > dodgy, given that endpoints are free to ignore SDP attributes they > don't understand. > > The fact that UDP and TLS appear in the m= line is kind of > unfortunate, but I think it can be interpreted as "do DTLS-SRTP". > > > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson > > wrote: > > On 2 June 2014 10:13, Harald Alvestrand > wrote: > > The current implementations both send "RTP/SAVPF" in this field. > But this > > usage is not specified by RFC 5764. > > Sounds easy to me. The SDP doesn't matter and can say anything. > "RTP/SAVPF" is as good as any other sequence of octets. > > I'm sure that JSEP can include a requirement that is directly > contradictory to an existing RFC. That happens all the time. At > least this time it can be explicit. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090302010602070801010801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On the other side, keeping "RTP/SAVFP" would have allowed a server (SBC/MCU/etc) to send an offer without knowing in advance if the other side supports SDES or DTLS, by sending both the crypto and fingerprint attributes and let the receiver choose which one to use (as chrome has done until recently). I know that it is not important for webrtc, as DTLS is mandatory and SDES is a must not, but for supporting other legacy clients it may be easier for some of us.

Best regards
Sergio

El 03/06/2014 8:04, Justin Uberti escribió:
I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one has to guess at this from the presence of a=fingerprint, which seems dodgy, given that endpoints are free to ignore SDP attributes they don't understand.

The fact that UDP and TLS appear in the m= line is kind of unfortunate, but I think it can be interpreted as "do DTLS-SRTP".


On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 2 June 2014 10:13, Harald Alvestrand <harald@alvestrand.no> wrote:
> The current implementations both send "RTP/SAVPF" in this field. But this
> usage is not specified by RFC 5764.

Sounds easy to me.  The SDP doesn't matter and can say anything.
"RTP/SAVPF" is as good as any other sequence of octets.

I'm sure that JSEP can include a requirement that is directly
contradictory to an existing RFC.  That happens all the time.  At
least this time it can be explicit.

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



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

--------------090302010602070801010801-- From nobody Tue Jun 3 02:08:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5051A0188 for ; Tue, 3 Jun 2014 02:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 opBfMmfE6nZ4 for ; Tue, 3 Jun 2014 02:08:17 -0700 (PDT) Received: from smtpdg95.aruba.it (smtpdg95.aruba.it [62.149.158.95]) by ietfa.amsl.com (Postfix) with ESMTP id 73DC11A00FC for ; Tue, 3 Jun 2014 02:08:16 -0700 (PDT) Received: from lminiero ([143.225.229.180]) by smtpcmd05.ad.aruba.it with bizsmtp id 9l871o01C3uAlfT01l88tl; Tue, 03 Jun 2014 11:08:09 +0200 Date: Tue, 3 Jun 2014 11:08:07 +0200 From: Lorenzo Miniero To: Sergio Garcia Murillo Message-ID: <20140603110807.0baf1982@lminiero> In-Reply-To: <538D882B.5030502@gmail.com> References: <538CB0C7.6050700@alvestrand.no> <538D882B.5030502@gmail.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ezVM_f3vdkERl_vKzTV0_I67a60 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:08:18 -0000 On Tue, 03 Jun 2014 10:32:43 +0200 Sergio Garcia Murillo wrote: > On the other side, keeping "RTP/SAVFP" would have allowed a server=20 > (SBC/MCU/etc) to send an offer without knowing in advance if the > other side supports SDES or DTLS, by sending both the crypto and > fingerprint attributes and let the receiver choose which one to use > (as chrome has done until recently). I know that it is not important > for webrtc, as DTLS is mandatory and SDES is a must not, but for > supporting other legacy clients it may be easier for some of us. >=20 > Best regards > Sergio >=20 I guess that was the rationale for having RTP/SAVPF in the first place, as initially both SDES and DTLS-SRTP were allowed. There are people confused about not having UDP/TLS/RTP/SAVPF now that DTLS-SRTP is mandatory (Asterisk developers, for instance, although getting it to work from a signalling point of view is a trivial replace matter in JavaScript), but I agree it makes sense to keep RTP/SAVPF, if not just because all browser implementations right now (the legacy of a few months from now on) only accept that, which would render them useless having this change. Lorenzo =20 > El 03/06/2014 8:04, Justin Uberti escribi=C3=B3: > > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it=20 > > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one > > has to guess at this from the presence of a=3Dfingerprint, which > > seems dodgy, given that endpoints are free to ignore SDP attributes > > they don't understand. > > > > The fact that UDP and TLS appear in the m=3D line is kind of=20 > > unfortunate, but I think it can be interpreted as "do DTLS-SRTP". > > > > > > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson=20 > > > wrote: > > > > On 2 June 2014 10:13, Harald Alvestrand > > wrote: > > > The current implementations both send "RTP/SAVPF" in this > > > field. > > But this > > > usage is not specified by RFC 5764. > > > > Sounds easy to me. The SDP doesn't matter and can say anything. > > "RTP/SAVPF" is as good as any other sequence of octets. > > > > I'm sure that JSEP can include a requirement that is directly > > contradictory to an existing RFC. That happens all the time. > > At least this time it can be explicit. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Jun 3 02:16:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103DF1A017F for ; Tue, 3 Jun 2014 02:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B1MBMUGNYYSO for ; Tue, 3 Jun 2014 02:16:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAE41A017C for ; Tue, 3 Jun 2014 02:16:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-62-538d9258de0d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 80.F1.28642.8529D835; Tue, 3 Jun 2014 11:16:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 11:16:08 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw Date: Tue, 3 Jun 2014 09:16:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> In-Reply-To: <538CB0C7.6050700@alvestrand.no> 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+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW7EpN5gg01/lC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGUcOlVRMJutYsaNQ4wNjJ9Yuhg5OSQETCR+ rF/JCmGLSVy4t56ti5GLQ0jgKKPE3A+3WCGcRYwSW4+uZexi5OBgE7CQ6P6nDdIgIhAs0fv8 PSOILSzgK9Fy7AMzRDxA4u6iJ0wQtpHE21lbwWpYBFQk/h9uA1vMC1Q/9dV2sLiQgI7EqWtn wWxOAV2J46fmgh3ECHTQ91NrwOYwC4hL3HoynwniUAGJJXvOM0PYohIvH/+DekBR4ur05VD1 OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSk l1qUmVxcnJ+nl5dasokRGCUHt/y22sF48LnjIUYBDkYlHt4Hn3uChVgTy4orcw8xSnOwKInz XtSoDhYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyHa3x8AkZ1Ht5HaZu6f8VjIIFauIrzix Pjx4+paki3v3sjdYS6h6lj+/27PVvoZrXulujyINltUKNa5zEzf7Hzhw5rVvwTEpxyjzM/da NeKPb6/zTTii0qS81TBm216Fpb6bLA6rzlc6IXnwzb/070q1DtfKQyPWvp64g+/t+qUT2aQF FVOPKLEUZyQaajEXFScCACBF90ZzAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GinpsU1cBnyWXpkEdrGdMZ4bCMQ Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:16:17 -0000 Hi Harald, >Given the nature of ICE, flows may shift back and forth between TCP candid= ates and UDP candidates over the lifetime of the flow, without any new SDP = negotiation being invoked. Is that really true? 1) When the selected candidates have been chosen, and updated offer is sent= where the c/m- lines represent the selected candidates 2) Media is sent only using the selected candidates 3) Keep-alives etc are sent only using the selected candidates (which means= that switching to other candidates "on the fly" may not even work) 4) If you want to change the selected candidates, you need to do an ICE res= tart, new candidate nominations, and new selected (which means a new offer)= . Or, did I misunderstand what you said? :) Regards, Christer From nobody Tue Jun 3 02:35:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A071A0197 for ; Tue, 3 Jun 2014 02:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 8yGYX5RycKWz for ; Tue, 3 Jun 2014 02:35:30 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DB01A018C for ; Tue, 3 Jun 2014 02:35:30 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so12958136qgd.1 for ; Tue, 03 Jun 2014 02:35: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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=jK18XsXTGGFbMW/LnWlInerKR3S30jyJRo2NN201S+0=; b=N8OSLpBSu4o4sIFKiI8CJgvTC8Uk2QMb7PwQvIm5BI1vdMqiUDZO/9bsF5VS6qY9o5 lTJYmZyCwwY6VqwosL7oRvLzqjjXSNQ09HqMdsRGnmg6FiIzy53o7GANehyR4CgoR+fa blCObxe21VVVvAz24QGhj3jG/m8hiDwfu2CvmjA1H7fwv2sdtrGL8KMVE4gmgsJYMHU0 BTqyAGLDbIdT1rKYmQp2XR5LqrjfyvwJ4RPY9SmawcP9CTszGDB21qphQeUEfnhJjx9J YktUcw6pqlw2HwyrBKTmqTGNXmyS32pI4+QkAk2DfTHcgExmH+DU51XOQibh9mEmC2uk ZwLg== X-Gm-Message-State: ALoCoQmrmt7OatdzZ6bPBtnVocEqje2Fr++oGjiw+09x9LhiEI/nQruL6tmefH+lCHN73cpXerlX X-Received: by 10.224.119.131 with SMTP id z3mr57063220qaq.91.1401788124656; Tue, 03 Jun 2014 02:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 02:35:03 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 11:35:03 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lDMe79k9phR1jzGpxW88oFDClao Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:35:32 -0000 2014-06-03 11:16 GMT+02:00 Christer Holmberg : > 1) When the selected candidates have been chosen, and updated offer is se= nt where the c/m- lines represent the selected candidates > > 2) Media is sent only using the selected candidates > > 3) Keep-alives etc are sent only using the selected candidates (which mea= ns that switching to other candidates "on the fly" may not even work) > > 4) If you want to change the selected candidates, you need to do an ICE r= estart, new candidate nominations, and new selected (which means a new offe= r). Please, may we forget this constrain/requirement in RFC 5245 that is 100% useless? By following ICE procedures both peers agree on which candidate-pair to use, and there is no need at all to force a "new SDP offer" indicating the selected pair since both peers already know that. And to prove it, let's take a look to WebRTC browsers as none of them "generates a new SDP offer if the winning ICE candidate-pair does not match the candidate in the m=3D line". Best regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 02:51:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73A71A00A3 for ; Tue, 3 Jun 2014 02:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpNQXQ61roJ4 for ; Tue, 3 Jun 2014 02:51:18 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3DC1A00C0 for ; Tue, 3 Jun 2014 02:51:18 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id q8so3221995lbi.26 for ; Tue, 03 Jun 2014 02:51: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8jKTijxXpLlMEjYoNP89eBARMnrk161An2zyn9VWgvs=; b=lUj05raLyrYP6frytpB2j/oiT6ij77HbWZyq1SkZqAwvioJlGMiutjpQKL33batghT M1QJkJnTg9YXATOBheY/fyPVYIsr6YgrL+L9VkKm36WjtSiLVp5iD+JAyN09zow1zeH/ BQ0ijV0JwtrxT+ykZlA824KS/Usv+CVeJKUI/NV0XtQpx+/WbZ65xfaj8pZan+UetxKu VkxEA/6ps7Ji6VuKrzwpUwrvabC6s1JKhtXvgVAFkBAOfYpG8yUWFVmc6ZqxQiJnytuI F1urRHzziaaJEDONO1DmpfdYeoeJd1P6gGRTU3iP5v7FMoOl9qbEwlR3by5auArmm5AD ftMg== X-Gm-Message-State: ALoCoQnjSE4b1T4r+WwxZ112aEl6rcfvAn+jpQuBcXYK8LKXIhb99XaxGFTLBE01tUVBLQpVfAVf X-Received: by 10.152.9.8 with SMTP id v8mr33984964laa.36.1401789071222; Tue, 03 Jun 2014 02:51:11 -0700 (PDT) Received: from camionet.local ([88.203.232.9]) by mx.google.com with ESMTPSA id i10sm13479056lah.13.2014.06.03.02.51.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 02:51:09 -0700 (PDT) Message-ID: <538D9A8B.4060002@jitsi.org> Date: Tue, 03 Jun 2014 12:51:07 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Christer Holmberg References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h-lMzhiXLaTPRu5fW8ByymSYHUg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:51:24 -0000 On 03.06.14, 12:35, Iħaki Baz Castillo wrote: > 2014-06-03 11:16 GMT+02:00 Christer Holmberg : >> 1) When the selected candidates have been chosen, and updated offer is sent where the c/m- lines represent the selected candidates >> >> 2) Media is sent only using the selected candidates >> >> 3) Keep-alives etc are sent only using the selected candidates (which means that switching to other candidates "on the fly" may not even work) >> >> 4) If you want to change the selected candidates, you need to do an ICE restart, new candidate nominations, and new selected (which means a new offer). > > > Please, may we forget this constrain/requirement in RFC 5245 that is > 100% useless? > > By following ICE procedures both peers agree on which candidate-pair > to use, and there is no need at all to force a "new SDP offer" > indicating the selected pair since both peers already know that. > > And to prove it, let's take a look to WebRTC browsers as none of them > "generates a new SDP offer if the winning ICE candidate-pair does not > match the candidate in the m= line". I believe Christer was talking about the need to send a new offer when you do an ICE restart. I don't think was about the part in RFC5245 that tells you to send a new offer once ICE is ready and that is only necessary for the benefit of signalling intermediaries. Emil -- https://jitsi.org From nobody Tue Jun 3 03:14:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407A91A0190 for ; Tue, 3 Jun 2014 03:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 8HVEPlxDDVLP for ; Tue, 3 Jun 2014 03:14:45 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4CE1A018A for ; Tue, 3 Jun 2014 03:14:45 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id j107so12682246qga.34 for ; Tue, 03 Jun 2014 03:14:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=3R3/wRirvzAAT2fiDfXUgYCdd0zrezfIO4xfyjIeSRU=; b=gA2srQ3LcfzOetBBDK2QLnZNR4nCndBlPgWc2A6HFiAXaz7FdxYHaV3VHBYy153D/I E1CjE43Am8wKvNlybz8VOMPnP3iTXVwm0Ni1DlPGUTkpdtI41Wg5zlrqg4fcCwegr1re GjnNcZi11dvvrS99QHi95BzY1WG5PoUZgjK/EDZFFJCchW7cM7YVHaidjBwD7I1dHPPE 6Nw2gBv+Rcf63MrCdaG7YpqT2Nf1oEEAPKO6SIk9YA0SNBeCrwqS6Yk+z1hNnFzlAjdr Q21XKtrwl9jyAey65BpMRwzs6fU3xar/JhWA+r7GhREjFYpb9rZov0+bOeyjMJO8hCZb cE5g== X-Gm-Message-State: ALoCoQnXg3ajmyCCMfSWWRtxahTdGuM4VeKcFp9+bC5UhpfdGOJ0uOstyVwqb0mAymqr8FeMGVgb X-Received: by 10.140.109.201 with SMTP id l67mr55132229qgf.72.1401790479533; Tue, 03 Jun 2014 03:14:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 03:14:19 -0700 (PDT) In-Reply-To: <538D9A8B.4060002@jitsi.org> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 12:14:19 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RYVBU5QrrmQNPKJIwbQ-Am-HQKo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:14:46 -0000 2014-06-03 11:51 GMT+02:00 Emil Ivov : > I believe Christer was talking about the need to send a new offer when yo= u > do an ICE restart. Once a candidate-pair is selected and used to transmit media, a device may check (after some time) the same candidate-pairs. And if it finds a better pair it may select it. There may be no need for a new SDP O/A in this case. Of course, in the case of mobility, interface changes, etc, signaling the ICE candidates from scratch is needed. > I don't think was about the part in RFC5245 that tells > you to send a new offer once ICE is ready and that is only necessary for = the > benefit of signalling intermediaries. That is 100% focused on SIP. Regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 04:35:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BAE1A01D3 for ; Tue, 3 Jun 2014 04:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy7FswQnvJ2Z for ; Tue, 3 Jun 2014 04:34:56 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761431A01C4 for ; Tue, 3 Jun 2014 04:34:56 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so2142899vcb.38 for ; Tue, 03 Jun 2014 04:34: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=ihznUMizEYM0a/RGqhG0xtZ02FI7MypdzyM+GQwwU/M=; b=KNMMq4cLYPXDBNn642P37J/fGh5cVnf+yTrDDSiVfSn26BtZDIAJ2cIndxjf+T8r+V HiOLcAmPrkv1M0lrceb7te5dZCLLik+q7bsYigD7kzvvBrquiNUZz/sQrKohesqkulRd kiiPlVlojI2c008potNkyChvfIEAAdlaxXR0pp75BPiALjEspN2b//ks0u1aSrg30piz QxeBaQ23TPeBsNAWlFe19xDVO23qa0xvWYxi+xZyE7B/oJwzEdgWqd3oiHqSmb7ruMJU C4SxmZK95tr/P5EYJ9nM9MdhSeAPR1nmcqv8O76yAmPjawhkKzBdvJnhqxYKXngE/v/M 2DuQ== X-Gm-Message-State: ALoCoQl4sfzV4BJpK6fH8G9ny1wPQxbxvKlpz1eKK7sJNCBIH21K1TYyhS8QlqZhldS6KDInyYpD X-Received: by 10.220.161.8 with SMTP id p8mr35910283vcx.4.1401795290210; Tue, 03 Jun 2014 04:34:50 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx.google.com with ESMTPSA id tp8sm14824680vdc.20.2014.06.03.04.34.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 04:34:48 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so3649476vcb.36 for ; Tue, 03 Jun 2014 04:34:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.246.132 with SMTP id xw4mr36297480vec.2.1401795288579; Tue, 03 Jun 2014 04:34:48 -0700 (PDT) Received: by 10.220.40.76 with HTTP; Tue, 3 Jun 2014 04:34:48 -0700 (PDT) Received: by 10.220.40.76 with HTTP; Tue, 3 Jun 2014 04:34:48 -0700 (PDT) In-Reply-To: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> Date: Tue, 3 Jun 2014 14:34:48 +0300 Message-ID: From: Emil Ivov To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7bd8fe9439673504faece625 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/choNxve9z5jfPJOuRNINgubEhf4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 11:34:58 -0000 --047d7bd8fe9439673504faece625 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03 Jun 2014 1:14 PM, "I=C3=B1aki Baz Castillo" wrote: > > 2014-06-03 11:51 GMT+02:00 Emil Ivov : > > I believe Christer was talking about the need to send a new offer when you > > do an ICE restart. > > Once a candidate-pair is selected and used to transmit media, a device > may check (after some time) the same candidate-pairs. And if it finds > a better pair it may select it. There may be no need for a new SDP O/A > in this case. That wouldn't work with current RFC5245 implementations (and I believe would cause problems) but if you want to make a proposal, mmusic would be the right place. > That is 100% focused on SIP. Yes, correct Emil --sent from my mobile --047d7bd8fe9439673504faece625 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 03 Jun 2014 1:14 PM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
>
> 2014-06-03 11:51 GMT+02:00 Emil Ivov <emcho@jitsi.org>:
> > I believe Christer was talking about the need to send a new offer= when you
> > do an ICE restart.
>
> Once a candidate-pair is selected and used to transmit media, a device=
> may check (after some time) the same candidate-pairs. And if it finds<= br> > a better pair it may select it. There may be no need for a new SDP O/A=
> in this case.

That wouldn't work with current=C2=A0 RFC5245 implementa= tions (and I believe would cause problems) but if you want to make a propos= al, mmusic would be the right place.

> That is 100% focused on SIP.

Yes, correct

Emil

--sent from my mobile

--047d7bd8fe9439673504faece625-- From nobody Tue Jun 3 04:52:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B731A01E0 for ; Tue, 3 Jun 2014 04:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD09R_0_AEIQ for ; Tue, 3 Jun 2014 04:52:54 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8DF1A01D5 for ; Tue, 3 Jun 2014 04:52:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E63F37C36B0 for ; Tue, 3 Jun 2014 13:52:47 +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 5hlnuNRaNfK8 for ; Tue, 3 Jun 2014 13:52:46 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id B72F37C36A2 for ; Tue, 3 Jun 2014 13:52:46 +0200 (CEST) Message-ID: <538DB70E.6020300@alvestrand.no> Date: Tue, 03 Jun 2014 13:52:46 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140519083842.21555.8626.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HFNIClrUcXYpnJ3_58bZKFOyzv8 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 11:52:57 -0000 On 06/02/2014 08:43 PM, Martin Thomson wrote: > On 2 June 2014 02:45, Ram Mohan R (rmohanr) wrote: >> >> I should have also stated that this would apply only for cases in which >> such use of multiple DSCPs was appropriate, as determined by DART. >> >> >> >> We did discuss this earlier and there was some support to use highest >> priority DSCP in case of BUNDLE. Here was the previous thread - >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11777.html >> I did not see any conclusion though on that topic. >> >> >> I am ok to have STUN packets to have highest DSCP when multiple DSCP >> values are used for a given 5-tuple (like in DART). The only issue I see >> is when there is a congestion then your STUN consent check packets would >> get preference over some of the other packets. I think this is ok as >> dropping a consent message means the sender is likely to stop sending >> media itself, if it does not see a consent refresh response. >> >> I will add the following text. Does this look ok ? >> >> "It is possible that different Diffserv Codepoints are used by >> different media over the same transport address as described in >> [I-D.ietf-tsvwg-rtcweb-qos]. In such cases, it is recommended to use >> the same DSCP for the STUN messages >> as that used for the highest priority media stream(s)." > I know that I haven't raised this point before, and I apologize for > not paying enough attention, but I don't think that we should be > talking about DSCP in this draft. > > Use of DSCP with STUN and the additional complications that BUNGLE > adds are best dealt with in those contexts. This was a simple > document, we should keep the scope constrained as much as possible. I think having BUNDLE depend on consent-freshness would be a Bad Thing. Probably the chairs should draw a tree of the various drafts and decide which draft can usefully say something about the relationship between RTP multiplexing (an -rtp- matter), DSCP (a -tsvwg- matter) and use of STUN (a -consent-freshness matter). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 3 04:57:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03ECA1A01D9 for ; Tue, 3 Jun 2014 04:57:10 -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 5IzRloVX0jnR for ; Tue, 3 Jun 2014 04:57:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2F01A01D5 for ; Tue, 3 Jun 2014 04:57:07 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-ee-538db80b1c4d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.5F.16420.B08BD835; Tue, 3 Jun 2014 13:57:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 13:56:59 +0200 From: Christer Holmberg To: Emil Ivov , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw///ow4CAAAR+gIAABnuAgAAWfQCAACRUEA== Date: Tue, 3 Jun 2014 11:56:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+JvjS7Pjt5gg+f7RS3W7JzAYjF9n43F 2n/t7A7MHuca3rN7LFnyk8nj/5vAAOYoLpuU1JzMstQifbsEroztqyazFvzhqZj09hhTA+MF ni5GTg4JAROJM99eMkPYYhIX7q1n62Lk4hASOMoosbHhMyuEs4hRYvaWx0AZDg42AQuJ7n/a IA0iAtES36d/YAexmQXUJe4sPgdmCwv4SrQc+8AMURMgcXfREyYIO0ziVfdlFhCbRUBFYuHm i8wgI3mB6mf+cYBY9YRJ4vHV56wgNZwCgRK7V98Hm8MIdNz3U2uYIHaJS9x6Mp8J4mgBiSV7 zkM9ICrx8vE/VghbUeLq9OVMIPOZBTQl1u/Sh2hVlJjS/RDsTF4BQYmTM5+wTGAUm4Vk6iyE jllIOmYh6VjAyLKKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCWDm75rbqD8fIbx0OMAhyM Sjy8Dz73BAuxJpYVV+YeYpTmYFES572oUR0sJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVH6 U8c/zbiu0+vz6ySLvjBLXSlxiXU6bpa2bnWLIeO/wH/bfjjzRqWrvJ4TItuTfSv5nfHGvOaX GsuylM2X6be3aZ+/dvSsh9L5p+GfTj4uuHqDfeKRf+uez88UcmA4zxNq3he29IVogcuUs+HG UWW6jYqiGjbluy9nF/x5GZrjfFVM6PwhJiWW4oxEQy3mouJEAMgGuNeGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JzLfU_92WjYIDOtOaH0BMavmf-Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 11:57:10 -0000 SGksDQoNCj4+PiBPbmNlIGEgY2FuZGlkYXRlLXBhaXIgaXMgc2VsZWN0ZWQgYW5kIHVzZWQgdG8g dHJhbnNtaXQgbWVkaWEsIGEgZGV2aWNlDQo+Pj4gbWF5IGNoZWNrIChhZnRlciBzb21lIHRpbWUp IHRoZSBzYW1lIGNhbmRpZGF0ZS1wYWlycy4gQW5kIGlmIGl0IGZpbmRzDQo+Pj4gYSBiZXR0ZXIg cGFpciBpdCBtYXkgc2VsZWN0IGl0LiANCg0KTm9ib2R5IGNhbiBvZiBjb3Vyc2UgcHJldmVudCBp bXBsZW1lbnRhdGlvbnMgZnJvbSBjaGVja2luZyB3aGV0aGVyIHByZXZpb3VzbHkgbm9taW5hdGVk IChidXQgbm90IHNlbGVjdGVkKSBjYW5kaWRhdGVzIHN0aWxsIHdvcmsuIEhvd2V2ZXIsIEkgYW0g bm90IHN1cmUgd2hldGhlciBlbnRpdGllcyBlLmcuIG11c3QgcmVzcG9uZCB0byBjb25uZWN0aXZp dHkgY2hlY2tzIGZyb20gc3VjaCBlbnRpdGllcy4NCg0KPj4+IFRoZXJlIG1heSBiZSBubyBuZWVk IGZvciBhIG5ldyBTRFAgTy9BDQo+Pj4gaW4gdGhpcyBjYXNlLg0KPj4+DQo+Pj4gVGhhdCB3b3Vs ZG4ndCB3b3JrIHdpdGggY3VycmVudMKgIFJGQzUyNDUgaW1wbGVtZW50YXRpb25zIChhbmQgSSBi ZWxpZXZlIHdvdWxkIGNhdXNlIHByb2JsZW1zKSBidXQgaWYgeW91IHdhbnQgdG8gbWFrZSBhIHBy b3Bvc2FsLCBtbXVzaWMgd291bGQgYmUgdGhlIHJpZ2h0IHBsYWNlLg0KPj4gVGhhdCBpcyAxMDAl IGZvY3VzZWQgb24gU0lQLg0KPiBZZXMsIGNvcnJlY3QNCg0KSXQgaXMgZm9jdXNlZCBvbiBlbnZp cm9ubWVudHMgd2hlcmUgaW50ZXJtZWRpYXJpZXMgbWFrZSBtZWRpYSBkZWNpc2lvbnMgYmFzZWQg b24gdGhlIHNpZ25hbGluZy4gU0lQIGlzIG9mIGNvdXJzZSBhbiBvYnZpb3VzIGV4YW1wbGUuDQoN CkJ1dCwgbmV2ZXIgdGhlIGxlc3MsIGFzIGZhciBhcyBJIGtub3cgd2UgaGF2ZSBhZG9wdGVkIFJG QzUyNDUgLSBub3QgYSBwcm9maWxlIG9mIFJGQzUyNDUgLSB3aGljaCBtZWFuczoNCg0KMSkgSUNF IHJlc3RhcnQgaW4gY2FzZSB5b3Ugd2FudCB0byBjaGFuZ2UgdGhlIHNlbGVjdGVkIGNhbmRpZGF0 ZSBwYWlyOyBhbmQNCg0KMikgc2VuZGluZyBhIG5ldyBvZmZlciBpZiBhIG5ldyBjYW5kaWRhdGUg cGFpciBpcyBjaG9zZW4gYXMgdGhlIHNlbGVjdGVkDQoNCipJRiogd2UgZGVjaWRlIHRvIGNoYW5n ZSBpdCwgdGhlbiBpdCBzaG91bGQgYmUgcHJvcGVybHkgZG9jdW1lbnRlZC4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0K From nobody Tue Jun 3 05:02:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FC71A01E5 for ; Tue, 3 Jun 2014 05:02:02 -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 w1ooVhoVvFEe for ; Tue, 3 Jun 2014 05:02:01 -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 4035C1A01DE for ; Tue, 3 Jun 2014 05:02:00 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-0b-538db931afe5 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.42.25910.139BD835; Tue, 3 Jun 2014 14:01:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 14:01:52 +0200 From: Christer Holmberg To: Emil Ivov , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw///ow4CAAAR+gIAARY2g Date: Tue, 3 Jun 2014 12:01:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E2F6@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> In-Reply-To: <538D9A8B.4060002@jitsi.org> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvja7hzt5gg1l9whZrdk5gsZi+z8Zi 7b92dgdmj3MN79k9liz5yeTx/01gAHMUl01Kak5mWWqRvl0CV8am+W2MBd9YKtYtzG1gfMLS xcjJISFgInGo8zAbhC0mceHeeiCbi0NI4CijxMo5i9khnEWMElf2H2LqYuTgYBOwkOj+pw3S ICIQLfF9+gd2EJtZQF3izuJzYLawgK9Ey7EPzBA1ARJ3Fz1hgrDdJPqfPwerYRFQkfiy7RIr iM0LVH/35E8miF3XGCXOX/sDdh2ngKbE9OkQRYxA130/tYYJYpm4xK0n85kgrhaQWLLnPDOE LSrx8vE/VghbUeLq9OVgNzMDzVm/Sx+iVVFiSvdDdoi9ghInZz5hmcAoNgvJ1FkIHbOQdMxC 0rGAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmAsHdzy22AH48vnjocYBTgYlXh4H3zu CRZiTSwrrsw9xCjNwaIkzntRozpYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+PKx0bt/9Is OUPXdBtPypCqc6zgW5ywkE/v297ZMs3b1z76sahe9mBIzJPsuo+3Cm6/dGxcsW2DqNdV1S// H79cWXAm2JLN4cadh3On3JL9dqFQn98880lbCpfK75hPD/zn7T0xWaf3avnVYwsUi9sPb+Dj P3ZriejVWN3eD9daRU6YsOzKNrqlxFKckWioxVxUnAgAi0bEaoYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YB1rZhfRVJ3y-Hg-xzIo5bxem7s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:02:02 -0000 SGksDQoNCj4gSSBiZWxpZXZlIENocmlzdGVyIHdhcyB0YWxraW5nIGFib3V0IHRoZSBuZWVkIHRv IHNlbmQgYSBuZXcgb2ZmZXIgd2hlbiB5b3UgZG8gYW4gSUNFIHJlc3RhcnQuIEkgZG9uJ3QgdGhp bmsgd2FzIGFib3V0IHRoZSBwYXJ0IGluIFJGQzUyNDUgdGhhdCB0ZWxscyB5b3UgdG8gc2VuZCBh IA0KPiBuZXcgb2ZmZXIgb25jZSBJQ0UgaXMgcmVhZHkgYW5kIHRoYXQgaXMgb25seSBuZWNlc3Nh cnkgZm9yIHRoZSBiZW5lZml0IG9mIHNpZ25hbGxpbmcgaW50ZXJtZWRpYXJpZXMuDQoNCkkgZ3Vl c3MgSSB3YXMgdGFsa2luZyBhYm91dCBib3RoIDopDQoNCihPZiBjb3Vyc2UsIGlmIHRoZSBjdXJy ZW50IGMvbS0gbGluZSBkYXRhIG1hdGNoIHRoZSBzZWxlY3RlZCBjYW5kaWRhdGUgZGF0YSwgdGhl cmUgaXMgbm8gbmVlZCB0byBzZW5kIGFuIG9mZmVyKQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQo= From nobody Tue Jun 3 05:12:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7A1A01E5 for ; Tue, 3 Jun 2014 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0FIAcUuA3kI for ; Tue, 3 Jun 2014 05:12:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107BC1A01D9 for ; Tue, 3 Jun 2014 05:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3527; q=dns/txt; s=iport; t=1401797522; x=1403007122; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nKopHCPoc3Zk9wuMHHUDXaYeRBzWeuumg72FMdgzxL0=; b=GEvSgbXzB2RTULBiW6X2/w/C9P8tblagWum8D/e1IIPu5LRRDsc/UzDX xfGVki+TpDXfBgmhNyv0mxLiL42EVTBr7nNWkSGctDeL1u4JBMkwb7B1Y OsvquVt4F8MHoZ0voaDjtzTDE+LWLEixprHk4DNI1rf2QUjCqFcvrKlXb 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAOG6jVOtJV2Y/2dsb2JhbABZgwdSWLslhmhRAYENFnSCJQEBAQQBAQE3NAQTBAIBCBEDAQIBHhAnCx0IAgQBEgmIOQ3RdBeNbxIBAVEFBoQ6BJoDkzGDOGyBCjk X-IronPort-AV: E=Sophos;i="4.98,964,1392163200"; d="scan'208";a="330183716" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jun 2014 12:12:01 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s53CC1ne003265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 12:12:01 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.106]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 07:12:01 -0500 From: "Ram Mohan R (rmohanr)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt Thread-Index: AQHPfyUFoT5bJEhrx02EK/lO8B72yA== Date: Tue, 3 Jun 2014 12:12:00 +0000 Message-ID: References: <20140519083842.21555.8626.idtracker@ietfa.amsl.com> <538DB70E.6020300@alvestrand.no> In-Reply-To: <538DB70E.6020300@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.66.108] Content-Type: text/plain; charset="us-ascii" Content-ID: <999AD496A9944143BF9EC666D4C4B937@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/b28qQWQz9wRhXekp7b0HUyZMmsE Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:12:10 -0000 Please see inline -----Original Message----- From: Harald Alvestrand Date: Tuesday, 3 June 2014 5:22 pm To: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt >On 06/02/2014 08:43 PM, Martin Thomson wrote: >> On 2 June 2014 02:45, Ram Mohan R (rmohanr) wrote: >>> >>> I should have also stated that this would apply only for cases in which >>> such use of multiple DSCPs was appropriate, as determined by DART. >>> >>> >>> >>> We did discuss this earlier and there was some support to use highest >>> priority DSCP in case of BUNDLE. Here was the previous thread - >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11777.html >>> I did not see any conclusion though on that topic. >>> >>> >>> I am ok to have STUN packets to have highest DSCP when multiple DSCP >>> values are used for a given 5-tuple (like in DART). The only issue I >>>see >>> is when there is a congestion then your STUN consent check packets >>>would >>> get preference over some of the other packets. I think this is ok as >>> dropping a consent message means the sender is likely to stop sending >>> media itself, if it does not see a consent refresh response. >>> >>> I will add the following text. Does this look ok ? >>> >>> "It is possible that different Diffserv Codepoints are used by >>> different media over the same transport address as described in >>> [I-D.ietf-tsvwg-rtcweb-qos]. In such cases, it is recommended to >>>use >>> the same DSCP for the STUN messages >>> as that used for the highest priority media stream(s)." >> I know that I haven't raised this point before, and I apologize for >> not paying enough attention, but I don't think that we should be >> talking about DSCP in this draft. >> >> Use of DSCP with STUN and the additional complications that BUNGLE >> adds are best dealt with in those contexts. This was a simple >> document, we should keep the scope constrained as much as possible. > >I think having BUNDLE depend on consent-freshness would be a Bad Thing. > >Probably the chairs should draw a tree of the various drafts and decide >which draft can usefully say something about the relationship between >RTP multiplexing (an -rtp- matter), DSCP (a -tsvwg- matter) and use of >STUN (a -consent-freshness matter). We added this text in this document initially as we did not have any other place holder. All other STUN usage drafts (like ICE RFC) do have text about DiffServ treatment and so we felt this draft also should talk about DiffServ treatment for STUN consent freshness. Consent freshness when BUNDLE is used has dependency on other documents( BUNDLE draft, DART draft) which are a work in progress. I agree having the text on consent freshness for BUNDLE would make the scope of this draft larger and perhaps slow the progress of this document. I am ok to move the text related to BUNDLE out of this draft but then it has to be put some where and linked with consent freshness. I will leave it to the Chairs to decide which is the best way forward for this.=20 Ram > > > > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 3 05:17:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF961A01E7 for ; Tue, 3 Jun 2014 05:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BJk5V8uP539 for ; Tue, 3 Jun 2014 05:17:00 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 49E8C1A01F3 for ; Tue, 3 Jun 2014 05:17:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 20BA17C36B1 for ; Tue, 3 Jun 2014 14:16:54 +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 o5I6l+maibJh for ; Tue, 3 Jun 2014 14:16:53 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2C8B67C36B0 for ; Tue, 3 Jun 2014 14:16:53 +0200 (CEST) Message-ID: <538DBCB3.3030408@alvestrand.no> Date: Tue, 03 Jun 2014 14:16:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4R2IGOlinv46FWUSal-nzIRpIJA Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:17:02 -0000 On 06/03/2014 01:56 PM, Christer Holmberg wrote: > Hi, > >>>> Once a candidate-pair is selected and used to transmit media, a device >>>> may check (after some time) the same candidate-pairs. And if it finds >>>> a better pair it may select it. > Nobody can of course prevent implementations from checking whether previously nominated (but not selected) candidates still work. However, I am not sure whether entities e.g. must respond to connectivity checks from such entities. > >>>> There may be no need for a new SDP O/A >>>> in this case. >>>> >>>> That wouldn't work with current RFC5245 implementations (and I believe would cause problems) but if you want to make a proposal, mmusic would be the right place. >>> That is 100% focused on SIP. >> Yes, correct > It is focused on environments where intermediaries make media decisions based on the signaling. SIP is of course an obvious example. > > But, never the less, as far as I know we have adopted RFC5245 - not a profile of RFC5245 - which means: > > 1) ICE restart in case you want to change the selected candidate pair; and > > 2) sending a new offer if a new candidate pair is chosen as the selected Does it? 11.1.3. Procedures for All Implementations ICE has interactions with jitter buffer adaptation mechanisms. An RTP stream can begin using one candidate, and switch to another one, though this happens rarely with ICE. The newer candidate may result in RTP packets taking a different path through the network -- one with different delay characteristics. As discussed below, agents are encouraged to re-adjust jitter buffers when there are changes in source or destination address of media packets. Furthermore, many audio codecs use the marker bit to signal the beginning of a talkspurt, for the purposes of jitter buffer adaptation. For such codecs, it is RECOMMENDED that the sender set the marker bit [RFC3550] when an agent switches transmission of media from one candidate pair to another. 11.2. Receiving Media ICE implementations MUST be prepared to receive media on each component on any candidates provided for that component in the most recent offer/answer exchange (in the case of RTP, this would include both RTP and RTCP if candidates were provided for both). It is RECOMMENDED that, when an agent receives an RTP packet with a new source or destination IP address for a particular media stream, that the agent re-adjust its jitter buffers. I would never want to call RFC 5245 a model of clarity, but it seems to me that this language was written in the expectation that a sender might choose to switch to a different pair at any time. I can't find the corresponding paragraph that says when the sender might do so, though. > > *IF* we decide to change it, then it should be properly documented. > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 3 05:22:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1BF1A0229 for ; Tue, 3 Jun 2014 05:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ6B71Pk2Bol for ; Tue, 3 Jun 2014 05:22:09 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F751A01F9 for ; Tue, 3 Jun 2014 05:22:07 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id dc16so4750914qab.0 for ; Tue, 03 Jun 2014 05:22:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=PAWe5wTP5L+nci8uaanvPdguaalqQW7fAUeg/0ahsRg=; b=YBsVd82pHD2A0nzoKGSWVw4j7YsJ47Ge/Y4HZ0hGoefEYtX7xhFZ+L9GN/e97TAgLB sUd0LbgffQu+2ENEXp1lNTMB538vDL+U+7mwAQPHOgVNGl0XSClKguB0equLCbzkTkPS cDR5npjCZxTHbyt9rENd+G9UzgxMGM8B8KB8BoUCNhXFZJS+G95SH/e7iIX+3JJVs0RV s/Cn6wlptFEIWF/e1L/QhO4vzSnNuxBp8HrPI/dxPOC5i37FDSLuFTzjXvEBqYEyUBCl 6CseSDMn6pBbdDHkkAiI5Q2VXjZRcwz+vX914btwtm9jYJHHobfWg0toGhE7VnzCxGU5 OCZQ== X-Gm-Message-State: ALoCoQn60QvqVi/VhLtNVgk8gJOwwZ6G4pwuUl98OTwR6hk3hi2Az+ErdQsy1SOcW4ZdjRkaxTz1 X-Received: by 10.140.47.18 with SMTP id l18mr56898077qga.9.1401798121239; Tue, 03 Jun 2014 05:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 05:21:41 -0700 (PDT) In-Reply-To: <538DBCB3.3030408@alvestrand.no> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 14:21:41 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/q1yo_mT_jj8cFI2lVYJxHc42R-M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:22:10 -0000 2014-06-03 14:16 GMT+02:00 Harald Alvestrand : > I would never want to call RFC 5245 a model of clarity, but it seems to m= e > that this language was written in the expectation that a sender might cho= ose > to switch to a different pair at any time. +1 > I can't find the corresponding paragraph that says when the sender might = do > so, though. IMHO if it's not defined when it can do that then it MUST be able to do that at any time. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 05:24:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E371A01DF for ; Tue, 3 Jun 2014 05:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6zDnxnRPKfR for ; Tue, 3 Jun 2014 05:24:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAA41A0225 for ; Tue, 3 Jun 2014 05:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5839; q=dns/txt; s=iport; t=1401798234; x=1403007834; h=from:to:subject:date:message-id:mime-version; bh=zNlDKmMEEhGUINK55/9WXKmA9+8ejgUZ8WUxvW22aqQ=; b=HcMvZ5tPtGH53t/f8D1UdkMJGD4M+NEPmXybn1plKOaKLNviZFsZO1S0 Z6yuslx8CZkwvJgt2TiHuT5UieWW8fvIWD7JEPE6+PefbNYhN4imKi6/w 4m7MfnNxdls+/p/iFHTRKBAMlQTP6lVsif4YQVli1TODZLtJpkgthCOBo A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAEG9jVOtJA2I/2dsb2JhbABZgkJFUljCXoEOFnSCJQECBC1eAQgRAwECKDkUCQoEARKIQtIHF45BhFgEmgOTMYM4gi8 X-IronPort-AV: E=Sophos; i="4.98,964,1392163200"; d="scan'208,217"; a="49702395" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 03 Jun 2014 12:23:53 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s53CNrXo023350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 12:23:53 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.106]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 07:23:53 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Continous consent when no media is sent Thread-Index: AQHPfyauOJVedlPuoUWlfGriQTFxJw== Date: Tue, 3 Jun 2014 12:23:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.66.108] Content-Type: multipart/alternative; boundary="_000_CFB3BBF88F7C2rmohanrciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9J9KQNR4wgiaivAwUkw4TyF_6Tg Subject: Re: [rtcweb] Continous consent when no media is sent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:24:03 -0000 --_000_CFB3BBF88F7C2rmohanrciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Agree. I will remove the =93recvonly=94 keyword from that sentence. Then I = believe it will cover for all cases where a endpoint is only receiving medi= a and not sending. Is that sufficient ? Regards, Ram From: Christer Holmberg > Date: Tuesday, 3 June 2014 1:25 pm To: "rtcweb@ietf.org" > Subject: [rtcweb] Continous consent when no media is sent Hi, Section 4.1 of draft-ietf-rtcweb-stun-consent-freshness-03 says: =93An endpoint that is only receiving application traffic (recvonly) does not need to obtain consent which can slightly conserve= its resources.=94 I think it would be good to be more generic, and talk about cases where the= sender does not send media. That is obviously true in case of =93recvonly= =94, but it could also be true in other cases. In addition, I guess the no-need-to-send-consent rule also applies to =93in= active=94 streams. Regards, Christer --_000_CFB3BBF88F7C2rmohanrciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <019729B103DF80468078319AA9319829@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi 

Agree. I will remove the =93recvonly=94 keyword from that sentence. Th= en I believe it will cover for all cases where a endpoint is only receiving= media and not sending. Is that sufficient ?

Regards,
Ram

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, 3 June 2014 1:25 pm<= br> To: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: [rtcweb] Continous consent= when no media is sent

Hi,

 

Section 4.1 of draft-ietf-rtcweb-stun-consent-freshn= ess-03 says:

 

=93An endpoint that is = only receiving application traffic (recvonly)

         &nb= sp;      does not need to obtain consent which can= slightly conserve its

         &nb= sp;      resources.=94

 

I think it would be good to be more generic, and tal= k about cases where the sender does not send media. That is obviously true = in case of =93recvonly=94, but it could also be true in other cases.

 

In addition, I guess the no-need-to-send-consent rul= e also applies to =93inactive=94 streams.

 

Regards,

 

Christer

 --_000_CFB3BBF88F7C2rmohanrciscocom_-- From nobody Tue Jun 3 05:26:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633C51A01E7 for ; Tue, 3 Jun 2014 05:26:46 -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 CClKFJ6WFK2N for ; Tue, 3 Jun 2014 05:26:44 -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 10E501A01F7 for ; Tue, 3 Jun 2014 05:26:41 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-e1-538dbefa6bae Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 45.24.16420.AFEBD835; Tue, 3 Jun 2014 14:26:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 14:26:34 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw///ow4CAAAR+gIAABnuAgAAWfQCAACRUEP//52uAgAAidEA= Date: Tue, 3 Jun 2014 12:26:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E462@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> In-Reply-To: <538DBCB3.3030408@alvestrand.no> 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+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje7vfb3BBlPnMVkc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4clqp4Jl0xYbGDrYGxgeiXYycHBICJhJr Nh1jh7DFJC7cW8/WxcjFISRwlFHiYNcFVpCEkMAiRok3u1O7GDk42AQsJLr/aYOERQSCJXqf v2cEsYUFfCVajn1ghogHSNxd9IQJwk6SOP1hGVicRUBF4ljHZTYQmxeofvnRh0wQu04zSzS+ /80CkuAU0JW48fETmM0IdND3U2vABjELiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsBUlrk5f DlWvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnp RsZ6qUWZycXF+Xl6eaklmxiBUXJwy2/VHYyX3zgeYhTgYFTi4X3wuSdYiDWxrLgy9xCjNAeL kjjvRY3qYCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MBeH3XRt2XvfLnSj/3ePhn4csS2fw p93f98fB7cjHSbkFP9JPpLrvjrLneHbcN5VTY84rzXM/X8+9bSOdf/VrOkfMp2fbXmovl3wS obhslt3hG2JWLBIthfXbKybqeXyczJ163eZ80B5G03uRbl1uhwv9dqYkukU0ZnicmOe/sEEg kZVRkveAEktxRqKhFnNRcSIAJTQr3HMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nzlnBKfutZQEjcs5mgDZrJ38fAE Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:26:46 -0000 Hi, >>>>> Once a candidate-pair is selected and used to transmit media, a=20 >>>>> device may check (after some time) the same candidate-pairs. And if=20 >>>>> it finds a better pair it may select it. >> Nobody can of course prevent implementations from checking whether previ= ously nominated (but not selected) candidates still work. However, I am not= sure whether entities e.g. must respond to connectivity checks from such e= ntities. >> >>>>> There may be no need for a new SDP O/A in this case. >>>>> >>>>> That wouldn't work with current RFC5245 implementations (and I belie= ve would cause problems) but if you want to make a proposal, mmusic would b= e the right place. >>>> That is 100% focused on SIP. >>> Yes, correct >> It is focused on environments where intermediaries make media decisions = based on the signaling. SIP is of course an obvious example. >> >> But, never the less, as far as I know we have adopted RFC5245 - not a pr= ofile of RFC5245 - which means: >> >> 1) ICE restart in case you want to change the selected candidate pair;=20 >> and >> >> 2) sending a new offer if a new candidate pair is chosen as the=20 >> selected > > Does it? > > 11.1.3. Procedures for All Implementations > > ICE has interactions with jitter buffer adaptation mechanisms. An > RTP stream can begin using one candidate, and switch to another one, > though this happens rarely with ICE. The newer candidate may result > in RTP packets taking a different path through the network -- one > with different delay characteristics. As discussed below, agents are > encouraged to re-adjust jitter buffers when there are changes in > source or destination address of media packets. Furthermore, many > audio codecs use the marker bit to signal the beginning of a > talkspurt, for the purposes of jitter buffer adaptation. For such > codecs, it is RECOMMENDED that the sender set the marker bit > [RFC3550] when an agent switches transmission of media from one > candidate pair to another. > > >11.2. Receiving Media > > ICE implementations MUST be prepared to receive media on each > component on any candidates provided for that component in the most > recent offer/answer exchange (in the case of RTP, this would include > both RTP and RTCP if candidates were provided for both). > > It is RECOMMENDED that, when an agent receives an RTP packet with a > new source or destination IP address for a particular media stream, > that the agent re-adjust its jitter buffers. I guess this could happen during session establishment if you use aggressiv= e nomination, where you may indicate a candidate pair as selected, but then= switch to another. But, the RFC still says that you send a new offer when = such switch occur. > I would never want to call RFC 5245 a model of clarity, but it seems to m= e that this language was written in the expectation that a sender might cho= ose to switch to a different pair at any time. > > I can't find the corresponding paragraph that says when the sender might = do so, though. Perhaps what you are talking about is related to the MICE work? It's a while since I read the MICE draft, so I don't remember the details. = There, I think you can use multiple candidate pairs alive, but I don't reme= mber whether you can switch without sending a new offer. In any case, if there is something unclear about ICE, I guess we should bri= ng it to MMUSIC :) Regards, Christer From nobody Tue Jun 3 05:29:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F111A01F7 for ; Tue, 3 Jun 2014 05:29:44 -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 G-VBYoq_98RB for ; Tue, 3 Jun 2014 05:29:42 -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 43A7C1A020A for ; Tue, 3 Jun 2014 05:29:42 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-03-538dbfafa30c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.C6.25910.FAFBD835; Tue, 3 Jun 2014 14:29:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 14:29:34 +0200 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Continous consent when no media is sent Thread-Index: AQHPfyauOJVedlPuoUWlfGriQTFxJ5tfUCiQ Date: Tue, 3 Jun 2014 12:29:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E474@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje76/b3BBt+3i1os79rBaLH2Xzu7 A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVxdd8i5oJ/nBVLX9g0MLZxdDFyckgImEhc e/CLBcIWk7hwbz0biC0kcJRRYt8Hjy5GLiB7EaPEoxPzgRIcHGwCFhLd/7RBakQEwiSmn1jA AhIWFrCVaJqkBWKKCNhJbGjMgqgwkpj5sQdsIouAisTKttmsIDavgK/EzY7rLBCb9CRe7jgP ZnMK6EtsWNnHDmIzAl3z/dQaJhCbWUBc4taT+UwQVwpILNlznhnCFpV4+fgfK4StKHF1+nKo ej2JG1OnsEHY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy 0kstykwuLs7P08tLLdnECIyPg1t+G+xgfPnc8RCjAAejEg/vg889wUKsiWXFlbmHGKU5WJTE eS9qVAcLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOS+4ucarjXzWU3voveJuX+fOjCf/Gft 3pR3n+NHzE+bjxOeZF0xnXUsKCt1zcebRokrIyNu6O7/HP1+WQqn7m5/M9vMuRMPSz39xrFX PNlb3tJXc/12SYlGu9oJ8pxPnI7svqN2r5fnq/XKKdP1BY9+L+7galy7TeuihrvIFFajN618 Ade1VyixFGckGmoxFxUnAgDRtejncAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xod6WG9tm7t6JBbaQ_fvJdIHMVU Subject: Re: [rtcweb] Continous consent when no media is sent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:29:44 -0000 Hi, >Agree. I will remove the "recvonly" keyword from that sentence. Then I bel= ieve it will cover for all cases where a endpoint is only receiving media a= nd not sending. Is that sufficient ? If the stream is inactive, the endpoint won't receive either, so I think yo= u only need to talk about sending. Whether the endpoint receives media or n= ot is irrelevant, isn't it? Regards, Christer From: Christer Holmberg Date: Tuesday, 3 June 2014 1:25 pm To: "rtcweb@ietf.org" Subject: [rtcweb] Continous consent when no media is sent Hi, =A0 Section 4.1 of draft-ietf-rtcweb-stun-consent-freshness-03 says: =A0 "An endpoint that is only receiving application traffic (recvonly) =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 does not need to obtain consent= which can slightly conserve its =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 resources." =A0 I think it would be good to be more generic, and talk about cases where the= sender does not send media. That is obviously true in case of "recvonly", = but it could also be true in other cases. =A0 In addition, I guess the no-need-to-send-consent rule also applies to "inac= tive" streams. =A0 Regards, =A0 Christer From nobody Tue Jun 3 05:31:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486321A01F9 for ; Tue, 3 Jun 2014 05:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3XWFpNA-6i5 for ; Tue, 3 Jun 2014 05:31:54 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887CF1A01F7 for ; Tue, 3 Jun 2014 05:31:54 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id x12so4690653qac.40 for ; Tue, 03 Jun 2014 05:31:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=BPV6DrgaTQy2wg0jKjRz2a9pJS2bFS+nuByMI6zSr3s=; b=Pvj57CEFJsNnSfD70yqMMpfs4GKCoL5aynrWV8Zj9b1t5v9I5ZpQ9/7bFylTUYHgZW QzXqA54MDCkvZMi7D7rOlxuldlNw0qnvtYTOUaazBrhIClnxsEOsFSzwKdlgWaxL5qKI fhDLadytzX2m9t8HOPWUDuWUza45JcgWXGfn2hN7CHH3Z4+UT0IeOctcPlDtHEHuE42Z YRW0/tIXWNWREr4OHyUaPI3nb1EOEwYRxk8VtRqfz5Gu+i0P7qCcIVoHghbHZNU54Vds +2fMdDmx7SQjgYgobHM7ClbqOJFZ+C4iY4bdXRnMBUkQqdQEHE67oPweoV+zS2m5M+w+ SD/A== X-Gm-Message-State: ALoCoQlhCbAftv7fNymB8R5gd7puWGg6xIp/yww9RbSkw4o7R8HUp8h8SqwnybvYdLuqgpQatFdY X-Received: by 10.140.47.18 with SMTP id l18mr56988486qga.9.1401798708393; Tue, 03 Jun 2014 05:31:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 05:31:28 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34E462@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E462@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 14:31:28 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aeP9BdKxKgTSEqJ3vmuxL7ZyquU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:31:56 -0000 2014-06-03 14:26 GMT+02:00 Christer Holmberg : > But, the RFC still says that you send a new offer when such switch occur. Yes, for making SIP B2BUAs happy ;) May we just ignore that? :) --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 05:33:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D891A021E for ; Tue, 3 Jun 2014 05:33:10 -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 1FLPsiR8sC_B for ; Tue, 3 Jun 2014 05:33:07 -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 003311A01F7 for ; Tue, 3 Jun 2014 05:33:06 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-86-538dc07bb54c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.23.15680.B70CD835; Tue, 3 Jun 2014 14:33:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 14:32:59 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Harald Alvestrand" Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw///ow4CAAAR+gIAABnuAgAAWfQCAACRUEP//52uAgAABWoCAACO/YA== Date: Tue, 3 Jun 2014 12:32:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E496@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> 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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvjW7Ngd5gg1dnmSyO9XWxWUzfZ2Ox 9l87uwOzx7mG9+weVyZcYfVYsuQnUwBzFJdNSmpOZllqkb5dAlfG48WL2AuusVes/lrQwLiH vYuRk0NCwETizunFTBC2mMSFe+vZuhi5OIQEjjJKXPh1jB3CWcQo8bPzF2sXIwcHm4CFRPc/ bZAGEYEsiZNnLrOB2MwC6hJ3Fp8DGyos4CvRcuwDM0RNgMTdRU+YYOovrH/EAmKzCKhITPl0 BayGF6j+4JmbjBC7JrFIdB09BTaIUyBQYue+TWANjEDXfT+1hglimbjErSfzoa4WkFiy5zwz hC0q8fLxP1YIW1Hi6vTlTCA3MwtoSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUm4Vk6iyEjllI OmYh6VjAyLKKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzCaDm75rbuDcfVrx0OMAhyMSjy8 Dz73BAuxJpYVV+YeYpTmYFES572kUR0sJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFlw+eT YenXV57dKXTmZ/TkuRkaIVLPuH4XrxcwfHP88UebZN4Nf5yTznXILs1kD13C26iasn9j3nmT S8+837Rmn1s1x9+S1er7xcZjRpv3/T73V/MeS5WRtOrEF2t47qfu56oOSQjVXWhq0bhayGep d3X4DZe1STvX7LJc/CLn/S3l48nn13sqsRRnJBpqMRcVJwIAs0FUj4cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ldxJK7b0sqVDlummR44yHEcxPSg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:33:10 -0000 SGksDQoNCj4+IEkgd291bGQgbmV2ZXIgd2FudCB0byBjYWxsIFJGQyA1MjQ1IGEgbW9kZWwgb2Yg Y2xhcml0eSwgYnV0IGl0IHNlZW1zIA0KPj4gdG8gbWUgdGhhdCB0aGlzIGxhbmd1YWdlIHdhcyB3 cml0dGVuIGluIHRoZSBleHBlY3RhdGlvbiB0aGF0IGEgc2VuZGVyIA0KPj4gbWlnaHQgY2hvb3Nl IHRvIHN3aXRjaCB0byBhIGRpZmZlcmVudCBwYWlyIGF0IGFueSB0aW1lLg0KPg0KPiArMQ0KDQpX ZSBjYW4gYXNrIE1NVVNJQyBhYm91dCB0aGF0Lg0KDQo+PiBJIGNhbid0IGZpbmQgdGhlIGNvcnJl c3BvbmRpbmcgcGFyYWdyYXBoIHRoYXQgc2F5cyB3aGVuIHRoZSBzZW5kZXIgDQo+PiBtaWdodCBk byBzbywgdGhvdWdoLg0KPg0KPiBJTUhPIGlmIGl0J3Mgbm90IGRlZmluZWQgd2hlbiBpdCBjYW4g ZG8gdGhhdCB0aGVuIGl0IE1VU1QgYmUgYWJsZSB0byBkbyB0aGF0IGF0IGFueSB0aW1lLg0KDQpJ dCBzdGlsbCBzYXlzIHRoYXQgeW91IG11c3Qgc2VuZCBhbiBvZmZlciwgc28gdGhhdCB0aGUgYy9t LSBsaW5lcyBtYXRjaCB0aGUgY2FuZGlkYXRlcy4NCg0KQW5kLCBpbiBnZW5lcmFsLCBJIHRoaW5r IHdlIHNob3VsZCBiZSByZWFsbHkgY2FyZWZ1bCBhYm91dCBtYWtpbmcgaW1wbGljaXQgYXNzdW1w dGlvbnMuIElmIHNvbWV0aGluZyBpcyB1bmNsZWFyLCBicmluZyBpdCB0byBNTVVTSUMgOikNCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQo= From nobody Tue Jun 3 05:36:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69EC1A01E7 for ; Tue, 3 Jun 2014 05:36:06 -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 prqMNIfbmREr for ; Tue, 3 Jun 2014 05:36:04 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682001A01DF for ; Tue, 3 Jun 2014 05:36:04 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so6430929wib.1 for ; Tue, 03 Jun 2014 05:35:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mSTr9r6CJF3+wN+4DjdhrH/kmvVlymGc+Q3oMoTF8/8=; b=BLw8Tz1uyfjzz6WHanN56B92emm3/lkil4EjqjdKrsIZKAvk9d6zEwOynk1lisqkEH yKtL0hcTxWnyE59FIA0ULJMMX+peIK51u3AcllAZw4a4TCxOuZaLxdsx3bROXQA7oP5H xn6ppW/j4JTD5rIUOJouls+al7g7VY2UJaZSv/4rEvfTJXNWBT/4SbjD5toUtx+QXN0o q6V8qSXrw22ZawBRmIBEFBJYurUi/CvR06zK08h3fX05850ZGj1C3dI3d0JL80OZyv6H LoZW3bmi5humhC0kkLFxqrHnSUy9hufEzFRYHk5O4Chx8WZN8f6d8+UUksHsJ/K9fj84 JgBQ== X-Gm-Message-State: ALoCoQmuDXrwXzQWABFvsnQsPQYmNl04gRTwgpj63YbtU4VIEfl1Syu5ukw+p1peJ9qGBjuBbUui X-Received: by 10.194.48.84 with SMTP id j20mr15626284wjn.80.1401798955584; Tue, 03 Jun 2014 05:35:55 -0700 (PDT) Received: from camionet.local ([88.203.232.9]) by mx.google.com with ESMTPSA id fc7sm8991159wjc.37.2014.06.03.05.35.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 05:35:54 -0700 (PDT) Message-ID: <538DC129.7030903@jitsi.org> Date: Tue, 03 Jun 2014 15:35:53 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Harald Alvestrand , rtcweb@ietf.org References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> In-Reply-To: <538DBCB3.3030408@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ITZSpOW5dpVVuwowuk3qZVFlI10 Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:36:07 -0000 On 03.06.14, 15:16, Harald Alvestrand wrote: > I would never want to call RFC 5245 a model of clarity, but it seems to > me that this language was written in the expectation that a sender might > choose to switch to a different pair at any time. I agree with Christer that the intention here was likely to make that possible while ICE processing is still ongoing. Note how section 8.3.1 says: Once ICE processing has reached the Completed state for all peers for media streams using those candidates, the agent SHOULD wait an additional three seconds, and then it MAY cease responding to checks or generating triggered checks on that candidate. It MAY free the candidate at that time. Freeing of server reflexive candidates is never explicit; it happens by lack of a keepalive. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed. 8.3.2. Lite Implementation Procedures A lite implementation MAY free candidates not selected by ICE as soon as ICE processing has reached the Completed state for all peers for all media streams using those candidates. Emil -- https://jitsi.org From nobody Tue Jun 3 05:36:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C931A021E for ; Tue, 3 Jun 2014 05:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebYkPbuRMFeu for ; Tue, 3 Jun 2014 05:36:08 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F080B1A01DF for ; Tue, 3 Jun 2014 05:36:07 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so6781637wgg.9 for ; Tue, 03 Jun 2014 05:36:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lTNWGq43A/ZSwWMHwiORsSptYsCcW9wqiqgPsrDrcJk=; b=L7WrRFFse550zrjYwRCjeAV2HV4f1f9rn4l4oJcV9bRadCp3nn9S1dpY4XZo7f/zCb nAZQFz6lvvbLklqBCnpkHqMxus89JS8sGIWFxDrUxgn77G5foXQg3QjxKflzmNExIiPb 73HQt0eD7JFVLgYsBgPMC+yDwLiXylXv7r/8amL9O3yCeazFiamSxVDOH//sYu6Wy8V4 xUioH1URdR96I/L9ym1xlp0ChODmlaCa6t0BQ6B7BKdZQ1rVM2DcPiKIhzywzJSEWAaH BLfcOaksLs/SqhcAjeBrAXmkD8fRlLzCjH42/Ka/+gkWzEAbxiFg7pwpWKNO1yF7PZhz +4HA== X-Gm-Message-State: ALoCoQlvJUyAM+8cYj43/tZ1i7B69CYZEXt8FPwRP6v+xF5d+jUMkqJQaFz2Ehy6+1DE9gKUKXhN X-Received: by 10.194.57.38 with SMTP id f6mr58094975wjq.59.1401798961263; Tue, 03 Jun 2014 05:36:01 -0700 (PDT) Received: from camionet.local ([88.203.232.9]) by mx.google.com with ESMTPSA id l5sm2578468wif.22.2014.06.03.05.35.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 05:35:59 -0700 (PDT) Message-ID: <538DC12D.8050100@jitsi.org> Date: Tue, 03 Jun 2014 15:35:57 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Christer Holmberg References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E462@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/X7rV0jAEYpdVDTIwAnSrvgM-c5w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:36:10 -0000 On 03.06.14, 15:31, Iħaki Baz Castillo wrote: > 2014-06-03 14:26 GMT+02:00 Christer Holmberg : >> But, the RFC still says that you send a new offer when such switch occur. > > Yes, for making SIP B2BUAs happy ;) > > May we just ignore that? :) B2BUAs may have very valid reasons for requiring this. Typically, some would add relay candidates as a fall back and they need to know when and where to release them. Emil -- https://jitsi.org From nobody Tue Jun 3 05:36:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E971A021E for ; Tue, 3 Jun 2014 05:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6DPYWYuYfKZ for ; Tue, 3 Jun 2014 05:36:51 -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 2AC711A01E7 for ; Tue, 3 Jun 2014 05:36:50 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-82-538dc15b8783 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.C2.28642.B51CD835; Tue, 3 Jun 2014 14:36:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 14:36:43 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw///ow4CAAAR+gIAABnuAgAAWfQCAACRUEP//52uAgAAidED//+GiAAAEQmBg Date: Tue, 3 Jun 2014 12:36:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E4BE@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E462@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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+JvjW7Mwd5gg6t/eS2O9XWxWUzfZ2Ox 9l87uwOzx7mG9+weVyZcYfVYsuQnUwBzFJdNSmpOZllqkb5dAlfG72dJBQ9YKpbvvM3ewHiB pYuRk0NCwETiyJfZjBC2mMSFe+vZuhi5OIQEjjJKNJz/wgThLGKUeHblCpDDwcEmYCHR/U8b pEFEwEbi34UL7CA2s0CwRG/XZFYQW1jAV6Ll2AdmiJoAibuLnjBB2HkSn950gi1jEVCRaH5w GszmBar/9nMe1OJrLBKHj/SzgOziFAiU+NdcDlLDCHTc91NrmCB2iUvcejKfCeJoAYkle84z Q9iiEi8f/2OFsBUlrk5fDnYys4CmxPpd+hCtihJTuh+yQ6wVlDg58wnLBEaxWUimzkLomIWk YxaSjgWMLKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAmPp4JbfVjsYDz53PMQowMGoxMP7 4HNPsBBrYllxZe4hRmkOFiVx3osa1cFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKvuvLo6 LzG/Zm/psffVbUWVj389s9//uUX4Hsuf04HLLVJWZNmLqH1RmFKS92qD9+xbBfvNhPlvX693 eqqyoGLieTPehk39iyJd9lc2RfDnBuTnzlT9tkyskLPhXvbBPUyezI0dpQW5tbwnDi6aai3x 4bK2911eXZtLXpIeJ+J+s6R8+tD2WImlOCPRUIu5qDgRAJTJzlKGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ADx8wrtJ9B_lXO_-F-lmSxsgt40 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:36:52 -0000 SGksDQoNCj4+IEJ1dCwgdGhlIFJGQyBzdGlsbCBzYXlzIHRoYXQgeW91IHNlbmQgYSBuZXcgb2Zm ZXIgd2hlbiBzdWNoIHN3aXRjaCBvY2N1ci4NCj4NCj4gWWVzLCBmb3IgbWFraW5nIFNJUCBCMkJV QXMgaGFwcHkgOykNCj4NCj4gTWF5IHdlIGp1c3QgaWdub3JlIHRoYXQ/IDopDQoNCklmIHdlIHJl ZmVyZW5jZSBhIHNwZWNpZmljYXRpb24sIHdlIHNoYWxsIG5vdCBpZ25vcmUgdGhlIHByb2NlZHVy ZXMuIFRoYXQgd2lsbCBvbmx5IGNhdXNlIGludGVyb3AgcHJvYmxlbXMgZXRjIGluIGZ1dHVyZS4N Cg0KQWdhaW4sIGlmIHdlIHdhbnQgdG8gY2hhbmdlIHNvbWV0aGluZywgbGV0J3MgZGlzY3VzcyBp dCwgYW5kIGJhc2VkIG9uIHRoZSBvdXRjb21lIHByb3Blcmx5IGRvY3VtZW50IHdoYXRldmVyIGNo YW5nZXMgYXJlIG5lZWRlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Tue Jun 3 05:40:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB6A1A01E7 for ; Tue, 3 Jun 2014 05:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7od80L2QeQPv for ; Tue, 3 Jun 2014 05:40:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914C71A01DF for ; Tue, 3 Jun 2014 05:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1719; q=dns/txt; s=iport; t=1401799213; x=1403008813; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=08TpBMutjJ5UfGfpaPrJFOSa+MH5lyPGBnMBYQLNhPQ=; b=VUk1Cypl2sN4LBxLXgzrvCAdzPkTodeXR7YfvKqR4oEE239ZZxDXwtO9 MeltYZkaXU+peKNAx8XpG1HB9eGxWfwpuodcV2DkFB1ndejwsQUBzUWbu BhBWT8SXT4xjzaFhXnZyiJ60yFm01MN5HoBTLYI8jLn4GFXZVTwu/6Ikr I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAO3BjVOtJA2F/2dsb2JhbABZgweBKsJeAYENFnSCJQEBAQSBBQQCAQgRAwECLzIdCAIEARIfiCPSBheOWQaEOgSJbZAWkzGDOIIv X-IronPort-AV: E=Sophos;i="4.98,965,1392163200"; d="scan'208";a="330191054" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jun 2014 12:39:52 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s53Cdq8t022891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 12:39:52 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.106]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 07:39:51 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Continous consent when no media is sent Thread-Index: AQHPfyjpxOE33WeTAUOuwJ5XKtxjug== Date: Tue, 3 Jun 2014 12:39:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D34E474@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34E474@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.66.108] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <108C9AF3A8CC1A409BE7445542DF217D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FAn3cn1ccvW_oUjFMCN40Nmt9ns Subject: Re: [rtcweb] Continous consent when no media is sent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:40:20 -0000 Agree. I think checking for sending is good enough. If both the endpoints are not sending media they won=B9t do consent with their peers. That will take care of all the cases Regards, Ram -----Original Message----- From: Christer Holmberg Date: Tuesday, 3 June 2014 5:59 pm To: Ram Mohan Ravindranath , "rtcweb@ietf.org" Subject: RE: [rtcweb] Continous consent when no media is sent >Hi, > >>Agree. I will remove the "recvonly" keyword from that sentence. Then I >>believe it will cover for all cases where a endpoint is only receiving >>media and not sending. Is that sufficient ? > >If the stream is inactive, the endpoint won't receive either, so I think >you only need to talk about sending. Whether the endpoint receives media >or not is irrelevant, isn't it? > >Regards, > >Christer > > > > > > >From: Christer Holmberg >Date: Tuesday, 3 June 2014 1:25 pm >To: "rtcweb@ietf.org" >Subject: [rtcweb] Continous consent when no media is sent > >Hi, >=20 >Section 4.1 of draft-ietf-rtcweb-stun-consent-freshness-03 says: >=20 > "An endpoint that is only receiving application traffic (recvonly) > does not need to obtain consent which can slightly >conserve its > resources." >=20 >I think it would be good to be more generic, and talk about cases where >the sender does not send media. That is obviously true in case of >"recvonly", but it could also be true in other cases. >=20 >In addition, I guess the no-need-to-send-consent rule also applies to >"inactive" streams. >=20 >Regards, >=20 >Christer From nobody Tue Jun 3 05:42:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F761A01DF for ; Tue, 3 Jun 2014 05:42:22 -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_44=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 06slC9_AXhuy for ; Tue, 3 Jun 2014 05:42: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 886C61A01D9 for ; Tue, 3 Jun 2014 05:42:19 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-56-538dc2a47dd1 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4D.74.15680.4A2CD835; Tue, 3 Jun 2014 14:42:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 14:42:12 +0200 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Continous consent when no media is sent Thread-Index: AQHPfyauOJVedlPuoUWlfGriQTFxJ5tfUCiQ///h1QCAACH/EA== Date: Tue, 3 Jun 2014 12:42:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E4EE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34E474@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.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje6SQ73BBo9va1ks79rBaLH2Xzu7 A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx+vQn9oLTAhWXT+1nbGBcztvFyMkhIWAi cfn/Q1YIW0ziwr31bF2MXBxCAkcZJXpufmeFcBYxSnx9cYupi5GDg03AQqL7nzZIg4hAmMT0 EwtYQMLCArYSTZO0QEwRATuJDY1ZEBVOEq9O/WIHsVkEVCS6Dz5iBCnhFfCVmHhcGGL4dEaJ m1M3sIHEOQX0JbY21ICUMwJd8/3UGiYQm1lAXOLWk/lMEFcKSCzZc54ZwhaVePn4H9T1ihJX py+HqteTuDF1ChuErS2xbOFrsHpeAUGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpx cW66kbFealFmcnFxfp5eXmrJJkZghBzc8lt3B+Pq146HGAU4GJV4eB987gkWYk0sK67MPcQo zcGiJM57SaM6WEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj69192WoLPz7/wLnUKy5rSuVe 973lx7pW9GVGzzpupDL7/GvXJxGtPYsbNTW0nq2samK8WtOs89RgQd6v7+uvW6/+r6v/Ove+ 6PYO4fUXLdJV7MoqJJPc59a5f3Sc8sXA80lYj3ffqv+nngq8YtI5KKGm8TXQkdHjj/SXKuM+ 1eI7L4++3XlIiaU4I9FQi7moOBEAAWh41XECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jgad3M0iGmojkwA9eLn-R4-Prg0 Subject: Re: [rtcweb] Continous consent when no media is sent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:42:22 -0000 And, we of course also need to make sure that the remote endpoint does not = expect to receive cont.cons. in such cases :) Regards, Christer -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: 3. kes=E4kuuta 2014 15:40 To: Christer Holmberg; rtcweb@ietf.org Subject: Re: [rtcweb] Continous consent when no media is sent Agree. I think checking for sending is good enough. If both the endpoints a= re not sending media they won=B9t do consent with their peers. That will take care of all the cases Regards, Ram -----Original Message----- From: Christer Holmberg Date: Tuesday, 3 June 2014 5:59 pm To: Ram Mohan Ravindranath , "rtcweb@ietf.org" Subject: RE: [rtcweb] Continous consent when no media is sent >Hi, > >>Agree. I will remove the "recvonly" keyword from that sentence. Then I=20 >>believe it will cover for all cases where a endpoint is only receiving=20 >>media and not sending. Is that sufficient ? > >If the stream is inactive, the endpoint won't receive either, so I=20 >think you only need to talk about sending. Whether the endpoint=20 >receives media or not is irrelevant, isn't it? > >Regards, > >Christer > > > > > > >From: Christer Holmberg >Date: Tuesday, 3 June 2014 1:25 pm >To: "rtcweb@ietf.org" >Subject: [rtcweb] Continous consent when no media is sent > >Hi, >=20 >Section 4.1 of draft-ietf-rtcweb-stun-consent-freshness-03 says: >=20 > "An endpoint that is only receiving application traffic (recvonly) > does not need to obtain consent which can slightly=20 >conserve its > resources." >=20 >I think it would be good to be more generic, and talk about cases where=20 >the sender does not send media. That is obviously true in case of=20 >"recvonly", but it could also be true in other cases. >=20 >In addition, I guess the no-need-to-send-consent rule also applies to=20 >"inactive" streams. >=20 >Regards, >=20 >Christer From nobody Tue Jun 3 05:44:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05AA1A01DF for ; Tue, 3 Jun 2014 05:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 gbMKIfItPWFd for ; Tue, 3 Jun 2014 05:44:04 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0088E1A01D9 for ; Tue, 3 Jun 2014 05:44:03 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so12813705qgd.24 for ; Tue, 03 Jun 2014 05:43:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=uXZFYPpy3qhrT2YCEjW8ela/NzaL5wk/xOzIX/rdalk=; b=Zwy68wY1/VYqNRtJ1hjnqtTyMENmVvWC8fimXW0zRFe6f32EwaxXsQqXDLMDH8Hzk7 QqsQ/xbCrXOZHN9AB6HaUo69wae/wd1Rs8N12sd8WD5/e/YhnMl9h1hs+4IfQI7+4i2A 8+yncen6Q2ymD2MAs50+wWV+oGF0BssIWBhgHK6/ymGFgHhphqwUBBjN51qboP79vwkx Xr1YcuGV+sO/bOGy3EQV2113sC/qx2ewDcruwElODXgmEMuEm9/ua+P4BVp8ik8/+v02 ygbxbzB43dFSs9unhRRKG1jzfPR753zFgxlG+nPeQKcSJSQF9Cds2ttockM/k5zxhLox 1nlA== X-Gm-Message-State: ALoCoQl7qZ+ZTPgMjJWnqKN6b4oDP4DDQkWrVoowHbKSjuzKCI0Qx5LJTNRP2R8H4FYDBwYFWe02 X-Received: by 10.229.70.196 with SMTP id e4mr59333257qcj.16.1401799437761; Tue, 03 Jun 2014 05:43:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 05:43:37 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34E496@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 14:43:37 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2fv3-omC9qXugorDLSiU2BHMxnM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:44:06 -0000 2014-06-03 14:32 GMT+02:00 Christer Holmberg : >>> I would never want to call RFC 5245 a model of clarity, but it seems >>> to me that this language was written in the expectation that a sender >>> might choose to switch to a different pair at any time. >> >> +1 > > We can ask MMUSIC about that. I strongly don't agree that any pure network-based feature requires MMUSIC (SDP) to accept it. Now: imagine a WebRTC device (a mobile) running a audio/video session. The user walks, looses WiFi and connects to 3G. The WebRTC application is probably notified about "network changed" and could restart ICE without the need of signaling a new SDP offer (it may signal it if it wants). Why do we need to mandate the new SDP O/A? ICE protocol should have been defined as a separate pure network protocol (a pure STUN usage) without involving SIP and SDP at all. And SIP should have its own MMUSIC RFC "ICE usage for SIP and SDP". And we wouldn't be here debating about the need of sending a fake SDP offer just because ICE does it work in background. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 06:06:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D461A0236 for ; Tue, 3 Jun 2014 06:06:27 -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 i6CZMzTGDcP9 for ; Tue, 3 Jun 2014 06:06:26 -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 D0B1F1A01F3 for ; Tue, 3 Jun 2014 06:06:25 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-7d-538dc84a65ad Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 43.58.15680.A48CD835; Tue, 3 Jun 2014 15:06:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 15:06:18 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw///ow4CAAAR+gIAABnuAgAAWfQCAACRUEP//52uAgAABWoCAACO/YP//4mKAAATCNXA= Date: Tue, 3 Jun 2014 13:06:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34E5EE@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvja7Xid5gg7PXzSyO9XWxWUzfZ2Ox 9l87uwOzx7mG9+weVyZcYfVYsuQnUwBzFJdNSmpOZllqkb5dAlfGjXUbmAtuCFTcfDqVrYFx gUAXIyeHhICJxJOvvcwQtpjEhXvr2boYuTiEBI4yShx6dJ0JwlnEKDF53ln2LkYODjYBC4nu f9ogDSICNhL/LlxgB7GZBYIlersms4LYwgK+Ei3HPjBD1ARI3F30hAnCLpNoXfmcFWQMi4CK xJy3cSBhXqDyqTefgLUKCcxllZj9VQ7E5hQIlDh/bB3YGEag276fWsMEsUpc4taT+UwQNwtI LNlzHup+UYmXj/+xQtiKElenL2cCWcUsoCmxfpc+RKuixJTuh+wQawUlTs58wjKBUWwWkqmz EDpmIemYhaRjASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAWDq45bfuDsbVrx0PMQpw MCrx8D743BMsxJpYVlyZe4hRmoNFSZz3kkZ1sJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG TI7l12Km5Z4Lczz413yV8cHtjlpV0Qwrn1i5pN+ZJtzxZPss+92z8n0/7vG/4CywQiuL731O TU//z01xe4++qwsLX9ct8Pbq4q8757FerbVccV5y04Jt1t/uZS+2qjmZMrezSHSO/LclG9eu 0OKZkbhuQdr0lcGieqzxlXq/zJ3OM3N/YDmTrsRSnJFoqMVcVJwIANxAmBOGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t0Ta7Sv5YEmCksD_yzbBudhB8S4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:06:28 -0000 SGksDQoNCj4+Pj4gSSB3b3VsZCBuZXZlciB3YW50IHRvIGNhbGwgUkZDIDUyNDUgYSBtb2RlbCBv ZiBjbGFyaXR5LCBidXQgaXQgc2VlbXMgDQo+Pj4+IHRvIG1lIHRoYXQgdGhpcyBsYW5ndWFnZSB3 YXMgd3JpdHRlbiBpbiB0aGUgZXhwZWN0YXRpb24gdGhhdCBhIA0KPj4+PiBzZW5kZXIgbWlnaHQg Y2hvb3NlIHRvIHN3aXRjaCB0byBhIGRpZmZlcmVudCBwYWlyIGF0IGFueSB0aW1lLg0KPj4+DQo+ Pj4gKzENCj4+DQo+PiBXZSBjYW4gYXNrIE1NVVNJQyBhYm91dCB0aGF0Lg0KPg0KPiBJIHN0cm9u Z2x5IGRvbid0IGFncmVlIHRoYXQgYW55IHB1cmUgbmV0d29yay1iYXNlZCBmZWF0dXJlIHJlcXVp cmVzIE1NVVNJQyAoU0RQKSB0byBhY2NlcHQgaXQuDQo+DQo+IE5vdzogaW1hZ2luZSBhIFdlYlJU QyBkZXZpY2UgKGEgbW9iaWxlKSBydW5uaW5nIGEgYXVkaW8vdmlkZW8gc2Vzc2lvbi4NCj4gVGhl IHVzZXIgd2Fsa3MsIGxvb3NlcyBXaUZpIGFuZCBjb25uZWN0cyB0byAzRy4gVGhlIFdlYlJUQyBh cHBsaWNhdGlvbiBpcyBwcm9iYWJseSBub3RpZmllZCBhYm91dCAibmV0d29yayBjaGFuZ2VkIiBh bmQgY291bGQgDQo+IHJlc3RhcnQgSUNFIHdpdGhvdXQgdGhlIG5lZWQgb2Ygc2lnbmFsaW5nIGEg bmV3IFNEUCBvZmZlciAoaXQgbWF5IHNpZ25hbCBpdCBpZiBpdCB3YW50cykuDQoNCklzbid0IHRo YXQgd2hhdCB0aGUgTUlDRSBkcmFmdCBpcyBhYm91dD8NCg0KPiBXaHkgZG8gd2UgbmVlZCB0byBt YW5kYXRlIHRoZSBuZXcgU0RQIE8vQT8NCg0KQmVjYXVzZSB0aGUgUkZDIHNheXMgc28gOikNCg0K U2VyaW91c2x5LCBwZW9wbGUgYmFzZSBpbXBsZW1lbnRhdGlvbnMsIHRlc3RzIGV0YyBvbiB0aGUg c3BlY2lmaWNhdGlvbnMuIFNvLCBpZiB3ZSB0aGluayBzb21ldGhpbmcgaW4gYSBzcGVjaWZpY2F0 aW9uIGlzIG5vdCBuZWVkZWQsIHdlIHNob3VsZCB0cnkgdG8gY2hhbmdlIGl0Lg0KDQo+SUNFIHBy b3RvY29sIHNob3VsZCBoYXZlIGJlZW4gZGVmaW5lZCBhcyBhIHNlcGFyYXRlIHB1cmUgbmV0d29y ayBwcm90b2NvbCAoYSBwdXJlIFNUVU4gdXNhZ2UpIHdpdGhvdXQgaW52b2x2aW5nIFNJUCBhbmQg U0RQIGF0IGFsbC4gDQoNCldlbGwsIHRoYXQncyB3aGF0IHBlb3BsZSB0cmllZCB0byBkbyBpbiB0 aGUgYmVnaW5uaW5nLCBhbmQgd2hhdCBJIGJlbGlldmUgcGVvcGxlIG5vdyB0cnkgdG8gZG8gaW4g NTI0NWJpcy4NCg0KPkFuZCBTSVAgc2hvdWxkIGhhdmUgaXRzIG93biBNTVVTSUMgUkZDICJJQ0Ug dXNhZ2UgZm9yIFNJUCBhbmQgU0RQIi4gQW5kIHdlIHdvdWxkbid0IGJlIGhlcmUgZGViYXRpbmcg YWJvdXQgdGhlIG5lZWQgb2Ygc2VuZGluZyBhIGZha2UgU0RQIG9mZmVyIGp1c3QgYmVjYXVzZSBJ Q0UgZG9lcyBpdCB3b3JrIGluIGJhY2tncm91bmQuDQoNCklmIHlvdXIgYnJvd3NlciBkb2VzIG5v dCB1c2UgU0lQL1NEUCBvbiB0aGUgd2lyZSwgeW91IGRvbid0IGhhdmUgdG8gc2VuZCB0aGUgb2Zm ZXIuIFlvdSBkbyB3aGF0ZXZlciB5b3VyIHdpcmUgcHJvdG9jb2wgc3BlY2lmaWVzLg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Tue Jun 3 06:08:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054781A026D for ; Tue, 3 Jun 2014 06:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyVr0yWIMzvM for ; Tue, 3 Jun 2014 06:08:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1B71A01F6 for ; Tue, 3 Jun 2014 06:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1986; q=dns/txt; s=iport; t=1401800894; x=1403010494; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uE4f5BOMKqwgFLfsBpjyKr9fmcxLk1xOZzqCBiCw2gY=; b=HUzKqWpmUQ9Iap5f3VEHCELmrTucZ2KF8SEMrPYVWuDt0Jhpr0NedWQK j2y5Q4o2GbqJF85K0hZqLoLHJmDUQvWVi6Db09Wby91CtJyiEBFwFZzn/ +fSD6fMTDpzSqwkP+V2i0KgTzxb12cIo6rTHngkHO/hNE1nLCehclC4ql 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAArIjVOtJV2Y/2dsb2JhbABZgwdSWLslhhtNUQGBDRZ0giUBAQEDAQEBAWsLBQsCAQhGJwslAgQOBYg6CA3RfhMEgmCLPzMHgyuBFQSJbZAWkzGDOIIv X-IronPort-AV: E=Sophos;i="4.98,965,1392163200"; d="scan'208";a="330077900" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 03 Jun 2014 13:08:13 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s53D8DBb008653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 13:08:13 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.48]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 08:08:13 -0500 From: "Pal Martinsen (palmarti)" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoZ1vUq3LEZqpEu/j0w8tssnVZtfb6oAgAAFS4CAAAR+gIAABnuAgAAWfQCAAAYygIAABY2AgAABWoCAAAMnAIAAAvqAgAAG3gA= Date: Tue, 3 Jun 2014 13:08:13 +0000 Message-ID: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@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: [10.55.154.71] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DrRS7bjCFL1d08oSde2_LJWXAgc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:08:22 -0000 On 03 Jun 2014, at 14:43, I=F1aki Baz Castillo wrote: > 2014-06-03 14:32 GMT+02:00 Christer Holmberg : >>>> I would never want to call RFC 5245 a model of clarity, but it seems >>>> to me that this language was written in the expectation that a sender >>>> might choose to switch to a different pair at any time. >>>=20 >>> +1 >>=20 >> We can ask MMUSIC about that. >=20 >=20 > I strongly don't agree that any pure network-based feature requires > MMUSIC (SDP) to accept it. >=20 > Now: imagine a WebRTC device (a mobile) running a audio/video session. > The user walks, looses WiFi and connects to 3G. The WebRTC application > is probably notified about "network changed" and could restart ICE > without the need of signaling a new SDP offer (it may signal it if it > wants). Why do we need to mandate the new SDP O/A? >=20 If there are NATs and FWs involved and you change your IP address there is = a good chance you need connectivity checks from both sides to get through a= ll the NATs. To do that you need to send your candidates to the remote side= so he can start doing the ICE magic. There is the MICE draft discussing how that can be done. Trickle ICE also h= ave the potential to better handle those mobility scenarios. But this needs= more work to iron out all the corner cases. > ICE protocol should have been defined as a separate pure network > protocol (a pure STUN usage) without involving SIP and SDP at all. And > SIP should have its own MMUSIC RFC "ICE usage for SIP and SDP". And we > wouldn't be here debating about the need of sending a fake SDP offer > just because ICE does it work in background. >=20 That is work in progress within the MMUSIC. .-. P=E5l-Erik > --=20 > I=F1aki Baz Castillo > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 3 06:34:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507941A028D for ; Tue, 3 Jun 2014 06:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 0b3CzIXEkl2W for ; Tue, 3 Jun 2014 06:34:27 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111D81A027C for ; Tue, 3 Jun 2014 06:34:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s53DYIwJ005963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Jun 2014 08:34:20 -0500 (CDT) 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 s53DY1k3026182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Jun 2014 15:34:17 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.51]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 15:34:06 +0200 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" Thread-Topic: Usage of draft-ietf-rtcweb-overview Thread-Index: Ac9/LgAhpbo80FtUQ4i9Wbs8L/lrOw== Date: Tue, 3 Jun 2014 13:34:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1C22F0@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/R5KyxwjYvyN-fwEjlNlb49-NwY8 Subject: [rtcweb] Usage of draft-ietf-rtcweb-overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:34:31 -0000 I was working through this document, and assessing whether it could form a = conformance assessment for a rtcweb implementation. I came to the conclusion that it could not as it currently stands. While it is standards track, it seems to be missing RFC 2119 language compl= etely. As such I end up wondering whether some of the referenced drafts are mandat= ory to implement, optional to implement (or could just be ignored - unlikel= y). So what is the philosophy here - Would I be right in considering that the i= ntent is that all the referenced normative references are mandatory, i.e. a= ll implementations implement all these documents? But if that is the case, how do I treat text in the document that reference= s draft-cbran-rtcweb-codec, which is an informative reference, but which th= e text treats with equal weight as other normative references? Regards Keith= From nobody Tue Jun 3 07:05:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41B91A0080 for ; Tue, 3 Jun 2014 07:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myK3KCjAQfm9 for ; Tue, 3 Jun 2014 07:05:49 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 28B651A02C6 for ; Tue, 3 Jun 2014 07:05:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 249D67C36B9 for ; Tue, 3 Jun 2014 16:05:18 +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 YdqK9rgzaTFx for ; Tue, 3 Jun 2014 16:05:17 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 408D27C36B3 for ; Tue, 3 Jun 2014 16:05:17 +0200 (CEST) Message-ID: <538DD61D.6030605@alvestrand.no> Date: Tue, 03 Jun 2014 16:05:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B1C22F0@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1C22F0@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/10rbXAwF-oGxKxUCcZO2YB4qvHs Subject: Re: [rtcweb] Usage of draft-ietf-rtcweb-overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:05:53 -0000 On 06/03/2014 03:34 PM, DRAGE, Keith (Keith) wrote: > I was working through this document, and assessing whether it could form a conformance assessment for a rtcweb implementation. > > I came to the conclusion that it could not as it currently stands. > > While it is standards track, it seems to be missing RFC 2119 language completely. > > As such I end up wondering whether some of the referenced drafts are mandatory to implement, optional to implement (or could just be ignored - unlikely). In that case, the language is unclear, and needs fixing. I'll review the document with this in mind; doing things like changing The data transport protocols used by RTCWEB are described in [I-D.ietf-rtcweb-transports]. into An RTCWEB implementation MUST implement the data transport protocols described in [I-D.ietf-rtcweb-transports]. is pretty mechanical. > > So what is the philosophy here - Would I be right in considering that the intent is that all the referenced normative references are mandatory, i.e. all implementations implement all these documents? The intent of the normative references is that the referenced RFCs have to be read, and the implications understood, in order to correctly implement an RTCWEB system. I believe that's the definition of a normative reference. Many of these (RFC 2119 being the prime example) are, by definition, unimplementable. Some of them are classified wrongly, like -data-protocol, which should be normative. (or deleted, since we now have a reference to it in -transport). I'm not sure where the W3C API documents should be placed; for browsers, they're normative, but I'm not sure having a normative reference to them in this document is the Right Thing. Opinions? > > But if that is the case, how do I treat text in the document that references draft-cbran-rtcweb-codec, which is an informative reference, but which the text treats with equal weight as other normative references? The reference to draft-cbran is due to be deleted, since that draft is (I believe) dead. This is a placeholder for a decision on the MTI video codec discussion. The particular sentence referencing this draft is: The mandatory to implement codecs, as well as any profiling requirements for both mandatory and optional codecs, is described in (candidate draft: [I-D.cbran-rtcweb-codec]. When I wrote this, I thought it was pretty clear that an implementation MUST implement the mandatory to implement codecs, but that the draft specifying them did not exist yet (and the reference to the wannabe-decision therefore had to be informative). But if you read it as "treat with equal weight", I guess that wasn't written clearly enough? > Regards > > Keith > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 3 07:16:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99B71A0080 for ; Tue, 3 Jun 2014 07:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 sLzicHF_-wl3 for ; Tue, 3 Jun 2014 07:16:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D543F1A0170 for ; Tue, 3 Jun 2014 07:16:42 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s53EGVK2023475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jun 2014 09:16:32 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s53EGGFW002656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 10:16:31 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 10:16:28 -0400 From: "Makaraju, Maridi Raju (Raju)" To: "Pal Martinsen (palmarti)" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Christer Holmberg Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ3SJNDgjOyUGKrVMmPtCWUptfFtqwgABNWYCAAAR9gIAABnuAgAAWfQCAAAYzgIAABYyAgAABWoCAAAMnAIAAAvqAgAAG4ID//8KX0A== Date: Tue, 3 Jun 2014 14:16:27 +0000 Message-ID: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@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: [135.5.27.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8FT1AWO8chF_rU0df38EuMY_5LE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:16:45 -0000 Strong "+1" for Christer's comments on taking it to MMUSIC. Please see my comments inserted below. > > Now: imagine a WebRTC device (a mobile) running a audio/video session. > > The user walks, looses WiFi and connects to 3G. The WebRTC application > > is probably notified about "network changed" and could restart ICE > > without the need of signaling a new SDP offer (it may signal it if it > > wants). Why do we need to mandate the new SDP O/A? [Raju] Such a new SDP O/A is needed for couple of reasons: 1. QoS: It is true that ICE client can do all inband without additional SDP= O/A. But there may be middle boxes in between that may apply QoS per the chan= ged=20 ICE candidate(s). One such example is, when going from WiFi to LTE the=20 network may provide better QoS via PCRF/PGW dedicated bearers. It can on= ly do so if it knows about the new media flow. Please note that the new media = flow may go thru completely new network elements who may not be aware of the old= =20 flow at all. Yes, one can provide a "costly" solution to solve this prob= lem by using DPI (and/or SDN), but such a solution is not only costly but al= so complex. IMHO, webrtc should facilitate achieving necessary QoS desired for sessi= ons=20 in the network. While doing so, I don't see any functionality being lost= at=20 WebRTC, rather it's a gain and greater adaption of WebRTC. For the same reason, I also agree with the comment that, a new SDP O/A m= ust be sent if the selected candidate is not the one listed in c/m=3D lines. WebRTC should not assume that middle boxes don't exist. Middle boxes do = exist for Very valid reasons (not just SIP/IMS, which is only one example). Especi= ally with the trend towards SDN, the control plane and data/user plane are being s= eparated for good and the control plane needs triggers to reconfigure the network= for better QoS. Sending new O/A (please do not equate this to SIP, it can be any si= gnaling protocol and even not necessarily SDP format) achieves that. 2. Resource allocation at middle boxes In cases like changing transport (not necessarily access network change)= =20 from UDP to TCP or vice-versa, it is highly desirable to have a new SDP = O/A.=20 Without such offer, it is a huge burden on middle boxes to be prepared=20 for any kind of mid-session transport (UDP or TCP) changes. Middle boxes= can=20 have complex logic to reserve all possible resources and keep them for a= ny future mid-session changes without new SDP O/A. Again, it's not only ine= fficient but also makes middle boxes logic complicated. Also, as pointed by Emil = Ivov, ICE RFC says you MAY free remaining candidates once ICE is completed. Ev= en if an implementation wants to keep ALL the candidates even after ICE is com= pleted, it can't expect the peer to do the same, especially ice lite implementat= ions typically won't keep the remaining candidates. BR Raju From nobody Tue Jun 3 07:38:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322081A02D0 for ; Tue, 3 Jun 2014 07:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr_jpDjDj7FP for ; Tue, 3 Jun 2014 07:38:50 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4FD1A0263 for ; Tue, 3 Jun 2014 07:38:50 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id w8so5017293qac.10 for ; Tue, 03 Jun 2014 07:38:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=NAk5eMI/Cex6QCiqKNTILntBxM21tkbLOfrdkHU3ht8=; b=EtpBdZiRa5gENTeboCrOkS9Twb/04AQzpC6TV7O0u8tJsUC0pw3r3ilEp4zfnkwCcs Rrbh8Mum52CMz+mp5mIdoeqaaE99h8UaJsWtxH3oz3WFD0bqxMbdNYZ7bgu+8Y3zFrTF 51uaJDIg61IJcM5wgTRpA1NZ1XGyPOFiCCLtzojhe1dpyjCWPSAcyFnABVniUHJTgElW YwK3YY0MPggUpWVmZewsRt7VavW7ao8hpE0JrMjVtCNLqT5HpcpRsUcYp1UYlKV+NXPA fH5bSo+PeqAaXtY3H1tgUjqanbjwfenI/FuSQ/IrTf31FPRe0qEAWsjap3wpvZr5obf9 vU9Q== X-Gm-Message-State: ALoCoQltaZ+Il/uHPc0bDn1PI8RhE5BiOc8CS5I+kD4HJgSKbX0dtDBOs9DPUVG7H5xNcNbBenjV X-Received: by 10.140.81.146 with SMTP id f18mr58791585qgd.47.1401806324248; Tue, 03 Jun 2014 07:38:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 07:38:24 -0700 (PDT) In-Reply-To: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 16:38:24 +0200 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Iv-sFehXEZex63NSfrnsQx8lvG0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:38:51 -0000 2014-06-03 16:16 GMT+02:00 Makaraju, Maridi Raju (Raju) : > [Raju] Such a new SDP O/A is needed for couple of reasons: > 1. QoS: It is true that ICE client can do all inband without additional S= DP O/A. > But there may be middle boxes in between that may apply QoS per the ch= anged > ICE candidate(s). One such example is, when going from WiFi to LTE the > network may provide better QoS via PCRF/PGW dedicated bearers. If you are talking about "middle boxes" then you mean a fixed and specific *signaling* protocol, right? even more, you probably mean SIP. Given the fact that WebRTC is supposed to be "signaling protocol" agnostic I don't buy your rationale. > For the same reason, I also agree with the comment that, a new SDP O/A= must be sent > if the selected candidate is not the one listed in c/m=3D lines. I'm glad that that does not occur now, and no one WebRTC browser cares about that. > WebRTC should not assume that middle boxes don't exist. Middle boxes d= o exist for > Very valid reasons (not just SIP/IMS, which is only one example). Espe= cially with > the trend towards SDN, the control plane and data/user plane are being= separated > for good and the control plane needs triggers to reconfigure the netwo= rk for better > QoS. Sending new O/A (please do not equate this to SIP, it can be any = signaling > protocol and even not necessarily SDP format) achieves that. If so it can be signaled *anyhow* (up to the specific application / vendor), but we are discussing here about the requirement of signaling a new SDP (as the RFC mandates). Regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 08:10:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851911A02F6 for ; Tue, 3 Jun 2014 08:10:31 -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 MWVkVmOM2Qye for ; Tue, 3 Jun 2014 08:10:19 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE741A02CE for ; Tue, 3 Jun 2014 08:10:14 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-1b-538de54f84c3 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.1A.15680.F45ED835; Tue, 3 Jun 2014 17:10:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 17:10:06 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ1ITXr2v8bkWsEJ3GsOpDmZtfFtqw///ow4CAAAR+gIAABnuAgAAWfQCAACRUEP//52uAgAABWoCAACO/YP//4mKAAADb+YAAAmIOgAAAxEAAAAT0/hA= Date: Tue, 3 Jun 2014 15:10:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34EA26@ESESSMB209.ericsson.se> References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rtf/aW+wQUOjiMX0fTYW76+vZLFo 2HiF1WLtv3Z2BxaP1md7WT3ONbxn95jyeyOrx5IlP5kCWKK4bFJSczLLUov07RK4Mo5e2cxY sI2tYvfKF8wNjAvYuhg5OSQETCSa+26wQthiEhfurQeKc3EICRxllOj/txnKWcQo8XTyAeYu Rg4ONgELie5/2iBxEYFGRonGA++YQLqZBaIkVl54DTZJWMBXouXYB2YQW0QgQOLuoidMEA1d jBLrNh1iB0mwCKhIzOubBdbAC9QwadlvJohtr9gkXv08D5bgFAiU6Gt9xghiMwLd9/3UGqht 4hK3nsxngrhbQGLJnvPMELaoxMvH/6D+UZJoXPKEFeRqZgFNifW79CFaFSWmdD9kh9grKHFy 5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbZwS2/ dXcwrn7teIhRgINRiYf3weeeYCHWxLLiytxDjNIcLErivJc0qoOFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MCbO9VNY+mnnkbSwXl2nn2ui+wSk1cJrBebmr603NVNv29l5Q28Db8uWh0p/ s9pUlvcZOH2uyPk4J/SG9hFB+6Qnt89qnbKJtljD+V7FMVWN73arWOSMF3cWhAZnnNxfzcY9 79cLT/5lRXzr9BcfZ2eTcSthW3bxdK5kk2t/fkbqhXXbtj85pcRSnJFoqMVcVJwIABuwXJCU AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t1kiiGtZE06eN-fP5Z3p-EDCOkA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:10:31 -0000 SGksDQoNCj5JZiBzbyBpdCBjYW4gYmUgc2lnbmFsZWQgKmFueWhvdyogKHVwIHRvIHRoZSBzcGVj aWZpYyBhcHBsaWNhdGlvbiAvIHZlbmRvciksIGJ1dCB3ZSBhcmUgZGlzY3Vzc2luZyA+aGVyZSBh Ym91dCB0aGUgcmVxdWlyZW1lbnQgb2Ygc2lnbmFsaW5nIGEgbmV3IFNEUCAoYXMgdGhlIFJGQyBt YW5kYXRlcykuDQoNCldoYXRldmVyIGlzIHNpZ25hbGxlZCBvbiB0aGUgd2lyZSBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiBvdXIgd29yay4gSXQncyBhIEphdmFTY3JpcHQgaW1wbGVtZW50YXRpb24g aXNzdWUuDQoNCldoYXQgSVMgd2l0aGluIG91ciBzY29wZSBpcyB3aGF0IHRoZSBXZWJSVEMgYnJv d3NlciBpcyBhbGxvd2VkIHRvIGRvIGludGVybmFsbHkgKGUuZy4gc3dpdGNoIGZyb20gb25lIGNh bmRpZGF0ZSBwYWlyIHRvIGFub3RoZXIgIm9uIHRoZSBmbHkiKSwgYW5kIGhvdyBpdCBpbmZvcm1z IHRoZSBKUyBBcHAgYWJvdXQgc3VjaCBzd2l0Y2ggKGluIG9yZGVyIGZvciB0aGUgSlMgQXBwIHRv IGUuZy4gZ2VuZXJhdGUgYW5kIHNlbmQgYSBuZXcgb2ZmZXIgcmVmbGVjdGluZyB0aGUgc3dpdGNo KS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Tue Jun 3 08:14:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8848B1A02F4 for ; Tue, 3 Jun 2014 08:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 mGGMnGNgaL2k for ; Tue, 3 Jun 2014 08:14:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D3E1A02E5 for ; Tue, 3 Jun 2014 08:14:39 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s53FEUFX029724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jun 2014 10:14:31 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s53FEUKf026341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 11:14:30 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 11:14:30 -0400 From: "Makaraju, Maridi Raju (Raju)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ3SJNDgjOyUGKrVMmPtCWUptfFtqwgABNWYCAAAR9gIAABnuAgAAWfQCAAAYzgIAABYyAgAABWoCAAAMnAIAAAvqAgAAG4ID//8KX0IAAVpsA//++IOA= Date: Tue, 3 Jun 2014 15:14:29 +0000 Message-ID: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@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: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uqbgqpgZG48cuaxJmLxrhaM7uoE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:14:43 -0000 DQo+IDIwMTQtMDYtMDMgMTY6MTYgR01UKzAyOjAwIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFq dSkNCj4gPFJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tPjoNCj4gDQo+ID4gW1JhanVd IFN1Y2ggYSBuZXcgU0RQIE8vQSBpcyBuZWVkZWQgZm9yIGNvdXBsZSBvZiByZWFzb25zOg0KPiA+ IDEuIFFvUzogSXQgaXMgdHJ1ZSB0aGF0IElDRSBjbGllbnQgY2FuIGRvIGFsbCBpbmJhbmQgd2l0 aG91dCBhZGRpdGlvbmFsDQo+IFNEUCBPL0EuDQo+ID4gICAgQnV0IHRoZXJlIG1heSBiZSBtaWRk bGUgYm94ZXMgaW4gYmV0d2VlbiB0aGF0IG1heSBhcHBseSBRb1MgcGVyIHRoZQ0KPiBjaGFuZ2Vk DQo+ID4gICAgSUNFIGNhbmRpZGF0ZShzKS4gT25lIHN1Y2ggZXhhbXBsZSBpcywgd2hlbiBnb2lu ZyBmcm9tIFdpRmkgdG8gTFRFIHRoZQ0KPiA+ICAgIG5ldHdvcmsgbWF5IHByb3ZpZGUgYmV0dGVy IFFvUyB2aWEgUENSRi9QR1cgZGVkaWNhdGVkIGJlYXJlcnMuDQo+IA0KPiBJZiB5b3UgYXJlIHRh bGtpbmcgYWJvdXQgIm1pZGRsZSBib3hlcyIgdGhlbiB5b3UgbWVhbiBhIGZpeGVkIGFuZA0KPiBz cGVjaWZpYyAqc2lnbmFsaW5nKiBwcm90b2NvbCwgcmlnaHQ/IGV2ZW4gbW9yZSwgeW91IHByb2Jh Ymx5IG1lYW4NCj4gU0lQLg0KDQpbUmFqdV0gTm8sIEkgZGlkbid0IG1lYW4gU0lQLiBNZW50aW9u IG9mICJtaWRkbGUgYm94ZXMiIGRvIG5vdCB0cmFuc2xhdGUgdG8gU0lQIQ0KT25lIGNhbiBzZW5k IHlvdXIgU0RQIGluIGEgdG90YWxseSBkaWZmZXJlbnQgZm9ybWF0IGluIGEgdG90YWxseSANCmRp ZmZlcmVudCBzaWduYWxpbmcgcHJvdG9jb2wgKFhNUFAgb3IgWFlaKS4gQSBzaW1wbGUgY2FzZSBm b3IgYSBtaWRkbGUgYm94DQpjb3VsZCBiZSBhIGNvbmYgYnJpZGdlLg0KDQo+IEdpdmVuIHRoZSBm YWN0IHRoYXQgV2ViUlRDIGlzIHN1cHBvc2VkIHRvIGJlICJzaWduYWxpbmcgcHJvdG9jb2wiDQo+ IGFnbm9zdGljIEkgZG9uJ3QgYnV5IHlvdXIgcmF0aW9uYWxlLg0KDQpbUmFqdV0gWWVzLCBXZWJS VEMgaXMgc2lnbmFsaW5nIHByb3RvY29sIGFnbm9zdGljLiBJIGRvIHJlYWxpemUgdGhlcmUgaXMg c29tZSBjb25mdXNpb24gYWJvdXQgbWl4aW5nIHNpZ25hbGluZyBwcm90b2NvbCBPL0Egd2l0aCBu ZXcgU0RQIG9mZmVyIGF0IFdlYlJUQyBjbGllbnQuDQpUaGF0J3Mgbm90IHdoYXQgd2UgYXJlIHRh bGtpbmcgYWJvdXQgaGVyZS4gSSBhbSB0YWxraW5nIGFib3V0IGEgbmVlZCBmb3IgV2ViUlRDIHRv ICJ0cmlnZ2VyIiBhIG5ldyBPL0EgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zIChlLmcuIGMvbT0g bGluZXMgZG8gbm90IG1hdGNoIHdpdGggc2VsZWN0ZWQgY2FuZGlkYXRlKSBzbyB0aGF0IGl0IGFs bG93cyB1bmRlcmx5aW5nIG5ldHdvcmsgdG8gcmVjb25maWd1cmUgaXRzZWxmIGZvciB0aGUgbmV3 IGZsb3cuIFBlZXJDb25uZWN0aW9uIChQQykgQVBJIHNob3VsZCBhbGxvdyBzdWNoIHRyaWdnZXJz IHRvIGJlIGRlbGl2ZXJlZCB0byB0aGUgYXBwbGljYXRpb24uIFRoZW4sIGl0J3MgdXAgdG8gdGhl IGFwcGxpY2F0aW9uIChhbmQgdGhlIHNlcnZpY2UgcHJvdmlkZXIpIHRvIGhhbmRsZSBpdCBhcHBy b3ByaWF0ZWx5IHRvIGVpdGhlciBpbml0aWF0ZSBhIG5ldyBTRFAgTy9BIHdpdGggaXRzIGZhdm9y aXRlIHNpZ25hbGluZyBwcm90b2NvbCBvciBzaW1wbHkgZGlzY2FyZCBpdC4NCg0KPiANCj4gDQo+ ID4gICAgRm9yIHRoZSBzYW1lIHJlYXNvbiwgSSBhbHNvIGFncmVlIHdpdGggdGhlIGNvbW1lbnQg dGhhdCwgYSBuZXcgU0RQIE8vQQ0KPiBtdXN0IGJlIHNlbnQNCj4gPiAgICBpZiB0aGUgc2VsZWN0 ZWQgY2FuZGlkYXRlIGlzIG5vdCB0aGUgb25lIGxpc3RlZCBpbiBjL209IGxpbmVzLg0KPiANCj4g SSdtIGdsYWQgdGhhdCB0aGF0IGRvZXMgbm90IG9jY3VyIG5vdywgYW5kIG5vIG9uZSBXZWJSVEMg YnJvd3NlciBjYXJlcw0KPiBhYm91dCB0aGF0Lg0KDQpbUmFqdV0gQSBTRFAgTy9BIGZvciBzaW1w bGUgY2hhbmdlcyBsaWtlIGRlZmF1bHQgY2FuZGlkYXRlIGNoYW5nZWQgaXMgbm90IG5lZWRlZCBm b3IgYWxsIGFwcGxpY2F0aW9ucy4gQnV0IGluIHNvbWUgY2FzZXMgKGUuZy4gUENSRiBkZWRpY2F0 ZWQgYmVhcmVycyBvciB1c2luZyBSU1ZQKSBoYXZpbmcgYSBuZXcgU0RQIE8vQSBhbGxvd3MgcHJv dmlkaW5nIGJldHRlciBRb1MuIElmIGEgc2VydmljZS9hcHAgcHJvdmlkZXIgd2FudHMgdG8gZ28g dGhhdCBleHRyYSBtaWxlIHRoZW4gV2ViUlRDIHNob3VsZCBwcm9iYWJseSBhbGxvdyBpdC4NCg0K PiANCj4gDQo+ID4gICAgV2ViUlRDIHNob3VsZCBub3QgYXNzdW1lIHRoYXQgbWlkZGxlIGJveGVz IGRvbid0IGV4aXN0LiBNaWRkbGUgYm94ZXMgZG8NCj4gZXhpc3QgZm9yDQo+ID4gICAgVmVyeSB2 YWxpZCByZWFzb25zIChub3QganVzdCBTSVAvSU1TLCB3aGljaCBpcyBvbmx5IG9uZSBleGFtcGxl KS4NCj4gRXNwZWNpYWxseSB3aXRoDQo+ID4gICAgdGhlIHRyZW5kIHRvd2FyZHMgU0ROLCB0aGUg Y29udHJvbCBwbGFuZSBhbmQgZGF0YS91c2VyIHBsYW5lIGFyZSBiZWluZw0KPiBzZXBhcmF0ZWQN Cj4gPiAgICBmb3IgZ29vZCBhbmQgdGhlIGNvbnRyb2wgcGxhbmUgbmVlZHMgdHJpZ2dlcnMgdG8g cmVjb25maWd1cmUgdGhlDQo+IG5ldHdvcmsgZm9yIGJldHRlcg0KPiA+ICAgIFFvUy4gU2VuZGlu ZyBuZXcgTy9BIChwbGVhc2UgZG8gbm90IGVxdWF0ZSB0aGlzIHRvIFNJUCwgaXQgY2FuIGJlIGFu eQ0KPiBzaWduYWxpbmcNCj4gPiAgICBwcm90b2NvbCBhbmQgZXZlbiBub3QgbmVjZXNzYXJpbHkg U0RQIGZvcm1hdCkgYWNoaWV2ZXMgdGhhdC4NCj4gDQo+IElmIHNvIGl0IGNhbiBiZSBzaWduYWxl ZCAqYW55aG93KiAodXAgdG8gdGhlIHNwZWNpZmljIGFwcGxpY2F0aW9uIC8NCj4gdmVuZG9yKSwg YnV0IHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgYWJvdXQgdGhlIHJlcXVpcmVtZW50IG9mIHNpZ25h bGluZw0KPiBhIG5ldyBTRFAgKGFzIHRoZSBSRkMgbWFuZGF0ZXMpLg0KDQpbUmFqdV0gWWVzLCBp dCBpcyB1cCB0byB0aGUgc3BlY2lmaWMgYXBwbGljYXRpb24vdmVuZG9yLiBCdXQsIHRvIGFjaGll dmUgdGhpcyB1bmRlcmx5aW5nIFBDL0pTRVAgQVBJIHNob3VsZCBwcm92aWRlIG1lY2hhbmlzbXMg dG86DQoxLiBJbmZvcm0gYXBwbGljYXRpb24gd2hlbiBkZWZhdWx0IGNhbmRpZGF0ZSBjaGFuZ2Vz L3NlbGVjdGVkLiBTbywgdGhhdCBhcHBsaWNhdGlvbg0KICAgY2FuIGRvIHdoYXRldmVyIGl0IHdh bnRzIHRvIGRvIHdpdGggdGhhdCBpbmZvLg0KMi4gTWFrZSBzdXJlIGMvbT0gbGluZXMgYXJlIGZv cm1hdHRpbmcgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBkZWZhdWx0L3NlbGVjdGVkDQogICBjYW5k aWRhdGUuIFRoYXQgbWVhbnMgdXNpbmcgb2YgUlRQL0FWUEYgaW5kZXBlbmRlbnQgb2YgYWN0dWFs IHRyYW5zcG9ydCBpcyANCiAgIG5vdCBjb3JyZWN0Lg0KRXhpc3RpbmcgUEMgY2FsbGJhY2sgb25p Y2Vjb25uZWN0aW9uc3RhdGVjaGFuZ2UoKSBtYXkgYmUgdXNlZCB0byBzb2x2ZSBib3RoIG9mIHRo ZXNlLg0KSG93ZXZlciwgY3JlYXRlT2ZmZXIoKSBjYWxsZWQgYWZ0ZXIgdGhpcyBjYWxsYmFjayBz aG91bGQgaGF2ZSB0aGUgdXBkYXRlZCBjL209DQpsaW5lcyBwZXIgdGhlIHNlbGVjdGVkIGNhbmRp ZGF0ZShzKS4gTm90IHN1cmUgaWYgYnJvd3NlcnMgZG8gZWl0aGVyIG9yIGJvdGggb2YgdGhlc2Ug dG9kYXk/ISBXaXRob3V0IGNsZWFyIHJlcXVpcmVtZW50cyBicm93c2VycyBtYXkgbm90IGltcGxl bWVudCB0aGlzIHRyaWdnZXIuIEkgdGhpbmssIHRoaXMgaXMgd2hhdCB3ZSBuZWVkIGZyb20gdGhl IFBDIEFQSSBhbmQgYnJvd3NlcnMgc28gdGhhdCBzb21lIGFwcGxpY2F0aW9ucyBjYW4gdGFrZSBh ZHZhbnRhZ2Ugb2YgdGhpcyBmb3IgYmV0dGVyIFFvUyBvciBvdGhlciByZWFzb25zLg0KDQpCUg0K UmFqdQ0KDQoNCj4gDQo+IA0KPiBSZWdhcmRzLg0KPiANCj4gDQo+IA0KPiAtLQ0KPiBJw7Fha2kg QmF6IENhc3RpbGxvDQo+IDxpYmNAYWxpYXgubmV0Pg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBy dGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWINCg== From nobody Tue Jun 3 08:20:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCD01A02F1 for ; Tue, 3 Jun 2014 08:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 mXfwrV_0DSoa for ; Tue, 3 Jun 2014 08:20:15 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276381A02E6 for ; Tue, 3 Jun 2014 08:20:15 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j5so13340026qga.14 for ; Tue, 03 Jun 2014 08:20:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=o+0CK4l3ofbLlpe2MFs2QnuesSGjitoSa9vDERFVeXE=; b=RwqPZH24A3SlXlJvlqueJtdfnpW1GU/nWxkvgdIDtpeBlHvo+SZBOc01l7gT21Pjct eZzmcSJyfOUljHuVVCqZ2XL3MPx0P3aT0K24uOrs6woGlHiMQ/9ztstiufC2xBp1gq1T Zb52vrJHF71cggfXSHZNHycevfOgVvZXp95oAcYmWrAEI9whE5zSAZbv93yC5+LsAV9G IQgs5317GZckfr2mY4QrkS2UICcjR2sSl8LxYxpEDfSuc0Pf8UrWKayOgIi1xskv9bEM obA6Yj7T60qUhj/u7rx7mS0grHr+/09uV/9bx7Vj1h5UNHF/aNxaUTWJll3atQDZ0hHc SY9g== X-Gm-Message-State: ALoCoQnnO1n+yNKHGnOi8mTAUw3s76kxaiUMDzqJkN1OvWhMAGIGpK0v8qDPDOqjnQxmuiQTK3Ko X-Received: by 10.140.40.81 with SMTP id w75mr57854162qgw.112.1401808808966; Tue, 03 Jun 2014 08:20:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 08:19:47 -0700 (PDT) In-Reply-To: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 17:19:47 +0200 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wmbHJb-9dj6DLf-NpIZteWNd0hU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:20:16 -0000 2014-06-03 17:14 GMT+02:00 Makaraju, Maridi Raju (Raju) : > Yes, it is up to the specific application/vendor. But, to achieve this un= derlying PC/JSEP API should provide mechanisms to: > 1. Inform application when default candidate changes/selected. So, that a= pplication > can do whatever it wants to do with that info. OK > 2. Make sure c/m=3D lines are formatting is consistent with the default/s= elected > candidate. That means using of RTP/AVPF independent of actual transpor= t is > not correct. OK > Existing PC callback oniceconnectionstatechange() may be used to solve bo= th of these. > However, createOffer() called after this callback should have the updated= c/m=3D > lines per the selected candidate(s). Not sure if browsers do either or bo= th of these today?! Without clear requirements browsers may not implement t= his trigger. I think, this is what we need from the PC API and browsers so = that some applications can take advantage of this for better QoS or other r= easons. My main concern is about whether a ICE endpoint should allow "on-the-fly" candidate-pair changes when such a new SDP O/A does not take place. That is what worries me, and the RFC is not clear about that. Regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 08:51:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BEB1A02B7 for ; Tue, 3 Jun 2014 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHQSAP0K6w4a for ; Tue, 3 Jun 2014 08:51:38 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BFC1A020E for ; Tue, 3 Jun 2014 08:51:37 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hq11so5038928vcb.39 for ; Tue, 03 Jun 2014 08:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=ufdv5UVMWfpN+tTbm9IWgUwKLGbIl3JjjrnFi/eUay0=; b=d+o2mBWpARkXdMz3tMpIzb7vhTp/fZHqwYTdRCdoJ3LtbAum5CGaxxCTKdtSaFel9A RUShUQA8dJadTOzZXHBIJSgjKcWZlJlr3dsGcXC8Og08SIYcVhjatwt5M4/3lOJP1DqM 1gMcxC1vY0Bo5g2u8y80yOEM7FbPtHHZGWZeIOn6ZQLbl5V/cDSXPwL3dVvjpFBq2/Jk JI1NBfrCjKbVHw1BRMyQvGcBUyz8Qga+VkdOp83k4/pufaO9cbvMbNylLK/tcZ77+yIv aCxswrLQyQTPQaWFSkYQEk07OQSkYoSueRETuIz0A8tlQiQ5pMdvOwfqvphNlgcG88o8 RkMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=ufdv5UVMWfpN+tTbm9IWgUwKLGbIl3JjjrnFi/eUay0=; b=hsa565OT/7B1DHcmQEka3qukfKrFSfftgAEmQvigM7ldqTdatoOPRNuUevnh/U5UND ZY58hGrMQrxyl5F7aY0J0jgfuPDhHiWbftQ4ZF+7TXOrprHNnFC55v4qrPIG2xDkbLwS ThNe2AhFkqSZqy654HvBh2vpYZrTkbeSdaVO3Suz+BA+6OerF0ihd7KE2x8TNru8H+JQ 7z7Yu8sKwLr4SVP5unPRNJWYVjx7nxfdQbzaaAxYlpvvFt5dgfUgNAQUaUA0uYIVKm+H USFVdyLPtToq85hqiIwQkWg0OOiXS8rhWYq5XkSxFOP12VTzMLM5L4wskMX0O0n3+QdF oO9A== X-Gm-Message-State: ALoCoQnQG8lIjq5wTSCuXLqq11XsB8Q7o3+OkohLVQ93ONXKOcolXD8/PAIdlY6jV/Yg14yOgc9G X-Received: by 10.52.235.97 with SMTP id ul1mr2316672vdc.87.1401810691396; Tue, 03 Jun 2014 08:51:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Tue, 3 Jun 2014 08:51:11 -0700 (PDT) From: Justin Uberti Date: Tue, 3 Jun 2014 08:51:11 -0700 Message-ID: To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=047d7bd751c04db51304faf07caf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NV3fIlKGPXVSrDSttUVLIgt04EY Cc: "rtcweb@ietf.org" Subject: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:51:40 -0000 --047d7bd751c04db51304faf07caf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The other thread has been hijacked by an ICE discussion, so reasking here. Should use of DTLS be indicated by: - UDP/TLS/RTP/SAVPF on the m=3D line - RTP/SAVPF, and presence of an a=3Dfingerprint line Some have expressed a preference for RTP/SAVPF, as being more backwards compatible. However, others have expressed a preference for UDP/TLS/RTP/SAVPF, as that is what RFC 5763/4 says. The last time this came up, in September 2013, the UDP/TLS/RTP/SAVPF proponents were able to convince me to include this into jsep-06, so if we want to change it back, I'd like to see a clear consensus. On Tue, Jun 3, 2014 at 2:08 AM, Lorenzo Miniero wrote: > On Tue, 03 Jun 2014 10:32:43 +0200 > Sergio Garcia Murillo wrote: > > > On the other side, keeping "RTP/SAVFP" would have allowed a server > > (SBC/MCU/etc) to send an offer without knowing in advance if the > > other side supports SDES or DTLS, by sending both the crypto and > > fingerprint attributes and let the receiver choose which one to use > > (as chrome has done until recently). I know that it is not important > > for webrtc, as DTLS is mandatory and SDES is a must not, but for > > supporting other legacy clients it may be easier for some of us. > > > > Best regards > > Sergio > > > > > I guess that was the rationale for having RTP/SAVPF in the first > place, as initially both SDES and DTLS-SRTP were allowed. There are > people confused about not having UDP/TLS/RTP/SAVPF now that DTLS-SRTP > is mandatory (Asterisk developers, for instance, although getting it to > work from a signalling point of view is a trivial replace matter in > JavaScript), but I agree it makes sense to keep RTP/SAVPF, if not just > because all browser implementations right now (the legacy of a few > months from now on) only accept that, which would render them useless > having this change. > > Lorenzo > > > > > El 03/06/2014 8:04, Justin Uberti escribi=C3=B3: > > > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it > > > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one > > > has to guess at this from the presence of a=3Dfingerprint, which > > > seems dodgy, given that endpoints are free to ignore SDP attributes > > > they don't understand. > > > > > > The fact that UDP and TLS appear in the m=3D line is kind of > > > unfortunate, but I think it can be interpreted as "do DTLS-SRTP". > > > > > > > > > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson > > > > wrote: > > > > > > On 2 June 2014 10:13, Harald Alvestrand > > > wrote: > > > > The current implementations both send "RTP/SAVPF" in this > > > > field. > > > But this > > > > usage is not specified by RFC 5764. > > > > > > Sounds easy to me. The SDP doesn't matter and can say anything. > > > "RTP/SAVPF" is as good as any other sequence of octets. > > > > > > I'm sure that JSEP can include a requirement that is directly > > > contradictory to an existing RFC. That happens all the time. > > > At least this time it can be explicit. > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > > > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd751c04db51304faf07caf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The other thread has been hijacked by an ICE discussion, s= o reasking here. Should use of DTLS be indicated by:
- UDP/TLS/RTP/SAVP= F on the m=3D line
- RTP/SAVPF, and presence of an a=3Dfingerprint = line

Some have expressed a preference f= or RTP/SAVPF, as being more backwards compatible. However, others have expr= essed a preference for UDP/TLS/RTP/SAVPF, as that is what RFC 5763/4 says. = The last time this came up, in September 2013, the=C2=A0UDP/TLS/RTP/SAVPF p= roponents were able to convince me to include this into jsep-06, so if we w= ant to change it back, I'd like to see a clear consensus.

On Tue, Jun 3, 2014 at 2:08 AM, Lorenzo Mini= ero <lorenzo@meetecho.com> wrote:
On Tue, 03 Jun 2014 10:32:43 +0200
Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

> On the other side, keeping "RTP/SAVFP" would have allowed a = server
> (SBC/MCU/etc) to send an offer without knowing in advance if the
> other side supports SDES or DTLS, by sending both the crypto and
> fingerprint attributes and let the receiver choose which one to use > (as chrome has done until recently). I know that it is not important > for webrtc, as DTLS is mandatory and SDES is a must not, but for
> supporting other legacy clients it may be easier for some of us.
>
> Best regards
> Sergio
>


I guess that was the rationale for having RTP/SAVPF in the first
place, as initially both SDES and DTLS-SRTP were allowed. There are
people confused about not having UDP/TLS/RTP/SAVPF now that DTLS-SRTP
is mandatory (Asterisk developers, for instance, although getting it to
work from a signalling point of view is a trivial replace matter in
JavaScript), but I agree it makes sense to keep RTP/SAVPF, if not just
because all browser implementations right now (the legacy of a few
months from now on) only accept that, which would render them useless
having this change.

Lorenzo



> El 03/06/2014 8:04, Justin Uberti escribi=C3=B3:
> > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that i= t
> > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, on= e
> > has to guess at this from the presence of a=3Dfingerprint, which<= br> > > seems dodgy, given that endpoints are free to ignore SDP attribut= es
> > they don't understand.
> >
> > The fact that UDP and TLS appear in the m=3D line is kind of
> > unfortunate, but I think it can be interpreted as "do DTLS-S= RTP".
> >
> >
> > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson
> > <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
> >
> > =C2=A0 =C2=A0 On 2 June 2014 10:13, Harald Alvestrand <harald@alvestrand.no
> > =C2=A0 =C2=A0 <mailto:harald@alvestrand.no>> wrote:
> > =C2=A0 =C2=A0 > The current implementations both send "RT= P/SAVPF" in this
> > =C2=A0 =C2=A0 > field.
> > =C2=A0 =C2=A0 But this
> > =C2=A0 =C2=A0 > usage is not specified by RFC 5764.
> >
> > =C2=A0 =C2=A0 Sounds easy to me. =C2=A0The SDP doesn't matter= and can say anything.
> > =C2=A0 =C2=A0 "RTP/SAVPF" is as good as any other seque= nce of octets.
> >
> > =C2=A0 =C2=A0 I'm sure that JSEP can include a requirement th= at is directly
> > =C2=A0 =C2=A0 contradictory to an existing RFC. =C2=A0That happen= s all the time.
> > At least this time it can be explicit.
> >
> > =C2=A0 =C2=A0 _______________________________________________
> > =C2=A0 =C2=A0 rtcweb mailing list
> > =C2=A0 =C2=A0 rtcweb@iet= f.org <mailto:rtcweb@ietf.org= >
> > =C2=A0 =C2=A0 https://www.ietf.= org/mailman/listinfo/rtcweb
> >
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>

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

--047d7bd751c04db51304faf07caf-- From nobody Tue Jun 3 09:20:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB671A02FC for ; Tue, 3 Jun 2014 09:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-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 VIxZ2ew6eXfz for ; Tue, 3 Jun 2014 09:20:44 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D36C1A020E for ; Tue, 3 Jun 2014 09:20:44 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s53GKZ35008531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jun 2014 11:20:36 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s53GKWHJ023125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 12:20:35 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 12:20:32 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Justin Uberti , Lorenzo Miniero Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPf0PY6zllukqgI0+lS1j0hPoDEJtfiwmQ Date: Tue, 3 Jun 2014 16:20:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E3DFD6EUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hSwaS1G_MdMQRfcbrRAg5TIaX0M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:20:47 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E3DFD6EUS70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIOKAnFVEUC9UTFMvUlRQL1NBVlBGIG9uIHRoZSBtPSBsaW5l4oCdDQoNClBsZWFzZSBk b27igJl0IHRyZWF0IHRoaXMgbGlrZSBhbm90aGVyIGhpamFja2luZyBhdHRlbXB0IOKYuiBidXQs IHVuZm9ydHVuYXRlbHkgdGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBpcyBzb21ld2hhdCByZWxhdGVk IHRvIHRoZSBJQ0UgZGlzY3Vzc2lvbi4NClJGQyAyMzI3IGNsZWFybHkgc2F5cyB0cmFuc3BvcnQg Zm9yIFJUUC9BVlAgaXMgVURQLiBSVFAvU0FWUEYgUkZDIDUxMjQgbW9zdGx5IGluaGVyaXRzIHRo YXQgKGFuZCBSVFAvQVZQRiBSRkMgNDU4NSkgYW5kIGluZGljYXRlcyB0cmFuc3BvcnQgYXMgdXN1 YWxseSBVRFAgKGFsdGVybmF0aXZlIGJlaW5nIERDQ1ApLg0KU28sIHVzaW5nIFJUUC9TQVZQRiBm b3IgRFRMUy1TUlRQIGRvZXMgbm90IHNlZW0gY29uc2lzdGVudCB3aXRoIHRoZXNlIFJGQ3MuIE1v cmUgaW1wb3J0YW50bHkgRFRMUy1TUlRQIHVzZSBvZiDigJxVRFAvVExTL1JUUC9TQVZQRiDigJwg aXMgY2xlYXJseSBkZWZpbmVkIGluIFJGQyA1NzY0Lg0KDQpOb3cgdGhlIGNhc2Ugb2YsIOKAnGNo YW5naW5nIGZyb20gZGVmYXVsdCBVRFAgdG8gZmluYWwgVENQIHRyYW5zcG9ydCBvciB2aWNlLXZl cnNh4oCdIGZvciBTUlRQIGhhcyB0byBiZSBoYW5kbGVkIHBlciBJQ0UgUkZDIHJ1bGVzLCB3aGlj aCBzYXlzIGMvbT0gbGluZXMgc2hvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGVmYXVsdCBk ZXN0aW5hdGlvbi4gU28sIHVzaW5nIOKAnFJUUC9TQVZQRuKAnSB0byBjb3ZlciBhbGwgdHJhbnNw b3J0cyBkb2VzIG5vdCBzb3VuZCByaWdodCB0byBtZSwgZXNwZWNpYWxseSB3aGVuIGJyb3dzZXIg aGFzIHRvIHVwZGF0ZSB0aGUgU0RQIHdoZW4gZmluYWwgc2VsZWN0ZWQgY2FuZGlkYXRlIGFuZC9v ciB0cmFuc3BvcnQgY2hhbmdlcyBhbnl3YXkuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzUyNDUjc2VjdGlvbi04LjEuMg0KDQogICAgICAgICAgICAgICAgICAgIElmIGFuIGFnZW50 IGlzIGNvbnRyb2xsaW5nLCBpdCBleGFtaW5lcyB0aGUgaGlnaGVzdC1wcmlvcml0eQ0KICAgICAg ICAgbm9taW5hdGVkIGNhbmRpZGF0ZSBwYWlyIGZvciBlYWNoIGNvbXBvbmVudCBvZiBlYWNoIG1l ZGlhDQogICAgICAgICBzdHJlYW0uICBJZiBhbnkgb2YgdGhvc2UgY2FuZGlkYXRlIHBhaXJzIGRp ZmZlciBmcm9tIHRoZQ0KICAgICAgICAgZGVmYXVsdCBjYW5kaWRhdGUgcGFpcnMgaW4gdGhlIG1v c3QgcmVjZW50IG9mZmVyL2Fuc3dlcg0KICAgICAgICAgZXhjaGFuZ2UsIHRoZSBjb250cm9sbGlu ZyBhZ2VudCBNVVNUIGdlbmVyYXRlIGFuIHVwZGF0ZWQgb2ZmZXINCiAgICAgICAgIGFzIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDk8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0 aW9uLTk+Lg0KDQpCUg0KUmFqdQ0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogVHVlc2RheSwg SnVuZSAwMywgMjAxNCAxMDo1MSBBTQ0KVG86IExvcmVuem8gTWluaWVybw0KQ2M6IHJ0Y3dlYkBp ZXRmLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gUmV0cnk6IERUTFMgY2FycnlpbmcgUlRQL1NBVlBG IG92ZXIgSUNFOiBUbyBVRFAgb3Igbm90IHRvIFVEUD8NCg0KVGhlIG90aGVyIHRocmVhZCBoYXMg YmVlbiBoaWphY2tlZCBieSBhbiBJQ0UgZGlzY3Vzc2lvbiwgc28gcmVhc2tpbmcgaGVyZS4gU2hv dWxkIHVzZSBvZiBEVExTIGJlIGluZGljYXRlZCBieToNCi0gVURQL1RMUy9SVFAvU0FWUEYgb24g dGhlIG09IGxpbmUNCi0gUlRQL1NBVlBGLCBhbmQgcHJlc2VuY2Ugb2YgYW4gYT1maW5nZXJwcmlu dCBsaW5lDQoNClNvbWUgaGF2ZSBleHByZXNzZWQgYSBwcmVmZXJlbmNlIGZvciBSVFAvU0FWUEYs IGFzIGJlaW5nIG1vcmUgYmFja3dhcmRzIGNvbXBhdGlibGUuIEhvd2V2ZXIsIG90aGVycyBoYXZl IGV4cHJlc3NlZCBhIHByZWZlcmVuY2UgZm9yIFVEUC9UTFMvUlRQL1NBVlBGLCBhcyB0aGF0IGlz IHdoYXQgUkZDIDU3NjMvNCBzYXlzLiBUaGUgbGFzdCB0aW1lIHRoaXMgY2FtZSB1cCwgaW4gU2Vw dGVtYmVyIDIwMTMsIHRoZSBVRFAvVExTL1JUUC9TQVZQRiBwcm9wb25lbnRzIHdlcmUgYWJsZSB0 byBjb252aW5jZSBtZSB0byBpbmNsdWRlIHRoaXMgaW50byBqc2VwLTA2LCBzbyBpZiB3ZSB3YW50 IHRvIGNoYW5nZSBpdCBiYWNrLCBJJ2QgbGlrZSB0byBzZWUgYSBjbGVhciBjb25zZW5zdXMuDQpP biBUdWUsIEp1biAzLCAyMDE0IGF0IDI6MDggQU0sIExvcmVuem8gTWluaWVybyA8bG9yZW56b0Bt ZWV0ZWNoby5jb208bWFpbHRvOmxvcmVuem9AbWVldGVjaG8uY29tPj4gd3JvdGU6DQpPbiBUdWUs IDAzIEp1biAyMDE0IDEwOjMyOjQzICswMjAwDQpTZXJnaW8gR2FyY2lhIE11cmlsbG8gPHNlcmdp by5nYXJjaWEubXVyaWxsb0BnbWFpbC5jb208bWFpbHRvOnNlcmdpby5nYXJjaWEubXVyaWxsb0Bn bWFpbC5jb20+PiB3cm90ZToNCg0KPiBPbiB0aGUgb3RoZXIgc2lkZSwga2VlcGluZyAiUlRQL1NB VkZQIiB3b3VsZCBoYXZlIGFsbG93ZWQgYSBzZXJ2ZXINCj4gKFNCQy9NQ1UvZXRjKSB0byBzZW5k IGFuIG9mZmVyIHdpdGhvdXQga25vd2luZyBpbiBhZHZhbmNlIGlmIHRoZQ0KPiBvdGhlciBzaWRl IHN1cHBvcnRzIFNERVMgb3IgRFRMUywgYnkgc2VuZGluZyBib3RoIHRoZSBjcnlwdG8gYW5kDQo+ IGZpbmdlcnByaW50IGF0dHJpYnV0ZXMgYW5kIGxldCB0aGUgcmVjZWl2ZXIgY2hvb3NlIHdoaWNo IG9uZSB0byB1c2UNCj4gKGFzIGNocm9tZSBoYXMgZG9uZSB1bnRpbCByZWNlbnRseSkuIEkga25v dyB0aGF0IGl0IGlzIG5vdCBpbXBvcnRhbnQNCj4gZm9yIHdlYnJ0YywgYXMgRFRMUyBpcyBtYW5k YXRvcnkgYW5kIFNERVMgaXMgYSBtdXN0IG5vdCwgYnV0IGZvcg0KPiBzdXBwb3J0aW5nIG90aGVy IGxlZ2FjeSBjbGllbnRzIGl0IG1heSBiZSBlYXNpZXIgZm9yIHNvbWUgb2YgdXMuDQo+DQo+IEJl c3QgcmVnYXJkcw0KPiBTZXJnaW8NCj4NCg0KSSBndWVzcyB0aGF0IHdhcyB0aGUgcmF0aW9uYWxl IGZvciBoYXZpbmcgUlRQL1NBVlBGIGluIHRoZSBmaXJzdA0KcGxhY2UsIGFzIGluaXRpYWxseSBi b3RoIFNERVMgYW5kIERUTFMtU1JUUCB3ZXJlIGFsbG93ZWQuIFRoZXJlIGFyZQ0KcGVvcGxlIGNv bmZ1c2VkIGFib3V0IG5vdCBoYXZpbmcgVURQL1RMUy9SVFAvU0FWUEYgbm93IHRoYXQgRFRMUy1T UlRQDQppcyBtYW5kYXRvcnkgKEFzdGVyaXNrIGRldmVsb3BlcnMsIGZvciBpbnN0YW5jZSwgYWx0 aG91Z2ggZ2V0dGluZyBpdCB0bw0Kd29yayBmcm9tIGEgc2lnbmFsbGluZyBwb2ludCBvZiB2aWV3 IGlzIGEgdHJpdmlhbCByZXBsYWNlIG1hdHRlciBpbg0KSmF2YVNjcmlwdCksIGJ1dCBJIGFncmVl IGl0IG1ha2VzIHNlbnNlIHRvIGtlZXAgUlRQL1NBVlBGLCBpZiBub3QganVzdA0KYmVjYXVzZSBh bGwgYnJvd3NlciBpbXBsZW1lbnRhdGlvbnMgcmlnaHQgbm93ICh0aGUgbGVnYWN5IG9mIGEgZmV3 DQptb250aHMgZnJvbSBub3cgb24pIG9ubHkgYWNjZXB0IHRoYXQsIHdoaWNoIHdvdWxkIHJlbmRl ciB0aGVtIHVzZWxlc3MNCmhhdmluZyB0aGlzIGNoYW5nZS4NCg0KTG9yZW56bw0KDQoNCg0KPiBF bCAwMy8wNi8yMDE0IDg6MDQsIEp1c3RpbiBVYmVydGkgZXNjcmliacOzOg0KPiA+IEkgdGhpbmsg dGhlcmUgaXMgdmFsdWUgaW4gc3BlY2lmeWluZyBVRFAvVExTL1JUUC9TQVZQRiwgaW4gdGhhdCBp dA0KPiA+IHVuYW1iaWd1b3VzbHkgaW5kaWNhdGVzIHRoZSBkZXNpcmUgdG8gZG8gRFRMUy1TUlRQ LiBPdGhlcndpc2UsIG9uZQ0KPiA+IGhhcyB0byBndWVzcyBhdCB0aGlzIGZyb20gdGhlIHByZXNl bmNlIG9mIGE9ZmluZ2VycHJpbnQsIHdoaWNoDQo+ID4gc2VlbXMgZG9kZ3ksIGdpdmVuIHRoYXQg ZW5kcG9pbnRzIGFyZSBmcmVlIHRvIGlnbm9yZSBTRFAgYXR0cmlidXRlcw0KPiA+IHRoZXkgZG9u J3QgdW5kZXJzdGFuZC4NCj4gPg0KPiA+IFRoZSBmYWN0IHRoYXQgVURQIGFuZCBUTFMgYXBwZWFy IGluIHRoZSBtPSBsaW5lIGlzIGtpbmQgb2YNCj4gPiB1bmZvcnR1bmF0ZSwgYnV0IEkgdGhpbmsg aXQgY2FuIGJlIGludGVycHJldGVkIGFzICJkbyBEVExTLVNSVFAiLg0KPiA+DQo+ID4NCj4gPiBP biBNb24sIEp1biAyLCAyMDE0IGF0IDExOjUzIEFNLCBNYXJ0aW4gVGhvbXNvbg0KPiA+IDxtYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4gPG1h aWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbT4+PiB3cm90ZToNCj4gPg0KPiA+ICAgICBPbiAyIEp1bmUgMjAxNCAxMDoxMywgSGFyYWxk IEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFu ZC5ubz4NCj4gPiAgICAgPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxk QGFsdmVzdHJhbmQubm8+Pj4gd3JvdGU6DQo+ID4gICAgID4gVGhlIGN1cnJlbnQgaW1wbGVtZW50 YXRpb25zIGJvdGggc2VuZCAiUlRQL1NBVlBGIiBpbiB0aGlzDQo+ID4gICAgID4gZmllbGQuDQo+ ID4gICAgIEJ1dCB0aGlzDQo+ID4gICAgID4gdXNhZ2UgaXMgbm90IHNwZWNpZmllZCBieSBSRkMg NTc2NC4NCj4gPg0KPiA+ICAgICBTb3VuZHMgZWFzeSB0byBtZS4gIFRoZSBTRFAgZG9lc24ndCBt YXR0ZXIgYW5kIGNhbiBzYXkgYW55dGhpbmcuDQo+ID4gICAgICJSVFAvU0FWUEYiIGlzIGFzIGdv b2QgYXMgYW55IG90aGVyIHNlcXVlbmNlIG9mIG9jdGV0cy4NCj4gPg0KPiA+ICAgICBJJ20gc3Vy ZSB0aGF0IEpTRVAgY2FuIGluY2x1ZGUgYSByZXF1aXJlbWVudCB0aGF0IGlzIGRpcmVjdGx5DQo+ ID4gICAgIGNvbnRyYWRpY3RvcnkgdG8gYW4gZXhpc3RpbmcgUkZDLiAgVGhhdCBoYXBwZW5zIGFs bCB0aGUgdGltZS4NCj4gPiBBdCBsZWFzdCB0aGlzIHRpbWUgaXQgY2FuIGJlIGV4cGxpY2l0Lg0K PiA+DQo+ID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gICAgIHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gPiAgICAgcnRjd2ViQGlldGYub3Jn PG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+IDxtYWlsdG86cnRjd2ViQGlldGYub3JnPG1haWx0bzpy dGN3ZWJAaWV0Zi5vcmc+Pg0KPiA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ ID4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E3DFD6EUS70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uZ3JleQ0K CXttc28tc3R5bGUtbmFtZTpncmV5O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiYjNDM7MSBmb3Ig4oCcVURQL1RMUy9SVFAvU0FWUEYgb24gdGhlIG09IGxpbmXigJ08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlBsZWFzZSBkb27igJl0IHRyZWF0IHRoaXMgbGlrZSBhbm90aGVyIGhpamFja2luZyBhdHRl bXB0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiBidXQsIHVuZm9ydHVuYXRlbHkgdGhlIHJhdGlvbmFsZSBmb3IgdGhp cyBpcyBzb21ld2hhdCByZWxhdGVkIHRvIHRoZSBJQ0UgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UkZDIDIzMjcgY2xlYXJseSBzYXlzIHRyYW5zcG9ydCBmb3IgUlRQ L0FWUCBpcyBVRFAuIFJUUC9TQVZQRiBSRkMgNTEyNCBtb3N0bHkgaW5oZXJpdHMgdGhhdCAoYW5k IFJUUC9BVlBGIFJGQyA0NTg1KSBhbmQgaW5kaWNhdGVzIHRyYW5zcG9ydCBhcyB1c3VhbGx5IFVE UCAoYWx0ZXJuYXRpdmUNCiBiZWluZyBEQ0NQKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+U28sIHVzaW5nIFJUUC9TQVZQRiBmb3IgRFRMUy1TUlRQIGRvZXMgbm90IHNlZW0gY29uc2lz dGVudCB3aXRoIHRoZXNlIFJGQ3MuIE1vcmUgaW1wb3J0YW50bHkgRFRMUy1TUlRQIHVzZSBvZiDi gJxVRFAvVExTL1JUUC9TQVZQRiDigJwgaXMgY2xlYXJseSBkZWZpbmVkIGluIFJGQw0KIDU3NjQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Ob3cgdGhlIGNhc2Ugb2YsIOKAnGNoYW5naW5nIGZyb20gZGVmYXVsdCBVRFAg dG8gZmluYWwgVENQIHRyYW5zcG9ydCBvciB2aWNlLXZlcnNh4oCdIGZvciBTUlRQIGhhcyB0byBi ZSBoYW5kbGVkIHBlciBJQ0UgUkZDIHJ1bGVzLCB3aGljaCBzYXlzIGMvbT0gbGluZXMgc2hvdWxk DQogYmUgY29uc2lzdGVudCB3aXRoIHRoZSBkZWZhdWx0IGRlc3RpbmF0aW9uLiBTbywgdXNpbmcg 4oCcUlRQL1NBVlBG4oCdIHRvIGNvdmVyIGFsbCB0cmFuc3BvcnRzIGRvZXMgbm90IHNvdW5kIHJp Z2h0IHRvIG1lLCBlc3BlY2lhbGx5IHdoZW4gYnJvd3NlciBoYXMgdG8gdXBkYXRlIHRoZSBTRFAg d2hlbiBmaW5hbCBzZWxlY3RlZCBjYW5kaWRhdGUgYW5kL29yIHRyYW5zcG9ydCBjaGFuZ2VzIGFu eXdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUy NDUjc2VjdGlvbi04LjEuMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0 aW9uLTguMS4yPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklm IGFuIGFnZW50IGlzIGNvbnRyb2xsaW5nLCBpdCBleGFtaW5lcyB0aGUgaGlnaGVzdC1wcmlvcml0 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbm9taW5hdGVkIGNhbmRpZGF0ZSBwYWlyIGZvciBlYWNoIGNv bXBvbmVudCBvZiBlYWNoIG1lZGlhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyZWFtLiZuYnNwOyBJZiBh bnkgb2YgdGhvc2UgY2FuZGlkYXRlIHBhaXJzIGRpZmZlciBmcm9tIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRlZmF1bHQgY2FuZGlkYXRlIHBhaXJzIGluIHRoZSBtb3N0IHJlY2VudCBvZmZlci9hbnN3 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBleGNoYW5nZSwgdGhlIGNvbnRyb2xsaW5nIGFnZW50IE1VU1Qg Z2VuZXJhdGUgYW4gdXBkYXRlZCBvZmZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIGRlc2NyaWJlZCBp bg0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTki PlNlY3Rpb24gOTwvYT4uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UmFqdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRp PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMDMsIDIwMTQgMTA6NTEgQU08YnI+DQo8 Yj5Ubzo8L2I+IExvcmVuem8gTWluaWVybzxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3ZWJdIFJldHJ5OiBEVExTIGNhcnJ5aW5nIFJUUC9T QVZQRiBvdmVyIElDRTogVG8gVURQIG9yIG5vdCB0byBVRFA/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvdGhlciB0aHJlYWQgaGFzIGJl ZW4gaGlqYWNrZWQgYnkgYW4gSUNFIGRpc2N1c3Npb24sIHNvIHJlYXNraW5nIGhlcmUuIFNob3Vs ZCB1c2Ugb2YgRFRMUyBiZSBpbmRpY2F0ZWQgYnk6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LSBVRFAvVExTL1JUUC9TQVZQRiBvbiB0aGUgbT0gbGluZTxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUlRQL1NBVlBGLCBhbmQg cHJlc2VuY2Ugb2YgYW4gYT1maW5nZXJwcmludCBsaW5lPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NClNvbWUgaGF2ZSBleHByZXNzZWQgYSBwcmVmZXJlbmNlIGZvciBSVFAvU0FW UEYsIGFzIGJlaW5nIG1vcmUgYmFja3dhcmRzIGNvbXBhdGlibGUuIEhvd2V2ZXIsIG90aGVycyBo YXZlIGV4cHJlc3NlZCBhIHByZWZlcmVuY2UgZm9yIFVEUC9UTFMvUlRQL1NBVlBGLCBhcyB0aGF0 IGlzIHdoYXQgUkZDIDU3NjMvNCBzYXlzLiBUaGUgbGFzdCB0aW1lIHRoaXMgY2FtZSB1cCwgaW4g U2VwdGVtYmVyIDIwMTMsIHRoZSZuYnNwO1VEUC9UTFMvUlRQL1NBVlBGIHByb3BvbmVudHMNCiB3 ZXJlIGFibGUgdG8gY29udmluY2UgbWUgdG8gaW5jbHVkZSB0aGlzIGludG8ganNlcC0wNiwgc28g aWYgd2Ugd2FudCB0byBjaGFuZ2UgaXQgYmFjaywgSSdkIGxpa2UgdG8gc2VlIGEgY2xlYXIgY29u c2Vuc3VzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1 ZSwgSnVuIDMsIDIwMTQgYXQgMjowOCBBTSwgTG9yZW56byBNaW5pZXJvICZsdDs8YSBocmVmPSJt YWlsdG86bG9yZW56b0BtZWV0ZWNoby5jb20iIHRhcmdldD0iX2JsYW5rIj5sb3JlbnpvQG1lZXRl Y2hvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gVHVlLCAwMyBKdW4gMjAx NCAxMDozMjo0MyAmIzQzOzAyMDA8YnI+DQpTZXJnaW8gR2FyY2lhIE11cmlsbG8gJmx0OzxhIGhy ZWY9Im1haWx0bzpzZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tIj5zZXJnaW8uZ2FyY2lh Lm11cmlsbG9AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBPbiB0aGUg b3RoZXIgc2lkZSwga2VlcGluZyAmcXVvdDtSVFAvU0FWRlAmcXVvdDsgd291bGQgaGF2ZSBhbGxv d2VkIGEgc2VydmVyPGJyPg0KJmd0OyAoU0JDL01DVS9ldGMpIHRvIHNlbmQgYW4gb2ZmZXIgd2l0 aG91dCBrbm93aW5nIGluIGFkdmFuY2UgaWYgdGhlPGJyPg0KJmd0OyBvdGhlciBzaWRlIHN1cHBv cnRzIFNERVMgb3IgRFRMUywgYnkgc2VuZGluZyBib3RoIHRoZSBjcnlwdG8gYW5kPGJyPg0KJmd0 OyBmaW5nZXJwcmludCBhdHRyaWJ1dGVzIGFuZCBsZXQgdGhlIHJlY2VpdmVyIGNob29zZSB3aGlj aCBvbmUgdG8gdXNlPGJyPg0KJmd0OyAoYXMgY2hyb21lIGhhcyBkb25lIHVudGlsIHJlY2VudGx5 KS4gSSBrbm93IHRoYXQgaXQgaXMgbm90IGltcG9ydGFudDxicj4NCiZndDsgZm9yIHdlYnJ0Yywg YXMgRFRMUyBpcyBtYW5kYXRvcnkgYW5kIFNERVMgaXMgYSBtdXN0IG5vdCwgYnV0IGZvcjxicj4N CiZndDsgc3VwcG9ydGluZyBvdGhlciBsZWdhY3kgY2xpZW50cyBpdCBtYXkgYmUgZWFzaWVyIGZv ciBzb21lIG9mIHVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkczxicj4NCiZndDsg U2VyZ2lvPGJyPg0KJmd0Ozxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIHRoYXQgd2FzIHRoZSByYXRpb25hbGUgZm9yIGhhdmlu ZyBSVFAvU0FWUEYgaW4gdGhlIGZpcnN0PGJyPg0KcGxhY2UsIGFzIGluaXRpYWxseSBib3RoIFNE RVMgYW5kIERUTFMtU1JUUCB3ZXJlIGFsbG93ZWQuIFRoZXJlIGFyZTxicj4NCnBlb3BsZSBjb25m dXNlZCBhYm91dCBub3QgaGF2aW5nIFVEUC9UTFMvUlRQL1NBVlBGIG5vdyB0aGF0IERUTFMtU1JU UDxicj4NCmlzIG1hbmRhdG9yeSAoQXN0ZXJpc2sgZGV2ZWxvcGVycywgZm9yIGluc3RhbmNlLCBh bHRob3VnaCBnZXR0aW5nIGl0IHRvPGJyPg0Kd29yayBmcm9tIGEgc2lnbmFsbGluZyBwb2ludCBv ZiB2aWV3IGlzIGEgdHJpdmlhbCByZXBsYWNlIG1hdHRlciBpbjxicj4NCkphdmFTY3JpcHQpLCBi dXQgSSBhZ3JlZSBpdCBtYWtlcyBzZW5zZSB0byBrZWVwIFJUUC9TQVZQRiwgaWYgbm90IGp1c3Q8 YnI+DQpiZWNhdXNlIGFsbCBicm93c2VyIGltcGxlbWVudGF0aW9ucyByaWdodCBub3cgKHRoZSBs ZWdhY3kgb2YgYSBmZXc8YnI+DQptb250aHMgZnJvbSBub3cgb24pIG9ubHkgYWNjZXB0IHRoYXQs IHdoaWNoIHdvdWxkIHJlbmRlciB0aGVtIHVzZWxlc3M8YnI+DQpoYXZpbmcgdGhpcyBjaGFuZ2Uu PGJyPg0KPGJyPg0KTG9yZW56bzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxicj4NCiZndDsgRWwgMDMvMDYvMjAxNCA4OjA0LCBKdXN0aW4g VWJlcnRpIGVzY3JpYmnDszo8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGVyZSBpcyB2YWx1ZSBp biBzcGVjaWZ5aW5nIFVEUC9UTFMvUlRQL1NBVlBGLCBpbiB0aGF0IGl0PGJyPg0KJmd0OyAmZ3Q7 IHVuYW1iaWd1b3VzbHkgaW5kaWNhdGVzIHRoZSBkZXNpcmUgdG8gZG8gRFRMUy1TUlRQLiBPdGhl cndpc2UsIG9uZTxicj4NCiZndDsgJmd0OyBoYXMgdG8gZ3Vlc3MgYXQgdGhpcyBmcm9tIHRoZSBw cmVzZW5jZSBvZiBhPWZpbmdlcnByaW50LCB3aGljaDxicj4NCiZndDsgJmd0OyBzZWVtcyBkb2Rn eSwgZ2l2ZW4gdGhhdCBlbmRwb2ludHMgYXJlIGZyZWUgdG8gaWdub3JlIFNEUCBhdHRyaWJ1dGVz PGJyPg0KJmd0OyAmZ3Q7IHRoZXkgZG9uJ3QgdW5kZXJzdGFuZC48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgVGhlIGZhY3QgdGhhdCBVRFAgYW5kIFRMUyBhcHBlYXIgaW4gdGhlIG09IGxp bmUgaXMga2luZCBvZjxicj4NCiZndDsgJmd0OyB1bmZvcnR1bmF0ZSwgYnV0IEkgdGhpbmsgaXQg Y2FuIGJlIGludGVycHJldGVkIGFzICZxdW90O2RvIERUTFMtU1JUUCZxdW90Oy48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gTW9uLCBKdW4gMiwgMjAxNCBh dCAxMTo1MyBBTSwgTWFydGluIFRob21zb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyBPbiAyIEp1bmUgMjAxNCAxMDoxMywgSGFyYWxkIEFsdmVzdHJh bmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyI+aGFyYWxkQGFsdmVz dHJhbmQubm88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyI+aGFyYWxkQGFsdmVzdHJhbmQubm88L2E+Jmd0OyZndDsg d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJmd0OyBUaGUgY3VycmVudCBpbXBs ZW1lbnRhdGlvbnMgYm90aCBzZW5kICZxdW90O1JUUC9TQVZQRiZxdW90OyBpbiB0aGlzPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJmd0OyBmaWVsZC48YnI+DQomZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyBCdXQgdGhpczxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZndDsgdXNhZ2Ug aXMgbm90IHNwZWNpZmllZCBieSBSRkMgNTc2NC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyBTb3VuZHMgZWFzeSB0byBtZS4gJm5ic3A7VGhlIFNEUCBkb2Vzbid0 IG1hdHRlciBhbmQgY2FuIHNheSBhbnl0aGluZy48YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmcXVvdDtSVFAvU0FWUEYmcXVvdDsgaXMgYXMgZ29vZCBhcyBhbnkgb3RoZXIgc2VxdWVuY2Ug b2Ygb2N0ZXRzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEkn bSBzdXJlIHRoYXQgSlNFUCBjYW4gaW5jbHVkZSBhIHJlcXVpcmVtZW50IHRoYXQgaXMgZGlyZWN0 bHk8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBjb250cmFkaWN0b3J5IHRvIGFuIGV4aXN0 aW5nIFJGQy4gJm5ic3A7VGhhdCBoYXBwZW5zIGFsbCB0aGUgdGltZS48YnI+DQomZ3Q7ICZndDsg QXQgbGVhc3QgdGhpcyB0aW1lIGl0IGNhbiBiZSBleHBsaWNpdC48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHJ0Y3dlYiBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRj d2ViQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsgcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWI8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E3DFD6EUS70UWXCHMBA02z_-- From nobody Tue Jun 3 09:25:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEE21A02F9 for ; Tue, 3 Jun 2014 09:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 0ymJSQAOisPD for ; Tue, 3 Jun 2014 09:25:42 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139E91A0309 for ; Tue, 3 Jun 2014 09:25:41 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s53GPXtU011134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jun 2014 11:25:34 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s53GPXE0010586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 12:25:33 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 12:25:33 -0400 From: "Makaraju, Maridi Raju (Raju)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ3SJNDgjOyUGKrVMmPtCWUptfFtqwgABNWYCAAAR9gIAABnuAgAAWfQCAAAYzgIAABYyAgAABWoCAAAMnAIAAAvqAgAAG4ID//8KX0IAAVpsA//++IOCAAE1wgP//welg Date: Tue, 3 Jun 2014 16:25:33 +0000 Message-ID: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@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: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fJQdQykXFV5EjhvVhTYngBshs4c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:25:48 -0000 DQo+ID4gRXhpc3RpbmcgUEMgY2FsbGJhY2sgb25pY2Vjb25uZWN0aW9uc3RhdGVjaGFuZ2UoKSBt YXkgYmUgdXNlZCB0byBzb2x2ZQ0KPiBib3RoIG9mIHRoZXNlLg0KPiA+IEhvd2V2ZXIsIGNyZWF0 ZU9mZmVyKCkgY2FsbGVkIGFmdGVyIHRoaXMgY2FsbGJhY2sgc2hvdWxkIGhhdmUgdGhlIHVwZGF0 ZWQNCj4gYy9tPQ0KPiA+IGxpbmVzIHBlciB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlKHMpLiBOb3Qg c3VyZSBpZiBicm93c2VycyBkbyBlaXRoZXIgb3INCj4gYm90aCBvZiB0aGVzZSB0b2RheT8hIFdp dGhvdXQgY2xlYXIgcmVxdWlyZW1lbnRzIGJyb3dzZXJzIG1heSBub3QgaW1wbGVtZW50DQo+IHRo aXMgdHJpZ2dlci4gSSB0aGluaywgdGhpcyBpcyB3aGF0IHdlIG5lZWQgZnJvbSB0aGUgUEMgQVBJ IGFuZCBicm93c2VycyBzbw0KPiB0aGF0IHNvbWUgYXBwbGljYXRpb25zIGNhbiB0YWtlIGFkdmFu dGFnZSBvZiB0aGlzIGZvciBiZXR0ZXIgUW9TIG9yIG90aGVyDQo+IHJlYXNvbnMuDQo+IA0KPiBN eSBtYWluIGNvbmNlcm4gaXMgYWJvdXQgd2hldGhlciBhIElDRSBlbmRwb2ludCBzaG91bGQgYWxs b3cNCj4gIm9uLXRoZS1mbHkiIGNhbmRpZGF0ZS1wYWlyIGNoYW5nZXMgd2hlbiBzdWNoIGEgbmV3 IFNEUCBPL0EgZG9lcyBub3QNCj4gdGFrZSBwbGFjZS4gVGhhdCBpcyB3aGF0IHdvcnJpZXMgbWUs IGFuZCB0aGUgUkZDIGlzIG5vdCBjbGVhciBhYm91dA0KPiB0aGF0Lg0KW1JhanVdIExldCdzIGRl ZmluZSAib24tdGhlLWZseSIgYXMgY2hhbmdpbmcgY2FuZGlkYXRlIHBhaXIgYWZ0ZXIgSUNFIGlz ICJjb21wbGV0ZWQiLCBpLmUuIGEgZmluYWwgY2FuZGlkYXRlIGhhcyBiZWVuIHNlbGVjdGVkIGFu ZCBub21pbmF0ZWQgKHZpYSBTVFVOIFVTRS1DQU5ESURBVEUtQVRUUklCVVRFKS4gSW4gc3VjaCBh IGNhc2UgSUNFIFJGQyA1MjQ1ICI5LjEuMi4yLiBFeGlzdGluZyBNZWRpYSBTdHJlYW1zIHdpdGgg SUNFIENvbXBsZXRlZCIgc2F5czoNCg0KPFJGQyA1MjQ1IGV4Y2VycHQ+DQogICA5LjEuMi4yLiAg RXhpc3RpbmcgTWVkaWEgU3RyZWFtcyB3aXRoIElDRSBDb21wbGV0ZWQNCiAgIC4uLg0KICAgVGhl IGRlZmF1bHQgZGVzdGluYXRpb24gZm9yIG1lZGlhIChpLmUuLCB0aGUgdmFsdWVzIG9mIHRoZSBJ UA0KICAgYWRkcmVzc2VzIGFuZCBwb3J0cyBpbiB0aGUgbSBhbmQgYyBsaW5lcyB1c2VkIGZvciB0 aGF0IG1lZGlhIHN0cmVhbSkNCiAgIE1VU1QgYmUgdGhlIGxvY2FsIGNhbmRpZGF0ZSBmcm9tIHRo ZSBoaWdoZXN0LXByaW9yaXR5IG5vbWluYXRlZCBwYWlyDQogICBpbiB0aGUgdmFsaWQgbGlzdCBm b3IgZWFjaCBjb21wb25lbnQuICBUaGlzICJmaXhlcyIgdGhlIGRlZmF1bHQNCiAgIGRlc3RpbmF0 aW9uIGZvciBtZWRpYSB0byBlcXVhbCB0aGUgZGVzdGluYXRpb24gSUNFIGhhcyBzZWxlY3RlZCBm b3INCiAgIG1lZGlhLg0KICAgVGhlIGFnZW50IE1VU1QgaW5jbHVkZSBjYW5kaWRhdGUgYXR0cmli dXRlcyBmb3IgY2FuZGlkYXRlcyBtYXRjaGluZw0KICAgdGhlIGRlZmF1bHQgZGVzdGluYXRpb24g Zm9yIGVhY2ggY29tcG9uZW50IG9mIHRoZSBtZWRpYSBzdHJlYW0sIGFuZA0KICAgTVVTVCBOT1Qg aW5jbHVkZSBhbnkgb3RoZXIgY2FuZGlkYXRlcy4NCjwvUkZDIDUyNDUgZXhjZXJwdD4NCg0KU28s IG5vIG5ldyBjYW5kaWRhdGVzIGNhbiBiZSBhZGRlZCB3aGVuIGluICJjb21wbGV0ZWQiIHN0YXRl ICh3aXRob3V0IElDRSByZXN0YXJ0KS4NCg0KSWYgSUNFIGlzIGluIHJ1bm5pbmcgc3RhdGUsIHRo ZW4gbmV3IGNhbmRpZGF0ZXMgY2FuIGJlIGFkZGVkLiBCdXQgZm9yIHN1Y2gNCm5ldyBvZmZlcnMg UkZDIHNheXMgYy9tPSBsaW5lIG11c3QgbWF0Y2ggd2l0aCBkZWZhdWx0IGNhbmRpZGF0ZS9kZXN0 aW5hdGlvbi4NCg0KPFJGQyA1MjQ1IGV4Y2VycHQ+DQogICA5LjEuMi4xLiAgRXhpc3RpbmcgTWVk aWEgU3RyZWFtcyB3aXRoIElDRSBSdW5uaW5nDQogICAuLi4NCiAgIFRoZSBjb21wb25lbnQgSUQg TVVTVCByZW1haW4gdGhlIHNhbWUuICBUaGUgYWdlbnQNCiAgIE1BWSBpbmNsdWRlIGFkZGl0aW9u YWwgY2FuZGlkYXRlcyBpdCBkaWQgbm90IG9mZmVyIHByZXZpb3VzbHksIGJ1dA0KICAgd2hpY2gg aXQgaGFzIGdhdGhlcmVkIHNpbmNlIHRoZSBsYXN0IG9mZmVyL2Fuc3dlciBleGNoYW5nZSwgaW5j bHVkaW5nDQogICBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzLg0KICAgVGhlIGFnZW50IE1BWSBj aGFuZ2UgdGhlIGRlZmF1bHQgZGVzdGluYXRpb24gZm9yIG1lZGlhLiAgQXMgd2l0aA0KICAgaW5p dGlhbCBvZmZlcnMsIHRoZXJlIE1VU1QgYmUgYSBzZXQgb2YgY2FuZGlkYXRlIGF0dHJpYnV0ZXMg aW4gdGhlDQogICBvZmZlciBtYXRjaGluZyB0aGlzIGRlZmF1bHQgZGVzdGluYXRpb24uDQoNCjwv UkZDIDUyNDUgZXhjZXJwdD4NCg0KVG8gYWRkIGEgbmV3IElDRSBjYW5kaWRhdGUgaW4gSUNFIGNv bXBsZXRlZCBzdGF0ZSBJQ0UgUmVzdGFydHMgbXVzdCBiZSBkb25lLiBJQ0UgcmVzdGFydCBwcmVz ZXJ2ZXMgZXhpc3RpbmcgbWVkaWEgYW5kIHRyaWVzIHRvIGZpbmQgYmVzdCBuZXcgY2FuZGlkYXRl IHBhaXIuDQoNCjxSRkMgNTI0NSBleGNlcnB0Pg0KICAgOS4xLjEuMS4gIElDRSBSZXN0YXJ0cw0K DQogICBBbiBhZ2VudCBNQVkgcmVzdGFydCBJQ0UgcHJvY2Vzc2luZyBmb3IgYW4gZXhpc3Rpbmcg bWVkaWEgc3RyZWFtLiAgQW4NCiAgIElDRSByZXN0YXJ0LCBhcyB0aGUgbmFtZSBpbXBsaWVzLCB3 aWxsIGNhdXNlIGFsbCBwcmV2aW91cyBzdGF0ZXMgb2YNCiAgIElDRSBwcm9jZXNzaW5nIHRvIGJl IGZsdXNoZWQgYW5kIGNoZWNrcyB0byBzdGFydCBhbmV3LiAgVGhlIG9ubHkNCiAgIGRpZmZlcmVu Y2UgYmV0d2VlbiBhbiBJQ0UgcmVzdGFydCBhbmQgYSBicmFuZCBuZXcgbWVkaWEgc2Vzc2lvbiBp cw0KICAgdGhhdCwgZHVyaW5nIHRoZSByZXN0YXJ0LCBtZWRpYSBjYW4gY29udGludWUgdG8gYmUg c2VudCB0byB0aGUNCiAgIHByZXZpb3VzbHkgdmFsaWRhdGVkIHBhaXIuDQogICBBbiBhZ2VudCBN VVNUIHJlc3RhcnQgSUNFIGZvciBhIG1lZGlhIHN0cmVhbSBpZjoNCg0KICAgbyAgVGhlIG9mZmVy IGlzIGJlaW5nIGdlbmVyYXRlZCBmb3IgdGhlIHB1cnBvc2VzIG9mIGNoYW5naW5nIHRoZQ0KICAg ICAgdGFyZ2V0IG9mIHRoZSBtZWRpYSBzdHJlYW0uICBJbiBvdGhlciB3b3JkcywgaWYgYW4gYWdl bnQgd2FudHMgdG8NCiAgICAgIGdlbmVyYXRlIGFuIHVwZGF0ZWQgb2ZmZXIgdGhhdCwgaGFkIElD RSBub3QgYmVlbiBpbiB1c2UsIHdvdWxkDQogICAgICByZXN1bHQgaW4gYSBuZXcgdmFsdWUgZm9y IHRoZSBkZXN0aW5hdGlvbiBvZiBhIG1lZGlhIGNvbXBvbmVudA0KDQo8L1JGQyA1MjQ1IGV4Y2Vy cHQ+DQoNClNvLCBpZiBhIHVzZXIgbW92ZXMgdG8gYSBuZXcgYWNjZXNzIG5ldHdvcmsgKGUuZy4g TFRFIHRvIFdpRmkpIHRoZW4gYXNzdW1pbmcgSUNFIGlzIGFscmVhZHkgY29tcGxldGVkLCBJQ0Ug bXVzdCBiZSByZXN0YXJ0ZWQsIHRodXMgYSBuZXcgU0RQIE8vQSBtdXN0IGJlIGRvbmUuIFRoaXMg aXMgYWxzbyBvYnZpb3VzIGZyb20gdGhhdCBmYWN0IHRoYXQgbmV3IGxvY2FsIGNhbmRpZGF0ZXMg Zm9yIHRoZSBhY2Nlc3MgbmV0d29yayBtdXN0IGJlIGNvbnZleWVkIHRvIHRoZSBwZWVyIHNvIHRo YXQgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3Mgc3RhcnQgYW5kIHN1Y2NlZWQuDQoNCg0KQlINClJh anUNCg0K From nobody Tue Jun 3 09:37:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63CF1A02EF for ; Tue, 3 Jun 2014 09:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_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 MeI1ZBl0Gpfh for ; Tue, 3 Jun 2014 09:37:46 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B7B1A02C4 for ; Tue, 3 Jun 2014 09:37:45 -0700 (PDT) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C99081C104FA4; Tue, 3 Jun 2014 18:37:37 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: Date: Tue, 3 Jun 2014 18:37:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E086C36-8254-473F-887E-D60C7D841C36@lurchi.franken.de> References: To: Doug Leonard X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mQqnswLvAcMQ_wlm2pzr0o568Q4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-data-protocol-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:37:49 -0000 On 02 Jun 2014, at 18:22, Doug Leonard wrote: Hi Doug, thanks a lot for your review. See my comments inline. Best regards Michael >=20 > -----BEGIN PGP SIGNED MESSAGE-----=20 > Hash: SHA256=20 >=20 >=20 > A1. Section 4, 1st paragraph=20 >=20 > I think the full name of the protocol better establishes context. It > should be used as a section's first reference to the protocol. Then > subsequent references may be less explicit. (see A4)=20 >=20 > I would change "This protocol..." to "The Data Channel Establishment > Protocol..." Done. >=20 > A2. Section 4, first bullet=20 >=20 > Should be simplified to read: Reliable or unreliable message > transmission. In the case of unreliable transmissions, the same level > of unreliability is used. Done with using reliable instead of Reliable. >=20 >=20 > A3. Section 4, second bullet=20 >=20 > Should be simplified to read: In-order or out-of- order message > delivery. Done with using in-order instead of In-order. >=20 >=20 > A4. Section 4, third paragraph=20 >=20 > Change the subsequent reference of "The Data Channel Establishment > Protocol..." to "This protocol..." Done. >=20 > A5. Section 4, third paragraph=20 >=20 > "...uses a two way handshake to open a data channel by combining two > SCTP streams, one in each direction, with the same SCTP stream > identifier." >=20 > For more clarity change to: >=20 > "...uses a two way handshake to open a data channel. The handshake > pairs one incoming and one outgoing SCTP stream, each having an > identical stream identifier, into a single bidirectional channel." I would prefer: The handshake pairs one incoming and one outgoing SCTP stream, both = having the same SCTP stream identifier, into a single bidirectional channel. >=20 > A6. Section 4, third paragraph=20 >=20 > I think the sentence that begins "Please note" should be separated out > into a new paragraph and labeled as a note as follows: >=20 > Note: The opening side can only send user messages before the > DATA_CHANNEL_ACK is received. Why did you insert an "only"? If you want the note to be in a separate paragraph, I would move it to the end of the 4th paragraph. >=20 > A7. Section 4, fourth paragraph=20 >=20 > I think we should formally reference the title of Internet- Drafts > and then link to their location, rather than using the link as the > subject of sentences. I would change the sentence that begins "When > using [I-D.ietf-tsvwg-sctp-dtls-encaps], the method..." to the > following: >=20 > =93When using SCTP over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps], the = method=85=94 Done. Best regards Michael >=20 >=20 > --=20 > Doug Leonard > Developer | Jive Communications, Inc. > Jive.com | dleonard at getjive . com >=20 > -----BEGIN PGP SIGNATURE-----=20 > Version: OpenPGP.js v0.5.1=20 > Comment: http://openpgpjs.org=20 >=20 > wsBcBAEBCAAQBQJTjKTaCRA6BPqvovvpGQAAPwMH/2Tp1sx9diRh48WhVELN > 0uA0HxU4ITI5sUbbHdpwbGZm2EmEB/enbrW74yBXdaSAk4ouXh5Kz11akFU5 > r50X8shgLSeziIOxSuJNuA5re11vLcdnRZ3fMDGPKbTsFDvJgNT+kwO8buKS > 6CLpQxCDxoNOyUN4KZqS1QBeUlVP49+a/ms0Pg/97oiSPAvipMknVB7KUFg6 > lppN8HuqOxxAKTFrU05tuXucIW/937FL5iTcDv6cdNTW+xiKmUXOOgoTTQtN > y7PfB8Bc01TnLpy2xFDAmkeKTAZ5REIXax0v80ASy8W4JFIopzCtSyS+XniG > 6oyeTLz02IMv1R8lUyVbbaA=3D=20 > =3DnotY=20 > -----END PGP SIGNATURE-----=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 3 09:38:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B921C1A0309 for ; Tue, 3 Jun 2014 09:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZv_nL33hA0U for ; Tue, 3 Jun 2014 09:38:09 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED441A0313 for ; Tue, 3 Jun 2014 09:38:09 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id i13so5243379qae.7 for ; Tue, 03 Jun 2014 09:38:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=GTDMw845PY2VMhIENqQivWPDRYXat10Qj+gUrLvkGOg=; b=ChN3Xdixt/h1hetZKfjOSL/mxCIW1gbou+gWxg/0G/AhNdgvuyDE/1vWBQO+8CBCNB oB0WC8CM4J2r69nRTVfp6Hoajpz+gTHRJPFh4PHBT7CmeOw4eVMqWK102TnswDGjBD9O 2vSzb8QKw7KZFrgRnsU9d6wzInU20w955N70sFrf71QdEPcAWnz3P0GFDpA1UOAHR2eA W0C8TQZTGjg4wOFSigXrQV8Ml7dXLbu3wVTdmiBHimsKYiL570Wc77vKtA94Gc6RgPPe mn112Kgs1FidZRa1QaYwto4MEAf0MguVMsE7lVAhcTTb1NgtZ+eYZFKLdUXnC0hYlWOT hqcQ== X-Gm-Message-State: ALoCoQnb+9ojRNQfjP2wIDn2A1+EUPdPympkMalGgFysmfugQDI04rTJTF3oGuudbgutEjmzEfr8 X-Received: by 10.140.47.18 with SMTP id l18mr59277614qga.9.1401813483145; Tue, 03 Jun 2014 09:38:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 09:37:43 -0700 (PDT) In-Reply-To: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 18:37:43 +0200 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/26Vyam1F3J5xjTq8qH6JX48F280 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:38:10 -0000 2014-06-03 18:25 GMT+02:00 Makaraju, Maridi Raju (Raju) : > [Raju] Let's define "on-the-fly" as changing candidate pair after ICE is = "completed", i.e. a final candidate has been selected and nominated (via ST= UN USE-CANDIDATE-ATTRIBUTE). In such a case ICE RFC 5245 "9.1.2.2. Existing= Media Streams with ICE Completed" says: > > > 9.1.2.2. Existing Media Streams with ICE Completed > ... > The default destination for media (i.e., the values of the IP > addresses and ports in the m and c lines used for that media stream) > MUST be the local candidate from the highest-priority nominated pair > in the valid list for each component. This "fixes" the default > destination for media to equal the destination ICE has selected for > media. > The agent MUST include candidate attributes for candidates matching > the default destination for each component of the media stream, and > MUST NOT include any other candidates. > > > So, no new candidates can be added when in "completed" state (without ICE= restart). > > If ICE is in running state, then new candidates can be added. But for suc= h > new offers RFC says c/m=3D line must match with default candidate/destina= tion. > > > 9.1.2.1. Existing Media Streams with ICE Running > ... > The component ID MUST remain the same. The agent > MAY include additional candidates it did not offer previously, but > which it has gathered since the last offer/answer exchange, including > peer reflexive candidates. > The agent MAY change the default destination for media. As with > initial offers, there MUST be a set of candidate attributes in the > offer matching this default destination. > > > > To add a new ICE candidate in ICE completed state ICE Restarts must be do= ne. ICE restart preserves existing media and tries to find best new candida= te pair. > > > 9.1.1.1. ICE Restarts > > An agent MAY restart ICE processing for an existing media stream. An > ICE restart, as the name implies, will cause all previous states of > ICE processing to be flushed and checks to start anew. The only > difference between an ICE restart and a brand new media session is > that, during the restart, media can continue to be sent to the > previously validated pair. > An agent MUST restart ICE for a media stream if: > > o The offer is being generated for the purposes of changing the > target of the media stream. In other words, if an agent wants to > generate an updated offer that, had ICE not been in use, would > result in a new value for the destination of a media component > > > > So, if a user moves to a new access network (e.g. LTE to WiFi) then assum= ing ICE is already completed, ICE must be restarted, thus a new SDP O/A mus= t be done. All the above can be summarized as: "RFC 5245 mandates a new SDP O/A if the selected candidate-pair does not match the address in the c/m lines". Well, I already know that, it is written in the RFC. The point is that the above is useless and a requirement that should not be added by a network protocol that defines a STUN usage. > This is also obvious from that fact that new local candidates for the acc= ess network must be conveyed to the peer so that ICE connectivity checks st= art and succeed. Not so obvious. If the mobile is talking to a peer which has public IP (and peer is a full or lite ICE implementation) then a new SDP O/A is useless. At the end, and regardless what the initial SDP Offer said, the peer will discover the new reflexive candidates from the mobile "on-the-fly" (as the ICE protocol states). --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 10:16:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAAB1A02EF for ; Tue, 3 Jun 2014 10:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 Tk1WNk6-0BZ4 for ; Tue, 3 Jun 2014 10:16:17 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DED1A0249 for ; Tue, 3 Jun 2014 10:16:17 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s53HG9Ak014488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jun 2014 12:16:09 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s53HG8jm015976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 13:16:09 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 13:15:47 -0400 From: "Makaraju, Maridi Raju (Raju)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPfoYJ3SJNDgjOyUGKrVMmPtCWUptfFtqwgABNWYCAAAR9gIAABnuAgAAWfQCAAAYzgIAABYyAgAABWoCAAAMnAIAAAvqAgAAG4ID//8KX0IAAVpsA//++IOCAAE1wgP//welgAAp7tIAAB6+GkA== Date: Tue, 3 Jun 2014 17:15:47 +0000 Message-ID: References: <538CB0C7.6050700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34DE48@ESESSMB209.ericsson.se> <538D9A8B.4060002@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D34E2D2@ESESSMB209.ericsson.se> <538DBCB3.3030408@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D34E496@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: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/S4CuDpD0CWs2VAt1phb4gc-FclY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:16:18 -0000 DQo+IEFsbCB0aGUgYWJvdmUgY2FuIGJlIHN1bW1hcml6ZWQgYXM6ICJSRkMgNTI0NSBtYW5kYXRl cyBhIG5ldyBTRFAgTy9BDQo+IGlmIHRoZSBzZWxlY3RlZCBjYW5kaWRhdGUtcGFpciBkb2VzIG5v dCBtYXRjaCB0aGUgYWRkcmVzcyBpbiB0aGUgYy9tDQo+IGxpbmVzIi4NCj4gV2VsbCwgSSBhbHJl YWR5IGtub3cgdGhhdCwgaXQgaXMgd3JpdHRlbiBpbiB0aGUgUkZDLiBUaGUgcG9pbnQgaXMgdGhh dA0KPiB0aGUgYWJvdmUgaXMgdXNlbGVzcyBhbmQgYSByZXF1aXJlbWVudCB0aGF0IHNob3VsZCBu b3QgYmUgYWRkZWQgYnkgYQ0KPiBuZXR3b3JrIHByb3RvY29sIHRoYXQgZGVmaW5lcyBhIFNUVU4g dXNhZ2UuDQoNCltSYWp1XSBDb3JyZWN0LiBJIHRoaW5rIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdl LiBBcyB3ZSBkaXNjdXNzZWQgZWFybGllciwgd2hhdCBhcHBsaWVzIHRvIFdlYlJUQyBpcyBmb3Ig dGhlIGJyb3dzZXIgdG8gdXBkYXRlIHRoZSBTRFAgYW5kIG5vdGlmeSB0aGUgYXBwbGljYXRpb24g b2YgdGhlc2UgZXZlbnRzLiBUaGVuIGl0IGlzIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiB0byBoYW5k bGUgdGhlbSBhbnl3YXkgaXQgd2FudHMuIA0KDQo+ID4gVGhpcyBpcyBhbHNvIG9idmlvdXMgZnJv bSB0aGF0IGZhY3QgdGhhdCBuZXcgbG9jYWwgY2FuZGlkYXRlcyBmb3IgdGhlDQo+IGFjY2VzcyBu ZXR3b3JrIG11c3QgYmUgY29udmV5ZWQgdG8gdGhlIHBlZXIgc28gdGhhdCBJQ0UgY29ubmVjdGl2 aXR5IGNoZWNrcw0KPiBzdGFydCBhbmQgc3VjY2VlZC4NCj4gDQo+IE5vdCBzbyBvYnZpb3VzLiBJ ZiB0aGUgbW9iaWxlIGlzIHRhbGtpbmcgdG8gYSBwZWVyIHdoaWNoIGhhcyBwdWJsaWMgSVANCj4g KGFuZCBwZWVyIGlzIGEgZnVsbCBvciBsaXRlIElDRSBpbXBsZW1lbnRhdGlvbikgdGhlbiBhIG5l dyBTRFAgTy9BIGlzDQoNCltSYWp1XSBJbXBsZW1lbnRhdGlvbiBNVVNUIG5vdCBhc3N1bWUgcGVl ciBoYXZpbmcgYSBwdWJsaWMgSVAuDQoNCj4gdXNlbGVzcy4gQXQgdGhlIGVuZCwgYW5kIHJlZ2Fy ZGxlc3Mgd2hhdCB0aGUgaW5pdGlhbCBTRFAgT2ZmZXIgc2FpZCwNCj4gdGhlIHBlZXIgd2lsbCBk aXNjb3ZlciB0aGUgbmV3IHJlZmxleGl2ZSBjYW5kaWRhdGVzIGZyb20gdGhlIG1vYmlsZQ0KPiAi b24tdGhlLWZseSIgKGFzIHRoZSBJQ0UgcHJvdG9jb2wgc3RhdGVzKS4NCg0KW1JhanVdIEkgZG9u J3QgdGhpbmsgcGVlciBkaXNjb3ZlcmluZyBuZXcgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgY2FuIGhh cHBlbiBhZnRlciBJQ0UgaXMgY29tcGxldGVkLiBGaXJzdCwgd2l0aG91dCBJQ0UgcmVzdGFydCB0 aGUgbW9iaWxlIHdoaWNoIGRldGVjdGVkIGEgbmV3IGxvY2FsIGNhbmRpZGF0ZSAoV2lGaSkgY2Fu J3Qgc2VuZCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBvbiBpdCBpZiB0aGUgSUNFIHN0YXRlIGlz IGNvbXBsZXRlZCAodGhpcyBpcyB3cml0dGVuIGluIHRoZSBzYW1lIFJGQykuIFNvLCBldmVuIGlm IHRoZXJlIGlzIGEgTkFUIGluIGJldHdlZW4gYW5kIHBlZXIgbWF5IHRyZWF0IHRoaXMgbmV3IGNh bmRpZGF0ZSBhcyBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGUsIGxvY2FsIHNpZGUgY2FuJ3Qgc2Vu ZCBTVFVOLiBBbHNvLCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIG5vdCBhc3N1bWUgTkFUIGJlaW5n IHByZXNlbnQgbG9jYWxseS4NCg0KDQpCUg0KUmFqdQ0KDQo= From nobody Tue Jun 3 10:17:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FEE1A02EF for ; Tue, 3 Jun 2014 10:17:28 -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 p8QePaY09sph for ; Tue, 3 Jun 2014 10:17:27 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B828F1A0249 for ; Tue, 3 Jun 2014 10:17:26 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so7077682wiw.4 for ; Tue, 03 Jun 2014 10:17:20 -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=RNn6uDPJoj0WNZg8UVkZLmw2+nvNFTE1XL7JAhR0uZ4=; b=Z19itfTgiJvFeYLvk1q33c+TpCalx48fg3f3OaeNEybqeUhom7KDx9dnWZZqgWqXDJ 8lonUyNAT+yJKLsDt7dwU6uu+4BF3gNY/xCpVAU3XrkQxlVujYLhFAhpChQxN6hhz+mS d0sFrgvyWJdsDARaDsvDHzpcjQ04jnZT4izcUPN+CRXG/wn+pOThtuRpj1d2umLnzv99 gTx6Wc+YY8QJ6Snv+lNO0Z2h/X/ItP1i84X6uEtjyJsCt8R/f9zbYu+sFr4+5i3FFys+ CB2uOBKgBqN32TKoLfB2ECKkAnND1E494mbqMzrUQW+zgteG+gTWrv45tOxeo0+Rwhtq +zBQ== MIME-Version: 1.0 X-Received: by 10.194.249.228 with SMTP id yx4mr50654505wjc.53.1401815840006; Tue, 03 Jun 2014 10:17:20 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Tue, 3 Jun 2014 10:17:19 -0700 (PDT) In-Reply-To: References: <20140519083842.21555.8626.idtracker@ietfa.amsl.com> <538DB70E.6020300@alvestrand.no> Date: Tue, 3 Jun 2014 10:17:19 -0700 Message-ID: From: Martin Thomson To: "Ram Mohan R (rmohanr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rCH92kxGBssm9hOPPkFvoywj4oA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:17:28 -0000 On 3 June 2014 05:12, Ram Mohan R (rmohanr) wrote: > I agree having the text on consent > freshness for BUNDLE would make the scope of this draft larger and perhaps > slow the progress of this document. The concern is not that there is consent freshness for BUNDLE, it's that there is DiffServ marking for BUNDLE. BUNDLE should determine that (or maybe some other document). Whatever this document does should - at most - say that the marking is the same for consent refresh as it is for initial connectivity checking. From nobody Tue Jun 3 10:27:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9030B1A0313 for ; Tue, 3 Jun 2014 10:27:24 -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_111=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 LYaVpmLHcMbN for ; Tue, 3 Jun 2014 10:27:22 -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 13D281A025E for ; Tue, 3 Jun 2014 10:27:20 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-58-538e0571a920 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F0.AB.25910.1750E835; Tue, 3 Jun 2014 19:27:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 19:27:13 +0200 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Justin Uberti" , Lorenzo Miniero Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPf0O2jirzOXhJL0iHVgJMhHnIiJtfb26AgAAzbTA= Date: Tue, 3 Jun 2014 17:27:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34EF1C@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D34EF1CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+JvjW4Ra1+wwcq1TBZbpwpZbN+ygMmi YeMVVou1/9rZHVg8Wp/tZfVYsKnUY8mSn0weHQ/vswewRHHZpKTmZJalFunbJXBlHG0NL+j7 wVjx69B5lgbGMx8Zuxg5OSQETCQW7jzABmGLSVy4tx7I5uIQEjjKKHH36F92CGcRo8ShCU+B Ojg42AQsJLr/aYPERQSmMkq8X7AYbBKzgLrEncXn2EFsYYEwiXOd75lBbBGBcInjP7qZIGwr ie9bDoLVswioSDw/tgyshlfAV2LCybtQyxYzSpxrOsMKkuAUiJV4+vox2HmMQOd9P7WGCWKZ uMStJ/OZIM4WkFiy5zwzhC0q8fLxP1YIW0micckTVoj6fIlbk34wQSwTlDg58wnLBEbRWUhG zUJSNgtJ2Sygn5kFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0IyO91KLM 5OLi/Dy9vNSSTYzAuDy45bfBDsaXzx0PMQpwMCrx8D743BMsxJpYVlyZe4hRmoNFSZz3okZ1 sJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGo3cbzj9ifKT+/s3h1bVRU6Q9c4L7bTTOF5be Mln4/nLkmfv360zuLL2x1G/+U/cT6itfx1zeLsTBWqZ8wuq8t/ujihi2piLx0968IucNWRyr BdY/i3+eb+TOnPdS0GS3zndWg3wOi7XTFy29bMPx6e7ObQpvTghqXJmoqOS4wlu/83JIX9h0 JZbijERDLeai4kQAVvhwZKwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jLPRHh-rKByfTXSHa5sgdyOvRDw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:27:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D34EF1CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIOKAnFVEUC9UTFMvUlRQL1NBVlBG4oCdDQoNCkp1c3QgZm9yIGNsYXJpZmljYXRpb24s IHdoYXQgaXMgbWVhbnQgYnkg4oCcYmFja3dhcmQgY29tcGF0aWJpbGl0eeKAnT8gVXNhZ2Ugb2Yg bm9uLXNlY3VyZSBSVFA/IEkgdGhvdWdodCB3ZSBhcmUgbm90IGdvaW5nIHRvIGFsbG93IHRoYXQu DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJh anUpDQpTZW50OiAwMyBKdW5lIDIwMTQgMTk6MjENClRvOiBKdXN0aW4gVWJlcnRpOyBMb3Jlbnpv IE1pbmllcm8NCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBSZXRy eTogRFRMUyBjYXJyeWluZyBSVFAvU0FWUEYgb3ZlciBJQ0U6IFRvIFVEUCBvciBub3QgdG8gVURQ Pw0KDQorMSBmb3Ig4oCcVURQL1RMUy9SVFAvU0FWUEYgb24gdGhlIG09IGxpbmXigJ0NCg0KUGxl YXNlIGRvbuKAmXQgdHJlYXQgdGhpcyBsaWtlIGFub3RoZXIgaGlqYWNraW5nIGF0dGVtcHQg4pi6 IGJ1dCwgdW5mb3J0dW5hdGVseSB0aGUgcmF0aW9uYWxlIGZvciB0aGlzIGlzIHNvbWV3aGF0IHJl bGF0ZWQgdG8gdGhlIElDRSBkaXNjdXNzaW9uLg0KUkZDIDIzMjcgY2xlYXJseSBzYXlzIHRyYW5z cG9ydCBmb3IgUlRQL0FWUCBpcyBVRFAuIFJUUC9TQVZQRiBSRkMgNTEyNCBtb3N0bHkgaW5oZXJp dHMgdGhhdCAoYW5kIFJUUC9BVlBGIFJGQyA0NTg1KSBhbmQgaW5kaWNhdGVzIHRyYW5zcG9ydCBh cyB1c3VhbGx5IFVEUCAoYWx0ZXJuYXRpdmUgYmVpbmcgRENDUCkuDQpTbywgdXNpbmcgUlRQL1NB VlBGIGZvciBEVExTLVNSVFAgZG9lcyBub3Qgc2VlbSBjb25zaXN0ZW50IHdpdGggdGhlc2UgUkZD cy4gTW9yZSBpbXBvcnRhbnRseSBEVExTLVNSVFAgdXNlIG9mIOKAnFVEUC9UTFMvUlRQL1NBVlBG IOKAnCBpcyBjbGVhcmx5IGRlZmluZWQgaW4gUkZDIDU3NjQuDQoNCk5vdyB0aGUgY2FzZSBvZiwg 4oCcY2hhbmdpbmcgZnJvbSBkZWZhdWx0IFVEUCB0byBmaW5hbCBUQ1AgdHJhbnNwb3J0IG9yIHZp Y2UtdmVyc2HigJ0gZm9yIFNSVFAgaGFzIHRvIGJlIGhhbmRsZWQgcGVyIElDRSBSRkMgcnVsZXMs IHdoaWNoIHNheXMgYy9tPSBsaW5lcyBzaG91bGQgYmUgY29uc2lzdGVudCB3aXRoIHRoZSBkZWZh dWx0IGRlc3RpbmF0aW9uLiBTbywgdXNpbmcg4oCcUlRQL1NBVlBG4oCdIHRvIGNvdmVyIGFsbCB0 cmFuc3BvcnRzIGRvZXMgbm90IHNvdW5kIHJpZ2h0IHRvIG1lLCBlc3BlY2lhbGx5IHdoZW4gYnJv d3NlciBoYXMgdG8gdXBkYXRlIHRoZSBTRFAgd2hlbiBmaW5hbCBzZWxlY3RlZCBjYW5kaWRhdGUg YW5kL29yIHRyYW5zcG9ydCBjaGFuZ2VzIGFueXdheS4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNTI0NSNzZWN0aW9uLTguMS4yDQoNCiAgICAgICAgICAgICAgICAgICAgSWYgYW4g YWdlbnQgaXMgY29udHJvbGxpbmcsIGl0IGV4YW1pbmVzIHRoZSBoaWdoZXN0LXByaW9yaXR5DQog ICAgICAgICBub21pbmF0ZWQgY2FuZGlkYXRlIHBhaXIgZm9yIGVhY2ggY29tcG9uZW50IG9mIGVh Y2ggbWVkaWENCiAgICAgICAgIHN0cmVhbS4gIElmIGFueSBvZiB0aG9zZSBjYW5kaWRhdGUgcGFp cnMgZGlmZmVyIGZyb20gdGhlDQogICAgICAgICBkZWZhdWx0IGNhbmRpZGF0ZSBwYWlycyBpbiB0 aGUgbW9zdCByZWNlbnQgb2ZmZXIvYW5zd2VyDQogICAgICAgICBleGNoYW5nZSwgdGhlIGNvbnRy b2xsaW5nIGFnZW50IE1VU1QgZ2VuZXJhdGUgYW4gdXBkYXRlZCBvZmZlcg0KICAgICAgICAgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb24gOTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1 I3NlY3Rpb24tOT4uDQoNCkJSDQpSYWp1DQoNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBUdWVz ZGF5LCBKdW5lIDAzLCAyMDE0IDEwOjUxIEFNDQpUbzogTG9yZW56byBNaW5pZXJvDQpDYzogcnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbcnRjd2ViXSBS ZXRyeTogRFRMUyBjYXJyeWluZyBSVFAvU0FWUEYgb3ZlciBJQ0U6IFRvIFVEUCBvciBub3QgdG8g VURQPw0KDQpUaGUgb3RoZXIgdGhyZWFkIGhhcyBiZWVuIGhpamFja2VkIGJ5IGFuIElDRSBkaXNj dXNzaW9uLCBzbyByZWFza2luZyBoZXJlLiBTaG91bGQgdXNlIG9mIERUTFMgYmUgaW5kaWNhdGVk IGJ5Og0KLSBVRFAvVExTL1JUUC9TQVZQRiBvbiB0aGUgbT0gbGluZQ0KLSBSVFAvU0FWUEYsIGFu ZCBwcmVzZW5jZSBvZiBhbiBhPWZpbmdlcnByaW50IGxpbmUNCg0KU29tZSBoYXZlIGV4cHJlc3Nl ZCBhIHByZWZlcmVuY2UgZm9yIFJUUC9TQVZQRiwgYXMgYmVpbmcgbW9yZSBiYWNrd2FyZHMgY29t cGF0aWJsZS4gSG93ZXZlciwgb3RoZXJzIGhhdmUgZXhwcmVzc2VkIGEgcHJlZmVyZW5jZSBmb3Ig VURQL1RMUy9SVFAvU0FWUEYsIGFzIHRoYXQgaXMgd2hhdCBSRkMgNTc2My80IHNheXMuIFRoZSBs YXN0IHRpbWUgdGhpcyBjYW1lIHVwLCBpbiBTZXB0ZW1iZXIgMjAxMywgdGhlIFVEUC9UTFMvUlRQ L1NBVlBGIHByb3BvbmVudHMgd2VyZSBhYmxlIHRvIGNvbnZpbmNlIG1lIHRvIGluY2x1ZGUgdGhp cyBpbnRvIGpzZXAtMDYsIHNvIGlmIHdlIHdhbnQgdG8gY2hhbmdlIGl0IGJhY2ssIEknZCBsaWtl IHRvIHNlZSBhIGNsZWFyIGNvbnNlbnN1cy4NCk9uIFR1ZSwgSnVuIDMsIDIwMTQgYXQgMjowOCBB TSwgTG9yZW56byBNaW5pZXJvIDxsb3JlbnpvQG1lZXRlY2hvLmNvbTxtYWlsdG86bG9yZW56b0Bt ZWV0ZWNoby5jb20+PiB3cm90ZToNCk9uIFR1ZSwgMDMgSnVuIDIwMTQgMTA6MzI6NDMgKzAyMDAN ClNlcmdpbyBHYXJjaWEgTXVyaWxsbyA8c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNvbTxt YWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQo+IE9uIHRo ZSBvdGhlciBzaWRlLCBrZWVwaW5nICJSVFAvU0FWRlAiIHdvdWxkIGhhdmUgYWxsb3dlZCBhIHNl cnZlcg0KPiAoU0JDL01DVS9ldGMpIHRvIHNlbmQgYW4gb2ZmZXIgd2l0aG91dCBrbm93aW5nIGlu IGFkdmFuY2UgaWYgdGhlDQo+IG90aGVyIHNpZGUgc3VwcG9ydHMgU0RFUyBvciBEVExTLCBieSBz ZW5kaW5nIGJvdGggdGhlIGNyeXB0byBhbmQNCj4gZmluZ2VycHJpbnQgYXR0cmlidXRlcyBhbmQg bGV0IHRoZSByZWNlaXZlciBjaG9vc2Ugd2hpY2ggb25lIHRvIHVzZQ0KPiAoYXMgY2hyb21lIGhh cyBkb25lIHVudGlsIHJlY2VudGx5KS4gSSBrbm93IHRoYXQgaXQgaXMgbm90IGltcG9ydGFudA0K PiBmb3Igd2VicnRjLCBhcyBEVExTIGlzIG1hbmRhdG9yeSBhbmQgU0RFUyBpcyBhIG11c3Qgbm90 LCBidXQgZm9yDQo+IHN1cHBvcnRpbmcgb3RoZXIgbGVnYWN5IGNsaWVudHMgaXQgbWF5IGJlIGVh c2llciBmb3Igc29tZSBvZiB1cy4NCj4NCj4gQmVzdCByZWdhcmRzDQo+IFNlcmdpbw0KPg0KSSBn dWVzcyB0aGF0IHdhcyB0aGUgcmF0aW9uYWxlIGZvciBoYXZpbmcgUlRQL1NBVlBGIGluIHRoZSBm aXJzdA0KcGxhY2UsIGFzIGluaXRpYWxseSBib3RoIFNERVMgYW5kIERUTFMtU1JUUCB3ZXJlIGFs bG93ZWQuIFRoZXJlIGFyZQ0KcGVvcGxlIGNvbmZ1c2VkIGFib3V0IG5vdCBoYXZpbmcgVURQL1RM Uy9SVFAvU0FWUEYgbm93IHRoYXQgRFRMUy1TUlRQDQppcyBtYW5kYXRvcnkgKEFzdGVyaXNrIGRl dmVsb3BlcnMsIGZvciBpbnN0YW5jZSwgYWx0aG91Z2ggZ2V0dGluZyBpdCB0bw0Kd29yayBmcm9t IGEgc2lnbmFsbGluZyBwb2ludCBvZiB2aWV3IGlzIGEgdHJpdmlhbCByZXBsYWNlIG1hdHRlciBp bg0KSmF2YVNjcmlwdCksIGJ1dCBJIGFncmVlIGl0IG1ha2VzIHNlbnNlIHRvIGtlZXAgUlRQL1NB VlBGLCBpZiBub3QganVzdA0KYmVjYXVzZSBhbGwgYnJvd3NlciBpbXBsZW1lbnRhdGlvbnMgcmln aHQgbm93ICh0aGUgbGVnYWN5IG9mIGEgZmV3DQptb250aHMgZnJvbSBub3cgb24pIG9ubHkgYWNj ZXB0IHRoYXQsIHdoaWNoIHdvdWxkIHJlbmRlciB0aGVtIHVzZWxlc3MNCmhhdmluZyB0aGlzIGNo YW5nZS4NCg0KTG9yZW56bw0KDQoNCg0KPiBFbCAwMy8wNi8yMDE0IDg6MDQsIEp1c3RpbiBVYmVy dGkgZXNjcmliacOzOg0KPiA+IEkgdGhpbmsgdGhlcmUgaXMgdmFsdWUgaW4gc3BlY2lmeWluZyBV RFAvVExTL1JUUC9TQVZQRiwgaW4gdGhhdCBpdA0KPiA+IHVuYW1iaWd1b3VzbHkgaW5kaWNhdGVz IHRoZSBkZXNpcmUgdG8gZG8gRFRMUy1TUlRQLiBPdGhlcndpc2UsIG9uZQ0KPiA+IGhhcyB0byBn dWVzcyBhdCB0aGlzIGZyb20gdGhlIHByZXNlbmNlIG9mIGE9ZmluZ2VycHJpbnQsIHdoaWNoDQo+ ID4gc2VlbXMgZG9kZ3ksIGdpdmVuIHRoYXQgZW5kcG9pbnRzIGFyZSBmcmVlIHRvIGlnbm9yZSBT RFAgYXR0cmlidXRlcw0KPiA+IHRoZXkgZG9uJ3QgdW5kZXJzdGFuZC4NCj4gPg0KPiA+IFRoZSBm YWN0IHRoYXQgVURQIGFuZCBUTFMgYXBwZWFyIGluIHRoZSBtPSBsaW5lIGlzIGtpbmQgb2YNCj4g PiB1bmZvcnR1bmF0ZSwgYnV0IEkgdGhpbmsgaXQgY2FuIGJlIGludGVycHJldGVkIGFzICJkbyBE VExTLVNSVFAiLg0KPiA+DQo+ID4NCj4gPiBPbiBNb24sIEp1biAyLCAyMDE0IGF0IDExOjUzIEFN LCBNYXJ0aW4gVGhvbXNvbg0KPiA+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbT4gPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208 bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+PiB3cm90ZToNCj4gPg0KPiA+ICAgICBP biAyIEp1bmUgMjAxNCAxMDoxMywgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5k Lm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4NCj4gPiAgICAgPG1haWx0bzpoYXJhbGRA YWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+Pj4gd3JvdGU6DQo+ID4g ICAgID4gVGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGJvdGggc2VuZCAiUlRQL1NBVlBGIiBp biB0aGlzDQo+ID4gICAgID4gZmllbGQuDQo+ID4gICAgIEJ1dCB0aGlzDQo+ID4gICAgID4gdXNh Z2UgaXMgbm90IHNwZWNpZmllZCBieSBSRkMgNTc2NC4NCj4gPg0KPiA+ICAgICBTb3VuZHMgZWFz eSB0byBtZS4gIFRoZSBTRFAgZG9lc24ndCBtYXR0ZXIgYW5kIGNhbiBzYXkgYW55dGhpbmcuDQo+ ID4gICAgICJSVFAvU0FWUEYiIGlzIGFzIGdvb2QgYXMgYW55IG90aGVyIHNlcXVlbmNlIG9mIG9j dGV0cy4NCj4gPg0KPiA+ICAgICBJJ20gc3VyZSB0aGF0IEpTRVAgY2FuIGluY2x1ZGUgYSByZXF1 aXJlbWVudCB0aGF0IGlzIGRpcmVjdGx5DQo+ID4gICAgIGNvbnRyYWRpY3RvcnkgdG8gYW4gZXhp c3RpbmcgUkZDLiAgVGhhdCBoYXBwZW5zIGFsbCB0aGUgdGltZS4NCj4gPiBBdCBsZWFzdCB0aGlz IHRpbWUgaXQgY2FuIGJlIGV4cGxpY2l0Lg0KPiA+DQo+ID4gICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgIHJ0Y3dlYiBtYWlsaW5nIGxp c3QNCj4gPiAgICAgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+IDxtYWls dG86cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KPiA+ICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWINCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D34EF1CESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZ3JleQ0KCXttc28t c3R5bGUtbmFtZTpncmV5O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxIGZvciDigJxVRFAvVExTL1JUUC9T QVZQRuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KdXN0IGZvciBjbGFy aWZpY2F0aW9uLCB3aGF0IGlzIG1lYW50IGJ5IOKAnGJhY2t3YXJkIGNvbXBhdGliaWxpdHnigJ0/ IFVzYWdlIG9mIG5vbi1zZWN1cmUgUlRQPyBJIHRob3VnaHQgd2UgYXJlIG5vdCBnb2luZyB0byBh bGxvdyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0 Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5NYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpPGJyPg0KPGI+U2VudDo8L2I+IDAzIEp1bmUg MjAxNCAxOToyMTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFViZXJ0aTsgTG9yZW56byBNaW5pZXJv PGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtydGN3ZWJdIFJldHJ5OiBEVExTIGNhcnJ5aW5nIFJUUC9TQVZQRiBvdmVyIElDRTogVG8gVURQ IG9yIG5vdCB0byBVRFA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mIzQzOzEgZm9yIOKAnFVEUC9UTFMvUlRQL1NBVlBGIG9uIHRoZSBtPSBsaW5l4oCdPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBkb27igJl0IHRyZWF0IHRo aXMgbGlrZSBhbm90aGVyIGhpamFja2luZyBhdHRlbXB0DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjoj MUY0OTdEIj5KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+IGJ1dCwgdW5mb3J0dW5hdGVseSB0aGUgcmF0aW9uYWxlIGZvciB0aGlz IGlzIHNvbWV3aGF0IHJlbGF0ZWQgdG8gdGhlDQogSUNFIGRpc2N1c3Npb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SRkMgMjMyNyBjbGVhcmx5IHNheXMgdHJh bnNwb3J0IGZvciBSVFAvQVZQIGlzIFVEUC4gUlRQL1NBVlBGIFJGQyA1MTI0IG1vc3RseSBpbmhl cml0cyB0aGF0IChhbmQgUlRQL0FWUEYgUkZDIDQ1ODUpIGFuZCBpbmRpY2F0ZXMgdHJhbnNwb3J0 IGFzDQogdXN1YWxseSBVRFAgKGFsdGVybmF0aXZlIGJlaW5nIERDQ1ApLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIHVzaW5nIFJUUC9TQVZQRiBmb3IgRFRM Uy1TUlRQIGRvZXMgbm90IHNlZW0gY29uc2lzdGVudCB3aXRoIHRoZXNlIFJGQ3MuIE1vcmUgaW1w b3J0YW50bHkgRFRMUy1TUlRQIHVzZSBvZiDigJxVRFAvVExTL1JUUC9TQVZQRiDigJwgaXMgY2xl YXJseSBkZWZpbmVkDQogaW4gUkZDIDU3NjQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk5vdyB0aGUgY2FzZSBvZiwg4oCcY2hhbmdpbmcgZnJvbSBkZWZhdWx0IFVEUCB0byBm aW5hbCBUQ1AgdHJhbnNwb3J0IG9yIHZpY2UtdmVyc2HigJ0gZm9yIFNSVFAgaGFzIHRvIGJlIGhh bmRsZWQgcGVyIElDRSBSRkMgcnVsZXMsIHdoaWNoIHNheXMgYy9tPQ0KIGxpbmVzIHNob3VsZCBi ZSBjb25zaXN0ZW50IHdpdGggdGhlIGRlZmF1bHQgZGVzdGluYXRpb24uIFNvLCB1c2luZyDigJxS VFAvU0FWUEbigJ0gdG8gY292ZXIgYWxsIHRyYW5zcG9ydHMgZG9lcyBub3Qgc291bmQgcmlnaHQg dG8gbWUsIGVzcGVjaWFsbHkgd2hlbiBicm93c2VyIGhhcyB0byB1cGRhdGUgdGhlIFNEUCB3aGVu IGZpbmFsIHNlbGVjdGVkIGNhbmRpZGF0ZSBhbmQvb3IgdHJhbnNwb3J0IGNoYW5nZXMgYW55d2F5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tOC4xLjIiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi04LjEuMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklmIGFuIGFnZW50 IGlzIGNvbnRyb2xsaW5nLCBpdCBleGFtaW5lcyB0aGUgaGlnaGVzdC1wcmlvcml0eTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vbWluYXRlZCBjYW5kaWRhdGUgcGFpciBmb3IgZWFj aCBjb21wb25lbnQgb2YgZWFjaCBtZWRpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz dHJlYW0uJm5ic3A7IElmIGFueSBvZiB0aG9zZSBjYW5kaWRhdGUgcGFpcnMgZGlmZmVyIGZyb20g dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmF1bHQgY2FuZGlkYXRlIHBhaXJz IGluIHRoZSBtb3N0IHJlY2VudCBvZmZlci9hbnN3ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZXhjaGFuZ2UsIHRoZSBjb250cm9sbGluZyBhZ2VudCBNVVNUIGdlbmVyYXRlIGFuIHVw ZGF0ZWQgb2ZmZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXMgZGVzY3JpYmVkIGlu DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tOSI+ U2VjdGlvbiA5PC9hPi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgWzxhIGhyZWY9Im1haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKdW5lIDAzLCAyMDE0IDEwOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBMb3JlbnpvIE1pbmll cm88YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dl YkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gUmV0cnk6IERUTFMg Y2FycnlpbmcgUlRQL1NBVlBGIG92ZXIgSUNFOiBUbyBVRFAgb3Igbm90IHRvIFVEUD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIG90aGVyIHRocmVhZCBoYXMg YmVlbiBoaWphY2tlZCBieSBhbiBJQ0UgZGlzY3Vzc2lvbiwgc28gcmVhc2tpbmcgaGVyZS4gU2hv dWxkIHVzZSBvZiBEVExTIGJlIGluZGljYXRlZCBieTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gVURQL1RMUy9S VFAvU0FWUEYgb24gdGhlIG09IGxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gUlRQL1NBVlBGLCBhbmQgcHJl c2VuY2Ugb2YgYW4gYT1maW5nZXJwcmludCBsaW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KU29tZSBoYXZlIGV4cHJlc3NlZCBh IHByZWZlcmVuY2UgZm9yIFJUUC9TQVZQRiwgYXMgYmVpbmcgbW9yZSBiYWNrd2FyZHMgY29tcGF0 aWJsZS4gSG93ZXZlciwgb3RoZXJzIGhhdmUgZXhwcmVzc2VkIGEgcHJlZmVyZW5jZSBmb3IgVURQ L1RMUy9SVFAvU0FWUEYsIGFzIHRoYXQgaXMgd2hhdCBSRkMgNTc2My80IHNheXMuIFRoZSBsYXN0 IHRpbWUgdGhpcyBjYW1lIHVwLCBpbiBTZXB0ZW1iZXIgMjAxMywgdGhlJm5ic3A7VURQL1RMUy9S VFAvU0FWUEYgcHJvcG9uZW50cw0KIHdlcmUgYWJsZSB0byBjb252aW5jZSBtZSB0byBpbmNsdWRl IHRoaXMgaW50byBqc2VwLTA2LCBzbyBpZiB3ZSB3YW50IHRvIGNoYW5nZSBpdCBiYWNrLCBJJ2Qg bGlrZSB0byBzZWUgYSBjbGVhciBjb25zZW5zdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIEp1biAz LCAyMDE0IGF0IDI6MDggQU0sIExvcmVuem8gTWluaWVybyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxv cmVuem9AbWVldGVjaG8uY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9yZW56b0BtZWV0ZWNoby5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ T24gVHVlLCAwMyBKdW4gMjAxNCAxMDozMjo0MyAmIzQzOzAyMDA8YnI+DQpTZXJnaW8gR2FyY2lh IE11cmlsbG8gJmx0OzxhIGhyZWY9Im1haWx0bzpzZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwu Y29tIj5zZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KJmd0OyBPbiB0aGUgb3RoZXIgc2lkZSwga2VlcGluZyAmcXVvdDtSVFAvU0FWRlAmcXVv dDsgd291bGQgaGF2ZSBhbGxvd2VkIGEgc2VydmVyPGJyPg0KJmd0OyAoU0JDL01DVS9ldGMpIHRv IHNlbmQgYW4gb2ZmZXIgd2l0aG91dCBrbm93aW5nIGluIGFkdmFuY2UgaWYgdGhlPGJyPg0KJmd0 OyBvdGhlciBzaWRlIHN1cHBvcnRzIFNERVMgb3IgRFRMUywgYnkgc2VuZGluZyBib3RoIHRoZSBj cnlwdG8gYW5kPGJyPg0KJmd0OyBmaW5nZXJwcmludCBhdHRyaWJ1dGVzIGFuZCBsZXQgdGhlIHJl Y2VpdmVyIGNob29zZSB3aGljaCBvbmUgdG8gdXNlPGJyPg0KJmd0OyAoYXMgY2hyb21lIGhhcyBk b25lIHVudGlsIHJlY2VudGx5KS4gSSBrbm93IHRoYXQgaXQgaXMgbm90IGltcG9ydGFudDxicj4N CiZndDsgZm9yIHdlYnJ0YywgYXMgRFRMUyBpcyBtYW5kYXRvcnkgYW5kIFNERVMgaXMgYSBtdXN0 IG5vdCwgYnV0IGZvcjxicj4NCiZndDsgc3VwcG9ydGluZyBvdGhlciBsZWdhY3kgY2xpZW50cyBp dCBtYXkgYmUgZWFzaWVyIGZvciBzb21lIG9mIHVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3Qg cmVnYXJkczxicj4NCiZndDsgU2VyZ2lvPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZ3Vlc3Mg dGhhdCB3YXMgdGhlIHJhdGlvbmFsZSBmb3IgaGF2aW5nIFJUUC9TQVZQRiBpbiB0aGUgZmlyc3Q8 YnI+DQpwbGFjZSwgYXMgaW5pdGlhbGx5IGJvdGggU0RFUyBhbmQgRFRMUy1TUlRQIHdlcmUgYWxs b3dlZC4gVGhlcmUgYXJlPGJyPg0KcGVvcGxlIGNvbmZ1c2VkIGFib3V0IG5vdCBoYXZpbmcgVURQ L1RMUy9SVFAvU0FWUEYgbm93IHRoYXQgRFRMUy1TUlRQPGJyPg0KaXMgbWFuZGF0b3J5IChBc3Rl cmlzayBkZXZlbG9wZXJzLCBmb3IgaW5zdGFuY2UsIGFsdGhvdWdoIGdldHRpbmcgaXQgdG88YnI+ DQp3b3JrIGZyb20gYSBzaWduYWxsaW5nIHBvaW50IG9mIHZpZXcgaXMgYSB0cml2aWFsIHJlcGxh Y2UgbWF0dGVyIGluPGJyPg0KSmF2YVNjcmlwdCksIGJ1dCBJIGFncmVlIGl0IG1ha2VzIHNlbnNl IHRvIGtlZXAgUlRQL1NBVlBGLCBpZiBub3QganVzdDxicj4NCmJlY2F1c2UgYWxsIGJyb3dzZXIg aW1wbGVtZW50YXRpb25zIHJpZ2h0IG5vdyAodGhlIGxlZ2FjeSBvZiBhIGZldzxicj4NCm1vbnRo cyBmcm9tIG5vdyBvbikgb25seSBhY2NlcHQgdGhhdCwgd2hpY2ggd291bGQgcmVuZGVyIHRoZW0g dXNlbGVzczxicj4NCmhhdmluZyB0aGlzIGNoYW5nZS48YnI+DQo8YnI+DQpMb3JlbnpvPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IEVsIDAzLzA2LzIwMTQgODowNCwgSnVzdGlu IFViZXJ0aSBlc2NyaWJpw7M6PGJyPg0KJmd0OyAmZ3Q7IEkgdGhpbmsgdGhlcmUgaXMgdmFsdWUg aW4gc3BlY2lmeWluZyBVRFAvVExTL1JUUC9TQVZQRiwgaW4gdGhhdCBpdDxicj4NCiZndDsgJmd0 OyB1bmFtYmlndW91c2x5IGluZGljYXRlcyB0aGUgZGVzaXJlIHRvIGRvIERUTFMtU1JUUC4gT3Ro ZXJ3aXNlLCBvbmU8YnI+DQomZ3Q7ICZndDsgaGFzIHRvIGd1ZXNzIGF0IHRoaXMgZnJvbSB0aGUg cHJlc2VuY2Ugb2YgYT1maW5nZXJwcmludCwgd2hpY2g8YnI+DQomZ3Q7ICZndDsgc2VlbXMgZG9k Z3ksIGdpdmVuIHRoYXQgZW5kcG9pbnRzIGFyZSBmcmVlIHRvIGlnbm9yZSBTRFAgYXR0cmlidXRl czxicj4NCiZndDsgJmd0OyB0aGV5IGRvbid0IHVuZGVyc3RhbmQuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IFRoZSBmYWN0IHRoYXQgVURQIGFuZCBUTFMgYXBwZWFyIGluIHRoZSBtPSBs aW5lIGlzIGtpbmQgb2Y8YnI+DQomZ3Q7ICZndDsgdW5mb3J0dW5hdGUsIGJ1dCBJIHRoaW5rIGl0 IGNhbiBiZSBpbnRlcnByZXRlZCBhcyAmcXVvdDtkbyBEVExTLVNSVFAmcXVvdDsuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIE1vbiwgSnVuIDIsIDIwMTQg YXQgMTE6NTMgQU0sIE1hcnRpbiBUaG9tc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRo b21zb25AZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBPbiAyIEp1bmUg MjAxNCAxMDoxMywgSGFyYWxkIEFsdmVzdHJhbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRA YWx2ZXN0cmFuZC5ubyI+aGFyYWxkQGFsdmVzdHJhbmQubm88L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmhh cmFsZEBhbHZlc3RyYW5kLm5vIj5oYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoZSBjdXJyZW50IGltcGxlbWVu dGF0aW9ucyBib3RoIHNlbmQgJnF1b3Q7UlRQL1NBVlBGJnF1b3Q7IGluIHRoaXM8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGZpZWxkLjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7IEJ1dCB0aGlzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJmd0OyB1c2FnZSBpcyBu b3Qgc3BlY2lmaWVkIGJ5IFJGQyA1NzY0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7IFNvdW5kcyBlYXN5IHRvIG1lLiAmbmJzcDtUaGUgU0RQIGRvZXNuJ3QgbWF0 dGVyIGFuZCBjYW4gc2F5IGFueXRoaW5nLjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZx dW90O1JUUC9TQVZQRiZxdW90OyBpcyBhcyBnb29kIGFzIGFueSBvdGhlciBzZXF1ZW5jZSBvZiBv Y3RldHMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgSSdtIHN1 cmUgdGhhdCBKU0VQIGNhbiBpbmNsdWRlIGEgcmVxdWlyZW1lbnQgdGhhdCBpcyBkaXJlY3RseTxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IGNvbnRyYWRpY3RvcnkgdG8gYW4gZXhpc3Rpbmcg UkZDLiAmbmJzcDtUaGF0IGhhcHBlbnMgYWxsIHRoZSB0aW1lLjxicj4NCiZndDsgJmd0OyBBdCBs ZWFzdCB0aGlzIHRpbWUgaXQgY2FuIGJlIGV4cGxpY2l0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgcnRjd2ViIG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0 bzpydGN3ZWJAaWV0Zi5vcmciPg0KcnRjd2ViQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgJmd0OyBydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYjwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D34EF1CESESSMB209erics_-- From nobody Tue Jun 3 10:27:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075921A025E for ; Tue, 3 Jun 2014 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhfhUnT9h6uN for ; Tue, 3 Jun 2014 10:27:23 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369441A023D for ; Tue, 3 Jun 2014 10:27:23 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so7117643wes.2 for ; Tue, 03 Jun 2014 10:27:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=N04ejz5DKGT4uOM3Jp3pA0IHxYn56nyY8u1T7V2QM78=; b=BT01pPmDGw+lUEfTYV9DcLpv+81NcHMkEMFE+mf+q803bsjWEl7rHha/REwf3trNnu lhKjLSyN2+Lm3hifvvpGAsR79zoS1fdltqJXynDR4RAexSuyzunL2iGIUzqVO532of/S EpfP7k3zY0nY7rsv1AecevXf8p1d+EnZpB88zqX2ZeYsl3+xprLBwKWHAeU1xl4UYFr7 FiO1dbUOhNKhLM9ycFRqDfknxOaxn4028JE0LBRqJtNDoEVuQa+PHswtNehYOb0ghY1R m3qMCHE5uL41bqEjLh9Pfk7Gx8TnkrrZIvIvEVmeOyEKC9P4MGPiodvIQ4g0SqM7XSgC /uqA== X-Gm-Message-State: ALoCoQlTmF61Jtwg7NufTfL+MnZeW+Tu2NPHcTlsivYPnafKPJ9zvE/3nPmcCUeEE1oOq/oVIKnd X-Received: by 10.180.76.210 with SMTP id m18mr23083112wiw.49.1401816436239; Tue, 03 Jun 2014 10:27:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Tue, 3 Jun 2014 10:26:36 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:c9c3:7b0c:3608:1e0f] In-Reply-To: References: From: Eric Rescorla Date: Tue, 3 Jun 2014 10:26:36 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d043c7b10b909ef04faf1d20d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/B5LAk9Hrkbu8G4nDcfsJtKZc3Gw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:27:25 -0000 --f46d043c7b10b909ef04faf1d20d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't feel strongly about this either way. The original motivation for th= e text in 5764 is that people in MMUSIC (not me particularlly) felt we should be clear on the profile and that DTLS was a different profile. If that sentiment has changed I would be happy to use RTP/SAVPF (which is what FFOX uses now, I believe). -Ekr On Tue, Jun 3, 2014 at 8:51 AM, Justin Uberti wrote: > The other thread has been hijacked by an ICE discussion, so reasking here= . > Should use of DTLS be indicated by: > - UDP/TLS/RTP/SAVPF on the m=3D line > - RTP/SAVPF, and presence of an a=3Dfingerprint line > > Some have expressed a preference for RTP/SAVPF, as being more backwards > compatible. However, others have expressed a preference for > UDP/TLS/RTP/SAVPF, as that is what RFC 5763/4 says. The last time this ca= me > up, in September 2013, the UDP/TLS/RTP/SAVPF proponents were able to > convince me to include this into jsep-06, so if we want to change it back= , > I'd like to see a clear consensus. > > On Tue, Jun 3, 2014 at 2:08 AM, Lorenzo Miniero > wrote: > >> On Tue, 03 Jun 2014 10:32:43 +0200 >> Sergio Garcia Murillo wrote: >> >> > On the other side, keeping "RTP/SAVFP" would have allowed a server >> > (SBC/MCU/etc) to send an offer without knowing in advance if the >> > other side supports SDES or DTLS, by sending both the crypto and >> > fingerprint attributes and let the receiver choose which one to use >> > (as chrome has done until recently). I know that it is not important >> > for webrtc, as DTLS is mandatory and SDES is a must not, but for >> > supporting other legacy clients it may be easier for some of us. >> > >> > Best regards >> > Sergio >> > >> >> >> I guess that was the rationale for having RTP/SAVPF in the first >> place, as initially both SDES and DTLS-SRTP were allowed. There are >> people confused about not having UDP/TLS/RTP/SAVPF now that DTLS-SRTP >> is mandatory (Asterisk developers, for instance, although getting it to >> work from a signalling point of view is a trivial replace matter in >> JavaScript), but I agree it makes sense to keep RTP/SAVPF, if not just >> because all browser implementations right now (the legacy of a few >> months from now on) only accept that, which would render them useless >> having this change. >> >> Lorenzo >> >> >> >> > El 03/06/2014 8:04, Justin Uberti escribi=C3=B3: >> > > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it >> > > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one >> > > has to guess at this from the presence of a=3Dfingerprint, which >> > > seems dodgy, given that endpoints are free to ignore SDP attributes >> > > they don't understand. >> > > >> > > The fact that UDP and TLS appear in the m=3D line is kind of >> > > unfortunate, but I think it can be interpreted as "do DTLS-SRTP". >> > > >> > > >> > > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson >> > > > wrote: >> > > >> > > On 2 June 2014 10:13, Harald Alvestrand > > > > wrote: >> > > > The current implementations both send "RTP/SAVPF" in this >> > > > field. >> > > But this >> > > > usage is not specified by RFC 5764. >> > > >> > > Sounds easy to me. The SDP doesn't matter and can say anything. >> > > "RTP/SAVPF" is as good as any other sequence of octets. >> > > >> > > I'm sure that JSEP can include a requirement that is directly >> > > contradictory to an existing RFC. That happens all the time. >> > > At least this time it can be explicit. >> > > >> > > _______________________________________________ >> > > rtcweb mailing list >> > > rtcweb@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtcweb >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > rtcweb mailing list >> > > rtcweb@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043c7b10b909ef04faf1d20d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't feel strongly about this either way. The origi= nal motivation for the
text in 5764 is that people in MMUSIC (not me pa= rticularlly) felt we
should be clear on the profile and that DTLS= was a different profile. If
that sentiment has changed I would be happy to use RTP/SAVPF
(which is what FFOX uses now, I believe).

-Ekr



On Tue, Jun 3, 2014 at 8:51 AM, Justin Uberti <juberti@google.com> wrote:
The other thread has been hijacked by an ICE discussion, s= o reasking here. Should use of DTLS be indicated by:
- UDP/TLS/RTP/SAVP= F on the m=3D line
- RTP/SAVPF, and presence of an a=3Dfingerprint = line

Some have expressed a preference f= or RTP/SAVPF, as being more backwards compatible. However, others have expr= essed a preference for UDP/TLS/RTP/SAVPF, as that is what RFC 5763/4 says. = The last time this came up, in September 2013, the=C2=A0UDP/TLS/RTP/SAVPF p= roponents were able to convince me to include this into jsep-06, so if we w= ant to change it back, I'd like to see a clear consensus.

On Tue, Jun 3, 2014 at 2:08 AM, Lorenzo Mini= ero <lorenzo@meetecho.com> wrote:
On Tue, 03 Jun 2014 10:32:43 +0200
Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

> On the other side, keeping "RTP/SAVFP" would have allowed a = server
> (SBC/MCU/etc) to send an offer without knowing in advance if the
> other side supports SDES or DTLS, by sending both the crypto and
> fingerprint attributes and let the receiver choose which one to use > (as chrome has done until recently). I know that it is not important > for webrtc, as DTLS is mandatory and SDES is a must not, but for
> supporting other legacy clients it may be easier for some of us.
>
> Best regards
> Sergio
>


I guess that was the rationale for having RTP/SAVPF in the first
place, as initially both SDES and DTLS-SRTP were allowed. There are
people confused about not having UDP/TLS/RTP/SAVPF now that DTLS-SRTP
is mandatory (Asterisk developers, for instance, although getting it to
work from a signalling point of view is a trivial replace matter in
JavaScript), but I agree it makes sense to keep RTP/SAVPF, if not just
because all browser implementations right now (the legacy of a few
months from now on) only accept that, which would render them useless
having this change.

Lorenzo



> El 03/06/2014 8:04, Justin Uberti escribi=C3=B3:
> > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that i= t
> > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, on= e
> > has to guess at this from the presence of a=3Dfingerprint, which<= br> > > seems dodgy, given that endpoints are free to ignore SDP attribut= es
> > they don't understand.
> >
> > The fact that UDP and TLS appear in the m=3D line is kind of
> > unfortunate, but I think it can be interpreted as "do DTLS-S= RTP".
> >
> >
> > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson
> > <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>= wrote:
> >
> > =C2=A0 =C2=A0 On 2 June 2014 10:13, Harald Alvestrand <harald@alvestrand.no=
> > =C2=A0 =C2=A0 <mailto:harald@alvestrand.no>> wrote:
> > =C2=A0 =C2=A0 > The current implementations both send "RT= P/SAVPF" in this
> > =C2=A0 =C2=A0 > field.
> > =C2=A0 =C2=A0 But this
> > =C2=A0 =C2=A0 > usage is not specified by RFC 5764.
> >
> > =C2=A0 =C2=A0 Sounds easy to me. =C2=A0The SDP doesn't matter= and can say anything.
> > =C2=A0 =C2=A0 "RTP/SAVPF" is as good as any other seque= nce of octets.
> >
> > =C2=A0 =C2=A0 I'm sure that JSEP can include a requirement th= at is directly
> > =C2=A0 =C2=A0 contradictory to an existing RFC. =C2=A0That happen= s all the time.
> > At least this time it can be explicit.
> >
> > =C2=A0 =C2=A0 _______________________________________________
> > =C2=A0 =C2=A0 rtcweb mailing list
> > =C2=A0 =C2=A0 rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> > =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtc= web
> >
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.= org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>

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


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


--f46d043c7b10b909ef04faf1d20d-- From nobody Tue Jun 3 10:32:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146EF1A023A for ; Tue, 3 Jun 2014 10:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMzBtksFb2d7 for ; Tue, 3 Jun 2014 10:32:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131531A023D for ; Tue, 3 Jun 2014 10:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1487; q=dns/txt; s=iport; t=1401816717; x=1403026317; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nRpSIf+4vkKrjDsX+mbdhWOUohEXEvSXqE9yP842gT8=; b=Rsg4RwD3l9wLfXfYPRJFXEdOWfE/1u8n4eNKr+j9c/e7zDofFjvFUiqc 7dhfkUUQg6sc/1sRBXapyw6KgRuV1f6JizxVZXDb9/n11Bh4CJDat9e8r pnhT970ISAKIghQSRJ2N/0Lf2tizYUIr/oA08OrOjkHtDSGw10G/cAyRR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4LADgFjlOtJA2H/2dsb2JhbABZgwdSWKo4AwEBAQUBkGOGaFEBgQ0WdIIlAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCIg6DdMcEwSFVYhMMQcGgyWBFQStPYM4gi8 X-IronPort-AV: E=Sophos;i="4.98,967,1392163200"; d="scan'208";a="330180032" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jun 2014 17:31:57 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s53HVufM029747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 17:31:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.220]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 12:31:56 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson , "Ram Mohan R (rmohanr)" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt Thread-Index: AQHPf0+1VEWqOGSG3E+223qYTVdTgZtfokPQ Date: Tue, 3 Jun 2014 17:31:56 +0000 Message-ID: References: <20140519083842.21555.8626.idtracker@ietfa.amsl.com> <538DB70E.6020300@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bsT55r-eOoBNvOFpN512FcRTxus Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:32:05 -0000 |-----Original Message----- |From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson |Sent: Tuesday, June 03, 2014 10:47 PM |To: Ram Mohan R (rmohanr) |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness= -03.txt | |On 3 June 2014 05:12, Ram Mohan R (rmohanr) wrote: |> I agree having the text on consent |> freshness for BUNDLE would make the scope of this draft larger and perha= ps |> slow the progress of this document. | | |The concern is not that there is consent freshness for BUNDLE, it's |that there is DiffServ marking for BUNDLE. BUNDLE should determine |that (or maybe some other document). Whatever this document does |should - at most - say that the marking is the same for consent |refresh as it is for initial connectivity checking. That is close to what the draft currently says: It is RECOMMENDED that STUN consent checks use the same Diffserv Codepoint markings as the media packets sent on that transport address. This follows the recommendation of ICE connectivity check described in section 7.1.2.4 of [RFC5245]. Of course, we can replace media packets with ICE connectivity check, if nee= ded. In addition, we can add a node that the BUNDLE case is out of scope of= this document. Muthu | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 3 10:32:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D31A023D for ; Tue, 3 Jun 2014 10:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etX9S9X_nIax for ; Tue, 3 Jun 2014 10:32:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553A31A023A for ; Tue, 3 Jun 2014 10:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1298; q=dns/txt; s=iport; t=1401816749; x=1403026349; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rZuQ5bbnf4Y0Cnuq3ZiytjE+pYsE5iTf4Lou6jTWyD8=; b=inoaL0EtuVAi13PaAEPNlkuyVU2Najxeu6MOJItAjPWpQwlo1xUH/igq QQu4u72Z1L7BB5QBn7nI2DdL0nU90ZtkyAhxu4iqnhzpb759bjU9CJbc6 6B5cQd5o5pYhrfcV7l7i5RWACcDfbh3rbblwiv0dqGeH84H3EznCTF3bq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAOsFjlOtJV2P/2dsb2JhbABZgweBKsJgAYENFnSCJQEBAQQ6SwQCAQgRAwECAR4QIREdCAIEARKILgMRzR8NhX4XjDyCHQaEOgEDmBGBeY0+hXWDOIIv X-IronPort-AV: E=Sophos;i="4.98,967,1392163200"; d="scan'208";a="329983031" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jun 2014 17:32:28 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s53HWSw8015727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 17:32:28 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.106]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 12:32:28 -0500 From: "Ram Mohan R (rmohanr)" To: Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt Thread-Index: AQHPf1HJoT5bJEhrx02EK/lO8B72yA== Date: Tue, 3 Jun 2014 17:32:27 +0000 Message-ID: References: <20140519083842.21555.8626.idtracker@ietfa.amsl.com> <538DB70E.6020300@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.32.162] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cGkPEEsnFe-SeY9mqWlFEvldUxs Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:32:35 -0000 -----Original Message----- From: Martin Thomson Date: Tuesday, 3 June 2014 10:47 pm To: Ram Mohan Ravindranath Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt >On 3 June 2014 05:12, Ram Mohan R (rmohanr) wrote: >> I agree having the text on consent >> freshness for BUNDLE would make the scope of this draft larger and >>perhaps >> slow the progress of this document. > > >The concern is not that there is consent freshness for BUNDLE, it's >that there is DiffServ marking for BUNDLE. BUNDLE should determine >that (or maybe some other document). Whatever this document does >should - at most - say that the marking is the same for consent >refresh as it is for initial connectivity checking. Agree. Instead of saying pick up highest DSCP value or lowest DSCP value from the media stream(s) in the BUNDLE for STUN consent messages, we could just say the DiffServ marking for STUN consent messages is same that is for initial ICE checks. I believe DiffServ marking for initial ICE checks when BUNDLE is used is itself a open item and not defined in any draft yet. Ram =20 > From nobody Tue Jun 3 11:29:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314841A0269 for ; Tue, 3 Jun 2014 11:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 8Gd9RBzRkRbD for ; Tue, 3 Jun 2014 11:29:42 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg224.aruba.it [62.149.158.224]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6E1A0219 for ; Tue, 3 Jun 2014 11:29:41 -0700 (PDT) Received: from rainpc ([79.46.63.127]) by smtpcmd02.ad.aruba.it with bizsmtp id 9uVY1o00U2kjZ4F01uVY5e; Tue, 03 Jun 2014 20:29:34 +0200 Date: Tue, 3 Jun 2014 20:29:32 +0200 From: Lorenzo Miniero To: Christer Holmberg Message-ID: <20140603202932.39a18fc0@rainpc> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34EF1C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34EF1C@ESESSMB209.ericsson.se> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eocPqmgGo7RujdCjydD68_I8xBk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:29:45 -0000 On Tue, 3 Jun 2014 17:27:12 +0000 Christer Holmberg wrote: > +1 for =E2=80=9CUDP/TLS/RTP/SAVPF=E2=80=9D >=20 > Just for clarification, what is meant by =E2=80=9Cbackward compatibility= =E2=80=9D? Usage of non-secure RTP? I thought we are not going to allow tha= t. >=20 When I mentioned "legacy", I talked about WebRTC implementations out in the= wild today, and most importantly browsers. Current up-to-date implementati= ons of Firefox and Chrome, which both use DTLS-SRTP, don't understand UDP/T= LS/RTP/SAVPF and so would fail when faced with that in a negotiation. This = might sound like a minor point, considering the autoupdate in most browsers= that could have them aligned when the time comes, but you'd be surprised a= bout how many older versions are still around that force applications to ha= ve to deal with all of them with polyfills and the like. This is especially= true if we consider the beta vs. stable versions both Chrome and Firefox a= re making available. Anyway, I agree this should not be a motivation for sticking to RTP/SAVPF. = After all, the spec is not stable yet and more things are going to change a= nyway. Besides, most existing deployments still rely on SDES being availabl= e in Chrome, and so they'll be forced to update sooner or later when it dis= appears for good. Lorenzo > Regards, >=20 > Christer >=20 >=20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Makaraju, Mari= di Raju (Raju) > Sent: 03 June 2014 19:21 > To: Justin Uberti; Lorenzo Miniero > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or = not to UDP? >=20 > +1 for =E2=80=9CUDP/TLS/RTP/SAVPF on the m=3D line=E2=80=9D >=20 > Please don=E2=80=99t treat this like another hijacking attempt =E2=98=BA = but, unfortunately the rationale for this is somewhat related to the ICE di= scussion. > RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC 5124 mo= stly inherits that (and RTP/AVPF RFC 4585) and indicates transport as usual= ly UDP (alternative being DCCP). > So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with these RFC= s. More importantly DTLS-SRTP use of =E2=80=9CUDP/TLS/RTP/SAVPF =E2=80=9C i= s clearly defined in RFC 5764. >=20 > Now the case of, =E2=80=9Cchanging from default UDP to final TCP transpor= t or vice-versa=E2=80=9D for SRTP has to be handled per ICE RFC rules, whic= h says c/m=3D lines should be consistent with the default destination. So, = using =E2=80=9CRTP/SAVPF=E2=80=9D to cover all transports does not sound ri= ght to me, especially when browser has to update the SDP when final selecte= d candidate and/or transport changes anyway. >=20 > http://tools.ietf.org/html/rfc5245#section-8.1.2 >=20 > If an agent is controlling, it examines the highest-p= riority > nominated candidate pair for each component of each media > stream. If any of those candidate pairs differ from the > default candidate pairs in the most recent offer/answer > exchange, the controlling agent MUST generate an updated offer > as described in Section 9. >=20 > BR > Raju >=20 >=20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti > Sent: Tuesday, June 03, 2014 10:51 AM > To: Lorenzo Miniero > Cc: rtcweb@ietf.org > Subject: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not = to UDP? >=20 > The other thread has been hijacked by an ICE discussion, so reasking here= . Should use of DTLS be indicated by: > - UDP/TLS/RTP/SAVPF on the m=3D line > - RTP/SAVPF, and presence of an a=3Dfingerprint line >=20 > Some have expressed a preference for RTP/SAVPF, as being more backwards c= ompatible. However, others have expressed a preference for UDP/TLS/RTP/SAVP= F, as that is what RFC 5763/4 says. The last time this came up, in Septembe= r 2013, the UDP/TLS/RTP/SAVPF proponents were able to convince me to includ= e this into jsep-06, so if we want to change it back, I'd like to see a cle= ar consensus. > On Tue, Jun 3, 2014 at 2:08 AM, Lorenzo Miniero > wrote: > On Tue, 03 Jun 2014 10:32:43 +0200 > Sergio Garcia Murillo > wrote: >=20 > > On the other side, keeping "RTP/SAVFP" would have allowed a server > > (SBC/MCU/etc) to send an offer without knowing in advance if the > > other side supports SDES or DTLS, by sending both the crypto and > > fingerprint attributes and let the receiver choose which one to use > > (as chrome has done until recently). I know that it is not important > > for webrtc, as DTLS is mandatory and SDES is a must not, but for > > supporting other legacy clients it may be easier for some of us. > > > > Best regards > > Sergio > > > I guess that was the rationale for having RTP/SAVPF in the first > place, as initially both SDES and DTLS-SRTP were allowed. There are > people confused about not having UDP/TLS/RTP/SAVPF now that DTLS-SRTP > is mandatory (Asterisk developers, for instance, although getting it to > work from a signalling point of view is a trivial replace matter in > JavaScript), but I agree it makes sense to keep RTP/SAVPF, if not just > because all browser implementations right now (the legacy of a few > months from now on) only accept that, which would render them useless > having this change. >=20 > Lorenzo >=20 >=20 >=20 > > El 03/06/2014 8:04, Justin Uberti escribi=C3=B3: > > > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it > > > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one > > > has to guess at this from the presence of a=3Dfingerprint, which > > > seems dodgy, given that endpoints are free to ignore SDP attributes > > > they don't understand. > > > > > > The fact that UDP and TLS appear in the m=3D line is kind of > > > unfortunate, but I think it can be interpreted as "do DTLS-SRTP". > > > > > > > > > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson > > > >> wrote: > > > > > > On 2 June 2014 10:13, Harald Alvestrand > > > >> wrote: > > > > The current implementations both send "RTP/SAVPF" in this > > > > field. > > > But this > > > > usage is not specified by RFC 5764. > > > > > > Sounds easy to me. The SDP doesn't matter and can say anything. > > > "RTP/SAVPF" is as good as any other sequence of octets. > > > > > > I'm sure that JSEP can include a requirement that is directly > > > contradictory to an existing RFC. That happens all the time. > > > At least this time it can be explicit. > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > > > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From nobody Tue Jun 3 11:42:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6781A0262 for ; Tue, 3 Jun 2014 11:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 ipdR2Rx3tlLj for ; Tue, 3 Jun 2014 11:42:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AB51A0260 for ; Tue, 3 Jun 2014 11:42:12 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s53Ig21F002677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jun 2014 13:42:03 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s53Ig0tj032713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 14:42:02 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 14:42:01 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Lorenzo Miniero , Christer Holmberg Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPf0PY6zllukqgI0+lS1j0hPoDEJtfiwmQgABbmQCAABFqAP//vbWA Date: Tue, 3 Jun 2014 18:42:00 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D34EF1C@ESESSMB209.ericsson.se> <20140603202932.39a18fc0@rainpc> In-Reply-To: <20140603202932.39a18fc0@rainpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ltcpfeGOttG4DTFt9LhYfnq46Mw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:42:15 -0000 PiBXaGVuIEkgbWVudGlvbmVkICJsZWdhY3kiLCBJIHRhbGtlZCBhYm91dCBXZWJSVEMgaW1wbGVt ZW50YXRpb25zIG91dCBpbiB0aGUNCj4gd2lsZCB0b2RheSwgYW5kIG1vc3QgaW1wb3J0YW50bHkg YnJvd3NlcnMuIEN1cnJlbnQgdXAtdG8tZGF0ZQ0KPiBpbXBsZW1lbnRhdGlvbnMgb2YgRmlyZWZv eCBhbmQgQ2hyb21lLCB3aGljaCBib3RoIHVzZSBEVExTLVNSVFAsIGRvbid0DQo+IHVuZGVyc3Rh bmQgVURQL1RMUy9SVFAvU0FWUEYgYW5kIHNvIHdvdWxkIGZhaWwgd2hlbiBmYWNlZCB3aXRoIHRo YXQgaW4gYQ0KPiBuZWdvdGlhdGlvbi4NCg0KW1JhanVdIA0KQ2FuJ3QgdGhpcyBiZSBoYW5kbGVk IGJ5IGJyb3dzZXJzIHZpYSBoYW5kbGluZyBSVFAvU0FWUEYgaW4gc2V0UmVtb3RlRGVzY3JpcHRp b24gKCksIGluIGFkZGl0aW9uIHRvIFVEUC9UTFMvUlRQL1NBVlBGLCBmb3Igc29tZSBtb3JlIHRp bWUgYW5kIHBoYXNlIGl0IG91dCBzbG93bHk/IA0KDQpBbHNvLCBjcmVhdGVBbnN3ZXIoKSB3aWxs IGdpdmUgYmFjayB3aGF0IGlzIGluIHRoZSBvZmZlci4NCmNyZWF0ZU9mZmVyKCkgd2lsbCB1c2Ug VURQL1RMUy9SVFAvU0FWUEYuDQoNCnNldExvY2FsRGVzY3JpcHRpb24gKCkgbWF5IG5vdCBoYXZl IHRvIGhhbmRsZSBSVFAvU0FWUEYgZm9yIERUTFMgYXMgYXBwbGljYXRpb25zIHR5cGljYWxseSBk b24ndCBtZXNzIHdpdGggdHJhbnNwb3J0Lg0KDQpCUg0KUmFqdQ0K From nobody Tue Jun 3 12:22:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071F71A032D for ; Tue, 3 Jun 2014 12:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 gjFxsbjuY1ML for ; Tue, 3 Jun 2014 12:22:42 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F98D1A0320 for ; Tue, 3 Jun 2014 12:22:42 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so14069060qgd.27 for ; Tue, 03 Jun 2014 12:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=2xE1HboHYY0dy/kU8AEkUL1Kn8VrFqj0oHVJAVwr7k0=; b=IeO5oaXaet3YDuGxXHqcN7mWr0zYMovL+XO0SwSP2uQwf/rFkysg/r0AAQn0ZwQxBP eb++cE+aAMamjH3liwGbNcrk0OZm140H/0PAnGUAIkHYC6udExJVaM65chVYOutl2SaE sQ9iwkDFYt00qejgil9fDic5itEE7ZwWAWv1DdgQ2v7aAfWyyYUQXj8Zh1lKBu9AHAtk 22tQirMvhbvGvTYimmApnSRmicZjD9KcphTP0JvLZ+ta13KWhBVsP4nPvE0J+6uet1AD ca6HXfJVHlRqshFr5MdHpzZ+Pp9n3nJMXKV1olZ1THynB1Ig8wH4Xsu7EK5K6ny/xMFl gYHg== X-Gm-Message-State: ALoCoQnsyAx5fAj+aCbYfhIsnTbzWoefQKVagMp0p6e4gNwkQM/jYdMer9ZeI4Nm7Y9rM5ZHYq2o X-Received: by 10.224.40.131 with SMTP id k3mr63066352qae.5.1401823355882; Tue, 03 Jun 2014 12:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Tue, 3 Jun 2014 12:22:15 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Jun 2014 21:22:15 +0200 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JVegbI9G-1JbrKzL2RXH1GeY36E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:22:43 -0000 2014-06-03 18:20 GMT+02:00 Makaraju, Maridi Raju (Raju) : > +1 for =E2=80=9CUDP/TLS/RTP/SAVPF on the m=3D line=E2=80=9D > > Please don=E2=80=99t treat this like another hijacking attempt J but, unf= ortunately > the rationale for this is somewhat related to the ICE discussion. > > RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC 5124 > mostly inherits that (and RTP/AVPF RFC 4585) and indicates transport as > usually UDP (alternative being DCCP). > > So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with these RFC= s. > More importantly DTLS-SRTP use of =E2=80=9CUDP/TLS/RTP/SAVPF =E2=80=9C is= clearly defined in > RFC 5764. > > Now the case of, =E2=80=9Cchanging from default UDP to final TCP transpor= t or > vice-versa=E2=80=9D for SRTP has to be handled per ICE RFC rules, which s= ays c/m=3D > lines should be consistent with the default destination. So, using > =E2=80=9CRTP/SAVPF=E2=80=9D to cover all transports does not sound right = to me, especially > when browser has to update the SDP when final selected candidate and/or > transport changes anyway. I don't like the above, but I strongly agree with it. So: - Initially use "UDP/TLS/RTP/SAVPF" as the RFC states. - If the selected candidate (after ICE procedures) has a different transport, then fire an event to tell the user about it. Something like: onicestatechange(event) where: - event.readyState=3D"open" - event.selectedTransport =3D "TCP/TLS/RTP/SAVPF" And in case the user calls getLocalDescription() it should retrieve a SDP with m/c lines matching the transport and address of the selected local candidate. (well, I know there is zero interest on implementing that, but the spec should say something like this in order to make SDP&ICE RFC's happy). Regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 3 20:29:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1621A01DC for ; Tue, 3 Jun 2014 20:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuSc0BxbPrHL for ; Tue, 3 Jun 2014 20:29:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736CC1A01CA for ; Tue, 3 Jun 2014 20:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3027; q=dns/txt; s=iport; t=1401852535; x=1403062135; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=V3ZcIbruiWkZii7WE2xZLV2PJujHtAD7h5lVfS+XdLg=; b=BSrZ+SooJ2YPNF+m9SQO5DLKHrNw/BHs1y0ULGiJWZJAXHgLl7gxKt1g 5jBozDOXtlXNYSHc8RXjVwqm9LScTox+s1Fcwn6cQVq+vXxdA6ukWHfNM KreABYpdP+NsK4P7MIVEv3bLjRYEycyhSa6SxE8AnUmKFGkUXrCNxJQg2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFACeRjlOtJV2S/2dsb2JhbABZgwdSWLs9hhtNUQGBChZ0giUBAQEDAQEBAWsLBQcGAQgRBAEBCx0uCxQJCQEEAQ0FCIgyCA3SKBeCYItBMQ2DJYEVBIlvkVmRdYM4gi8 X-IronPort-AV: E=Sophos;i="4.98,970,1392163200"; d="scan'208";a="330350614" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jun 2014 03:28:54 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s543Ssi2003257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 03:28:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 22:28:53 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Makaraju, Maridi Raju (Raju)" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: Ac9/pRpNC+BdMcQKQfKK3xPSxWQwpA== Date: Wed, 4 Jun 2014 03:28:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C7B0F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.73.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6jTG1Vq5IYw2r2fRcuPpB_5UGRg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 03:29:02 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Makaraju, Mari= di > Raju (Raju) > Sent: Tuesday, June 03, 2014 10:46 PM > To: I=F1aki Baz Castillo > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to = UDP? >=20 >=20 > > All the above can be summarized as: "RFC 5245 mandates a new SDP O/A > > if the selected candidate-pair does not match the address in the c/m > > lines". > > Well, I already know that, it is written in the RFC. The point is that > > the above is useless and a requirement that should not be added by a > > network protocol that defines a STUN usage. >=20 > [Raju] Correct. I think we are on the same page. As we discussed earlier,= what > applies to WebRTC is for the browser to update the SDP and notify the > application of these events. Then it is up to the application to handle t= hem > anyway it wants. >=20 > > > This is also obvious from that fact that new local candidates for > > > the > > access network must be conveyed to the peer so that ICE connectivity > > checks start and succeed. > > > > Not so obvious. If the mobile is talking to a peer which has public IP > > (and peer is a full or lite ICE implementation) then a new SDP O/A is >=20 > [Raju] Implementation MUST not assume peer having a public IP. >=20 > > useless. At the end, and regardless what the initial SDP Offer said, > > the peer will discover the new reflexive candidates from the mobile > > "on-the-fly" (as the ICE protocol states). >=20 > [Raju] I don't think peer discovering new reflexive candidates can happen= after > ICE is completed. First, without ICE restart the mobile which detected a = new > local candidate (WiFi) can't send ICE connectivity checks on it if the IC= E state is > completed (this is written in the same RFC).=20 If both endpoints support MICE (tools.ietf.org/html/draft-wing-mmusic-ice-m= obility-06) then after mobility event, endpoint which detected local IP add= ress change can trigger ICE connectivity checks without depending on ICE re= start. If the remote peer does not support MICE but the endpoint needs mobi= lity then it can get that using relayed candidates (TURN client and server = will have to support "Mobility using TURN"). With MICE, If endpoint has mul= tiple interfaces then it can maintain unused candidates from interfaces wit= h lower-priority in standby mode, so that when the active interface is not = available then media streams can be migrated to any one of these interfaces= without depending on ICE restart. =20 -Tiru > So, even if there is a NAT in between > and peer may treat this new candidate as peer reflexive candidate, local = side > can't send STUN. Also, implementations should not assume NAT being presen= t > locally. >=20 >=20 > BR > Raju >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jun 4 00:33:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABF91A00AD for ; Wed, 4 Jun 2014 00:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6XPyhH9K_Zh for ; Wed, 4 Jun 2014 00:33:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF89E1A00B0 for ; Wed, 4 Jun 2014 00:33:27 -0700 (PDT) X-AuditID: c1b4fb2d-f79776d000001085-7b-538ecbc03113 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.58.04229.0CBCE835; Wed, 4 Jun 2014 09:33:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 09:33:20 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPf2EzJJwwfinVzkSeFUWi1HOIo5tgeAnA Date: Wed, 4 Jun 2014 07:33:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvje6B033BBv/eaVtM32dj0bDxCqvF 2n/t7A7MHq3P9rJ6nGt4z+6xZMlPpgDmKC6blNSczLLUIn27BK6Mn89PMxacEqp4//oYewNj j1AXIyeHhICJxP/+20wQtpjEhXvr2boYuTiEBI4yShw4+xcowQHkLGKUuMECYrIJWEh0/9MG KRERaGSUaDzwDqyXWUBd4s7ic+wgtrBAmERzx2NGEFtEIFxi0fTJzBC2kcTpza0sIDaLgIrE rUl/wWp4BXwldrw5BWYLCbxilPjd7wNicwoESty7OxOslxHotu+n1kDtEpe49WQ+1M0CEkv2 nGeGsEUlXj7+xwphK0n82HAJ7GZmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjGKzkEydhdAx C0nHLCQdCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtLBLb91dzCufu14iFGAg1GJ h1eBty9YiDWxrLgy9xCjNAeLkjjvJY3qYCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MXZka Haaz3v/Reh2+rSj8UpRjjWupbRVT9gP/hSVbDt4Qv6N5rO5motTujK6zgaxyid3TtlswLuK9 LMfpd2HJz+qAXacPnlmpffXg+4a0yT99cn/rFxcdm5rvF9duUr/l9wHNCwH+KzRqljOx+Vlz XvlYtf/1hcP9y7gfPG1affbeyr0Oq1nfKbEUZyQaajEXFScCAMqzZEaGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ai7mfcpQ1Fi5e1y5uEDrtpouLco Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 07:33:29 -0000 SGksDQoNCj4+ICsxIGZvciDigJxVRFAvVExTL1JUUC9TQVZQRiBvbiB0aGUgbT0gbGluZeKAnQ0K Pj4NCj4+IFBsZWFzZSBkb27igJl0IHRyZWF0IHRoaXMgbGlrZSBhbm90aGVyIGhpamFja2luZyBh dHRlbXB0IEogYnV0LCANCj4+IHVuZm9ydHVuYXRlbHkgdGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBp cyBzb21ld2hhdCByZWxhdGVkIHRvIHRoZSBJQ0UgZGlzY3Vzc2lvbi4NCj4+DQo+PiBSRkMgMjMy NyBjbGVhcmx5IHNheXMgdHJhbnNwb3J0IGZvciBSVFAvQVZQIGlzIFVEUC4gUlRQL1NBVlBGIFJG QyA1MTI0IA0KPj4gbW9zdGx5IGluaGVyaXRzIHRoYXQgKGFuZCBSVFAvQVZQRiBSRkMgNDU4NSkg YW5kIGluZGljYXRlcyB0cmFuc3BvcnQgDQo+PiBhcyB1c3VhbGx5IFVEUCAoYWx0ZXJuYXRpdmUg YmVpbmcgRENDUCkuDQo+Pg0KPj4gU28sIHVzaW5nIFJUUC9TQVZQRiBmb3IgRFRMUy1TUlRQIGRv ZXMgbm90IHNlZW0gY29uc2lzdGVudCB3aXRoIHRoZXNlIFJGQ3MuDQo+PiBNb3JlIGltcG9ydGFu dGx5IERUTFMtU1JUUCB1c2Ugb2Yg4oCcVURQL1RMUy9SVFAvU0FWUEYg4oCcIGlzIGNsZWFybHkg DQo+PiBkZWZpbmVkIGluIFJGQyA1NzY0Lg0KPj4NCj4+IE5vdyB0aGUgY2FzZSBvZiwg4oCcY2hh bmdpbmcgZnJvbSBkZWZhdWx0IFVEUCB0byBmaW5hbCBUQ1AgdHJhbnNwb3J0IG9yIA0KPj4gdmlj ZS12ZXJzYeKAnSBmb3IgU1JUUCBoYXMgdG8gYmUgaGFuZGxlZCBwZXIgSUNFIFJGQyBydWxlcywg d2hpY2ggc2F5cyANCj4+IGMvbT0gbGluZXMgc2hvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUg ZGVmYXVsdCBkZXN0aW5hdGlvbi4gU28sIA0KPj4gdXNpbmcg4oCcUlRQL1NBVlBG4oCdIHRvIGNv dmVyIGFsbCB0cmFuc3BvcnRzIGRvZXMgbm90IHNvdW5kIHJpZ2h0IHRvIG1lLCANCj4+IGVzcGVj aWFsbHkgd2hlbiBicm93c2VyIGhhcyB0byB1cGRhdGUgdGhlIFNEUCB3aGVuIGZpbmFsIHNlbGVj dGVkIA0KPj4gY2FuZGlkYXRlIGFuZC9vciB0cmFuc3BvcnQgY2hhbmdlcyBhbnl3YXkuDQo+DQo+ IEkgZG9uJ3QgbGlrZSB0aGUgYWJvdmUsIGJ1dCBJIHN0cm9uZ2x5IGFncmVlIHdpdGggaXQuIFNv Og0KPg0KPiAtIEluaXRpYWxseSB1c2UgIlVEUC9UTFMvUlRQL1NBVlBGIiBhcyB0aGUgUkZDIHN0 YXRlcy4NCj4NCj4gLSBJZiB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlIChhZnRlciBJQ0UgcHJvY2Vk dXJlcykgaGFzIGEgZGlmZmVyZW50IHRyYW5zcG9ydCwgdGhlbiBmaXJlIGFuIGV2ZW50IHRvIHRl bGwgdGhlIHVzZXIgYWJvdXQgaXQuIFNvbWV0aGluZw0KPiBsaWtlOg0KPiAgICBvbmljZXN0YXRl Y2hhbmdlKGV2ZW50KSAgd2hlcmU6DQo+ICAgIC0gZXZlbnQucmVhZHlTdGF0ZT0ib3BlbiINCj4g ICAgLSBldmVudC5zZWxlY3RlZFRyYW5zcG9ydCA9ICJUQ1AvVExTL1JUUC9TQVZQRiINCj4gQW5k IGluIGNhc2UgdGhlIHVzZXIgY2FsbHMgZ2V0TG9jYWxEZXNjcmlwdGlvbigpIGl0IHNob3VsZCBy ZXRyaWV2ZSBhIFNEUCB3aXRoIG0vYyBsaW5lcyBtYXRjaGluZyB0aGUgdHJhbnNwb3J0IGFuZCBh ZGRyZXNzIG9mIHRoZSBzZWxlY3RlZCBsb2NhbCBjYW5kaWRhdGUuDQoNCkxldCdzIGtlZXAgaW4g bWluZCB0aGF0IHRoZXJlIGFyZSBhbHNvIG90aGVyIGRhdGEgKGUuZy4gcG9ydCkgdGhhbiB0aGUg dHJhbnNwb3J0IHRoYXQgbWF5IGNoYW5nZSBhcyBwYXJ0IG9mIHRoZSBJQ0UgcHJvY2VkdXJlLg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Wed Jun 4 14:49:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0931A0349 for ; Wed, 4 Jun 2014 14:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 W2VHfJ0H1_bE for ; Wed, 4 Jun 2014 14:49:25 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781461A0356 for ; Wed, 4 Jun 2014 14:49:25 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jw12so145775veb.34 for ; Wed, 04 Jun 2014 14:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Mf1uIFtttghJ85C2k5md8z9M9dB5I1P3HFcWhJja5Qs=; b=MtvsDecMeebUzmEhBl4i1egG6a2qysjbekQvdDCxljboXFXUW73s2PCRL+qjZn9EMu kiqBI/MiricLv3+b2lLr/HXuu6Z2h/oHhK4urTuLfk43tBpw4ts1Cqz1vlyldNy3QWQZ 5OarXmjAj/d33wXdDjJltXmFt3gBWAZcKUyb3svv1E5Gq+I2Vx+UHCF2LiI+v7/09YEA bP6MX0JHOU/vv1IUAFcGjeHdoZGMQayysCxz8AsK5AlGzEoUUacyq7jLAieEGkk1HhAg 27IA/kj3m/lbfROKBnR64uJbbXbEq7B9JZ1JNNaiAnwTPoqT1FmanYGuhm9VTFOBrf8Y KEeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Mf1uIFtttghJ85C2k5md8z9M9dB5I1P3HFcWhJja5Qs=; b=L2CUj9TsZeuLeyRfzvDeVc36lNoKWfm+tYfalwsWSbZYh8H9wqAiT7nWK1RDwhOCIx PE49eLuXoyTjWnNQWVcXXHbkDP7ybqSU6DiVSGR9KvekXy6kdrsno4azgDiO3wTjYT1P 8HGvpKT6AlmDR623Qfud0xwd7V5nXCaG0cbODwG1Xb5Rar3UXI+Bpx4/4xcwctZhGcm1 yON4zai+6BVOJ2s1axPxpvtTzab/S0JZit8ktbDZbd/ND1d5GPubf6njdekZBlX9CcWA K8ytQxZI8mIzphObzjYXL6Xi6xitXFmFv9d84sXOHpH0YDEyiYt9ezVwh4ODhfqBwTru y3PA== X-Gm-Message-State: ALoCoQny2EdTFyUwRx0FyK6dWGG9gh8jjGkGmOEAZlPaJGfaqUWvp0H1B/lmaqx2ohDZ02YakAcf X-Received: by 10.220.182.5 with SMTP id ca5mr5718759vcb.50.1401918558780; Wed, 04 Jun 2014 14:49:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Wed, 4 Jun 2014 14:48:58 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> From: Justin Uberti Date: Wed, 4 Jun 2014 14:48:58 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1133d7eab3660f04fb0999d5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mZRnOb1P5LTnGtM5FGBMbQVPyXY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:49:28 -0000 --001a1133d7eab3660f04fb0999d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable count me out on this. I see no value in updating the m=3D line protocol depending on the active protocol in use (e.g. UDP vs TCP). I suggest that we go ahead with Martin's suggestion of offering RTP/SAVPF, but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are following 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF offer remains as an open question.) On Wed, Jun 4, 2014 at 12:33 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> +1 for =E2=80=9CUDP/TLS/RTP/SAVPF on the m=3D line=E2=80=9D > >> > >> Please don=E2=80=99t treat this like another hijacking attempt J but, > >> unfortunately the rationale for this is somewhat related to the ICE > discussion. > >> > >> RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC 5124 > >> mostly inherits that (and RTP/AVPF RFC 4585) and indicates transport > >> as usually UDP (alternative being DCCP). > >> > >> So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with these > RFCs. > >> More importantly DTLS-SRTP use of =E2=80=9CUDP/TLS/RTP/SAVPF =E2=80=9C= is clearly > >> defined in RFC 5764. > >> > >> Now the case of, =E2=80=9Cchanging from default UDP to final TCP trans= port or > >> vice-versa=E2=80=9D for SRTP has to be handled per ICE RFC rules, whic= h says > >> c/m=3D lines should be consistent with the default destination. So, > >> using =E2=80=9CRTP/SAVPF=E2=80=9D to cover all transports does not sou= nd right to me, > >> especially when browser has to update the SDP when final selected > >> candidate and/or transport changes anyway. > > > > I don't like the above, but I strongly agree with it. So: > > > > - Initially use "UDP/TLS/RTP/SAVPF" as the RFC states. > > > > - If the selected candidate (after ICE procedures) has a different > transport, then fire an event to tell the user about it. Something > > like: > > onicestatechange(event) where: > > - event.readyState=3D"open" > > - event.selectedTransport =3D "TCP/TLS/RTP/SAVPF" > > And in case the user calls getLocalDescription() it should retrieve a > SDP with m/c lines matching the transport and address of the selected loc= al > candidate. > > Let's keep in mind that there are also other data (e.g. port) than the > transport that may change as part of the ICE procedure. > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1133d7eab3660f04fb0999d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
count me out on this. I see no value in updating the m=3D = line protocol depending on the active protocol in use (e.g. UDP vs TCP).
I suggest that we go ahead with Martin's suggestion of= offering RTP/SAVPF, but also accept UDP/TLS/RTP/SAVPF for remote endpoints= that are following 5764 exactly. (What protocol is used in an answer to a = UDP/TLS/RTP/SAVPF offer remains as an open question.)


On Wed,= Jun 4, 2014 at 12:33 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

>> +1 for =E2=80=9CUDP/TLS/RTP/SAVPF on the m=3D line=E2=80=9D
>>
>> Please don=E2=80=99t treat this like another hijacking attempt J b= ut,
>> unfortunately the rationale for this is somewhat related to the IC= E discussion.
>>
>> RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC = 5124
>> mostly inherits that (and RTP/AVPF RFC 4585) and indicates transpo= rt
>> as usually UDP (alternative being DCCP).
>>
>> So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with th= ese RFCs.
>> More importantly DTLS-SRTP use of =E2=80=9CUDP/TLS/RTP/SAVPF =E2= =80=9C is clearly
>> defined in RFC 5764.
>>
>> Now the case of, =E2=80=9Cchanging from default UDP to final TCP t= ransport or
>> vice-versa=E2=80=9D for SRTP has to be handled per ICE RFC rules, = which says
>> c/m=3D lines should be consistent with the default destination. So= ,
>> using =E2=80=9CRTP/SAVPF=E2=80=9D to cover all transports does not= sound right to me,
>> especially when browser has to update the SDP when final selected<= br> >> candidate and/or transport changes anyway.
>
> I don't like the above, but I strongly agree with it. So:
>
> - Initially use "UDP/TLS/RTP/SAVPF" as the RFC states.
>
> - If the selected candidate (after ICE procedures) has a different tra= nsport, then fire an event to tell the user about it. Something
> like:
> =C2=A0 =C2=A0onicestatechange(event) =C2=A0where:
> =C2=A0 =C2=A0- event.readyState=3D"open"
> =C2=A0 =C2=A0- event.selectedTransport =3D "TCP/TLS/RTP/SAVPF&quo= t;
> And in case the user calls getLocalDescription() it should retrieve a = SDP with m/c lines matching the transport and address of the selected local= candidate.

Let's keep in mind that there are also other data (e.g. port) tha= n the transport that may change as part of the ICE procedure.

Regards,

Christer

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

--001a1133d7eab3660f04fb0999d5-- From nobody Wed Jun 4 14:57:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234EC1A0344 for ; Wed, 4 Jun 2014 14:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsGnJttmiWEk for ; Wed, 4 Jun 2014 14:57:07 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B2C1A024F for ; Wed, 4 Jun 2014 14:57:06 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id hw13so194478qab.18 for ; Wed, 04 Jun 2014 14:57:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=e2fYvDDiRqRzJo8ABTOSTiBD2cWbCJ4TX2cwEenRs6k=; b=Ep5ljW4QT3l5mPMmp48Ctz42sIuTW/aaiuILU9z3c1tzlpJwF6BtCLzxss1i3pOeKM LPlSC6Su/Fyt0STxh3xzfZdptLzNqq4Jjpr1798f/LXG0z65jq48mE6yWf1IxwFlKQ4k Qhh23b5iv1XnK2bnFG2IdXBEJuS//D63XvDxUSfbBk8U2wZhlLDVU9+qWhbGqLMTntIC XnIjX9Xk7vfhorZqMEULVvsyR5t4dIxLEd84G/iuydmy2xLjp3hPL31z0pDfA2gvU3hv d80q3H0nVMNgvoZxRr4Qp/m+XXRI81P/IjGfptmEIQrH0UCTUbgEudBwHZVWQrl51U/M 9dvw== X-Gm-Message-State: ALoCoQn4p2vEPeaSo9buQymsHxZuItFcBVFCyIi7IaYktMuAw+aUfpIJg2LpASooj+xDVatPwJ9Q X-Received: by 10.224.79.198 with SMTP id q6mr10952853qak.99.1401919020390; Wed, 04 Jun 2014 14:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Wed, 4 Jun 2014 14:56:40 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 4 Jun 2014 23:56:40 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F5efh_wgXTB2WWlkjg81AFd6dDE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:57:08 -0000 2014-06-04 23:48 GMT+02:00 Justin Uberti : > count me out on this. I see no value in updating the m=3D line protocol > depending on the active protocol in use (e.g. UDP vs TCP). > > I suggest that we go ahead with Martin's suggestion of offering RTP/SAVPF= , > but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are following > 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF > offer remains as an open question.) Question: do we have (or will have) a PC event telling us *which* ICE candidate is the selected one? If so, those who want to play with the "SDP rules" in RFC 5245 can be notified about the selected candidate and can even play more by mangling the SDP to "update the default media address" (after all, I think we all are used to mangle the SDP with JavaScript...). Wouldn't that be enough to satisfy all the needs? --=20 I=C3=B1aki Baz Castillo From nobody Wed Jun 4 15:03:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B3E1A032B for ; Wed, 4 Jun 2014 15:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcpoBa6UjozC for ; Wed, 4 Jun 2014 15:03:16 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3512D1A032D for ; Wed, 4 Jun 2014 15:03:16 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so9210997wib.11 for ; Wed, 04 Jun 2014 15:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ukUaTKvMZXQWtwNp7DmOcOkIJQ3jkRi/Msdp+B8/WEA=; b=OJAXqy/2bDgiFwPIQ1zBWdKMdRuMcalOpDrKLCdN8AqA/7S+C65Ijwk/D44VlkSUi7 qyGZ9LDaNv7LJ0JFe+1L/NYqdR7V6UgkJ4fOBXdeEobxweqbxsQCSIc61nTB5bWKy6z5 Lysj6iR7o1OWMUp86VSNEV871IiL5UPzO5FRZwM8GYqBB4MwEhHaX1cdLDrqdEUlJkbC B9L6mCt89uMDQHF6hZPc3inWYvkEQlAIdL3zElTYPRNE0dDYsiNPdlid9PWkk7TvB3Kl jPJiW76Dmc1BQ/VD02hSYjh/bViJTJ0B0PUmMK5xRPNdWigE07Zl+lQfk232nNMsHdJb i3bQ== X-Gm-Message-State: ALoCoQn0OFZMiQ1PQHWcIhPxsMwOd7yfyZboJUgdiX7fMKnCke5aqPiK1MHuYm3pDyJJKigX16rN X-Received: by 10.180.84.41 with SMTP id v9mr9558032wiy.1.1401919388921; Wed, 04 Jun 2014 15:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 4 Jun 2014 15:02:28 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:19e0:e4ad:d85d:67bd] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Wed, 4 Jun 2014 15:02:28 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=14dae9cc9b982e4f3204fb09cbde Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QLfjTE8B9bqBFAycHN4zAhQHyJ8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:03:18 -0000 --14dae9cc9b982e4f3204fb09cbde Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2014 at 2:48 PM, Justin Uberti wrote: > count me out on this. I see no value in updating the m=3D line protocol > depending on the active protocol in use (e.g. UDP vs TCP). > > I suggest that we go ahead with Martin's suggestion of offering RTP/SAVPF= , > but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are following > 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF > offer remains as an open question.) > This would be acceptable to me, but we probably should update 5764 to make RTP/SAVPF legal as well. -Ekr > > On Wed, Jun 4, 2014 at 12:33 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> +1 for =E2=80=9CUDP/TLS/RTP/SAVPF on the m=3D line=E2=80=9D >> >> >> >> Please don=E2=80=99t treat this like another hijacking attempt J but, >> >> unfortunately the rationale for this is somewhat related to the ICE >> discussion. >> >> >> >> RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC 512= 4 >> >> mostly inherits that (and RTP/AVPF RFC 4585) and indicates transport >> >> as usually UDP (alternative being DCCP). >> >> >> >> So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with these >> RFCs. >> >> More importantly DTLS-SRTP use of =E2=80=9CUDP/TLS/RTP/SAVPF =E2=80= =9C is clearly >> >> defined in RFC 5764. >> >> >> >> Now the case of, =E2=80=9Cchanging from default UDP to final TCP tran= sport or >> >> vice-versa=E2=80=9D for SRTP has to be handled per ICE RFC rules, whi= ch says >> >> c/m=3D lines should be consistent with the default destination. So, >> >> using =E2=80=9CRTP/SAVPF=E2=80=9D to cover all transports does not so= und right to me, >> >> especially when browser has to update the SDP when final selected >> >> candidate and/or transport changes anyway. >> > >> > I don't like the above, but I strongly agree with it. So: >> > >> > - Initially use "UDP/TLS/RTP/SAVPF" as the RFC states. >> > >> > - If the selected candidate (after ICE procedures) has a different >> transport, then fire an event to tell the user about it. Something >> > like: >> > onicestatechange(event) where: >> > - event.readyState=3D"open" >> > - event.selectedTransport =3D "TCP/TLS/RTP/SAVPF" >> > And in case the user calls getLocalDescription() it should retrieve a >> SDP with m/c lines matching the transport and address of the selected lo= cal >> candidate. >> >> Let's keep in mind that there are also other data (e.g. port) than the >> transport that may change as part of the ICE procedure. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --14dae9cc9b982e4f3204fb09cbde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 2:48 PM, Justin Uberti <= ;juberti@google.com= > wrote:
count me out on this. I see= no value in updating the m=3D line protocol depending on the active protoc= ol in use (e.g. UDP vs TCP).

I suggest that we go ahead with Martin's suggestion of o= ffering RTP/SAVPF, but also accept UDP/TLS/RTP/SAVPF for remote endpoints t= hat are following 5764 exactly. (What protocol is used in an answer to a UD= P/TLS/RTP/SAVPF offer remains as an open question.)

This would be acceptable to me, but = we probably should update 5764 to make
RTP/SAVPF legal as well.

-Ekr
=C2=A0

On Wed, Jun 4, 2014 at 12:33 AM, Christer Holmberg <= span dir=3D"ltr"><christer.holmberg@ericsson.com> wrote:
Hi,

>> +1 for =E2=80=9CUDP/TLS/RTP/SAVPF on the m=3D line=E2=80=9D
>>
>> Please don=E2=80=99t treat this like another hijacking attempt J b= ut,
>> unfortunately the rationale for this is somewhat related to the IC= E discussion.
>>
>> RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC = 5124
>> mostly inherits that (and RTP/AVPF RFC 4585) and indicates transpo= rt
>> as usually UDP (alternative being DCCP).
>>
>> So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with th= ese RFCs.
>> More importantly DTLS-SRTP use of =E2=80=9CUDP/TLS/RTP/SAVPF =E2= =80=9C is clearly
>> defined in RFC 5764.
>>
>> Now the case of, =E2=80=9Cchanging from default UDP to final TCP t= ransport or
>> vice-versa=E2=80=9D for SRTP has to be handled per ICE RFC rules, = which says
>> c/m=3D lines should be consistent with the default destination. So= ,
>> using =E2=80=9CRTP/SAVPF=E2=80=9D to cover all transports does not= sound right to me,
>> especially when browser has to update the SDP when final selected<= br> >> candidate and/or transport changes anyway.
>
> I don't like the above, but I strongly agree with it. So:
>
> - Initially use "UDP/TLS/RTP/SAVPF" as the RFC states.
>
> - If the selected candidate (after ICE procedures) has a different tra= nsport, then fire an event to tell the user about it. Something
> like:
> =C2=A0 =C2=A0onicestatechange(event) =C2=A0where:
> =C2=A0 =C2=A0- event.readyState=3D"open"
> =C2=A0 =C2=A0- event.selectedTransport =3D "TCP/TLS/RTP/SAVPF&quo= t;
> And in case the user calls getLocalDescription() it should retrieve a = SDP with m/c lines matching the transport and address of the selected local= candidate.

Let's keep in mind that there are also other data (e.g. port) tha= n the transport that may change as part of the ICE procedure.

Regards,

Christer

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


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


--14dae9cc9b982e4f3204fb09cbde-- From nobody Wed Jun 4 15:12:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1E71A032B for ; Wed, 4 Jun 2014 15:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERdpzufTSP5x for ; Wed, 4 Jun 2014 15:12:43 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE47F1A0309 for ; Wed, 4 Jun 2014 15:12:42 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id i13so213208qae.21 for ; Wed, 04 Jun 2014 15:12:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=JkTWTOferRC6P8Wj63+pHdzbK7n8wU18KNbwUdOP5Go=; b=IvQJh9tJgMReEEsGUeAD7IKH1cRfwIeJ7bcdMFkgN7YMApNbTYnQCXsVDck6/SpkKX RAxGjr/2VePqJpR6BVuSrOaYDfIq6T0Nt4AQypKuetWT8rafQvcdz5BQzl3rQUEYbBw0 WlcyxmVv6/cyXHtSZzzBW4vgc8SIoMRHXq7Vxy5TXMYBktsv4952svgqePEWnWElCCwl A5VO2hIInQcpC3dS/VrIse7UZM4bhY76MC/1VEEMN4nSCjGKVmyO4lv0Gb6p9nx+jnH6 LWzD6uVJbAxTKzoxLF1OhFNNAVjDgYmE21GgLQfNk/GwERTS1Qdvz7gvyESFhHzm4ql4 A8ZQ== X-Gm-Message-State: ALoCoQkjdRgvM+cufwAzCuIznH5BuTHJ5vixlxOP4xXbw2UFETNua+Ogoll3EztxGvpbj1Sud2bf X-Received: by 10.224.40.131 with SMTP id k3mr75659075qae.5.1401919956264; Wed, 04 Jun 2014 15:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Wed, 4 Jun 2014 15:12:16 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Jun 2014 00:12:16 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Abg5y7OndxecNE8bBptDjjGE0hQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:12:43 -0000 2014-06-05 0:02 GMT+02:00 Eric Rescorla : > On Wed, Jun 4, 2014 at 2:48 PM, Justin Uberti wrote: >> >> count me out on this. I see no value in updating the m=3D line protocol >> depending on the active protocol in use (e.g. UDP vs TCP). >> >> I suggest that we go ahead with Martin's suggestion of offering RTP/SAVP= F, >> but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are followin= g >> 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF >> offer remains as an open question.) > > > This would be acceptable to me, but we probably should update 5764 to mak= e > RTP/SAVPF legal as well. Hi, my previous suggestion includes that the m=3D protocol field gets "UDP/TLS/RTP/SAVPF" as defined by RFC 5764. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jun 4 15:15:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355A11A032B for ; Wed, 4 Jun 2014 15:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 4zgWF93rRAyC for ; Wed, 4 Jun 2014 15:15:29 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6041A0309 for ; Wed, 4 Jun 2014 15:15:29 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so149434wes.15 for ; Wed, 04 Jun 2014 15:15:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b1v+yfErUmiK+nladearDoCuohnZIfMvvbHPR/5p5xo=; b=j+v9BzHcEhryL2D9uM/INKj/iSjmH+xr+wXA1oZUY1+gQFyjh5x/S5fsAF8fLO030G bj/wBw546hD6+Ikn9Q25bQFl7WIhIPx98AULm30EUKtWrNcjz2Q93TxlKzPvBt3vY7tp 7f/nEA2ydWlMiI2ViEQuHi10ZbU5bLHwwRPCKhMkWHuiSON5u2DF8Oe+8Rg8Pu10Q0Fe USf1B66FUw16+xmDBJ2swJ4NahyHlfYvZcQuQrLs1Ls7QCb3p9bAGrZlNSMaI5jjsXDQ oK9B1MmnLkPHd9tNfCDXPorNsO8TZyJ2j59niAqNa5u6frO8hjHgRE9+8ow5tIKy/JBV vZHQ== X-Gm-Message-State: ALoCoQm54ZG8dwLZEy/K+4922TJGhDBCKnjQ1ePdIs5Jiq0WI1tqqIAVumt3YTWprEPFXIofadKp X-Received: by 10.180.210.237 with SMTP id mx13mr9621017wic.49.1401920122056; Wed, 04 Jun 2014 15:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 4 Jun 2014 15:14:40 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:19e0:e4ad:d85d:67bd] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Wed, 4 Jun 2014 15:14:40 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c25860e112a604fb09f69f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KHEhwfdpZS_nsDjwE6LnW2jTkWo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:15:30 -0000 --001a11c25860e112a604fb09f69f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2014 at 3:12 PM, I=C3=B1aki Baz Castillo wro= te: > 2014-06-05 0:02 GMT+02:00 Eric Rescorla : > > On Wed, Jun 4, 2014 at 2:48 PM, Justin Uberti > wrote: > >> > >> count me out on this. I see no value in updating the m=3D line protoco= l > >> depending on the active protocol in use (e.g. UDP vs TCP). > >> > >> I suggest that we go ahead with Martin's suggestion of offering > RTP/SAVPF, > >> but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are > following > >> 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAV= PF > >> offer remains as an open question.) > > > > > > This would be acceptable to me, but we probably should update 5764 to > make > > RTP/SAVPF legal as well. > > Hi, my previous suggestion includes that the m=3D protocol field gets > "UDP/TLS/RTP/SAVPF" as defined by RFC 5764. I prefer Justin's suggestion. -Ekr > > -- > I=C3=B1aki Baz Castillo > > --001a11c25860e112a604fb09f69f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 3:12 PM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2014-06-05 0:02 GMT+02:00 Eric Rescorla <= ekr@rtfm.com>:
> On Wed, Jun 4, 2014 at 2:48 PM, Justin Uberti <juberti@google.com> wrote:
>>
>> count me out on this. I see no value in updating the m=3D line pro= tocol
>> depending on the active protocol in use (e.g. UDP vs TCP).
>>
>> I suggest that we go ahead with Martin's suggestion of offerin= g RTP/SAVPF,
>> but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are fo= llowing
>> 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP= /SAVPF
>> offer remains as an open question.)
>
>
> This would be acceptable to me, but we probably should update 5764 to = make
> RTP/SAVPF legal as well.

Hi, my previous suggestion includes that the m=3D protocol field gets=
"UDP/TLS/RTP/SAVPF" as defined by RFC 5764.

=
I prefer Justin's suggestion.

-Ekr<= /div>



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

--001a11c25860e112a604fb09f69f-- From nobody Wed Jun 4 15:15:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C064A1A0362 for ; Wed, 4 Jun 2014 15:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 1yIUm5N4DTXj for ; Wed, 4 Jun 2014 15:15:53 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DD41A0309 for ; Wed, 4 Jun 2014 15:15:53 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s54MFgS4001703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jun 2014 17:15:43 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s54MFgvq025933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 18:15:42 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 4 Jun 2014 18:15:42 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Justin Uberti , Christer Holmberg Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPgD7abSYqU+IK/kuiw4z1j/rtWJthf6wQ Date: Wed, 4 Jun 2014 22:15:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@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: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E3E45C1US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/b_3QLRnP_OkIHHSvP4HfReVCdfE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:15:55 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E3E45C1US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpjb3VudCBtZSBvdXQgb24gdGhpcy4gSSBzZWUgbm8gdmFsdWUgaW4gdXBkYXRpbmcgdGhlIG09 IGxpbmUgcHJvdG9jb2wgZGVwZW5kaW5nIG9uIHRoZSBhY3RpdmUgcHJvdG9jb2wgaW4gdXNlIChl LmcuIFVEUCB2cyBUQ1ApLg0KW1JhanVdIEkgc2VlIHRoZXJlIGlzIGEgY2xlYXIgdmFsdWUgaW4g ZG9pbmcgdGhpczoNCg0KMS4gICAgICAgSUNFIFJGQyBzdGF0ZXMgYy9tPSBsaW5lcyBzaG91bGQg YmUgdXBkYXRlZCB0byBkZWZhdWx0IGRlc3RpbmF0aW9uIGZvciBpbml0aWFsIG9mZmVyIGFuZCBz dWItc2VxdWVudCBvZmZlciAoc2VsZWN0ZWQgY2FuZGlkYXRlKS4gU28sIGlmIGNyZWF0ZU9mZmVy KCkgaXMgY2FsbGVkIGFmdGVyIElDRSBjb21wbGV0ZWQgdGhlbiBicm93c2VyIGhhcyB0byB1cGRh dGUgU0RQIHRvIHJlZmxlY3QgdGhpcyBhbnl3YXkuIFNvLCB3aHkgbm90IGJyb3dzZXIgdXBkYXRl IFNEUCBhbmQgZmlyZSBhbiBldmVudCBhYm91dCBmaW5hbCBjYW5kaWRhdGUgYmVlbiBzZWxlY3Rl ZD8gSXQgY2FuIGZpcmUgdGhpcyBldmVudCBhbHdheXMgb3Igb25seSB3aGVuIGl0IGlzIGRpZmZl cmVudCBmcm9tIGRlZmF1bHQgY2FuZGlkYXRlIHRoYXQgd2FzIHVzZWQgb24gYy9tPSBsaW5lcy4g RXhpc3Rpbmcgb25pY2Vjb25uZWN0aW9uc3RhdGVjaGFuZ2UgKCkgY2FuIGJlIHVzZWQgYXMgYSB0 cmlnZ2VyIGFuZCBhcHBsaWNhdGlvbiBjYW4gaW5zcGVjdCBTRFAgdG8gbGVhcm4gYWJvdXQgdGhl IHNlbGVjdGVkIGNhbmRpZGF0ZS4NCg0KMi4gICAgICAgU29tZSBhcHBsaWNhdGlvbnMgbWF5IHdh bnQgdG8ga25vdyB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlIGFuZCB0cmFuc3BvcnQgZm9yIHZhcmlv dXMgcmVhc29ucyBsaWtlOg0KDQotICAgICAgICAgIFVwZGF0aW5nIG1pZGRsZSBib3hlcyBmb3Ig YmV0dGVyIFFvUyAobm90IGp1c3QgZm9yIHNlbGVjdGVkIHRyYW5zcG9ydCwgYnV0IGZvciBzZWxl Y3RlZCBpcCwgcG9ydCkuIEkgYmVsaWV2ZSB0aGlzIGlzIHRoZSBtYWluIHJlYXNvbiB3aHkgSUNF IFJGQyBzYXlzICgxKSBhYm92ZS4NCg0KLSAgICAgICAgICBMZWFybmluZyBhYm91dCB0aGUgYWN0 dWFsIHRyYW5zcG9ydCB0aGF0IGlzIHVzZWQsIHdoaWNoIG1heSBnaXZlIGNsdWVzIGFib3V0IHRo ZSB1bmRlcmx5aW5nIG5ldHdvcmsgKHJlc3RyaWN0aXZlIGZpcmV3YWxscz8gd3JvbmcgcHJvdmlz aW9uaW5nIG9uIGhvbWUgcm91dGVycyB0byBub3QgYWxsb3cgc29tZSB0eXBlIG9mIFVEUCBvdXQ/ KS4NCiAgICAgICAgICAgICBCYXNpY2FsbHksIHdlIG1heSBjb21lIHVwIHdpdGggdmFyaW91cyBv dGhlciByZWFzb25zLCBidXQgSU1ITyB0aGUgbWFpbiBwb2ludCBpcywgSUNFIGNhbmRpZGF0ZSBz ZWxlY3Rpb24NCiAgICAgICAgICAgICBpcyBhbiBpbXBvcnRhbnQgZXZlbnQgYW5kIGFwcGxpY2F0 aW9uIGtub3dpbmcgdGhlIHNlbGVjdGVkIGNhbmRpZGF0ZSB3aWxsIGhlbHAgZG8gc29tZSBpbnRl cmVzdGluZw0KICAgICAgICAgICAgIHZhbHVlIGFkZGVkIHRoaW5ncy4NCg0KDQoNCkkgc3VnZ2Vz dCB0aGF0IHdlIGdvIGFoZWFkIHdpdGggTWFydGluJ3Mgc3VnZ2VzdGlvbiBvZiBvZmZlcmluZyBS VFAvU0FWUEYsIGJ1dCBhbHNvIGFjY2VwdCBVRFAvVExTL1JUUC9TQVZQRiBmb3IgcmVtb3RlIGVu ZHBvaW50cyB0aGF0IGFyZSBmb2xsb3dpbmcgNTc2NCBleGFjdGx5LiAoV2hhdCBwcm90b2NvbCBp cyB1c2VkIGluIGFuIGFuc3dlciB0byBhIFVEUC9UTFMvUlRQL1NBVlBGIG9mZmVyIHJlbWFpbnMg YXMgYW4gb3BlbiBxdWVzdGlvbi4pDQpbUmFqdV0gSSB0aGluayBhbnN3ZXIgc2hvdWxkIGhhdmUg VURQL1RMUy9SVFAvU0FWUEYgZWxzZSBpdCB3aWxsIHJlc3VsdCBpbiBTRFAgTy9BIHZpb2xhdGlv bi4NCg0KQlINClJhanUNCg0KDQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E3E45C1US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo0NDI2NDk3NjM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xMzc2MjI0MjM2IC0yNDgxOTA5MDQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6 Ym9sZDsNCgltc28tYW5zaS1mb250LXN0eWxlOml0YWxpYzt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDoxNTAzMDA3ODg4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczo1MDgyMDA1NTIgMzg5NzExMzYwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 Q2FsaWJyaTt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Y291bnQgbWUgb3V0IG9uIHRoaXMuIEkgc2VlIG5vIHZhbHVlIGluIHVw ZGF0aW5nIHRoZSBtPSBsaW5lIHByb3RvY29sIGRlcGVuZGluZyBvbiB0aGUgYWN0aXZlIHByb3Rv Y29sIGluIHVzZSAoZS5nLiBVRFAgdnMgVENQKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5bUmFqdV0gSSBzZWUgdGhlcmUgaXMgYSBjbGVhciB2YWx1ZSBpbiBkb2luZyB0aGlzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2k+PC9iPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SUNFIFJGQyBzdGF0ZXMgYy9t PSBsaW5lcyBzaG91bGQgYmUgdXBkYXRlZCB0byBkZWZhdWx0IGRlc3RpbmF0aW9uIGZvciBpbml0 aWFsIG9mZmVyIGFuZCBzdWItc2VxdWVudCBvZmZlciAoc2VsZWN0ZWQgY2FuZGlkYXRlKS4gU28s IGlmIGNyZWF0ZU9mZmVyKCkNCiBpcyBjYWxsZWQgYWZ0ZXIgSUNFIGNvbXBsZXRlZCB0aGVuIGJy b3dzZXIgaGFzIHRvIHVwZGF0ZSBTRFAgdG8gcmVmbGVjdCB0aGlzIGFueXdheS4gU28sIHdoeSBu b3QgYnJvd3NlciB1cGRhdGUgU0RQIGFuZCBmaXJlIGFuIGV2ZW50IGFib3V0IGZpbmFsIGNhbmRp ZGF0ZSBiZWVuIHNlbGVjdGVkPyBJdCBjYW4gZmlyZSB0aGlzIGV2ZW50IGFsd2F5cyBvciBvbmx5 IHdoZW4gaXQgaXMgZGlmZmVyZW50IGZyb20gZGVmYXVsdCBjYW5kaWRhdGUgdGhhdA0KIHdhcyB1 c2VkIG9uIGMvbT0gbGluZXMuIEV4aXN0aW5nIG9uaWNlY29ubmVjdGlvbnN0YXRlY2hhbmdlICgp IGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlciBhbmQgYXBwbGljYXRpb24gY2FuIGluc3BlY3QgU0RQ IHRvIGxlYXJuIGFib3V0IHRoZSBzZWxlY3RlZCBjYW5kaWRhdGUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48L2k+PC9iPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U29tZSBhcHBsaWNhdGlvbnMgbWF5IHdhbnQgdG8ga25vdyB0aGUg c2VsZWN0ZWQgY2FuZGlkYXRlIGFuZCB0cmFuc3BvcnQgZm9yIHZhcmlvdXMgcmVhc29ucyBsaWtl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VXBkYXRpbmcgbWlkZGxlIGJveGVzIGZvciBiZXR0ZXIgUW9TIChub3QganVzdCBmb3Igc2Vs ZWN0ZWQgdHJhbnNwb3J0LCBidXQgZm9yIHNlbGVjdGVkIGlwLCBwb3J0KS4gSSBiZWxpZXZlIHRo aXMgaXMgdGhlIG1haW4gcmVhc29uIHdoeSBJQ0UgUkZDIHNheXMNCiAoMSkgYWJvdmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MZWFy bmluZyBhYm91dCB0aGUgYWN0dWFsIHRyYW5zcG9ydCB0aGF0IGlzIHVzZWQsIHdoaWNoIG1heSBn aXZlIGNsdWVzIGFib3V0IHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgKHJlc3RyaWN0aXZlIGZpcmV3 YWxscz8gd3JvbmcgcHJvdmlzaW9uaW5nIG9uDQogaG9tZSByb3V0ZXJzIHRvIG5vdCBhbGxvdyBz b21lIHR5cGUgb2YgVURQIG91dD8pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7QmFzaWNhbGx5LCB3ZSBtYXkgY29tZSB1cCB3aXRoIHZhcmlvdXMgb3RoZXIg cmVhc29ucywgYnV0IElNSE8gdGhlIG1haW4gcG9pbnQgaXMsIElDRSBjYW5kaWRhdGUgc2VsZWN0 aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 aXMgYW4gaW1wb3J0YW50IGV2ZW50IGFuZCBhcHBsaWNhdGlvbiBrbm93aW5nIHRoZSBzZWxlY3Rl ZCBjYW5kaWRhdGUgd2lsbCBoZWxwIGRvIHNvbWUgaW50ZXJlc3RpbmcNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt2YWx1ZSBhZGRlZCB0aGluZ3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDouNzVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgc3VnZ2VzdCB0aGF0IHdlIGdvIGFoZWFkIHdpdGggTWFydGluJ3Mgc3VnZ2Vz dGlvbiBvZiBvZmZlcmluZyBSVFAvU0FWUEYsIGJ1dCBhbHNvIGFjY2VwdCBVRFAvVExTL1JUUC9T QVZQRiBmb3IgcmVtb3RlIGVuZHBvaW50cyB0aGF0IGFyZSBmb2xsb3dpbmcgNTc2NCBleGFjdGx5 LiAoV2hhdCBwcm90b2NvbCBpcyB1c2VkIGluIGFuIGFuc3dlciB0byBhIFVEUC9UTFMvUlRQL1NB VlBGIG9mZmVyIHJlbWFpbnMNCiBhcyBhbiBvcGVuIHF1ZXN0aW9uLik8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bUmFqdV0gSSB0aGluayBhbnN3ZXIgc2hvdWxkIGhhdmUgVURQL1RMUy9S VFAvU0FWUEYgZWxzZSBpdCB3aWxsIHJlc3VsdCBpbiBTRFAgTy9BIHZpb2xhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJhanU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E3E45C1US70UWXCHMBA02z_-- From nobody Wed Jun 4 16:29:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDA41A03D0 for ; Wed, 4 Jun 2014 16:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 ijZ8CAfyYcJV for ; Wed, 4 Jun 2014 16:29:43 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D591A03A1 for ; Wed, 4 Jun 2014 16:29:43 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id la4so248660vcb.28 for ; Wed, 04 Jun 2014 16:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6PB84rp3Z8KQFEIW2KB0VWCeHmGG7XlkUdv35rVnemg=; b=b2cskA4tCryd9I/xS2yw8gGtKFdCJn+Ug5eKiYqzs4M8XXD89LON2beHBsLOur787W IHkX+ndSHTTT+Rq48xH0S84ZOhi40rmhT5oEf+cuxBUNq25yUpH+FYH7DJfIUt/mDw5p YIiEhmyXJ8ojKU3d70fJNSbMdNmL7bd13ij3QdekezONQM6i3YjuqIjK6VUtMoDm+rIf MMYmJFNs7+F2zSOdjdWoBbxyeopHMzKl2FGo1SVamKqHicCeLgOwKPqRR79Js2YPyH1X hs8wdc9v34YGh57TWvZNL6cMpm27oJRonHRDCP57ReZygzW7NIFuMn0Fy8/s8rNwiqDj 70gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6PB84rp3Z8KQFEIW2KB0VWCeHmGG7XlkUdv35rVnemg=; b=Tr0t2P6v2R1+svMwQ8w6MhmtqaRWatJFpZxNzw3hZcRBTUfLNnqWQPSRS4T47pXafD 8QYX5XTqBAgL6VY7Y94jL0YhACw9orHBbRe15GdkJLkXQujIgOU4mwBIm4dcdVrtPGhe 1Cv1RHBNmpofKvrbu4Y+jgxvrR67aTLR0zJXFCAqOck9HvZU6vVW2U0qgIvzB4DApR6i 76SYF71iAjTriS1IQwZqttK5F6B+/C45GXzSiTl7mVnLiVT9NWRVzJQfxp2Ss7PoKwYk 0IU9UnG5mjZgyefVxVB/CBTBSFYbY9280Suk1Wvd0/CM9W9HjTNZXA+CGOfz1Qr/zaGO mzFw== X-Gm-Message-State: ALoCoQlEYvr9//2J3mp3OhflZOUFCQCfimf6RVYknj9sckOI89oQ2aHf79hFowk5djejG94rZC0G X-Received: by 10.58.74.38 with SMTP id q6mr46679601vev.7.1401924576950; Wed, 04 Jun 2014 16:29:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Wed, 4 Jun 2014 16:29:16 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> From: Justin Uberti Date: Wed, 4 Jun 2014 16:29:16 -0700 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=047d7bacbedc695aa504fb0b00cf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Pz8sAOmBiLV5IIlhU0Yrn5F2pX0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 23:29:45 -0000 --047d7bacbedc695aa504fb0b00cf Content-Type: text/plain; charset=UTF-8 On Wed, Jun 4, 2014 at 3:15 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > > count me out on this. I see no value in updating the m= line protocol > depending on the active protocol in use (e.g. UDP vs TCP). > > *[Raju] I see there is a clear value in doing this:* > > *1. *ICE RFC states c/m= lines should be updated to default > destination for initial offer and sub-sequent offer (selected candidate). > So, if createOffer() is called after ICE completed then browser has to > update SDP to reflect this anyway. So, why not browser update SDP and fire > an event about final candidate been selected? It can fire this event always > or only when it is different from default candidate that was used on c/m= > lines. Existing oniceconnectionstatechange () can be used as a trigger and > application can inspect SDP to learn about the selected candidate. > > *2. *Some applications may want to know the selected candidate and > transport for various reasons like: > > - Updating middle boxes for better QoS (not just for selected > transport, but for selected ip, port). I believe this is the main reason > why ICE RFC says (1) above. > > - Learning about the actual transport that is used, which may > give clues about the underlying network (restrictive firewalls? wrong > provisioning on home routers to not allow some type of UDP out?). > > Basically, we may come up with various other reasons, but > IMHO the main point is, ICE candidate selection > > is an important event and application knowing the selected > candidate will help do some interesting > > value added things. > > > You could still do that. The question is whether the m= line needs to explicitly include the protocol used by the active candidate pair. > > > I suggest that we go ahead with Martin's suggestion of offering RTP/SAVPF, > but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are following > 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF > offer remains as an open question.) > > *[Raju] I think answer should have UDP/TLS/RTP/SAVPF else it will result > in SDP O/A violation.* > Can you point me to the text that requires this? I looked in 3264 before, but didn't see it. > --047d7bacbedc695aa504fb0b00cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 3:15 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

=C2=A0

count me out on this. I see no value in updating the= m=3D line protocol depending on the active protocol in use (e.g. UDP vs TC= P).

[Raju] I see = there is a clear value in doing this:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ICE RFC stat= es c/m=3D lines should be updated to default destination for initial offer = and sub-sequent offer (selected candidate). So, if createOffer() is called after ICE completed then browser has to update SDP to reflect th= is anyway. So, why not browser update SDP and fire an event about final can= didate been selected? It can fire this event always or only when it is diff= erent from default candidate that was used on c/m=3D lines. Existing oniceconnectionstatechange () can be us= ed as a trigger and application can inspect SDP to learn about the selected= candidate.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Some applica= tions may want to know the selected candidate and transport for various rea= sons like:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Updating middle boxe= s for better QoS (not just for selected transport, but for selected ip, por= t). I believe this is the main reason why ICE RFC says (1) above.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Learning about the a= ctual transport that is used, which may give clues about the underlying net= work (restrictive firewalls? wrong provisioning on home routers to not allow some type of UDP out?).

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Basically, we may come up = with various other reasons, but IMHO the main point is, ICE candidate selec= tion

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is an important event= and application knowing the selected candidate will help do some interesti= ng

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0value added things.


You could still do that. The question is whether the m=3D line needs = to explicitly include the protocol used by the active candidate pair.=C2=A0=

=C2=A0

I suggest that we go ahead with Martin's suggest= ion of offering RTP/SAVPF, but also accept UDP/TLS/RTP/SAVPF for remote end= points that are following 5764 exactly. (What protocol is used in an answer= to a UDP/TLS/RTP/SAVPF offer remains as an open question.)

[Raju] I thin= k answer should have UDP/TLS/RTP/SAVPF else it will result in SDP O/A viola= tion.


Can you poin= t me to the text that requires this? I looked in 3264 before, but didn'= t see it.=C2=A0

--047d7bacbedc695aa504fb0b00cf-- From egueiros@jive.com Wed Jun 4 17:03:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D851A03DB for ; Wed, 4 Jun 2014 17:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0EtqH4CEm4f for ; Wed, 4 Jun 2014 17:03:16 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6711A03D8 for ; Wed, 4 Jun 2014 17:03:16 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rd18so228994iec.38 for ; Wed, 04 Jun 2014 17:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type; bh=+C57fCi/jkFxgXuUO7LbLG6bxagEhAqochNRjSKJFSw=; b=EbDXzXj0Lo3PPXhah7mOxR25+qVedsvL/KaqCAZj8G28m66dZVVtR9xUBOggAH0/r9 trls/SF27ypWRTlx4PWv4Ojw4KcWNwtfjNV6FdUTHnisYob18h03p3XfNw2xVXj4CHDk VrqNnwuLIrKzTTg71yVEPnW7KjPHw99DbuHAA/SS1wOraNtN659WNfJw+1i29axKjeQo f3K64L79GfFsBef7qyGX8FIOOB7/C84I8/dw5SBfx7ND0w4asUowgadyNE4W16A4OYvk PsDdpTeC9+R4TPBq4d/ykBMHHLJX5cPtuu3YAC6op5sS2sqsZQ7GRne641sdHcVHZ7oN Pu4Q== X-Gm-Message-State: ALoCoQnde81Ujtc7i7xfpN1mecKPOMnQo49zIAQLN4lPtc4qtId6ViAxWGiAKxNmlLsGHvbUo4SA X-Received: by 10.50.47.112 with SMTP id c16mr13360267ign.4.1401926589633; Wed, 04 Jun 2014 17:03:09 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id ck1sm14172618igb.13.2014.06.04.17.03.08 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 17:03:08 -0700 (PDT) Date: Wed, 4 Jun 2014 18:03:06 -0600 From: Eduardo Gueiros To: rtcweb@ietfa.amsl.com Message-ID: In-Reply-To: <20140605000150.588F01A03D8@ietfa.amsl.com> References: <20140605000150.588F01A03D8@ietfa.amsl.com> X-Mailer: Airmail (237) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="538fb3ba_66334873_fbe" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ggx7_eYzraXYlMGi2j75zRLwKHs Subject: Re: [rtcweb] =?utf-8?q?Confirm=3A_rtcweb=40ietfa=2Eamsl=2Ecom=3AU4-zb?= =?utf-8?q?g9pFjOs=3Afy4K1-4EDckKF1Gu8j-uo3Mpgjv-ONke-6L7JA?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 00:05:26 -0000 --538fb3ba_66334873_fbe Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --=C2=A0 Eduardo Gueiros Sent with Airmail On June 4, 2014 at 6:01:46 PM, rtcweb=40ietfa.amsl.com (rtcweb=40ietfa.am= sl.com) wrote: U4-zbg9p=46jOs --538fb3ba_66334873_fbe Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi,

 

A comment on draft-ietf-rtcweb-data-protocol-06:

 

Section 5.1 says:

 

"Protocol: Variable Length (sequence of characters)
      The sub-protocol for the channel as a UTF-8 = encoded string.  If
      this is an empty string the protocol is unsp= ecified.  If it is a
      non-empty string, it specifies an protocol r= egistered in the
      'WebSocket Subprotocol Name Registry' create= d in [RFC6455]."

 

 

I think "The sub-protocol for the channel as a UTF-8 encoded string= ." part is a little confusing, because there is no such thing as sub-p= rotocol in DCEP itself (DCEP only uses the WebSocket sub-protocol registry = for registering DCEP *protocol* values).

 

Perhaps we could just remove the sentence, and keep:

 

"Protocol: Variable Length (sequence of characters)
      If this is an empty string the protocol is u= nspecified.  If it is a
      non-empty string, it specifies an protocol r= egistered in the
      'WebSocket Subprotocol Name Registry' create= d in [RFC6455]."

 

Section 4 gives more information about the usage of the protocol.

 

(Alternatively, we could use sub-protocol terminology also in DCEP)

 

Regards,

 

Christer

 

 

 

 

 

 

From: rtcweb [rtcweb-bounces@ietf.org] on = behalf of Ted Hardie [ted.ietf@gmail.com]
Sent: Tuesday, 10 June, 2014 9:52 PM
To: rtcweb@ietf.org
Subject: [rtcweb] WGLC for data channel drafts

Dear WG,<= br>
This star= ts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please re= view them in detail, especially for areas which may be of concern to the br= oader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen
--_000_7594FB04B1934943A5C02806D1A2204B1D35B976ESESSMB209erics_-- From nobody Tue Jun 10 12:42:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6901A02A6 for ; Tue, 10 Jun 2014 12:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le6BZQJXFSR5 for ; Tue, 10 Jun 2014 12:42:33 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9E41A02C4 for ; Tue, 10 Jun 2014 12:42:32 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-a6-53975fa6555b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0E.D2.16420.6AF57935; Tue, 10 Jun 2014 21:42:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 21:42:30 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WGLC for data channel drafts - web terminology Thread-Index: AQHPhOItQba5CXiF9UCW6zEpLdNoww== Date: Tue, 10 Jun 2014 19:42:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D35B9DC@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_7594FB04B1934943A5C02806D1A2204B1D35B9DCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje6y+OnBBnu2WVms/dfObtE4186B yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgypi6ehVjwQWvitP7rrA1MB6x7WLk5JAQMJGY 33yDBcIWk7hwbz1bFyMXh5DAUUaJG2tus0A4ixklOia3AmU4ONgELCS6/2mDNIgIeEhs+vub FcQWFnCR2Pu4iw0i7irx88gqZpByEQE9iX9XPUHCLAKqEmuPfAPbxSvgK7F+YQNYKyPQ3u+n 1jCB2MwC4hK3nsxngrhHQGLJnvPMELaoxMvH/1ghbEWJq9OXQ9XnSzx/NI8NYqagxMmZT1gm MArNQjJqFpKyWUjKIOJ6EjemTmGDsLUlli18zQxh60rM+HeIBVl8ASP7KkbR4tTipNx0I2O9 1KLM5OLi/Dy9vNSSTYzAGDm45bfqDsbLbxwPMQpwMCrx8C5wnx4sxJpYVlyZe4hRmoNFSZz3 okZ1sJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGFYu+rCk8FXyGBqlCsof2vnZRuveuuO5H gtqa9a+ubmvkeNIe7bzN8NSBeXns1+PvJu18cPPetqYFGoFv1uu3HQxiloj6e6721oG3jxl9 pqZtswtdtGfJLvuWeTpc+1si5DiqDBMvtFeskv+6YWqj89m87To+tc5qDawrZY16rY8s0/YM nMqpxFKckWioxVxUnAgAglrn7HICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KgJHPEdTkynFfiLXkwnp9KfQ_8E Subject: Re: [rtcweb] WGLC for data channel drafts - web terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:42:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D35B9DCESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, A comment (which has been raised before) on draft-ietf-rtcweb-data-channel-= 10: The name of the mechanism is "WebRTC Data Channel", and much of the text gi= ves a picture that the mechanism is only to be used within the WebRTC conte= xt. If we want to call it "WebRTC Data Channel", we should make it clear that W= ebRTC is only one scenario where it can be used, but that it can also be us= ed elsewhere. For example, we are using it in CLUE. A few places, where I think we need modifications to reflect it. Section 3: ------------ Q3_1: s/For general use cases see [I-D.ietf-rtcweb-use-cases-and-requiremen= ts]./For WebRTC use cases see [I-D.ietf-rtcweb-use-cases-and-requirements]. Q3_2: In sections 3.1 and 3.2, there are a number of WebRTC specific requir= ements, and "PeerConnection", "JavaScript" etc terminology is used. I think= it should be clear that those requirements come from WebRTC. Section 5: ------------ Q5_1: I suggest to replace: "SCTP multihoming will not be used in WebRTC." ...with something like: "The WebRTC Data Channel mechanism does not support SCTP multihoming." Section 6: ------------ Q6_1: In section 6.2, the follwoing sentence: "The SCTP association will be set up when the two endpoints of the WebRTC PeerConnection agree on opening it, as negotiated by JSEP (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]." ...only applies to WebRTC. But, it needs to be clear that, in other context= s, other mechanisms can be used. Q6_2: In section 6.4, I suggest to re-order the paragraphs in the following= way: "The realization of a bidirectional Data Channel is a pair of one incoming stream and one outgoing SCTP stream having the same stream SCTP identifier. How stream values are selected is protocol and implementation dependent. Each data channel also has a priority, which is an 2 byte unsigned integer value. These priorities MUST be interpreted as weighted- fair-queuing scheduling priorities per the definition of the corresponding stream scheduler supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high") or 1024 ("extra high"). The W3C has consensus on defining the application API for WebRTC DataChannels to be bidirectional. They also consider the notions of in-sequence, out-of-sequence, reliable and unreliable as properties of Channels. One strong wish is for the application-level API to be close to the API for WebSockets, which implies bidirectional streams of data and waiting for onopen to fire before sending, a textual label used to identify the meaning of the stream, among other things." ...because, the realization is the important part :) Regards, Christer ________________________________ From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie [ted.ietf@gm= ail.com] Sent: Tuesday, 10 June, 2014 9:52 PM To: rtcweb@ietf.org Subject: [rtcweb] WGLC for data channel drafts Dear WG, This starts a working group last call for our core Data Channel drafts: draft-ietf-rtcweb-data-protocol-06.txt draft-ietf-rtcweb-data-channel-10.txt Please review them in detail, especially for areas which may be of concern = to the broader IETF community. This WGLC will end on June 27, 2014. Ted, Sean, Cullen --_000_7594FB04B1934943A5C02806D1A2204B1D35B9DCESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

A comment (which has been raised before) on draft-ietf-rtcweb-data-= channel-10:

 

The name of the mechanism is "WebRTC Data Channel", and much o= f the text gives a picture that the mechanism is only to be used within the= WebRTC context.

 

If we want to call it "WebRTC Data Channel", we should make it= clear that WebRTC is only one scenario where it can be used, but that it c= an also be used elsewhere. For example, we are using it in CLUE.

 

A few places, where I think we need modifications to reflect it.

 

Section 3:

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

 

Q3_1: s/For general use cases see [I-D.ietf-rtcweb-use-cases-and-require= ments]./For WebRTC use cases see [I-D.ietf-rtcweb-use-cases-and-requirement= s].

 

Q3_2: In sections 3.1 and 3.2, there are a number of WebRTC specific req= uirements, and "PeerConnection", "JavaScript" etc = terminology is used. I think it should be clear that those requirements com= e from WebRTC.

 

 

Section 5:

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

 

Q5_1: I suggest to replace:

    

    "SCTP multihoming will not be used in WebRT= C."

 

...with something like:

 

    "The WebRTC Data Channel mechanism does not= support SCTP multihoming."

 

 

Section 6:

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

 

Q6_1: In section 6.2, the follwoing sentence:

 

  "The SCTP association will be set up when the two endpoints = of the
   WebRTC PeerConnection agree on opening it, as negotiated by JS= EP
   (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]."

 

...only applies to WebRTC. But, it needs to be clear that, in other cont= exts, other mechanisms can be used.

 

 

Q6_2: In section 6.4, I suggest to re-order the paragraphs in the follow= ing way:

 

   "The realization of a bidirectional Data Channel is a = pair of one
   incoming stream and one outgoing SCTP stream having the same s= tream
   SCTP identifier.

   How stream values are selected is protocol and implementation<= br>    dependent.

   Each data channel also has a priority, which is an 2 byte unsi= gned
   integer value.  These priorities MUST be interpreted as w= eighted-
   fair-queuing scheduling priorities per the definition of the    corresponding stream scheduler supporting interleaving in
   [I-D.ietf-tsvwg-sctp-ndata].  For use in WebRTC, the valu= es used
   SHOULD be one of 128 ("below normal"), 256 ("no= rmal"), 512 ("high")
   or 1024 ("extra high").

   The W3C has consensus on defining the application API for WebR= TC
   DataChannels to be bidirectional.  They also consider the= notions of
   in-sequence, out-of-sequence, reliable and unreliable as prope= rties
   of Channels.  One strong wish is for the application-leve= l API to be
   close to the API for WebSockets, which implies bidirectional s= treams
   of data and waiting for onopen to fire before sending, a textu= al
   label used to identify the meaning of the stream, among other = things."

 

...because, the realization is the important part :)

 

Regards,

 

Christer

 

 

 

 

 

From: rtcweb [rtcweb-bounces@ietf.org] on = behalf of Ted Hardie [ted.ietf@gmail.com]
Sent: Tuesday, 10 June, 2014 9:52 PM
To: rtcweb@ietf.org
Subject: [rtcweb] WGLC for data channel drafts

Dear WG,<= br>
This star= ts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please re= view them in detail, especially for areas which may be of concern to the br= oader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen
--_000_7594FB04B1934943A5C02806D1A2204B1D35B9DCESESSMB209erics_-- From nobody Tue Jun 10 14:04:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9761A02E0 for ; Tue, 10 Jun 2014 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXwbAWUKgOSs for ; Tue, 10 Jun 2014 14:04:28 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7EF1A02D8 for ; Tue, 10 Jun 2014 14:04:28 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 5672823F047C; Tue, 10 Jun 2014 23:04:27 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 23:04:26 +0200 From: "Hutton, Andrew" To: Justin Uberti , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPhFJWLG8HUrMMIkSeWeCy2f7KMZtq1WNw Date: Tue, 10 Jun 2014 21:04:26 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17DE927A@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> <5395C7A2.2050706@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PGzn2x7vvBqSafz40D3QuNS7jqg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:04:29 -0000 T246IDA5IEp1bmUgMjAxNCAyMjoxOCBKdXN0aW4gVWJlcnRpIFdyb3RlOg0KDQoNCj4gDQo+IEhv d2V2ZXIsIGlmIHdlIGRlY2lkZSB0aGF0IHRoZSB0cmFuc3BvcnQgdG9rZW4gc2hvdWxkIHJlZmxl Y3QgdGhlIGluLQ0KPiB1c2UgdHJhbnNwb3J0IHByb3RvY29sLCBJIGRvbid0IHRoaW5rIHRoYXQg YWRkcyBhbnkgYWRkaXRpb25hbA0KPiBzaWduYWxpbmcgLSB0aGUgYXBwIGNhbiBhbHJlYWR5IGRl Y2lkZSB3aGV0aGVyIG9yIG5vdCBpdCB3YW50cyB0byBzZW5kDQo+IGFuIHVwZGF0ZWQgb2ZmZXIg d2l0aCB0aGUgY29ycmVjdCBkZWZhdWx0IGNhbmRpZGF0ZSBpbiB0aGUgbS9jIGxpbmVzLg0KPiAN Cg0KVG90YWxseSBhZ3JlZSB0aGF0IGFwcCBuZWVkcyB0byBiZSBpbiBjb250cm9sIG9mIHRoaXMu IElmIHRoZSBhcHAgZG9lcyBub3QgY2FyZSBpdCBzaG91bGQgbm90IGhhdmUgdG8gc2VuZCBhbiB1 cGRhdGVkIG9mZmVyIHRoYXQgd291bGQganVzdCBiZSB2ZXJ5IHdhc3RlZnVsLiBJZiBpdCBkb2Vz IGNhcmUgdGhlbiBpdCBzaG91bGQgYmUgYWJsZSB0byBkZWNpZGUgdG8gc2VuZCB0aGUgdXBkYXRl ZCBvZmZlci4NCg0KQW5keQ0K From nobody Tue Jun 10 14:15:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919E41A02EC for ; Tue, 10 Jun 2014 14:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya0O_eD0uXUn for ; Tue, 10 Jun 2014 14:15:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1611A02E2 for ; Tue, 10 Jun 2014 14:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 368207C3766; Tue, 10 Jun 2014 23:15:43 +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 IzwBHEKEZTfH; Tue, 10 Jun 2014 23:15:42 +0200 (CEST) Received: from android-b42137fce5d2e3ef.home.lan (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2F16A7C3762; Tue, 10 Jun 2014 23:15:42 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----SWDJJZG4PZIFHI2UPT249OV5KI1DGY" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Tue, 10 Jun 2014 23:15:40 +0200 To: Christer Holmberg , "Makaraju, Maridi Raju (Raju)" , Justin Uberti Message-ID: <1bc926a9-1d9f-437d-a29c-6dc79faa3053@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e-ZIErXaa8HhVK3JZyUoZxi7Zes Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:15:48 -0000 ------SWDJJZG4PZIFHI2UPT249OV5KI1DGY Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 On 10. juni 2014 15:52:13 CEST, Christer Holmberg wrote: >Hi Harald, > >>Repeat: >>At the time of SDP negotiation, we have no idea whether a TCP or UDP >candidate will be chosen. The transport token merely serves to verify >that we agree on the transport token. >> >>Renegotiating the transport token because of choices made in ICE is >wasteful and useless. > >I asked this before, and I apologized if I missed your reply: do you >assume that the same port would be used for UDP and TCP? > >If not, you would still have to "renegotiate" due to the port change - >even if the transport token doesn't change. > >Regards, > >Christer Even if you wanted the ports to be the same it is unlikely that you could get them consistently. Port change must be accommodated. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------SWDJJZG4PZIFHI2UPT249OV5KI1DGY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10. juni 2014 15:52:13 CEST, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Harald,

Repeat:
At the time of SDP negotiation, we have no idea whether a TCP or UDP candidate will be chosen. The transport token merely serves to verify that we agree on the transport token.

Renegotiating the transport token because of choices made in ICE is wasteful and useless.

I asked this before, and I apologized if I missed your reply: do you assume that the same port would be used for UDP and TCP?

If not, you would still have to "renegotiate" due to the port change - even if the transport token doesn't change.

Regards,

Christer


Even if you wanted the ports to be the same it is unlikely that you could get them consistently. Port change must be accommodated.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------SWDJJZG4PZIFHI2UPT249OV5KI1DGY-- From nobody Tue Jun 10 14:41:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889611A02E3 for ; Tue, 10 Jun 2014 14:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihETZg_j4Jas for ; Tue, 10 Jun 2014 14:40:55 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3961A0304 for ; Tue, 10 Jun 2014 14:40:55 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id cm18so2601014qab.14 for ; Tue, 10 Jun 2014 14:40:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=jQAGSdJiZBOS5bs6PMrC8o+IBs0q5cuf6CfOl56dPNE=; b=hOkJg7FJDzOMLCFZ5h48ynt4m17QWC4xMDc8avh7XdFd4eyeTnpItRMW5LsyHVO+ln 0dTIQpbT3UMy2RTDahm7ttFHghLwlpHNS7ljvA6JJWkGo9dWCusn+gORSy1Kb9VLqZUI cTSPND+ziVKTGceivyId0HtJ0nioZkoMrFZ3iG+x0I0X8M9gc+rQbZKkDw8vBl8Ep9PL l2SyriAjqKcIKBO60SOfk00HenJzXqqJrC1iNehm+CgpxyvGScnF2afZrDmW7SWfdG26 8bWHLWY/P50B00pZU78AmDUFSDBhsR7W9ilQe+K/daY1mw2Nd2XHHgkn4buUKmGzbqs9 aeQg== X-Gm-Message-State: ALoCoQmyMkr6ekPw/cg4eUvGQ20a8AFBmpq4HDvqnd7o8oiycm3Wpcv4SurNScbfD846UZyQWRTb X-Received: by 10.140.30.70 with SMTP id c64mr42371441qgc.13.1402436454268; Tue, 10 Jun 2014 14:40:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Tue, 10 Jun 2014 14:40:34 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 10 Jun 2014 23:40:34 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/S9P-D7My5osY8P3FRA9M2nbUK8g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:41:00 -0000 2014-06-10 20:03 GMT+02:00 Christer Holmberg : >>> If not, you would still have to "renegotiate" due to the port change - = even if the transport token >>> doesn't change. >> >> There is nothing to re-negotiate at signaling level. What for? > > The m=3D line contains the "transport token" - AND the port number. So you are just quoting what the RFC says ("the SDP must be updated once the stream has a winner ICE candidate"). Some points: - The above does not require AT ALL that a new "SDP renegotiation" is needed. In fact, SDP O/A was previously negotiated for ICE to work. IMHO this is clear. - The ICE RFC states that the SDP must be updated and so on. OK. It is clear (IMHO) that the ICE spec should not mention SDP at all. And we all agree that "sending a new SDP with the updated m/c line" is just required for some QoS, B2BUAs or similar systems, and we all know that this may make sense in certain signaling protocols (SIP and others), but NOT in WebRTC where there is not a defined/mandated "signaling protocol" at all (so in case the app wants to indicate the server its winner ICE candidate it can do that in tons of ways). - And at the end, IMHO it is clear that browser vendors are not going to implement the "SDP update" mentioned in the ICE RFC because they find it not useful (as it clearly is). Regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 10 15:29:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA5A1A0328 for ; Tue, 10 Jun 2014 15:29:27 -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 uk-HWLz5K7Kn for ; Tue, 10 Jun 2014 15:29:24 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B1A1A032B for ; Tue, 10 Jun 2014 15:29:24 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so79670wiw.11 for ; Tue, 10 Jun 2014 15:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=e4qcf4YvRzgHoPFMmgXSIyxDwO1vSqH7mivc5dIDhtE=; b=rb0BBIYej+kVu2cE4i84HMe7PdxQBqFi82U0EfOt3bwJRnz2iV5CdT2kcFDt3w5hEe hf8WH0sh8bodtKpX+4dYmMZLzn8zB5Fc15itWWL1vMrB0mfpCaRDzLFFV/kAnBjHtPMK bv/IOGWUkayl6f+X7WASdC3jAdMYb48k9I8f9gGyzqWZ+I3UrElXX3ODI5LDaVBL7itJ rCMkMxQt3YDfNxdCqkXNewtzdiovDLeGo9WC6zfdMQJYhjMc2BpPEHPgcep+RlcyvxpI 8YC6eJN+sO/b8MW8rpwj1T9/Kq7XJLowa0dD/uBH3qhNnOFjM8l4yWQpScGcxMTxJjEC NusQ== X-Received: by 10.194.80.7 with SMTP id n7mr45617996wjx.8.1402439363045; Tue, 10 Jun 2014 15:29:23 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id di10sm31467013wjb.1.2014.06.10.15.29.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 15:29:22 -0700 (PDT) Message-ID: <539786C7.8090806@gmail.com> Date: Wed, 11 Jun 2014 00:29:27 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jdEWGB_OmO3HYb_Yg9wOriy5bJY Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 22:29:27 -0000 El 10/06/2014 23:40, Iħaki Baz Castillo escribi³: > 2014-06-10 20:03 GMT+02:00 Christer Holmberg : >>>> If not, you would still have to "renegotiate" due to the port change - even if the transport token >>>> doesn't change. >>> There is nothing to re-negotiate at signaling level. What for? >> The m= line contains the "transport token" - AND the port number. > So you are just quoting what the RFC says ("the SDP must be updated > once the stream has a winner ICE candidate"). Some points: > > - The above does not require AT ALL that a new "SDP renegotiation" is > needed. In fact, SDP O/A was previously negotiated for ICE to work. > IMHO this is clear. > > - The ICE RFC states that the SDP must be updated and so on. OK. It is > clear (IMHO) that the ICE spec should not mention SDP at all. And we > all agree that "sending a new SDP with the updated m/c line" is just > required for some QoS, B2BUAs or similar systems, and we all know that > this may make sense in certain signaling protocols (SIP and others), > but NOT in WebRTC where there is not a defined/mandated "signaling > protocol" at all (so in case the app wants to indicate the server its > winner ICE candidate it can do that in tons of ways). > > I found this part of the RFC particular insightful: This begs the question -- why is the updated offer/answer exchange needed at all? Indeed, in a pure offer/answer environment, it would not be. The offerer and answerer will agree on the candidates to use through ICE, and then can begin using them. As far as the agents themselves are concerned, the updated offer/answer provides no new information. Best regards Sergio From nobody Tue Jun 10 16:50:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92EE1A032B for ; Tue, 10 Jun 2014 16:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 8gM4nYzZxAxV for ; Tue, 10 Jun 2014 16:50:20 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFA91A0264 for ; Tue, 10 Jun 2014 16:50:19 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5ANoH3R000903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jun 2014 18:50:17 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s5ANoHZX026310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 19:50:17 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 10 Jun 2014 19:50:17 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPgD7abSYqU+IK/kuiw4z1j/rtWJtgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18IAAXqgAgAAjEjiAAFCFgP//zz3w Date: Tue, 10 Jun 2014 23:50:16 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> In-Reply-To: <539786C7.8090806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/34lTne0nUddTkRYL8sPOCg2vcig Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 23:50:22 -0000 DQo+ICAgICBUaGlzIGJlZ3MgdGhlIHF1ZXN0aW9uIC0tIHdoeSBpcyB0aGUgdXBkYXRlZCBvZmZl ci9hbnN3ZXIgZXhjaGFuZ2UNCj4gICAgIG5lZWRlZCBhdCBhbGw/ICBJbmRlZWQsIGluIGEgcHVy ZSBvZmZlci9hbnN3ZXIgZW52aXJvbm1lbnQsIGl0IHdvdWxkDQo+ICAgICBub3QgYmUuICBUaGUg b2ZmZXJlciBhbmQgYW5zd2VyZXIgd2lsbCBhZ3JlZSBvbiB0aGUgY2FuZGlkYXRlcyB0byB1c2UN Cj4gICAgIHRocm91Z2ggSUNFLCBhbmQgdGhlbiBjYW4gYmVnaW4gdXNpbmcgdGhlbS4gIEFzIGZh ciBhcyB0aGUgYWdlbnRzDQo+ICAgICB0aGVtc2VsdmVzIGFyZSBjb25jZXJuZWQsIHRoZSB1cGRh dGVkIG9mZmVyL2Fuc3dlciBwcm92aWRlcyBubyBuZXcNCj4gICAgIGluZm9ybWF0aW9uLg0KDQpb UmFqdV0gSSBjZXJ0YWlubHkgZG9u4oCZdCB3YW50IHRvIHNvdW5kIGxpa2UgYSBicm9rZW4gcmVj b3JkIO+BiiBidXQgSSBkaWQgcG9zdCByZWFzb25zIGZvciBzdWNoIFNEUCBPL0EuDQpJIGFtIGNv cHlpbmcgdGhhdCBlbWFpbCBoZXJlIGJlbG93LiBJIGFsc28gd2FudCB0byByZXBlYXQgaGVyZSBh Z2FpbiB0aGF0IHRoZSByZXF1aXJlbWVudCB3ZSBpbXBvc2Ugb24gV2ViUlRDIEFQSSBpcyBmb3Ig YnJvd3NlciB0byB1cGRhdGUgdGhlIGxvY2FsIFNEUCBwZXIgc2VsZWN0ZWQgSUNFLWNhbmRpZGF0 ZSBhbmQgbGVhdmUgaXQgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHRvIGRlY2lkZSBvbiBzZW5kaW5n IGEgbmV3IFNEUCBPZmZlciBvciBub3QuIA0KDQo8RWFybGllci1Qb3N0Pg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkNClNlbnQ6 IFR1ZXNkYXksIEp1bmUgMDMsIDIwMTQgOToxNiBBTQ0KDQouLi4NCg0KW1JhanVdIFN1Y2ggYSBu ZXcgU0RQIE8vQSBpcyBuZWVkZWQgZm9yIGNvdXBsZSBvZiByZWFzb25zOg0KMS4gUW9TOiBJdCBp cyB0cnVlIHRoYXQgSUNFIGNsaWVudCBjYW4gZG8gYWxsIGluYmFuZCB3aXRob3V0IGFkZGl0aW9u YWwgU0RQDQpPL0EuDQogICBCdXQgdGhlcmUgbWF5IGJlIG1pZGRsZSBib3hlcyBpbiBiZXR3ZWVu IHRoYXQgbWF5IGFwcGx5IFFvUyBwZXIgdGhlDQpjaGFuZ2VkDQogICBJQ0UgY2FuZGlkYXRlKHMp LiBPbmUgc3VjaCBleGFtcGxlIGlzLCB3aGVuIGdvaW5nIGZyb20gV2lGaSB0byBMVEUgdGhlDQog ICBuZXR3b3JrIG1heSBwcm92aWRlIGJldHRlciBRb1MgdmlhIFBDUkYvUEdXIGRlZGljYXRlZCBi ZWFyZXJzLiBJdCBjYW4NCm9ubHkgZG8NCiAgIHNvIGlmIGl0IGtub3dzIGFib3V0IHRoZSBuZXcg bWVkaWEgZmxvdy4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgbmV3IG1lZGlhDQpmbG93IG1heQ0KICAg Z28gdGhydSBjb21wbGV0ZWx5IG5ldyBuZXR3b3JrIGVsZW1lbnRzIHdobyBtYXkgbm90IGJlIGF3 YXJlIG9mIHRoZSBvbGQNCiAgIGZsb3cgYXQgYWxsLiBZZXMsIG9uZSBjYW4gcHJvdmlkZSBhICJj b3N0bHkiIHNvbHV0aW9uIHRvIHNvbHZlIHRoaXMNCnByb2JsZW0NCiAgIGJ5IHVzaW5nIERQSSAo YW5kL29yIFNETiksIGJ1dCBzdWNoIGEgc29sdXRpb24gaXMgbm90IG9ubHkgY29zdGx5IGJ1dA0K YWxzbyBjb21wbGV4Lg0KICAgSU1ITywgd2VicnRjIHNob3VsZCBmYWNpbGl0YXRlIGFjaGlldmlu ZyBuZWNlc3NhcnkgUW9TIGRlc2lyZWQgZm9yDQpzZXNzaW9ucw0KICAgaW4gdGhlIG5ldHdvcmsu IFdoaWxlIGRvaW5nIHNvLCBJIGRvbid0IHNlZSBhbnkgZnVuY3Rpb25hbGl0eSBiZWluZyBsb3N0 DQphdA0KICAgV2ViUlRDLCByYXRoZXIgaXQncyBhIGdhaW4gYW5kIGdyZWF0ZXIgYWRhcHRpb24g b2YgV2ViUlRDLg0KDQogICBGb3IgdGhlIHNhbWUgcmVhc29uLCBJIGFsc28gYWdyZWUgd2l0aCB0 aGUgY29tbWVudCB0aGF0LCBhIG5ldyBTRFAgTy9BDQptdXN0IGJlIHNlbnQNCiAgIGlmIHRoZSBz ZWxlY3RlZCBjYW5kaWRhdGUgaXMgbm90IHRoZSBvbmUgbGlzdGVkIGluIGMvbT0gbGluZXMuDQog ICBXZWJSVEMgc2hvdWxkIG5vdCBhc3N1bWUgdGhhdCBtaWRkbGUgYm94ZXMgZG9uJ3QgZXhpc3Qu IE1pZGRsZSBib3hlcyBkbw0KZXhpc3QgZm9yDQogICBWZXJ5IHZhbGlkIHJlYXNvbnMgKG5vdCBq dXN0IFNJUC9JTVMsIHdoaWNoIGlzIG9ubHkgb25lIGV4YW1wbGUpLg0KRXNwZWNpYWxseSB3aXRo DQogICB0aGUgdHJlbmQgdG93YXJkcyBTRE4sIHRoZSBjb250cm9sIHBsYW5lIGFuZCBkYXRhL3Vz ZXIgcGxhbmUgYXJlIGJlaW5nDQpzZXBhcmF0ZWQNCiAgIGZvciBnb29kIGFuZCB0aGUgY29udHJv bCBwbGFuZSBuZWVkcyB0cmlnZ2VycyB0byByZWNvbmZpZ3VyZSB0aGUgbmV0d29yaw0KZm9yIGJl dHRlcg0KICAgUW9TLiBTZW5kaW5nIG5ldyBPL0EgKHBsZWFzZSBkbyBub3QgZXF1YXRlIHRoaXMg dG8gU0lQLCBpdCBjYW4gYmUgYW55DQpzaWduYWxpbmcNCiAgIHByb3RvY29sIGFuZCBldmVuIG5v dCBuZWNlc3NhcmlseSBTRFAgZm9ybWF0KSBhY2hpZXZlcyB0aGF0Lg0KDQoyLiBSZXNvdXJjZSBh bGxvY2F0aW9uIGF0IG1pZGRsZSBib3hlcw0KICAgSW4gY2FzZXMgbGlrZSBjaGFuZ2luZyB0cmFu c3BvcnQgKG5vdCBuZWNlc3NhcmlseSBhY2Nlc3MgbmV0d29yayBjaGFuZ2UpDQogICBmcm9tIFVE UCB0byBUQ1Agb3IgdmljZS12ZXJzYSwgaXQgaXMgaGlnaGx5IGRlc2lyYWJsZSB0byBoYXZlIGEg bmV3IFNEUA0KTy9BLg0KICAgV2l0aG91dCBzdWNoIG9mZmVyLCBpdCBpcyBhIGh1Z2UgYnVyZGVu IG9uIG1pZGRsZSBib3hlcyB0byBiZSBwcmVwYXJlZA0KICAgZm9yIGFueSBraW5kIG9mIG1pZC1z ZXNzaW9uIHRyYW5zcG9ydCAoVURQIG9yIFRDUCkgY2hhbmdlcy4gTWlkZGxlIGJveGVzDQpjYW4N CiAgIGhhdmUgY29tcGxleCBsb2dpYyB0byByZXNlcnZlIGFsbCBwb3NzaWJsZSByZXNvdXJjZXMg YW5kIGtlZXAgdGhlbSBmb3INCmFueQ0KICAgZnV0dXJlIG1pZC1zZXNzaW9uIGNoYW5nZXMgd2l0 aG91dCBuZXcgU0RQIE8vQS4gQWdhaW4sIGl0J3Mgbm90IG9ubHkNCmluZWZmaWNpZW50DQogICBi dXQgYWxzbyBtYWtlcyBtaWRkbGUgYm94ZXMgbG9naWMgY29tcGxpY2F0ZWQuIEFsc28sIGFzIHBv aW50ZWQgYnkgRW1pbA0KSXZvdiwNCiAgIElDRSBSRkMgc2F5cyB5b3UgTUFZIGZyZWUgcmVtYWlu aW5nIGNhbmRpZGF0ZXMgb25jZSBJQ0UgaXMgY29tcGxldGVkLg0KRXZlbiBpZg0KICAgYW4gaW1w bGVtZW50YXRpb24gd2FudHMgdG8ga2VlcCBBTEwgdGhlIGNhbmRpZGF0ZXMgZXZlbiBhZnRlciBJ Q0UgaXMNCmNvbXBsZXRlZCwNCiAgIGl0IGNhbid0IGV4cGVjdCB0aGUgcGVlciB0byBkbyB0aGUg c2FtZSwgZXNwZWNpYWxseSBpY2UgbGl0ZQ0KaW1wbGVtZW50YXRpb25zDQogICB0eXBpY2FsbHkg d29uJ3Qga2VlcCB0aGUgcmVtYWluaW5nIGNhbmRpZGF0ZXMuDQoNCg0KQlINClJhanUNCjwvRWFy bGllci1Qb3N0Pg0KDQpCUg0KUmFqdQ0K From nobody Tue Jun 10 23:40:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D3D1A064A for ; Tue, 10 Jun 2014 23:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVSZWFoUM5bu for ; Tue, 10 Jun 2014 23:40:49 -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 BA7731A063F for ; Tue, 10 Jun 2014 23:40:48 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-cc-5397f9ee2274 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.1A.28642.EE9F7935; Wed, 11 Jun 2014 08:40:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 11 Jun 2014 08:40:46 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPf2EzJJwwfinVzkSeFUWi1HOIo5tgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18P//+84AgABKgpqAABttAIAAtycg Date: Wed, 11 Jun 2014 06:40:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D35C219@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@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+NgFupkkeLIzCtJLcpLzFFi42KZGfG3Rvf9z+nBBounM1oc6+tis5i+z8Zi 61Qhi4aNV1gt1v5rZ3dg9Wh9tpfV41zDe3aPKxOusHos2FTqsWTJT6YA1igum5TUnMyy1CJ9 uwSujD9v5zEVnBGpePZlF3MDY4dIFyMnh4SAicT59m+sELaYxIV769m6GLk4hASOMkqsXrWW FcJZzCjRerGbpYuRg4NNwEKi+582SIOIgI3EvwsX2EFqmAX2MEo8/rwIbJKwQJhEc8djRoii cIlF0yczgxSJCDQxSnzc+wmsiEVAVWLV388sIDavgK/EpZVHoba1ckhcfXiWDSTBKRAoce7A DHYQmxHovu+n1jCB2MwC4hK3nsxngrhbQGLJnvPMELaoxMvH/6D+UZTYebadGeRqZgFNifW7 9CFaFSWmdD9kh9grKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxihanFhfnphsZ6aUWZSYX F+fn6eWllmxiBMbdwS2/rXYwHnzueIhRgINRiYd3gfv0YCHWxLLiytxDjNIcLErivBc1qoOF BNITS1KzU1MLUovii0pzUosPMTJxcEo1MFbHbfb8xq2n95nr3wNulw1rv1f5zrSzj5zQqvTy JXv4aTGGX22P3pjuv/H4SxrLx/cClydpRs35vdq6sGVH7a8dvn/WnHsqEMy9xNtmX3mabvfv PYWzD1w4OfXP4cXLtf0NY8srK9Lb7u94fdh6n6lQlGzAHg7pZZMYbmdxz/pd4cFS4Fzfd1CJ pTgj0VCLuag4EQC71H5MnAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0ioOQsmi_pzd_UifmBsHwc3LBJQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 06:40:50 -0000 SGksDQoNCj4+Pj4gSWYgbm90LCB5b3Ugd291bGQgc3RpbGwgaGF2ZSB0byAicmVuZWdvdGlhdGUi IGR1ZSB0byB0aGUgcG9ydCBjaGFuZ2UgDQo+Pj4+IC0gZXZlbiBpZiB0aGUgdHJhbnNwb3J0IHRv a2VuIGRvZXNuJ3QgY2hhbmdlLg0KPj4+DQo+Pj4gVGhlcmUgaXMgbm90aGluZyB0byByZS1uZWdv dGlhdGUgYXQgc2lnbmFsaW5nIGxldmVsLiBXaGF0IGZvcj8NCj4+DQo+PiBUaGUgbT0gbGluZSBj b250YWlucyB0aGUgInRyYW5zcG9ydCB0b2tlbiIgLSBBTkQgdGhlIHBvcnQgbnVtYmVyLg0KPg0K PiBTbyB5b3UgYXJlIGp1c3QgcXVvdGluZyB3aGF0IHRoZSBSRkMgc2F5cyAoInRoZSBTRFAgbXVz dCBiZSB1cGRhdGVkIG9uY2UgdGhlIHN0cmVhbSBoYXMgYSB3aW5uZXIgSUNFIGNhbmRpZGF0ZSIp LiANCg0KQ29ycmVjdC4gQW5kLCB0aGUgcmVhc29uIGZvciB0aGF0IGlzIGJlY2F1c2Ugd2UgaGF2 ZSBtYWRlIGEgZGVjaXNpb24gdG8gdXNlIHRoZSBtZWNoYW5pc20gZGVmaW5lZCBpbiB0aGUgUkZD Lg0KDQo+IFNvbWUgcG9pbnRzOg0KPg0KPiAtIFRoZSBhYm92ZSBkb2VzIG5vdCByZXF1aXJlIEFU IEFMTCB0aGF0IGEgbmV3ICJTRFAgcmVuZWdvdGlhdGlvbiIgaXMgbmVlZGVkLiBJbiBmYWN0LCBT RFAgTy9BIHdhcyBwcmV2aW91c2x5IG5lZ290aWF0ZWQgZm9yIElDRSB0byB3b3JrLg0KPiBJTUhP IHRoaXMgaXMgY2xlYXIuDQo+DQo+IC0gVGhlIElDRSBSRkMgc3RhdGVzIHRoYXQgdGhlIFNEUCBt dXN0IGJlIHVwZGF0ZWQgYW5kIHNvIG9uLiBPSy4gSXQgaXMgY2xlYXIgKElNSE8pIHRoYXQgdGhl IElDRSBzcGVjIHNob3VsZCBub3QgbWVudGlvbiBTRFAgYXQgYWxsLiBBbmQgd2UgYWxsIGFncmVl IHRoYXQgInNlbmRpbmcgYSBuZXcgU0RQIHdpdGggdGhlIHVwZGF0ZWQgbS9jIGxpbmUiIGlzIGp1 c3QgcmVxdWlyZWQgZm9yIHNvbWUgUW9TLCANCj4gQjJCVUFzIG9yIHNpbWlsYXIgc3lzdGVtcywg YW5kIHdlIGFsbCBrbm93IHRoYXQgdGhpcyBtYXkgbWFrZSBzZW5zZSBpbiBjZXJ0YWluIHNpZ25h bGluZyBwcm90b2NvbHMgKFNJUCBhbmQgb3RoZXJzKSwgYnV0IE5PVCBpbiBXZWJSVEMgd2hlcmUg dGhlcmUgaXMgbm90IGEgZGVmaW5lZC9tYW5kYXRlZCAic2lnbmFsaW5nIHByb3RvY29sIiBhdCBh bGwgKHNvIGluIGNhc2UgdGhlIGFwcCB3YW50cyB0byANCj4gaW5kaWNhdGUgdGhlIHNlcnZlciBp dHMgd2lubmVyIElDRSBjYW5kaWRhdGUgaXQgY2FuIGRvIHRoYXQgaW4gdG9ucyBvZiB3YXlzKS4N Cg0KSSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJOT1QgaW4gV2ViUlRDIi4gSSBjYW4g dXNlICJjZXJ0YWluIHNpZ25hbGluZyBwcm90b2NvbHMiIHdpdGggV2ViUlRDLg0KDQo+IC0gQW5k IGF0IHRoZSBlbmQsIElNSE8gaXQgaXMgY2xlYXIgdGhhdCBicm93c2VyIHZlbmRvcnMgYXJlIG5v dCBnb2luZyB0byBpbXBsZW1lbnQgdGhlICJTRFAgdXBkYXRlIiBtZW50aW9uZWQgaW4gdGhlIElD RSBSRkMgYmVjYXVzZSB0aGV5IGZpbmQgaXQgbm90IHVzZWZ1bCAoYXMgaXQgY2xlYXJseSBpcyku DQoNCkpTRVAgaXMgYmFzZWQgb24gb2ZmZXIvYW5zd2VyLCAgYW5kIGEgcyB3ZSBoYXZlIGRpc2N1 c3NlZCBiZWZvcmUsIGFsbCB0aGUgYnJvd3NlciBuZWVkcyB0byBkbyBpcyB0byBpbmZvcm0gdGhl IEpTIEFwcCBhYm91dCB0aGUgdXBkYXRlLCBhbmQgdGhlIEpTIEFwcCBjYW4gdGhlbiBkbyB3aGF0 ZXZlciB0aGV5IHdhbnQuDQoNClRoZSBwb2ludCBvZiBteSBjb21tZW50IHdhcyB0aGF0IHJlbW92 aW5nICJVRFAiIGZyb20gdGhlIHByb3RvY29sIHRva2VuIGRvZXMgbm90IGF1dG9tYXRpY2FsbHkg ZW5zdXJlIHRoYXQgdGhlIG09IGxpbmUgaXMgYWx3YXlzIHVwIHRvIGRhdGUsIGFzIHRoZSBwb3J0 IG1heSBhbHNvIGNoYW5nZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Wed Jun 11 04:26:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FA61B2865 for ; Wed, 11 Jun 2014 04:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 KJrt2ZlhEve5 for ; Wed, 11 Jun 2014 04:25:45 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8111B2866 for ; Wed, 11 Jun 2014 04:25:44 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5BBPggW000130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2014 06:25:42 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s5BBPgeN028005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 07:25:42 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 11 Jun 2014 07:25:42 -0400 From: "Makaraju, Maridi Raju (Raju)" To: =?utf-8?B?SmF2aWVyIENlcnZpw7Fv?= Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPgD7abSYqU+IK/kuiw4z1j/rtWJtgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18IAAXqgAgAAjEjiAAFCFgP//zz3wgAEAN4D//8KCkA== Date: Wed, 11 Jun 2014 11:25:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D34FCBA@ESESSMB209.ericsson.se> <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HPtIdRDeioomKhJg_iCx9VSWm-I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 11:25:47 -0000 PkknbSBKYXZpZXIgQ2VydmnDsW8sIG1lbWJlciBvZiB0aGUgdGVhbSB0aGF0IGlzIGltcGxlbWVu dGluZyBMaWNvZGUncyBNQ1UgPihodHRwOi8vbHluY2tpYS5jb20pLiBJbiBvdXIgY2FzZSB3ZSdy ZSBkb2luZyBzb21lIGV4cGVyaW1lbnRzIGV4YWN0bHkgaW4gdGhlIHRlcm1zID55b3UncmUgbWVu dGlvbiBpbiB0aGUgdGhyZWFkLiBJbiBvdXIgY2FzZSB3ZSdyZSBxdWl0ZSBpbnRlcmVzdGVkIGlu IE1DVSBtb2JpbGl0eSA+YmV0d2VlbiBzZXJ2ZXIgdG8gc2NhbGUgdXAgYW5kIGRvd24gdGhlIHNl cnZpY2UuIEl0J3MgY3J1Y2lhbCBmb3IgdGhpcyBwdXJwb3NlIG5vdCB0byA+ZXhjaGFuZ2UgYWRk aXRpb25hbCBPZmZlci9BbnN3ZXIgbWVzc2FnZXMgYW5kIG5vdCB0byBnYXRoZXIgYWdhaW4gbmV3 IGNhbmRpZGF0ZXMgaW4gPnRoZSBjbGllbnQgc2lkZS4NCsKgDQpbUmFqdV0gV2UgYXJlIE5PVCB0 YWxraW5nIGFib3V0IG5ldyBjYW5kaWRhdGUgZ2F0aGVyaW5nIGhlcmUuIA0KUGxlYXNlIHNlZSBl eHBsYW5hdGlvbiBiZWxvdy4NCg0KPlJhanUsIGZvciBleGFtcGxlLCBpbiBjYXNlIG9mIGNsaWVu dCBvciBNQ1UgbW9iaWxpdHksIHdlIGRvbid0IG5lZWQgdG8gZXhjaGFuZ2UgbWVkaWEgPmluZm8g YWdhaW4sIGFzIGl0IHdpbGwgYmUgZXhhY3RseSB0aGUgc2FtZS4gSW4gb3VyIGNhc2Ugd2Ugb25s eSB3YW50IHRvIHByb3BhZ2F0ZSBuZXcgPklDRSBjYW5kaWRhdGVzIHRvIHJlY2hlY2sgd2l0aCBJ Q0UgaWYgdGhlcmUgaXMgYSBkaWZmZXJlbnQgdmFsaWQgcGFpci4gwqBCdXQgSSB0aGluayA+dGhl IHNvbHV0aW9ucyBjb21tZW50ZWQgaW4gdGhlIHRocmVhZCBhcmUgc3RpbGwgY29tcGF0aWJsZSB3 aXRoIHlvdXIgaWRlYS4gQXMgbG9uZyBhcyA+dGhlIGZpcnN0IG9mZmVyL2Fuc3dlciBtZXNzYWdl cyBhcmUgc3RpbGwgdmFsaWQgeW91IGNvdWxkIHNlbmQgdGhlbSBhZ2FpbiB3aXRoIHRoZSA+bmV3 IGNhbmRpZGF0ZXMgdG8gdGhlIG1pZGRsZSBib3hlcyBpZiB5b3UgbmVlZCBpdC4NCg0KW1JhanVd IA0KSGkgSmF2aWVyLCBUaGFua3MgZm9yIGV4cGxhaW5pbmcgeW91ciBNQ1UgdXNlIGNhc2VzLg0K SSB3YW50ZWQgdG8gYXNzZXJ0IGFnYWluIHRoYXQsIEkgYW0gbm90IGFkdm9jYXRpbmcgZm9yIGFu IGF1dG9tYXRpYyBuZXcgU0RQIE8vQS4gV2UgbmVlZCB0byBzZXBhcmF0ZSB1cGRhdGluZyBsb2Nh bCBTRFAgZnJvbSBnZW5lcmF0aW5nIG5ldyBTRFAgb2ZmZXIuIFRoZSBmb3JtZXIgaGFzIHRvIGJl IGRvbmUgYnkgYnJvd3NlciBhbmQgdGhlIGxhdHRlciBpcyB1cCB0byB0aGUgYXBwbGljYXRpb24g YW5kIGZhbGxzIGludG8gc2lnbmFsaW5nICh3aGljaCB3ZWJydGMgaGFzIGxlZnQgdG8gYXBwbGlj YXRpb25zKS4NCkF0IGEgdmVyeSBoaWdoLWxldmVsLCB0aGlzIGlzIGhvdyB0aGUgZmxvdyBsb29r cyBsaWtlOg0KMS4gV2hlbiBJQ0UgaXMgY29tcGxldGVkLCBicm93c2VyIHdpbGwgdXBkYXRlIGxv Y2FsIFNEUCANCiAgIGMvbT0gbGluZXMgd2l0aCBzZWxlY3RlZCBjYW5kaWRhdGUgZm9yOg0KICAg YS4gTG9jYWwgSVAsIHBvcnQNCiAgIGIuIE1hdGNoaW5nIHRyYW5zcG9ydCAob3IgdG8gaW5kaWNh dGUgdGhlIHRyYW5zcG9ydCANCiAgICAgIHNlbGVjdGVkLiBUQ1Agb3IgVURQKS4gDQoyLiBCcm93 c2VyIGNhbGxzIGFuIEFQSSAoVEJEKSBsaWtlIG9uaWNlY2FuZGlkYXRlKE5VTEwpIA0KICAgdG8g aW5kaWNhdGUgZW5kIG9mIElDRS4NCg0KQXQgdGhpcyBwb2ludCBpdCBpcyB1cCB0byB0aGUgYXBw bGljYXRpb24gdG8gdXNlIHRoaXMgdHJpZ2dlciANCnRvIHNlbmQgYW4gdXBkYXRlZCBvZmZlciBv ciBub3QuIEF0IHRoaXMgc3RlcCwgd2UgYXJlIA0KTk9UIHRhbGtpbmcgYWJvdXQgSUNFIHJlc3Rh cnQgb3IgbmV3IGNhbmRpZGF0ZSBnYXRoZXJpbmcgZXRjLg0KDQpCUg0KcmFqdQ0KICAgDQo= From nobody Wed Jun 11 04:42:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8BF1B2869 for ; Wed, 11 Jun 2014 04:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FkynIv14bsM for ; Wed, 11 Jun 2014 04:41:20 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181A01B2864 for ; Wed, 11 Jun 2014 04:41:19 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so2111858wes.4 for ; Wed, 11 Jun 2014 04:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=xrwrJxSuJkkHB0N+LcP62OWSBx98EN/4CujMcbR+lkY=; b=LAGZnBk1FWlocd6e+RSFXFmZNOUzMqvNLgg4p4DS3kCSd2If0jhdfjEYO5J+sq6dpP j+5CcuUwIpTfK6WVn27kCtrWtmSmgHasdocQnabcEX9xSV4dyquf7unMdsC7O+k/hIzA o/zauciwwD97cOfGJFKnPNggF4L4X+X/+1axrXdHtSnG6A1yY0RGQjrOSkQ+UfoEzKS/ DkScjSBiAIX0g2nsQ9ft4NqEleZmUMb1fdE1/kCWxa1yNcFShXSL9LJYBh6tCanQmSlz gUv+RZ7pWc2KwAgYqciP57VTEOaHxPmU9iyTavV2ekCCsIa/+eE+yy4sNIgAF8IXLGZg 1x/A== X-Received: by 10.194.179.9 with SMTP id dc9mr51283918wjc.74.1402486878323; Wed, 11 Jun 2014 04:41:18 -0700 (PDT) Received: from [192.168.1.39] (207.Red-79-146-136.dynamicIP.rima-tde.net. [79.146.136.207]) by mx.google.com with ESMTPSA id bq7sm22100079wib.7.2014.06.11.04.41.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 04:41:17 -0700 (PDT) Message-ID: <53984062.1090202@gmail.com> Date: Wed, 11 Jun 2014 13:41:22 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , =?UTF-8?B?SmF2aWVyIENlcnZpw7Fv?= References: <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040803070701000203050202" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pzPNFpfXD1gHr31F6DosgUwEP0I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 11:41:21 -0000 This is a multi-part message in MIME format. --------------040803070701000203050202 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 11/06/2014 13:25, Makaraju, Maridi Raju (Raju) escribi³: >> Raju, for example, in case of client or MCU mobility, we don't need to exchange media >info again, as it will be exactly the same. In our case we only want to propagate new >ICE candidates to recheck with ICE if there is a different valid pair. But I think >the solutions commented in the thread are still compatible with your idea. As long as >the first offer/answer messages are still valid you could send them again with the >new candidates to the middle boxes if you need it. > [Raju] > Hi Javier, Thanks for explaining your MCU use cases. > I wanted to assert again that, I am not advocating for an automatic new SDP O/A. We need to separate updating local SDP from generating new SDP offer. The former has to be done by browser and the latter is up to the application and falls into signaling (which webrtc has left to applications). > At a very high-level, this is how the flow looks like: > 1. When ICE is completed, browser will update local SDP > c/m= lines with selected candidate for: > a. Local IP, port > b. Matching transport (or to indicate the transport > selected. TCP or UDP). > 2. Browser calls an API (TBD) like onicecandidate(NULL) > to indicate end of ICE. Isn't (2) already defined in current api with |oniceconnectionstatechange|with state "connected" ? Maybe it would be interesting to also add the selected candidate in the event as I see it useful for applications. As a side note, is anyone using ICE TCP at all? Given that we already support TURN over TCP/TLS, is it useful for anyone? As I see it it is only useful for servers, but locating a TURN server near it would do the same trick. Best regards Sergio --------------040803070701000203050202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
El 11/06/2014 13:25, Makaraju, Maridi Raju (Raju) escribi³:
Raju, for example, in case of client or MCU mobility, we don't need to exchange media >info again, as it will be exactly the same. In our case we only want to propagate new >ICE candidates to recheck with ICE if there is a different valid pair.  But I think >the solutions commented in the thread are still compatible with your idea. As long as >the first offer/answer messages are still valid you could send them again with the >new candidates to the middle boxes if you need it.

[Raju] 
Hi Javier, Thanks for explaining your MCU use cases.
I wanted to assert again that, I am not advocating for an automatic new SDP O/A. We need to separate updating local SDP from generating new SDP offer. The former has to be done by browser and the latter is up to the application and falls into signaling (which webrtc has left to applications).
At a very high-level, this is how the flow looks like:
1. When ICE is completed, browser will update local SDP 
   c/m= lines with selected candidate for:
   a. Local IP, port
   b. Matching transport (or to indicate the transport 
      selected. TCP or UDP). 
2. Browser calls an API (TBD) like onicecandidate(NULL) 
   to indicate end of ICE.

Isn't (2) already defined in current api with oniceconnectionstatechange with state "connected" ? Maybe it would be interesting to also add the selected candidate in the event as I see it useful for applications.

As a side note, is anyone using ICE TCP at all? Given that we already support TURN over TCP/TLS, is it useful for anyone? As I see it it is only useful for servers, but locating a TURN server near it would do the same trick.

Best regards
Sergio
 --------------040803070701000203050202-- From nobody Wed Jun 11 05:08:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7F41A03ED for ; Wed, 11 Jun 2014 05:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 bNBijf9jsoUg for ; Wed, 11 Jun 2014 05:08:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE11C1A0380 for ; Wed, 11 Jun 2014 05:08:21 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5BC8IaG002618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2014 07:08:19 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s5BC8IcJ029444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 08:08:18 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 11 Jun 2014 08:08:18 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Sergio Garcia Murillo , =?utf-8?B?SmF2aWVyIENlcnZpw7Fv?= Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPgD7abSYqU+IK/kuiw4z1j/rtWJtgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18IAAXqgAgAAjEjiAAFCFgP//zz3wgAEAN4D//8KCkIAAS0wA//+9FvA= Date: Wed, 11 Jun 2014 12:08:18 +0000 Message-ID: References: <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> In-Reply-To: <53984062.1090202@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bS5guvQL5tnAtijuH-WLWtpcvAE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:08:24 -0000 DQo+SXNuJ3QgKDIpIGFscmVhZHkgZGVmaW5lZCBpbiBjdXJyZW50IGFwaSB3aXRoIG9uaWNlY29u bmVjdGlvbnN0YXRlY2hhbmdlIHdpdGggc3RhdGUgPiJjb25uZWN0ZWQiID8gTWF5YmUgaXQgd291 bGQgYmUgaW50ZXJlc3RpbmcgdG8gYWxzbyBhZGQgdGhlIHNlbGVjdGVkIGNhbmRpZGF0ZSBpbiB0 aGUgPmV2ZW50IGFzIEkgc2VlIGl0IHVzZWZ1bCBmb3IgYXBwbGljYXRpb25zLg0KDQpbUmFqdV0g KDIpIGlzIGRvbmUgYXQgdGhlIHRpbWUgb2YgSUNFIGdhdGhlcmluZywgd2hpY2ggaGFwcGVucyBi ZWZvcmUgaW5pdGlhbCBvZmZlciBpcyBzZW50IG91dC4gQnV0LCB3ZSBuZWVkIGEgdHJpZ2dlciB3 aGVuIElDRSBpcyBjb21wbGV0ZWQsIHdoaWNoIGhhcHBlbnMgYWZ0ZXIgaW5pdGlhbCBPL0EgaXMg Y29tcGxldGVkLg0KDQpUcmlja2xlIElDRSAoZHJhZnQtaWV0Zi1tbXVzaWMtdHJpY2tsZS1pY2Ut MDEpIGlzIGFub3RoZXIgcG93ZXJmdWwgdXNlIGNhc2Ugb2YgbGVhdmluZyBTRFAgTy9BIHRvIGFw cGxpY2F0aW9uLCBidXQgcHJvdmlkZSBBUElzIChvbmljZWNhbmRpZGF0ZSwgYWRkaWNlY2FuZGlk YXRlKSBmb3IgdGhlbSB0byBhY2hpZXZlIHRoZWlyIG5lZWRzLiBUcmlja2xlIElDRSBpcyBwb3Nz aWJsZSBiZWNhdXNlIGJyb3dzZXIgZ2l2ZXMgSUNFIGNhbmRpZGF0ZXMgdG8gYXBwIGFzIHRoZXkg YXJlIGRpc2NvdmVyZWQuIE1vc3QgYXBwcyBqdXN0IG5lZWQgdG8ga25vdyBvbmx5IHdoZW4gZ2F0 aGVyaW5nIGlzIGNvbXBsZXRlZC4gQnV0IHNvbWUgZGVsYXkgY29uc2Npb3VzIGFwcHMgY2FuIG1h a2UgdXNlIG9mIHRoZXNlIGNhbmRpZGF0ZXMgdG8gcGVyZm9ybSB0cmlja2xlIElDRS4gDQpJTU8s IGFza2luZyBmb3IgZW5kIG9mIElDRSB0cmlnZ2VyIGFuZCB1cGRhdGluZyBjL209IGxpbmVzIGZh bGxzIGluIHRvIHRoZSBzYW1lIGNhdGVnb3J5IHRoYXQgaXMgYWxyZWFkeSBhbGxvd2VkIGJ5IHRo ZSBBUElzLg0KDQo+QXMgYSBzaWRlIG5vdGUsIGlzIGFueW9uZSB1c2luZyBJQ0UgVENQIGF0IGFs bD8gR2l2ZW4gdGhhdCB3ZSBhbHJlYWR5IHN1cHBvcnQgVFVSTiA+b3ZlciBUQ1AvVExTLCBpcyBp dCB1c2VmdWwgZm9yIGFueW9uZT8gQXMgSSBzZWUgaXQgaXQgaXMgb25seSB1c2VmdWwgZm9yIHNl cnZlcnMsIGJ1dCA+bG9jYXRpbmcgYSBUVVJOIHNlcnZlciBuZWFyIGl0IHdvdWxkIGRvIHRoZSBz YW1lIHRyaWNrLg0KDQpbUmFqdV0NClRVUk4gaW52b2x2ZXMgYW4gYWRkaXRpb25hbCBlbGVtZW50 IGluIHRoZSBuZXR3b3JrIGFuZCBiZWFyZXIgcGF0aDsgYXMgYSByZXN1bHQgdG8gcmVkdWNlIFRV Uk4gY29zdHMgYW5kIGJlYXJlciBkZWxheSwgdXNpbmcgSUNFLVRDUCBpcyBhZHZpc2VkLg0KZHJh ZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0wNCBzYXlzOg0KICAgIklDRS1UQ1AgY2FuZGlkYXRl cyBbUkZDNjU0NF0gTVVTVCBiZSBzdXBwb3J0ZWQ7IHRoaXMgbWF5IGFsbG93DQogICBhcHBsaWNh dGlvbnMgdG8gY29tbXVuaWNhdGUgdG8gcGVlcnMgd2l0aCBwdWJsaWMgSVAgYWRkcmVzc2VzIGFj cm9zcw0KICAgVURQLWJsb2NraW5nIGZpcmV3YWxscyB3aXRob3V0IHVzaW5nIGEgVFVSTiBzZXJ2 ZXIuIg0KDQpCUg0KUmFqdQ0KDQoNCg== From nobody Wed Jun 11 05:18:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FC81B286D for ; Wed, 11 Jun 2014 05:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwHmyMfzFmP8 for ; Wed, 11 Jun 2014 05:18:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id B5C071B2883 for ; Wed, 11 Jun 2014 05:18:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 264627C3782; Wed, 11 Jun 2014 14:17:59 +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 g03nYq4LpgJG; Wed, 11 Jun 2014 14:17:57 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5BFA57C3773; Wed, 11 Jun 2014 14:17:57 +0200 (CEST) Message-ID: <539848F3.4090103@alvestrand.no> Date: Wed, 11 Jun 2014 14:17:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eduardo Gueiros , rtcweb@ietf.org References: <538FB362.1070109@jive.com> In-Reply-To: <538FB362.1070109@jive.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/enzNokFpr6fAdsLPvnQbRC_Qk1M Subject: Re: [rtcweb] review [draft-ietf-rtcweb-transports] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:18:04 -0000 On 06/05/2014 02:01 AM, Eduardo Gueiros wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Some thoughts/suggestions on [draft-ietf-rtcweb-transports-04] that > perhaps could help making it more clear. Thanks for the feedback! > > - -- > 1. Paragraph 1, 2, and 3. > > Introduction seems to give fragmented information about this document > [draft-ietf-rtcweb-transports] and the general RTCWEB effort. At times > I don’t > know to which the introduction is referring to. Consider giving that > information in distinct ways. Suggestion: > > - - The IETF RTCWEB effort is aimed at specifying a protocol suite that > is useful for real time multimedia exchange between clients. This > protocol suite is designed for WebRTC and intents to satisfy the > security considerations described in the WebRTC security documents > [document link]. > - - The IEFT RTCWEB effort is part of the WebRTC cooperation between the > IETF and W3C. The overall effort is described in WebRTC Overview > document, [document link]. I'm not sure that helps. But we should make it shorter. I'm removing the whole effort description, because it's irrelevant to this document - especially when the RFC is published, and the effort is concluded. > > 1. Paragraph 2, 2nd sentence > > “This document focuses on the dataâ€Ĥ” - To me it’s not clear which > document you’re referring to; the one it was just cited, or this > document [draft-ietf-rtcweb-transports]. I think this is clear enough - if it had pointed to the other document, it would have said "that document". > > > 3.2. 2nd paragraph > “When TURN is used, and the TURN server has IPv4 or IPv6 connectivity > to the peer or its TURN server, candidates of the appropriate types > MUST be supported.” > > This could be simplified to “When TURN is used, if the server or the > peer has IPv4 or IPv6 connectivity, candidates of the appropriate > types MUST be supported.” I don't think the proposed sentence is correct, because it doesn't say what the server or the peer has to have connectivity to. The following cases exist (at least) where IPv6 candidates are required: Client --IPv4-> TURN server --IPv6-> Peer Client --IPv6-> TURN server --IPv6-> Peer Client --IPv4-> Client TURN server --IPv6-> Peer TURN server -IPv4 -> Peer However, in the following scenario, IPv6 candidates are NOT required: Client --IPv6-> TURN server --IPv4->Peer Because even though the TURN server has wonderful IPv6 connectivity, it doesn't have IPv6 connectivity to the peer or the peer's TURN server. > > 3.4, 1st Paragraph > > Avoid contraction in formal writing, change “it’s” to “it is” 45 "it's" in the last 250 RFCs, and 2227 "it is". Non-contractions win. (There doesn't seem to be any such written rule) > > 3.4, 2nd Paragraph > > “this allows interworking with bothâ€Ĥ” A clearer sentence would read: > “a full implementation allows interworking with bothâ€Ĥ” Done. > > 3.4 3rd Paragraph > > missing comma after “NATs” It's not supposed to be there. The sentence parses as "behind (NATs which perform endpoint-dependent mapping), TURN MUST be supported" There are lots of NATs that don't perform endpoint-dependent mapping. Changed to "NATs of the type that perform endpoint-dependent mapping". > > 3.4 5th Paragraph > > missing commas “â€ĤTURN [comma] using TCP between the client and server > [comma] MUST be supported.” Again, this would change the meaning to a claim that TURN always uses TCP, which is false. Rephrased as "the mode of TURN that uses TCP .... MUST be supported". > > The sentence could also be rewritten, for clarification, as: “TURN > MUST be supported when using TCP between the client and the server in > order to deal with firewalls that block all UDP traffic. TURN MUST > also be supported when using TLS over TCP between the client and the > server.” > > 3.4, 6th and 7th Paragraphs should be combined. No, they should not. Paragraph 6 deals with IPv6 candidates, paragraph 7 deals with TCP candidates. Perhaps you mean paragraph 7 and 8? That makes more sense, but I still want those sentences separated by whitespace, so I'll keep the distinction. > > 3.4 7th Paragraph > > - - If the intention of the paragraph to show why TURN TCP candidates > do not provide significant benefit it needs to indicate so: “â€Ĥnot seen > as providing significant benefit since/because:” > - - suggest change “Secondly” to “Second” > - - suggest change “that use case is anyway supported” to “this use case > is not supported” But as long as TURN over TCP is supported, the use case is supported, that's the point. Changed "anyway supported" to "supported in a different way". > - - suggest change “Thirdly” to “Third” Done. > > 4. 1st Paragraph > > It seems to me the word “that” in the sentence “â€Ĥprioritization model > is that the application tellsâ€Ĥ” should be changed to ‘what’. I tried "The RTCWEB prioritization model is what the application tells the RTCWEB implementation", and couldn't find a meaning for it, so I don't think that's right. The model is that the application tells the implementation something about what it wants. What it tells the implementation ... I don't have a name for. > > 4.1 3rd Paragraph > > It seems to me this sentence, “ (same as above + DSCP code point)”, > could be clearer as “(5-tuple plus DSCP code point)” Makes sense. Done. > > - -- > Eduardo Gueiros > Developer | Jive Communications, Inc. > Jive.com | egueiros at jive.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTj7NiAAoJEInLDRowktwYsCoIALzUwWWN2CZ5aXa0LJ5BZN2h > CDOe4XxZAmaZLYDB8A/HS4SfXswCOaCxOgxmqQD1NN++8znd/0TfgZZ9dq6IbV/N > m71pkzrv8R0mXkj7wLYiHEyhhX0Sb2KzzjRVwIDSfXIEzWrSlDKw9KLuNrXL7qfe > NZmKhiyxSjdFOI1eF8qckIiQPCovJfi7j4Q7Ee01A6MxCXPXJdU+rYff88GCGgWi > f1bN+yC5/NtYJo+icc3Kg7lZCOfYIPgCRoiAI+vQl11IMrygCski5bp3S423sQjX > HAFSC9U9ram951vXMIb9JBNli3TyZlP51JggcUiBq28tEtabYOjTkpALdbdKoyo= > =+LbI > -----END PGP SIGNATURE----- From nobody Wed Jun 11 07:01:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604ED1A00D2 for ; Wed, 11 Jun 2014 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CckdxEqNQxz for ; Wed, 11 Jun 2014 07:01:11 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50FCF1A00C9 for ; Wed, 11 Jun 2014 07:01:11 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so2319972wes.4 for ; Wed, 11 Jun 2014 07:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=d+dss94tKNVK/jhdMixCuH0KDc1OS1TN5mZN0CdflDs=; b=evZsDU8d4Aa6YLNUcbBQd2boy1QALxUYCZWHFDbz67RqVvAdomuO3J2K7/2wCLdBxF S0U6phbVFCs6Z2CoVYZBTFdA0gf85CAqpSrTywS6XFJZahqGlbOtnjsy9p8MxpOKTtJz mebJ648yekufaAm9Dj9RrcWs7j2yQmw36AkP7Qu4V8THKZ4ziwgL2UX9M3BXkaqfYT81 SXakyyS0R9hZ/qyOdVIkjxqVpA0YKYIKOAvXIw7uU8D/RWsY8G921XcoBjpbmLTXXr0L GOS+yaNYMpqBe6BMpSSL7EJKQYsLghOrKqLvvWq/nj0HA7F8SyVTnn04Ts1n6x1XKFPX ZCjw== X-Received: by 10.194.80.161 with SMTP id s1mr52469986wjx.47.1402495269551; Wed, 11 Jun 2014 07:01:09 -0700 (PDT) Received: from [192.168.1.39] (207.Red-79-146-136.dynamicIP.rima-tde.net. [79.146.136.207]) by mx.google.com with ESMTPSA id d2sm16109368eeo.12.2014.06.11.07.01.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 07:01:08 -0700 (PDT) Message-ID: <53986129.4050209@gmail.com> Date: Wed, 11 Jun 2014 16:01:13 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , =?UTF-8?B?SmF2aWVyIENlcnZpw7Fv?= References: <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080002080605080206040002" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/my_kqOcF6AJgjU8H1f-gQgfxtVg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:01:16 -0000 This is a multi-part message in MIME format. --------------080002080605080206040002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 11/06/2014 14:08, Makaraju, Maridi Raju (Raju) escribi³: > >> Isn't (2) already defined in current api with oniceconnectionstatechange with state >"connected" ? Maybe it would be interesting to also add the selected candidate in the >event as I see it useful for applications. > [Raju] (2) is done at the time of ICE gathering, which happens before initial offer is sent out. But, we need a trigger when ICE is completed, which happens after initial O/A is completed. I think that's not correct, from the editor's draft: |oniceconnectionstatechange|of typeEventHandler, This event handler, of event handler event type|iceconnectionstatechange |,/must/be fired by all objects implementing the||RTCPeerConnection| |interface. It is called any time theiceConnectionStatechanges. enum RTCIceConnectionState { "new", "checking", "connected", "completed", "failed", "disconnected", "closed" }; That has nothing to do with enum RTCIceGatheringState { "new", "gathering", "complete" }; BTW, as discussed on other email thread, we should add the onicegatheringstatechange and remove the onicecandidate(null) > > Trickle ICE (draft-ietf-mmusic-trickle-ice-01) is another powerful use case of leaving SDP O/A to application, but provide APIs (onicecandidate, addicecandidate) for them to achieve their needs. Trickle ICE is possible because browser gives ICE candidates to app as they are discovered. Most apps just need to know only when gathering is completed. But some delay conscious apps can make use of these candidates to perform trickle ICE. > IMO, asking for end of ICE trigger and updating c/m= lines falls in to the same category that is already allowed by the APIs. > >> As a side note, is anyone using ICE TCP at all? Given that we already support TURN >over TCP/TLS, is it useful for anyone? As I see it it is only useful for servers, but >locating a TURN server near it would do the same trick. > [Raju] > TURN involves an additional element in the network and bearer path; as a result to reduce TURN costs and bearer delay, using ICE-TCP is advised. > draft-ietf-rtcweb-transports-04 says: > "ICE-TCP candidates [RFC6544] MUST be supported; this may allow > applications to communicate to peers with public IP addresses across > UDP-blocking firewalls without using a TURN server." > You haven't tried to use it, right? https://code.google.com/p/webrtc/issues/detail?id=2320 TURN is bulletproof, but ICE TCP is so seldom used that it is going to be very low tested/cared about on browsers implementations, I am afraid. Best regards Sergio --------------080002080605080206040002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
El 11/06/2014 14:08, Makaraju, Maridi Raju (Raju) escribi³:

Isn't (2) already defined in current api with oniceconnectionstatechange with state >"connected" ? Maybe it would be interesting to also add the selected candidate in the >event as I see it useful for applications.

[Raju] (2) is done at the time of ICE gathering, which happens before initial offer is sent out. But, we need a trigger when ICE is completed, which happens after initial O/A is completed.

I think that's not correct, from the editor's draft:

oniceconnectionstatechange of type EventHandler, This event handler, of event handler event type iceconnectionstatechange, must be fired by all objects implementing the RTCPeerConnection interface. It is called any time the iceConnectionState changes.

enum RTCIceConnectionState {
    "new",
    "checking",
    "connected",
    "completed",
    "failed",
    "disconnected",
    "closed"
};

That has nothing to do with

enum RTCIceGatheringState {
    "new",
    "gathering",
    "complete"
};

BTW,  as discussed on other email thread, we should add the onicegatheringstatechange and remove the onicecandidate(null)


Trickle ICE (draft-ietf-mmusic-trickle-ice-01) is another powerful use case of leaving SDP O/A to application, but provide APIs (onicecandidate, addicecandidate) for them to achieve their needs. Trickle ICE is possible because browser gives ICE candidates to app as they are discovered. Most apps just need to know only when gathering is completed. But some delay conscious apps can make use of these candidates to perform trickle ICE. 
IMO, asking for end of ICE trigger and updating c/m= lines falls in to the same category that is already allowed by the APIs.


As a side note, is anyone using ICE TCP at all? Given that we already support TURN >over TCP/TLS, is it useful for anyone? As I see it it is only useful for servers, but >locating a TURN server near it would do the same trick.

[Raju]
TURN involves an additional element in the network and bearer path; as a result to reduce TURN costs and bearer delay, using ICE-TCP is advised.
draft-ietf-rtcweb-transports-04 says:
   "ICE-TCP candidates [RFC6544] MUST be supported; this may allow
   applications to communicate to peers with public IP addresses across
   UDP-blocking firewalls without using a TURN server."
You haven't tried to use it, right?

https://code.google.com/p/webrtc/issues/detail?id=2320

TURN is bulletproof, but ICE TCP is so seldom used that it is going to be very low tested/cared about on browsers implementations, I am afraid.

Best regards
Sergio

--------------080002080605080206040002-- From nobody Wed Jun 11 07:18:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B4A1A00EC; Wed, 11 Jun 2014 07:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCTj-wW1tChD; Wed, 11 Jun 2014 07:18:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8C11A00FC; Wed, 11 Jun 2014 07:18:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611141847.31511.82114.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 07:18:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rJHuMSEwWKyMy2AnuTvFhz6KNKU Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:18:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for RTCWEB Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-05.txt Pages : 13 Date : 2014-06-11 Abstract: This document describes the data transport protocols used by RTCWEB, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-transports-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 11 07:29:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605121A010D for ; Wed, 11 Jun 2014 07:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_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 1Ht88HCkkd9s for ; Wed, 11 Jun 2014 07:29:01 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982851A0538 for ; Wed, 11 Jun 2014 07:29:00 -0700 (PDT) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C90BE1C105074; Wed, 11 Jun 2014 16:28:55 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35B976@ESESSMB209.ericsson.se> Date: Wed, 11 Jun 2014 16:28:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D35B976@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F4mv_BKcbEABosZjO7lP5rXILnI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:29:04 -0000 On 10 Jun 2014, at 21:22, Christer Holmberg = wrote: > Hi, > =20 > A comment on draft-ietf-rtcweb-data-protocol-06: > =20 > Section 5.1 says: > =20 > "Protocol: Variable Length (sequence of characters) > The sub-protocol for the channel as a UTF-8 encoded string. If > this is an empty string the protocol is unspecified. If it is a > non-empty string, it specifies an protocol registered in the > 'WebSocket Subprotocol Name Registry' created in [RFC6455]." > =20 > =20 > I think "The sub-protocol for the channel as a UTF-8 encoded string." = part is a little confusing, because there is no such thing as = sub-protocol in DCEP itself (DCEP only uses the WebSocket sub-protocol = registry for registering DCEP *protocol* values). > =20 > Perhaps we could just remove the sentence, and keep: > =20 > "Protocol: Variable Length (sequence of characters) > If this is an empty string the protocol is unspecified. If it = is a > non-empty string, it specifies an protocol registered in the > 'WebSocket Subprotocol Name Registry' created in [RFC6455]." > =20 > Section 4 gives more information about the usage of the protocol. Do you intend to drop the statement about the UTF-8 encoding? I think we should keep a statement about the encoding. Best regards Michael > =20 > (Alternatively, we could use sub-protocol terminology also in DCEP) > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > =20 > =20 > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie = [ted.ietf@gmail.com] > Sent: Tuesday, 10 June, 2014 9:52 PM > To: rtcweb@ietf.org > Subject: [rtcweb] WGLC for data channel drafts >=20 > Dear WG, >=20 > This starts a working group last call for our core Data Channel = drafts: >=20 > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt >=20 > Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >=20 > Ted, Sean, Cullen > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jun 11 07:52:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751131A0148 for ; Wed, 11 Jun 2014 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 7O4BTc1ozCRW for ; Wed, 11 Jun 2014 07:52:23 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECBF1A0127 for ; Wed, 11 Jun 2014 07:52:22 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5BEqJwG009412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2014 09:52:20 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s5BEqJuT026882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 10:52:19 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 11 Jun 2014 10:52:19 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Sergio Garcia Murillo , =?utf-8?B?SmF2aWVyIENlcnZpw7Fv?= Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPgD7abSYqU+IK/kuiw4z1j/rtWJtgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18IAAXqgAgAAjEjiAAFCFgP//zz3wgAEAN4D//8KCkIAAS0wA//+9FvAADT+7gAAG5Jyg Date: Wed, 11 Jun 2014 14:52:19 +0000 Message-ID: References: <5395C7A2.2050706@alvestrand.no> <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> In-Reply-To: <53986129.4050209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cPEZhf6QU-BevqL-9yNco5ykplI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:52:25 -0000 PkkgdGhpbmsgdGhhdCdzIG5vdCBjb3JyZWN0LCBmcm9tIHRoZSBlZGl0b3IncyBkcmFmdDoNCj5v bmljZWNvbm5lY3Rpb25zdGF0ZWNoYW5nZcKgb2YgdHlwZcKgRXZlbnRIYW5kbGVyLCBUaGlzIGV2 ZW50IGhhbmRsZXIsIG9mIGV2ZW50IGhhbmRsZXIgPmV2ZW50IHR5cGXCoGljZWNvbm5lY3Rpb25z dGF0ZWNoYW5nZSzCoE1VU1TCoGJlIGZpcmVkIGJ5IGFsbCBvYmplY3RzIGltcGxlbWVudGluZyA+ dGhlwqBSVENQZWVyQ29ubmVjdGlvbsKgaW50ZXJmYWNlLiBJdCBpcyBjYWxsZWQgYW55IHRpbWUg PnRoZcKgaWNlQ29ubmVjdGlvblN0YXRlwqBjaGFuZ2VzLg0KDQo+ZW51bSBSVENJY2VDb25uZWN0 aW9uU3RhdGUgew0KPsKgwqDCoCAibmV3IiwNCj7CoMKgwqAgImNoZWNraW5nIiwNCj7CoMKgwqAg ImNvbm5lY3RlZCIsDQo+wqDCoMKgICJjb21wbGV0ZWQiLA0KPsKgwqDCoCAiZmFpbGVkIiwNCj7C oMKgwqAgImRpc2Nvbm5lY3RlZCIsDQo+wqDCoMKgICJjbG9zZWQiDQo+fTsNCg0KPlRoYXQgaGFz IG5vdGhpbmcgdG8gZG8gd2l0aCANCg0KPmVudW0gUlRDSWNlR2F0aGVyaW5nU3RhdGUgew0KPsKg wqDCoCAibmV3IiwNCj7CoMKgwqAgImdhdGhlcmluZyIsDQo+wqDCoMKgICJjb21wbGV0ZSINCj59 Ow0KDQpbUmFqdV0gWW91IGFyZSByaWdodC4gSSBvdmVybG9va2VkOyBpY2Vjb25uZWN0aW9uc3Rh dGVjaGFuZ2UoKSBkb2VzIGluZGljYXRlIGVuZCBvZiBJQ0UuIFRoZSBtaXNzaW5nIHBhcnQgdGhl biBpcyB0byB1cGRhdGUgdGhlIFNEUCBvciB0byBpbmRpY2F0ZSB0aGUgc2VsZWN0ZWQgY2FuZGlk YXRlLiBUaGFua3MgZm9yIHBvaW50aW5nIGl0IG91dC4NCg0KPkJUVyzCoCBhcyBkaXNjdXNzZWQg b24gb3RoZXIgZW1haWwgdGhyZWFkLCB3ZSBzaG91bGQgYWRkIHRoZSBvbmljZWdhdGhlcmluZ3N0 YXRlY2hhbmdlID5hbmQgcmVtb3ZlIHRoZSBvbmljZWNhbmRpZGF0ZShudWxsKQ0KDQpbUmFqdV0g WWVzLiBJIGFncmVlIG9uaWNlZ2F0aGVyaW5nc3RhdGVjaGFuZ2UoKSBpcyBtb3JlIGFwcHJvcHJp YXRlIGZvciBlbmQgb2YgaWNlIGNhbmRpZGF0ZXMuDQoNCg0KPllvdSBoYXZlbid0IHRyaWVkIHRv IHVzZSBpdCwgcmlnaHQ/DQo+aHR0cHM6Ly9jb2RlLmdvb2dsZS5jb20vcC93ZWJydGMvaXNzdWVz L2RldGFpbD9pZD0yMzIwDQo+VFVSTiBpcyBidWxsZXRwcm9vZiwgYnV0IElDRSBUQ1AgaXMgc28g c2VsZG9tIHVzZWQgdGhhdCBpdCBpcyBnb2luZyB0byBiZSB2ZXJ5IGxvdyA+dGVzdGVkL2NhcmVk IGFib3V0IG9uIGJyb3dzZXJzIGltcGxlbWVudGF0aW9ucywgSSBhbSBhZnJhaWQuDQoNCltSYWp1 XSBJIGRvbid0IHRoaW5rIGl0IGlzIHJlYWxseSBhYm91dCBpZiB0aGUgaW1wbGVtZW50YXRpb24g aXMgc3RhYmxlIG9yIG5vdCBhcyBpbXBsZW1lbnRhdGlvbnMgZG8gZ2V0IHN0YWJsZSBvdmVyIHRp bWUuIEJ1dCB0aGUgcmVhbCBxdWVzdGlvbiBpcyB3aGF0IGlzIHdlYnJ0YyBpbXBsZW1lbnRhdGlv bnMgcmVxdWlyZWQgdG8gZG8/IFRoZSBzcGVjIGNsZWFybHkgc2F5cyAiTVVTVCIuDQoNCkJSDQpS YWp1DQogDQo= From nobody Wed Jun 11 09:11:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B891B27A4 for ; Wed, 11 Jun 2014 09:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZAC4oFuUeQ6 for ; Wed, 11 Jun 2014 09:11:47 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2170F1A01AB for ; Wed, 11 Jun 2014 09:11:46 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so6572287wgg.27 for ; Wed, 11 Jun 2014 09:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K3563hnyRqFtqszRfVNvYqmkkJuKbGi9FpH4KtuWMAI=; b=ORz6SW7q/FH4AF9TSHjsrYc8ZrRQphUXrPZANN1plbTxBqMlAeCgnw+/c2hFkCKWCK 44hwY7S1Ka3Re27mx/WqlUZwYNH3iDoxhyeUDTfyk141xEzNMHEHQkwcd2/o1YSK13xC leCSNdila440KeUNkSczXzqmpEVbQf9Bn8rIMipnavEel4KYKEETApvVaE6H2QeB/ygE gRNmxeKjVnfe8X1dwXZlcF3mWUp0jcnEy7mqxyD1Wd0sEIC53s6KvRLmMJYMMI/lMu+Y +Q2PofnItpV1RrQ2lCCV7Ic2kWxJLw0sKL36M7lWLfziWiJFuzEhna+JeFiwHLEGUsAy rMcQ== X-Received: by 10.194.120.68 with SMTP id la4mr52829223wjb.40.1402503104389; Wed, 11 Jun 2014 09:11:44 -0700 (PDT) Received: from [192.168.1.39] (207.Red-79-146-136.dynamicIP.rima-tde.net. [79.146.136.207]) by mx.google.com with ESMTPSA id gi8sm28106923wib.8.2014.06.11.09.11.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 09:11:43 -0700 (PDT) Message-ID: <53987FC3.7060408@gmail.com> Date: Wed, 11 Jun 2014 18:11:47 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , =?UTF-8?B?SmF2aWVyIENlcnZpw7Fv?= References: <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BIAbHhWmqoX-poINGs0XKtbDcyc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:11:48 -0000 El 11/06/2014 16:52, Makaraju, Maridi Raju (Raju) escribi³: >> You haven't tried to use it, right? >> https://code.google.com/p/webrtc/issues/detail?id=2320 >> TURN is bulletproof, but ICE TCP is so seldom used that it is going to be very low >tested/cared about on browsers implementations, I am afraid. > [Raju] I don't think it is really about if the implementation is stable or not as implementations do get stable over time. But the real question is what is webrtc implementations required to do? The spec clearly says "MUST". > > My point was if that "MUST" was really needed at all. Best regards Sergio From nobody Wed Jun 11 09:57:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FE81A01ED for ; Wed, 11 Jun 2014 09:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1tD6T_A_0cc for ; Wed, 11 Jun 2014 09:57:43 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 605461A0201 for ; Wed, 11 Jun 2014 09:57:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9D39F7C3786; Wed, 11 Jun 2014 18:57:42 +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 2qctA+RlkvjE; Wed, 11 Jun 2014 18:57:41 +0200 (CEST) Received: from [10.166.199.55] (host-95-199-7-55.mobileonline.telia.com [95.199.7.55]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7DB867C377A; Wed, 11 Jun 2014 18:57:41 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <53987FC3.7060408@gmail.com> References: <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----K7SIJH9C6BVJI4PS1W1SK6KUVM6L6K" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Wed, 11 Jun 2014 18:57:38 +0200 To: Sergio Garcia Murillo , "Makaraju, Maridi Raju (Raju)" , =?ISO-8859-1?Q?Javier_Cervi=F1o?= Message-ID: <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ur2CZmp9q_g1IinW0rr944fQ51E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:57:52 -0000 ------K7SIJH9C6BVJI4PS1W1SK6KUVM6L6K Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The MUST was a consensus call in London. See the minutes for numbers. I was one of the ones who were surprised at the strength of the consensus. On 11. juni 2014 18:11:47 CEST, Sergio Garcia Murillo wrote: >El 11/06/2014 16:52, Makaraju, Maridi Raju (Raju) escribi³: >>> You haven't tried to use it, right? >>> https://code.google.com/p/webrtc/issues/detail?id=2320 >>> TURN is bulletproof, but ICE TCP is so seldom used that it is going >to be very low >tested/cared about on browsers implementations, I am >afraid. >> [Raju] I don't think it is really about if the implementation is >stable or not as implementations do get stable over time. But the real >question is what is webrtc implementations required to do? The spec >clearly says "MUST". >> >> > >My point was if that "MUST" was really needed at all. > >Best regards >Sergio > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------K7SIJH9C6BVJI4PS1W1SK6KUVM6L6K Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The MUST was a consensus call in London. See the minutes for numbers. I was one of the ones who were surprised at the strength of the consensus.

On 11. juni 2014 18:11:47 CEST, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
El 11/06/2014 16:52, Makaraju, Maridi Raju (Raju) escribi³:
 You haven't tried to use it, right?
 https://code.google.com/p/webrtc/issues/detail?id=2320
 TURN is bulletproof, but ICE TCP is so seldom used that it is going to be very low >tested/cared about on browsers implementations, I am afraid.
 [Raju] I don't think it is really about if the implementation is stable or not as implementations do get stable over time. But the real question is what is webrtc implementations required to do? The spec clearly says "MUST".



My point was if that "MUST" was really needed at all.

Best regards
Sergio


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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------K7SIJH9C6BVJI4PS1W1SK6KUVM6L6K-- From nobody Wed Jun 11 10:25:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECCE1B2799 for ; Wed, 11 Jun 2014 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJikA43wqEdE for ; Wed, 11 Jun 2014 10:24:57 -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 BEDCF1A0228 for ; Wed, 11 Jun 2014 10:24:48 -0700 (PDT) X-AuditID: c1b4fb2d-f79776d000001085-ad-539890de3e92 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.D7.04229.ED098935; Wed, 11 Jun 2014 19:24:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Wed, 11 Jun 2014 19:24:46 +0200 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] WGLC for data channel drafts - sub-protocol usage Thread-Index: AQHPhN+AfyTSYp5Q8kmpv1ASj3hsrJtr16yAgABSfyU= Date: Wed, 11 Jun 2014 17:24:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D35B976@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvje79CTOCDX5cZ7S42LSE0WLtv3Z2 i8a5dg7MHjtn3WX3WLLkJ5PHhpYdTAHMUVw2Kak5mWWpRfp2CVwZyyZ+Yy94JFzxeE9tA+Mj /i5GTg4JAROJDat3MELYYhIX7q1nA7GFBI4ySjT+zoOwFzNKrFju28XIwcEmYCHR/U8bJCwi YCpxcPk8FhCbWcBDYtqtpawgtrCAu8S8G9NYIWo8JHa8eMQIYVtJHG5dCTaeRUBV4svlN2Bx XgFfiRsnV7J3MXIBrWpjlOh7/4IJJMEp4CpxYtFisEGMQLd9P7WGCWKZuMStJ/OZIG4WkFiy 5zwzhC0q8fLxP1YIW1Hi6vTlUPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScss JC2zkLQsYGRZxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYTQe3/Nbdwbj6teMhRgEORiUe 3gXu04OFWBPLiitzDzFKc7AoifNe0qgOFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDoZn1I 44qVvPPB6ns3moxeyV79vyy90a0ny/I173H3M+8+nLku3KOpyjU1y7VyhdBpW9+sWcUH1hWL 5ez4snKehQuHlz23rXjBLolpQRkVRk1H3syv6PmqvlG65fH9reVqNmHezqKit0y2HBHken5y +s0tzYsO62u4TTj05NnhFR/bqr9cXVWoxFKckWioxVxUnAgATlMYx4cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/392gxDRhzC95_3UH42W2jl3q2H4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:24:59 -0000 Hi Michael, I agree that we need to keep text about the encoding. Regards, Christer ________________________________________ From: Michael Tuexen [Michael.Tuexen@lurchi.franken.de] Sent: Wednesday, 11 June 2014 5:28 PM To: Christer Holmberg Cc: Ted Hardie; rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage On 10 Jun 2014, at 21:22, Christer Holmberg wrote: > Hi, > > A comment on draft-ietf-rtcweb-data-protocol-06: > > Section 5.1 says: > > "Protocol: Variable Length (sequence of characters) > The sub-protocol for the channel as a UTF-8 encoded string. If > this is an empty string the protocol is unspecified. If it is a > non-empty string, it specifies an protocol registered in the > 'WebSocket Subprotocol Name Registry' created in [RFC6455]." > > > I think "The sub-protocol for the channel as a UTF-8 encoded string." par= t is a little confusing, because there is no such thing as sub-protocol in = DCEP itself (DCEP only uses the WebSocket sub-protocol registry for registe= ring DCEP *protocol* values). > > Perhaps we could just remove the sentence, and keep: > > "Protocol: Variable Length (sequence of characters) > If this is an empty string the protocol is unspecified. If it is a > non-empty string, it specifies an protocol registered in the > 'WebSocket Subprotocol Name Registry' created in [RFC6455]." > > Section 4 gives more information about the usage of the protocol. Do you intend to drop the statement about the UTF-8 encoding? I think we should keep a statement about the encoding. Best regards Michael > > (Alternatively, we could use sub-protocol terminology also in DCEP) > > Regards, > > Christer > > > > > > > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie [ted.ietf@= gmail.com] > Sent: Tuesday, 10 June, 2014 9:52 PM > To: rtcweb@ietf.org > Subject: [rtcweb] WGLC for data channel drafts > > Dear WG, > > This starts a working group last call for our core Data Channel drafts: > > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt > > Please review them in detail, especially for areas which may be of concer= n to the broader IETF community. This WGLC will end on June 27, 2014. > > Ted, Sean, Cullen > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb= From nobody Wed Jun 11 11:39:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5FE1B27C3 for ; Wed, 11 Jun 2014 11:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 x7Rzt9yEXnDk for ; Wed, 11 Jun 2014 11:39:05 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BBE1A00D4 for ; Wed, 11 Jun 2014 11:39:04 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5BIcwXn018019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2014 13:38:58 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s5BIctWp003018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 14:38:58 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 11 Jun 2014 14:38:56 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , Sergio Garcia Murillo , =?utf-8?B?SmF2aWVyIENlcnZpw7Fv?= Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPgD7abSYqU+IK/kuiw4z1j/rtWJtgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18IAAXqgAgAAjEjiAAFCFgP//zz3wgAEAN4D//8KCkIAAS0wA//+9FvAADT+7gAAG5Jyg//+3OXP//+slAA== Date: Wed, 11 Jun 2014 18:38:55 +0000 Message-ID: References: <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> In-Reply-To: <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KhUpHp675soQAUat3O9uV84jDzc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:39:06 -0000 PlRoZSBNVVNUIHdhcyBhIGNvbnNlbnN1cyBjYWxsIGluIExvbmRvbi4gU2VlIHRoZSBtaW51dGVz IGZvciBudW1iZXJzLiBJIHdhcyBvbmUgb2YgPnRoZSBvbmVzIHdobyB3ZXJlIHN1cnByaXNlZCBh dCB0aGUgc3RyZW5ndGggb2YgdGhlIGNvbnNlbnN1cy4NCltSYWp1XSBJIHRob3VnaHQgb25lIG9m IHRoZSBpbXBsaWNpdCAobWF5IGJlIGV4cGxpY2l0IGluIGRyYWZ0LWlldGYtcnRjd2ViLXVzZS1j YXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0KSByZXF1aXJlbWVudCBmb3IgV2ViUlRDIGlzICJpbXBs ZW1lbnRhdGlvbnMgc2hvdWxkIHdvcmsgcmlnaHQgb3V0IG9mIHRoZSBib3ggd2l0aG91dCBleHRy YSBib3hlcyAoZS5nLiBUVVJOKSBpbiBiZXR3ZWVuIHVuZGVyIFVEUCByZXN0cmljdGl2ZSBmaXJl d2FsbHMiLg0KVGhlbiBJIHNlZSB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50IGluIGRyYWZ0LWll dGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0LiBJdCBkaWQgbm90IG1lbnRp b24gdXNlIG9mIFRVUk4gaW4gdGhlIHRleHQuDQoNCiAgIEYxOCAgICAgVGhlIGJyb3dzZXIgbXVz dCBiZSBhYmxlIHRvIHNlbmQgc3RyZWFtcyBhbmQNCiAgICAgICAgICAgZGF0YSB0byBhIHBlZXIg aW4gdGhlIHByZXNlbmNlIG9mIE5BVHMgYW5kDQogICAgICAgICAgIEZpcmV3YWxscyB0aGF0IGJs b2NrIFVEUCB0cmFmZmljLg0KDQpCUg0KUmFqdQ0KDQo= From nobody Wed Jun 11 12:33:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C751A028D for ; Wed, 11 Jun 2014 12:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF66p-aXKIRI for ; Wed, 11 Jun 2014 12:33:21 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9811A01D6 for ; Wed, 11 Jun 2014 12:33:20 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so1761088wiw.17 for ; Wed, 11 Jun 2014 12:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=zZ+e3P1YSXZT+xBipu59qEuULYM9T79FNnjy4nWf4/w=; b=QBvkkMCJRCL0XGukAfm6gAjkIbuAzTETiEw62qri1YP0vEV69SEJMfvPnVG/oQJjV0 HmvaFbfo/3vaAKZoNgCxPeoZ/Gd5V8w7Ohqtg+ulzRdFWsw/YLG7lwSpE+yM24fjMbns 3gEOvubnXAin/7rKFbRZjxaSW6WXj7nDxNTjNT722EeDGWu/2PUz7Ixd/znB1hf2hVQY GpPikkoI+ZaV+oc7YagzXcCzqLsneZfsJZD3H4kFlzLy3uEhNqBeYiV2mFKPY7PCki74 OcFYDIF2yfZf2K+OeGlto5CSMu470uOCXij+CYelEcdUMeuFtpP8+2Ifqc4fmkPRzGxo oTvw== X-Received: by 10.180.97.131 with SMTP id ea3mr41321007wib.35.1402515199086; Wed, 11 Jun 2014 12:33:19 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id fc7sm35521416wjc.37.2014.06.11.12.33.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 12:33:18 -0700 (PDT) Message-ID: <5398AF03.70106@gmail.com> Date: Wed, 11 Jun 2014 21:33:23 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Harald Alvestrand , "Makaraju, Maridi Raju (Raju)" , =?UTF-8?B?SmF2aWVyIENlcnZpw7Fv?= References: <5395FC02.7090507@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> In-Reply-To: <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> Content-Type: multipart/alternative; boundary="------------000309030604020703030608" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UDJYv71rbPg67SLhCUV3xiaQlPs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:33:22 -0000 This is a multi-part message in MIME format. --------------000309030604020703030608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I am late then.. :) El 11/06/2014 18:57, Harald Alvestrand escribi³: > The MUST was a consensus call in London. See the minutes for numbers. > I was one of the ones who were surprised at the strength of the consensus. > > On 11. juni 2014 18:11:47 CEST, Sergio Garcia Murillo > wrote: > > El 11/06/2014 16:52, Makaraju, Maridi Raju (Raju) escribi³: > > You haven't tried to use it, right? > https://code.google.com/p/webrtc/issues/detail?id=2320 > TURN is bulletproof, but ICE TCP is so seldom used that it > is going to be very low >tested/cared about on browsers > implementations, I am afraid. > > [Raju] I don't think it is really about if the implementation > is stable or not as implementations do get stable over time. > But the real question is what is webrtc implementations > required to do? The spec clearly says "MUST". > > > > > My point was if that "MUST" was really needed at all. > > Best regards > Sergio > > ------------------------------------------------------------------------ > > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------000309030604020703030608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I am late then.. :)

El 11/06/2014 18:57, Harald Alvestrand escribi³:
The MUST was a consensus call in London. See the minutes for numbers. I was one of the ones who were surprised at the strength of the consensus.

On 11. juni 2014 18:11:47 CEST, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote: 
El 11/06/2014 16:52, Makaraju, Maridi Raju (Raju) escribi³:

 You haven't tried to use it, right?
 https://code.google.com/p/webrtc/issues/detail?id=2320
 TURN is bulletproof, but ICE TCP is so seldom used that it is going to be very low >tested/cared about on browsers implementations, I am afraid.

 [Raju] I don't think it is really about if the implementation is stable or not as implementations do get stable over time. But the real question is what is webrtc implementations required to do? The spec clearly says "MUST".



My point was if that "MUST" was really needed at all.

Best regards
Sergio



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


--------------000309030604020703030608-- From nobody Wed Jun 11 21:17:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB01B29C8 for ; Wed, 11 Jun 2014 21:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYxcvi_EwXWl for ; Wed, 11 Jun 2014 21:17:09 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4CACE1B29C6 for ; Wed, 11 Jun 2014 21:17:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BBE367C37E8; Thu, 12 Jun 2014 06:17:06 +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 jsxI8s0v6-4a; Thu, 12 Jun 2014 06:17:06 +0200 (CEST) Received: from [172.30.42.74] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 070A67C37E2; Thu, 12 Jun 2014 06:17:06 +0200 (CEST) Message-ID: <539929C1.3070205@alvestrand.no> Date: Thu, 12 Jun 2014 06:17:05 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Sergio Garcia Murillo , =?UTF-8?B?SmF2aWVyIENlcnZpw7Fv?= References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dJbhp0F-mU623qh0BEBaPL9Qct0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 04:17:12 -0000 On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote: >> The MUST was a consensus call in London. See the minutes for numbers. I was one of >the ones who were surprised at the strength of the consensus. > [Raju] I thought one of the implicit (may be explicit in draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC is "implementations should work right out of the box without extra boxes (e.g. TURN) in between under UDP restrictive firewalls". Unfortunately, nobody's found a way to make that true even for all common NATs/firewalls that want to permit the communication. TURN servers are the least obnoxious way to make sure apps can work in the presence of symmetric NATs. We could wish that this wasn't so, but we could also wish that NATs would go away and everyone would run IPv6; neither is likely to happen this year. Of course, in the presence of firewalls where the admin does *not* want to permit the communication, we neither can nor should make communication work. > Then I see the following requirement in draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use of TURN in the text. > > F18 The browser must be able to send streams and > data to a peer in the presence of NATs and > Firewalls that block UDP traffic. Yes. Using TURN servers is the way in which it is possible to fulfil this requirement. > > BR > Raju > From nobody Thu Jun 12 02:58:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C8F1B2822 for ; Thu, 12 Jun 2014 02:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6oMZLyo9_Jm for ; Thu, 12 Jun 2014 02:58:22 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4819A1B27FD for ; Thu, 12 Jun 2014 02:58:20 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201406121158166296; Thu, 12 Jun 2014 11:58:16 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" , "'Makaraju, Maridi Raju \(Raju\)'" , "'Sergio Garcia Murillo'" , =?iso-8859-1?Q?'Javier_Cervi=F1o'?= References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070 205@alvestrand.no> In-Reply-To: <539929C1.3070205@alvestrand.no> Date: Thu, 12 Jun 2014 11:58:15 +0200 Message-ID: <017301cf8624$d4a68060$7df38120$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+F9TbOiJ01z9x+QjmQ/8tXYG8SnAAHiT/Q Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2hOrbfrIKTgE19fTAQzm0tyhiCA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 09:58:24 -0000 >> F18 The browser must be able to send streams and >> data to a peer in the presence of NATs and >> Firewalls that block UDP traffic. >Yes. Using TURN servers is the way in which it is possible to fulfil = this requirement. Further in draft-ietf-rtcweb-use-cases-and-requirements-14:=20 "the straddling TURN server ... It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods." F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). This is a TURN server with one interface on the Enterprise LAN where the browser=20 simple shall place the WebRTC media. (The other interface should be = public.) The way for the browser to autodiscover such network provided (from the enterprise and ISP) TURN server is being worked in draft-patil-tram-turn-serv-disc-01.txt. This resolves any firewall restriction not allowing WebRTC media (by paralleling the firewall with the TURN server), and also allows the enterprise or ISP to point out a better path for the WebRTC media = (instead of through the often data crowded firewall default gateway). (This will also be needed with IPv6.) /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand Skickat: den 12 juni 2014 06:17 Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier = Cervi=F1o Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or = not to UDP? On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote: >> The MUST was a consensus call in London. See the minutes for numbers. = I was one of >the ones who were surprised at the strength of the = consensus. > [Raju] I thought one of the implicit (may be explicit in draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC = is "implementations should work right out of the box without extra boxes = (e.g. TURN) in between under UDP restrictive firewalls". Unfortunately, nobody's found a way to make that true even for all = common NATs/firewalls that want to permit the communication. TURN servers are the least obnoxious way to make sure apps can work in = the presence of symmetric NATs. We could wish that this wasn't so, but we could also wish that NATs = would go away and everyone would run IPv6; neither is likely to happen this year. Of course, in the presence of firewalls where the admin does *not* want = to permit the communication, we neither can nor should make communication = work. > Then I see the following requirement in draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use = of TURN in the text. > > F18 The browser must be able to send streams and > data to a peer in the presence of NATs and > Firewalls that block UDP traffic. Yes. Using TURN servers is the way in which it is possible to fulfil = this requirement. > > BR > Raju > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 12 04:31:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DABF1B2858 for ; Thu, 12 Jun 2014 04:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9rXTMKUufou for ; Thu, 12 Jun 2014 04:30:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9570B1B2848 for ; Thu, 12 Jun 2014 04:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4440; q=dns/txt; s=iport; t=1402572654; x=1403782254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PRNRf+AwJhOQGj59jvPYrdAVjs+hrPdg0xg0j5F4gQU=; b=lBwlvMWfR9nyb+UvcbOosDuFCQGCbQccPokAYIEccYLlALxHhpV6paEw UiqtXukBnnvEDdo2xGF7ef2Eu4hdXeoRT1E2Rf8YjfIF4EYEiFM5f9jDh SExqoVsReZptvKlPQeS7dyhvhuF/UgMueZdnOyk59TXNP0Dem7OJuvPKm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAAGPmVOtJA2E/2dsb2JhbABagw1SWbs6hmtRAYEJFnWEAwEBAQMBAQEBawsQAgEIGCcHJwsUEQIEDgWIOggN0XsTBIJgiychMweDK4EWBIoBkDGTUoM8gi8 X-IronPort-AV: E=Sophos;i="5.01,464,1400025600"; d="scan'208";a="329479837" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jun 2014 11:30:54 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5CBUr1G003910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 11:30:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.48]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 12 Jun 2014 06:30:53 -0500 From: "Pal Martinsen (palmarti)" To: Karl Stahl Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPf2E03wYVzx+zl0G8y0mYcyQaI5tgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18IAAXqgAgAAjEjiAAFCFgP//zz3wgAEAN4D//8KCkIAAXcsAgAAHhwCAAB+MgIAADkeAgAAWNICAAAzPAIAAHE2AgAChioCAAF9SgIAAGeAA Date: Thu, 12 Jun 2014 11:30:52 +0000 Message-ID: <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070 205@alvestrand.no> <017301cf8624$d4a68060$7df38120$@stahl@intertex.se> In-Reply-To: <017301cf8624$d4a68060$7df38120$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mBTDeKAJNo6IrO6jQyMrAcdGJzQ Cc: "rtcweb@ietf.org" , =?iso-8859-1?Q?Javier_Cervi=F1o?= Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 11:31:03 -0000 On 12 Jun 2014, at 11:58, Karl Stahl wrote: >>> F18 The browser must be able to send streams and >>> data to a peer in the presence of NATs and >>> Firewalls that block UDP traffic. >=20 >> Yes. Using TURN servers is the way in which it is possible to fulfil thi= s > requirement. >=20 > Further in draft-ietf-rtcweb-use-cases-and-requirements-14:=20 > "the straddling TURN server ... It must be > possible to configure the browsers used in the enterprise with > network specific STUN and TURN servers. This should be possible to > achieve by auto-configuration methods." > F20 The browser must support the use of STUN and TURN > servers that are supplied by entities other than > the web application (i.e. the network provider). >=20 > This is a TURN server with one interface on the Enterprise LAN where the > browser=20 > simple shall place the WebRTC media. (The other interface should be publi= c.) >=20 > The way for the browser to autodiscover such network provided (from the > enterprise and ISP) TURN server is being worked in > draft-patil-tram-turn-serv-disc-01.txt. >=20 > This resolves any firewall restriction not allowing WebRTC media (by > paralleling the firewall with the TURN server), and also allows the > enterprise or ISP to point out a better path for the WebRTC media (instea= d > of through the often data crowded firewall default gateway). > (This will also be needed with IPv6.) >=20 I have problems understanding how this solves any issues. I doubt many ente= rprise network managers would install a TURN server in parallel with their = FW. Would be fair easier and safer to open up the appropriate ports in the = firewall towards the TURN server. They could then allow only UDP to allow = for DPI and see that it is actually RTP traffic flowing.=20 Having a TURN server supporting UDP/TCP/TLS as communication between the cl= ient and TURN server would solve almost all connectivity problems. We shoul= d, as Harald also pointed out, not try to force us throughout the FW if the= admin do not want the traffic to go through.=20 .-. P=E5l-Erik > /Karl >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand > Skickat: den 12 juni 2014 06:17 > Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier Cervi= =F1o > Kopia: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or n= ot to > UDP? >=20 > On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote: >>> The MUST was a consensus call in London. See the minutes for numbers. I > was one of >the ones who were surprised at the strength of the consensus. >> [Raju] I thought one of the implicit (may be explicit in > draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC i= s > "implementations should work right out of the box without extra boxes (e.= g. > TURN) in between under UDP restrictive firewalls". > Unfortunately, nobody's found a way to make that true even for all common > NATs/firewalls that want to permit the communication. >=20 > TURN servers are the least obnoxious way to make sure apps can work in th= e > presence of symmetric NATs. > We could wish that this wasn't so, but we could also wish that NATs would= go > away and everyone would run IPv6; neither is likely to happen this year. >=20 > Of course, in the presence of firewalls where the admin does *not* want t= o > permit the communication, we neither can nor should make communication wo= rk. >=20 >=20 >> Then I see the following requirement in > draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use o= f > TURN in the text. >>=20 >> F18 The browser must be able to send streams and >> data to a peer in the presence of NATs and >> Firewalls that block UDP traffic. >=20 > Yes. Using TURN servers is the way in which it is possible to fulfil this > requirement. >=20 >>=20 >> BR >> Raju >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 12 05:12:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393301B2865 for ; Thu, 12 Jun 2014 05:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 ofmZHJHjs2qm for ; Thu, 12 Jun 2014 05:12:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C7C1B2863 for ; Thu, 12 Jun 2014 05:12:16 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5CCCBpD006243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 07:12:11 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s5CCCArd032635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 08:12:11 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 12 Jun 2014 08:12:10 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , Sergio Garcia Murillo , =?utf-8?B?SmF2aWVyIENlcnZpw7Fv?= Thread-Topic: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) Thread-Index: AQHPhjeI2RSVoNelQ0ussSjLxoIP2Q== Date: Thu, 12 Jun 2014 12:12:09 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> In-Reply-To: <539929C1.3070205@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xSMUEJsXuIMY2xHayKu44e0qHRE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:12:18 -0000 U2luY2Ugd2UgYXJlIGRpZ3Jlc3NpbmcgYSBsb3QgSSBjaGFuZ2VkIHRoZSBzdWJqZWN0Lg0KDQo+ IFRVUk4gc2VydmVycyBhcmUgdGhlIGxlYXN0IG9ibm94aW91cyB3YXkgdG8gbWFrZSBzdXJlIGFw cHMgY2FuIHdvcmsgaW4NCj4gdGhlIHByZXNlbmNlIG9mIHN5bW1ldHJpYyBOQVRzLg0KDQpbUmFq dV0gQWdyZWVkLiBIb3dldmVyLCBpZiB0aGVyZSBpcyBubyBzeW1tZXRyaWMgTkFUKHMpIGluIHRo ZSBwYXRoIHdlYnJ0YyBjYW4gZmluZCBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUgVFVSTiBzZXJ2 ZXJzLiBJIHRoaW5rLCB0aGF0IGlzIGhpZ2hseSBwcmVmZXJyZWQgYW5kIHRodXMgZXhwbGFpbnMg dGhlICJNVVNUIiBmb3IgVENQLUlDRSByZXF1aXJlbWVudC4gTm8gbWF0dGVyIGhvdyBtdWNoIHdl IHRydXN0IGEgVFVSTiBzZXJ2ZXIsIGl0IGlzIHN0aWxsIGEgKm1pZGRsZSBib3gqIGFuZCB0aGVy ZSB3aWxsIGJlIHByaXZhY3kgY29uY2VybnMgd2l0aCBpdCEhDQoNCiANCj4gPiBUaGVuIEkgc2Vl IHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2Vz LWFuZC0NCj4gcmVxdWlyZW1lbnRzLTE0LiBJdCBkaWQgbm90IG1lbnRpb24gdXNlIG9mIFRVUk4g aW4gdGhlIHRleHQuDQo+ID4NCj4gPiAgICAgRjE4ICAgICBUaGUgYnJvd3NlciBtdXN0IGJlIGFi bGUgdG8gc2VuZCBzdHJlYW1zIGFuZA0KPiA+ICAgICAgICAgICAgIGRhdGEgdG8gYSBwZWVyIGlu IHRoZSBwcmVzZW5jZSBvZiBOQVRzIGFuZA0KPiA+ICAgICAgICAgICAgIEZpcmV3YWxscyB0aGF0 IGJsb2NrIFVEUCB0cmFmZmljLg0KPiANCj4gWWVzLiBVc2luZyBUVVJOIHNlcnZlcnMgaXMgdGhl IHdheSBpbiB3aGljaCBpdCBpcyBwb3NzaWJsZSB0byBmdWxmaWwNCj4gdGhpcyByZXF1aXJlbWVu dC4NCltSYWp1XSBZZXMsIEkgdGhpbmsgdXNlIG9mIFNUVU4gc2VydmVycyBvbmx5IGlmIGRpcmVj dCBjb25uZWN0aW9uIHVzaW5nIFRDUCBJQ0UgaXMgbm90IHBvc3NpYmxlIChkdWUgdG8gc3ltbWV0 cmljIE5BVHMpLiBEdWUgdG8gdmFyaW91cyBpc3N1ZXMgd2l0aCBUVVJOcyBvciBtaWRkbGUgYm94 ZXMgKGxhdGVuY3ksIGNvc3Qgb2Ygc2VydmljZSwgaW5jcmVhc2VkIGxvc3Mgb2YgcGFja2V0cykg SUNFIFJGQyByZWNvbW1lbmRzIHRoZSBmb2xsb3dpbmcgcHJpb3JpdGllcyBmb3IgSUNFIGNhbmRp ZGF0ZXMuIEkgZG9uJ3Qgc2VlIHdlYnJ0YyBoYXMgYW4gb3ZlcnJpZGluZyByZXF1aXJlbWVudCBm b3IgdGhpcy4gQXQgdGhlIGVuZCwgaXQncyBhbHdheXMgYXBwbGljYXRpb24vdXNlciBjaG9pY2Ug dG8gdXNlIG9yIG5vdCB1c2UgVFVSTiBvciBvdGhlciBtaWRkbGUgYm94ZXMuIFRvIGZhY2lsaXRh dGUgdGhpcywgSU1ITyBicm93c2VyIHJlcXVpcmVtZW50IG9mIE1VU1QgZm9yIFRDUC1JQ0UgaXMg anVzdGlmaWVkLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24t NC4xLjIuMg0KICAgSWYgdGhlc2UgY29uY2VybnMgYXJlIGltcG9ydGFudCwgdGhlDQogICB0eXBl IHByZWZlcmVuY2UgZm9yIHJlbGF5ZWQgY2FuZGlkYXRlcyBTSE9VTEQgYmUgbG93ZXIgdGhhbiBo b3N0DQogICBjYW5kaWRhdGVzLiAgVGhlIFJFQ09NTUVOREVEIHZhbHVlcyBhcmUgMTI2IGZvciBo b3N0IGNhbmRpZGF0ZXMsIDEwMA0KICAgZm9yIHNlcnZlciByZWZsZXhpdmUgY2FuZGlkYXRlcywg MTEwIGZvciBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzLA0KICAgYW5kIDAgZm9yIHJlbGF5ZWQg Y2FuZGlkYXRlcy4NCg0KQlINClJhanUNCg0K From nobody Thu Jun 12 05:37:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325D31B29EE for ; Thu, 12 Jun 2014 05:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcQdsrGxWmrM for ; Thu, 12 Jun 2014 05:37:41 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105AE1A0080 for ; Thu, 12 Jun 2014 05:37:40 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id a1so1196935wgh.12 for ; Thu, 12 Jun 2014 05:37:39 -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=5ZTTT9AWE9mxAWJoByZvU7wYrBmTTq4lf/jUMrrhQgQ=; b=rSq7pmnXEo/vRnDyTnyiJalzaJxxZ+Xzeds/NaHBV9Q7riLgoWpK1QrfIZt0KWG9oU jTsiJ54SYEKUt9b5V01Pik8Mc0VLcdsbBNL/cyd8Y9fHHEy4qt1hqtaEmk4sfbiDltZL CGXBatH26ZYlGGLkuCTI3DLXC8cBhN9BCIA4Z1x9zdE8xks+on03dxiY/wCd6cFcxb17 2xEU/8+c26YIxCR39aILUDmf5Zsl5GIUWhjHK8DU/oWLJKouZqfb3SV59SajAP522VRn ntdvrKeJV3vyCz9W9pgWTzxjiDSizcfZBHJF81Tgu5xom7GpgMFe5NSjAefP6kSYT3ud myXA== MIME-Version: 1.0 X-Received: by 10.194.61.193 with SMTP id s1mr61872886wjr.36.1402576659480; Thu, 12 Jun 2014 05:37:39 -0700 (PDT) Received: by 10.216.39.1 with HTTP; Thu, 12 Jun 2014 05:37:39 -0700 (PDT) Received: by 10.216.39.1 with HTTP; Thu, 12 Jun 2014 05:37:39 -0700 (PDT) In-Reply-To: <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> Date: Thu, 12 Jun 2014 05:37:39 -0700 Message-ID: From: Ca By To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=047d7b86cdc28f071504fba2d3f9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O2f0Az9qZ3qDsIB26dYk6a0v9dQ Cc: =?UTF-8?Q?Javier_Cervi=C3=B1o?= , "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:37:43 -0000 --047d7b86cdc28f071504fba2d3f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jun 12, 2014 4:31 AM, "Pal Martinsen (palmarti)" wrote: > > > On 12 Jun 2014, at 11:58, Karl Stahl wrote: > > >>> F18 The browser must be able to send streams and > >>> data to a peer in the presence of NATs and > >>> Firewalls that block UDP traffic. > > > >> Yes. Using TURN servers is the way in which it is possible to fulfil this > > requirement. > > > > Further in draft-ietf-rtcweb-use-cases-and-requirements-14: > > "the straddling TURN server ... It must be > > possible to configure the browsers used in the enterprise with > > network specific STUN and TURN servers. This should be possible to > > achieve by auto-configuration methods." > > F20 The browser must support the use of STUN and TURN > > servers that are supplied by entities other than > > the web application (i.e. the network provider). > > > > This is a TURN server with one interface on the Enterprise LAN where th= e > > browser > > simple shall place the WebRTC media. (The other interface should be public.) > > > > The way for the browser to autodiscover such network provided (from the > > enterprise and ISP) TURN server is being worked in > > draft-patil-tram-turn-serv-disc-01.txt. > > > > This resolves any firewall restriction not allowing WebRTC media (by > > paralleling the firewall with the TURN server), and also allows the > > enterprise or ISP to point out a better path for the WebRTC media (instead > > of through the often data crowded firewall default gateway). > > (This will also be needed with IPv6.) > > > > I have problems understanding how this solves any issues. I doubt many enterprise network managers would install a TURN server in parallel with their FW. Would be fair easier and safer to open up the appropriate ports in the firewall towards the TURN server. They could then allow only UDP to allow for DPI and see that it is actually RTP traffic flowing. > I believe they will install a TURN server in parallel to a firewall, like many enterprises install SBCs in parallel to firewalls. Enterprise firewalls are generally not optimized for multimedia traffic. CB > Having a TURN server supporting UDP/TCP/TLS as communication between the client and TURN server would solve almost all connectivity problems. We should, as Harald also pointed out, not try to force us throughout the FW if the admin do not want the traffic to go through. > > .-. > P=C3=A5l-Erik > > > > > > > > > > > > /Karl > > > > -----Ursprungligt meddelande----- > > Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Harald Alve= strand > > Skickat: den 12 juni 2014 06:17 > > Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier Cervi=C3=B1o > > Kopia: rtcweb@ietf.org > > =C3=84mne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP= or not to > > UDP? > > > > On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote: > >>> The MUST was a consensus call in London. See the minutes for numbers. I > > was one of >the ones who were surprised at the strength of the consensus. > >> [Raju] I thought one of the implicit (may be explicit in > > draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC is > > "implementations should work right out of the box without extra boxes (e.g. > > TURN) in between under UDP restrictive firewalls". > > Unfortunately, nobody's found a way to make that true even for all common > > NATs/firewalls that want to permit the communication. > > > > TURN servers are the least obnoxious way to make sure apps can work in the > > presence of symmetric NATs. > > We could wish that this wasn't so, but we could also wish that NATs would go > > away and everyone would run IPv6; neither is likely to happen this year= . > > > > Of course, in the presence of firewalls where the admin does *not* want to > > permit the communication, we neither can nor should make communication work. > > > > > >> Then I see the following requirement in > > draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use of > > TURN in the text. > >> > >> F18 The browser must be able to send streams and > >> data to a peer in the presence of NATs and > >> Firewalls that block UDP traffic. > > > > Yes. Using TURN servers is the way in which it is possible to fulfil this > > requirement. > > > >> > >> BR > >> Raju > >> > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --047d7b86cdc28f071504fba2d3f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 12, 2014 4:31 AM, "Pal Martinsen (palmarti)" <palmarti@cisco.com> wrote:
>
>
> On 12 Jun 2014, at 11:58, Karl Stahl <karl.stahl@intertex.se> wrote:
>
> >>> =C2=A0 =C2=A0F18 =C2=A0 =C2=A0 The browser must be able t= o send streams and
> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data to a peer i= n the presence of NATs and
> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Firewalls that b= lock UDP traffic.
> >
> >> Yes. Using TURN servers is the way in which it is possible to= fulfil this
> > requirement.
> >
> > Further in draft-ietf-rtcweb-use-cases-and-requirements-14:
> > "the straddling TURN server ... It must be
> > =C2=A0 possible to configure the browsers used in the enterprise = with
> > =C2=A0 network specific STUN and TURN servers. =C2=A0This should = be possible to
> > =C2=A0 achieve by auto-configuration methods."
> > F20 =C2=A0 =C2=A0 The browser must support the use of STUN and TU= RN
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 servers that are supplied by e= ntities other than
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the web application (i.e. the = network provider).
> >
> > This is a TURN server with one interface on the Enterprise LAN wh= ere the
> > browser
> > simple shall place the WebRTC media. (The other interface should = be public.)
> >
> > The way for the browser to autodiscover such network provided (fr= om the
> > enterprise and ISP) TURN server is being worked in
> > draft-patil-tram-turn-serv-disc-01.txt.
> >
> > This resolves any firewall restriction not allowing WebRTC media = (by
> > paralleling the firewall with the TURN server), and also allows t= he
> > enterprise or ISP to point out a better path for the WebRTC media= (instead
> > of through the often data crowded firewall default gateway).
> > (This will also be needed with IPv6.)
> >
>
> I have problems understanding how this solves any issues. I doubt many= enterprise network managers would install a TURN server in parallel with t= heir FW. Would be fair easier and safer to open up the appropriate ports in= the firewall towards the TURN server. =C2=A0They could then allow only UDP= to allow for DPI and see that it is actually RTP traffic flowing.
>

I believe they will install a TURN server in parallel to a f= irewall, like many enterprises install SBCs in parallel to firewalls. Enter= prise firewalls are generally not optimized for multimedia traffic.

CB
> Having a TURN server supporting UDP/TCP/TLS as communication between t= he client and TURN server would solve almost all connectivity problems. We = should, as Harald also pointed out, not try to force us throughout the FW i= f the admin do not want the traffic to go through.
>
> .-.
> P=C3=A5l-Erik
>
>
>
>
>
>
>
>
>
>
> > /Karl
> >
> > -----Ursprungligt meddelande-----
> > Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Harald Alvestrand
> > Skickat: den 12 juni 2014 06:17
> > Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier= Cervi=C3=B1o
> > Kopia: rtcweb@ietf.org
> > =C3=84mne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: = To UDP or not to
> > UDP?
> >
> > On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote:
> >>> The MUST was a consensus call in London. See the minutes = for numbers. I
> > was one of >the ones who were surprised at the strength of the= consensus.
> >> [Raju] I thought one of the implicit (may be explicit in
> > draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for = WebRTC is
> > "implementations should work right out of the box without ex= tra boxes (e.g.
> > TURN) in between under UDP restrictive firewalls".
> > Unfortunately, nobody's found a way to make that true even fo= r all common
> > NATs/firewalls that want to permit the communication.
> >
> > TURN servers are the least obnoxious way to make sure apps can wo= rk in the
> > presence of symmetric NATs.
> > We could wish that this wasn't so, but we could also wish tha= t NATs would go
> > away and everyone would run IPv6; neither is likely to happen thi= s year.
> >
> > Of course, in the presence of firewalls where the admin does *not= * want to
> > permit the communication, we neither can nor should make communic= ation work.
> >
> >
> >> Then I see the following requirement in
> > draft-ietf-rtcweb-use-cases-and-requirements-14. It did not menti= on use of
> > TURN in the text.
> >>
> >> =C2=A0 =C2=A0F18 =C2=A0 =C2=A0 The browser must be able to se= nd streams and
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data to a peer in th= e presence of NATs and
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Firewalls that block= UDP traffic.
> >
> > Yes. Using TURN servers is the way in which it is possible to ful= fil this
> > requirement.
> >
> >>
> >> BR
> >> Raju
> >>
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--047d7b86cdc28f071504fba2d3f9-- From nobody Thu Jun 12 07:57:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900A51B2A7D for ; Thu, 12 Jun 2014 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-8oGQv8EULR for ; Thu, 12 Jun 2014 07:57:47 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id BED121A0546 for ; Thu, 12 Jun 2014 07:57:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 114247C3814; Thu, 12 Jun 2014 16:57:46 +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 xB7LYh+xynan; Thu, 12 Jun 2014 16:57:43 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id B2B517C3812; Thu, 12 Jun 2014 16:57:43 +0200 (CEST) Message-ID: <5399BFE6.5050003@alvestrand.no> Date: Thu, 12 Jun 2014 16:57:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , Karl Stahl References: <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070 205@alvestrand.no> <017301cf8624$d4a68060$7df38120$@stahl@intertex.se> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> In-Reply-To: <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wZG26WTexTufBEcLbfUxr5hCKes Cc: =?ISO-8859-1?Q?Javier_Cervi=F1o?= , "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:57:48 -0000 On 06/12/2014 01:30 PM, Pal Martinsen (palmarti) wrote: > On 12 Jun 2014, at 11:58, Karl Stahl wrote: > >>>> F18 The browser must be able to send streams and >>>> data to a peer in the presence of NATs and >>>> Firewalls that block UDP traffic. >>> Yes. Using TURN servers is the way in which it is possible to fulfil this >> requirement. >> >> Further in draft-ietf-rtcweb-use-cases-and-requirements-14: >> "the straddling TURN server ... It must be >> possible to configure the browsers used in the enterprise with >> network specific STUN and TURN servers. This should be possible to >> achieve by auto-configuration methods." >> F20 The browser must support the use of STUN and TURN >> servers that are supplied by entities other than >> the web application (i.e. the network provider). >> >> This is a TURN server with one interface on the Enterprise LAN where the >> browser >> simple shall place the WebRTC media. (The other interface should be public.) >> >> The way for the browser to autodiscover such network provided (from the >> enterprise and ISP) TURN server is being worked in >> draft-patil-tram-turn-serv-disc-01.txt. >> >> This resolves any firewall restriction not allowing WebRTC media (by >> paralleling the firewall with the TURN server), and also allows the >> enterprise or ISP to point out a better path for the WebRTC media (instead >> of through the often data crowded firewall default gateway). >> (This will also be needed with IPv6.) >> > I have problems understanding how this solves any issues. I doubt many enterprise network managers would install a TURN server in parallel with their FW. Would be fair easier and safer to open up the appropriate ports in the firewall towards the TURN server. They could then allow only UDP to allow for DPI and see that it is actually RTP traffic flowing. That is actually a very convenient way to (logically) install a TURN server in parallel with your firewall. They don't have to be on the same physical segments to be in parallel. The important thing that Cullen (I think it was Cullen) pointed out when we discussed this requirement is that the TURN server is designated by the local network administrator, not by the entity responsible for the Web application that uses WebRTC. Thus, some way for the browser to find this TURN server is needed. > > Having a TURN server supporting UDP/TCP/TLS as communication between the client and TURN server would solve almost all connectivity problems. We should, as Harald also pointed out, not try to force us throughout the FW if the admin do not want the traffic to go through. > > .-. > Pċl-Erik > > > > > > > > > > >> /Karl >> >> -----Ursprungligt meddelande----- >> Frċn: rtcweb [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand >> Skickat: den 12 juni 2014 06:17 >> Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier Cerviño >> Kopia: rtcweb@ietf.org >> Ämne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to >> UDP? >> >> On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote: >>>> The MUST was a consensus call in London. See the minutes for numbers. I >> was one of >the ones who were surprised at the strength of the consensus. >>> [Raju] I thought one of the implicit (may be explicit in >> draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC is >> "implementations should work right out of the box without extra boxes (e.g. >> TURN) in between under UDP restrictive firewalls". >> Unfortunately, nobody's found a way to make that true even for all common >> NATs/firewalls that want to permit the communication. >> >> TURN servers are the least obnoxious way to make sure apps can work in the >> presence of symmetric NATs. >> We could wish that this wasn't so, but we could also wish that NATs would go >> away and everyone would run IPv6; neither is likely to happen this year. >> >> Of course, in the presence of firewalls where the admin does *not* want to >> permit the communication, we neither can nor should make communication work. >> >> >>> Then I see the following requirement in >> draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use of >> TURN in the text. >>> F18 The browser must be able to send streams and >>> data to a peer in the presence of NATs and >>> Firewalls that block UDP traffic. >> Yes. Using TURN servers is the way in which it is possible to fulfil this >> requirement. >> >>> BR >>> Raju >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 12 08:18:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F8F1B2A85 for ; Thu, 12 Jun 2014 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwv5ngqyH__r for ; Thu, 12 Jun 2014 08:18:26 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8C51B2A70 for ; Thu, 12 Jun 2014 08:18:26 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so2111193qcy.4 for ; Thu, 12 Jun 2014 08:18:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=QBhSIlBqQ6r4rO6zeHMqgGUoOGDLALd5RRDJlU8ULsA=; b=dgA2/7KGjeHLYWPhi3Kq9cjJBWTUIlc3kxv5Jfgd8zk4A017e59cwAoTTXt0zhGZEp MNgaQMOzBcToy982tcJEgWYPFmSVtZ8igMb+RzWgOh3sWGVFrFwXmTuErEl/9cIwvuOj if5Ge7ltRSPDyyKj+oAEkER6v2njux+f/55fdfKApx42rJpvgnvdm7g+/g646NXil3bj lzJQgOm33kyk0XDfPbxLzpn5s3prCSggpiP9/Jju2jKo5SoSo/taKsaN8JEHbPtraYgw /ojg6422UXJKfwQecJItC6jzYbUqh4y29JwNMQRAQo9mst07r/gszCjVLD4wTR7iJTlu 5p0Q== X-Gm-Message-State: ALoCoQl7sfyJKSHgvMzH2eqVfdbDXeo6BFjOYjjNv0S4RB+bpCwLB3KZdm26sAyP0lH04P/ludI3 X-Received: by 10.140.109.201 with SMTP id l67mr59049623qgf.72.1402586305299; Thu, 12 Jun 2014 08:18:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.60.71 with HTTP; Thu, 12 Jun 2014 08:18:04 -0700 (PDT) In-Reply-To: <5399BFE6.5050003@alvestrand.no> References: <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> <5399BFE6.5050003@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 12 Jun 2014 17:18:04 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PTrcg-PizI9ZWyG6wB0QqOdDGxE Cc: =?UTF-8?Q?Javier_Cervi=C3=B1o?= , "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:18:27 -0000 2014-06-12 16:57 GMT+02:00 Harald Alvestrand : > The important thing that Cullen (I think it was Cullen) pointed out when = we > discussed this requirement is that the TURN server is designated by the > local network administrator, not by the entity responsible for the Web > application that uses WebRTC. > > Thus, some way for the browser to find this TURN server is needed. This topic has been discussed many times (and IMHO it deserves a separate thread). Basically, we need per-browser TURN settings. They may be global or per-origin (which overrides the global ones). And then we need an API to get it: var turnServers =3D navigator.getTurnServers() // now pass turnServers to PeerConnection as usual. but... that means that all the web applications must add the above code into their webs. It may also be "transparent", this is, if the PeerConnection is not provided with TURN servers it may internally retrieve them from the browser. But probably that would fail if the web developer set his own TURN servers and the "corporative firewall" block them. So we probably also need a "Force TURN servers [true/false]" within the browser TURN serttins (again global and per-origin). --=20 I=C3=B1aki Baz Castillo From nobody Thu Jun 12 08:56:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0D11B2AAD for ; Thu, 12 Jun 2014 08:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5UCG-YlXT74 for ; Thu, 12 Jun 2014 08:56:00 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655F11B2AA4 for ; Thu, 12 Jun 2014 08:55:54 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so1322243iec.13 for ; Thu, 12 Jun 2014 08:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yEtQ/Va8pVodrr3r972nk+Tc1mzsjp0RqApCUUIiYTQ=; b=qcfCLAu4/l1hamYRhYzJuGh5QWCLTMyZkRpf4UOmE5JMfiAWL2GzMmwRi7IBm6BWKf VkL1esPeuIkzo8lT2TGr4r8JAWs2l51M8ct6aO80D7Gluw6kwvW57Qd/deaNH06QF5d8 mIUwuc2vhfUbNgsuSwKNk4/CBme96fmAGP63bRqzHC6aIPNhouF67Flry+C7gVCA1TDC P0ANciyOM8SKAuZJ612WxhcKdzlyKRywMSeIHPUQ1C3+Rr1GElShcG+DgldaMUmelSqe nW8a0YrMXbQJQyflXdqdaHqdCgNdcsA3fIc3vzrrhi/97grEToM6iVzLHaQENQidMPqc M65g== MIME-Version: 1.0 X-Received: by 10.50.122.73 with SMTP id lq9mr8247272igb.13.1402588553708; Thu, 12 Jun 2014 08:55:53 -0700 (PDT) Received: by 10.42.119.211 with HTTP; Thu, 12 Jun 2014 08:55:53 -0700 (PDT) Date: Thu, 12 Jun 2014 08:55:53 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/mixed; boundary=001a11c1faca8349f704fba598f9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KACCVrsfwaxHO4I_nBELP6z_ylg Subject: [rtcweb] Minutes and videos from the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:56:03 -0000 --001a11c1faca8349f704fba598f9 Content-Type: multipart/alternative; boundary=001a11c1faca8349f204fba598f7 --001a11c1faca8349f204fba598f7 Content-Type: text/plain; charset=UTF-8 Dear Working Group, Attached is a draft set of minutes from the meeting. The secretariat is currently working on moving the videos of the meeting to the IETF channel at Youtube; the sources videos are available at https://drive.google.com/#folders/0B-1skjUwD-8EakhmY2pFdV85dHM if you would like to download them, but please be aware that they are very large. Comments and corrections on the minutes to the list please, Ted, Cullen, Sean --001a11c1faca8349f204fba598f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Working Group,

Attached is a draft set of minutes from t= he meeting.=C2=A0 The secretariat is currently working on moving the videos= of the meeting to the IETF channel at Youtube; the sources videos are avai= lable at https://drive.google.com/#folders/0B-1skjUwD-8EakhmY2pFdV85dHM= if you would like to download them, but please be aware that they are very= large.

= Comments and corrections on the minutes to the list please,

Ted, Cul= len, Sean
--001a11c1faca8349f204fba598f7-- --001a11c1faca8349f704fba598f9 Content-Type: text/plain; charset=UTF-8; name="MinutesRTCWEBIntermmeeting519-5212014.txt" Content-Disposition: attachment; filename="MinutesRTCWEBIntermmeeting519-5212014.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hwc8z22c0 77u/Q2hhaXJzOiAgQ3VsbGVuIEplbm5pbmdzLCBTZWFuIFR1cm5lciwgVGVkIEhhcmRpZQ0KU2Ny aWJlczogIERhbiBCdXJuZXR0LCBNYWdudXMgV2VzdGVybHVuZCwgQmVuIENhbXBiZWxsDQoNCg0K UlRDV0VCIFVTRS1DQVNFUyAmIFJFUVVJUkVNRU5UUw0KSUVTRyBESVNDVVNTIGl0ZW1zIChDaHJp c3RlciBIb2xtYmVyZykNCg0KDQotIEJlbm9pdCBDbGFpc2UgcmVxdWVzdGluZyBhIHJlcGx5IHRv IFRpbmEncyBPUFMtRElSIHJldmlldy4gIE9mZmljaWFsIHJlc3BvbnNlIGlzIHRoYXQgdGhpcyB2 aW9sYXRlcyBESVNDVVNTIGNyaXRlcmlhLCB3aGljaCByZXF1aXJlIHB1bGxpbmcgb3V0IHNwZWNp ZmljIHBvaW50cy4gIFN1Z2dlc3Rpb24gZnJvbSBvdXIgQURzIHRvIGJlIHBvbGl0ZSBpbiBob3cg d2UgcGhyYXNlIHRoaXMgcmVwbHkuDQoNCg0KLSBKYXJpIEFya2tvIHdhbnRpbmcgYSByZXNwb25z ZSBvIEJyaWFuIENhcnBlbnRlcidzIEdlbi1BUlQgcmV2aWV3LCBwYXJ0aWN1bGFybHkgaGlzIGZp cnN0IGNvbW1lbnQgb24gZGlmZmVyZW50IGNvbWJpbmF0aW9ucyBvZiBJUHY0L0lQdjYuICBKYXJp IHN1Z2dlc3RzIGEgY2hhbmdlLiAgV2UgYXBwcm92ZSBoaXMgc3VnZ2VzdGVkIGNoYW5nZS4NCg0K DQotIFN0ZXBoZW4gRmFycmVsbCBoYWQgbWFueSBESVNDVVNTIGl0ZW1zIGJ1dCB3b3VsZCBiZSBo YXBweSB0byBjb252ZXJ0IHRoZW0gaW50byBDT01NRU5UcyBpZiB3ZSBkb24ndCBtYWtlIHRoZSBy ZXF1aXJlbWVudHMgaW4gdGhpcyBkb2N1bWVudCBiZSBub3JtYXRpdmUgZm9yIGltcGxlbWVudGF0 aW9ucyBvciBvdGhlciBmdXR1cmUgc3BlY3MgYnV0IHJhdGhlciBoYXZlIHRoZW0gYmUgZ2VuZXJh bCBndWlkYW5jZS4NCg0KDQpDdWxsZW4gc3VnZ2VzdHMgcmVwbHlpbmcgdGhhdCB0aGlzIGRvY3Vt ZW50IHdhcyBvbmx5IGludGVuZGVkIHRvIGJlIGhlbHBmdWwgaW4gdGhlIHByb2Nlc3Mgb2YgZGV2 ZWxvcGluZyBvdXIgZG9jdW1lbnRzLCBhbmQgdGhhdCdzIHdoeSBpdCdzIGFuIEluZm9ybWF0aW9u YWwgZG9jdW1lbnQuICBHZW5lcmFsIGFncmVlbWVudCB3aXRoIHRoaXMga2luZCBvZiByZXBseSwg YWx0aG91Z2ggZGV0YWlscyBvZiB0aGUgcmVwbHkgd2lsbCBiZSB3b3JrZWQgb3V0IG9uIHRoZSBs aXN0Lg0KDQoNClNlYW4gVHVybmVyIHN1Z2dlc3RzIGNoYW5naW5nIHRoZSBuYW1lIHRvIHNvbWV0 aGluZyBsaWtlICJkZXNpZ24gY2hhcmFjdGVyaXN0aWNzIiB0byBhdm9pZCBmdXR1cmUgbWlzdW5k ZXJzdGFuZGluZ3MgYWJvdXQgdGhlIGludGVudCBvZiB0aGUgZG9jdW1lbnQuDQpBbHlzc2Egc3Vn Z2VzdHMgaW5zdGVhZCBjaGFuZ2luZyBpbml0aWFsIHRleHQgYXMgZm9sbG93czoNCg0KDQpPTEQ6 DQpUaGlzIGRvY3VtZW50IHdhcyBkZXZlbG9wZWQgaW4gYW4gaW5pdGlhbCBwaGFzZSBvZiB0aGUg d29yayB3aXRoDQogIHJhdGhlciBtaW5vciB1cGRhdGVzIGF0IGxhdGVyIHN0YWdlcy4gIEl0IGhh cyBub3QgcmVhbGx5IHNlcnZlZCBhcyBhDQogIHRvb2wgaW4gZGVjaWRpbmcgZmVhdHVyZXMgb3Ig c2NvcGUgZm9yIHRoZSBXR3MgZWZmb3J0cyBzbyBmYXIuICBJdCBpcw0KICBwcm9wb3NlZCB0byBi ZSB1c2VkIGluIGEgbGF0ZXIgcGhhc2UgdG8gZXZhbHVhdGUgdGhlIHByb3RvY29scyBhbmQNCiAg c29sdXRpb25zIGRldmVsb3BlZCBieSB0aGUgV0cuDQogIA0KTkVXOg0KVGhpcyBkb2N1bWVudCB3 YXMgZGV2ZWxvcGVkIGluIGFuIGluaXRpYWwgcGhhc2Ugb2YgdGhlIHdvcmsgd2l0aA0KICByYXRo ZXIgbWlub3IgdXBkYXRlcyBhdCBsYXRlciBzdGFnZXMuICBJdCBoYXMgbm90IHJlYWxseSBzZXJ2 ZWQgYXMgYQ0KICB0b29sIGluIGRlY2lkaW5nIGZlYXR1cmVzIG9yIHNjb3BlIGZvciB0aGUgV0dz IGVmZm9ydHMgc28gZmFyLiAgSXQgaXMgYmVpbmcgcHVibGlzaGVkIHRvIHJlY29yZCB0aGUgZWFy bHkgY29uY2x1c2lvbnMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIEl0IHdpbGwgbm90IGJlIHVzZWQg YXMgYSBzZXQgb2YgcmlnaWQgZ3VpZGVsaW5lcyB0aGF0IHNwZWNpZmljYXRpb25zIGFuZCBpbXBs ZW1lbnRhdGlvbnMgd2lsbCBiZSBoZWxkIHRvIGluIHRoZSBmdXR1cmUuDQoNCg0KVGhlcmUgaXMg Z2VuZXJhbCBhZ3JlZW1lbnQuDQoNCg0KV2UgdGhlbiBkaXNjdXNzIFN0ZXBoZW4gRmFycmVsbCdz IERJU0NVU1MgaXRlbXMuDQotIG9uIEYxMyByZWdhcmRpbmcgd2hhdCAiYXV0aGVudGljYXRlIiBt ZWFuczogIFNlYW4ncyBzdWdnZXN0aW9uIGlzIHRvIHBvaW50IHRvIHRoZSBzZWN1cml0eSBkb2N1 bWVudCBoZXJlLiAgRGVjaXNpb24gaXMgcmF0aGVyIHRvIHJlcGx5ICJ5ZXMsIHdlIGNvbnNpZGVy ZWQgaXQsIHllcyB0byBTU0ggbGVhcC1vZi1mYWl0aCBldGMuIGFuZCBmdXJ0aGVyIGRldGFpbHMg d2lsbCBiZSBpbiB0aGUgc2VjdXJpdHkgZG9jdW1lbnQgYWZ0ZXIgd2UgZGlzY3VzcyBpdCwgd2hp Y2ggd2Ugd2lsbCIuDQoNCg0KU2VwYXJhdGUgZGlzY3Vzc2lvbiBwb2ludCBjYW1lIHVwIGhlcmUg YWJvdXQgeWVzL25vIG9uIHN1cHBvcnQgZm9yIG51bGwgY2lwaGVycy4gIFdlIHdpbGwgc2NoZWR1 bGUgdGhpcyBmb3IgZGlzY3Vzc2lvbiB0b21vcnJvdyAoV2VkKSBtb3JuaW5nLiAgR2lyaSBNYW5k eWFtIHdpbGwgcHJlcGFyZSBzb21ldGhpbmcgb24gdGhpcyBzaW5jZSBoZSBicm91Z2h0IGl0IHVw Lg0KDQoNCi0gb24gRjIwIHJlZ2FyZGluZyBjb25zdW1pbmcgYmFuZHdpZHRoIG9mIHNvbWVvbmUg ZWxzZSdzIFRVUk4gc2VydmVyOiAgT3VyIHJlc3BvbnNlIGlzICJpZiB5b3UndmUgYmVlbiBhdXRo b3JpemVkIHRvIHVzZSBhIFRVUk4gc2VydmVyICh1L3ApLCB0aGVuIHlvdSBhcmUgYXV0aG9yaXpl ZCB0byB1c2UgaXQuICBUaGUgY3JlZGVudGlhbHMgYXJlIHRoZSB3YXkgaW4gd2hpY2ggYXV0aG9y aXphdGlvbiBpcyB0byBiZSBtYW5hZ2VkIGJ5IHRoZSBzZXJ2ZXIgb3duZXIuIg0KDQoNCi0gb24g RjM2IHJlZ2FyZGluZyBzYWZlIGRpc3BsYXkgb2YgdGhlIHVzZXIncyBzY3JlZW46ICBXZSBhdXRo b3JpemUgU2VhbiB0byBkZWNpZGUgaGVyZSBiZXR3ZWVuIHJlbW92aW5nIHRoaXMgcmVxdWlyZW1l bnQgb3IgZmluZGluZyBhIHNpbXBsZSB3YXkgdG8gY2xlYXIgaXQuICBUZWQgdGhlbiBzaG9ydGN1 dHRlZCB0aGUgZW50aXJlIHByb2Nlc3MgYnkgc3VnZ2VzdGluZyB0aGUgZG9jdW1lbnQgc2hlcGhl cmQgKFNlYW4pIGZpZ3VyZSBvdXQgaG93IHRvIGdldCB0aGVzZSBpdGVtcyBjbGVhcmVkIGluIHRo ZSBzaW1wbGVzdCB3YXkgcG9zc2libGUgLS0gKmFsbCogb2YgU3RlcGhlbidzIGRpc2N1c3MvY29t bWVudCBpdGVtcy4gIFdlIHdpbGwgcmVzcGluIHRoZSBkb2N1bWVudCByYXRoZXIgdGhhbiBkbyBS RkMgZWRpdG9yIG5vdGVzLCBhbmQgdGhlIGdyb3VwIHdpbGwgaGF2ZSBhIGNoYW5jZSB0byByZXZp ZXcgaXQgYmVmb3JlIHJlc2VuZGluZy4NCg0KDQoNCg0KRGF0YSBjaGFubmVsIChSYW5kZWxsIEpl c3VwKQ0KU2xpZGVzIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8y MDE0LzA1LzE5L3J0Y3dlYi9zbGlkZXMvc2xpZGVzLWludGVyaW0tMjAxNC1ydGN3ZWItMS0zLnBk Zg0KDQoNCg0KUmFuZGVsbCByZXZpZXdzIHJlY2VudCBjaGFuZ2VzIHRvIGRyYWZ0LWlldGYtcnRj d2ViLWRhdGEtcHJvdG9jb2wuICBTb21lIHF1ZXN0aW9ucyBjYW1lIHVwIHJlZ2FyZGluZyB0aGUg bmV3IHZhbHVlcyBmb3IgcHJpb3JpdHkuICBSYW5kZWxsIGxhcmdlbHkgZGVmZXJzIHRvIHRoZSBk cmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWwgZG9jdW1lbnQuDQoNCg0KSGFyYWxkIG5vdGVz IGhpcyBpc3N1ZSBhcm91bmQgcHJpb3JpdHkgaXMgc3RpbGwgb3Blbi4gIFJhbmRlbGwgd2lsbCB0 cnkgdG8gd3JpdGUgdXAgc29tZSB0ZXh0IGZvciByZXZpZXcgdG9kYXkgb3IgdG9tb3Jyb3cgc28g d2UgY2FuIG1vdmUgdG8gTGFzdCBDYWxsIEFTQVAuDQoNCg0KUmFuZGVsbCByZXZpZXdzIHJlY2Vu dCBjaGFuZ2VzIHRvIGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbC4gIA0KDQoNClJhbmRl bGwgYmVsaWV2ZXMgd2UgY2FuIGFkZHJlc3MgdGhlIGp1c3QtcmVtaW5kZWQgaXNzdWUgcXVpY2ts eSBhbmQgYXNrcyBmb3IgYW55IG90aGVyIG91dHN0YW5kaW5nIGlzc3Vlcy4gIElmIGhlIGNhbiBn ZXQgdGV4dCBkdXJpbmcgY29mZmVlIGJyZWFrIGhlIHdpbGwgZG8gaXQgc28gd2UgY2FuIHJlc29s dmUuICBJZiBub3QsIGhlJ2xsIGJlIG9uIHRoZSBhZ2VuZGEgZm9yIHRvbW9ycm93Lg0KDQoNCg0K DQpUaGUgbm90ZXMgZm9yIHRoZSBKU0VQIHJldmlldyBmcm9tIE1hcmNoIDE5dGgsIDIwMTQgYXJl IGluIHRoZSBnaXRodWIgY29tbWVudHMgZm9yIGVhY2ggb2YgdGhlIGlzc3Vlcy4gIFRob3NlIGNh biBiZSByZXZpZXdlZCBoZXJlOmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcCAuIElz c3VlcyB1cCB0byBJc3N1ZSAjMzkgd2VyZSBkaXNjdXNzZWQgYXQgdGhlIG1lZXRpbmcuIA0KDQoN CioqKiogQXVkaW8gSW50ZXJvcGVyYWJpbGl0eSAtIE1hZ251cyAqKioqDQoNCg0KZHJhZnQtcHJv dXN0LXJ0Y3dlYi1hdWRpby1jb2RlY3MtZm9yLWludGVyb3AtMDANCg0KDQoNCg0KSW5mb3JtYXRp b25hbCBkcmFmdCB0byBvZmZlciBndWlkYW5jZSBmb3IgYXVkaW8gY29kZWMgaW50ZXJvcCB3aXRo b3V0ID0NCnRyYW5zY29kZWVycw0KDQoNClByb3Bvc2FsOiBSZWZlcmVuY2UgdGhpcyBkcmFmdCBm b3JtIGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvDQoNCg0KU29tZSBwcm9ibGVtYXRpYyBzdGF0ZW1l bnRzIChlLmcuIE9QVVMgaXMgZGVwbG95ZWQgb3V0c2lkZSBvZiBydGN3ZWIuID0NCkc3MjIgZ3Jv c3NseSBpbmZlcmlvciB0byBvcHVzLikgU3VnZ2VzdCBhdm9pZGluZyB2YWx1ZSBqdWRnZW1lbnRz Lg0KQWdyZWUgdGhhdCB2YWx1ZSBqdWRnZW1lbnQgc2hvdWxkIGJlIGJhc2VkIG9uIGFjdHVhbGx5 IHdpZGUgZGVwbG95bWVudCwgPQ0KZXRjLg0KDQoNCmRpc2N1c3Npb24gYWJvdXQgY29kZWMgYXZh aWxhYmlsaXR5IGluIGJyb3dzZXJzDQoNCg0KQnJvd3NlcnMgYXJlIGxpbWl0ZWQgdG8gY29kZWNz IGV4cG9zZWQgYnkgT1MgZm9yIHZhcmlvdXMgcmVhc29ucyAoZS5nLiByb3lhbHRpZXMpDQpxdWVz dGlvbiBhYm91dCB2YWx1ZSBvZiBkb2luZyB0aGlzIGluIElFVEYgdnMgd29ya2luZyBkaXJlY3Rs eSB3aXRoIGJyb3dzZXIgdmVuZG9ycy4NCg0KDQoqKiBObyBjb25zZW5zdXMgdG8gcmVmZXJlbmNl IGRyYWZ0DQoNCg0KUHJvcG9zYWw6IFdHIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQNCg0KDQoqKiBu byBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQuIEF1dGhvcnMgYXNrZWQgdG8gY29udGludWUgYXMg bm9uLXdnIGRyYWZ0LiBNYXkgYmUgYmV0dGVyIHRvIHByb2dyZXNzIGluIG90aGVyIHZlbnVlcy4N Cg0KDQoNCg0KKioqKiBKU0VQIGlzc3VlcyBjb250aW51ZWQgKioqDQoNCg0KSXNzdWUgMjE6IElz IG0tbGluZSByZWN5Y2xpbmcgYSBNVVNUPyBFS1IgZG9lcyBub3QgcmVtZW1iZXIgYSBjb25zZW5z dXMgZm9yIG1hbmRhdG9yeSBtLWxpbmUgcmVjeWNsaW5nLiBDb21tZW50cyB0aGF0IGJlaGF2aW9y IHNob3VsZCBiZSBkZXRlcm1pbmlzdGljLg0KDQoNClJlc29sdXRpb246IExlYXZlIHRleHQgYXMg aW4sIGFzayBDaHJpc3RlciB0byBwcm92aWRlIGV4YW1wbGUgb24gd2h5IHdlIG5lZWQgdG8gcmVz dHJpY3QgdG8gcG9ydCAwLCB0aGVuIHJlYWRkcmVzcy4gRG8gbm90IGhvbGQgcHVibGljYXRpb24g b2YgZG9jdW1lbnQgcGVuZGluZyBpc3N1ZS4gKGNsb3NlIGlzc3VlKQ0KDQoNCklzc3VlIDE5OiBF bmNvdXJhZ2UgbWVyZ2luZyBvZiBjb21tb24gbS1saW5lIGF0dHJpYnV0ZXMgdG8gc2Vzc2lvbi1s ZXZlbD8gQ3VycmVudCB0ZXh0IGhhcyBNQVkuIElzc3VlIHByb3Bvc2VzIG1vdmluZyB0byBTSE9V TEQuDQoNCg0KRGlzY3Vzc2lvbiBhYm91dCBpbnRlcm9wIGlzc3Vlcy4gTWVudGlvbiB0aGF0IGlu dGVyb3Agd2l0aCBsZWdhY3kgZGV2aWNlcyB3aWxsIG5lZWQgc29tZSBzb3J0IG9mIGdhdGV3YXlz Lg0KDQoNCkFkZGluZyBuZXcgbS1saW5lcyBjb3VsZCBmb3JjZSBjaGFuZ2VzIHRocm91Z2hvdXQg U0RQLCB3aGljaCBjb3VsZCBiZSBzdXJwcmlzaW5nLiBNYXkgbmVlZCB0byBsb29rIGF0IHdoYXQg dGhpbmdzIGFyZSBsaWtlbHkgdG8gY2hhbmdlIG92ZXIgYSBzZXNzaW9uLg0KDQoNClJlc29sdXRp b246IE1ha2UgZXhpc3RpbmcgdGV4dCBTSE9VTEQgTk9ULCBhZGQgYSBNVVNUIGZvciB0aGluZ3Mg dGhhdCBhcmUgZXhwbGljaXRseSByZXF1aXJlZCB0byBiZSB0aGUgc2FtZSBmb3IgYWxsIG0tbGlu ZXMuDQoNCg0KSXNzdWUgMTU6IFByb3ZpZGUgZXhhbXBsZSBvZiBob3cgdG8gZG8gYW4gaW5hY3Rp dmUgc3RyZWFtLg0KDQoNCkFzayBmb3Igc29tZW9uZSB0byBwcm92aWRlIGV4YW1wbGUuDQoNCg0K SXNzdWUgNjogc2N0cG1hcCBmb3IgPw0KDQoNClJlc29sdXRpb246IEplc3NlcCB0byBoZWxwIHJl c29sdmUuIE1heSBiZSAob3Igc2hvdWxkIGJlKSBkZWZpbmVkIGluIHNjdHAtc2RwIGRyYWZ0Lg0K DQoNCklzc3VlIDU6IFdoZW4gdG8gdXNlIGE9aW1hZ2VhdHRyDQoNCg0KVHJ5aW5nIHRvIHJlc29s dmUgaW4gVlA4IHBheWxvYWQgZHJhZnQuIEFkZCBhZHZpc2UgaGVyZSBhZnRlciB0aGF0IGRyYWZ0 IGlzIGF2YWlsYWJsZT8NCg0KDQpPcGVuIGlzc3VlOiBIb3cgdG8gc2lnbmFsIGhhcmQgdXBwZXIg Ym91bmRzIG9mIHJlc29sdXRpb24geW91IGFyZSB3aWxsaW5nIHRvIHJlY2VpdmUsIHZzIHNpZ25h bGluZyBwcmVmZXJyZWQgcmVzb2x1dGlvbj8NCg0KDQpSZXNvbHV0aW9uOiBIYXJhbGQgdG8gcHJv cG9zZSB0ZXh0IG9uIHJlc29sdXRpb24gaGludHMvcHJlZmVyZW5jZXMuICBDdWxsZW4gdG8gb3Bl biBuZXcgaXNzdWUgYWJvdXQgaGFyZCBtYXhpbXVtcyBbYmVmb3JlIHdlIGdldCBmaW5pc2hlZCB3 aXRoIHRoZSByZXN0IG9mIHRoZSBpc3N1ZXNdDQoNCg0KSXNzdWUgMzogSG93IGlzIEFwcElEIHVz ZWQ/DQoNCg0KUmVzb2x1dGlvbjogRG8gd29yayBpbiBidW5kbGUsIG1ha2UgSlNFUCBwb2ludCB0 byB0aGVyZS4gU291aGFzIHRvIHByb3ZpZGUgcHVsbCByZXF1ZXN0IHRvIHBvaW50IHRvIGFjdHVh bCBwYXJ0IG9mIGJ1bmRsZSBkcmFmdCwgU2VhbiB0byBwdXNoIHdvcmsgdG8gZ2V0IHRoZSByaWdo dCB0aGluZyBpbiBidW5kbGUuDQoNCg0KSXNzdWUgMjogU2Vzc2lvbiBSZWh5ZHJhdGlvbg0KDQoN ClJlc29sdXRpb246IFB1bGwgb3V0IG9mIHNwZWMuDQoNCg0KSXNzdWUgMjM6IENyZWF0ZUFuc3dl ciBhbmQgbm9uLXRyaWNrbGUgb2ZmZXJzDQoNCg0KUmVzb2x1dGlvbjogR28gd2l0aCBhcHBsaWNh dGlvbiByZXNwb25zaWJpbGl0eSwgYWRkICIgY2FuLXRyaWNrbGUgYXR0cmlidXRlIHdpdGggIHRy dWUvZmFsc2UvdW5kZWZpbmVkIHZhbHVlcy4sIHVwIHRvIHdlYnJ0YyBzcGVjcyB0byBmaWd1cmUg b3V0IGRldGFpbHMuDQoNCg0KSXNzdWUgMzA6IE5lZWQgd2F5IHRvIGluZGljYXRlIHVwcGVyIGJv dW5kIG9uIHJlc29sdXRpb24vZnJhbWUgcmF0ZSB0aGF0IGNhbiBiZSByZWNlaXZlZC4NCg0KDQpJ c3N1ZSBmb3IgcGF5bG9hZCB3Zz8gTmVlZHMgdG8gYmUgZG9uZSBvbiBwZXItY29kZWMgYmFzaXMu IEhhcyBiZWVuID0NCm1lbnRpb25lZCBidXQgbm90IGRpc2N1c3NlZCBpbiBwYXlsb2FkLg0KDQoN ClF1ZXN0aW9ucyBhYm91dCBob3cgdG8gaGFuZGxlIG11bHRpcGxlIHN0cmVhbXMuDQoNCg0KUXVl c3Rpb25zIHRvIHJvb206DQoNCg0KMTogTXVzdCBoYXZlIHRvIHNoaXA6IDQNCjI6IERhcm4gTmlj ZSB0byBoYXZlOiAxMA0KMzogVXNlIHdoZW4gYXZhaWxhYmxlLCB3aGVuIG5vdCBhdmFpbGFibGUg aXQ9RTI9ODA9OTlzIG5vdDogOA0KNDogRG9uPUUyPTgwPTk5dCB3YW50IHRvIHRhbGsgYWJvdXQg dGhpcywgd2FudCB0byBoYXZlIGx1bmNoOiA2DQoNCg0KUmVzb2x1dGlvbjogQXNzaWduIHRvIFJh bmRhbCB0byBnZW5lcmF0ZSBwcm9wb3NlZCB0ZXh0LCBkaXNjdXNzIGZ1cnRoZXIgb24gbGlzdC4g Rm9yIGFueXRoaW5nIHBheWxvYWQgc3BlY2lmaWMsIHBlb3BsZSBzaG91bGQgYmUgdHJ5aW5nIHRv ICByZXNvbHZlIGluIHRoZSBwYXlsb2FkIHdnLiBBY3Rpb24gaXRlbSB0byBBRHMgdG8gYXNzaXN0 IGluIG1ha2luZyB0aGF0IGhhcHBlbi4NCg0KDQpJc3N1ZSA0OiBDTmFtZSBnZW5lcmF0aW9uIGZv ciBNU1RzDQoNCg0KUmVzb2x1dGlvbjogSm9uYXRoYW4gTGVubm94IHRvIGdlbmVyYXRlIGdlbmVy YWwgZ3VpZGFuY2Ugb24gTFMgZ3JvdXAgaGFuZGxpbmcuIEN1bGxlbiB3aWxsIGdlbmVyYXRlIGFj dHVhbCB0ZXh0IGhhdmUgRmxlbW1pbmcgcmV2aWV3Lg0KDQoNCnJ0Y3dlYi1pbnRlcmltLW5vdGVz LnR4dA0KDQoNCmksDQoNCg0KSGVyZSBpcyB0aGUgbm90ZXMgZm9yIFJUQ1dFQiBpbnRlcmltIGRh eSAzDQoNCg0KUHJpb3JpdHkgLSBKZXN1cA0KLS0tLS0tLS0NCkplc3VwICBwcmVzZW50ZWQgYSBw cm9wb3NhbA0KDQoNClNvbWUgZGlzY3Vzc2lvbiBvdmVyIHRoZSB2YWx1ZXMgdGhhdCBzaG91bGQg YmUgdXNlZCBmb3IgcHJpb3JpdHkuDQoNCg0KQ29uY2x1c2lvbjogSmVzdXAgd2lsbCBhZGQgYSB0 YWJsZSBvZiB2YWx1ZXMgdG8gdXNlIHRoYXQgaXMgYmVsaWV2ZWQgdG8gcHJvdmlkZSB0aGUgMngg cGVyIHByaW9yaXR5IGxldmVsLiBXaWxsIHByb3ZpZGUgdGhlIHRleHQgdG9kYXkuDQoNCg0KTnVs bCBDaXBoZXIgLSBHaXJpDQotLS0tLS0tLS0tLQ0KDQoNClByb3Bvc2FsIHRvIGFsbG93IE5VTEwg Q0lQSEVSIHRvIHN1cHBvcnQgcHJveHkgY2FzZXMgd2l0aGluIGEgc2luZ2xlIGRldmljZS4NCg0K DQpRdWVzdGlvbnMgYW5kIGRpc2N1c3Npb24gcmVnYXJkaW5nIGFjdHVhbCBwZXJmb3JtYW5jZSBo aXQuDQoNCg0KRGlzY3Vzc2lvbiBhYm91dCB0aGUgZGFuZ2VycyBvZiBudWxsIGNpcGhlcnMsIGFu ZCB0aGUgbmVlZCB0byBrbm93IHRoYXQgeW91ciBhcmUgYWN0dWFsbHkgdGFsa2luZyB0aGUgcHJv eHkuIE90aGVyd2lzZSB0aGUgZG93bmdyYWRlZCBhdHRhY2suDQoNCg0KQ29uY2x1c2lvbjogQSBz b2xpZCBjb25zZW5zdXMgZXhpc3QgZnJvbSBiZWZvcmUgdG8gZGlzYWxsb3cgTlVMTCBjaXBoZXJz LiBUaGVyZSBhcmUgbm8gY29uc2Vuc3VzIHRvIHJlb3BlbiB0aGF0IGRlY2lzaW9uLg0KDQoNCg0K DQpTZWN1cml0eSAtIE1hcnRpbg0KLS0tLS0tLS0NCg0KDQpJZGVudGl0eQ0KLS0tLS0tLS0tDQoN Cg0KSXNzdWUgMTogQXMgc3RhdGVkIG9uIHNsaWRlDQoNCg0KQ3VsbGVuIHJlcXVlc3QgdG8gY2xh cmlmeSB0aGF0IHRoZSB2ZXJzaW9uIGlzIGFuIG9wYXF1ZSB0b2tlbi4gQ3VsbGVuIHRvIHNlbmQg ZGV0YWlscyBmb3IgaGlzIHJlcXVlc3QgdG8gTWFydGluLg0KDQoNCklzc3VlIDI6IFByb3Bvc2Fs IGFjY2VwdGVkDQoNCg0KSmltIGNvbW1lbnRlZCB0aGF0IHRoZXJlIHNvbWUgaW5jb25zaXN0ZW50 IGRpc2N1c3Npb24gYWJvdXQgcG9wIHVwcyBhbmQgaS1mcmFtZXMuDQoNCg0KSmltIFNwcmluZyBj b21tZW50ZWQgdGhhdCB0aGUgcHJvcG9zZWQgbWVzc2FnZXMgc2hvdWxkIG5vdCBiZSBnZW5lcmF0 ZWQgd2hlbiB0aGUgdXNlci9icm93c2VyIHVzZXMgYnVpbHQgaW4gSWRQLg0KDQoNCklzc3VlIDM6 IE11bHRpcGxlIGZpbmdlcnByaW50cyBhcmUgcHJvdmlkZWQgYXMgYWx0ZXJuYXRpdmUgb25lcy4N Cg0KDQpJc3N1ZSA0OiBBcyBwcm9wb3NlZCBpbiBzbGlkZS4NCg0KDQpJc3N1ZSA1OiBUZWQgKGFz IGluZGl2aWR1YWwpIGFza2VkIGlmIHRoaXMgbWFwcGluZyBzaG91bGQgYmUgc3BlY2lmaWVkIGlu IHNlcGFyYXRlIGRvY3VtZW50IHRoYXQgY2FuIHByb2dyZXNzIGluZGVwZW5kZW50bHkuDQoNCg0K Q29uY2x1ZGVkOiBBZnRlciBkaXNjdXNzaW9uIE1hcnRpbiB3aWxsIHdyaXRlIHRoaXMgcGFydCBh cyBhIHNlcGFyYXRlIGRvY3VtZW50IHRvIGVuYWJsZSBiZXR0ZXIgcmV2aWV3Lg0KDQoNCklzc3Vl IDY6DQoNCg0KSmltIFNwcmluZyBhc2tlZCBhYm91dCBpZiB0aGVyZSBhcmUgZXhwbGljaXQgdGV4 dCBiZXR3ZWVuIElkUCBhbmQgSXNvbGF0aW9uLiBQZW9wbGUgYWdyZWUgdGhhdCB0aGVyZSBzaG91 bGQgYmUuDQoNCg0KQ3VsbGVuLCBhc2tlZCBhYm91dCB0aGUgVVggYXNwZWN0cyBvZiB0aGlzLiBU aGUgYmFzaWNzIGFyZSBpbiBwbGFjZSBidXQgZnVydGhlciBpbXByb3ZlbWVudHMgbWF5IGJlIHBv c3NpYmxlIG9uIHRoZSByZWNlaXZlciBzaWRlLiANCg0KDQpRdWl0ZSBzb21lIGRpc2N1c3Npb24g b24gaG93IHRoaW5ncyB3b3JrLiBJbmNsdWRpbmcgd2hlbiBJZGVudGl0eSBhc3NlcnRpb24gY29t ZXMgaW4gYW5kIHdoYXQgaGFwcGVucyB3aXRoIG1lZGlhIHVudGlsIGl0IGhhcHBlbnMuDQoNCg0K RGlzY3Vzc2lvbiBpZiB0aGUgaXNvbGF0aW9uIHNob3VsZCBiZSBvbiB0aGUgcGVlckNvbm5lY3Rp b24gbGV2ZWwgcGVyIGRpcmVjdGlvbiBvciBvbiBpbmRpdmlkdWFsIHRyYWNrLg0KDQoNCkNvbmNs dXNpb246IFN0cm9uZyBjb25zZW5zdXMgdG8gdXNlIEFMUE4gYXMgdGhlIG1ldGhvZCB0byBhY2hp ZXZlIHJlY2VpdmUgc2lkZSBpc29sYXRpb24uIENoYWlycyB3aWxsIHJlcXVlc3QgYWRvcHRpb24g b2YgZHJhZnQtdGhvbXNvbi1ydGN3ZWItYWxwbi4NCg0KDQpOZXcgaXNzdWU6IEtleS1jb250aW51 dHkgYW5kIGRpc2N1c3Mgb24gcmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0KDQoNCkVLUiBjb21tZW50 ZWQgdGhhdCB0aGUgaXNzdWUgaXMgdGhhdCBicm93c2VycyBoYXMgbm90IGJ1aWx0IGFueSBrZXkt Y29udGludXR5IGhhbmRsZXIuIFRoZXJlIGFyZSBpc3N1ZXMgaGVyZSB0aGF0IGlzIG5vbi10cml2 aWFsLg0KDQoNCg0KDQpDb25zZW50IEZyZXNobmVzcyAtIE1hcnRpbg0KLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQpDb25jbHVzaW9uIG9uIHRyYW5zbWlzc2lvbjogVXNlIGEgImZpeGVkIiBjYWRlbmNl IHRyYW5zbWlzc2lvbiBzY2hlbWVkIHdpdGggbmV3IFRyYW5zYWN0aW9uIElEcyBmb3IgZWFjaCB0 cmFuc21pc3Npb24uIFRoZSBjYWRlbmNlIHNob3VsZCBiZSBhcHByb3hpbWF0ZSA1IHNlY29uZHMu DQoNCg0KVG8gYXZvaWQgY2xvY2sgc3luY3Job25pemF0aW9uIHRoZSBjYWRlbmNlIHNob3VsZCBi ZSBqaXR0ZXIsIHBlcmhhcHMgaW4gdGhlIGFyZWEgb2YgNC02IHNlY29uZHMuDQoNCg0KQ29uc2Vu dCByZXZvY2F0aW9uDQoNCg0KVXNpbmcgYW55IGF1dGhlbnRpY2F0ZWQgcmVzcG9uc2UgaW5kaWNh dGUgY2xvc3VyZSBvciBlcnJvciwgZS5nLiBUTFMgZXJyb3IuIElmIHlvdSByZWNlaXZlIGEgU1RV TiBlcnJvciByZXNwb25zZSB0aGF0IGlzIGF1dGhlbnRpY2F0ZWQgdGhhdCBpcyByZXZvY2F0aW9u LiBXaGF0IGNvZGUgdG8gdXNlIGlzIGZvciBwcm9wb3NhbC4NCg0KDQpDb25zZW50IGZvciBUQ1AN Cg0KDQpOb3QgbmVlZGVkIGZvciBUQ1AuIFJlcXVpcmVkIGZvciBVRFAgZW5kLXRvLWVuZC4NCg0K DQpVc2luZyBjb25zZW50IG1lY2hhbmlzbSB0byBtZWFzdXJlIFJUVCBpcyBhbGxvd2VkIG9uIFRD UC4gQnV0IG5vdCByZXF1aXJlZCB0byBpc3N1ZS4NCg0KDQpBIGVuZHBvaW50IHRoYXQgZnVydGhl ciByZWxheXMgbWVkaWEgaGF2ZSByZXNwb25zaWJpbGl0eSBmb3Igd2hhdCBpdCBmb3J3YXJkcy4= --001a11c1faca8349f704fba598f9-- From nobody Thu Jun 12 10:51:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B621A0201 for ; Thu, 12 Jun 2014 10:51:12 -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 0zthPvyZltPA for ; Thu, 12 Jun 2014 10:51:09 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F88B1A01CE for ; Thu, 12 Jun 2014 10:51:08 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so929440wes.37 for ; Thu, 12 Jun 2014 10:51:07 -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=HxVFJ6PicgkQRre5XVKsFpQQClKmT3oU0SCStJVoGmE=; b=gA9V+ckFtzUzITaZpBvlnS6AE+ftjWW0sAwruPsKVlvx9J1HGMWeP07nOhTkFqAlO9 E3LGWqKXVQv2sWZ/izPhBOWj4UvnnHAg6HWsrp4xbVjVNCKV01pbjjD/B6JLX5mt6FVB 8BqUIKjrM4+JJB3vCDqnSCGszTQa6XpJiivyQtOBxP4HExZA1w+lDWu9scxMqkpF1VBi V3fKc94Eo9WXfU9s4EIXXMZW275U/mvZ9cKu9nfM7KH+q2UUUJxerFz8i4wD74nl0TBU ffuWTEhqvKI8HY1PzqxytjZVICQq27FtBMKjCDa+jqhUk/09d6zoaiUTOmj+dR5Ul2Mb RySg== X-Gm-Message-State: ALoCoQmwjUfPSho0Jf0b/VgBiZD21e+QmT0nc7Bjti0CKIq+JuHav/kfxBpgOZSmkxAPyGCQ+OF9 X-Received: by 10.194.87.200 with SMTP id ba8mr64333996wjb.28.1402595467033; Thu, 12 Jun 2014 10:51:07 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx.google.com with ESMTPSA id hs8sm34612665wib.10.2014.06.12.10.51.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 10:51:05 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so4032746wib.7 for ; Thu, 12 Jun 2014 10:51:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.243.104 with SMTP id wx8mr62280252wjc.32.1402595465075; Thu, 12 Jun 2014 10:51:05 -0700 (PDT) Received: by 10.216.162.10 with HTTP; Thu, 12 Jun 2014 10:51:04 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> Date: Thu, 12 Jun 2014 13:51:04 -0400 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=089e014940f075a2d404fba734e2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8iLmyzyk4VFDF14EESSnaz-MnYQ Cc: =?UTF-8?Q?Javier_Cervi=C3=B1o?= , "rtcweb@ietf.org" Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:51:12 -0000 --089e014940f075a2d404fba734e2 Content-Type: text/plain; charset=UTF-8 On the related note, is there TLS-ICE? Would not it be simpler to open a TLS connection to the server with provided fingerprint validation and use RFC 4571 framing with plain RTP? This will also have a higher chance of traversing firewalls then plain TCP. Even if DTLS is used over this TLS connection, it would still make sense to use TLS instead of TCP for better firewall traversal. _____________ Roman Shpount On Thu, Jun 12, 2014 at 8:12 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > Since we are digressing a lot I changed the subject. > > > TURN servers are the least obnoxious way to make sure apps can work in > > the presence of symmetric NATs. > > [Raju] Agreed. However, if there is no symmetric NAT(s) in the path webrtc > can find a connection without the TURN servers. I think, that is highly > preferred and thus explains the "MUST" for TCP-ICE requirement. No matter > how much we trust a TURN server, it is still a *middle box* and there will > be privacy concerns with it!! > > > > > Then I see the following requirement in > draft-ietf-rtcweb-use-cases-and- > > requirements-14. It did not mention use of TURN in the text. > > > > > > F18 The browser must be able to send streams and > > > data to a peer in the presence of NATs and > > > Firewalls that block UDP traffic. > > > > Yes. Using TURN servers is the way in which it is possible to fulfil > > this requirement. > [Raju] Yes, I think use of STUN servers only if direct connection using > TCP ICE is not possible (due to symmetric NATs). Due to various issues with > TURNs or middle boxes (latency, cost of service, increased loss of packets) > ICE RFC recommends the following priorities for ICE candidates. I don't see > webrtc has an overriding requirement for this. At the end, it's always > application/user choice to use or not use TURN or other middle boxes. To > facilitate this, IMHO browser requirement of MUST for TCP-ICE is justified. > > http://tools.ietf.org/html/rfc5245#section-4.1.2.2 > If these concerns are important, the > type preference for relayed candidates SHOULD be lower than host > candidates. The RECOMMENDED values are 126 for host candidates, 100 > for server reflexive candidates, 110 for peer reflexive candidates, > and 0 for relayed candidates. > > BR > Raju > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e014940f075a2d404fba734e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the related note, is there TLS-ICE? Would not it be sim= pler to open a TLS connection to the server with provided=C2=A0fingerprint = validation and use RFC 4571 framing with plain RTP? This will also have a h= igher chance of traversing firewalls then plain TCP. Even if DTLS is used o= ver this TLS connection, it would still make sense to use TLS instead of TC= P for better firewall traversal.

_____________
Roman Sh= pount


On Thu, Jun 12, 2014 at 8:12 AM, Makaraj= u, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com= > wrote:
Since we are digressing a lot I changed the = subject.

> TURN servers are the least obnoxious way to make sure apps can work in=
> the presence of symmetric NATs.

[Raju] Agreed. However, if there is no symmetric NAT(s) in the path webrtc = can find a connection without the TURN servers. I think, that is highly pre= ferred and thus explains the "MUST" for TCP-ICE requirement. No m= atter how much we trust a TURN server, it is still a *middle box* and there= will be privacy concerns with it!!


> > Then I see the following requirement in draft-ietf-rtcweb-use-cas= es-and-
> requirements-14. It did not mention use of TURN in the text.
> >
> > =C2=A0 =C2=A0 F18 =C2=A0 =C2=A0 The browser must be able to send = streams and
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 data to a peer in the p= resence of NATs and
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Firewalls that block UD= P traffic.
>
> Yes. Using TURN servers is the way in which it is possible to fulfil > this requirement.
[Raju] Yes, I think use of STUN servers only if direct connection using TCP= ICE is not possible (due to symmetric NATs). Due to various issues with TU= RNs or middle boxes (latency, cost of service, increased loss of packets) I= CE RFC recommends the following priorities for ICE candidates. I don't = see webrtc has an overriding requirement for this. At the end, it's alw= ays application/user choice to use or not use TURN or other middle boxes. T= o facilitate this, IMHO browser requirement of MUST for TCP-ICE is justifie= d.

http://tools.ietf.org/html/rfc5245#section-4.1.2.2
=C2=A0 =C2=A0If these concerns are important, the
=C2=A0 =C2=A0type preference for relayed candidates SHOULD be lower than ho= st
=C2=A0 =C2=A0candidates. =C2=A0The RECOMMENDED values are 126 for host cand= idates, 100
=C2=A0 =C2=A0for server reflexive candidates, 110 for peer reflexive candid= ates,
=C2=A0 =C2=A0and 0 for relayed candidates.

BR
Raju

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

--089e014940f075a2d404fba734e2-- From nobody Thu Jun 12 11:04:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FFF1A01F3 for ; Thu, 12 Jun 2014 11:04: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 OJGbaQO3teBW for ; Thu, 12 Jun 2014 11:04:32 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE211A015C for ; Thu, 12 Jun 2014 11:04:31 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so1591150wgh.26 for ; Thu, 12 Jun 2014 11:04: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=hjYRfA4Y3Y4xi9VkqGuAMExW07i3DDsc2El45eV7M5c=; b=lqBnW1PdOKWQJv1wJ1j4NElPehlr3ZjcJj0uJmNVmRPMJDqPYwkLkc+J2GP3X6/HIY 4d2lQd4jMe7rPGJPYkXQi988Cz2vxw5x3NUESvZzA8dp4jMubjwb4+GdC+DNGWV4XDdm KN6UZ0QtE0vCKWCUKqeNKZ2oZgB7z9Yl8b/4rY+VsShlq/dLFgF4pAsGIWQNncuyOw05 me8rCk8iuVxlPsbULR4zRKoTUXIakaK9mPl/PTdN0fKWJp1JZv5oOyWHHV6+krwd5hJ7 SfHFiujhkUF0I8G98lYOstqL8ou67yqfgHjMeCgEUlsynPRA3dfID3oBako3qSQdfDP2 E0DQ== X-Gm-Message-State: ALoCoQkhIXMR1hHQCHIaunhalpNLSDhqceoa9KHpxRxEOV/Eimnos4n+TRV5b9Ml1bDImAreV7cL X-Received: by 10.180.218.41 with SMTP id pd9mr8575829wic.7.1402596268220; Thu, 12 Jun 2014 11:04:28 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx.google.com with ESMTPSA id wv9sm2454126wjc.28.2014.06.12.11.04.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 11:04:26 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so3436980wib.3 for ; Thu, 12 Jun 2014 11:04:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.243.104 with SMTP id wx8mr62375843wjc.32.1402596266308; Thu, 12 Jun 2014 11:04:26 -0700 (PDT) Received: by 10.216.162.10 with HTTP; Thu, 12 Jun 2014 11:04:26 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> Date: Thu, 12 Jun 2014 14:04:26 -0400 Message-ID: From: Roman Shpount To: Ca By Content-Type: multipart/alternative; boundary=089e014940f0377e5504fba76463 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RGNWiHvGwz8ScVSqSV9vEzqi7wY Cc: "rtcweb@ietf.org" , =?UTF-8?Q?Javier_Cervi=C3=B1o?= Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:04:34 -0000 --089e014940f0377e5504fba76463 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 8:37 AM, Ca By wrote: > I believe they will install a TURN server in parallel to a firewall, like > many enterprises install SBCs in parallel to firewalls. Enterprise > firewalls are generally not optimized for multimedia traffic. > May I remind that SBCs installed in parallel to firewalls are usually called SIP ALGs and they are mostly broken ( https://wiki.freeswitch.org/wiki/ALG)? I am afraid that most of the locally provided TURN servers will be terribly mis-configured, used when they should not, and generally cause more harm then good. For local TURN servers to work correctly you would need local network administrators which are educated in correct WebRTC setup and who are interested in spending time to make their setup to work correctly. In most cases this would be highly unlikely. All an administrator would do is turn on some setting in their firewall labeled "Enable WebRTC TURN" which would more likely turn on something no one will understand and cause all types of havoc. Based on our experience with SIP, expecting local network administrators to provide any working solution for NAT traversal is extremely optimistic. _____________ Roman Shpount --089e014940f0377e5504fba76463 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 12, 2014 at 8:= 37 AM, Ca By <cb.list6@gmail.com> wrote:

I believe they will install a TURN server in par= allel to a firewall, like many enterprises install SBCs in parallel to fire= walls. Enterprise firewalls are generally not optimized for multimedia traf= fic.

May I remind that SBCs installed in parallel = to firewalls are usually called SIP ALGs and they are mostly broken (https://wiki.freeswitch.org/wiki= /ALG)?

I am afraid that most of the locally provided TURN serv= ers will be terribly mis-configured, used when they should not, and general= ly cause more harm then good. For local TURN servers to work correctly you = would need local network administrators which are educated in correct WebRT= C setup and who are interested in spending time to make their setup to work= correctly. In most cases this would be highly unlikely. All an administrat= or would do is turn on some setting in their firewall labeled "Enable = WebRTC TURN" which would more likely turn on something no one will und= erstand and cause all types of havoc. Based on our experience with SIP, exp= ecting local network administrators to provide any working solution for NAT= traversal is extremely optimistic.
_____________
Roman Shpount
=C2=A0
--089e014940f0377e5504fba76463-- From nobody Thu Jun 12 13:07:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0DA1B280A for ; Thu, 12 Jun 2014 13:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 dY9m-U47QaIL for ; Thu, 12 Jun 2014 13:07:41 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6837A1B27F4 for ; Thu, 12 Jun 2014 13:07:41 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5CK7cnS000156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 15:07:39 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s5CK7beu026205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 16:07:37 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 12 Jun 2014 16:07:37 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Roman Shpount Thread-Topic: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) Thread-Index: AQHPhjeI2RSVoNelQ0ussSjLxoIP2ZtuBGEA///he/A= Date: Thu, 12 Jun 2014 20:07:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cyjWhcIbWgA9yrSb9fJXKd0sGOw Cc: "rtcweb@ietf.org" , =?utf-8?B?SmF2aWVyIENlcnZpw7Fv?= Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 20:07:42 -0000 Pk9uIHRoZSByZWxhdGVkIG5vdGUsIGlzIHRoZXJlIFRMUy1JQ0U/IFdvdWxkIG5vdCBpdCBiZSBz aW1wbGVyIHRvIG9wZW4gYSBUTFMgY29ubmVjdGlvbiA+dG8gdGhlIHNlcnZlciB3aXRoIHByb3Zp ZGVkIGZpbmdlcnByaW50IHZhbGlkYXRpb24gYW5kIHVzZSBSRkMgNDU3MSBmcmFtaW5nIHdpdGgg cGxhaW4gPlJUUD8gVGhpcyB3aWxsIGFsc28gaGF2ZSBhIGhpZ2hlciBjaGFuY2Ugb2YgdHJhdmVy c2luZyBmaXJld2FsbHMgdGhlbiBwbGFpbiBUQ1AuIEV2ZW4gaWYgPkRUTFMgaXMgdXNlZCBvdmVy IHRoaXMgVExTIGNvbm5lY3Rpb24sIGl0IHdvdWxkIHN0aWxsIG1ha2Ugc2Vuc2UgdG8gdXNlIFRM UyBpbnN0ZWFkIG9mID5UQ1AgZm9yIGJldHRlciBmaXJld2FsbCB0cmF2ZXJzYWwuDQoNCltSYWp1 XSBJQ0UgVENQIFJGQyA2NTQ0IGRvZXMgY292ZXIgYm90aCBUTFMgYW5kIERUTFMuIFBsZWFzZSBz ZWUgcGFnZSA2IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NDQjc2VjdGlvbi0zIA0K WWVzLCB5b3UgY2FuIHJ1biBwbGFpbiBSVFAgb24gdG9wIG9mIFRMUy1JQ0UsIGJ1dCBmb3Igd2Vi cnRjIHVzZSBpdCB3YXMgYWxyZWFkeSBkZWNpZGVkIHRvIHVzZSBEVExTLVNSVFAgZXZlbiBmb3Ig VENQLg0KDQpCUg0KUmFqdQ0KDQo= From nobody Thu Jun 12 13:18:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD5C1A0260 for ; Thu, 12 Jun 2014 13:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 PExWCB4_IpcB for ; Thu, 12 Jun 2014 13:17:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452881A025C for ; Thu, 12 Jun 2014 13:17:54 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5CKHqrl008512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 15:17:53 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s5CKHp8L008729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 16:17:52 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 12 Jun 2014 16:17:52 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Roman Shpount , Ca By Thread-Topic: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? Thread-Index: AQHPgD7abSYqU+IK/kuiw4z1j/rtWJtgeAnAgADlQQCAAAd3gIAAFI8AgAdIPQCAACqUAIAACU4AgAAKjQCAAWc18IAAXqgAgAAjEjiAAFCFgP//zz3wgAEAN4D//8KCkIAAS0wA//+9FvAADT+7gAAG5Jyg//+3OXP//+slAIABFZ2AgABfUoCAABnhAIAAKxTN///dohA= Date: Thu, 12 Jun 2014 20:17:51 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O_e3oXG8OLsplCoSoLMueBq0EJw Cc: =?utf-8?B?SmF2aWVyIENlcnZpw7Fv?= , "rtcweb@ietf.org" Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 20:17:57 -0000 DQo+PkkgYmVsaWV2ZSB0aGV5IHdpbGwgaW5zdGFsbCBhIFRVUk4gc2VydmVyIGluIHBhcmFsbGVs IHRvIGEgZmlyZXdhbGwsIGxpa2UgbWFueSA+PmVudGVycHJpc2VzID4+aW5zdGFsbCBTQkNzIGlu IHBhcmFsbGVsIHRvIGZpcmV3YWxscy4gRW50ZXJwcmlzZSBmaXJld2FsbHMgYXJlIGdlbmVyYWxs eSA+Pm5vdCBvcHRpbWl6ZWQgPj5mb3IgbXVsdGltZWRpYSB0cmFmZmljLg0KPk1heSBJIHJlbWlu ZCB0aGF0IFNCQ3MgaW5zdGFsbGVkIGluIHBhcmFsbGVsIHRvIGZpcmV3YWxscyBhcmUgdXN1YWxs eSBjYWxsZWQgU0lQIEFMR3MgYW5kID50aGV5IGFyZSBtb3N0bHkgYnJva2VuIChodHRwczovL3dp a2kuZnJlZXN3aXRjaC5vcmcvd2lraS9BTEcpDQoNCltSYWp1XSBXaGF0J3MgYnJva2VuIGlzIFNJ UCBBTEcgaW5zaWRlIGEgTkFUL3JvdXRlci4gRm9yIGJlYXJlciBmdW5jdGlvbmFsaXR5IHBvaW50 IG9mIHZpZXcsIFNCQ3MgYXJlIHN0YW5kYWxvbmUgc2VydmVycyBhbmQgdmVyeSBtdWNoIGFuYWxv Z291cyB0byBUVVJOIHNlcnZlcnMgKGFjdHVhbGx5IG1vcmUgdHJhbnNwYXJlbnQgdGhhbiBUVVJO IHNlcnZlcnMpLiBTQkNzIGhhdmUgYWRkZWQgZnVuY3Rpb25hbGl0eSBvZiBzaWduYWxpbmcgYW5j aG9yaW5nIHNvIHRoYXQgdGhlIHNpZ25hbGluZyBjb250ZW50IChlLmcuIFNEUCkgY2FuIGJlIG1v ZGlmaWVkIGFzIGFwcHJvcHJpYXRlbHkuIFN1Y2ggU0JDcyBhcmUgTk9UIGJyb2tlbiAod29ya3Mg d2l0aCBlbmNyeXB0aW9uKSBhbmQgaXMgYSBjcml0aWNhbCBhbmQgaW52YWx1YWJsZSBjb21wb25l bnQgZm9yIHNlcnZpY2VzIGxpa2UgVm9MVEUuDQpUaGUgU0JDcyBlbnRlcnByaXNlcyB1c2UgZmFs bCBpbnRvIG5vbi1OQVQvcm91dGVyIGltcGxlbWVudGF0aW9ucy4NCg0KQlINClJhanUNCg0K From nobody Thu Jun 12 14:16:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459E21A028B for ; Thu, 12 Jun 2014 14:16:12 -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 a0KIX7-SKq1E for ; Thu, 12 Jun 2014 14:16:10 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130371A026D for ; Thu, 12 Jun 2014 14:16:09 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id j15so2358125qaq.12 for ; Thu, 12 Jun 2014 14:16:09 -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=7dSzX+KKxpYRqE3UVRKiJS8LbV/Kuh/XX7v4QC9rwXQ=; b=XWR5dB/KbnBQDQvUNQlnXS7dAJhBS6YIRolifqM5urx6fdXaSKqNuO3JEOFty1y/2f rgqXoRXgyuoTJV3S4pkE1WO9scJPJnyJOtUMWr3QKl6MDzCiOAljyzZ4bIzXZkO12mCi Xmsm0kQGrB+VhLdV4UzA7j19/6zs24sqY4fJYukaKpP/jE/v3A36fgp+vN5M2gZkLrwM 0qILu6YGQ0zxMr1agqAThdmsQXgodL0htdOZEuNBC7gUttlTrmqHH9q/cXB7u1EAji9q 7dN+AegFlo5gWtK1et1CAXFNTvRUpE8wiy/xdOyHgnl8hH/9szyrTV3ppiwcAOrdWiwf Jb1g== X-Gm-Message-State: ALoCoQmycCabIHjX0Ky15EvYBjoHAu8jFPGmNN+NHgezCJtOoxd72mhjo/wQQNzpe21/gPha0yr9 X-Received: by 10.224.114.145 with SMTP id e17mr64974087qaq.53.1402607769246; Thu, 12 Jun 2014 14:16:09 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by mx.google.com with ESMTPSA id l10sm3214511qae.41.2014.06.12.14.16.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 14:16:08 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id m5so2319393qaj.23 for ; Thu, 12 Jun 2014 14:16:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.63.145 with SMTP id b17mr10136574qai.38.1402607768403; Thu, 12 Jun 2014 14:16:08 -0700 (PDT) Received: by 10.96.210.68 with HTTP; Thu, 12 Jun 2014 14:16:08 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> Date: Thu, 12 Jun 2014 17:16:08 -0400 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=047d7bdc0e4ccb89a104fbaa1176 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zig8HEDe7rnIsi0zN1wjK-Cc_cE Cc: "rtcweb@ietf.org" , =?UTF-8?Q?Javier_Cervi=C3=B1o?= Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:16:12 -0000 --047d7bdc0e4ccb89a104fbaa1176 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 4:07 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > >On the related note, is there TLS-ICE? Would not it be simpler to open a > TLS connection >to the server with provided fingerprint validation and use > RFC 4571 framing with plain >RTP? This will also have a higher chance of > traversing firewalls then plain TCP. Even if >DTLS is used over this TLS > connection, it would still make sense to use TLS instead of >TCP for better > firewall traversal. > > [Raju] ICE TCP RFC 6544 does cover both TLS and DTLS. Please see page 6 > http://tools.ietf.org/html/rfc6544#section-3 > Yes, you can run plain RTP on top of TLS-ICE, but for webrtc use it was > already decided to use DTLS-SRTP even for TCP. > > I am not sure this is right since TLS or DTLS are supposed to run on top of RFC 4571 on top of TCP. What I was asking about was RTP on top of RFC 4571 on top of TLS. _____________ Roman Shpount --047d7bdc0e4ccb89a104fbaa1176 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Jun 12, 2014 at 4:07 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>On the related note, is there TLS-ICE? Would not = it be simpler to open a TLS connection >to the server with provided fing= erprint validation and use RFC 4571 framing with plain >RTP? This will a= lso have a higher chance of traversing firewalls then plain TCP. Even if &g= t;DTLS is used over this TLS connection, it would still make sense to use T= LS instead of >TCP for better firewall traversal.

[Raju] ICE TCP RFC 6544 does cover both TLS and DTLS. Please see page= 6 http://tools.ietf.org/html/rfc6544#section-3
Yes, you can run plain RTP on top of TLS-ICE, but for webrtc use it was alr= eady decided to use DTLS-SRTP even for TCP.


I am not sure this is right since TLS = or DTLS are supposed to run=C2=A0on top of RFC 4571 on top of TCP. What I w= as asking about was RTP on top of RFC 4571 on top of TLS.
_______= ______
Roman Shpount
=C2=A0
--047d7bdc0e4ccb89a104fbaa1176-- From nobody Fri Jun 13 05:54:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CA61B2817 for ; Fri, 13 Jun 2014 05:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ucLsfmDReH8 for ; Fri, 13 Jun 2014 05:54:52 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15DF1A04CA for ; Fri, 13 Jun 2014 05:54:50 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201406131454452773; Fri, 13 Jun 2014 14:54:45 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" , "'Pal Martinsen \(palmarti\)'" References: <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070 205@alvestrand.no> <017301cf8624$d4a68060$7df38120$@stahl@intertex.se> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> <5399BFE6.5050 003@alvestrand.no> In-Reply-To: <5399BFE6.5050003@alvestrand.no> Date: Fri, 13 Jun 2014 14:54:48 +0200 Message-ID: <00a601cf8706$a89a1ee0$f9ce5ca0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+GTq58opzbmTCNTUCGD1WeAsVMVgAqQ/6Q Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5JEQdGkpgnXw2WrCn27OYQD0Orc Cc: =?iso-8859-1?Q?'Javier_Cervi=F1o'?= , rtcweb@ietf.org Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:54:54 -0000 Below I am agreeing with Harald that WebRTC browsers need to = auto-discover and use network provided TURN servers in favor of application provided = TURN servers (that will still remain with its hassles and limitations, for = some time of course). --> /Karl -----Ursprungligt meddelande----- Fr=E5n: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Skickat: den 12 juni 2014 16:58 Till: Pal Martinsen (palmarti); Karl Stahl Kopia: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier = Cervi=F1o; rtcweb@ietf.org =C4mne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or = not to UDP? On 06/12/2014 01:30 PM, Pal Martinsen (palmarti) wrote: > On 12 Jun 2014, at 11:58, Karl Stahl wrote: > >>>> F18 The browser must be able to send streams and >>>> data to a peer in the presence of NATs and >>>> Firewalls that block UDP traffic. >>> Yes. Using TURN servers is the way in which it is possible to fulfil = >>> this >> requirement. >> >> Further in draft-ietf-rtcweb-use-cases-and-requirements-14: >> "the straddling TURN server ... It must be >> possible to configure the browsers used in the enterprise with >> network specific STUN and TURN servers. This should be possible = to >> achieve by auto-configuration methods." >> F20 The browser must support the use of STUN and TURN >> servers that are supplied by entities other than >> the web application (i.e. the network provider). >> >> This is a TURN server with one interface on the Enterprise LAN where=20 >> the browser simple shall place the WebRTC media. (The other interface = >> should be public.) >> >> The way for the browser to autodiscover such network provided (from=20 >> the enterprise and ISP) TURN server is being worked in=20 >> draft-patil-tram-turn-serv-disc-01.txt. >> >> This resolves any firewall restriction not allowing WebRTC media (by=20 >> paralleling the firewall with the TURN server), and also allows the=20 >> enterprise or ISP to point out a better path for the WebRTC media=20 >> (instead of through the often data crowded firewall default gateway). >> (This will also be needed with IPv6.) >> > I have problems understanding how this solves any issues. I doubt many enterprise network managers would install a TURN server in parallel with their FW. Would be fair easier and safer to open up the appropriate = ports in the firewall towards the TURN server. They could then allow only UDP to allow for DPI and see that it is actually RTP traffic flowing. That is actually a very convenient way to (logically) install a TURN = server in parallel with your firewall. They don't have to be on the same physical segments to be in parallel. The important thing that Cullen (I think it was Cullen) pointed out when = we discussed this requirement is that the TURN server is designated by the local network administrator, not by the entity responsible for the Web application that uses WebRTC. [Karl] I fully agree with this - The WebRTC application should be = off-loaded of having to provide a TURN-server to allow usage behind (some) NAT/firewalls (and we should not put that burden on the peer either). = This is something we do today to get something going (but still don't succeed with the most restrictive firewalls), but hopefully don't have to do in = the future on "WebRTC-ready" accesses. Such accesses simply put ICE = initiated real-time traffic through the TURN server, while data goes as usual = through the default gateway (in a future clever firewall/NAT this can be the = same default gateway IP-address). [Karl] Yes, let's hope for network provided turn servers, which could be boxes in parallel with existing firewalls or built into the firewall. (A turn server is much cleaner and better standardized to integrate, than non-working SIP ALGs, where we instead put SBCs in parallel with = firewalls just to get SIP voice through (and with quality)).=20 [Karl] Also consider all triple play (surf/telephony/IP-TV) broadband accesses, that have a quality pipe just to cope with voice. A turn = server in such CPE will be required to place demanding WebRTC media on the pipe = that can handle WebRTCs real-time traffic. Separate pipes are also often = deployed e.g. for SIP trunking enterprise voice (PBXs and UC) paralleling the firewall. A local turn server could similarly feed WebRTC media into = such pipes, then bypassing the ordinary firewall (that may be too restrictive = to allow real-time traffic or just is too data crowded to cope with WebRTC media - NAT/Firewalls are typical congestion points). Harald> Thus, some way for the browser to find this TURN server is = needed. [Karl] Auto discovered, network provided (enterprise or ISP) turn = servers are being done in draft-patil-tram-turn-serv-disc-01.txt. I favor the anycast method suggested. Will WebRTC browsers implement all auto = discovery methods suggested there? [Karl] Network provided turn servers available for the network users, = need no authentication - The WebRTC browser can just use them as part of the Internet access (you get an IP address, a default gateway and a turn = server address to simply use). Those turn servers are required/can solve both traversal and quality problems of many internet accesses. > > Having a TURN server supporting UDP/TCP/TLS as communication between = the client and TURN server would solve almost all connectivity problems. We should, as Harald also pointed out, not try to force us throughout the = FW if the admin do not want the traffic to go through. > > .-. > P=E5l-Erik > > > > > > > > > > >> /Karl >> >> -----Ursprungligt meddelande----- >> Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Harald = Alvestrand >> Skickat: den 12 juni 2014 06:17 >> Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier=20 >> Cervi=F1o >> Kopia: rtcweb@ietf.org >> =C4mne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP = or=20 >> not to UDP? >> >> On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote: >>>> The MUST was a consensus call in London. See the minutes for=20 >>>> numbers. I >> was one of >the ones who were surprised at the strength of the = consensus. >>> [Raju] I thought one of the implicit (may be explicit in >> draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for=20 >> WebRTC is "implementations should work right out of the box without = extra boxes (e.g. >> TURN) in between under UDP restrictive firewalls". >> Unfortunately, nobody's found a way to make that true even for all=20 >> common NATs/firewalls that want to permit the communication. >> >> TURN servers are the least obnoxious way to make sure apps can work=20 >> in the presence of symmetric NATs. >> We could wish that this wasn't so, but we could also wish that NATs=20 >> would go away and everyone would run IPv6; neither is likely to = happen this year. >> >> Of course, in the presence of firewalls where the admin does *not*=20 >> want to permit the communication, we neither can nor should make communication work. >> >> >>> Then I see the following requirement in >> draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention=20 >> use of TURN in the text. >>> F18 The browser must be able to send streams and >>> data to a peer in the presence of NATs and >>> Firewalls that block UDP traffic. >> Yes. Using TURN servers is the way in which it is possible to fulfil=20 >> this requirement. >> >>> BR >>> Raju >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jun 13 05:56:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9101E1B2824 for ; Fri, 13 Jun 2014 05:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk8wPgIZbxRj for ; Fri, 13 Jun 2014 05:56:22 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3A91A04CA for ; Fri, 13 Jun 2014 05:56:21 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201406131456173158; Fri, 13 Jun 2014 14:56:17 +0200 From: "Karl Stahl" To: "'Roman Shpount'" , "'Makaraju, Maridi Raju \(Raju\)'" References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> In-Reply-To: Date: Fri, 13 Jun 2014 14:56:20 +0200 Message-ID: <00c801cf8706$dfa5eae0$9ef1c0a0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01CF8717.A32EBAE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+Gg4/k+UPcbkKHSMOx43VWua9ZigAf7YEQ Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n2f0L_vNMA6Fo1B1r95esG1l0i4 Cc: =?utf-8?Q?'Javier_Cervi=C3=B1o'?= , rtcweb@ietf.org Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:56:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01CF8717.A32EBAE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable WebRTC media over TCP/TLS (always open port 80 or 443) must also be = considered a =E2=80=9Cworkaround=E2=80=9D to get WebRTC connectivity = through a few more restrictive NAT/firewalls =E2=80=93 It will not cope = with the most restrictive firewalls having HTTP(S) proxies = (discussed/worked on at the pnta-list, wasn=E2=80=99t it). =20 Also, in general, it is bad to put quality demanding WebRTC media over a = retransmitting TCP connection, especially through the firewall that = often is a data crowded congestion point. =20 /Karl =20 Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Roman = Shpount Skickat: den 12 juni 2014 23:16 Till: Makaraju, Maridi Raju (Raju) Kopia: rtcweb@ietf.org; Javier Cervi=C3=B1o =C3=84mne: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying = RTP/SAVPF over ICE: To UDP or not to UDP?) =20 =20 On Thu, Jun 12, 2014 at 4:07 PM, Makaraju, Maridi Raju (Raju) = wrote: >On the related note, is there TLS-ICE? Would not it be simpler to open = a TLS connection >to the server with provided fingerprint validation and = use RFC 4571 framing with plain >RTP? This will also have a higher = chance of traversing firewalls then plain TCP. Even if >DTLS is used = over this TLS connection, it would still make sense to use TLS instead = of >TCP for better firewall traversal. [Raju] ICE TCP RFC 6544 does cover both TLS and DTLS. Please see page 6 = http://tools.ietf.org/html/rfc6544#section-3 Yes, you can run plain RTP on top of TLS-ICE, but for webrtc use it was = already decided to use DTLS-SRTP even for TCP. =20 I am not sure this is right since TLS or DTLS are supposed to run on top = of RFC 4571 on top of TCP. What I was asking about was RTP on top of RFC = 4571 on top of TLS. _____________ Roman Shpount =20 ------=_NextPart_000_00C9_01CF8717.A32EBAE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

We= bRTC media over TCP/TLS (always open port 80 or 443) must also be = considered a =E2=80=9Cworkaround=E2=80=9D to get WebRTC connectivity = through a few more restrictive NAT/firewalls =E2=80=93 It will not cope = with the most restrictive firewalls having HTTP(S) proxies = (discussed/worked on at the pnta-list, wasn=E2=80=99t = it).

 

Al= so, in general, it is bad to put quality demanding WebRTC media over a = retransmitting TCP connection, especially through the firewall that = often is a data crowded congestion point.

 

/K= arl

 

Fr=C3=A5n: rtcweb = [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Roman = Shpount
Skickat: den 12 juni 2014 23:16
Till: = Makaraju, Maridi Raju (Raju)
Kopia: rtcweb@ietf.org; Javier = Cervi=C3=B1o
=C3=84mne: Re: [rtcweb] Need for TURN, TCP-ICE = (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to = UDP?)

 

 

On Thu, = Jun 12, 2014 at 4:07 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> = wrote:

>On the related note, is there = TLS-ICE? Would not it be simpler to open a TLS connection >to the = server with provided fingerprint validation and use RFC 4571 framing = with plain >RTP? This will also have a higher chance of traversing = firewalls then plain TCP. Even if >DTLS is used over this TLS = connection, it would still make sense to use TLS instead of >TCP for = better firewall traversal.

[Raju] ICE TCP RFC 6544 does cover both = TLS and DTLS. Please see page 6 http://tools.ietf.org/html/rfc6544#section-3
Yes= , you can run plain RTP on top of TLS-ICE, but for webrtc use it was = already decided to use DTLS-SRTP even for TCP.

 

I = am not sure this is right since TLS or DTLS are supposed to run on = top of RFC 4571 on top of TCP. What I was asking about was RTP on top of = RFC 4571 on top of TLS.

_____________
Roman = Shpount

 

------=_NextPart_000_00C9_01CF8717.A32EBAE0-- From nobody Fri Jun 13 11:18:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADF81B29B1 for ; Fri, 13 Jun 2014 11:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 yshkdftDP-Te for ; Fri, 13 Jun 2014 11:18:54 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75AD91B2994 for ; Fri, 13 Jun 2014 11:18:54 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5DIIohB009206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 13:18:51 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s5DIIoHL028409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 14:18:50 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.96]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Fri, 13 Jun 2014 14:18:50 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Karl Stahl , "'Roman Shpount'" Thread-Topic: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) Thread-Index: AQHPhjeI2RSVoNelQ0ussSjLxoIP2ZtuBGEA///he/CAAFfQAIABBrEA///mCEA= Date: Fri, 13 Jun 2014 18:18:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> <00c801cf8706$dfa5eae0$9ef1c0a0$@stahl@intertex.se> In-Reply-To: <00c801cf8706$dfa5eae0$9ef1c0a0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kOtSjg3-jD73LatHZW6iOk6Gt30 Cc: =?utf-8?B?J0phdmllciBDZXJ2acOxbyc=?= , "rtcweb@ietf.org" Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:18:56 -0000 PldlYlJUQyBtZWRpYSBvdmVyIFRDUC9UTFMgKGFsd2F5cyBvcGVuIHBvcnQgODAgb3IgNDQzKSBt dXN0IGFsc28gYmUgY29uc2lkZXJlZCBhID7igJx3b3JrYXJvdW5k4oCdIHRvIGdldCBXZWJSVEMg Y29ubmVjdGl2aXR5IHRocm91Z2ggYSBmZXcgbW9yZSByZXN0cmljdGl2ZSBOQVQvZmlyZXdhbGxz IOKAkyBJdCA+d2lsbCBub3QgY29wZSB3aXRoIHRoZSBtb3N0IHJlc3RyaWN0aXZlIGZpcmV3YWxs cyBoYXZpbmcgSFRUUChTKSBwcm94aWVzIChkaXNjdXNzZWQvd29ya2VkID5vbiBhdCB0aGUgcG50 YS1saXN0LCB3YXNu4oCZdCBpdCkuDQoNCltSYWp1XSBUbyBnZXQgdGhydSB0aGVzZSB2ZXJ5IHJl c3RyaWN0aXZlIGZpcmV3YWxscyB0aGF0IGFsbG93IEhUVFAgb25seSwgdXNpbmcgVENQL1RMUyB3 aXRoIEhUVFAgZmFsbGJhY2sgaXMgYW4gb3B0aW9uLiBCdXQgdGhlIHJlc3RyaWN0aXZlIGZpcmV3 YWxscyBtYXkgZXZlbiBnbyBncmVhdCBsZW5ndGhzIHRvIGxpbWl0IHRoZSBkdXJhdGlvbiBvZiB0 aGUgY29ubmVjdGlvbiBhbmQvb3Igc2l6ZSBvZiB0aGUgZGF0YSAoaW4gY2FzZSBvZiBUTFMpLiAN CldpdGggZWl0aGVyIEhUVFAgZmFsbGJhY2sgb3B0aW9uIG9yIG90aGVyd2lzZSwgZG9pbmcgVExT IGJlbG93IFJGQyA0NTcxIGZyYW1pbmcgaGFzIGZvbGxvd2luZyBpbXBsaWNhdGlvbnMgZm9yIHdl YnJ0YyB1c2UgY2FzZTsgYSBzaW5nbGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gbmVlZCB0byBhbGxv dyBmb2xsb3dpbmcgMyB0eXBlcyBvZiBkYXRhIHRvIGJlIG11bHRpcGxleGVkL2J1bmRsZWQ6DQox LiBTZW5kaW5nIFNUVU4gcmVxIGJlZm9yZSBEVExTIGlzIGVzdGFibGlzaGVkOyB1bmxlc3MgU1RV TiBzdWNjZWVkcyB0aGVyZSBpcyBubyBwb2ludA0KICAgaW4gc2V0dGluZyB1cCBEVExTL1RMUy4N CjIuIFNlbmRpbmcgRFRMUy1TUlRQLiBUaGlzIHJlcXVpcmVzIHRoZSBSVFAgaGVhZGVycyB0byBi ZSBpbiBjbGVhciB0ZXh0IChpLmUuIG5vdCBlbmNyeXB0ZWQpIHdoaWxlIG9ubHkgdGhlIHBheWxv YWQgaXMgZW5jcnlwdGVkLg0KMy4gU2V0dGluZyB1cCBTQ1RQIG9uIHRvcCBvZiBEVExTLg0KDQpJ ZiBUTFMgaXMgcnVuIGJlbG93IFJGQyA0NTcxIHRoZW4gKDEpIGFuZCAoMikgY2FuJ3QgYmUgYWNo aWV2ZWQuDQoNCkJSDQpSYWp1DQoNCg== From nobody Fri Jun 13 11:25:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EBB1B29C8 for ; Fri, 13 Jun 2014 11:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 vx_zpSRIbvdA for ; Fri, 13 Jun 2014 11:25:10 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679FD1B29C3 for ; Fri, 13 Jun 2014 11:25:10 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db11so3665500veb.26 for ; Fri, 13 Jun 2014 11:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=khBIEWvNlidgmhH7LmpihwXg5hpW6K+tZsaCyoIWjRg=; b=IAFWvYuuYY1sTvcotL5DTSwCq5oMBNPTdwRiUTn3zt/N+OPlTZJjvpQuzevrQkBdmY HM1giaREUJjlrgYBo3jsdsI64997qUDfo/qO0HmWiIo9+i0U4F2GR0aWko8aAng+1J0Z Y/N2SJogwW/ZHiK/pPIZXHu/tLddPfrow7+aRkV0wLKbtCGnWT6PfRCcGXOrBwv274mx hb9pjVep9p9CU8P35715icFutOPw3in1YOtza8ihByh8YCcX+V9+erIlLmr8E9xeYlYn Tgpd9MZNvB8E1SzDwGBjS3hIbN2Za0eEvKtPwUUSkNE36VgWEpvFxehgenKXx6bbAglg H0ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=khBIEWvNlidgmhH7LmpihwXg5hpW6K+tZsaCyoIWjRg=; b=Mw06zBEnJ7cjyIgONw629ns4BqkWWzCCmjPGfRxI2ZzXwBRHrZp7bvfLCQ7Q5BcXpS Q2qKxwmSNQv3PqG2fiaHMRNsHhfI5mD6Jc5VO4BaLX68l4y57VEM5QZUtg3sCcnE8zlA Q+CIHR/MVI3SSitr5ye+u/U754IL8NyjuVjyU9XA6O4qIhTD96SxR9gNOsjVowUkcxoM oJHB6j2qD4SCqf4e/OwcHuYQohRmKxDniIvjs/4vqIFmUDdgvly/t2l/t4yki6lBQr82 aFMp8X5AYRTDQQ9cZLlWPqsGo196/rk5CkOQEtWLVUnIIhGJrYEy/N9r0aJBbGYa/wr/ T9HQ== X-Gm-Message-State: ALoCoQnjveetJ6psMj4A2CDrQHJ1QapEn7Xei4Ika9iEdHYpC7eNxwdG2CmnpYAVaWMq0oT+rNjQ X-Received: by 10.52.51.196 with SMTP id m4mr2459660vdo.26.1402683909384; Fri, 13 Jun 2014 11:25:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Fri, 13 Jun 2014 11:24:49 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> From: Justin Uberti Date: Fri, 13 Jun 2014 11:24:49 -0700 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=001a1136b1f426dd4904fbbbcc20 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rpW5uqBA8y1MZNH45mqK9j5mVeU Cc: =?UTF-8?Q?Javier_Cervi=C3=B1o?= , "rtcweb@ietf.org" Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:25:15 -0000 --001a1136b1f426dd4904fbbbcc20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ICE-TLS doesn't really make sense since you don't have a DNS name for the remote side, just an IP, which makes certificate management very difficult. ICE-TCP is a nice optimization for services that don't want to stand up both a gateway and a TURN server. On Fri, Jun 13, 2014 at 11:18 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > >WebRTC media over TCP/TLS (always open port 80 or 443) must also be > considered a >=E2=80=9Cworkaround=E2=80=9D to get WebRTC connectivity thr= ough a few more > restrictive NAT/firewalls =E2=80=93 It >will not cope with the most restr= ictive > firewalls having HTTP(S) proxies (discussed/worked >on at the pnta-list, > wasn=E2=80=99t it). > > [Raju] To get thru these very restrictive firewalls that allow HTTP only, > using TCP/TLS with HTTP fallback is an option. But the restrictive > firewalls may even go great lengths to limit the duration of the connecti= on > and/or size of the data (in case of TLS). > With either HTTP fallback option or otherwise, doing TLS below RFC 4571 > framing has following implications for webrtc use case; a single transpor= t > connection need to allow following 3 types of data to be > multiplexed/bundled: > 1. Sending STUN req before DTLS is established; unless STUN succeeds ther= e > is no point > in setting up DTLS/TLS. > 2. Sending DTLS-SRTP. This requires the RTP headers to be in clear text > (i.e. not encrypted) while only the payload is encrypted. > 3. Setting up SCTP on top of DTLS. > > If TLS is run below RFC 4571 then (1) and (2) can't be achieved. > > BR > Raju > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1136b1f426dd4904fbbbcc20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ICE-TLS doesn't really make sense since you don't = have a DNS name for the remote side, just an IP, which makes certificate ma= nagement very difficult.

ICE-TCP is a nice optimization = for services that don't want to stand up both a gateway and a TURN serv= er.


On Fri,= Jun 13, 2014 at 11:18 AM, Makaraju, Maridi Raju (Raju) &= lt;Ra= ju.Makaraju@alcatel-lucent.com> wrote:
>WebRTC media over TCP/TL= S (always open port 80 or 443) must also be considered a >=E2=80=9Cworka= round=E2=80=9D to get WebRTC connectivity through a few more restrictive NA= T/firewalls =E2=80=93 It >will not cope with the most restrictive firewa= lls having HTTP(S) proxies (discussed/worked >on at the pnta-list, wasn= =E2=80=99t it).

[Raju] To get thru these very restrictive firewalls that allow HTTP o= nly, using TCP/TLS with HTTP fallback is an option. But the restrictive fir= ewalls may even go great lengths to limit the duration of the connection an= d/or size of the data (in case of TLS).
With either HTTP fallback option or otherwise, doing TLS below RFC 4571 fra= ming has following implications for webrtc use case; a single transport con= nection need to allow following 3 types of data to be multiplexed/bundled:<= br> 1. Sending STUN req before DTLS is established; unless STUN succeeds there = is no point
=C2=A0 =C2=A0in setting up DTLS/TLS.
2. Sending DTLS-SRTP. This requires the RTP headers to be in clear text (i.= e. not encrypted) while only the payload is encrypted.
3. Setting up SCTP on top of DTLS.

If TLS is run below RFC 4571 then (1) and (2) can't be achieved.

BR
Raju

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

--001a1136b1f426dd4904fbbbcc20-- From nobody Fri Jun 13 11:52:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D4D1B29C3 for ; Fri, 13 Jun 2014 11:52:36 -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 gxLItzorYIDF for ; Fri, 13 Jun 2014 11:52:35 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6B11A05F5 for ; Fri, 13 Jun 2014 11:52:34 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so3063937wgg.33 for ; Fri, 13 Jun 2014 11:52:33 -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=QYYbqXnsPFdlWTxz7TfFaZX0K0cWnHZ76zbBgGeGhs4=; b=RHzS0rZtmwSYrta0ozkFEJMk6ZRvQOo7xNXzF7PY7rg0eLGFlf88mGttR/7lGX85R4 jVMWS1LlUVXnZ39GQKAXN+qEx/7CqNjq8Ke1IvYbV0zlD4fVmPSCz12FFd9SVHGY5YOg hsraP52c/18OBwgnSjkKjn1qZncsKD9tf+GsEX9LlGsTbGu/VZB/+tUnDloky5gHOJCc RktY+cPQeczbNqdSxNnCE74xtSvzeHOui+Nowrf74e29eBWd7agQ/iHizLi4it1Yfr4y QSv+UkGfXcLdGR1coS1NST66sHWPrnDtceQYVrCVJsAif8qd3GLl/2Fy3D7bO+OyNZk5 rKmw== X-Gm-Message-State: ALoCoQnY8GK0OCP5DUjK7w4ctXdcpgEadMOFzKUrM7sULgDbFXTyTKKdNpOPgyMZR/bkx3yiEH4y X-Received: by 10.194.190.42 with SMTP id gn10mr6997734wjc.9.1402685553069; Fri, 13 Jun 2014 11:52:33 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx.google.com with ESMTPSA id cd1sm6904823wjc.19.2014.06.13.11.52.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 11:52:31 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so1387259wiw.11 for ; Fri, 13 Jun 2014 11:52:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.157.226 with SMTP id wp2mr6865299wjb.66.1402685551380; Fri, 13 Jun 2014 11:52:31 -0700 (PDT) Received: by 10.216.162.10 with HTTP; Fri, 13 Jun 2014 11:52:31 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> Date: Fri, 13 Jun 2014 14:52:31 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0122f54805956604fbbc2e25 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZUjGvYm9fynQE9nWXw9H8HxtKXA Cc: "rtcweb@ietf.org" , =?UTF-8?Q?Javier_Cervi=C3=B1o?= Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:52:36 -0000 --089e0122f54805956604fbbc2e25 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 2:24 PM, Justin Uberti wrote: > ICE-TLS doesn't really make sense since you don't have a DNS name for the > remote side, just an IP, which makes certificate management very difficult. > We have a fingerprint in SDP which can be used to verify the certificates. > ICE-TCP is a nice optimization for services that don't want to stand up > both a gateway and a TURN server. > Agreed _____________ Roman Shpount --089e0122f54805956604fbbc2e25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 13, 2014 at 2:24 PM, Justin Uberti <juberti@google.com> wrote:
ICE-TLS doesn't really make sense sin= ce you don't have a DNS name for the remote side, just an IP, which mak= es certificate management very difficult.

We have a fingerprint in SDP which can be = used to verify the certificates.=C2=A0


ICE-TCP is a nice optimization for ser= vices that don't want to stand up both a gateway and a TURN server.

Agreed=C2=A0
___________= __
Roman Shpount
=C2=A0
--089e0122f54805956604fbbc2e25-- From nobody Fri Jun 13 16:34:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6A51A0467 for ; Fri, 13 Jun 2014 16:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 nLUY_RURyj29 for ; Fri, 13 Jun 2014 16:34:51 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992B71A02B8 for ; Fri, 13 Jun 2014 16:34:51 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hy10so2994708vcb.3 for ; Fri, 13 Jun 2014 16:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bfkRTf4YuesT+nUbkfC1njXnpyCXmuyDce641dk0hK8=; b=mOLa7+M6c6SqkbVR/qTabi31iAZoakewfJxyvb9FLt/2MRt3GC9Du6k6xU0jPVNh7w 2NZVm6SnRm7MFyS/FukLAH8HnIZy7i9bxH+N4LPQm9r2o0VQpzZnMQdizHpsJRR653Kq Ic9gkbW1sVnc3eZwRJT2FvqzOWbFbWowogOtdGRr+UlEdC6tXMBTWqssK0WXFSLs1sym bdk6gze1quQlrJRFJBSYapd3Y/6D2R4SW+PBXyshPCr+gxyvquex+qsY61OIf/2SeHAD WcpgIdWmWTa9bd1gGT7X+tGcsm0UYe/40SV6L5moHsnuWEzKbWugn53MYVvHIGKs2PDZ WeRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bfkRTf4YuesT+nUbkfC1njXnpyCXmuyDce641dk0hK8=; b=BvvfUnOHODV795fZ8V9Z3h92CSkz3FGVlPF6ps2YhLesmMiCvuBEdbv5p4GseMY37i jEXZbBGJqXRsLJsT+geQygxZ7/j8tnljUF2qJgXHAyEyHJGxd39HtmTynIR9YNOS7hSQ pPNY2K6SqOxcICam9dpT5mkEMidS3ihFbAmcn+UjbiY/1kYFaCuc3gkyTFufmwIqwqgE YxgDlphpD4hLpzQTRaTi9Q+quArkYG4O0a4QttEpz+sPD1HYtaObO7e9KjGYkBBodQB8 XdU1xeN1mzCTpW2DVrj3CA6GngCcZMvsNafRqp9s6HNr526mbCz4ugaa7mnkqJN5Nn/X Fz3w== X-Gm-Message-State: ALoCoQnRmEGAKtL0Ic4K+Ow3PtiZX43zj5NgPr6aA2kZ/DsngfrHLGZvem1wO3HJPupy/xAqrS6/ X-Received: by 10.220.9.201 with SMTP id m9mr3901265vcm.5.1402702490616; Fri, 13 Jun 2014 16:34:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Fri, 13 Jun 2014 16:34:30 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <539786C7.8090806@gmail.com> <53984062.1090202@gmail.com> <53986129.4050209@gmail.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <539929C1.3070205@alvestrand.no> From: Justin Uberti Date: Fri, 13 Jun 2014 16:34:30 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c35efeade06c04fbc01f9b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TaAPwX6ia3cNU1_FW5FUxPMSjQ8 Cc: "rtcweb@ietf.org" , =?UTF-8?Q?Javier_Cervi=C3=B1o?= Subject: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 23:34:53 -0000 --001a11c35efeade06c04fbc01f9b Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 11:52 AM, Roman Shpount wrote: > On Fri, Jun 13, 2014 at 2:24 PM, Justin Uberti wrote: > >> ICE-TLS doesn't really make sense since you don't have a DNS name for the >> remote side, just an IP, which makes certificate management very difficult. >> > > We have a fingerprint in SDP which can be used to verify the certificates. > Not without crossing layers; also, the fingerprint is in the SDP answer, which means that ICE-TLS couldn't start until the answer is received. Generally, I think ICE-TCP to 443 should work fine in most cases, and for the cases where DPI prevents this, it's not clear the DPI wouldn't also stop ICE-TLS. > > >> ICE-TCP is a nice optimization for services that don't want to stand up >> both a gateway and a TURN server. >> > > Agreed > _____________ > Roman Shpount > > --001a11c35efeade06c04fbc01f9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 11:52 AM, Roman Shpount &= lt;roman@telurix.com= > wrote:
=
On Fri, Jun 13, 2014 at 2:24 PM,= Justin Uberti <juberti@google.com> wrote:
ICE-TLS doesn't really make sense sin= ce you don't have a DNS name for the remote side, just an IP, which mak= es certificate management very difficult.

We have a fingerprint in SDP which c= an be used to verify the certificates.=C2=A0

Not without crossing layers; also, the fingerprin= t is in the SDP answer, which means that ICE-TLS couldn't start until t= he answer is received.

Generally, I think ICE-TCP to 443 should work fine in m= ost cases, and for the cases where DPI prevents this, it's not clear th= e DPI wouldn't also stop ICE-TLS.=C2=A0


ICE-TCP is a nice optimization for ser= vices that don't want to stand up both a gateway and a TURN server.

Agreed=C2=A0
_____= ________
Roman Shpount
=C2=A0

--001a11c35efeade06c04fbc01f9b-- From nobody Sun Jun 15 17:45:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4981B299D for ; Sun, 15 Jun 2014 17:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.672 X-Spam-Level: X-Spam-Status: No, score=0.672 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, 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 UYe1ebFqPCzy for ; Sun, 15 Jun 2014 17:44:55 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90ED61B298C for ; Sun, 15 Jun 2014 17:44:55 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db12so5277061veb.21 for ; Sun, 15 Jun 2014 17:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s4N4tv8nQzGdLTunqR9UORKBTson42K81wYZtC3JgUQ=; b=WISMnuSZKRVttH2QpuGg0hpnmXsbhAvi8wMZLRkdX1Nl51lFza2TfcT5u/xffyBkrg kJNN4XLPMgm8PdVXCpjeduO+C4PJCuruJ8L6DL0u37bAhlGxCMaEQZPC2X6cASF7k0Wg eTbZI20eAovlkXdpcS6zQU4BWa3fmqgbTS9PfENv1LUvnNMq37lsYF8E0TmQJ0ScaNYU X275o/fTMolRNww1PdacpQOONIO8gtKIsWYvKnh+/4f5FJvk+XcoYN/4MDrKJv6qbNEU D2ZYFtMTo96n09xT3JccVkAp3vhysMmbYDAY+UkTfSTYvviW3EdD3JCo2Pxp+suEo82f jQdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=s4N4tv8nQzGdLTunqR9UORKBTson42K81wYZtC3JgUQ=; b=CIWIN6l7GvUqZSkkbMkbC9l7glnBZ28+eHnzYoVMdI+GYcdsaZMdUrfvxCj6/WQ+lm 7+q1nOL+ugOul+PotEhsa6wSCHSsSherZnY2FVJU2z0EOIpcX0OJFaRKABg5JxD5bElb BMocynoRTPvNKxH68bITHe86dCg56xOmYYBFQHgwvzf3xz8J7Sv+NI2LXEyjspzeOPYb DC39R2xEycJvC2xywRDtdVQKHT4wH6a6c6E4jnYVdZBWZ3rD/tPXm1Z/WJj0qsOJtPQw tUi980RV/DbZoyHY0aCvy0XdZLcQwun9sHW6bCc61OVdNmdDG+nMFtX4IoHdhBQSbY53 HhtQ== X-Gm-Message-State: ALoCoQliUJ6PdU92Eeb4A1Y5V7FdaJp/0WDBn9TRrw1e4fnaEY3TGB4fngS/xtf7Kt77KiOgRMLw X-Received: by 10.221.20.199 with SMTP id qp7mr2298640vcb.24.1402879492703; Sun, 15 Jun 2014 17:44:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Sun, 15 Jun 2014 17:44:32 -0700 (PDT) In-Reply-To: References: <5322FE7F.9040007@ericsson.com> From: Justin Uberti Date: Sun, 15 Jun 2014 17:44:32 -0700 Message-ID: To: Magnus Westerlund , Eric Rescorla , Cullen Jennings Content-Type: multipart/alternative; boundary=001a11339e2ed365af04fbe955f7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NJmvgpbAuzUL9gLPwsuqG2a4mZo Cc: draft-ietf-rtcweb-jsep@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-jsep-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 00:45:00 -0000 --001a11339e2ed365af04fbe955f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for the super long latency on this. We've created issues in the GH tracker for the points identified below. Specific comments inline. https://github.com/rtcweb-wg/jsep/issues/51 https://github.com/rtcweb-wg/jsep/issues/52 https://github.com/rtcweb-wg/jsep/issues/53 https://github.com/rtcweb-wg/jsep/issues/54 On Fri, Mar 14, 2014 at 9:48 AM, Justin Uberti wrote: > Thanks for the detailed review. We will work through these comments over > the next few days. > > > On Fri, Mar 14, 2014 at 6:05 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> I did review the JSEP -06 prior to the meeting. Now I have had time to >> write-up my comments. >> >> 1) Section 1): >> >> [W3C.WD-webrtc-20111027] >> This is very old version of the API, please update to the currently >> relevant version. >> > Will do. > >> 2) Section 3.4.1.1: >> The m-line index is a zero-based index, referring to the Nth m-line in >> the SDP. >> >> a) I think the above is a bit confusing. As a zero-based index would >> mean that the first m=3D section would have index 0. Thus, the referring >> to the Nth m-line in the SDP is unclear. Is N, the provided index, in >> which case it would be the N+1th m-line. Please rewrite. >> > Will clarify. > >> b) I also wonder if one has to be clearer on what "the SDP" is. I assume >> it is the one that has been generated by the agent, rather than the >> latest sent or received? >> > It can be for either the local generated SDP, in the case where the candidate is gotten from the onicecandidate callback, or the remote SDP, in the case where the candidates are trickled from the remote side. We'll add some text to make this clear. > >> 3) Section 3.4.1.1: >> "The MID uses the "media stream identification", as defined in >> [RFC5888] , to identify the m-line." >> >> a spurious space after ref. >> > OK. > >> 4) JSEP applications typically inform the browser to begin ICE gathering >> via the information supplied to setLocalDescription, as this is where >> the app specifies the number of media streams to gather candidates >> for. >> >> I find the statement that ICE candidate gathering starts first with >> setLocalDescription. Doesn't the created offer already contain local >> candidates, thus one must have already gathered some candidates? To me >> it appears reasonable to start gathering earlier, rather than later. >> Thus, as soon as one create the PeerConnection object and have added any >> MST to it or a data channel, one can start gathering. >> > The initial offer comes out as soon as possible, so it contains no candidates. setLocalDescription is the first time the implementation knows exactly how many m=3D lines it needs to gather for, so gathering can't definitively sta= rt until this point. Candidates may be pre-gathered using the candidate pool, but they aren't released via onicecandidate until setLD. > >> 5) Section 3.5.2: >> In the parallel forking case where the Javascript application wishes >> to simultaneously exchange media with multiple peers, the flow is >> slightly more complex, but the Javascript application can follow the >> strategy that [RFC3960] describes using UPDATE. (It is worth noting >> that use cases where this is the desired behavior are very unusual.) >> >> I mostly react to the last sentence within the paragraph. I think the >> poster child for semi-parallel forking was the MMORG that like to >> establish PCs with anyone that is coming close in the virtual world. >> Thus either needs to have a number of PCs on standby or have just one, >> but treat that as parallel forking. And if you like to discourage the >> later, then I think you might need to at least inform about the >> possibility to have stand-by PCs. >> > Is the MMORG case described in the use-case doc? If so, I agree the parenthesized text should be changed. > >> 6. Section 3.6: >> >> In the event that the local application state is reinitialized, >> either due to a user reload of the page, or a decision within the >> application to reload itself (perhaps to update to a new version), it >> is possible to keep an existing session alive, via a process called >> "rehydration". The explicit goal of rehydration is to carry out this >> session resumption with no interaction with the remote side other >> than normal call signaling messages. >> >> I think this paragraph makes two erronous statements: >> a) "keep an existing session alive" >> I think "resume" an existing session would be more correct. Because it >> would be broken when the reload happens. >> >> b) "with no interaction with the remote side" >> My understanding is that due to DTLS and key handling a DTLS >> renegotiation will be required with the peer. Isn't also a signalling >> exchange likely to be required due to change of local DTLS cert as well >> as ICE candidates as parameters? Any other parameters that will be >> required to exchanges when rehydrating? >> >> This section has been removed, as nobody was working on this and it wasn't clear exactly what it ought to do. > 7. Section 3.6: >> Next, a new offer is >> generated by the new PeerConnection; this offer will have new ICE and >> possibly new DTLS-SRTP certificate fingerprints (since the old ICE >> and SRTP state has been lost). >> >> I think this may require quite a bit more details. A forward pointer to >> where you will specify that? >> > See above > >> 8. Section 3.6: >> [OPEN ISSUE: EKR proposed an alternative rehydration approach where >> the actual internal PeerConnection object in the browser was kept >> alive for some time after the web page was killed and provided some >> way for a new page to acquire the old PeerConnection object.] >> >> Can't we declare this open issue closed? I have seen no details on the >> alternative proposal. Thus, lets work with the one that is present. >> >> See above > 9. Section 4.1.1: >> There is no discussion of how the bundle policies relate to the Data >> Channels? Are they included or do they have a specific set of policies. >> Please extend this to discuss this. >> > Will do. > >> 10. Section 4.1.3: >> >> This text doesn't appear to contain a requirement on that one MUST have >> called setRemote prior to being able to call it. >> > Will fix. > >> 11. Section 4.1.4.1: >> While this could also be done with an inactive "pranswer", followed >> by a sendrecv "answer", the initial "pranswer" leaves the offer- >> answer exchange open, which means the caller cannot send an updated >> offer during this time. >> >> Should one mention that also the callee can't send an offer without >> doing a "final" answer? >> > The callee could still send more pranswers, so it is not as restricted in this state as the caller. However, it can't add streams at this point, so there are some limitations. If you think this is unclear I could change the text to say "neither side can send an updated offer during this time" > >> 12. Section 4.1.4.1 >> >> By the time the human has accepted the call and >> triggered the new offer, it is likely that the ICE and DTLS >> handshaking for all the channels will already be set up. >> >> Wouldn't the handshaking have "finished" rather than "set up"? >> > Yes. > >> 13. Section 4.1.4.2: >> Rollback can only be used to cancel proposed changes; there is no >> support for rolling back from a stable state to a previous stable >> state. >> >> What is meant with "proposed changes"? From my side it is not clear how >> much you can do after having performed a SetLocal or SetRemote. I think >> these needs to be treated separately. > > >> For an offerer, they can createOffer, SetLocal, send to peer, receive >> reject and then undo the SetLocal. That is straight forward, and if they >> done the SetRemote, they would be consider in a new Stable state and >> can't roll back anymore? >> >> For the answering side, it receive an offer, does SetRemote, >> CreateAnswer, determines that it doesn't like it, the can undo the >> SetRemote and send a reject message to offerer. >> >> But what about this case? it receive an offer, does SetRemote, >> CreateAnswer, SetLocal and sends the message, then receive a reject from >> the peer, because it didn't like the answer? Are the answerer then in a >> stable state that can't be unrolled, or? >> > If you don't like the answer, I think it's game over. The answerer has already started acting on the new local/remote description at this point. IOW, "proposed changes" really only means what has been offered. > >> 14. Section 4.1.5: >> This API indirectly controls the candidate gathering process. When a >> local description is supplied, and the number of transports currently >> in use does not match the number of transports needed by the local >> description, the PeerConnection will create transports as needed and >> begin gathering candidates for them. >> >> Another part of an earlier question regarding what triggers ICE gatherin= g? >> > See answer above. > >> 15. Section 4.1.7: >> TODO: Do we need to expose accessors for both the current and >> proposed local description? >> >> This needs to be resolved, I don't know if I can answer this question. >> > We agreed in the interim that we would expose them. > >> 16. Section 4.1.9: >> >> Should this section discuss that it might be browser that has overriding >> controls regarding if other candidates then relay ones may be provided, >> i.e. privacy mode? >> > Probably. The use of host candidates is something that might be forbidden by local policy. I think the right thing to do would be to introduce the concept of iceTransports in section 3.4 (ICE), and then refer to it here in updateIce (now called setConfiguration), as well as the ctor section, where the initial policy can be set. > >> 17. Section 4.1.9: >> Regardless of the configuration, the gathering process collects all >> available candidates, but excluded candidates will not be surfaced in >> onicecandidate callback or used for connectivity checks. >> >> Doesn't this result in both resource consumption and that the configured >> TURN server will learn the external IP address and port for the client? >> > I'm not sure what the exact concern is here. Gathering candidates, even those that aren't desired, allows the withheld candidates to be released as soon as the app asks for them. > >> 18. Section 5.2.1: >> >> Structure in relation between RTP media and DATA channel. Maybe you >> should try to find a structure that makes the difference between the two >> types of transport more clear, and what applies to the perspective. >> >> Agree this could be improved. > 19. Section 5.2.1: >> >> >> o For the current default candidate, a "c=3D" line, as specific in >> [RFC5245], Section 4.3., paragraph 6. If no candidates have been >> gathered yet, the default candidate should be set to the 'null' >> value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. >> >> What about host candidates? >> > See above. This text has been clarified in the latest non-public revision. > >> 20. Section 5.2.1: >> The CNAME must be generated >> in accordance with draft-rescorla-random-cname-00. [OPEN ISSUE: >> How are CNAMEs specified for MSTs? Are they randomly generated >> for each MediaStream? If so, can two MediaStreams be synced?] >> >> I think you should point to the RTP usage for this particular piece. >> Because we do have text there both for the CNAME generation and how >> CNAMES among MSTs and between PeerConnection. Likely to be changed soon >> based on the mailing list discussion. >> > Agreed. > >> 21. Section 5.2.1: >> o [OPEN ISSUE: Handling of a=3Dimageattr] >> >> Yes, I think imageattr should be supported to give guidance on suitable >> resolutions that an endpoint like to receive for a particular MST. >> >> Agreed. Harald is working on changes to address this. > 22. Section 5.2.1: >> Once all m=3D sections have been generated, a session-level "a=3Dgrou= p" >> attribute MUST be added as specified in [RFC5888]. This attribute >> MUST have semantics "BUNDLE", and MUST include the mid identifiers of >> each m=3D section. >> >> Isn't this overriding BUNDLE as currently specified, forcing everything >> into a single bundle group. Thus, preventing the bundle policies to work= . >> >> The BUNDLE policies only affect what is bundle-only. Between two browsers, a single BUNDLE will always be used. > 23. Section 5.2.2: >> >> o If any MediaStreamTracks have been added, and there exist m=3D >> sections of the appropriate media type with no associated >> MediaStreamTracks >> >> Isnt' the last a "MediaStreamTrack" rather than plural ones? >> >> Agree this could be clarified. > 24. 5.2.3.3. VoiceActivityDetection >> >> If the "VoiceActivityDetection" constraint is specified, with a value >> of "true", the offer MUST indicate support for silence suppression by >> including comfort noise ("CN") codecs for each supported clock rate, >> as specified in [RFC3389], Section 5.1. >> >> As currently specified this text requires the usage of a comfort noise >> codec, currently there is no such on required. I think the "MUST" needs >> to be rewritten. >> > I think this needs to be specified as a MUST in RTP usage then. Otherwise, this setting won't work in some browsers, leading to nondeterministic behavior. This should also be updated to set usedtx=3D1 for Opus. > >> 25. Section 5.3.1: >> Note >> that for simplicity, the answerer MAY use different payload types >> for codecs than the offerer, as it is not prohibited by >> Section 6.1. >> >> I react to the word simplicity here. I never consider usage of different >> PTs per direction anything simple. But, yes it is allowed by RFC 3264. >> But I kind of protest to encourage the usage. >> >> Clearly this needs more explanation. The basic issue is the fact that using the same payload types gets really hairy when using RTX and when bundling. We can add an example of the problem. 26. Section 5.3.2 etc. >> >> When will we see a first draft of the text in the sections: >> 5.3.2, 5.3.3., 5.4, 5.5, 5.6, 5.7? >> >> I really like to see it prior to the Interim meeting. >> > Work in progress, will be in jsep-07 before Toronto. > >> 27. Section 6: >> Note: This section is still very early and is likely to significantly >> change as we get a better understanding of a) the use cases for this >> b) the implications at the protocol level c) feedback from >> implementors on what they can do. >> >> Shouldn't this mention W3C discussion also? >> > Sure. > >> 28. Section 7 - Security Considerations: >> >> First of all there are no references to the Security Considerations or >> architecture document. >> >> Secondly, I would like to have some security discussion on significant >> issues with JSEP itself. Resource attacks on the local endpoint for >> example? >> > We will add a open issue for this. > >> 29. section 10 >> >> There are a couple of draft references that are either published RFCs or >> at least WG versions. Please update the reference list. >> >> OK. > 30. Section 10.2: >> Looking at the spec, I think the following references are normative: >> >> [I-D.ietf-mmusic-trickle-ice] >> Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: >> Incremental Provisioning of Candidates for the Interactive >> Connectivity Establishment (ICE) Protocol", draft-ietf- >> mmusic-trickle-ice-00 (work in progress), March 2013. >> >> [I-D.ietf-rtcweb-data-protocol] >> Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel >> Protocol", draft-ietf-rtcweb-data-protocol-04 (work in >> progress), February 2013. >> >> >> OK. > Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --001a11339e2ed365af04fbe955f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the super long latency on this. We've create= d issues in the GH tracker for the points identified below. Specific commen= ts inline.
https://github.com/rtcweb-wg/jsep/issues/53
https://github= .com/rtcweb-wg/jsep/issues/54

On Fri, Mar 14, 2014 at 9:48 AM, Justin Uberti <juber= ti@google.com> wrote:
Thanks for the detailed review. We will w= ork through these comments over the next few days.


On Fri, = Mar 14, 2014 at 6:05 AM, Magnus Westerlund <magnus.westerlund= @ericsson.com> wrote:
Hi,

I did review the JSEP -06 prior to the meeting. Now I have had time to
write-up my comments.

1) Section 1):

[W3C.WD-webrtc-20111027]
This is very old version of the API, please update to the currently
relevant version.

Will do.=C2=A0

2) Section 3.4.1.1:
The m-line index is a zero-based index, referring to the Nth m-line in
the SDP.

a) I think the above is a bit confusing. As a zero-based index would
mean that the first m=3D section would have index 0. Thus, the referring to the Nth m-line in the SDP is unclear. Is N, the provided index, in
which case it would be the N+1th m-line. Please rewrite.

Will clarify.
<= div>=C2=A0

b) I also wonder if one has to be clearer on what "the SDP" is. I= assume
it is the one that has been generated by the agent, rather than the
latest sent or received?

It can be for either the local generated SDP, in the= case where the candidate is gotten from the onicecandidate callback, or th= e remote SDP, in the case where the candidates are trickled from the remote= side. We'll add some text to make this clear.=C2=A0

3) Section 3.4.1.1:
"The MID uses the "media stream identification", as defined = in
=C2=A0 =C2=A0[RFC5888] , to identify the m-line."

a spurious space after ref.

OK.=C2=A0

4) JSEP applications typically inform the browser to begin ICE gathering =C2=A0 =C2=A0via the information supplied to setLocalDescription, as this i= s where
=C2=A0 =C2=A0the app specifies the number of media streams to gather candid= ates
=C2=A0 =C2=A0for.

I find the statement that ICE candidate gathering starts first with
setLocalDescription. Doesn't the created offer already contain local candidates, thus one must have already gathered some candidates? To me
it appears reasonable to start gathering earlier, rather than later.
Thus, as soon as one create the PeerConnection object and have added any MST to it or a data channel, one can start gathering.

The initial offer comes= out as soon as possible, so it contains no candidates.

setLocalDescription is the first time the implementation knows e= xactly how many m=3D lines it needs to gather for, so gathering can't d= efinitively start until this point. Candidates may be pre-gathered using th= e candidate pool, but they aren't released via onicecandidate until set= LD.
=C2=A0
=

5) Section 3.5.2:
=C2=A0 =C2=A0In the parallel forking case where the Javascript application = wishes
=C2=A0 =C2=A0to simultaneously exchange media with multiple peers, the flow= is
=C2=A0 =C2=A0slightly more complex, but the Javascript application can foll= ow the
=C2=A0 =C2=A0strategy that [RFC3960] describes using UPDATE. =C2=A0(It is w= orth noting
=C2=A0 =C2=A0that use cases where this is the desired behavior are very unu= sual.)

I mostly react to the last sentence within the paragraph. I think the
poster child for semi-parallel forking was the MMORG that like to
establish PCs with anyone that is coming close in the virtual world.
Thus either needs to have a number of PCs on standby or have just one,
but treat that as parallel forking. And if you like to discourage the
later, then I think you might need to at least inform about the
possibility to have stand-by PCs.
<= /blockquote>

Is the MMORG case described in the use-case= doc? If so, I agree the parenthesized text should be changed.
=C2=A0

6. Section 3.6:

=C2=A0 =C2=A0In the event that the local application state is reinitialized= ,
=C2=A0 =C2=A0either due to a user reload of the page, or a decision within = the
=C2=A0 =C2=A0application to reload itself (perhaps to update to a new versi= on), it
=C2=A0 =C2=A0is possible to keep an existing session alive, via a process c= alled
=C2=A0 =C2=A0"rehydration". =C2=A0The explicit goal of rehydratio= n is to carry out this
=C2=A0 =C2=A0session resumption with no interaction with the remote side ot= her
=C2=A0 =C2=A0than normal call signaling messages.

I think this paragraph makes two erronous statements:
a) "keep an existing session alive"
I think "resume" an existing session would be more correct. Becau= se it
would be broken when the reload happens.

b) "with no interaction with the remote side"
My understanding is that due to DTLS and key handling a DTLS
renegotiation will be required with the peer. Isn't also a signalling exchange likely to be required due to change of local DTLS cert as well
as ICE candidates as parameters? Any other parameters that will be
required to exchanges when rehydrating?

This section has= been removed, as nobody was working on this and it wasn't clear exactl= y what it ought to do.
=C2=A0
7. Section 3.6:
Next, a new offer is
=C2=A0 =C2=A0generated by the new PeerConnection; this offer will have new = ICE and
=C2=A0 =C2=A0possibly new DTLS-SRTP certificate fingerprints (since the old= ICE
=C2=A0 =C2=A0and SRTP state has been lost).

I think this may require quite a bit more details. A forward pointer to
where you will specify that?

See above=C2=A0

8. Section 3.6:
=C2=A0 =C2=A0[OPEN ISSUE: EKR proposed an alternative rehydration approach = where
=C2=A0 =C2=A0the actual internal PeerConnection object in the browser was k= ept
=C2=A0 =C2=A0alive for some time after the web page was killed and provided= some
=C2=A0 =C2=A0way for a new page to acquire the old PeerConnection object.]<= br>
Can't we declare this open issue closed? I have seen no details on the<= br> alternative proposal. Thus, lets work with the one that is present.

See above
<= div>=C2=A0
9. Section 4.1.1:
There is no discussion of how the bundle policies relate to the Data
Channels? Are they included or do they have a specific set of policies.
Please extend this to discuss this.

Will do.=C2=A0

10. Section 4.1.3:

This text doesn't appear to contain a requirement on that one MUST have=
called setRemote prior to being able to call it.

Will fix.=C2=A0

11. Section 4.1.4.1:
=C2=A0 =C2=A0While this could also be done with an inactive "pranswer&= quot;, followed
=C2=A0 =C2=A0by a sendrecv "answer", the initial "pranswer&q= uot; leaves the offer-
=C2=A0 =C2=A0answer exchange open, which means the caller cannot send an up= dated
=C2=A0 =C2=A0offer during this time.

Should one mention that also the callee can't send an offer without
doing a "final" answer?
<= /blockquote>

The callee could still send more pranswers,= so it is not as restricted in this state as the caller. However, it can= 9;t add streams at this point, so there are some limitations.

If you think this is unclear I could change the text to= say "neither side can send an updated offer during this time"=C2= =A0

12. Section 4.1.4.1

By the time the human has accepted the call and
=C2=A0 =C2=A0triggered the new offer, it is likely that the ICE and DTLS =C2=A0 =C2=A0handshaking for all the channels will already be set up.

Wouldn't the handshaking have "finished" rather than "se= t up"?

<= /div>
Yes.=C2=A0

13. Section 4.1.4.2:
=C2=A0 =C2=A0Rollback can only be used to cancel proposed changes; there is= no
=C2=A0 =C2=A0support for rolling back from a stable state to a previous sta= ble
=C2=A0 =C2=A0state.

What is meant with "proposed changes"? From my side it is not cle= ar how
much you can do after having performed a SetLocal or SetRemote. I think
these needs to be treated separately.= =C2=A0

For an offerer, they can createOffer, SetLocal, send to peer, receive
reject and then undo the SetLocal. That is straight forward, and if they done the SetRemote, they would be consider in a new Stable state and
can't roll back anymore?

For the answering side, it receive an offer, does SetRemote,
CreateAnswer, determines that it doesn't like it, the can undo the
SetRemote and send a reject message to offerer.

But what about this case? it receive an offer, does SetRemote,
CreateAnswer, SetLocal and sends the message, then receive a reject from the peer, because it didn't like the answer? Are the answerer then in a=
stable state that can't be unrolled, or?

If you don't like the answer= , I think it's game over. The answerer has already started acting on th= e new local/remote description at this point.=C2=A0

IOW, "proposed changes" really only means wha= t has been offered.

14. Section 4.1.5:
=C2=A0 =C2=A0This API indirectly controls the candidate gathering process. = =C2=A0When a
=C2=A0 =C2=A0local description is supplied, and the number of transports cu= rrently
=C2=A0 =C2=A0in use does not match the number of transports needed by the l= ocal
=C2=A0 =C2=A0description, the PeerConnection will create transports as need= ed and
=C2=A0 =C2=A0begin gathering candidates for them.

Another part of an earlier question regarding what triggers ICE gathering?<= br>

Se= e answer above.=C2=A0

15. Section 4.1.7:
=C2=A0 =C2=A0TODO: Do we need to expose accessors for both the current and<= br> =C2=A0 =C2=A0proposed local description?

This needs to be resolved, I don't know if I can answer this question.<= br>

We= agreed in the interim that we would expose them.=C2=A0

16. Section 4.1.9:

Should this section discuss that it might be browser that has overriding controls regarding if other candidates then relay ones may be provided,
i.e. privacy mode?

=C2=A0Probably. The use of host candidates is something th= at might be forbidden by local policy. I think the right thing to do would = be to introduce the concept of iceTransports in section 3.4 (ICE), and then= refer to it here in updateIce (now called setConfiguration), as well as th= e ctor section, where the initial policy can be set.

17. Section 4.1.9:
=C2=A0 =C2=A0Regardless of the configuration, the gathering process collect= s all
=C2=A0 =C2=A0available candidates, but excluded candidates will not be surf= aced in
=C2=A0 =C2=A0onicecandidate callback or used for connectivity checks.

Doesn't this result in both resource consumption and that the configure= d
TURN server will learn the external IP address and port for the client?
=

I'= ;m not sure what the exact concern is here. Gathering candidates, even thos= e that aren't desired, allows the withheld candidates to be released as= soon as the app asks for them.

18. Section 5.2.1:

Structure in relation between RTP media and DATA channel. Maybe you
should try to find a structure that makes the difference between the two types of transport more clear, and what applies to the perspective.

Agree this could= be improved.
=C2=A0
19. Section 5.2.1:


=C2=A0 =C2=A0o =C2=A0For the current default candidate, a "c=3D" = line, as specific in
=C2=A0 =C2=A0 =C2=A0 [RFC5245], Section 4.3., paragraph 6. =C2=A0If no cand= idates have been
=C2=A0 =C2=A0 =C2=A0 gathered yet, the default candidate should be set to t= he 'null'
=C2=A0 =C2=A0 =C2=A0 value defined in [I-D.ietf-mmusic-trickle-ice], Sectio= n 5.1.

What about host candidates?

See above. This text has been clarified in the la= test non-public revision.=C2=A0

20. Section 5.2.1:
The CNAME must be generated
=C2=A0 =C2=A0 =C2=A0 in accordance with draft-rescorla-random-cname-00. =C2= =A0[OPEN ISSUE:
=C2=A0 =C2=A0 =C2=A0 How are CNAMEs specified for MSTs? =C2=A0Are they rand= omly generated
=C2=A0 =C2=A0 =C2=A0 for each MediaStream? =C2=A0If so, can two MediaStream= s be synced?]

I think you should point to the RTP usage for this particular piece.
Because we do have text there both for the CNAME generation and how
CNAMES among MSTs and between PeerConnection. Likely to be changed soon
based on the mailing list discussion.

Agreed.=C2=A0

21. Section 5.2.1:
=C2=A0 =C2=A0o =C2=A0[OPEN ISSUE: Handling of a=3Dimageattr]

Yes, I think imageattr should be supported to give guidance on suitable
resolutions that an endpoint like to receive for a particular MST.

Agreed. Harald i= s working on changes to address this.
=C2=A0
22. Section 5.2.1:
=C2=A0 =C2=A0Once all m=3D sections have been generated, a session-level &q= uot;a=3Dgroup"
=C2=A0 =C2=A0attribute MUST be added as specified in [RFC5888]. =C2=A0This = attribute
=C2=A0 =C2=A0MUST have semantics "BUNDLE", and MUST include the m= id identifiers of
=C2=A0 =C2=A0each m=3D section.

Isn't this overriding BUNDLE as currently specified, forcing everything=
into a single bundle group. Thus, preventing the bundle policies to work.
The BUNDLE polic= ies only affect what is bundle-only. Between two browsers, a single BUNDLE = will always be used.
=C2=A0
23. Section 5.2.2:

=C2=A0 =C2=A0o =C2=A0If any MediaStreamTracks have been added, and there ex= ist m=3D
=C2=A0 =C2=A0 =C2=A0 sections of the appropriate media type with no associa= ted
=C2=A0 =C2=A0 =C2=A0 MediaStreamTracks

Isnt' the last a "MediaStreamTrack" rather than plural ones?<= br>
Agree this could= be clarified.
=C2=A0
24. 5.2.3.3. =C2=A0VoiceActivityDetection

=C2=A0 =C2=A0If the "VoiceActivityDetection" constraint is specif= ied, with a value
=C2=A0 =C2=A0of "true", the offer MUST indicate support for silen= ce suppression by
=C2=A0 =C2=A0including comfort noise ("CN") codecs for each suppo= rted clock rate,
=C2=A0 =C2=A0as specified in [RFC3389], Section 5.1.

As currently specified this text requires the usage of a comfort noise
codec, currently there is no such on required. I think the "MUST"= needs
to be rewritten.
=
I think this needs to be specified as a MUST in RTP usage th= en. Otherwise, this setting won't work in some browsers, leading to non= deterministic behavior.=C2=A0

This should also be updated to set usedtx=3D1 for Opus.=

25. Section 5.3.1:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Note
=C2=A0 =C2=A0 =C2=A0 that for simplicity, the answerer MAY use different pa= yload types
=C2=A0 =C2=A0 =C2=A0 for codecs than the offerer, as it is not prohibited b= y
=C2=A0 =C2=A0 =C2=A0 Section 6.1.

I react to the word simplicity here. I never consider usage of different PTs per direction anything simple. But, yes it is allowed by RFC 3264.
But I kind of protest to encourage the usage.


C= learly this needs more explanation. The basic issue is the fact that using = the same payload types gets really hairy when using RTX and when bundling. = We can add an example of the problem.


26. Section 5.3.2 etc.

When will we see a first draft of the text in the sections:
5.3.2, 5.3.3., 5.4, 5.5, 5.6, 5.7?

I really like to see it prior to the Interim meeting.

Work in progress, will = be in jsep-07 before Toronto.
=C2=A0

27. Section 6:
=C2=A0 =C2=A0Note: This section is still very early and is likely to signif= icantly
=C2=A0 =C2=A0change as we get a better understanding of a) the use cases fo= r this
=C2=A0 =C2=A0b) the implications at the protocol level c) feedback from
=C2=A0 =C2=A0implementors on what they can do.

Shouldn't this mention W3C discussion also?

Sure.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

28. Section 7 - Security Considerations:

First of all there are no references to the Security Considerations or
architecture document.

Secondly, I would like to have some security discussion on significant
issues with JSEP itself. Resource attacks on the local endpoint for
example?

We will add a open issue for this.=C2=A0

29. section 10

There are a couple of draft references that are either published RFCs or at least WG versions. Please update the reference list.

OK.
= =C2=A0
30. Section 10.2:
Looking at the spec, I think the following references are normative:

=C2=A0 =C2=A0[I-D.ietf-mmusic-trickle-ice]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ivov, E., Rescorla, E., an= d J. Uberti, "Trickle ICE:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Incremental Provisioning o= f Candidates for the Interactive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Connectivity Establishment= (ICE) Protocol", draft-ietf-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic-trickle-ice-00 (wor= k in progress), March 2013.

=C2=A0 =C2=A0[I-D.ietf-rtcweb-data-protocol]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jesup, R., Loreto, S., and= M. Tuexen, "WebRTC Data Channel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Protocol", draft-ietf= -rtcweb-data-protocol-04 (work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 progress), February 2013.<= br>

OK.
= =C2=A0
Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Phone= =C2=A0+46 10 7148287
F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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


--001a11339e2ed365af04fbe955f7-- From nobody Mon Jun 16 09:00:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C611A010C for ; Mon, 16 Jun 2014 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DJGCwwobyrYL for ; Mon, 16 Jun 2014 09:00:17 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B111A00FD for ; Mon, 16 Jun 2014 09:00:14 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rd18so5028608iec.23 for ; Mon, 16 Jun 2014 09:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KhaQBhCL1aYnwakhSHPO/CXP4MZe+5lYJQcQxvUBE9A=; b=KjjzpkaTITliDq/a9jnPZ5rKQ48Ezw7C1NAo2K4dqcvZeAk59QXIv9OHf3c4DjTnsf YFhlkXKKqUMIaH5d++qMM0YNbO11sJ0hYQgx6ZwE+F+rinmWvIV8hnWWifm0sXS4Pb7r kAxmEqFcu3wqe3X7GIknHGuMzZeLLIFHanGOU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KhaQBhCL1aYnwakhSHPO/CXP4MZe+5lYJQcQxvUBE9A=; b=WET3sZb2fIcNEAWBPkG4LE9lKELXa3yn+4DxvMPsRkNuocBGKn2pi95Ef+Ka1jmoXQ sUBV5HCrimoAwTrtelDJaiwvfDuYIF0oTrW5oIwpxSTy3e7ed0OfYFAbvqd2heCQFmUu H2b/D8Rk/m+Sjr4w9GwI4xatc+qXHSoqVuVSdWM+J5hkr7L4IrVHPMF61wCcePk2JPlB JrzmtvHhKgnRgVTKSP0ZxWDh3DU8LkJ9vtJ+7/NERvCX28uGoccjzG36VUlh9tf9+zS1 BMjsRcHk5t0bl9lnDq+ok4H20gFohi8zr+JIxD+DK/XWRRU0548i6V7AuZorrUJZgGFo eVLQ== X-Gm-Message-State: ALoCoQk2B3G2wqgLe9WQ0XtWSS1Wt3QIR75vOFk0Gqo07uFv3WwjXVU6g2mXRqigY5XL1rClWoDu X-Received: by 10.43.160.4 with SMTP id ma4mr3351725icc.83.1402934414167; Mon, 16 Jun 2014 09:00:14 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id p12sm21612884igx.18.2014.06.16.09.00.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 09:00:13 -0700 (PDT) Message-ID: <539F1487.3030808@getjive.com> Date: Mon, 16 Jun 2014 10:00:07 -0600 From: Colton Shields User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <539F118A.8010201@getjive.com> In-Reply-To: <539F118A.8010201@getjive.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <539F118A.8010201@getjive.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6fSQ0qOtFd-DV9Zi55CKXOgM3YM Subject: [rtcweb] draft-ietf-rtcweb-overview-09 Review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:00:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Here is my review of the Overview: Real Time Protocols for Browser-based Applications draft-ietf-rtcweb-overview-09. Please take into consideration my suggestions. Thanks - -Colton Section 3 Paragraph 1 I am a native English speaker and I had to look up the definition of "envisage". Drafts should be written in the plainest language possible, to make it easier for everyone to understand. "The model of real-time support for browser-based applications does not envisage that the browser will contain all the functions that need to be performed in order to have a function such as a telephone or a video conferencing unit;" I suggest replacing "envisage" with one of the following - suppose - assume Section 3 Paragraph 5 "Existing protocols (for example SIP or XMPP) could be used between servers..." In case the reader is not familiar with SIP or XMPP, the draft should link to these protocols. Just like it does with other protocols. Especially since the next paragraphs provide an example of SIP and XMPP. If the reader does not understand how SIP or XMPP work they could get confused. Providing links gives them a resource to learn how those protocols work. SIP RFC 3261 http://www.ietf.org/rfc/rfc3261.txt XMPP RFC 3920 http://www.ietf.org/rfc/rfc3920.txt Spelling error in the Title Title should say "Browser-based" rather than "Brower-based" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTnxSHAAoJEKWz5R7vDXT70KIIAMD4QhckVf/zFbyN43WJnd/6 AtaahLFVZl7UeNU5KRFnYiedDH2RbVm4L9TgEWAgPiRxzzmsAZDg6CgDe599Q9jS 4oRklaXGMlsF0IoQ7DmvTpUSeiql2dl64rLpTREL1vnXaQN3RbBpdPyuvu5MRUDw 8rS1+eXyf8zL3T71iwsidc2/903r/vNsWE274chIxUGIv/vgW9RX2u1GS1DFvttw FZRlVc6Xb3BYWrJshwX+uGw8Doiak/yx+IpMdJ5lBzIvRCi13Au4fpdWwsqYME0v VXoPrWddqGTEJbx+/KkKsWi2hhq7NwQC5usWUT+NQwhJhBQWNaZJDECmotB821o= =u0qm -----END PGP SIGNATURE----- From nobody Mon Jun 16 12:56:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267A1A01A6 for ; Mon, 16 Jun 2014 12:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93El6ixEJJEN for ; Mon, 16 Jun 2014 12:56:22 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id EBC511A018E for ; Mon, 16 Jun 2014 12:56:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C17C77C3854; Mon, 16 Jun 2014 21:56:19 +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 IrxZ9nSbz6MX; Mon, 16 Jun 2014 21:56:18 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 58D747C382D; Mon, 16 Jun 2014 21:56:18 +0200 (CEST) Message-ID: <539F4BE2.1020608@alvestrand.no> Date: Mon, 16 Jun 2014 21:56:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Colton Shields , rtcweb@ietf.org References: <539F118A.8010201@getjive.com> <539F1487.3030808@getjive.com> In-Reply-To: <539F1487.3030808@getjive.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060507010207010401000209" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/a0l3yu1DptmVW6VEQg-fKHsTYHw Subject: Re: [rtcweb] draft-ietf-rtcweb-overview-09 Review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 19:56:27 -0000 This is a multi-part message in MIME format. --------------060507010207010401000209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you for the review! It is very timely, since I'm looking to revise this now based on other reviews. I will take care of the stuff you point out at the same time - thanks for making such specific suggestions! On 06/16/2014 06:00 PM, Colton Shields wrote: > Here is my review of the Overview: Real Time Protocols for > Browser-based Applications draft-ietf-rtcweb-overview-09. Please take > into consideration my suggestions. > > Thanks > -Colton > > > > Section 3 Paragraph 1 > > I am a native English speaker and I had to look up the definition of > "envisage". Drafts should be written in the plainest language > possible, to make it easier for everyone to understand. > > "The model of real-time support for browser-based applications does > not envisage that the browser will contain all the functions that > need to be performed in order to have a function such as a telephone > or a video conferencing unit;" > > I suggest replacing "envisage" with one of the following > - suppose > - assume > > > > Section 3 Paragraph 5 > > "Existing protocols (for example SIP or XMPP) could be used between > servers..." > > In case the reader is not familiar with SIP or XMPP, the draft should > link to these protocols. Just like it does with other protocols. > Especially since the next paragraphs provide an example of SIP and > XMPP. If the reader does not understand how SIP or XMPP work they > could get confused. Providing links gives them a resource to > learn how those protocols work. > > > SIP RFC 3261 > http://www.ietf.org/rfc/rfc3261.txt > > XMPP RFC 3920 > http://www.ietf.org/rfc/rfc3920.txt > > > > > Spelling error in the Title > > Title should say "Browser-based" rather than "Brower-based" > > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb - -- Surveillance is pervasive. Go Dark. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTn0viAAoJEIjUFboxkRizLXgIALfufpGO48OKmwY8LAtN8C3W pCk/l7JkR/4yhJTcevZopg2sU26KL1MPAzPUdk/DQ4mWwMF0d7+6jlxHhhNWKaXo nxj0GN4EwBTjftwj7FyRcZwJ/WSVgnXuPVgl/fI/5hY2ZxHQQSdruF/tvm2zAg5G wVSmvPei94u9UHdX/fVV0Q9jlHLqCOPHD8iGctUIjhJpq1TK9j6mDLyAuKd86Li4 OC3WdK0YqWayesx4AtMNPtWuT8Z9dgvej/hIKzMEhf8yQlpNA9XsLq20eEIikOr/ 6foa5nqkvx1cvOV/5w/JRRlaUQHfgvBl9GDStBxfpcLRJ6lmtVyD2LdSNLeuGQI= =caYy -----END PGP SIGNATURE----- --------------060507010207010401000209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you for the review!

It is very timely, since I'm looking to revise this now based on other reviews.
I will take care of the stuff you point out at the same time - thanks for making such specific suggestions!


On 06/16/2014 06:00 PM, Colton Shields wrote:
> Here is my review of the Overview: Real Time Protocols for
> Browser-based Applications draft-ietf-rtcweb-overview-09. Please take
> into consideration my suggestions.
>
> Thanks
> -Colton
>
>
>
> Section 3 Paragraph 1
>
> I am a native English speaker and I had to look up the definition of
> "envisage". Drafts should be written in the plainest language
> possible, to make it easier for everyone to understand.
>
> "The model of real-time support for browser-based applications does
>    not envisage that the browser will contain all the functions that
>    need to be performed in order to have a function such as a telephone
>    or a video conferencing unit;"
>
> I suggest replacing "envisage" with one of the following
>     - suppose
>     - assume
>
>
>
> Section 3 Paragraph 5
>
> "Existing protocols (for example SIP or XMPP) could be used between
> servers..."
>
> In case the reader is not familiar with SIP or XMPP, the draft should
> link to these protocols. Just like it does with other protocols.
> Especially since the next paragraphs provide an example of SIP and
> XMPP. If the reader does not understand how SIP or XMPP work they
> could get confused. Providing links gives them a resource to
> learn how those protocols work.
>
>
> SIP RFC 3261
> http://www.ietf.org/rfc/rfc3261.txt
>
> XMPP RFC 3920
> http://www.ietf.org/rfc/rfc3920.txt
>
>
>
>
> Spelling error in the Title
>
> Title should say "Browser-based" rather than "Brower-based"
>
>
>
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

- --
Surveillance is pervasive. Go Dark.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTn0viAAoJEIjUFboxkRizLXgIALfufpGO48OKmwY8LAtN8C3W
pCk/l7JkR/4yhJTcevZopg2sU26KL1MPAzPUdk/DQ4mWwMF0d7+6jlxHhhNWKaXo
nxj0GN4EwBTjftwj7FyRcZwJ/WSVgnXuPVgl/fI/5hY2ZxHQQSdruF/tvm2zAg5G
wVSmvPei94u9UHdX/fVV0Q9jlHLqCOPHD8iGctUIjhJpq1TK9j6mDLyAuKd86Li4
OC3WdK0YqWayesx4AtMNPtWuT8Z9dgvej/hIKzMEhf8yQlpNA9XsLq20eEIikOr/
6foa5nqkvx1cvOV/5w/JRRlaUQHfgvBl9GDStBxfpcLRJ6lmtVyD2LdSNLeuGQI=
=caYy
-----END PGP SIGNATURE-----

--------------060507010207010401000209-- From nobody Tue Jun 17 05:59:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D2A1A037D; Tue, 17 Jun 2014 05:59:23 -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 qSjthyTC9-FQ; Tue, 17 Jun 2014 05:59:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 287631A0377; Tue, 17 Jun 2014 05:59:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140617125918.29980.9279.idtracker@ietfa.amsl.com> Date: Tue, 17 Jun 2014 05:59:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/No-GxAww6MOg7tLPZ3I2uJSLdUE Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 12:59:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-10.txt Pages : 20 Date : 2014-06-17 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications RTCWEB compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-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 Jun 17 06:12:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0387D1A037A for ; Tue, 17 Jun 2014 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HvmHLewt7p8 for ; Tue, 17 Jun 2014 06:12:24 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id CB3561A000E for ; Tue, 17 Jun 2014 06:12:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 29E947C37D9 for ; Tue, 17 Jun 2014 15:12:23 +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 Zj-qRxtbmt5M for ; Tue, 17 Jun 2014 15:12:17 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:ccd9:58e6:98cc:f473] (unknown [IPv6:2001:470:de0a:27:ccd9:58e6:98cc:f473]) by mork.alvestrand.no (Postfix) with ESMTPSA id 374DC7C386F for ; Tue, 17 Jun 2014 15:12:17 +0200 (CEST) Message-ID: <53A03EAE.7080309@alvestrand.no> Date: Tue, 17 Jun 2014 15:12:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20140617125918.29980.52006.idtracker@ietfa.amsl.com> In-Reply-To: <20140617125918.29980.52006.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140617125918.29980.52006.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060508060103020300090302" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3HnJFuk0PqgZkXg5LXR7OrQL9kg Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-overview-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:12:29 -0000 This is a multi-part message in MIME format. --------------060508060103020300090302 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The most important new words are definitions of terms "WebRTC Browser" and "WebRTC Device", and using these as requirement categories - which then support a new scattering of MUSTs on the references. Comments welcome! Harald -------- Original Message -------- Subject: New Version Notification for draft-ietf-rtcweb-overview-10.txt Date: Tue, 17 Jun 2014 05:59:18 -0700 From: internet-drafts@ietf.org To: Harald T. Alvestrand , Harald T. Alvestrand A new version of I-D, draft-ietf-rtcweb-overview-10.txt has been successfully submitted by Harald T. Alvestrand and posted to the IETF repository. Name: draft-ietf-rtcweb-overview Revision: 10 Title: Overview: Real Time Protocols for Browser-based Applications Document date: 2014-06-17 Group: rtcweb Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ Htmlized: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-10 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-10 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications RTCWEB compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. 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 --------------060508060103020300090302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit The most important new words are definitions of terms "WebRTC Browser" and "WebRTC Device", and using these as requirement categories - which then support a new scattering of MUSTs on the references.

Comments welcome!

Harald


-------- Original Message --------
Subject: New Version Notification for draft-ietf-rtcweb-overview-10.txt
Date: Tue, 17 Jun 2014 05:59:18 -0700
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald T. Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-ietf-rtcweb-overview-10.txt
has been successfully submitted by Harald T. Alvestrand and posted to the
IETF repository.

Name:		draft-ietf-rtcweb-overview
Revision:	10
Title:		Overview: Real Time Protocols for Browser-based Applications
Document date:	2014-06-17
Group:		rtcweb
Pages:		20
URL:            http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/
Htmlized:       http://tools.ietf.org/html/draft-ietf-rtcweb-overview-10
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-10

Abstract:
   This document gives an overview and context of a protocol suite
   intended for use with real-time applications that can be deployed in
   browsers - "real time communication on the Web".

   It intends to serve as a starting and coordination point to make sure
   all the parts that are needed to achieve this goal are findable, and
   that the parts that belong in the Internet protocol suite are fully
   specified and on the right publication track.

   This document is an Applicability Statement - it does not itself
   specify any protocol, but specifies which other specifications RTCWEB
   compliant implementations are supposed to follow.

   This document is a work item of the RTCWEB working group.

                                                                                  


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


--------------060508060103020300090302-- From nobody Tue Jun 17 08:54:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8C1A0051 for ; Tue, 17 Jun 2014 08:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJxdkRJ9KKyW for ; Tue, 17 Jun 2014 08:54:07 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2E91A0043 for ; Tue, 17 Jun 2014 08:54:07 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 551751EB85C2; Tue, 17 Jun 2014 17:54:06 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Tue, 17 Jun 2014 17:54:06 +0200 From: "Hutton, Andrew" To: Ted Hardie , Cullen Jennings , "Sean Turner" Thread-Topic: [rtcweb] Minutes and videos from the Interim meeting Thread-Index: AQHPhlbbV8nbUFwzckS4FxX0TAB9Spt1eqgw Date: Tue, 17 Jun 2014 15:54:05 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17DF1291@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17DF1291MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rBb6MNDB3Nybt-8k3ptX84Htv-I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minutes and videos from the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:54:10 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17DF1291MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb3VsZCBub3QgZmluZCBhbnl0aGluZyBpbiB0aGUgbWludXRlcyByZWdhcmRpbmcgb3VyIGRp c2N1c3Npb24gb24gdGhlIHRyYW5zcG9ydHMgZHJhZnQgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvaW50ZXJpbS8yMDE0LzA1LzE5L3J0Y3dlYi9zbGlkZXMvc2xpZGVzLWludGVyaW0t MjAxNC1ydGN3ZWItMS0yLnBkZikuDQoNCk5vdCBoYWQgdGltZSB0byBkb3dubG9hZCB0aGUgdmlk ZW8geWV0IGJ1dCBJIHRoaW5rIHdlIGRpc2N1c3NlZCB0aGlzIG9uIHRoZSBNb25kYXkgbW9ybmlu Zy4NCg0KUmVnYXJkcw0KQW5keQ0KDQoNCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6IDEyIEp1bmUg MjAxNCAxNjo1Ng0KVG86IHJ0Y3dlYkBpZXRmLm9yZzsgQ3VsbGVuIEplbm5pbmdzOyBTZWFuIFR1 cm5lcg0KU3ViamVjdDogW3J0Y3dlYl0gTWludXRlcyBhbmQgdmlkZW9zIGZyb20gdGhlIEludGVy aW0gbWVldGluZw0KDQpEZWFyIFdvcmtpbmcgR3JvdXAsDQoNCkF0dGFjaGVkIGlzIGEgZHJhZnQg c2V0IG9mIG1pbnV0ZXMgZnJvbSB0aGUgbWVldGluZy4gIFRoZSBzZWNyZXRhcmlhdCBpcyBjdXJy ZW50bHkgd29ya2luZyBvbiBtb3ZpbmcgdGhlIHZpZGVvcyBvZiB0aGUgbWVldGluZyB0byB0aGUg SUVURiBjaGFubmVsIGF0IFlvdXR1YmU7IHRoZSBzb3VyY2VzIHZpZGVvcyBhcmUgYXZhaWxhYmxl IGF0IGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS8jZm9sZGVycy8wQi0xc2tqVXdELThFYWtobVky cEZkVjg1ZEhNIGlmIHlvdSB3b3VsZCBsaWtlIHRvIGRvd25sb2FkIHRoZW0sIGJ1dCBwbGVhc2Ug YmUgYXdhcmUgdGhhdCB0aGV5IGFyZSB2ZXJ5IGxhcmdlLg0KQ29tbWVudHMgYW5kIGNvcnJlY3Rp b25zIG9uIHRoZSBtaW51dGVzIHRvIHRoZSBsaXN0IHBsZWFzZSwNCg0KVGVkLCBDdWxsZW4sIFNl YW4NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF17DF1291MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBh bm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjb3VsZCBub3QgZmlu ZCBhbnl0aGluZyBpbiB0aGUgbWludXRlcyByZWdhcmRpbmcgb3VyIGRpc2N1c3Npb24gb24gdGhl IHRyYW5zcG9ydHMgZHJhZnQgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvaW50ZXJpbS8yMDE0LzA1LzE5L3J0Y3dlYi9zbGlkZXMvc2xpZGVzLWludGVyaW0tMjAxNC1y dGN3ZWItMS0yLnBkZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIw MTQvMDUvMTkvcnRjd2ViL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE0LXJ0Y3dlYi0xLTIucGRm PC9hPikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Ob3QgaGFkIHRpbWUgdG8gZG93bmxvYWQgdGhlIHZpZGVvIHlldCBi dXQgSSB0aGluayB3ZSBkaXNjdXNzZWQgdGhpcyBvbiB0aGUgTW9uZGF5IG1vcm5pbmcuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBIYXJkaWU8YnI+DQo8Yj5T ZW50OjwvYj4gMTIgSnVuZSAyMDE0IDE2OjU2PGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5v cmc7IEN1bGxlbiBKZW5uaW5nczsgU2VhbiBUdXJuZXI8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0 Y3dlYl0gTWludXRlcyBhbmQgdmlkZW9zIGZyb20gdGhlIEludGVyaW0gbWVldGluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RGVhciBXb3JraW5nIEdyb3VwLDxicj4N Cjxicj4NCkF0dGFjaGVkIGlzIGEgZHJhZnQgc2V0IG9mIG1pbnV0ZXMgZnJvbSB0aGUgbWVldGlu Zy4mbmJzcDsgVGhlIHNlY3JldGFyaWF0IGlzIGN1cnJlbnRseSB3b3JraW5nIG9uIG1vdmluZyB0 aGUgdmlkZW9zIG9mIHRoZSBtZWV0aW5nIHRvIHRoZSBJRVRGIGNoYW5uZWwgYXQgWW91dHViZTsg dGhlIHNvdXJjZXMgdmlkZW9zIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHBzOi8vZHJp dmUuZ29vZ2xlLmNvbS8jZm9sZGVycy8wQi0xc2tqVXdELThFYWtobVkycEZkVjg1ZEhNIj5odHRw czovL2RyaXZlLmdvb2dsZS5jb20vI2ZvbGRlcnMvMEItMXNralV3RC04RWFraG1ZMnBGZFY4NWRI TTwvYT4gaWYgeW91IHdvdWxkIGxpa2UgdG8gZG93bmxvYWQgdGhlbSwgYnV0IHBsZWFzZSBiZSBh d2FyZSB0aGF0IHRoZXkgYXJlIHZlcnkgbGFyZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkNvbW1lbnRzIGFuZCBjb3Jy ZWN0aW9ucyBvbiB0aGUgbWludXRlcyB0byB0aGUgbGlzdCBwbGVhc2UsPGJyPg0KPGJyPg0KVGVk LCBDdWxsZW4sIFNlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF17DF1291MCHP04MSXglobal_-- From nobody Tue Jun 17 20:17:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B7B1A01AC; Tue, 17 Jun 2014 20:17:27 -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 m8vDnPC8yh6G; Tue, 17 Jun 2014 20:17:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 148A01A00D2; Tue, 17 Jun 2014 20:17:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> Date: Tue, 17 Jun 2014 20:17:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HEXUmf1EpEz38K06c199lcqxuYg Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 03:17:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-04.txt Pages : 9 Date : 2014-06-17 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new STUN usage. This same mechanism can also determine connection loss ("liveness") with a remote peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 17 20:33:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1F91A014C for ; Tue, 17 Jun 2014 20:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrU6o0Wb9epy for ; Tue, 17 Jun 2014 20:33:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D281A0140 for ; Tue, 17 Jun 2014 20:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2485; q=dns/txt; s=iport; t=1403062433; x=1404272033; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0eTpkD2MX/ZOeUQC6m7pjXjhyqmY7L8djbiDEBP7cCs=; b=MEeQ2TFqxVW2I4e+WbXw8ZOUacsWoNLSp16g7Q2qVGzLfGw/B7DAe1kc 3ZuIkcR406I97imbK7Du/A+kgeUAgLJF3h37skkWu8qNxDL9bfdcD1j7G 151NGkHVxbcscEmUFa5uypxJfK20Qwyc3IUWuc6r00TPc8V9tRolNUTSU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYKAD8IoVOtJV2Y/2dsb2JhbABagw1SUwe7f4ZsUwGBDRZ1hAMBAQEEAQEBNzQXBAIBCBEDAQIfECcLHQgCBBMJEognCAXKZReOQjoGhD0EmkOBQ5IVg0KCMA X-IronPort-AV: E=Sophos;i="5.01,498,1400025600"; d="scan'208";a="333882083" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jun 2014 03:33:40 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5I3XcMU013542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Jun 2014 03:33:38 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.51]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 22:33:37 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt Thread-Index: AQHPiqYXubLlqR+f60yFZZh53ozuRQ== Date: Wed, 18 Jun 2014 03:33:37 +0000 Message-ID: References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> In-Reply-To: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.65.66] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WDTTQqQ_smdRjX7uBNjc-pzPpPA Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 03:33:53 -0000 The new revision has: 1) Comments from Christer and Charles incorporated. 2) Incorporated the feedback received in the interim meeting in Section 4 on re-transmissions, revocation of consent 3) Removed the Appendix that had a example as it was no different from what is mentioned in solution. 4) Updates to section 6 (DiffServ Treatment) based on discussions in the mailing list. Please review and provide your feedback. Regards, Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Wednesday, 18 June 2014 8:47 am To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Real-Time Communication in WEB-browsers >Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-04.txt > Pages : 9 > Date : 2014-06-17 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new STUN usage. > This same mechanism can also determine connection loss ("liveness") > with a remote peer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshnes= s- >04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 19 10:44:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FAE1A0092 for ; Thu, 19 Jun 2014 10:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-xF9gy2AX-2 for ; Thu, 19 Jun 2014 10:44:03 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0AC1A0051 for ; Thu, 19 Jun 2014 10:44:03 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so2294963ier.30 for ; Thu, 19 Jun 2014 10:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nIoXYTyg8LNExNcPrFqjIbFRDiYJaat7A/hs1YvplOI=; b=V0s1V5UBWMLOSn11lXt/ZR7lbCuC05EnbTCsq6OJeYUea9paW53rIXPcfQKYHKTVFu 9LKWlnLALd6/5sv17YvSj2FzGFxL/lFab7U8uFbHZpmNltFoLmjtFMKRq5OM6lJsPz/W drhfgck8k8w0zonJZXzOi18OkpNlt/DqpLymZCaCzR0k702vK5P1W6efYigF7frNHL1u stXC3O8xk4bpu3ezluA1fBhhmkmMBUkWyun2QqvKlTQheGH8O/YO6IO/Gwb2H7tn7WrA NcTq2iErWsj6xXdbwXCGTir71k3Wh1ZJYIa+I/PEjIqy6no6/E37tOwk6dpmjprzB/no YlXA== MIME-Version: 1.0 X-Received: by 10.50.18.80 with SMTP id u16mr9126286igd.30.1403199843286; Thu, 19 Jun 2014 10:44:03 -0700 (PDT) Received: by 10.42.99.6 with HTTP; Thu, 19 Jun 2014 10:44:03 -0700 (PDT) Date: Thu, 19 Jun 2014 10:44:03 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=089e01493cba3544aa04fc33ec26 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gtPnYcckS48zgBfVbEO-5156pVk Subject: [rtcweb] Meeting recordings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 17:44:05 -0000 --089e01493cba3544aa04fc33ec26 Content-Type: text/plain; charset=UTF-8 The secretariat has now uploaded the recordings from the recent Interim to the IETF Youtube channel: https://www.youtube.com/user/ietf regards, Ted Hardie --089e01493cba3544aa04fc33ec26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The secretariat has now uploaded the recordings from the recent Inte= rim to the IETF Youtube channel:

https://www.youtube.com/user/ietf

= regards,

Ted Hardie
--089e01493cba3544aa04fc33ec26-- From nobody Sun Jun 22 22:46:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EFD1B29AB for ; Sun, 22 Jun 2014 22:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2vLccWZ197d for ; Sun, 22 Jun 2014 22:46:42 -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 C71B21B29A9 for ; Sun, 22 Jun 2014 22:46:41 -0700 (PDT) Received: from ppp118-209-152-146.lns20.mel6.internode.on.net ([118.209.152.146]:56849 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wyx5A-0003BD-3p for rtcweb@ietf.org; Mon, 23 Jun 2014 15:46:20 +1000 Message-ID: <53A7BF3E.8010505@nteczone.com> Date: Mon, 23 Jun 2014 15:46:38 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D35B976@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/a2I_e9-UwsCvE_CxUce6u6jvMkM Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 05:46:44 -0000 Do you need that statement? [RFC6455] section 11.5 says: Subprotocol Identifier The identifier of the subprotocol, as will be used in the |Sec-WebSocket-Protocol| header field registered in Section 11.3.4 of this specification. The value must conform to the requirements given in item 10 of Section 4.1 of this specification -- namely, the value must be a token as defined by RFC 2616 [RFC2616]. "Token" is RFC2616 is defined as: CHAR = token = 1* Regards, Christian On 12/06/2014 3:24 AM, Christer Holmberg wrote: > Hi Michael, > > I agree that we need to keep text about the encoding. > > Regards, > > Christer > > ________________________________________ > From: Michael Tuexen [Michael.Tuexen@lurchi.franken.de] > Sent: Wednesday, 11 June 2014 5:28 PM > To: Christer Holmberg > Cc: Ted Hardie; rtcweb@ietf.org > Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage > > On 10 Jun 2014, at 21:22, Christer Holmberg wrote: > >> Hi, >> >> A comment on draft-ietf-rtcweb-data-protocol-06: >> >> Section 5.1 says: >> >> "Protocol: Variable Length (sequence of characters) >> The sub-protocol for the channel as a UTF-8 encoded string. If >> this is an empty string the protocol is unspecified. If it is a >> non-empty string, it specifies an protocol registered in the >> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >> >> >> I think "The sub-protocol for the channel as a UTF-8 encoded string." part is a little confusing, because there is no such thing as sub-protocol in DCEP itself (DCEP only uses the WebSocket sub-protocol registry for registering DCEP *protocol* values). >> >> Perhaps we could just remove the sentence, and keep: >> >> "Protocol: Variable Length (sequence of characters) >> If this is an empty string the protocol is unspecified. If it is a >> non-empty string, it specifies an protocol registered in the >> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >> >> Section 4 gives more information about the usage of the protocol. > Do you intend to drop the statement about the UTF-8 encoding? > I think we should keep a statement about the encoding. > > Best regards > Michael >> (Alternatively, we could use sub-protocol terminology also in DCEP) >> >> Regards, >> >> Christer >> >> >> >> >> >> >> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie [ted.ietf@gmail.com] >> Sent: Tuesday, 10 June, 2014 9:52 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] WGLC for data channel drafts >> >> Dear WG, >> >> This starts a working group last call for our core Data Channel drafts: >> >> draft-ietf-rtcweb-data-protocol-06.txt >> draft-ietf-rtcweb-data-channel-10.txt >> >> Please review them in detail, especially for areas which may be of concern to the broader IETF community. This WGLC will end on June 27, 2014. >> >> Ted, Sean, Cullen >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Jun 24 06:51:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C571B2A1C for ; Tue, 24 Jun 2014 06:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HWHGM89wUYw for ; Tue, 24 Jun 2014 06:51:15 -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 9E58E1B2A18 for ; Tue, 24 Jun 2014 06:51:14 -0700 (PDT) Received: from ppp118-209-176-137.lns20.mel6.internode.on.net ([118.209.176.137]:53623 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WzR7L-0001xH-A2 for rtcweb@ietf.org; Tue, 24 Jun 2014 23:50:35 +1000 Message-ID: <53A9824D.9090401@nteczone.com> Date: Tue, 24 Jun 2014 23:51:09 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0pkw_g0qz1zmomkZ6QhQ8L1URqg Subject: Re: [rtcweb] WGLC for data channel drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:51:20 -0000 Some comments: draft-ietf-rtcweb-data-channel talks about unreliable use cases. Draft-ietf-rtcweb-data-protocol-06 in clause 4 also mentions "reliable or unreliable message transmission". However there is no channel type for "unreliable" only "DATA_CHANNEL_RELIABLE_xxx" and "DATA_CHANNEL_PARTIAL_RELIABLE_xxx". Are the "unreliable" use cases/text actually "partial reliable"? The requirements suggest that unreliable transport is needed but the solution offered is for reliable and partial reliability. draft-ietf-rtcweb-data-channel-10 --------------------------------- Cl. 6.1 bullet 1: Would "stream reconfiguration" be a better term than "stream reset"? RFC6525 allows reset and addition of streams. Cl. 6.1 bullet 2: "dynamic address reconfiguration" is the name of the RFC 5061. Is the part that Data Channel supports only the "Supported Extensions" parameter (cl.4.2.7/RFC5061)? Regards, Christian On 11/06/2014 4:52 AM, Ted Hardie wrote: > Dear WG, > > This starts a working group last call for our core Data Channel drafts: > > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt > > Please review them in detail, especially for areas which may be of > concern to the broader IETF community. This WGLC will end on June 27, > 2014. > > Ted, Sean, Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 24 08:34:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1C41B2D99 for ; Tue, 24 Jun 2014 08:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcIJdNgM-FHo for ; Tue, 24 Jun 2014 08:33:53 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B00751B2DA1 for ; Tue, 24 Jun 2014 08:30:39 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 9AB8423F053E; Tue, 24 Jun 2014 17:30:38 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 24 Jun 2014 17:30:38 +0200 From: "Hutton, Andrew" To: Harald Alvestrand Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-overview-10.txt Thread-Index: AQHPii3RzQwOWQySp0yOAQXisuQvWpuAZHLg Date: Tue, 24 Jun 2014 15:30:38 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E08E8C@MCHP04MSX.global-ad.net> References: <20140617125918.29980.52006.idtracker@ietfa.amsl.com> <53A03EAE.7080309@alvestrand.no> In-Reply-To: <53A03EAE.7080309@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17E08E8CMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/59PJXtGGwqIPfe1YTjmCe596Nd8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-overview-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 15:33:57 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17E08E8CMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VjdGlvbiA0IG5vdyBzdGF0ZXMg4oCcV2ViUlRDIGRldmljZXMgTVVTVCBpbXBsZW1lbnQgdGhl IHRyYW5zcG9ydCBwcm90b2NvbHMgZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1ydGN3ZWItdHJhbnNw b3J0czxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmll dy0xMCNyZWYtSS1ELmlldGYtcnRjd2ViLXRyYW5zcG9ydHM+XeKAnQ0KDQoNClRoaXMgbWlnaHQg YmUgYSBjb21tZW50IG9uIOKAk3RyYW5zcG9ydHMtIG1vcmUgdGhhbiDigJNvdmVydmlldy0gYnV0 IHNlY3Rpb24gMy40IG9mIHRyYW5zcG9ydHMgc3RhdGVzIHRoYXQg4oCcVGhlIGltcGxlbWVudGF0 aW9uIE1VU1QgYmUgYSBmdWxsIElDRSBpbXBsZW1lbnRhdGlvbiwgbm90IElDRS1MaXRl4oCdLiBU aGlzIGlzIGhvd2V2ZXIgbm90IHRydWUgZm9yIOKAnFdlYlJUQyBkZXZpY2Vz4oCdIG9ubHkgZm9y IOKAnFdlYlJUQyBicm93c2Vyc+KAnSBzaW5jZSBJQ0UtTGl0ZSBpcyBzdWZmaWNpZW50IGZvciDi gJxXZWJSVEMgZGV2aWNlc+KAnS4NCg0KDQoNClJlZ2FyZHMNCg0KQW5keQ0KDQoNCg0KDQpGcm9t OiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhh cmFsZCBBbHZlc3RyYW5kDQpTZW50OiAxNyBKdW5lIDIwMTQgMTQ6MTINClRvOiBydGN3ZWJAaWV0 Zi5vcmcNClN1YmplY3Q6IFtydGN3ZWJdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMC50eHQNCg0KVGhlIG1vc3QgaW1wb3J0YW50 IG5ldyB3b3JkcyBhcmUgZGVmaW5pdGlvbnMgb2YgdGVybXMgIldlYlJUQyBCcm93c2VyIiBhbmQg IldlYlJUQyBEZXZpY2UiLCBhbmQgdXNpbmcgdGhlc2UgYXMgcmVxdWlyZW1lbnQgY2F0ZWdvcmll cyAtIHdoaWNoIHRoZW4gc3VwcG9ydCBhIG5ldyBzY2F0dGVyaW5nIG9mIE1VU1RzIG9uIHRoZSBy ZWZlcmVuY2VzLg0KDQpDb21tZW50cyB3ZWxjb21lIQ0KDQpIYXJhbGQNCg0KDQotLS0tLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEwLnR4dA0KDQpEYXRlOg0KDQpU dWUsIDE3IEp1biAyMDE0IDA1OjU5OjE4IC0wNzAwDQoNCkZyb206DQoNCmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpUbzoNCg0KSGFy YWxkIFQuIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPjxtYWlsdG86aGFyYWxkQGFs dmVzdHJhbmQubm8+LCBIYXJhbGQgVC4gQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm8+ PG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMC50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBIYXJhbGQgVC4gQWx2ZXN0cmFuZCBhbmQgcG9zdGVkIHRvIHRoZQ0K DQpJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAgICAgICAgIGRyYWZ0LWlldGYtcnRjd2Vi LW92ZXJ2aWV3DQoNClJldmlzaW9uOiAgICAgMTANCg0KVGl0bGU6ICAgICAgICBPdmVydmlldzog UmVhbCBUaW1lIFByb3RvY29scyBmb3IgQnJvd3Nlci1iYXNlZCBBcHBsaWNhdGlvbnMNCg0KRG9j dW1lbnQgZGF0ZTogMjAxNC0wNi0xNw0KDQpHcm91cDogICAgICAgIHJ0Y3dlYg0KDQpQYWdlczog ICAgICAgIDIwDQoNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMC50eHQNCg0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLW92 ZXJ2aWV3Lw0KDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTANCg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEwDQoNCg0K DQpBYnN0cmFjdDoNCg0KICAgVGhpcyBkb2N1bWVudCBnaXZlcyBhbiBvdmVydmlldyBhbmQgY29u dGV4dCBvZiBhIHByb3RvY29sIHN1aXRlDQoNCiAgIGludGVuZGVkIGZvciB1c2Ugd2l0aCByZWFs LXRpbWUgYXBwbGljYXRpb25zIHRoYXQgY2FuIGJlIGRlcGxveWVkIGluDQoNCiAgIGJyb3dzZXJz IC0gInJlYWwgdGltZSBjb21tdW5pY2F0aW9uIG9uIHRoZSBXZWIiLg0KDQoNCg0KICAgSXQgaW50 ZW5kcyB0byBzZXJ2ZSBhcyBhIHN0YXJ0aW5nIGFuZCBjb29yZGluYXRpb24gcG9pbnQgdG8gbWFr ZSBzdXJlDQoNCiAgIGFsbCB0aGUgcGFydHMgdGhhdCBhcmUgbmVlZGVkIHRvIGFjaGlldmUgdGhp cyBnb2FsIGFyZSBmaW5kYWJsZSwgYW5kDQoNCiAgIHRoYXQgdGhlIHBhcnRzIHRoYXQgYmVsb25n IGluIHRoZSBJbnRlcm5ldCBwcm90b2NvbCBzdWl0ZSBhcmUgZnVsbHkNCg0KICAgc3BlY2lmaWVk IGFuZCBvbiB0aGUgcmlnaHQgcHVibGljYXRpb24gdHJhY2suDQoNCg0KDQogICBUaGlzIGRvY3Vt ZW50IGlzIGFuIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IC0gaXQgZG9lcyBub3QgaXRzZWxmDQoN CiAgIHNwZWNpZnkgYW55IHByb3RvY29sLCBidXQgc3BlY2lmaWVzIHdoaWNoIG90aGVyIHNwZWNp ZmljYXRpb25zIFJUQ1dFQg0KDQogICBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25zIGFyZSBzdXBw b3NlZCB0byBmb2xsb3cuDQoNCg0KDQogICBUaGlzIGRvY3VtZW50IGlzIGEgd29yayBpdGVtIG9m IHRoZSBSVENXRUIgd29ya2luZyBncm91cC4NCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K DQoNCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF17E08E8CMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5TZWN0aW9uIDQgbm93IHN0YXRlcyDigJxXZWJSVEMgZGV2aWNlcyBNVVNUIGltcGxl bWVudCB0aGUgdHJhbnNwb3J0IHByb3RvY29scyBkZXNjcmliZWQgaW4gWzxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEwI3JlZi1J LUQuaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPkktRC5pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzPC9zcGFuPjwvYT5d 4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBtaWdodCBiZSBhIGNvbW1lbnQg b24g4oCTdHJhbnNwb3J0cy0gbW9yZSB0aGFuIOKAk292ZXJ2aWV3LSBidXQgc2VjdGlvbiAzLjQg b2YgdHJhbnNwb3J0cyBzdGF0ZXMgdGhhdCDigJxUaGUgaW1wbGVtZW50YXRpb24gTVVTVCBiZSBh IGZ1bGwgSUNFIGltcGxlbWVudGF0aW9uLCBub3QgSUNFLUxpdGXigJ0uIFRoaXMgaXMgaG93ZXZl ciBub3QgdHJ1ZSBmb3Ig4oCcV2ViUlRDIGRldmljZXPigJ0gb25seSBmb3Ig4oCcV2ViUlRDIGJy b3dzZXJz4oCdIHNpbmNlIElDRS1MaXRlIGlzIHN1ZmZpY2llbnQgZm9yIOKAnFdlYlJUQyBkZXZp Y2Vz4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5B bmR5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IYXJhbGQgQWx2ZXN0cmFuZDxicj4NCjxiPlNl bnQ6PC9iPiAxNyBKdW5lIDIwMTQgMTQ6MTI8YnI+DQo8Yj5Ubzo8L2I+IHJ0Y3dlYkBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbcnRjd2ViXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTAudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG1vc3QgaW1wb3J0YW50IG5ldyB3 b3JkcyBhcmUgZGVmaW5pdGlvbnMgb2YgdGVybXMgJnF1b3Q7V2ViUlRDIEJyb3dzZXImcXVvdDsg YW5kICZxdW90O1dlYlJUQyBEZXZpY2UmcXVvdDssIGFuZCB1c2luZyB0aGVzZSBhcyByZXF1aXJl bWVudCBjYXRlZ29yaWVzIC0gd2hpY2ggdGhlbiBzdXBwb3J0IGEgbmV3IHNjYXR0ZXJpbmcgb2Yg TVVTVHMgb24gdGhlIHJlZmVyZW5jZXMuPGJyPg0KPGJyPg0KQ29tbWVudHMgd2VsY29tZSE8YnI+ DQo8YnI+DQpIYXJhbGQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9v OnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3Bh Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1Ympl Y3Q6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTAudHh0PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5EYXRlOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UdWUsIDE3IEp1biAyMDE0IDA1OjU5OjE4IC0wNzAwPG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu OnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFyYWxkIFQuIEFs dmVzdHJhbmQgPGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vIj4mbHQ7aGFyYWxk QGFsdmVzdHJhbmQubm8mZ3Q7PC9hPiwgSGFyYWxkIFQuIEFsdmVzdHJhbmQNCjxhIGhyZWY9Im1h aWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyI+Jmx0O2hhcmFsZEBhbHZlc3RyYW5kLm5vJmd0Ozwv YT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHByZT5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1ydGN3ZWIt b3ZlcnZpZXctMTAudHh0PG86cD48L286cD48L3ByZT4NCjxwcmU+aGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBIYXJhbGQgVC4gQWx2ZXN0cmFuZCBhbmQgcG9zdGVkIHRvIHRoZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPklFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5OYW1lOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmll dzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAxMDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPdmVydmlldzogUmVhbCBUaW1lIFByb3RvY29scyBmb3IgQnJv d3Nlci1iYXNlZCBBcHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Eb2N1bWVudCBk YXRlOiAyMDE0LTA2LTE3PG86cD48L286cD48L3ByZT4NCjxwcmU+R3JvdXA6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJ0Y3dlYjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTAudHh0 Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJ0Y3dlYi1v dmVydmlldy0xMC50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3RhdHVzOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy8iPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3 LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRp ZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtcnRjd2ViLW92ZXJ2aWV3LTEwIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBnaXZlcyBhbiBvdmVydmlldyBhbmQgY29u dGV4dCBvZiBhIHByb3RvY29sIHN1aXRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGludGVuZGVkIGZvciB1c2Ugd2l0aCByZWFsLXRpbWUgYXBwbGljYXRpb25zIHRoYXQgY2Fu IGJlIGRlcGxveWVkIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGJyb3dz ZXJzIC0gJnF1b3Q7cmVhbCB0aW1lIGNvbW11bmljYXRpb24gb24gdGhlIFdlYiZxdW90Oy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgSXQgaW50ZW5kcyB0byBzZXJ2ZSBhcyBhIHN0YXJ0aW5nIGFuZCBjb29yZGluYXRpb24g cG9pbnQgdG8gbWFrZSBzdXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFs bCB0aGUgcGFydHMgdGhhdCBhcmUgbmVlZGVkIHRvIGFjaGlldmUgdGhpcyBnb2FsIGFyZSBmaW5k YWJsZSwgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIHBh cnRzIHRoYXQgYmVsb25nIGluIHRoZSBJbnRlcm5ldCBwcm90b2NvbCBzdWl0ZSBhcmUgZnVsbHk8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3BlY2lmaWVkIGFuZCBvbiB0aGUg cmlnaHQgcHVibGljYXRpb24gdHJhY2suPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgaXMgYW4gQXBw bGljYWJpbGl0eSBTdGF0ZW1lbnQgLSBpdCBkb2VzIG5vdCBpdHNlbGY8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgc3BlY2lmeSBhbnkgcHJvdG9jb2wsIGJ1dCBzcGVjaWZpZXMg d2hpY2ggb3RoZXIgc3BlY2lmaWNhdGlvbnMgUlRDV0VCPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgYXJlIHN1cHBvc2VkIHRvIGZv bGxvdy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUlRDV0VC IHdvcmtpbmcgZ3JvdXAuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF17E08E8CMCHP04MSXglobal_-- From nobody Tue Jun 24 09:11:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784D81B2B2E for ; Tue, 24 Jun 2014 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjRV-MSJE5_J for ; Tue, 24 Jun 2014 09:11:21 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D40701B2DF7 for ; Tue, 24 Jun 2014 09:08:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C5A6F7C3A62; Tue, 24 Jun 2014 18:08:31 +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 VV2rXXKlw3+q; Tue, 24 Jun 2014 18:08:30 +0200 (CEST) Received: from [192.168.0.114] (unknown [213.123.58.114]) by mork.alvestrand.no (Postfix) with ESMTPSA id 616647C3A59; Tue, 24 Jun 2014 18:08:30 +0200 (CEST) Message-ID: <53A9A27D.9090805@alvestrand.no> Date: Tue, 24 Jun 2014 18:08:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hutton, Andrew" , "rtcweb@ietf.org" References: <20140617125918.29980.52006.idtracker@ietfa.amsl.com> <53A03EAE.7080309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E08E67@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E08E67@MCHP04MSX.global-ad.net> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------050502020300090305020703" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AnDSEw8D70Y_crathwY0nH5DzqI Subject: Re: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-overview-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:11:25 -0000 This is a multi-part message in MIME format. --------------050502020300090305020703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/24/2014 05:28 PM, Hutton, Andrew wrote: > Section 4 now states “WebRTC devices MUST implement the transport protocols described in [I-D.ietf-rtcweb-transports ]” > > > > This might be a comment on –transports- more than –overview- but section 3.4 of transports states that “The implementation MUST be a full ICE implementation, not ICE-Lite”. This is however not true for “WebRTC devices” only for “WebRTC browsers” since ICE-Lite is sufficient for “WebRTC devices”. > Good point. -transports- was last updated before I invented "WebRTC devices", it uses "devices" and "browsers" interchangeably. Will make them consistent next round, if WG signs off on the split. > Regards > Andy > > > > > > > > > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Harald > Alvestrand > *Sent:* 17 June 2014 14:12 > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Fwd: New Version Notification for > draft-ietf-rtcweb-overview-10.txt > > > > The most important new words are definitions of terms "WebRTC Browser" > and "WebRTC Device", and using these as requirement categories - which > then support a new scattering of MUSTs on the references. > > Comments welcome! > > Harald > > > > -------- Original Message -------- > > *Subject: * > > > > New Version Notification for draft-ietf-rtcweb-overview-10.txt > > *Date: * > > > > Tue, 17 Jun 2014 05:59:18 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Harald T. Alvestrand > , Harald T. Alvestrand > > > > > A new version of I-D, draft-ietf-rtcweb-overview-10.txt > has been successfully submitted by Harald T. Alvestrand and posted to the > IETF repository. > > Name: draft-ietf-rtcweb-overview > Revision: 10 > Title: Overview: Real Time Protocols for Browser-based Applications > Document date: 2014-06-17 > Group: rtcweb > Pages: 20 > URL: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > Htmlized: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-10 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-10 > > Abstract: > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This document is an Applicability Statement - it does not itself > specify any protocol, but specifies which other specifications RTCWEB > compliant implementations are supposed to follow. > > This document is a work item of the RTCWEB working group. > > > > > 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 > > > > > > -- Surveillance is pervasive. Go Dark. --------------050502020300090305020703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 06/24/2014 05:28 PM, Hutton, Andrew wrote:
Section 4 now states “WebRTC devices MUST implement the transport protocols described in [I-D.ietf-rtcweb-transports]”

 

This might be a comment on –transports- more than –overview- but section 3.4 of transports states that “The implementation MUST be a full ICE implementation, not ICE-Lite”. This is however not true for “WebRTC devices” only for “WebRTC browsers” since ICE-Lite is sufficient for “WebRTC devices”.
 

Good point. -transports- was last updated before I invented "WebRTC devices", it uses "devices" and "browsers" interchangeably.

Will make them consistent next round, if WG signs off on the split.


Regards
Andy

 

 

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 17 June 2014 14:12
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-overview-10.txt

 

The most important new words are definitions of terms "WebRTC Browser" and "WebRTC Device", and using these as requirement categories - which then support a new scattering of MUSTs on the references.

Comments welcome!

Harald



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

Subject:

New Version Notification for draft-ietf-rtcweb-overview-10.txt

Date:

Tue, 17 Jun 2014 05:59:18 -0700

From:

internet-drafts@ietf.org

To:

Harald T. Alvestrand <harald@alvestrand.no>, Harald T. Alvestrand <harald@alvestrand.no>

 

A new version of I-D, draft-ietf-rtcweb-overview-10.txt
has been successfully submitted by Harald T. Alvestrand and posted to the
IETF repository.
 
Name:         draft-ietf-rtcweb-overview
Revision:     10
Title:        Overview: Real Time Protocols for Browser-based Applications
Document date: 2014-06-17
Group:        rtcweb
Pages:        20
URL:            http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/
Htmlized:       http://tools.ietf.org/html/draft-ietf-rtcweb-overview-10
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-10
 
Abstract:
   This document gives an overview and context of a protocol suite
   intended for use with real-time applications that can be deployed in
   browsers - "real time communication on the Web".
 
   It intends to serve as a starting and coordination point to make sure
   all the parts that are needed to achieve this goal are findable, and
   that the parts that belong in the Internet protocol suite are fully
   specified and on the right publication track.
 
   This document is an Applicability Statement - it does not itself
   specify any protocol, but specifies which other specifications RTCWEB
   compliant implementations are supposed to follow.
 
   This document is a work item of the RTCWEB working group.
 
                                                                                  
 
 
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
 

 

 



-- 
Surveillance is pervasive. Go Dark.
--------------050502020300090305020703-- From nobody Tue Jun 24 11:03:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578D91B298B for ; Tue, 24 Jun 2014 11:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvDIsHrJ6q9Y for ; Tue, 24 Jun 2014 11:03:18 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F7D1B2B62 for ; Tue, 24 Jun 2014 11:03:18 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id h18so5038922igc.4 for ; Tue, 24 Jun 2014 11:03:16 -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 :content-type; bh=vVfydWOir9ubGfB4oLLBpm7zJUWKe4sqrWpJu7/G/sI=; b=uhdYFvGwzp7pFXq77qv866GVNg47pZptJFW8qGMazFQYSmjEqYHCj8OtWFSo9VGc0U +Eky/wPtqMcb6lQYMsaZjCRq9rzXPNLIqPz2XgdbSazCO3/NrZYCCfwE7PAHdjCpOZiw sOYfrJnHUz1tX2Koq5D031wZOLFSbmnPUocUR/rIb4+7trzm4CSuWnPb/rOwSfuYD0pH PQ6SBtu91WtHxIhA6m76V8NW9qb3549SoVA0sEteF/VZvCg7OyTAUhjAS5FEzPIqF9/N dT7LEsYdS/9HSAekXlGBTJCMcP3SUnwGBFJxYwlCyLLDAQQmPwknMZJIZsahRZtO7TZy LpeQ== MIME-Version: 1.0 X-Received: by 10.42.43.5 with SMTP id v5mr2512993ice.62.1403632996738; Tue, 24 Jun 2014 11:03:16 -0700 (PDT) Received: by 10.42.99.6 with HTTP; Tue, 24 Jun 2014 11:03:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Jun 2014 11:03:16 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5186ab02a6fbb04fc98c6bd Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/se4vlI75ur8eGjgr9s5LOuTgzxQ Subject: Re: [rtcweb] WGLC for data channel drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 18:03:20 -0000 --bcaec5186ab02a6fbb04fc98c6bd Content-Type: text/plain; charset=UTF-8 Howdy, Please note that this working group last call ends in 3 days, and we have very little in the way or responses. Please review the current drafts if you have not done so. thanks, Ted On Tue, Jun 10, 2014 at 11:52 AM, Ted Hardie wrote: > Dear WG, > > This starts a working group last call for our core Data Channel drafts: > > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt > > Please review them in detail, especially for areas which may be of concern > to the broader IETF community. This WGLC will end on June 27, 2014. > > Ted, Sean, Cullen > --bcaec5186ab02a6fbb04fc98c6bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Please note that this working group last call ends in 3 da= ys, and we have very little in the way or responses.=C2=A0 Please review th= e current drafts if you have not done so.

thanks,

Ted


On Tue, Jun 10, 2014 at 11:52 AM, Ted Hardie <ted.ie= tf@gmail.com> wrote:
Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to=20 the broader IETF community.=C2=A0 This WGLC will end on June 27, 2014.

Ted, Sean, Cullen

--bcaec5186ab02a6fbb04fc98c6bd-- From nobody Fri Jun 27 01:27:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DA71B3129 for ; Fri, 27 Jun 2014 01:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qtesR3BN1sD for ; Fri, 27 Jun 2014 01:27:13 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 40CF61B278A for ; Fri, 27 Jun 2014 01:27:13 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 6BA251EB8758 for ; Fri, 27 Jun 2014 10:27:12 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 27 Jun 2014 10:27:12 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: draft-hutton-httpbis-connect-protocol-00.txt Thread-Index: AQHPkeGX5bnzJp6nL0GR/Q7sAjMPQg== Date: Fri, 27 Jun 2014 08:27:11 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E0CF6A@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7x8LbAouPZ7EmbqmWBLCnqALYcU Subject: [rtcweb] draft-hutton-httpbis-connect-protocol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:27:14 -0000 I just submitted this draft for which there is a short agenda slot in Toron= to httpbis wg meeting. It was written as a result of our discussion during the recent rtcweb inter= im meeting in Washington DC. The draft proposes adding an indication in to HTTP Connect as to what proto= col is used with the tunnel and specifically for use with WebRTC (I.e. TURN= /ICE-TCP) so should be of interest to this group. Discussion should be on the HTTPBIS list. Regards Andy Title : HTTP Connect - Tunnel Protocol For WebRTC Authors : Andrew Hutton Justin Uberti Martin Thomson Filename : draft-hutton-httpbis-connect-protocol-00.txt Pages : 7 Date : 2014-06-27 Abstract: This document describes a mechanism to enable HTTP Clients to provide an indication within a HTTP Connect request as to which protocol will be used within the tunnel established to the Server identified by the target resource. The tunneled protocol is declared using the Tunnel- Protocol HTTP Request header field. Label usage relating to the use of HTTP Connect by WebRTC clients (e.g. turn, webrtc) are described in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hutton-httpbis-connect-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-hutton-httpbis-connect-protocol-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jun 27 03:06:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41B91B2CC4 for ; Fri, 27 Jun 2014 03:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 SDiROJvns6pJ for ; Fri, 27 Jun 2014 03:06:09 -0700 (PDT) Received: from mail-wi0-f173.google.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id B35601B2B14 for ; Fri, 27 Jun 2014 03:06:08 -0700 (PDT) Received: from mail-wi0-f173.google.com ([209.85.212.173]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKU61CEMEf/5oI0he0DBp0xejqD9LF1Jls@postini.com; Fri, 27 Jun 2014 03:06:08 PDT Received: by mail-wi0-f173.google.com with SMTP id cc10so2533950wib.6 for ; Fri, 27 Jun 2014 03:06:07 -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=+IrW2o4TiZe1MBvuZ0KLd6zlSB3+YGpyaIsEeurvkP8=; b=Zb6VsYeLBb7si8BR6mzF7USGei6RyVUh6KhMsHrHcd6OEGyQyKXykXgSawQY4GuRt4 MhA3eoBpWe6abyLgvhR9hv5ArUdXgw8CkJgc+X5GgWzi4yR7IH9kKVOV3+473ZOKrDCA puI8vhHlIbI5b38lyONZ854sV8TNJfX08wbROQaLVv+h44lNNS9UjKC+CNXEgDWlLA5j +kCtgJ9nu8POWcraP+UcwRFzrlsIMPbS999787Tl2QkNj9lisONTa2V6JfGSJOpb+myy Afe1t1f4hHUE9E3ISbFFyw/4WY7B/vuEe5+xF+PisPemLNrfQvM4+lC96+Aa7Dgtob6u vf/w== X-Gm-Message-State: ALoCoQmj72feTloJd+SHMOCECZ7ziM972gFFk7Ab1F6zpHZxoqBmHEBEcZ8q6OfDDyiR5I9TFfBSHnmYNRg3cJiK1QKj+oDWEIJUbGqb9bTyr9Ky3trx31L0+yHPF2ptnHfx1mVKvmDi X-Received: by 10.180.211.71 with SMTP id na7mr2395264wic.55.1403863567121; Fri, 27 Jun 2014 03:06:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.71 with SMTP id na7mr2395239wic.55.1403863566942; Fri, 27 Jun 2014 03:06:06 -0700 (PDT) Received: by 10.194.190.8 with HTTP; Fri, 27 Jun 2014 03:06:06 -0700 (PDT) In-Reply-To: References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 11:06:06 +0100 Message-ID: From: Michael Procter To: "Ram Mohan R (rmohanr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zRkCz84S-K3f2LGTASnjED5zXfE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 10:06:15 -0000 Hi Ram, I have a couple of comments about the word "inverted". In section 4.1, the draft says: receiving a matching, authenticated, non-error ICE binding response from the inverted remote peer's Transport Address. I think this means receiving it from the remote peer's Transport Address, although the presence of 'inverted' made me wonder. If the word is unnecessary, please remove it. If it is needed, please add more explanation as to what it means. Further on, the draft says: That is, if a valid STUN binding response [...] has not been received from the inverted 5-tuple, [...] I think this means receiving it from the 5-tuple, but again, the presence of 'inverted' made me wonder. Is this a naming issue? I am happy to send and receive on the same 5-tuple, and I expect my peer to do the same. However, my peer's 5-tuple will be inverted with respect to mine! Regards, Michael On 18 June 2014 04:33, Ram Mohan R (rmohanr) wrote: > The new revision has: > > 1) Comments from Christer and Charles incorporated. > 2) Incorporated the feedback received in the interim meeting in Section 4 > on re-transmissions, revocation of consent > 3) Removed the Appendix that had a example as it was no different from > what is mentioned in solution. > 4) Updates to section 6 (DiffServ Treatment) based on discussions in the > mailing list. > > Please review and provide your feedback. > > Regards, > Ram > > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Wednesday, 18 June 2014 8:47 am > To: "i-d-announce@ietf.org" > Cc: "rtcweb@ietf.org" > Subject: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-04.txt > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Real-Time Communication in WEB-browsers >>Working Group of the IETF. >> >> Title : STUN Usage for Consent Freshness >> Authors : Muthu Arul Mozhi Perumal >> Dan Wing >> Ram Mohan Ravindranath >> Tirumaleswar Reddy >> Martin Thomson >> Filename : draft-ietf-rtcweb-stun-consent-freshness-04.txt >> Pages : 9 >> Date : 2014-06-17 >> >>Abstract: >> To prevent sending excessive traffic to an endpoint, periodic consent >> needs to be obtained from that remote endpoint. >> >> This document describes a consent mechanism using a new STUN usage. >> This same mechanism can also determine connection loss ("liveness") >> with a remote peer. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness- >>04 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jun 27 06:00:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F32E1B2BB7 for ; Fri, 27 Jun 2014 06:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztAHSDd2MOin for ; Fri, 27 Jun 2014 06:00:26 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF9F1B2B7E for ; Fri, 27 Jun 2014 06:00:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 456027C3B45 for ; Fri, 27 Jun 2014 15:00:25 +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 Gq0dY2Kkl7kk for ; Fri, 27 Jun 2014 15:00:22 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:8513:deb:f219:3bde] (unknown [IPv6:2001:470:de0a:27:8513:deb:f219:3bde]) by mork.alvestrand.no (Postfix) with ESMTPSA id C9DAC7C3B1D for ; Fri, 27 Jun 2014 15:00:21 +0200 (CEST) Message-ID: <53AD6AE4.4050707@alvestrand.no> Date: Fri, 27 Jun 2014 15:00:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030901010204030002020001" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OMKlQODSBPX_QYCFkFhlJ5DKc6g Subject: [rtcweb] WGLC review for data channel drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 13:00:30 -0000 This is a multi-part message in MIME format. --------------030901010204030002020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2014 08:52 PM, Ted Hardie wrote: > Dear WG, > > This starts a working group last call for our core Data Channel drafts: > > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt > > Please review them in detail, especially for areas which may be of > concern to the broader IETF community. This WGLC will end on June 27, > 2014. This is my Last Call review of these two drafts. First of all: The drafts are ready for IETF Last Call. Second: There are a number of details that should be fixed. Whether that happens before IETF Last Call or not is not of great concern to me. draft-ietf-rtcweb-data-channel-10 ---------------------------------------------- Abstract Ten years from now, the RFC will exist, but the RTCWEB WG will not. I suggest replacing "The Real-Time Communication in Web browsers working group is charged to" with "The WebRTC framework specifies". 1. Introduction It's a little abrupt. Some more words of introduction may be needed here. Something like this: In the WebRTC framework, communication between the parties consists of media (for example audio and video) and non-media data. Media is sent using SRTP, and is not specified further here. Non-media data is handled by...." I suggest a global replace of "non-SRTP media data" with "non-media data" (3 occurences total). "non-SRTP media data" can be parsed as "media data that is not carried over SRTP", which is not the intended meaning. 4. Requirements Suggest striking "and that the WebRTC PeerConnection as a whole is fair with competing traffic such as TCP". The RMCAT discussions have proved how difficult it is just to define that, far less achieve it. If we want to say something in relation to TCP, I would suggest "and that the WebRTC PeerConnection does not cause excessive problems when run in parallel with TCP connections". 5. SCTP over DTLS over UDP Considerations In the paragraph on SCTP multihoming, I suggest using "the DTLS layer" instead of "the lower layer". There are multiple lower layers, identifying which one is mentioned here improves clarity. The term "user-land" is used here, while Req. 10 uses "user application space". I suggest using "user application space" in both places. The paragraph "When using DTLS as the lower layer..." repeats the info that SCTP multihoming is not used. It may be enough to say this once. "The partial reliability extension MUST support policies..." - this paragraph would be more implementable if specific policies, specified in an I-D or RFC, were referenced. The split between section 5 and section 6 seems odd. In particular, the section "This SCTP stack and its upper layer...." down to "exactly once and delivered in the order received." seems to belong to section 6 not section 5. 6.1 SCTP Protocol Considerations I think the -ndata messsage interleaving MUST be implemented, according to previous consensus. "SHOULD be used" seems both meaningless and unneccssary. 6.2 Association setup Nit: "that can negotiated" -> "that can be negotiated" 6.4 Channel definition The title should probably be "WebRTC Data Channel Definition". As part of getting the WGs out of the document, the first sentence should be "The WebRTC DataChannels are bidirectional." "Among other things" is a bad term to have in a document at Last Call time. Can we remove it? The SHOULD for -ndata- interleaving should be MUST implement and MUST offer. If it is not successfully negotiated at association setup time (is that how it works?), the "SHOULD limit" clause is appropriate. 6.7 Closing a channel Nit: "available to reuse" -> "available for reuse" Nit: "before resetting the stream" -> "before the stream is reset" 7 Security considerations Is there a security worry with an attacker sending over-long messages in an attempt to cause OOM situations? draft-ietf-rtcweb-data-protocol-06 --------------------------------------------- Abstract: Same worry about WG reference. 3. Terminology Stream is defined in terms of stream, which is unhealthy. A reference to a section of a relevant SCTP document would be better. The term "SCTP stream" occurs at least 18 times in the document (out of approx 41 occurences of "stream" overall). We should either use "SCTP stream" consistently" or stick to "Stream" consistently. The term "SCTP stream identifier" (or "stream identifier") should be called out in the terminology. The term "data channel" occurs 36 times. Consider standardizing on either Channel or Data Channel, and either capitalizing it or not. 6 Procedures Nit: "the sender of it can start" -> "the sender of the DATA_CHANNEL_OPEN can start" "If a DATA_CHANNEL_OPEN message is received .... the stream identifier corresponds to the role of the peer" - is there a reason to insist that the protocol machine enforce the odd/even rule?`(actually the next paragraph does not cover the odd/even rule violation case, which is probably just an unintentional mistake - I prefer writing this kind of thing in "IF ... ELSE .... - because if one writes it as "IF ; IF ", the risk of losing some edge cases is high. An alternative formulation for the second paragraph is "If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for instance if..." 7 Security Considerations The "When using..." paragraph sounds a bit off. What about saying This protocol does not provide privacy, integrity or authentication. It needs to be used as part of a protocol suite that contains all these things. Such a protocol suite is specified in [-dtls-encaps]. Dependency worries --------------------------- -protocol- depends normatively on these non-WG documents: draft-ietf-tsvwg-sctp-ndata ("I-D exists") draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching") draft-ietf-tsvwg-sctp-prpolicies ("I-D exists") draft-ietf-mmusic-sctp-sdp ("I-D exists") None of these are in the IESG queue. Are we confident of their speed of progress? This concludes my review. I think the protocol definition is ready, and needs no changes. --------------030901010204030002020001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2014 08:52 PM, Ted Hardie wrote:
Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.

This is my Last Call review of these two drafts.

First of all: The drafts are ready for IETF Last Call.
Second: There are a number of details that should be fixed. Whether that happens before IETF Last Call or not is not of great concern to me.

draft-ietf-rtcweb-data-channel-10
----------------------------------------------
Abstract

Ten years from now, the RFC will exist, but the RTCWEB WG will not. I suggest replacing "The Real-Time Communication in Web browsers working group is charged to" with "The WebRTC framework specifies".

1. Introduction

It's a little abrupt. Some more words of introduction may be needed here. Something like this:

In the WebRTC framework, communication between the parties consists of media (for example audio and video) and non-media data. Media is sent using SRTP, and is not specified further here. Non-media data is handled by...."

I suggest a global replace of "non-SRTP media data" with "non-media data" (3 occurences total). "non-SRTP media data" can be parsed as "media data that is not carried over SRTP", which is not the intended meaning.

4. Requirements

Suggest striking "and that the WebRTC PeerConnection as a whole is fair with competing traffic such as TCP". The RMCAT discussions have proved how difficult it is just to define that, far less achieve it.
If we want to say something in relation to TCP, I would suggest "and that the WebRTC PeerConnection does not cause excessive problems when run in parallel with TCP connections".

5. SCTP over DTLS over UDP Considerations

In the paragraph on SCTP multihoming, I suggest using "the DTLS layer" instead of "the lower layer". There are multiple lower layers, identifying which one is mentioned here improves clarity.

The term "user-land" is used here, while Req. 10 uses "user application space". I suggest using "user application space" in both places.

The paragraph "When using DTLS as the lower layer..." repeats the info that SCTP multihoming is not used. It may be enough to say this once.

"The partial reliability extension MUST support policies..." - this paragraph would be more implementable if specific policies, specified in an I-D or RFC, were referenced.

The split between section 5 and section 6 seems odd. In particular, the section "This SCTP stack and its upper layer...." down to "exactly once and delivered in the order received." seems to belong to section 6 not section 5.

6.1 SCTP Protocol Considerations

I think the -ndata messsage interleaving MUST be implemented, according to previous consensus.
"SHOULD be used" seems both meaningless and unneccssary.

6.2 Association setup

Nit: "that can negotiated" -> "that can be negotiated"

6.4 Channel definition

The title should probably be "WebRTC Data Channel Definition".

As part of getting the WGs out of the document, the first sentence should be "The  WebRTC DataChannels are bidirectional."
"Among other things" is a bad term to have in a document at Last Call time. Can we remove it?

The SHOULD for -ndata- interleaving should be MUST implement and MUST offer. If it is not successfully negotiated at association setup time (is that how it works?), the "SHOULD limit" clause is appropriate.

6.7 Closing a channel

Nit: "available to reuse" -> "available for reuse"
Nit: "before resetting the stream" -> "before the stream is reset"

7 Security considerations

Is there a security worry with an attacker sending over-long messages in an attempt to cause OOM situations?

draft-ietf-rtcweb-data-protocol-06
---------------------------------------------
Abstract: Same worry about WG reference.

3. Terminology

Stream is defined in terms of stream, which is unhealthy. A reference to a section of a relevant SCTP document would be better.

The term "SCTP stream" occurs at least 18 times in the document (out of approx 41 occurences of "stream" overall). We should either use "SCTP stream" consistently" or stick to "Stream" consistently.

The term "SCTP stream identifier" (or "stream identifier") should be called out in the terminology.

The term "data channel" occurs 36 times. Consider standardizing on either Channel or Data Channel, and either capitalizing it or not.

6 Procedures
Nit: "the sender of it can start" -> "the sender of the DATA_CHANNEL_OPEN can start"

"If a DATA_CHANNEL_OPEN message is received .... the stream identifier corresponds to the role of the peer" - is there a reason to insist that the protocol machine enforce the odd/even rule?`(actually the next paragraph does not cover the odd/even rule violation case, which is probably just an unintentional mistake - I prefer writing this kind of thing in "IF <condition> ... ELSE .... - because if one writes it as "IF <condition>; IF <opposite condition>", the risk of losing some edge cases is high.

An alternative formulation for the second paragraph is "If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for instance if..."

7 Security Considerations

The "When using..." paragraph sounds a bit off. What about saying

This protocol does not provide privacy, integrity or authentication. It needs to be used as part of a protocol suite that contains all these things. Such a protocol suite is specified in [-dtls-encaps].

Dependency worries
---------------------------
-protocol- depends normatively on these non-WG documents:

draft-ietf-tsvwg-sctp-ndata ("I-D exists")
draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching")
draft-ietf-tsvwg-sctp-prpolicies ("I-D exists")
draft-ietf-mmusic-sctp-sdp ("I-D exists")

None of these are in the IESG queue. Are we confident of their speed of progress?


This concludes my review. I think the protocol definition is ready, and needs no changes.




--------------030901010204030002020001-- From nobody Sat Jun 28 09:52:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8C1A037A for ; Sat, 28 Jun 2014 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4fkyo0GayzE for ; Sat, 28 Jun 2014 09:52:44 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909EC1A037B for ; Sat, 28 Jun 2014 09:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4429; q=dns/txt; s=iport; t=1403974365; x=1405183965; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qDAx+4692w2o78ex8WCkpQYyPCM94DpTEnW628WLEk4=; b=ICRn5Q2b4JleKKk5EcA5EahO0IgaaiR7msmskr/8h9FiwbBHIiQAQCFU qDzlhklhNEm67XapoQGGPST4ln8jQDjQAMHnihJpRlArNEsukqudA5ZaT b53UOygmqqYRBuxybEUsESo//Z0ZMIfbvwatbqLKq7FPQawe1umW9fD18 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcIAEDyrlOtJA2I/2dsb2JhbABagw1SUwe9PoZtUwGBCRZ1hAMBAQEEAQEBNzQXBAIBCBEDAQIBHhAnCx0IAgQBEgkSiCcIBcVYF45SOgaEPQWaXYFGkjWDQoIw X-IronPort-AV: E=Sophos;i="5.01,567,1400025600"; d="scan'208";a="56712792" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 28 Jun 2014 16:52:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5SGqhvk007407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Jun 2014 16:52:43 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.243]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sat, 28 Jun 2014 11:52:43 -0500 From: "Ram Mohan R (rmohanr)" To: Michael Procter , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt Thread-Index: AQHPkvFgZ2Whekz/zE2/r9bCYxpBmw== Date: Sat, 28 Jun 2014 16:52:42 +0000 Message-ID: References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.41.170] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E6C1A84F5D1B14398466F06E3009A13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1x9iB26FQAjkFE4Z7-FJDL8Vb3s Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 16:52:47 -0000 Hi Michael, Thanks for your review. We used inverted to convey that Consent response (STUN binding response) from remote peer must be from inverted 5-tuple (source and dest addr swapped) of the request sent. I will see how to re-word it. Regards, Ram -----Original Message----- From: Michael Procter Date: Friday, 27 June 2014 3:36 pm To: Ram Mohan Ravindranath Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt >Hi Ram, > >I have a couple of comments about the word "inverted". In section >4.1, the draft says: > > receiving a > matching, authenticated, non-error ICE binding response from the > inverted remote peer's Transport Address. > >I think this means receiving it from the remote peer's Transport >Address, although the presence of 'inverted' made me wonder. If the >word is unnecessary, please remove it. If it is needed, please add >more explanation as to what it means. > >Further on, the draft says: > > That is, if a valid STUN binding response [...] > has not been received from the inverted 5-tuple, [...] > >I think this means receiving it from the 5-tuple, but again, the >presence of 'inverted' made me wonder. Is this a naming issue? I am >happy to send and receive on the same 5-tuple, and I expect my peer to >do the same. However, my peer's 5-tuple will be inverted with respect >to mine! > >Regards, > >Michael > > > >On 18 June 2014 04:33, Ram Mohan R (rmohanr) wrote: >> The new revision has: >> >> 1) Comments from Christer and Charles incorporated. >> 2) Incorporated the feedback received in the interim meeting in Section >>4 >> on re-transmissions, revocation of consent >> 3) Removed the Appendix that had a example as it was no different from >> what is mentioned in solution. >> 4) Updates to section 6 (DiffServ Treatment) based on discussions in the >> mailing list. >> >> Please review and provide your feedback. >> >> Regards, >> Ram >> >> -----Original Message----- >> From: "internet-drafts@ietf.org" >> Date: Wednesday, 18 June 2014 8:47 am >> To: "i-d-announce@ietf.org" >> Cc: "rtcweb@ietf.org" >> Subject: [rtcweb] I-D Action: >> draft-ietf-rtcweb-stun-consent-freshness-04.txt >> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Real-Time Communication in >>>WEB-browsers >>>Working Group of the IETF. >>> >>> Title : STUN Usage for Consent Freshness >>> Authors : Muthu Arul Mozhi Perumal >>> Dan Wing >>> Ram Mohan Ravindranath >>> Tirumaleswar Reddy >>> Martin Thomson >>> Filename : draft-ietf-rtcweb-stun-consent-freshness-04.txt >>> Pages : 9 >>> Date : 2014-06-17 >>> >>>Abstract: >>> To prevent sending excessive traffic to an endpoint, periodic consent >>> needs to be obtained from that remote endpoint. >>> >>> This document describes a consent mechanism using a new STUN usage. >>> This same mechanism can also determine connection loss ("liveness") >>> with a remote peer. >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshnes >>>s/ >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 >>> >>>A diff from the previous version is available at: >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshn= es >>>s- >>>04 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission >>>until the htmlized version and diff are available at tools.ietf.org. >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Jun 29 01:26:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0C51A0381 for ; Sun, 29 Jun 2014 01:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbgnQMF-8YCW for ; Sun, 29 Jun 2014 01:26:17 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id AAC621A029F for ; Sun, 29 Jun 2014 01:26:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6EBF27C387C for ; Sun, 29 Jun 2014 10:26:13 +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 tyi8buTjE4u3 for ; Sun, 29 Jun 2014 10:26:12 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:80a1:71d:836a:9d2e] (unknown [IPv6:2001:470:de0a:27:80a1:71d:836a:9d2e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 18BFE7C385D for ; Sun, 29 Jun 2014 10:26:12 +0200 (CEST) Message-ID: <53AFCDA3.5000508@alvestrand.no> Date: Sun, 29 Jun 2014 10:26:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aeUAmrR1JHrA4PCUCa4diKQLitE Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 08:26:20 -0000 On 06/28/2014 06:52 PM, Ram Mohan R (rmohanr) wrote: > Hi Michael, > > Thanks for your review. > > We used inverted to convey that Consent response (STUN binding response) > from remote peer must be from inverted 5-tuple (source and dest addr > swapped) of the request sent. > I will see how to re-word it. I think it will be fine if you just put in a definition for the term. BTW, I'd like it to be an "inverse" 5-tuple, not an "inverted" one. > > Regards, > Ram > > -----Original Message----- > From: Michael Procter > Date: Friday, 27 June 2014 3:36 pm > To: Ram Mohan Ravindranath > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-04.txt > >> Hi Ram, >> >> I have a couple of comments about the word "inverted". In section >> 4.1, the draft says: >> >> receiving a >> matching, authenticated, non-error ICE binding response from the >> inverted remote peer's Transport Address. >> >> I think this means receiving it from the remote peer's Transport >> Address, although the presence of 'inverted' made me wonder. If the >> word is unnecessary, please remove it. If it is needed, please add >> more explanation as to what it means. >> >> Further on, the draft says: >> >> That is, if a valid STUN binding response [...] >> has not been received from the inverted 5-tuple, [...] >> >> I think this means receiving it from the 5-tuple, but again, the >> presence of 'inverted' made me wonder. Is this a naming issue? I am >> happy to send and receive on the same 5-tuple, and I expect my peer to >> do the same. However, my peer's 5-tuple will be inverted with respect >> to mine! >> >> Regards, >> >> Michael >> >> >> >> On 18 June 2014 04:33, Ram Mohan R (rmohanr) wrote: >>> The new revision has: >>> >>> 1) Comments from Christer and Charles incorporated. >>> 2) Incorporated the feedback received in the interim meeting in Section >>> 4 >>> on re-transmissions, revocation of consent >>> 3) Removed the Appendix that had a example as it was no different from >>> what is mentioned in solution. >>> 4) Updates to section 6 (DiffServ Treatment) based on discussions in the >>> mailing list. >>> >>> Please review and provide your feedback. >>> >>> Regards, >>> Ram >>> >>> -----Original Message----- >>> From: "internet-drafts@ietf.org" >>> Date: Wednesday, 18 June 2014 8:47 am >>> To: "i-d-announce@ietf.org" >>> Cc: "rtcweb@ietf.org" >>> Subject: [rtcweb] I-D Action: >>> draft-ietf-rtcweb-stun-consent-freshness-04.txt >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Real-Time Communication in >>>> WEB-browsers >>>> Working Group of the IETF. >>>> >>>> Title : STUN Usage for Consent Freshness >>>> Authors : Muthu Arul Mozhi Perumal >>>> Dan Wing >>>> Ram Mohan Ravindranath >>>> Tirumaleswar Reddy >>>> Martin Thomson >>>> Filename : draft-ietf-rtcweb-stun-consent-freshness-04.txt >>>> Pages : 9 >>>> Date : 2014-06-17 >>>> >>>> Abstract: >>>> To prevent sending excessive traffic to an endpoint, periodic consent >>>> needs to be obtained from that remote endpoint. >>>> >>>> This document describes a consent mechanism using a new STUN usage. >>>> This same mechanism can also determine connection loss ("liveness") >>>> with a remote peer. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshnes >>>> s/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshnes >>>> s- >>>> 04 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Jun 29 05:36:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108961A049F for ; Sun, 29 Jun 2014 05:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 58rYnspeYIyL for ; Sun, 29 Jun 2014 05:36:47 -0700 (PDT) Received: from mail-we0-f170.google.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with SMTP id A7D621A0496 for ; Sun, 29 Jun 2014 05:36:46 -0700 (PDT) Received: from mail-we0-f170.google.com ([74.125.82.170]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKU7AIXcre4gfGemAeds0YT3yxtx3byrGU@postini.com; Sun, 29 Jun 2014 05:36:46 PDT Received: by mail-we0-f170.google.com with SMTP id w61so6867056wes.1 for ; Sun, 29 Jun 2014 05:36:44 -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=WQUnmIpmYWjOHCpyOjjoB0UGVEP33ECX9XxlZOPdUo4=; b=HAAUmBEvXFhFw2m1PlJdCpiuBL6HVA/yN5QVcs57WcCzTadyjXvlLYOuPUIIeF5psx M8nbOnqXL8yVq0Eo5ioTAjuUNR/BDszTlijAwC0NYPAGb18Ky6y2xLK5kg1ASzH65zUl 7VCtGF5Qes6bYQsLRy8IbXC+353TMIU/9Q9sWKpIx5wxPTN/vfUq4ydOnrFV1quwqxeF tp2ly0/mF6Ec0gQuTlQ/hYwV1xv1fUJYgMRR7oF40Vqo4Dopodolb/cdlgMPapW27rg3 UpU5lMS8B5XBEMmr8pE1AsQjZ7RI4ZN07QpO5XstgJQzxFjqu/MEBt/Vud3sVtVH3hQ5 oC8Q== X-Gm-Message-State: ALoCoQmINDPUB6E471nJPK2ECIjlrrzo+la3ZQ5upvrWCpyy+fHStIXfIcwf6M5/wiIyMX1YyR9D0t0ADEK2dmrTCO7jbghDH4nSgEGUrI8Qy3WWHxnm8t84qSIpT2aAP/s9sDgTHxrR X-Received: by 10.194.71.12 with SMTP id q12mr37902116wju.5.1404045404818; Sun, 29 Jun 2014 05:36:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.71.12 with SMTP id q12mr37902105wju.5.1404045404699; Sun, 29 Jun 2014 05:36:44 -0700 (PDT) Received: by 10.194.190.8 with HTTP; Sun, 29 Jun 2014 05:36:44 -0700 (PDT) In-Reply-To: <53AFCDA3.5000508@alvestrand.no> References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> <53AFCDA3.5000508@alvestrand.no> Date: Sun, 29 Jun 2014 13:36:44 +0100 Message-ID: From: Michael Procter To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lbAiLBl6cqbEdcCTp2oxrOEqzHk Cc: "" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 12:36:49 -0000 On 29 June 2014 09:26, Harald Alvestrand wrote: > I think it will be fine if you just put in a definition for the term. > BTW, I'd like it to be an "inverse" 5-tuple, not an "inverted" one. Adding a definition would be fine for me. And "inverse" is better, too. I had spent some time peering at stun xor-mapped-addresses before reading this draft, so I might have been overly sensitive to the word 'inverted'! Michael From nobody Mon Jun 30 16:44:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FAA1A0402 for ; Mon, 30 Jun 2014 16:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_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 Fgh8holILkTB for ; Mon, 30 Jun 2014 16:44:45 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFC01B27AC for ; Mon, 30 Jun 2014 16:44:45 -0700 (PDT) Received: from [192.168.1.181] (p508F0C46.dip0.t-ipconnect.de [80.143.12.70]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5F50E1C0B4026 for ; Tue, 1 Jul 2014 01:44:43 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 1 Jul 2014 01:44:42 +0200 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Us5fMHbDfo8b8uaMWHWIFiL8Jxg Subject: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 23:44:48 -0000 Dear all, based on a comment from EKR, I would like to bring up a question: RTCWeb uses DTLS for deriving the keys for SRTP on the one hand and for transporting SCTP on the other hand. The SRTP related documents refer to DTLS version 1.0 as specified in http://tools.ietf.org/html/rfc4347 The SCTP over DTLS document currently refers to DTLS version 1.2 as = specified in http://tools.ietf.org/html/rfc6347 I think we need to use a single version of DTLS for RTCWeb. RFC 4347 is = obsoleted by RFC 6347. Wouldn't that imply that it makes sense to use DTLS 1.2 in = all documents? Best regards Michael= From nobody Mon Jun 30 16:49:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB21B27AE for ; Mon, 30 Jun 2014 16:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX4uJknJlDnp for ; Mon, 30 Jun 2014 16:49:20 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7081A0A8D for ; Mon, 30 Jun 2014 16:49:19 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so8709746wgh.26 for ; Mon, 30 Jun 2014 16:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7XWA40gEdTa3y9gXGY9T26HoiiJKvKrVQLAffeA9BGQ=; b=EOR/50xZdmZXy4XMhEhHzhoeC2QOnfjPxewnzkpsVufdlDPPTP4CzCDtFmr/iaseko g4BHhiTu+OkqZG5XuWqYPZI/GU9MgWGVnGOrDL2EVj8X6gJUYwefh4nL9MBEQ/Kjeg+R 2HaGOW2ljKn/V08AX+sWvC9VwG9tW75p8hT421aaGNMsfnR7LkncO/UniLZ9p+TwRenG z8brcvl2STbYAaP9CV0BDQ1/8xcnYbmuGWD/lfjq5Jd86UZdWQHYHNpAtUXKml+vDOTV 0ck2IVXreCseODe+U7ynxhTtW1G5vX2PxUN7xVsst91eTA7h8B8XWBvyuvd9m3Qkdonp WT3Q== X-Received: by 10.180.75.75 with SMTP id a11mr32058824wiw.3.1404172158454; Mon, 30 Jun 2014 16:49:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.80.69 with HTTP; Mon, 30 Jun 2014 16:48:57 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Mon, 30 Jun 2014 16:48:57 -0700 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=f46d04388e95b5564704fd164e6a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/owsQ7ADpGCvu92zlOwVJHVRW5UE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 23:49:23 -0000 --f46d04388e95b5564704fd164e6a Content-Type: text/plain; charset=UTF-8 "Wouldn't that imply that it makes sense to use DTLS 1.2 in all documents?" [BA] Not necessarily. As I understand it, existing implementations only support 1.0 - and if we were to mandate only 1.2 ciphersuites, then this would create an interoperability problem. On Mon, Jun 30, 2014 at 4:44 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > Dear all, > > based on a comment from EKR, I would like to bring up a question: > RTCWeb uses DTLS for deriving the keys for SRTP on the one hand and > for transporting SCTP on the other hand. > The SRTP related documents refer to DTLS version 1.0 as specified in > http://tools.ietf.org/html/rfc4347 > The SCTP over DTLS document currently refers to DTLS version 1.2 as > specified in > http://tools.ietf.org/html/rfc6347 > > I think we need to use a single version of DTLS for RTCWeb. RFC 4347 is > obsoleted > by RFC 6347. Wouldn't that imply that it makes sense to use DTLS 1.2 in > all documents? > > Best regards > Michael > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d04388e95b5564704fd164e6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"Wouldn't that imply that it makes sense to = use DTLS 1.2 in all documents?"

[BA] Not necessarily.=C2= =A0 As I understand it, existing implementations only support 1.0 - and if = we were to mandate only 1.2 ciphersuites, then this would create an interop= erability problem.


On Mon,= Jun 30, 2014 at 4:44 PM, Michael Tuexen <Michael.Tuexen@lu= rchi.franken.de> wrote:
Dear all,

based on a comment from EKR, I would like to bring up a question:
RTCWeb uses DTLS for deriving the keys for SRTP on the one hand and
for transporting SCTP on the other hand.
The SRTP related documents refer to DTLS version 1.0 as specified in
http://too= ls.ietf.org/html/rfc4347
The SCTP over DTLS document currently refers to DTLS version 1.2 as specifi= ed in
http://too= ls.ietf.org/html/rfc6347

I think we need to use a single version of DTLS for RTCWeb. RFC 4347 is obs= oleted
by RFC 6347. Wouldn't that imply that it makes sense to use DTLS 1.2 in= all documents?

Best regards
Michael
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d04388e95b5564704fd164e6a-- From nobody Mon Jun 30 16:55:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D071A0453 for ; Mon, 30 Jun 2014 16:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_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 GlRmUhP-Q3Z6 for ; Mon, 30 Jun 2014 16:55:12 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817F61A0415 for ; Mon, 30 Jun 2014 16:55:12 -0700 (PDT) Received: from [192.168.1.181] (p508F0C46.dip0.t-ipconnect.de [80.143.12.70]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B29651C104D83; Tue, 1 Jul 2014 01:55:10 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Tue, 1 Jul 2014 01:55:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PIx4hOxFO_BeM5h6GrGWXiGotgU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 23:55:14 -0000 On 01 Jul 2014, at 01:48, Bernard Aboba wrote: > "Wouldn't that imply that it makes sense to use DTLS 1.2 in all = documents?" >=20 > [BA] Not necessarily. As I understand it, existing implementations = only support 1.0 - and if we were to mandate only 1.2 ciphersuites, then = this would create an interoperability problem.=20 There are also several clarifications and corrections to handshake = issues. This really helps in interoperability.... Best regards Michael >=20 >=20 > On Mon, Jun 30, 2014 at 4:44 PM, Michael Tuexen = wrote: > Dear all, >=20 > based on a comment from EKR, I would like to bring up a question: > RTCWeb uses DTLS for deriving the keys for SRTP on the one hand and > for transporting SCTP on the other hand. > The SRTP related documents refer to DTLS version 1.0 as specified in > http://tools.ietf.org/html/rfc4347 > The SCTP over DTLS document currently refers to DTLS version 1.2 as = specified in > http://tools.ietf.org/html/rfc6347 >=20 > I think we need to use a single version of DTLS for RTCWeb. RFC 4347 = is obsoleted > by RFC 6347. Wouldn't that imply that it makes sense to use DTLS 1.2 = in all documents? >=20 > Best regards > Michael > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Jun 30 17:21:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663311A044D for ; Mon, 30 Jun 2014 17:20:58 -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 JvGkuY_ciBe1 for ; Mon, 30 Jun 2014 17:20:57 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5481D1A0426 for ; Mon, 30 Jun 2014 17:20:57 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id m1so9696679oag.35 for ; Mon, 30 Jun 2014 17:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+5FLLaxOynaB8DuHP5Kpw3c+lNE49b2Dw7VT4kn5rr8=; b=xEQ42yqCgo2QEZXGSHZ9MWKraAoLjm6lLVqA2d+ghCtgDjL2RH4om8/abWHH3o03kP H7xGpwrYlvR16o7CJaOwuGYZmWKgZod9Exhci8YrFkpEph+glcHB6a+M14cAfUMDf1iz kjzSU4ooHQ6/MokhFMxuf5rrPK+f5YMaaxxzMutwUHQojH6nnphSlN/IfKjLbNI41fwN x7ulAZ3s4BT2A8vH2NeEYLwHC07YJsrFjVslNGx+dtGWwYHuv7bk//j4lYCGtDfVfopk 14kYev5m8+nZHQkxvzkM6nGsbmJ3IuAXUZFiHTQxONKXVNrgvRpFLu+u5ESuRvmtMFSZ JQgw== MIME-Version: 1.0 X-Received: by 10.182.191.106 with SMTP id gx10mr12246781obc.69.1404174056776; Mon, 30 Jun 2014 17:20:56 -0700 (PDT) Received: by 10.60.40.6 with HTTP; Mon, 30 Jun 2014 17:20:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jun 2014 17:20:56 -0700 Message-ID: From: Martin Thomson To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wt21BnkMptMbKTE6msXeq02BuE8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 00:20:58 -0000 On 30 June 2014 16:55, Michael Tuexen wrote: >> "Wouldn't that imply that it makes sense to use DTLS 1.2 in all documents?" >> >> [BA] Not necessarily. As I understand it, existing implementations only support 1.0 - and if we were to mandate only 1.2 ciphersuites, then this would create an interoperability problem. > There are also several clarifications and corrections to handshake issues. This > really helps in interoperability.... Bernard is right. But there are several advantages to an update to referencing (D)TLS 1.2. For one, we get better ciphersuites (AES-GCM and all the AEAD modes). That said, there are enough implementations out there already that *requiring* 1.2 might be too aggressive. I think that I'd prefer that (so that we can make modern ciphersuite recommendations to fit), but if someone has a strong need for 1.0, I don't have a problem suggesting that 1.0 be accepted. p.s., DTLS 1.2 is coming in Firefox. As it turns out, NSS supported it, but it hadn't been turned on.