From nobody Mon Feb 2 09:05:03 2015 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 3CD7F1A1A4D for ; Mon, 2 Feb 2015 06:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrfnPaLiTFe3 for ; Mon, 2 Feb 2015 06:18:39 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE901A1F70 for ; Mon, 2 Feb 2015 06:16:34 -0800 (PST) Received: (qmail 79923 invoked from network); 2 Feb 2015 14:16:32 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 8604 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 2 Feb 2015 14:16:32 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id D4E7618A0B61; Mon, 2 Feb 2015 14:16:30 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C563B18A0138; Mon, 2 Feb 2015 14:16:30 +0000 (GMT) From: Tim Panton Content-Type: multipart/alternative; boundary="Apple-Mail=_6F972E43-2EA1-41BC-9BC9-6062EA970ABF" Date: Mon, 2 Feb 2015 14:16:30 +0000 Message-Id: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> To: public-webrtc Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 09:05:00 -0800 Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" Subject: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 14:18:43 -0000 --Apple-Mail=_6F972E43-2EA1-41BC-9BC9-6062EA970ABF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Firstly- sorry for cross posting - I=E2=80=99m not sure which side of = the line this falls. Secondly - if this is covered, please let me know, I don=E2=80=99t = recall it cropping up... I=E2=80=99ve been reading worried blogs that WEBRTC in browsers = =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2=80=99 ip addresses to = the javascript. The principle worriers are VPN users e.g = https://cryptostorm.org/viewtopic.php?f=3D50&t=3D2867&p=3D13096#p13096 = The concern is that this can be done without user notification = (DataChannel request) and might be used to=20 identify or finger-print users. Clearly the most vulnerable are Tor = users who are on a real routeable IP address or directly on a carrier grade nat (eg android phones etc) where the IP = may reveal the identity or location of the user. It seems to me that this concern will be increased in the case of ipv6 = deployments (MNOs). Do we need to specify a config option on the browser =E2=80=98I=E2=80=99m = using a VPN don=E2=80=99t expose my local IP=E2=80=99=20 Again, sorry if I missed this being hashed to death already.=20 T Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_6F972E43-2EA1-41BC-9BC9-6062EA970ABF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Firstly- sorry for cross posting - I=E2=80=99m = not sure which side of the line this falls.
Secondly = - if this is covered, please let me know, I don=E2=80=99t recall it = cropping up...

I=E2=80=99ve been reading worried blogs that WEBRTC in = browsers =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2=80=99 ip = addresses to the javascript.
The principle worriers = are VPN users e.g https://cryptostorm.org/viewtopic.php?f=3D50&t=3D2867&p= =3D13096#p13096
The concern is that this can be = done without user notification (DataChannel request) and might be used = to 
identify or finger-print users. Clearly = the most vulnerable are Tor users who are on a real routeable IP = address
or directly on a carrier grade nat (eg = android phones etc) where the IP may reveal the identity or location of = the user.

It = seems to me that this concern will be increased in the case of ipv6 = deployments (MNOs).

Do we need to specify a config option on the browser =E2=80=98I= =E2=80=99m using a VPN don=E2=80=99t expose my local = IP=E2=80=99 

Again, sorry if I missed this being hashed to death = already. 

T

Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_6F972E43-2EA1-41BC-9BC9-6062EA970ABF-- From nobody Mon Feb 2 09:05:13 2015 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 DA8121A1A23 for ; Mon, 2 Feb 2015 06:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp_lgxQa2vHK for ; Mon, 2 Feb 2015 06:34:12 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0FD1A1A03 for ; Mon, 2 Feb 2015 06:34:11 -0800 (PST) Received: (qmail 77618 invoked from network); 2 Feb 2015 14:34:10 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 8946 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 2 Feb 2015 14:34:10 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 947B718A0427 for ; Mon, 2 Feb 2015 14:34:09 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 85F4018A0AE2 for ; Mon, 2 Feb 2015 14:34:09 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_8F081823-C453-4A5C-BFA6-2CE530841D1A" From: Tim Panton Resent-Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" Resent-From: Tim Panton Date: Mon, 2 Feb 2015 14:16:30 +0000 Resent-Date: Mon, 2 Feb 2015 14:34:08 +0000 Message-Id: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> To: public-webrtc X-Mailer: Apple Mail (2.1993) Resent-Message-Id: <20150202143409.85F4018A0AE2@zimbra003.verygoodemail.com> Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 09:05:00 -0800 Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" Subject: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 14:34:15 -0000 --Apple-Mail=_8F081823-C453-4A5C-BFA6-2CE530841D1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Firstly- sorry for cross posting (to w3c webrtc) - I=E2=80=99m not sure = which side of the line this falls. Secondly - if this is covered, please let me know, I don=E2=80=99t = recall it cropping up... I=E2=80=99ve been reading worried blogs that WEBRTC in browsers = =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2=80=99 ip addresses to = the javascript. The principle worriers are VPN users e.g = https://cryptostorm.org/viewtopic.php?f=3D50&t=3D2867&p=3D13096#p13096 = The concern is that this can be done without user notification = (DataChannel request) and might be used to=20 identify or finger-print users. Clearly the most vulnerable are Tor = users who are on a real routeable IP address or directly on a carrier grade nat (eg android phones etc) where the IP = may reveal the identity or location of the user. It seems to me that this concern will be increased in the case of ipv6 = deployments (MNOs). Do we need to specify a config option on the browser =E2=80=98I=E2=80=99m = using a VPN don=E2=80=99t expose my local IP=E2=80=99=20 Again, sorry if I missed this being hashed to death already.=20 T Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_8F081823-C453-4A5C-BFA6-2CE530841D1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Firstly- sorry for cross = posting (to w3c webrtc) - I=E2=80=99m not sure which side of the line = this falls.
Secondly - if this is covered, please = let me know, I don=E2=80=99t recall it cropping up...

I=E2=80=99ve been = reading worried blogs that WEBRTC in browsers =E2=80=98leaks=E2=80=99 = the local =E2=80=98real=E2=80=99 ip addresses to the = javascript.
The principle worriers are VPN users = e.g https://cryptostorm.org/viewtopic.php?f=3D50&t=3D2867&p= =3D13096#p13096
The concern is that this can be = done without user notification (DataChannel request) and might be used = to 
identify or finger-print users. Clearly = the most vulnerable are Tor users who are on a real routeable IP = address
or directly on a carrier grade nat (eg = android phones etc) where the IP may reveal the identity or location of = the user.

It = seems to me that this concern will be increased in the case of ipv6 = deployments (MNOs).

Do we need to specify a config option on the browser =E2=80=98I= =E2=80=99m using a VPN don=E2=80=99t expose my local = IP=E2=80=99 

Again, sorry if I missed this being hashed to death = already. 

T

Tim Panton - Web/VoIP consultant and = implementor
www.westhawk.co.uk



= --Apple-Mail=_8F081823-C453-4A5C-BFA6-2CE530841D1A-- From bemasc@google.com Mon Feb 2 06:58:14 2015 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 534911A1AFB for ; Mon, 2 Feb 2015 06:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC_e4REWbi59 for ; Mon, 2 Feb 2015 06:58:12 -0800 (PST) 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 9E35F1A1A73 for ; Mon, 2 Feb 2015 06:58:12 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hq12so14729503vcb.0 for ; Mon, 02 Feb 2015 06:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vlCTwVeA9NhMLD61Rn0n2FU997wYaJ8fgn5acGMG1n8=; b=ITNsz9vzCGFF8lMfSGXzR8qcNv/TEOSrOwD09/clMJu6f/YhZwHH757kqugqwKaoH5 Mo89t/zq/bLVn+/VxfMRFWuaKw4Ts3kspBLvNAircVJZbejP2U1jqMRvjAhISrbkEBY7 q7ezBuO/2cvmY6+CKSIlbUVccO7AbJ665pZKXbmpSiZyU2rF2Wh008dTswi9+9Xp3pKu 7I1r5t55EmRndqju6D9v90JVSc1+Fd0atfonocGotKUteQsaKuvyUz7IDhM3xLMbyICP fiZgRTf/LVFr/caTlfkoftMbDcTATAunk26hcWcJvoMyfdOt6tqvF2SuDNw4LEAvhhmX WREA== 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=vlCTwVeA9NhMLD61Rn0n2FU997wYaJ8fgn5acGMG1n8=; b=MqYIHjfaQVXVzCZSrF6/Rm8sWtWk/kSdWWHUwtcTniaGUyx1PDKRq4FI3iY7t1aGSs f2AZL0cQjlu2Gt/sCzlfI1m0YSIl8pteupAVqmQgdyTV+S1VGzCYCBMXp7d+TAQZW/xV YzRUu+RI6R0Fxo0ErsO3VN+Jc/K/HczS4/Do1uoNz135ZE4Dwz4mBxjvH43DEqKCkiA6 7GUJTT1ylCY4pIgTaxnA4N0IxJ8CWzPwHNcFmfkwZdqvmWXXiEv6q+YgHJoj3L5l0sdP Gl9uQeVedwfXqDIvOiEO919BF66Ri0tKRaWY6/0LyIYOeOQDNk0A4PgGcxKyx/lAyWpO YodQ== X-Gm-Message-State: ALoCoQnOIbvNqMWj8eaM8Da3ApFjrLeS2BtLgRJ4buqiA459Sdm4fmgVvSsm7Xuup3vOmyVHCFeV MIME-Version: 1.0 X-Received: by 10.52.156.130 with SMTP id we2mr5782793vdb.72.1422889091729; Mon, 02 Feb 2015 06:58:11 -0800 (PST) Received: by 10.52.54.194 with HTTP; Mon, 2 Feb 2015 06:58:11 -0800 (PST) In-Reply-To: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> Date: Mon, 2 Feb 2015 09:58:11 -0500 Message-ID: From: Benjamin Schwartz To: Tim Panton Content-Type: multipart/alternative; boundary=089e01634ccade239c050e1c2ea0 Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 09:05:00 -0800 Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" , public-webrtc Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 15:08:39 -0000 --089e01634ccade239c050e1c2ea0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Standards-wise: You might want to have a look at http://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-5.3 (a draft which I'm hoping will be adopted by the rtcweb group). Reality-wise: Tor is not a VPN. It acts as a SOCKS5 proxy. Tor doesn't support UDP, and none of the major browsers support SOCKS5-UDP anyway, so it's not much use for WebRTC. Tor Browser Bundle, IMHO the only responsible way to use Tor, has disabled WebRTC from the beginning, precisely to avoid revealing the user's IP address. VPN users who want to be safe should set permissions such that the browser can only access the VPN, not the physical network. (I don't personally know how to do this, especially on all different operating systems!) On Mon, Feb 2, 2015 at 9:16 AM, Tim Panton wrote: > Firstly- sorry for cross posting - I=E2=80=99m not sure which side of the= line > this falls. > Secondly - if this is covered, please let me know, I don=E2=80=99t recall= it > cropping up... > > I=E2=80=99ve been reading worried blogs that WEBRTC in browsers =E2=80=98= leaks=E2=80=99 the local > =E2=80=98real=E2=80=99 ip addresses to the javascript. > The principle worriers are VPN users e.g > https://cryptostorm.org/viewtopic.php?f=3D50&t=3D2867&p=3D13096#p13096 > The concern is that this can be done without user notification > (DataChannel request) and might be used to > identify or finger-print users. Clearly the most vulnerable are Tor users > who are on a real routeable IP address > or directly on a carrier grade nat (eg android phones etc) where the IP > may reveal the identity or location of the user. > > It seems to me that this concern will be increased in the case of ipv6 > deployments (MNOs). > > Do we need to specify a config option on the browser =E2=80=98I=E2=80=99m= using a VPN > don=E2=80=99t expose my local IP=E2=80=99 > > Again, sorry if I missed this being hashed to death already. > > T > > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk > > > > --089e01634ccade239c050e1c2ea0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
On Mon, Feb 2, 2015 at 9:16 AM, Tim Panton <= span dir=3D"ltr"><thp@westhawk.co.uk> wrote:
Firstly- sorry for cross posting= - I=E2=80=99m not sure which side of the line this falls.
Second= ly - if this is covered, please let me know, I don=E2=80=99t recall it crop= ping up...

I=E2=80=99ve been reading worried blogs= that WEBRTC in browsers =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2= =80=99 ip addresses to the javascript.
The conc= ern is that this can be done without user notification (DataChannel request= ) and might be used to=C2=A0
identify or finger-print users. Clea= rly the most vulnerable are Tor users who are on a real routeable IP addres= s
or directly on a carrier grade nat (eg android phones etc) wher= e the IP may reveal the identity or location of the user.

It seems to me that this concern will be increased in the case of i= pv6 deployments (MNOs).

Do we need to specify a co= nfig option on the browser =E2=80=98I=E2=80=99m using a VPN don=E2=80=99t e= xpose my local IP=E2=80=99=C2=A0

Again, sorry if I= missed this being hashed to death already.=C2=A0

= T

Tim Panton - W= eb/VoIP consultant and implementor




--089e01634ccade239c050e1c2ea0-- From nobody Mon Feb 2 12:00:37 2015 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 336071A1ACA for ; Mon, 2 Feb 2015 12:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yr63zy-AkXUh for ; Mon, 2 Feb 2015 12:00:23 -0800 (PST) Received: from Mail3.kpnnet.org (mail3.kpnnet.org [192.58.226.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F43D1A8033 for ; Mon, 2 Feb 2015 12:00:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,507,1418079600"; d="scan'208,217";a="138256345" Received: from w2004.kpnnl.local ([10.75.81.3]) by Mail3.kpnnet.org with ESMTP; 02 Feb 2015 21:30:52 +0100 Received: from W3014.kpnnl.local (158.67.247.23) by W2004.kpnnl.local (10.75.81.3) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 2 Feb 2015 20:58:10 +0100 Received: from W3018.kpnnl.local ([fe80::901f:81cf:ea70:9e75]) by W3014.kpnnl.local ([169.254.4.197]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 20:58:09 +0100 From: To: Thread-Topic: [rtcweb] ICE exposes 'real' local IP to javascript Thread-Index: AQHQPwp9s87XqwGewUumvP+AnHU1QpzdYnqAgABkkww= Date: Mon, 2 Feb 2015 19:58:09 +0000 Message-ID: <715F96D7-0BCA-4C91-BDEC-9DF28FD9A484@kpn.com> References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk>, In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_715F96D70BCA4C91BDEC9DF28FD9A484kpncom_" MIME-Version: 1.0 Archived-At: Cc: rtcweb@ietf.org, thp@westhawk.co.uk, public-webrtc@w3.org Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 20:00:31 -0000 --_000_715F96D70BCA4C91BDEC9DF28FD9A484kpncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Isn't that done by whitelisting. You as a user use a application wich uses = webrtc. M.vr.gr., Richard van Det 06 2054 7291 Op 2 feb. 2015 om 18:05 heeft Benjamin Schwartz > het volgende geschreven: Standards-wise: You might want to have a look at http://tools.ietf.org/html= /draft-schwartz-rtcweb-return-04#section-5.3 (a draft which I'm hoping will= be adopted by the rtcweb group). Reality-wise: Tor is not a VPN. It acts as a SOCKS5 proxy. Tor doesn't support UDP, and= none of the major browsers support SOCKS5-UDP anyway, so it's not much use= for WebRTC. Tor Browser Bundle, IMHO the only responsible way to use Tor,= has disabled WebRTC from the beginning, precisely to avoid revealing the u= ser's IP address. VPN users who want to be safe should set permissions such that the browser = can only access the VPN, not the physical network. (I don't personally kno= w how to do this, especially on all different operating systems!) On Mon, Feb 2, 2015 at 9:16 AM, Tim Panton > wrote: Firstly- sorry for cross posting - I=92m not sure which side of the line th= is falls. Secondly - if this is covered, please let me know, I don=92t recall it crop= ping up... I=92ve been reading worried blogs that WEBRTC in browsers =91leaks=92 the l= ocal =91real=92 ip addresses to the javascript. The principle worriers are VPN users e.g https://cryptostorm.org/viewtopic.= php?f=3D50&t=3D2867&p=3D13096#p13096 The concern is that this can be done without user notification (DataChannel= request) and might be used to identify or finger-print users. Clearly the most vulnerable are Tor users w= ho are on a real routeable IP address or directly on a carrier grade nat (eg android phones etc) where the IP may= reveal the identity or location of the user. It seems to me that this concern will be increased in the case of ipv6 depl= oyments (MNOs). Do we need to specify a config option on the browser =91I=92m using a VPN d= on=92t expose my local IP=92 Again, sorry if I missed this being hashed to death already. T Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_715F96D70BCA4C91BDEC9DF28FD9A484kpncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Isn't that done by whitelisting. You as a user use a application wich = uses webrtc.

M.vr.gr.,

Richard van Det
06 2054 7291

Op 2 feb. 2015 om 18:05 heeft Benjamin Schwartz <bemasc@google.com> het volgende geschreven:


On Mon, Feb 2, 2015 at 9:16 AM, Tim Panton <thp@westhawk.co= .uk> wrote:
Firstly- sorry for cross posting - I=92m not sure which side of the li= ne this falls.
Secondly - if this is covered, please let me know, I don=92t recall it= cropping up...

I=92ve been reading worried blogs that WEBRTC in browsers =91leaks=92 = the local =91real=92 ip addresses to the javascript.
The concern is that this can be done without user notification (DataCh= annel request) and might be used to 
identify or finger-print users. Clearly the most vulnerable are Tor us= ers who are on a real routeable IP address
or directly on a carrier grade nat (eg android phones etc) where the I= P may reveal the identity or location of the user.

It seems to me that this concern will be increased in the case of ipv6= deployments (MNOs).

Do we need to specify a config option on the browser =91I=92m using a = VPN don=92t expose my local IP=92 

Again, sorry if I missed this being hashed to death already. 

T

Tim Panton - Web/VoIP consultant and implementor




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_715F96D70BCA4C91BDEC9DF28FD9A484kpncom_-- From nobody Mon Feb 2 13:14:20 2015 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 C48991A9073 for ; Mon, 2 Feb 2015 13:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL_3j3kWwwhC for ; Mon, 2 Feb 2015 13:14:08 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973A31A9068 for ; Mon, 2 Feb 2015 13:13:23 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-26-54cfe8710bc4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 73.B5.04484.178EFC45; Mon, 2 Feb 2015 22:13:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0210.002; Mon, 2 Feb 2015 22:13:20 +0100 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Tim Panton , public-webrtc Thread-Topic: ICE exposes 'real' local IP to javascript Thread-Index: AQHQPvMv+BxouWAcQ0+2Cl6Uwu5GKJzdnZZA Date: Mon, 2 Feb 2015 21:13:20 +0000 Message-ID: <532A6DC6F9C115439C41705FF73D13871D1B5F96@ESESSMB209.ericsson.se> References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> In-Reply-To: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_532A6DC6F9C115439C41705FF73D13871D1B5F96ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RrfwxfkQg2+fVSx6Py5htFj7r53d Yt37YywOzB5Llvxk8jg6bz+rx8Vp+5kCmKO4bFJSczLLUov07RK4Mvo3z2ItOFFdcXuRYgPj nIouRk4OCQETiXPNl9khbDGJC/fWs4HYQgJHGCV+H7brYuQCshcxSpy62MUEkmAT8JZoaznM AmKLCHhKPLv2EqyBWcBKYvWHLYwgtrCAmcSvw/1A9RxANeYSn5bIQ5QbSRztnQVWziKgInHn 8RtWEJtXwFfizssb7BB7HSWurHkKNoZTwElizdUTYPWMArIS97/fY4FYJS5x68l8JoibBSSW 7DnPDGGLSrx8/I8VwlaSWHt4O1R9vkRbx2JmiF2CEidnPmGZwCg6C8moWUjKZiEpmwX0AbOA psT6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRfxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREY fQe3/DbYwfjyueMhRgEORiUe3gKF8yFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamCsVIuVbeTOrlp7zdVbcoev6lH3p3oSpi12BTKzjjFfvCoS5PnCQEuQ U429lVuOx8jA2jW+Qly+TMLSpeN5/rd3Ske3KAermbEnscoIaCw4/VHaUYh90rYPjjMmhxX1 ZzlsELimsKUsfo5zSXpIvOIvFaEWc70vfySOLit7ENwwg/2Zv1eQEktxRqKhFnNRcSIATeiK YZ8CAAA= Archived-At: Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 21:14:14 -0000 --_000_532A6DC6F9C115439C41705FF73D13871D1B5F96ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFRpbSBQYW50b24gW21haWx0bzp0aHBAd2VzdGhhd2suY28udWtdDQpTZW50OiBk ZW4gMiBmZWJydWFyaSAyMDE1IDE1OjE3DQpUbzogcHVibGljLXdlYnJ0Yw0KQ2M6IHJ0Y3dlYkBp ZXRmLm9yZyA+PiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IElDRSBleHBvc2VzICdyZWFsJyBs b2NhbCBJUCB0byBqYXZhc2NyaXB0DQoNCkZpcnN0bHktIHNvcnJ5IGZvciBjcm9zcyBwb3N0aW5n IC0gSeKAmW0gbm90IHN1cmUgd2hpY2ggc2lkZSBvZiB0aGUgbGluZSB0aGlzIGZhbGxzLg0KU2Vj b25kbHkgLSBpZiB0aGlzIGlzIGNvdmVyZWQsIHBsZWFzZSBsZXQgbWUga25vdywgSSBkb27igJl0 IHJlY2FsbCBpdCBjcm9wcGluZyB1cC4uLg0KDQpJ4oCZdmUgYmVlbiByZWFkaW5nIHdvcnJpZWQg YmxvZ3MgdGhhdCBXRUJSVEMgaW4gYnJvd3NlcnMg4oCYbGVha3PigJkgdGhlIGxvY2FsIOKAmHJl YWzigJkgaXAgYWRkcmVzc2VzIHRvIHRoZSBqYXZhc2NyaXB0Lg0KVGhlIHByaW5jaXBsZSB3b3Jy aWVycyBhcmUgVlBOIHVzZXJzIGUuZyBodHRwczovL2NyeXB0b3N0b3JtLm9yZy92aWV3dG9waWMu cGhwP2Y9NTAmdD0yODY3JnA9MTMwOTYjcDEzMDk2DQpUaGUgY29uY2VybiBpcyB0aGF0IHRoaXMg Y2FuIGJlIGRvbmUgd2l0aG91dCB1c2VyIG5vdGlmaWNhdGlvbiAoRGF0YUNoYW5uZWwgcmVxdWVz dCkgYW5kIG1pZ2h0IGJlIHVzZWQgdG8NCmlkZW50aWZ5IG9yIGZpbmdlci1wcmludCB1c2Vycy4g Q2xlYXJseSB0aGUgbW9zdCB2dWxuZXJhYmxlIGFyZSBUb3IgdXNlcnMgd2hvIGFyZSBvbiBhIHJl YWwgcm91dGVhYmxlIElQIGFkZHJlc3MNCm9yIGRpcmVjdGx5IG9uIGEgY2FycmllciBncmFkZSBu YXQgKGVnIGFuZHJvaWQgcGhvbmVzIGV0Yykgd2hlcmUgdGhlIElQIG1heSByZXZlYWwgdGhlIGlk ZW50aXR5IG9yIGxvY2F0aW9uIG9mIHRoZSB1c2VyLg0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IHRo aXMgY29uY2VybiB3aWxsIGJlIGluY3JlYXNlZCBpbiB0aGUgY2FzZSBvZiBpcHY2IGRlcGxveW1l bnRzIChNTk9zKS4NCg0KRG8gd2UgbmVlZCB0byBzcGVjaWZ5IGEgY29uZmlnIG9wdGlvbiBvbiB0 aGUgYnJvd3NlciDigJhJ4oCZbSB1c2luZyBhIFZQTiBkb27igJl0IGV4cG9zZSBteSBsb2NhbCBJ UOKAmQ0KDQpBZ2Fpbiwgc29ycnkgaWYgSSBtaXNzZWQgdGhpcyBiZWluZyBoYXNoZWQgdG8gZGVh dGggYWxyZWFkeS4NCltHQVBFOl0gVGhlcmUgYXJlIGRpZmZlcmVudCDigJxjaGFsbGVuZ2Vz4oCd IGFzIEkgc2VlIGl0OyBhKSBvbmUgdG8g4oCYaGlkZeKAmSB0aGUgaW5mb3JtYXRpb24gZnJvbSB0 aGUgaW52b2x2ZWQgd2ViIHNpdGVzIGFuZCBwZWVycyBhbmQgYikgYW5vdGhlciBmcm9tIGEgd2Vi IHNpdGUgb3duZXIgcGVyc3BlY3RpdmUsIGhvdyB0byBzYWZlZ3VhcmQgdXNlcnMgcHJpdmFjeSBh bmQgc2VjdXJpdHkuIOKAmGHigJkgaGFzIGJlZW4gZGlzY3Vzc2VkIGFuZCBwYXJ0bHkgYWRkcmVz c2VkLCBlLmcuICBpbiBbMV0gYW5kIFsyXSAuDQpGb3Ig4oCYYuKAmSwgd2UgaGF2ZSBXZWIgcGxh dGZvcm0gbWVjaGFuaXNtcyBDU1AgWzMsNF0gKGFuZCBDT1JTKSB0aGF0IHRoZSB3ZWIgc2l0ZSBh ZG1pbiBjYW4gdXNlIHRvIGdldCBoZWxwIGZyb20gdGhlIFVBIHRvIGRvIGRlZmVuc2UtaW4tZGVw dGguIE5vdywgSSBtYXkgaGF2ZSBtaXNzZWQgaXQgYnV0IGhhcyB0aGVyZSBiZWVuIGFueSBpbi1k ZXB0aCBkaXNjdXNzaW9uIGFib3V0IENTUCAoZXhpc3Rpbmcgb3IgbmV3IGRpcmVjdGl2ZXMgZm9y IHRoZSBPL0EgcHJvY2VkdXJlLCBldGMuIGZvciBhcyBXZWIgc2l0ZSB1c2luZyB0aGUgV2ViUlRD IEFQSSBub3IgaXMgdGhlcmUgYW55dGhpbmcgbWVudGlvbmVkIGluIHRoZSBsYXRlc3QgVzNDICB3 b3JraW5nIGRyYWZ0LiBQZXJoYXBzIEnigJl2ZSBtaXNzZWQgaXQtIHdoYXQgaXMgdGhlIHN0YXR1 cz8gUG9zdHBvbmVkIHRvIGZ1dHVyZSB3b3JrPw0KDQpHw7ZyYW4NCg0KWzFdIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gvDQpb Ml0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVy bi0wNCNzZWN0aW9uLTUuMw0KWzNdIENTUCBMZXZlbCAxLjEsIGh0dHA6Ly93d3cudzMub3JnL1RS L0NTUC8NCls0XUNTUCBMZXZlbCAxLjIgKERyYWZ0KSwgaHR0cDovL3d3dy53My5vcmcvVFIvQ1NQ Mi8NCg0KDQpUDQoNClRpbSBQYW50b24gLSBXZWIvVm9JUCBjb25zdWx0YW50IGFuZCBpbXBsZW1l bnRvcg0Kd3d3Lndlc3RoYXdrLmNvLnVrPGh0dHA6Ly93d3cud2VzdGhhd2suY28udWs+DQoNCg0K DQo= --_000_532A6DC6F9C115439C41705FF73D13871D1B5F96ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDENCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJ bXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFyIjsNCgltYXJnaW4tdG9wOjI0LjBwdDsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCglmb250 LXNpemU6MTQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiMz NjVGOTE7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1z dHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSGVhZGluZzFD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7DQoJZm9udC1mYW1pbHk6IkNhbWJy aWEiLCJzZXJpZiI7DQoJY29sb3I6IzM2NUY5MTsNCglmb250LXdlaWdodDpib2xkO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUaW0gUGFu dG9uIFttYWlsdG86dGhwQHdlc3RoYXdrLmNvLnVrXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAy IGZlYnJ1YXJpIDIwMTUgMTU6MTc8YnI+DQo8Yj5Ubzo8L2I+IHB1YmxpYy13ZWJydGM8YnI+DQo8 Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZyAmZ3Q7Jmd0OyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gSUNFIGV4cG9zZXMgJ3JlYWwnIGxvY2FsIElQIHRvIGphdmFzY3JpcHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rmly c3RseS0gc29ycnkgZm9yIGNyb3NzIHBvc3RpbmcgLSBJ4oCZbSBub3Qgc3VyZSB3aGljaCBzaWRl IG9mIHRoZSBsaW5lIHRoaXMgZmFsbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWNvbmRseSAtIGlmIHRoaXMgaXMgY292ZXJlZCwgcGxlYXNl IGxldCBtZSBrbm93LCBJIGRvbuKAmXQgcmVjYWxsIGl0IGNyb3BwaW5nIHVwLi4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJl2ZSBiZWVu IHJlYWRpbmcgd29ycmllZCBibG9ncyB0aGF0IFdFQlJUQyBpbiBicm93c2VycyDigJhsZWFrc+KA mSB0aGUgbG9jYWwg4oCYcmVhbOKAmSBpcCBhZGRyZXNzZXMgdG8gdGhlIGphdmFzY3JpcHQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJp bmNpcGxlIHdvcnJpZXJzIGFyZSBWUE4gdXNlcnMgZS5nIDxhIGhyZWY9Imh0dHBzOi8vY3J5cHRv c3Rvcm0ub3JnL3ZpZXd0b3BpYy5waHA/Zj01MCZhbXA7dD0yODY3JmFtcDtwPTEzMDk2I3AxMzA5 NiI+DQpodHRwczovL2NyeXB0b3N0b3JtLm9yZy92aWV3dG9waWMucGhwP2Y9NTAmYW1wO3Q9Mjg2 NyZhbXA7cD0xMzA5NiNwMTMwOTY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY29uY2VybiBpcyB0aGF0IHRoaXMgY2FuIGJlIGRvbmUg d2l0aG91dCB1c2VyIG5vdGlmaWNhdGlvbiAoRGF0YUNoYW5uZWwgcmVxdWVzdCkgYW5kIG1pZ2h0 IGJlIHVzZWQgdG8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmlkZW50aWZ5IG9yIGZpbmdlci1wcmludCB1c2Vycy4gQ2xlYXJseSB0aGUg bW9zdCB2dWxuZXJhYmxlIGFyZSBUb3IgdXNlcnMgd2hvIGFyZSBvbiBhIHJlYWwgcm91dGVhYmxl IElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPm9yIGRpcmVjdGx5IG9uIGEgY2FycmllciBncmFkZSBuYXQgKGVnIGFuZHJvaWQgcGhv bmVzIGV0Yykgd2hlcmUgdGhlIElQIG1heSByZXZlYWwgdGhlIGlkZW50aXR5IG9yIGxvY2F0aW9u IG9mIHRoZSB1c2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgY29uY2VybiB3aWxsIGJlIGluY3Jl YXNlZCBpbiB0aGUgY2FzZSBvZiBpcHY2IGRlcGxveW1lbnRzIChNTk9zKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gd2UgbmVlZCB0byBz cGVjaWZ5IGEgY29uZmlnIG9wdGlvbiBvbiB0aGUgYnJvd3NlciDigJhJ4oCZbSB1c2luZyBhIFZQ TiBkb27igJl0IGV4cG9zZSBteSBsb2NhbCBJUOKAmSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2Fpbiwgc29ycnkgaWYgSSBtaXNz ZWQgdGhpcyBiZWluZyBoYXNoZWQgdG8gZGVhdGggYWxyZWFkeS48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltHQVBFOl0gVGhl cmUgYXJlIGRpZmZlcmVudCDigJxjaGFsbGVuZ2Vz4oCdIGFzIEkgc2VlIGl0OyBhKSBvbmUgdG8g 4oCYaGlkZeKAmSB0aGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgaW52b2x2ZWQgd2ViIHNpdGVzIGFu ZCBwZWVycyBhbmQgYikgYW5vdGhlciBmcm9tIGEgd2ViDQogc2l0ZSBvd25lciBwZXJzcGVjdGl2 ZSwgaG93IHRvIHNhZmVndWFyZCB1c2VycyBwcml2YWN5IGFuZCBzZWN1cml0eS4g4oCYYeKAmSBo YXMgYmVlbiBkaXNjdXNzZWQgYW5kIHBhcnRseSBhZGRyZXNzZWQsIGUuZy4gJm5ic3A7aW4gWzFd IGFuZCBbMl0gLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZv ciDigJhi4oCZLCB3ZSBoYXZlIFdlYiBwbGF0Zm9ybSBtZWNoYW5pc21zIENTUCBbMyw0XSAoYW5k IENPUlMpIHRoYXQgdGhlIHdlYiBzaXRlIGFkbWluIGNhbiB1c2UgdG8gZ2V0IGhlbHAgZnJvbSB0 aGUgVUEgdG8gZG8gZGVmZW5zZS1pbi1kZXB0aC4gTm93LCBJIG1heQ0KIGhhdmUgbWlzc2VkIGl0 IGJ1dCBoYXMgdGhlcmUgYmVlbiBhbnkgaW4tZGVwdGggZGlzY3Vzc2lvbiBhYm91dCBDU1AgKGV4 aXN0aW5nIG9yIG5ldyBkaXJlY3RpdmVzIGZvciB0aGUgTy9BIHByb2NlZHVyZSwgZXRjLiBmb3Ig YXMgV2ViIHNpdGUgdXNpbmcgdGhlIFdlYlJUQyBBUEkgbm9yIGlzIHRoZXJlIGFueXRoaW5nIG1l bnRpb25lZCBpbiB0aGUgbGF0ZXN0IFczQyAmbmJzcDt3b3JraW5nIGRyYWZ0LiBQZXJoYXBzIEni gJl2ZSBtaXNzZWQgaXQtIHdoYXQNCiBpcyB0aGUgc3RhdHVzPyBQb3N0cG9uZWQgdG8gZnV0dXJl IHdvcms/PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R8O2cmFuPG86cD48 L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WzFdPC9zcGFuPjwvaT48L2I+DQo8Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkt YXJjaC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2Vi LXNlY3VyaXR5LWFyY2gvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlsyXTwvc3Bhbj48L2k+PC9iPg0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0wNCNzZWN0aW9uLTUuMyI+DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTA0I3Nl Y3Rpb24tNS4zPC9hPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bM10gQ1NQ IExldmVsIDEuMSwNCjxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSL0NTUC8iPmh0dHA6Ly93 d3cudzMub3JnL1RSL0NTUC88L2E+PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+WzRdQ1NQIExldmVsIDEuMiAoRHJhZnQpLCBodHRwOi8vd3d3LnczLm9yZy9UUi9D U1AyLzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRpbSBQYW50b24gLSBXZWIvVm9J UCBjb25zdWx0YW50IGFuZCBpbXBsZW1lbnRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cud2VzdGhhd2suY28udWsiPnd3dy53 ZXN0aGF3ay5jby51azwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_532A6DC6F9C115439C41705FF73D13871D1B5F96ESESSMB209erics_-- From nobody Tue Feb 3 06:03:56 2015 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 A77351A0382 for ; Tue, 3 Feb 2015 06:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ0fcUWiBn6E for ; Tue, 3 Feb 2015 06:03:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF321A0362 for ; Tue, 3 Feb 2015 06:03:51 -0800 (PST) Received: from netb ([82.113.106.93]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MaE4a-1Y3Baz0A8m-00Jojr; Tue, 03 Feb 2015 15:03:47 +0100 From: Bjoern Hoehrmann To: Tim Panton Date: Tue, 03 Feb 2015 15:03:43 +0100 Message-ID: <5gk1da11j4bvb89rq7u7bkv24d3jutvnoe@hive.bjoern.hoehrmann.de> References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> In-Reply-To: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ANEevUUB3PbBuHu7m8gJ7+8qzbrRaMCOfqvAs65u9xnAElouOSm S/XRZoIjfcp/R8GkPD4Um6BiTxfchVkOXN6HvHdVOWKlTzxOj6IFWwSdvJXjVKvStYwmoA9 ZVMDAM2+M2tHXI4opE1jkgMVF2CJZx7BeLAdsayROrS84DV6tYWFI/wri5qcQi68YdAiQpN dq61W+/kpsxc/WeSzXJcQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" , public-webrtc Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 14:03:55 -0000 * Tim Panton wrote: >I’ve been reading worried blogs that WEBRTC in browsers ‘leaks’ the local ‘real’ ip addresses to the javascript. >The principle worriers are VPN users e.g https://cryptostorm.org/viewtopic.php?f=50&t=2867&p=13096#p13096 >The concern is that this can be done without user notification (DataChannel request) and might be used to >identify or finger-print users. Clearly the most vulnerable are Tor users who are on a real routeable IP address >or directly on a carrier grade nat (eg android phones etc) where the IP may reveal the identity or location of the user. If this actually allows random web sites to know that I am using the addresses 192.168.12.96, 192.168.3.222, and 192.168.200.7 (Ethernet, Wifi, virtual machine) on this computer then that is pretty much like broadcasting a device GUID and should concern everybody. I note that some of the recent news coverage of this indicated that some major web sites and services already use this to identify and track users. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Tue Feb 3 07:29:10 2015 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 259471A0636 for ; Tue, 3 Feb 2015 07:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-bVixlP1PUP for ; Tue, 3 Feb 2015 07:29:07 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E111A036E for ; Tue, 3 Feb 2015 07:28:54 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-1b-54d0e93410b5 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 74.22.04231.439E0D45; Tue, 3 Feb 2015 16:28:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Tue, 3 Feb 2015 16:28:52 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Data Channel Closure: Is sctp-reset mandatory? Thread-Index: AdA/xe63wHjuzNMzQZG6G5y7dzah/Q== Date: Tue, 3 Feb 2015 15:28:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D68E833@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D68E833ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja7JywshBhdmmFqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIttH9gLOsUr9nz5wNTAuFiki5GTQ0LARKL3WA87hC0mceHe erYuRi4OIYEjjBJv2xawQDiLGCWe9ZwCcjg42AQsJLr/aYM0iAioS1x+eIEdJCwsYC7xbq8G iCkiYCPx9DcXRIWexN/Nn5hBbBYBFYn9X+Yxgdi8Ar4SqxadB7MZgdZ+P7UGzGYWEJe49WQ+ E8Q5AhJL9pxnhrBFJV4+/scKYStJrNh+iRGiPl9iw52pjBAzBSVOznzCMoFRaBaSUbOQlM1C UgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZs YgTGw8Etv3V3MK5+7XiIUYCDUYmHd4PlhRAh1sSy4srcQ4zSHCxK4rx2xodChATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTBOzK7zW9bUs003+ytzz99LHz+7qr+SshCI2J+i4DDn15M/haYP ORM+moScXeBW4mT6xPjiLWZ7Vo+wl8Y2AjVGd20zJwYs9JVQ2BX6fa/JEkmupVumTv5uO7FV 5Aq32PzU7y++fRUx+1IQd3Zr420LjUTZuVt+H5BfvK32DIdkuNisC6ervq5UYinOSDTUYi4q TgQAfz44vmgCAAA= Archived-At: Subject: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? 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 Feb 2015 15:29:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D68E833ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When I am about to close the data channel, if I also want to tear down the = SCTP-over-DTLS association, do I first need to send sctp-reset (in order to= close my data channel(s)), before sending SHUTDOWN? Or, can I simply send = SHUTDOWN? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D68E833ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When I am about to close the data channel, if I also= want to tear down the SCTP-over-DTLS association, do I first need to send = sctp-reset (in order to close my data channel(s)), before sending SHUTDOWN?= Or, can I simply send SHUTDOWN?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D68E833ESESSMB209erics_-- From nobody Tue Feb 3 08:42:14 2015 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 3514C1A1A3C for ; Tue, 3 Feb 2015 08:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1svqqNk2LD59 for ; Tue, 3 Feb 2015 08:42:04 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D0B421A1A4B for ; Tue, 3 Feb 2015 08:42:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CE3AD7C422A; Tue, 3 Feb 2015 17:42:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaTo4xiMSey0; Tue, 3 Feb 2015 17:42:02 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:681e:b696:225b:85f5]) by mork.alvestrand.no (Postfix) with ESMTPSA id E49687C4203; Tue, 3 Feb 2015 17:42:01 +0100 (CET) Message-ID: <54D0FA59.6060504@alvestrand.no> Date: Tue, 03 Feb 2015 17:42:01 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tim Panton new , =?UTF-8?B?R8O2cmFuIEVyaWtzc29uIEE=?= =?UTF-8?B?UA==?= References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> <532A6DC6F9C115439C41705FF73D13871D1B5F96@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" , public-webrtc Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 16:42:08 -0000 Some thoughts.... 1) Datachannel is a red herring. There are many ways to do a valid CreateOffer with m-lines, which is all that is required: - Datachannel - OfferToReceiveVideo / Audio - Generate a MediaStreamTrack from WebAudio and so on. 2) Speaking with my WebRTC hat on: IP addresses have to be surfaced at the API as long as the other side needs to try to send packets to these interfaces. We can't obfuscate them or encrypt them because they have to be communicated to the other party, through channels that aren't in the WebRTC spec. 3) Speaking with my (imaginary) implementors hat: One can imagine a (browser-wide) configuration setting for which addresses to allow access to, possibly with a whitelist of apps / pages / sites allowed more access than others. Normal people will never configure this (and if they tried, they would get it wrong), so the defaults need to be "safe enough for most", but sysadmins and the people with special reasons to care about security might. 4) Again wearing my WebRTC spec shepherding hat: It seems that the spec should make it clear: a) that IP addresses will be exposed (in SDP and in oncandidate callbacks) b) why IP addresses are being exposed but not really anything more than that. 5) Wearing my forum-shuffling hat, it seems that the "why" part belongs more in the IETF than in the WebRTC side of things - so I'd favour continuing this thread on rtcweb@ietf only.... Harald From nobody Tue Feb 3 09:15:59 2015 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 2C8A31A1E0B for ; Tue, 3 Feb 2015 09:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUzN4QnZCuHd for ; Tue, 3 Feb 2015 09:15:50 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213E81A1A16 for ; Tue, 3 Feb 2015 09:15:50 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so25791162igj.4 for ; Tue, 03 Feb 2015 09:15:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=l2TmhS+ymYlGg5ZyOwzlzylyGMQtXj2QAUmBj8kLHTA=; b=bzerqaSi4ATMQ4TJub6MaHCyku1rgTj3b+1GI2gFYOo46YGwRAzHrcHo9qqZ57Tl6M szcMGvZs7i62S0KaUNLjJFtu/QorKk8MzUjviO0arn/ekKdcFcqgGemYvwxe3LGrax8l u8OHmSF4p6sSbcMrUgwR2MXv0te1p+RXR/BN19jLVURBScFZ5KmILuVZjFH7mrp7OrtT Nw4yHQYMZqdSkwm/CgpOmU0+q7mV3E1JzBS1khHKjGf75wEkUtQom7mQqxQiBb2l7a3s 4sD4d5a5NHuXxAx+Knuve1UjRIfFXcpRW+j3KZTzbjab1zXzU3gY5N6/url211N+l2rS iW7w== X-Gm-Message-State: ALoCoQlRr37ZT/tvDP7uB+1cMF1b+dMGkpr/eAzEZIeUP5wlVZnt0Sc8AcfdN7yXyoCo9u4fIzEv X-Received: by 10.50.253.12 with SMTP id zw12mr18817694igc.24.1422983749481; Tue, 03 Feb 2015 09:15:49 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com. [209.85.223.181]) by mx.google.com with ESMTPSA id f3sm8103249iof.16.2015.02.03.09.15.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 09:15:48 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id rd18so17536671iec.12 for ; Tue, 03 Feb 2015 09:15:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.11.17 with SMTP id v17mr15065913ioi.18.1422983747008; Tue, 03 Feb 2015 09:15:47 -0800 (PST) Received: by 10.36.20.10 with HTTP; Tue, 3 Feb 2015 09:15:46 -0800 (PST) In-Reply-To: <54D0FA59.6060504@alvestrand.no> References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> <532A6DC6F9C115439C41705FF73D13871D1B5F96@ESESSMB209.ericsson.se> <54D0FA59.6060504@alvestrand.no> Date: Tue, 3 Feb 2015 12:15:46 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1147d2d0c302f5050e3238c8 Archived-At: Cc: public-webrtc , "rtcweb@ietf.org >> rtcweb@ietf.org" , Tim Panton new Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 17:15:56 -0000 --001a1147d2d0c302f5050e3238c8 Content-Type: text/plain; charset=UTF-8 The thing I was wondering about was, should there be a confirmation dialog when browser tries to setup any type of peer-to-peer connection? We get a confirmation dialog when microphone or camera access is requested. I think setting up a peer-to-peer connection is something that should be controlled by the user on the per web site basis in the similar manner. _____________ Roman Shpount On Tue, Feb 3, 2015 at 11:42 AM, Harald Alvestrand wrote: > Some thoughts.... > > 1) Datachannel is a red herring. There are many ways to do a valid > CreateOffer with m-lines, which is all that is required: > > - Datachannel > - OfferToReceiveVideo / Audio > - Generate a MediaStreamTrack from WebAudio > > and so on. > > 2) Speaking with my WebRTC hat on: IP addresses have to be surfaced at the > API as long as the other side needs to try to send packets to these > interfaces. We can't obfuscate them or encrypt them because they have to be > communicated to the other party, through channels that aren't in the WebRTC > spec. > > 3) Speaking with my (imaginary) implementors hat: One can imagine a > (browser-wide) configuration setting for which addresses to allow access > to, possibly with a whitelist of apps / pages / sites allowed more access > than others. Normal people will never configure this (and if they tried, > they would get it wrong), so the defaults need to be "safe enough for > most", but sysadmins and the people with special reasons to care about > security might. > > 4) Again wearing my WebRTC spec shepherding hat: It seems that the spec > should make it clear: > a) that IP addresses will be exposed (in SDP and in oncandidate callbacks) > b) why IP addresses are being exposed > but not really anything more than that. > > 5) Wearing my forum-shuffling hat, it seems that the "why" part belongs > more in the IETF than in the WebRTC side of things - so I'd favour > continuing this thread on rtcweb@ietf only.... > > Harald > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1147d2d0c302f5050e3238c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The thing I was wondering about was, should there be a con= firmation dialog when browser tries to setup any type of peer-to-peer conne= ction? We get a confirmation dialog when microphone or camera access is req= uested. I think setting up a peer-to-peer connection is something that shou= ld be controlled by the user on the per web site basis in the similar manne= r.

_____________
Roman Shpount

On Tue, Feb 3, 2015 at 11:42 AM, Harald Alve= strand <harald@alvestrand.no> wrote:
Some thoughts....

1) Datachannel is a red herring. There are many ways to do a valid CreateOf= fer with m-lines, which is all that is required:

- Datachannel
- OfferToReceiveVideo=C2=A0 / Audio
- Generate a MediaStreamTrack from WebAudio

and so on.

2) Speaking with my WebRTC hat on: IP addresses have to be surfaced at the = API as long as the other side needs to try to send packets to these interfa= ces. We can't obfuscate them or encrypt them because they have to be co= mmunicated to the other party, through channels that aren't in the WebR= TC spec.

3) Speaking with my (imaginary) implementors hat: One can imagine a (browse= r-wide) configuration setting for which addresses to allow access to, possi= bly with a whitelist of apps / pages / sites allowed more access than other= s. Normal people will never configure this (and if they tried, they would g= et it wrong), so the defaults need to be "safe enough for most", = but sysadmins and the people with special reasons to care about security mi= ght.

4) Again wearing my WebRTC spec shepherding hat: It seems that the spec sho= uld make it clear:
a) that IP addresses will be exposed (in SDP and in oncandidate callbacks)<= br> b) why IP addresses are being exposed
but not really anything more than that.

5) Wearing my forum-shuffling hat, it seems that the "why" part b= elongs more in the IETF than in the WebRTC side of things - so I'd favo= ur continuing this thread on rtcweb@ietf only....

Harald




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

--001a1147d2d0c302f5050e3238c8-- From nobody Tue Feb 3 09:28:55 2015 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 7A46C1A6EE1 for ; Tue, 3 Feb 2015 09:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlfeA-rl_7f5 for ; Tue, 3 Feb 2015 09:28:46 -0800 (PST) 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 D64121A1BFB for ; Tue, 3 Feb 2015 09:28:45 -0800 (PST) Received: from [192.168.1.200] (p508F1D62.dip0.t-ipconnect.de [80.143.29.98]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 022FD1C104351; Tue, 3 Feb 2015 18:28:43 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D68E833@ESESSMB209.ericsson.se> Date: Tue, 3 Feb 2015 18:28:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BEE43BE-9797-4178-9A72-9F031FB18A60@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D68E833@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? 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 Feb 2015 17:28:48 -0000 > On 03 Feb 2015, at 16:28, Christer Holmberg = wrote: >=20 > Hi, > =20 > When I am about to close the data channel, if I also want to tear down = the SCTP-over-DTLS association, do I first need to send sctp-reset (in = order to close my data channel(s)), before sending SHUTDOWN? Or, can I = simply send SHUTDOWN? You can simply shutdown. See the last paragraph in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2 Best regards Michael > =20 > Regards, > =20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Feb 3 09:35:13 2015 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 D47661A0378 for ; Tue, 3 Feb 2015 09:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5l41DiuELNP for ; Tue, 3 Feb 2015 09:35:06 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EA41A1AFB for ; Tue, 3 Feb 2015 09:35:05 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-3d-54d106c7f844 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.CC.04076.7C601D45; Tue, 3 Feb 2015 18:35:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Tue, 3 Feb 2015 18:35:03 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? Thread-Index: AdA/xe63wHjuzNMzQZG6G5y7dzah/QACIrmAAAJU37A= Date: Tue, 3 Feb 2015 17:35:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D68EE5B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D68E833@ESESSMB209.ericsson.se> <5BEE43BE-9797-4178-9A72-9F031FB18A60@lurchi.franken.de> In-Reply-To: <5BEE43BE-9797-4178-9A72-9F031FB18A60@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje5xtoshBhfWqVtcbFrCaLH2Xzu7 A5PHkiU/mTw2tOxgCmCK4rJJSc3JLEst0rdL4Mo4cPYDa8Ea9oq3H4QaGCexdTFyckgImEhc +TeHGcIWk7hwbz1YXEjgCKPE4WaxLkYuIHsRo8T5zttARRwcbAIWEt3/tEFqRARMJQ4un8cC YjMLqEvcWXyOHcQWFnCR2PXgIitEjavE3x1nmCBsK4nGLxPB4iwCKhKH36wH6+UV8JWYMvUm M8SuDkaJ6WufMoIkOIGal01dC3YcI9Bx30+tYYJYJi5x68l8JoijBSSW7DkP9YCoxMvH/1gh bCWJRbc/Q9XrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFaNo cWpxcW66kZFealFmcnFxfp5eXmrJJkZg9Bzc8ttqB+PB546HGAU4GJV4eDdYXggRYk0sK67M PcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjq/2OK9ezlsnvV5l9aon6 opStF289MbNeYn70TJfzrcc/o7jVmpVdeqZfjPafVfLelaf35sRYG5u/n79sOLvtUfZvvhWX PizXv/ZhmZnGh4zI5fpdD3VnsnSLGOu1lHYk+/ez539Z5Bf+bHeWsqLpnA+CgWzi8dfLrG5k CS9Y8Ss8LsmewaJXiaU4I9FQi7moOBEAyhVFEn8CAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? 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 Feb 2015 17:35:10 -0000 Thanks! -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Sent: 03 February 2015 19:29 To: Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? > On 03 Feb 2015, at 16:28, Christer Holmberg wrote: >=20 > Hi, > =20 > When I am about to close the data channel, if I also want to tear down th= e SCTP-over-DTLS association, do I first need to send sctp-reset (in order = to close my data channel(s)), before sending SHUTDOWN? Or, can I simply sen= d SHUTDOWN? You can simply shutdown. See the last paragraph in https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2 Best regards Michael > =20 > Regards, > =20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Feb 3 10:36:26 2015 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 34CB51A6FF0 for ; Tue, 3 Feb 2015 10:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk9njAvgUxg9 for ; Tue, 3 Feb 2015 10:36:22 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9CF1A1ADF for ; Tue, 3 Feb 2015 10:36:22 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 16552A14EA15B; Tue, 3 Feb 2015 18:36:15 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t13IaH23007360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 19:36:17 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 19:36:18 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Michael Tuexen Thread-Topic: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? Thread-Index: AdA/xe63wHjuzNMzQZG6G5y7dzah/QACIrmAAAJU37AAAfg9IA== Date: Tue, 3 Feb 2015 18:36:17 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC4B3860E4@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D68E833@ESESSMB209.ericsson.se> <5BEE43BE-9797-4178-9A72-9F031FB18A60@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D68EE5B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D68EE5B@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? 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 Feb 2015 18:36:24 -0000 Michael, thanks for answering the case of the termination of the SCTP association in= outgoing direction. What about the incoming direction? How should I react in case of an incoming SCTP RE-CONFIG chunk (with a SCTP= stream reset)? a) may I immediately send a SCTP SHUTDOWN chunk? or b) firstly replying the RE-CONFIG procedure and subsequently initiating the= SCTP association shutdwon with a SCTP SHUTDOWN chunk? The distinction between incoming and outgoing direction isn't made in https= ://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2 in my = understanding. Thanks, Albrecht -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Dienstag, 3. Februar 2015 18:35 To: Michael Tuexen Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? Thanks! -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Sent: 03 February 2015 19:29 To: Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? > On 03 Feb 2015, at 16:28, Christer Holmberg wrote: >=20 > Hi, > =20 > When I am about to close the data channel, if I also want to tear down th= e SCTP-over-DTLS association, do I first need to send sctp-reset (in order = to close my data channel(s)), before sending SHUTDOWN? Or, can I simply sen= d SHUTDOWN? You can simply shutdown. See the last paragraph in https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2 Best regards Michael > =20 > Regards, > =20 > 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 From nobody Tue Feb 3 12:15:32 2015 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 5143B1A88E4 for ; Tue, 3 Feb 2015 12:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk5IO4nmTaNR for ; Tue, 3 Feb 2015 12:15:28 -0800 (PST) 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 008971A1A72 for ; Tue, 3 Feb 2015 12:15:27 -0800 (PST) Received: from [192.168.1.200] (p508F1D62.dip0.t-ipconnect.de [80.143.29.98]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9BAA41C104351; Tue, 3 Feb 2015 21:15:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC4B3860E4@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Tue, 3 Feb 2015 21:15:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D68E833@ESESSMB209.ericsson.se> <5BEE43BE-9797-4178-9A72-9F031FB18A60@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D68EE5B@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B3860E4@FR711WXCHMBA03.zeu.alcatel-lucent.com> To: "Schwarz, Albrecht (Albrecht)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? 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 Feb 2015 20:15:29 -0000 > On 03 Feb 2015, at 19:36, Schwarz, Albrecht (Albrecht) = wrote: >=20 > Michael, >=20 > thanks for answering the case of the termination of the SCTP = association in outgoing direction. > What about the incoming direction? > How should I react in case of an incoming SCTP RE-CONFIG chunk (with a = SCTP stream reset)? > a) may I immediately send a SCTP SHUTDOWN chunk? > or > b) firstly replying the RE-CONFIG procedure and subsequently = initiating the SCTP association shutdwon with a SCTP SHUTDOWN chunk? >=20 > The distinction between incoming and outgoing direction isn't made in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2 = in my understanding. No it isn't. If you want to turn down the association, but can do that = at any time. This is at least my understanding when I put the text into the document. Best regards Michael >=20 > Thanks, > Albrecht >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer = Holmberg > Sent: Dienstag, 3. Februar 2015 18:35 > To: Michael Tuexen > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? >=20 > Thanks! >=20 > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Sent: 03 February 2015 19:29 > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Data Channel Closure: Is sctp-reset mandatory? >=20 >> On 03 Feb 2015, at 16:28, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> When I am about to close the data channel, if I also want to tear = down the SCTP-over-DTLS association, do I first need to send sctp-reset = (in order to close my data channel(s)), before sending SHUTDOWN? Or, can = I simply send SHUTDOWN? > You can simply shutdown. See the last paragraph in > = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2 > Best regards > Michael >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> 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 From nobody Tue Feb 3 12:41:22 2015 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 006D51A87C4 for ; Tue, 3 Feb 2015 12:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLCu3f7p-IxH for ; Tue, 3 Feb 2015 12:41:18 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCEF1A1B64 for ; Tue, 3 Feb 2015 12:41:17 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-ba-54d1326a4583 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.D1.24955.A6231D45; Tue, 3 Feb 2015 21:41:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Tue, 3 Feb 2015 21:41:14 +0100 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Harald Alvestrand , Tim Panton new Thread-Topic: ICE exposes 'real' local IP to javascript Thread-Index: AQHQPvMv+BxouWAcQ0+2Cl6Uwu5GKJzdnZZAgAGFMmCAADnNEA== Date: Tue, 3 Feb 2015 20:41:14 +0000 Message-ID: <532A6DC6F9C115439C41705FF73D13871D1B65C6@ESESSMB209.ericsson.se> References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> <532A6DC6F9C115439C41705FF73D13871D1B5F96@ESESSMB209.ericsson.se> <54D0FA59.6060504@alvestrand.no> In-Reply-To: <54D0FA59.6060504@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rjfb6GKIwcovPBbH+rrYLHo/LmG0 WPuvnd1i3ftjLA4sHlcmXGH1WLLkJ5PH0Xn7WT0uTtvPFMASxWWTkpqTWZZapG+XwJVxuHsL c8EM5Yr733tZGhiXKHUxcnJICJhI/Pq0kgnCFpO4cG89WxcjF4eQwBFGiWlvl7FDOIsYJRbO 3skCUsUm4C3R1nIYzBYRCJb4sPoKK4jNLJAkcXzmWbC4sICZxK/D/UBTOYBqzCU+LZGHKHeS +HP2KxuIzSKgInHpfAPYYl4BX4kfPxuhFj9glLh56RXYHE4BXYmLT/rB5jMKyErc/36PBWKX uMStJ/OhrhaQWLLnPDOELSrx8vE/VghbSWLt4e0sIDcwC2hKrN+lD9GqKDGl+yE7xF5BiZMz n7BMYBSbhWTqLISOWUg6ZiHpWMDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMMoObvmt uoPx8hvHQ4wCHIxKPLwbLC+ECLEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBMf5WTMqcBeIWR163u/+beG+x1mb5X+x5hxgOs7pb3js/7UdPhkSk6Oz381rW W/XO39D32P924SNWOaGPHM8m3ChzY2I//XDSjH23S2Inat0Pztz4/cK0hbcX1pxeHGbxIslm 5QPR/et48gQfv8hRYAjIUp98g9kn+fli4QllOz30zERvbYzeEaTEUpyRaKjFXFScCABb4bhv kwIAAA== Archived-At: Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" , public-webrtc Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 20:41:20 -0000 SW5saW5lDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGFyYWxkIEFs dmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ub10NCj4gU2VudDogZGVuIDMgZmVi cnVhcmkgMjAxNSAxNzo0Mg0KPiBUbzogVGltIFBhbnRvbiBuZXc7IEfDtnJhbiBFcmlrc3NvbiBB UA0KPiBDYzogcHVibGljLXdlYnJ0YzsgcnRjd2ViQGlldGYub3JnID4+IHJ0Y3dlYkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogSUNFIGV4cG9zZXMgJ3JlYWwnIGxvY2FsIElQIHRvIGphdmFzY3Jp cHQNCj4gDQo+IFNvbWUgdGhvdWdodHMuLi4uDQo+IA0KPiAxKSBEYXRhY2hhbm5lbCBpcyBhIHJl ZCBoZXJyaW5nLiBUaGVyZSBhcmUgbWFueSB3YXlzIHRvIGRvIGEgdmFsaWQNCj4gQ3JlYXRlT2Zm ZXIgd2l0aCBtLWxpbmVzLCB3aGljaCBpcyBhbGwgdGhhdCBpcyByZXF1aXJlZDoNCj4gDQo+IC0g RGF0YWNoYW5uZWwNCj4gLSBPZmZlclRvUmVjZWl2ZVZpZGVvICAvIEF1ZGlvDQo+IC0gR2VuZXJh dGUgYSBNZWRpYVN0cmVhbVRyYWNrIGZyb20gV2ViQXVkaW8NCj4gDQo+IGFuZCBzbyBvbi4NCj4g DQo+IDIpIFNwZWFraW5nIHdpdGggbXkgV2ViUlRDIGhhdCBvbjogSVAgYWRkcmVzc2VzIGhhdmUg dG8gYmUgc3VyZmFjZWQgYXQgdGhlDQo+IEFQSSBhcyBsb25nIGFzIHRoZSBvdGhlciBzaWRlIG5l ZWRzIHRvIHRyeSB0byBzZW5kIHBhY2tldHMgdG8gdGhlc2UgaW50ZXJmYWNlcy4NCj4gV2UgY2Fu J3Qgb2JmdXNjYXRlIHRoZW0gb3IgZW5jcnlwdCB0aGVtIGJlY2F1c2UgdGhleSBoYXZlIHRvIGJl DQo+IGNvbW11bmljYXRlZCB0byB0aGUgb3RoZXIgcGFydHksIHRocm91Z2ggY2hhbm5lbHMgdGhh dCBhcmVuJ3QgaW4gdGhlDQo+IFdlYlJUQyBzcGVjLg0KW0dBUEU6XSBPSywgc3VyZSwgdGhhdCB3 b3VsZCBmaXQgaW4gSUVURi4gQnV0IENTUC9DT1JTIGFyZSB3aXRoaW4gdGhlIFczQyBzY29wZSwg cmlnaHQ/IEZvciBpbnN0YW5jZSwgY29uc2lkZXIgdXNpbmcgV2ViIHBsYXRmb3JtIG1lY2hhbmlz bXMgc3VjaCBhcyBDU1A7IHRoYXQgc2hvdWxkIGJlIGluIHRoZSBzY29wZSBvZiB0aGUgVzNDIGRy YWZ0LCByaWdodD8gU29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBXZWIgc2l0ZSBhZG1pbiB1c2lu ZyBDU1AvQ09SUyB0byBoYXZlIHRoZSBVQSAnY2hlY2snIHRoZSAnZmluZCZjb25uZWN0JyBwcm94 eSBvcmlnaW4gKGVzcGVjaWFsbHkgd2hlbiBpdCBpcyBub3QgaW4gdGhlIHNhbWUgJ29yaWdpbicg YXMgdGhhdCBvZiB0aGUgcGFyZW50IGRvY3VtZW50KT8gDQogICAgDQo+IA0KPiAzKSBTcGVha2lu ZyB3aXRoIG15IChpbWFnaW5hcnkpIGltcGxlbWVudG9ycyBoYXQ6IE9uZSBjYW4gaW1hZ2luZSBh DQo+IChicm93c2VyLXdpZGUpIGNvbmZpZ3VyYXRpb24gc2V0dGluZyBmb3Igd2hpY2ggYWRkcmVz c2VzIHRvIGFsbG93IGFjY2VzcyB0bywNCj4gcG9zc2libHkgd2l0aCBhIHdoaXRlbGlzdCBvZiBh cHBzIC8gcGFnZXMgLyBzaXRlcyBhbGxvd2VkIG1vcmUgYWNjZXNzIHRoYW4NCj4gb3RoZXJzLiBO b3JtYWwgcGVvcGxlIHdpbGwgbmV2ZXIgY29uZmlndXJlIHRoaXMgKGFuZCBpZiB0aGV5IHRyaWVk LCB0aGV5IHdvdWxkDQo+IGdldCBpdCB3cm9uZyksIHNvIHRoZSBkZWZhdWx0cyBuZWVkIHRvIGJl ICJzYWZlIGVub3VnaCBmb3IgbW9zdCIsIGJ1dA0KPiBzeXNhZG1pbnMgYW5kIHRoZSBwZW9wbGUg d2l0aCBzcGVjaWFsIHJlYXNvbnMgdG8gY2FyZSBhYm91dCBzZWN1cml0eSBtaWdodC4NCltHQVBF Ol0gSG1tLCB0aGVyZSBhcmUgc3VjaCBsaXN0cyBhcm91bmQgSSBpbWFnaW5lLCA6LSkuIEJ1dCBJ IHdvdWxkIHByZWZlciBsZXZlcmFnaW5nIFczQyBtZWNoYW5pc21zIGZvciBtYW55IHJlYXNvbnMt IHRoZXNlIHRoaW5ncyBhcmUgc3ViamVjdCB0byByZWd1bGF0aW9uIGluIHNvbWUgcGFydHMgb2Yg dGhlIHdvcmxkIGFuZCBpdCBvZnRlbiBhICsgdG8gYmUgYWJsZSB0byBwb2ludCB0byBhbiAib3Bl biBzdGFuZGFyZCIgbm90IHRvIG1lbnRpb24gdGhlIGZyYWdtZW50YXRpb24gY2hhbGxlbmdlcy4g QnV0IHllcywgaXQgaXMgZXNwZWNpYWxseSB0aGUgJ3N5cyBhZG1pbnMnICBvZiB0aGUgV2ViIHNp dGUgb3duZXJzIEkgYW0gdGhpbmtpbmcgYWJvdXQgbm93Lg0KPiANCj4gNCkgQWdhaW4gd2Vhcmlu ZyBteSBXZWJSVEMgc3BlYyBzaGVwaGVyZGluZyBoYXQ6IEl0IHNlZW1zIHRoYXQgdGhlIHNwZWMN Cj4gc2hvdWxkIG1ha2UgaXQgY2xlYXI6DQo+IGEpIHRoYXQgSVAgYWRkcmVzc2VzIHdpbGwgYmUg ZXhwb3NlZCAoaW4gU0RQIGFuZCBpbiBvbmNhbmRpZGF0ZSBjYWxsYmFja3MpDQo+IGIpIHdoeSBJ UCBhZGRyZXNzZXMgYXJlIGJlaW5nIGV4cG9zZWQNCj4gYnV0IG5vdCByZWFsbHkgYW55dGhpbmcg bW9yZSB0aGFuIHRoYXQuDQpbR0FQRTpdICsxDQo+IA0KPiA1KSBXZWFyaW5nIG15IGZvcnVtLXNo dWZmbGluZyBoYXQsIGl0IHNlZW1zIHRoYXQgdGhlICJ3aHkiIHBhcnQgYmVsb25ncw0KPiBtb3Jl IGluIHRoZSBJRVRGIHRoYW4gaW4gdGhlIFdlYlJUQyBzaWRlIG9mIHRoaW5ncyAtIHNvIEknZCBm YXZvdXIgY29udGludWluZw0KPiB0aGlzIHRocmVhZCBvbiBydGN3ZWJAaWV0ZiBvbmx5Li4uLg0K W0dBUEU6XSBJdCBpcyBub3Qgb25lIG9yIHRoZSBvdGhlciBJIHdvdWxkIHNheS0gdGhpcyBjb25j ZXJucyB0aGUgV2ViIHBsYXRmb3JtIHVzZXJzIHNlY3VyaXR5IGFuZCBwcml2YWN5LCBoYXJkbHkg YSBtYXR0ZXIgb25seSBvZiBJRVRGIGNvbmNlcm4sIDotLCBhbmQgYWdhaW4sIHdlIHNob3VsZCBo YXZlIGEgc2Vjb25kIGxvb2sgYXQgV2ViIHBsYXRmb3JtIHNlY3VyaXR5IG1lY2hhbmlzbXMgKHN1 Y2ggYXMgQ1NQKS4gQnV0IGFwYXJ0IGZyb20gdGhhdCwgd2Ugc2hvdWxkIGRpc2N1c3MgYW5kIHBv c3NpYmxlIHVwZGF0ZSByZWxldmFudCBJRVRGIGRyYWZ0cyB3aXRoIGF0IGxlYXN0IHRoYXQgaW5m byBpbiBZb3VyICc0Jy4gDQoNCkkgYW0gbm90IGNlcnRhaW4gdGhhdCBzdWNoIGEgZGlzY3Vzc2lv biB3aWxsIHJlc3VsdCBpbiBhbnkgW3NpZ25pZmljYW50XSBpbXBhY3Qgb24gdGhlIFVBLCBwZXJo YXBzIG1vcmUgIkJDUCdpc2giIGluZm9ybWF0aW9uLCBidXQgZ2l2ZW4gdGhlIGltcG9ydGFuY2Ug b2YgY29uc2lkZXJpbmcgdXNlciBwcml2YWN5IGFuZCBzZWN1cml0eSwgSSBiZWxpZXZlIGl0IGlz IHdvcnRod2hpbGUgZG9pbmctIGF0IHRoZSB2ZXJ5IGxlYXN0IHNwZW5kIHNvbWUgdGltZSBvbiBp dCBoZXJlLCA6LSkuDQoNCj4gDQo+IEhhcmFsZA0KPiANCj4gDQoNCg== From nobody Tue Feb 3 13:03:25 2015 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 B207E1A8974 for ; Tue, 3 Feb 2015 13:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkAX-GX72L53 for ; Tue, 3 Feb 2015 13:03:22 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1476B1A8725 for ; Tue, 3 Feb 2015 13:03:22 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id g201so51171010oib.4 for ; Tue, 03 Feb 2015 13:03:21 -0800 (PST) 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=7qWYXJZq/3c4GzhZkEfukCZov/YdRRea9Vk3fsY9sP0=; b=r1uA5HJsCMls8qAnNoIPCyapcrrxrsE5Slra6M2JkJx5W83gJ9ZQbMuzbR73Fu3n9n aucE4Rw/eYopLmGaYr08wnKpM/eMNzaguHhK85BuYHieXH+UEuN7n+/gLTtFqElXBepC XS3Ew2jHr5i/Pdr3duc2gB9M1KXuzY4uGUdGAZRzYTh/ijRUZWcsQvc7nHdSwclcNbP8 t0f4yJVGK/Fi5GT+j0eFFlvzN5V+G5FdbzjLx4+tLIztg1/5P2XXZ6lOfN5OJQDY4SF7 B7704DWJxeux1iwr92K5kfsXrfNnwZzB1KC6BGvNBtmnvMVGmr+V5pHFgu9tbZ8k44UK APCQ== MIME-Version: 1.0 X-Received: by 10.202.94.197 with SMTP id s188mr15977765oib.94.1422997401368; Tue, 03 Feb 2015 13:03:21 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 3 Feb 2015 13:03:21 -0800 (PST) Date: Tue, 3 Feb 2015 13:03:21 -0800 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] DTLS requirements 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 Feb 2015 21:03:23 -0000 The current security architecture mandates *both* DTLS 1.0 and 1.2. At the last meeting we agreed MUST 1.0, SHOULD 1.2 [1]. Also, I think that the only elliptic curve feature that is risky is ECDSA, not ECDHE. I'm going to propose that we move to ECDHE. https://github.com/rtcweb-wg/security-arch/pull/19 In addition to that change, I would also like to propose that we *require* a forward-secrecy-capable cipher suite. https://github.com/rtcweb-wg/security-arch/pull/20 [1] https://tools.ietf.org/wg/rtcweb/minutes?item=minutes-91-rtcweb.html From nobody Wed Feb 4 02:40:39 2015 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 BFC4B1A8740 for ; Wed, 4 Feb 2015 02:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuOJ81qT6_uM for ; Wed, 4 Feb 2015 02:40:24 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3D41A872C for ; Wed, 4 Feb 2015 02:40:24 -0800 (PST) Received: from ppp118-209-101-219.lns20.mel4.internode.on.net ([118.209.101.219]:52863 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YIxM3-0006MN-Jq for rtcweb@ietf.org; Wed, 04 Feb 2015 21:38:43 +1100 Message-ID: <54D1F710.4090504@nteczone.com> Date: Wed, 04 Feb 2015 21:40:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? 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 Feb 2015 10:40:31 -0000 Is it too late to add some explicit text indicating TCP rather than having to reply on another draft? It's easily missed by people reading the draft and given the real estate given in the data channel draft its possible to come to another conclusion. Christian On 28/01/2015 5:15 AM, Michael Tuexen wrote: >> On 27 Jan 2015, at 18:44, Christer Holmberg wrote: >> >> Hi, >> >>> Well, if you are doing ICE-TCP, I would expect you to run >DataChannels over that. ISTM that that suggests that the marker >should be TCP/DTLS/SCTP. >> >> I am not arguing against that. I just wonder why the data channel draft doesn’t say anything about TCP, while explicitly talking about UDP. > That is correct. However, > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09 > says in the Abstract: > Using the > encapsulation method described in this document, SCTP is unaware of > the protocols being used below DTLS; > So it is clear that you can use other protocols like ICE/TCP. However, this > is not explicitly discussed and using TCP has the known drawback of running > a CC (in SCTP) over a CC (in TCP). > > I guess the reason why TCP is not mentioned explicitly is that noone brought > the issue up. It was always meant that you run over ICE no matter what ICE is running over... > > Best regards > Michael >> >> Regards, >> >> Christer >> >> >> >> On Tue, Jan 27, 2015 at 4:18 AM, Christer Holmberg wrote: >> Hi, >> >> Related to this, when I read the data channel draft, it explicitly talks about UDP. TCP is not even mentioned. >> >> So, does that mean that TCP/DTLS/SCTP is not “officially” a part of the data channel spec? >> >> Regards, >> >> Christer >> >> From: Makaraju, Maridi Raju (Raju) [mailto:Raju.Makaraju@alcatel-lucent.com] >> Sent: 24. tammikuuta 2015 15:35 >> To: Christer Holmberg; Justin Uberti >> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >> >> I am ok to use UDP/DTLS/SCTP and TCP/DTLS/SCTP. >> I agree that use of RFC #s is not the best option. >> However, I find some unease in the discussions about “TCP/DTLS” part, which seems to suggest why not use “TCP/TLS”? We understand that it can’t be called that way because of the RFC 4571 “shim layer” in between DTLS and TCP layers. Unfortunately, unlike TPKT, RFC 4571 did not give a name to the protocol, which would have been easy to use than the RFC directly. >> >> BR >> Raju >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Friday, January 23, 2015 1:22 AM >> To: Justin Uberti; Makaraju, Maridi Raju (Raju) >> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >> >> Hi, >> >> I agree that we should not use RFC numbers in proto values. >> >> Also keep in mind that UDP/DTLS/SCTP does not mean “ICE based”. ICE is optional for UDP/DTLS/SCTP (that fact that we mandate ICE for RTCWEB is a separate issue). >> >> Regards, >> >> Christer >> >> From: Justin Uberti [mailto:juberti@google.com] >> Sent: 23. tammikuuta 2015 5:57 >> To: Makaraju, Maridi Raju (Raju) >> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >> >> No, I don't think including RFC4571 is reasonable. That ship has already sailed. >> >> On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) wrote: >> I was also suggesting the following identifying string to make it unambiguous up to L4 protocol. >> I don’t hear any objections to it explicitly. Or did I misinterpret the response? >> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >> For UDP ICE based data channel transport: UDP/DTLS/SCTP >> >> BR >> Raju >> >> From: Justin Uberti [mailto:juberti@google.com] >> Sent: Thursday, January 22, 2015 4:45 PM >> To: Makaraju, Maridi Raju (Raju) >> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >> >> The protocol is the same. We are just deciding what the identifying string should be. >> >> Given the amount of confusion in this space, I think it makes sense to be as explicit as possible, and use DTLS instead of TLS for the name. >> >> On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) wrote: >> From protocol stacks layering point of view, isn’t the following more accurately represent them? >> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >> For UDP ICE based data channel transport: UDP/DTLS/SCTP >> >> Per my understanding, independent of underlying transport (UDP; or “TCP over RFC4471” framing mimicking datagram transport) the DTLS protocol is same. >> >> 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 From nobody Wed Feb 4 03:07:34 2015 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 0E5C11A8722 for ; Wed, 4 Feb 2015 03:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po_kn8jIavxl for ; Wed, 4 Feb 2015 03:07:28 -0800 (PST) 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 CBB091A1A92 for ; Wed, 4 Feb 2015 03:07:27 -0800 (PST) Received: from [192.168.1.200] (p508F0233.dip0.t-ipconnect.de [80.143.2.51]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4155E1C104E9E; Wed, 4 Feb 2015 12:07:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <54D1F710.4090504@nteczone.com> Date: Wed, 4 Feb 2015 12:07:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> References: <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> <54D1F710.4090504@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? 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 Feb 2015 11:07:31 -0000 > On 04 Feb 2015, at 11:40, Christian Groves = wrote: >=20 > Is it too late to add some explicit text indicating TCP rather than = having to reply on another draft? It's easily missed by people reading = the draft and given the real estate given in the data channel draft its = possible to come to another conclusion. The document is in the RFC Editor queue... I would think that it is = clear that ICE can run over several protocols, not only UDP. So it might have been better not show nothing = below ICE. But it think ICE/UDP will be the stack used in a lot of cases. We could still try to make sure the stack is clear in https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07 That has the advantage that it also deals with the media channels. Best regards Michael >=20 > Christian >=20 > On 28/01/2015 5:15 AM, Michael Tuexen wrote: >>> On 27 Jan 2015, at 18:44, Christer Holmberg = wrote: >>>=20 >>> Hi, >>> =20 >>>> Well, if you are doing ICE-TCP, I would expect you to run = >DataChannels over that. ISTM that that suggests that the marker >should = be TCP/DTLS/SCTP. >>> I am not arguing against that. I just wonder why the data channel = draft doesn=E2=80=99t say anything about TCP, while explicitly talking = about UDP. >> That is correct. However, >> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09 >> says in the Abstract: >> Using the >> encapsulation method described in this document, SCTP is unaware = of >> the protocols being used below DTLS; >> So it is clear that you can use other protocols like ICE/TCP. = However, this >> is not explicitly discussed and using TCP has the known drawback of = running >> a CC (in SCTP) over a CC (in TCP). >>=20 >> I guess the reason why TCP is not mentioned explicitly is that noone = brought >> the issue up. It was always meant that you run over ICE no matter = what ICE is running over... >>=20 >> Best regards >> Michael >>> Regards, >>> Christer >>> On Tue, Jan 27, 2015 at 4:18 AM, Christer Holmberg = wrote: >>> Hi, >>> Related to this, when I read the data channel draft, it explicitly = talks about UDP. TCP is not even mentioned. >>> So, does that mean that TCP/DTLS/SCTP is not =E2=80=9Cofficially=E2=80= =9D a part of the data channel spec? >>> Regards, >>> Christer >>> From: Makaraju, Maridi Raju (Raju) = [mailto:Raju.Makaraju@alcatel-lucent.com] >>> Sent: 24. tammikuuta 2015 15:35 >>> To: Christer Holmberg; Justin Uberti >>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = >>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>> I am ok to use UDP/DTLS/SCTP and TCP/DTLS/SCTP. >>> I agree that use of RFC #s is not the best option. >>> However, I find some unease in the discussions about =E2=80=9CTCP/DTLS= =E2=80=9D part, which seems to suggest why not use =E2=80=9CTCP/TLS=E2=80=9D= ? We understand that it can=E2=80=99t be called that way because of the = RFC 4571 =E2=80=9Cshim layer=E2=80=9D in between DTLS and TCP layers. = Unfortunately, unlike TPKT, RFC 4571 did not give a name to the = protocol, which would have been easy to use than the RFC directly. >>> BR >>> Raju >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Friday, January 23, 2015 1:22 AM >>> To: Justin Uberti; Makaraju, Maridi Raju (Raju) >>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = >>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>> Hi, >>> I agree that we should not use RFC numbers in proto values. >>> Also keep in mind that UDP/DTLS/SCTP does not mean =E2=80=9CICE = based=E2=80=9D. ICE is optional for UDP/DTLS/SCTP (that fact that we = mandate ICE for RTCWEB is a separate issue). >>> Regards, >>> Christer >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: 23. tammikuuta 2015 5:57 >>> To: Makaraju, Maridi Raju (Raju) >>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas = Nandakumar; >>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>> No, I don't think including RFC4571 is reasonable. That ship has = already sailed. >>> On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) = wrote: >>> I was also suggesting the following identifying string to make it = unambiguous up to L4 protocol. >>> I don=E2=80=99t hear any objections to it explicitly. Or did I = misinterpret the response? >>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>> BR >>> Raju >>> From: Justin Uberti [mailto:juberti@google.com] >>> Sent: Thursday, January 22, 2015 4:45 PM >>> To: Makaraju, Maridi Raju (Raju) >>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas = Nandakumar; >>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>> The protocol is the same. We are just deciding what the identifying = string should be. >>> Given the amount of confusion in this space, I think it makes sense = to be as explicit as possible, and use DTLS instead of TLS for the name. >>> On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) = wrote: >>> =46rom protocol stacks layering point of view, isn=E2=80=99t the = following more accurately represent them? >>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>> Per my understanding, independent of underlying transport (UDP; or = =E2=80=9CTCP over RFC4471=E2=80=9D framing mimicking datagram transport) = the DTLS protocol is same. >>> BR >>> Raju >>> =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 >> _______________________________________________ >> 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 Wed Feb 4 11:12:26 2015 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 CCFC81A038D for ; Mon, 2 Feb 2015 14:16:35 -0800 (PST) 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, 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 ic2AT42YH-7D for ; Mon, 2 Feb 2015 14:16:32 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EACB1A0252 for ; Mon, 2 Feb 2015 14:16:31 -0800 (PST) Received: (qmail 458 invoked from network); 2 Feb 2015 22:16:29 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13856 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 2 Feb 2015 22:16:29 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CAA8B18A0589; Mon, 2 Feb 2015 22:16:23 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id ADDA218A02EF; Mon, 2 Feb 2015 22:16:23 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8969E797-619E-4729-8F93-D11D24A598F5" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton new In-Reply-To: <532A6DC6F9C115439C41705FF73D13871D1B5F96@ESESSMB209.ericsson.se> Date: Mon, 2 Feb 2015 22:16:22 +0000 Message-Id: References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> <532A6DC6F9C115439C41705FF73D13871D1B5F96@ESESSMB209.ericsson.se> To: =?utf-8?Q?G=C3=B6ran_Eriksson_AP?= X-Mailer: Apple Mail (2.1993) Archived-At: X-Mailman-Approved-At: Wed, 04 Feb 2015 11:12:21 -0800 Cc: "rtcweb@ietf.org >> rtcweb@ietf.org" , public-webrtc Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 22:16:36 -0000 --Apple-Mail=_8969E797-619E-4729-8F93-D11D24A598F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Feb 2015, at 21:13, G=C3=B6ran Eriksson AP = wrote: >=20 > =20 > =20 > From: Tim Panton [mailto:thp@westhawk.co.uk = ]=20 > Sent: den 2 februari 2015 15:17 > To: public-webrtc > Cc: rtcweb@ietf.org >> rtcweb@ietf.org = > Subject: ICE exposes 'real' local IP to javascript > =20 > Firstly- sorry for cross posting - I=E2=80=99m not sure which side of = the line this falls. > Secondly - if this is covered, please let me know, I don=E2=80=99t = recall it cropping up... > =20 > I=E2=80=99ve been reading worried blogs that WEBRTC in browsers = =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2=80=99 ip addresses to = the javascript. > The principle worriers are VPN users e.g = https://cryptostorm.org/viewtopic.php?f=3D50&t=3D2867&p=3D13096#p13096 = > The concern is that this can be done without user notification = (DataChannel request) and might be used to=20 > identify or finger-print users. Clearly the most vulnerable are Tor = users who are on a real routeable IP address > or directly on a carrier grade nat (eg android phones etc) where the = IP may reveal the identity or location of the user. > =20 > It seems to me that this concern will be increased in the case of ipv6 = deployments (MNOs). > =20 > Do we need to specify a config option on the browser =E2=80=98I=E2=80=99= m using a VPN don=E2=80=99t expose my local IP=E2=80=99=20 > =20 > Again, sorry if I missed this being hashed to death already. > [GAPE:] There are different =E2=80=9Cchallenges=E2=80=9D as I see it; = a) one to =E2=80=98hide=E2=80=99 the information from the involved web = sites and peers and b) another from a web site owner perspective, how to = safeguard users privacy and security. =E2=80=98a=E2=80=99 has been = discussed and partly addressed, e.g. in [1] and [2] . I think these VPN users have hit the =E2=80=98partly=E2=80=99 aspect. = 5.4 in [1] says:=20 "Note that these requirements are NOT intended to protect the user=E2=80=99= s IP address from a malicious site. In general, the site will learn at least a user's server reflexive address from any HTTP transaction.=E2=80=9D= =20 The VPN folks are worried that their privacy may be compromised by = webRTC exposing their local IP without their permission. An advert might call a dataChannel createOffer() for the purposes of = gaining the local IPV6 address and using it to fingerprint the user in ways that the reflexive address couldn=E2=80=99t. - So they don=E2=80=99t = want to trust =E2=80=98evil_banners.com=E2=80=99 with their local = addresses and before webRTC they didn=E2=80=99t have to. I=E2=80=99m not clear that this is a big enough = issue to warrant a spec change, but it is an issue they seem to care = about. T. --Apple-Mail=_8969E797-619E-4729-8F93-D11D24A598F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 2 Feb 2015, at 21:13, G=C3=B6ran Eriksson AP <goran.ap.eriksson@ericsson.com> wrote:

 
 
From: Tim Panton [mailto:thp@westhawk.co.uk] 
Sent: den= 2 februari 2015 15:17
To: public-webrtc
Cc: rtcweb@ietf.org >> rtcweb@ietf.org
Subject: ICE exposes 'real' local IP = to javascript
 
Firstly- sorry for = cross posting - I=E2=80=99m not sure which side of the line this = falls.
Secondly - if this is covered, please let = me know, I don=E2=80=99t recall it cropping up...
 
I=E2=80=99ve been reading worried blogs = that WEBRTC in browsers =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2= =80=99 ip addresses to the javascript.
The concern is that this can be done = without user notification (DataChannel request) and might be used = to 
identify or finger-print users. Clearly = the most vulnerable are Tor users who are on a real routeable IP = address
or directly on a carrier grade nat (eg = android phones etc) where the IP may reveal the identity or location of = the user.
 
It seems to me that this concern will be increased in = the case of ipv6 deployments (MNOs).
 
Do we need to specify a config option on the browser = =E2=80=98I=E2=80=99m using a VPN don=E2=80=99t expose my local = IP=E2=80=99 
 
Again, sorry if I missed this being hashed to death = already.
[GAPE:] There = are different =E2=80=9Cchallenges=E2=80=9D as I see it; a) one to = =E2=80=98hide=E2=80=99 the information from the involved web sites and = peers and b) another from a web site owner perspective, how to safeguard = users privacy and security. =E2=80=98a=E2=80=99 has been discussed and = partly addressed, e.g.  in [1] and [2] = .

I think these VPN users have hit the =E2=80=98partly= =E2=80=99 aspect. 5.4 in [1] says: 
"Note that these requirements = are NOT intended to protect the user=E2=80=99s
IP address from a malicious = site. In = general, the site will learn at
least a user's server = reflexive address from any HTTP transaction.=E2=80=9D =
The = VPN folks are worried that their privacy may be compromised by webRTC = exposing their local IP without their permission.
An advert might call a = dataChannel createOffer() for the purposes of gaining the local IPV6 = address and using it to fingerprint the user in
ways that the reflexive = address couldn=E2=80=99t. - So they don=E2=80=99t want to trust = =E2=80=98evil_banners.com=E2=80=99 with their local addresses and before = webRTC they
didn=E2=80=99t have to. I=E2=80=99m not clear that this is a = big enough issue to warrant a spec change, but it is an issue they seem = to care about.

T.
<= br class=3D"">= --Apple-Mail=_8969E797-619E-4729-8F93-D11D24A598F5-- From nobody Wed Feb 4 11:46:09 2015 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 8132B1A1A8D for ; Wed, 4 Feb 2015 11:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.61 X-Spam-Level: X-Spam-Status: No, score=-13.61 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, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9tXR0GFVJrv for ; Wed, 4 Feb 2015 11:45:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44C01A0155 for ; Wed, 4 Feb 2015 11:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15250; q=dns/txt; s=iport; t=1423079149; x=1424288749; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=41uBRDjBD8ckjsKUALZBDdn9uBEYXDgVkqVcRBXxdHE=; b=D78MPlXD0gGRKu5734WlRsvhvq7pKYlkglBaStenKNP3AEpid+a6iDV0 WIY8gqvWABOcAlxMOa7o4al2gboQci3ZJmz8Es5D5bIsUJPe9F3lw4W41 U7MH64pD521S5ysrQUE2Q8Tc4xQKkxN+uBPpqH/IBLhfexs4W0QqenHlZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUJALV10lStJA2D/2dsb2JhbABAEAEJgkNDUlmCOke/QYVxAoEhQwEBAQEBfYQMAQEBBAwXRAUNEAkCEQQBAQEnAwICRgkIBhECiC0NN6MLnGyWPQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjxwBVwQGAYJoLoETBYoeiEKFWYEXgwOCJYwkIoIHF4FxHQQtAYJBAQEB X-IronPort-AV: E=Sophos;i="5.09,519,1418083200"; d="scan'208,217";a="390351391" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 04 Feb 2015 19:45:48 +0000 Received: from [10.24.57.108] ([10.24.57.108]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t14Jjj04020833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2015 19:45:47 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_23BE5529-278A-4809-999E-EEDE50E0BD44" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Wed, 4 Feb 2015 11:45:44 -0800 Message-Id: References: <5B986D58-AB56-4976-8F61-4E80110916A2@westhawk.co.uk> <532A6DC6F9C115439C41705FF73D13871D1B5F96@ESESSMB209.ericsson.se> To: Tim Panton new X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: public-webrtc , "rtcweb@ietf.org >> rtcweb@ietf.org" Subject: Re: [rtcweb] ICE exposes 'real' local IP to javascript 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 Feb 2015 19:45:58 -0000 --Apple-Mail=_23BE5529-278A-4809-999E-EEDE50E0BD44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 2, 2015, at 02:16 PM, Tim Panton new wrote:=20= >=20 >> On 2 Feb 2015, at 21:13, G=C3=B6ran Eriksson AP = > = wrote: >>=20 >> =20 >> =20 >> From: Tim Panton [mailto:thp@westhawk.co.uk = ]=20 >> Sent: den 2 februari 2015 15:17 >> To: public-webrtc >> Cc: rtcweb@ietf.org >> rtcweb@ietf.org = >> Subject: ICE exposes 'real' local IP to javascript >> =20 >> Firstly- sorry for cross posting - I=E2=80=99m not sure which side of = the line this falls. >> Secondly - if this is covered, please let me know, I don=E2=80=99t = recall it cropping up... >> =20 >> I=E2=80=99ve been reading worried blogs that WEBRTC in browsers = =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2=80=99 ip addresses to = the javascript. >> The principle worriers are VPN users e.g = https://cryptostorm.org/viewtopic.php?f=3D50&t=3D2867&p=3D13096#p13096 = >> The concern is that this can be done without user notification = (DataChannel request) and might be used to=20 >> identify or finger-print users. Clearly the most vulnerable are Tor = users who are on a real routeable IP address >> or directly on a carrier grade nat (eg android phones etc) where the = IP may reveal the identity or location of the user. >> =20 >> It seems to me that this concern will be increased in the case of = ipv6 deployments (MNOs). >> =20 >> Do we need to specify a config option on the browser =E2=80=98I=E2=80=99= m using a VPN don=E2=80=99t expose my local IP=E2=80=99=20 >> =20 >> Again, sorry if I missed this being hashed to death already. >> [GAPE:] There are different =E2=80=9Cchallenges=E2=80=9D as I see it; = a) one to =E2=80=98hide=E2=80=99 the information from the involved web = sites and peers and b) another from a web site owner perspective, how to = safeguard users privacy and security. =E2=80=98a=E2=80=99 has been = discussed and partly addressed, e.g. in [1] and [2] . >=20 > I think these VPN users have hit the =E2=80=98partly=E2=80=99 aspect. = 5.4 in [1] says:=20 > "Note that these requirements are NOT intended to protect the user=E2=80= =99s > IP address from a malicious site. In general, the site will learn at > least a user's server reflexive address from any HTTP transaction.=E2=80= =9D=20 > The VPN folks are worried that their privacy may be compromised by = webRTC exposing their local IP without their permission. > An advert might call a dataChannel createOffer() for the purposes of = gaining the local IPV6 address and using it to fingerprint the user in > ways that the reflexive address couldn=E2=80=99t. - So they don=E2=80=99= t want to trust =E2=80=98evil_banners.com=E2=80=99 with their local = addresses and before webRTC they > didn=E2=80=99t have to. I=E2=80=99m not clear that this is a big = enough issue to warrant a spec change, but it is an issue they seem to = care about. Witholding the local IP address means traffic always has to go through a = TURN server, which harms the user experience. Consider for example two = users in the same office with their traffic tromboning up their little = DSL access link to a TURN server on the Internet. We don't want that. = But, likewise, those users may value their IPv6 privacy addresses and = their IPv4 NAPT to obscure "Alice" from "Bob" at that same company, and = disclosing their local IP address does leak information. This worry has = long been a problem on enterprise networks implementing ICE, to such a = degree that stripping a=3Dcandidate lines containing the internal = addresses is desirable for privacy (as well as to force ICE to complete = faster, as a firewall or NAT would prevent ICE from working with those = addresses in many cases, anyway). -d --Apple-Mail=_23BE5529-278A-4809-999E-EEDE50E0BD44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 2, 2015, at 02:16 PM, Tim Panton new <thp@westhawk.co.uk> = wrote:

On 2 Feb 2015, at 21:13, G=C3=B6ran Eriksson AP <goran.ap.eriksson@ericsson.com> wrote:

 
 
From: Tim Panton [mailto:thp@westhawk.co.uk] 
Sent: den= 2 februari 2015 15:17
To: public-webrtc
Cc: rtcweb@ietf.org >> rtcweb@ietf.org
Subject: ICE exposes 'real' local IP = to javascript
 
Firstly- sorry for = cross posting - I=E2=80=99m not sure which side of the line this = falls.
Secondly - if this is covered, please let = me know, I don=E2=80=99t recall it cropping up...
 
I=E2=80=99ve been reading worried blogs = that WEBRTC in browsers =E2=80=98leaks=E2=80=99 the local =E2=80=98real=E2= =80=99 ip addresses to the javascript.
The concern is that this can be done = without user notification (DataChannel request) and might be used = to 
identify or finger-print users. Clearly = the most vulnerable are Tor users who are on a real routeable IP = address
or directly on a carrier grade nat (eg = android phones etc) where the IP may reveal the identity or location of = the user.
 
It seems to me that this concern will be increased in = the case of ipv6 deployments (MNOs).
 
Do we need to specify a config option on the browser = =E2=80=98I=E2=80=99m using a VPN don=E2=80=99t expose my local = IP=E2=80=99 
 
Again, sorry if I missed this being hashed to death = already.
[GAPE:] There = are different =E2=80=9Cchallenges=E2=80=9D as I see it; a) one to = =E2=80=98hide=E2=80=99 the information from the involved web sites and = peers and b) another from a web site owner perspective, how to safeguard = users privacy and security. =E2=80=98a=E2=80=99 has been discussed and = partly addressed, e.g.  in [1] and [2] = .

I think these VPN users = have hit the =E2=80=98partly=E2=80=99 aspect. 5.4 in [1] = says: 
"Note that these requirements are NOT intended to protect the = user=E2=80=99s
IP address from a malicious = site. In = general, the site will learn at
least a user's server = reflexive address from any HTTP transaction.=E2=80=9D
The VPN = folks are worried that their privacy may be compromised by webRTC = exposing their local IP without their permission.
An advert = might call a dataChannel createOffer() for the purposes of gaining the = local IPV6 address and using it to fingerprint the user = in
ways that the reflexive address couldn=E2=80=99t. - So they = don=E2=80=99t want to trust =E2=80=98evil_banners.com=E2=80=99 with = their local addresses and before webRTC they
didn=E2=80=99= t have to. I=E2=80=99m not clear that this is a big enough issue to = warrant a spec change, but it is an issue they seem to care = about.

Witholding the local IP address means traffic = always has to go through a TURN server, which harms the user experience. =  Consider for example two users in the same office with their = traffic tromboning up their little DSL access link to a TURN server on = the Internet.  We don't want that.  But, likewise, those users = may value their IPv6 privacy addresses and their IPv4 NAPT to obscure = "Alice" from "Bob" at that same company, and disclosing their local IP = address does leak information.  This worry has long been a problem = on enterprise networks implementing ICE, to such a degree that stripping = a=3Dcandidate lines containing the internal addresses is desirable for = privacy (as well as to force ICE to complete faster, as a firewall or = NAT would prevent ICE from working with those addresses in many cases, = anyway).

-d





= --Apple-Mail=_23BE5529-278A-4809-999E-EEDE50E0BD44-- From nobody Wed Feb 4 16:02:28 2015 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 E975D1A0097 for ; Wed, 4 Feb 2015 16:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGnoHnsoD-Cm for ; Wed, 4 Feb 2015 16:02:24 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EAC1A002F for ; Wed, 4 Feb 2015 16:02:23 -0800 (PST) Received: from ppp118-209-97-104.lns20.mel4.internode.on.net ([118.209.97.104]:54181 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YJ9s3-0003Kc-Kj; Thu, 05 Feb 2015 11:00:35 +1100 Message-ID: <54D2B308.3060907@nteczone.com> Date: Thu, 05 Feb 2015 11:02:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> <54D1F710.4090504@nteczone.com> <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> In-Reply-To: <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? 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 Feb 2015 00:02:27 -0000 Hello Michael, Yes I think UDP will be the common case and I agree ICE can run over several protocols however Figure 1 (and associated text)/[http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13] only shows ICE/UDP. The draft really gives the impression that whilst ICE is used, ICE/UDP is the variant the draft has chosen. Could we ask the RFC editor to insert something in the introduction like "Note: This document focusses on SCTP over DTLS over ICE/UDP. However SCTP over DTLS over ICE/TCP is also supported."? I think it's much better to try to get something in the data channel draft than updating the transports draft. Although it still wouldn't hurt to add something there either. Regards, Christian On 4/02/2015 10:07 PM, Michael Tuexen wrote: >> On 04 Feb 2015, at 11:40, Christian Groves wrote: >> >> Is it too late to add some explicit text indicating TCP rather than having to reply on another draft? It's easily missed by people reading the draft and given the real estate given in the data channel draft its possible to come to another conclusion. > The document is in the RFC Editor queue... I would think that it is clear that ICE can run over several > protocols, not only UDP. So it might have been better not show nothing below ICE. But it think ICE/UDP > will be the stack used in a lot of cases. > > We could still try to make sure the stack is clear in > https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07 > > That has the advantage that it also deals with the media channels. > > Best regards > Michael >> Christian >> >> On 28/01/2015 5:15 AM, Michael Tuexen wrote: >>>> On 27 Jan 2015, at 18:44, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>>> Well, if you are doing ICE-TCP, I would expect you to run >DataChannels over that. ISTM that that suggests that the marker >should be TCP/DTLS/SCTP. >>>> I am not arguing against that. I just wonder why the data channel draft doesn’t say anything about TCP, while explicitly talking about UDP. >>> That is correct. However, >>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09 >>> says in the Abstract: >>> Using the >>> encapsulation method described in this document, SCTP is unaware of >>> the protocols being used below DTLS; >>> So it is clear that you can use other protocols like ICE/TCP. However, this >>> is not explicitly discussed and using TCP has the known drawback of running >>> a CC (in SCTP) over a CC (in TCP). >>> >>> I guess the reason why TCP is not mentioned explicitly is that noone brought >>> the issue up. It was always meant that you run over ICE no matter what ICE is running over... >>> >>> Best regards >>> Michael >>>> Regards, >>>> Christer >>>> On Tue, Jan 27, 2015 at 4:18 AM, Christer Holmberg wrote: >>>> Hi, >>>> Related to this, when I read the data channel draft, it explicitly talks about UDP. TCP is not even mentioned. >>>> So, does that mean that TCP/DTLS/SCTP is not “officially” a part of the data channel spec? >>>> Regards, >>>> Christer >>>> From: Makaraju, Maridi Raju (Raju) [mailto:Raju.Makaraju@alcatel-lucent.com] >>>> Sent: 24. tammikuuta 2015 15:35 >>>> To: Christer Holmberg; Justin Uberti >>>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> I am ok to use UDP/DTLS/SCTP and TCP/DTLS/SCTP. >>>> I agree that use of RFC #s is not the best option. >>>> However, I find some unease in the discussions about “TCP/DTLS” part, which seems to suggest why not use “TCP/TLS”? We understand that it can’t be called that way because of the RFC 4571 “shim layer” in between DTLS and TCP layers. Unfortunately, unlike TPKT, RFC 4571 did not give a name to the protocol, which would have been easy to use than the RFC directly. >>>> BR >>>> Raju >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Friday, January 23, 2015 1:22 AM >>>> To: Justin Uberti; Makaraju, Maridi Raju (Raju) >>>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> Hi, >>>> I agree that we should not use RFC numbers in proto values. >>>> Also keep in mind that UDP/DTLS/SCTP does not mean “ICE based”. ICE is optional for UDP/DTLS/SCTP (that fact that we mandate ICE for RTCWEB is a separate issue). >>>> Regards, >>>> Christer >>>> From: Justin Uberti [mailto:juberti@google.com] >>>> Sent: 23. tammikuuta 2015 5:57 >>>> To: Makaraju, Maridi Raju (Raju) >>>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> No, I don't think including RFC4571 is reasonable. That ship has already sailed. >>>> On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) wrote: >>>> I was also suggesting the following identifying string to make it unambiguous up to L4 protocol. >>>> I don’t hear any objections to it explicitly. Or did I misinterpret the response? >>>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>>> BR >>>> Raju >>>> From: Justin Uberti [mailto:juberti@google.com] >>>> Sent: Thursday, January 22, 2015 4:45 PM >>>> To: Makaraju, Maridi Raju (Raju) >>>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> The protocol is the same. We are just deciding what the identifying string should be. >>>> Given the amount of confusion in this space, I think it makes sense to be as explicit as possible, and use DTLS instead of TLS for the name. >>>> On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) wrote: >>>> From protocol stacks layering point of view, isn’t the following more accurately represent them? >>>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>>> Per my understanding, independent of underlying transport (UDP; or “TCP over RFC4471” framing mimicking datagram transport) the DTLS protocol is same. >>>> 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 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Feb 4 16:29:57 2015 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 2492B1A008F for ; Wed, 4 Feb 2015 16:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8SJCIfh2RoF for ; Wed, 4 Feb 2015 16:29:52 -0800 (PST) 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 1013C1A0081 for ; Wed, 4 Feb 2015 16:29:52 -0800 (PST) Received: from [192.168.1.200] (p54818151.dip0.t-ipconnect.de [84.129.129.81]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 069961C104367; Thu, 5 Feb 2015 01:29:48 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <54D2B308.3060907@nteczone.com> Date: Thu, 5 Feb 2015 01:29:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <34755AAD-C903-49B0-83A8-066E07D95703@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> <54D1F710.4090504@nteczone.com> <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> <54D2B308.3060907@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? 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 Feb 2015 00:29:55 -0000 > On 05 Feb 2015, at 01:02, Christian Groves = wrote: >=20 > Hello Michael, >=20 > Yes I think UDP will be the common case and I agree ICE can run over = several protocols however Figure 1 (and associated = text)/[http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13] = only shows ICE/UDP. The draft really gives the impression that whilst = ICE is used, ICE/UDP is the variant the draft has chosen. >=20 > Could we ask the RFC editor to insert something in the introduction = like "Note: This document focusses on SCTP over DTLS over ICE/UDP. = However SCTP over DTLS over ICE/TCP is also supported."? I don't know. I don't think this is appropriate for an AUTH48 comment. = But the WG chairs might now the process better... Best regards Michael >=20 > I think it's much better to try to get something in the data channel = draft than updating the transports draft. Although it still wouldn't = hurt to add something there either. >=20 > Regards, Christian >=20 > On 4/02/2015 10:07 PM, Michael Tuexen wrote: >>> On 04 Feb 2015, at 11:40, Christian Groves = wrote: >>>=20 >>> Is it too late to add some explicit text indicating TCP rather than = having to reply on another draft? It's easily missed by people reading = the draft and given the real estate given in the data channel draft its = possible to come to another conclusion. >> The document is in the RFC Editor queue... I would think that it is = clear that ICE can run over several >> protocols, not only UDP. So it might have been better not show = nothing below ICE. But it think ICE/UDP >> will be the stack used in a lot of cases. >>=20 >> We could still try to make sure the stack is clear in >> https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07 >>=20 >> That has the advantage that it also deals with the media channels. >>=20 >> Best regards >> Michael >>> Christian >>>=20 >>> On 28/01/2015 5:15 AM, Michael Tuexen wrote: >>>>> On 27 Jan 2015, at 18:44, Christer Holmberg = wrote: >>>>>=20 >>>>> Hi, >>>>> =20 >>>>>> Well, if you are doing ICE-TCP, I would expect you to run = >DataChannels over that. ISTM that that suggests that the marker >should = be TCP/DTLS/SCTP. >>>>> I am not arguing against that. I just wonder why the data channel = draft doesn=E2=80=99t say anything about TCP, while explicitly talking = about UDP. >>>> That is correct. However, >>>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09 >>>> says in the Abstract: >>>> Using the >>>> encapsulation method described in this document, SCTP is unaware = of >>>> the protocols being used below DTLS; >>>> So it is clear that you can use other protocols like ICE/TCP. = However, this >>>> is not explicitly discussed and using TCP has the known drawback of = running >>>> a CC (in SCTP) over a CC (in TCP). >>>>=20 >>>> I guess the reason why TCP is not mentioned explicitly is that = noone brought >>>> the issue up. It was always meant that you run over ICE no matter = what ICE is running over... >>>>=20 >>>> Best regards >>>> Michael >>>>> Regards, >>>>> Christer >>>>> On Tue, Jan 27, 2015 at 4:18 AM, Christer Holmberg = wrote: >>>>> Hi, >>>>> Related to this, when I read the data channel draft, it = explicitly talks about UDP. TCP is not even mentioned. >>>>> So, does that mean that TCP/DTLS/SCTP is not =E2=80=9Cofficially=E2= =80=9D a part of the data channel spec? >>>>> Regards, >>>>> Christer >>>>> From: Makaraju, Maridi Raju (Raju) = [mailto:Raju.Makaraju@alcatel-lucent.com] >>>>> Sent: 24. tammikuuta 2015 15:35 >>>>> To: Christer Holmberg; Justin Uberti >>>>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = >>>>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>>>> I am ok to use UDP/DTLS/SCTP and TCP/DTLS/SCTP. >>>>> I agree that use of RFC #s is not the best option. >>>>> However, I find some unease in the discussions about = =E2=80=9CTCP/DTLS=E2=80=9D part, which seems to suggest why not use = =E2=80=9CTCP/TLS=E2=80=9D? We understand that it can=E2=80=99t be = called that way because of the RFC 4571 =E2=80=9Cshim layer=E2=80=9D in = between DTLS and TCP layers. Unfortunately, unlike TPKT, RFC 4571 did = not give a name to the protocol, which would have been easy to use than = the RFC directly. >>>>> BR >>>>> Raju >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Friday, January 23, 2015 1:22 AM >>>>> To: Justin Uberti; Makaraju, Maridi Raju (Raju) >>>>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = >>>>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>>>> Hi, >>>>> I agree that we should not use RFC numbers in proto values. >>>>> Also keep in mind that UDP/DTLS/SCTP does not mean =E2=80=9CICE = based=E2=80=9D. ICE is optional for UDP/DTLS/SCTP (that fact that we = mandate ICE for RTCWEB is a separate issue). >>>>> Regards, >>>>> Christer >>>>> From: Justin Uberti [mailto:juberti@google.com] >>>>> Sent: 23. tammikuuta 2015 5:57 >>>>> To: Makaraju, Maridi Raju (Raju) >>>>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas = Nandakumar; >>>>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>>>> No, I don't think including RFC4571 is reasonable. That ship has = already sailed. >>>>> On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) = wrote: >>>>> I was also suggesting the following identifying string to make it = unambiguous up to L4 protocol. >>>>> I don=E2=80=99t hear any objections to it explicitly. Or did I = misinterpret the response? >>>>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>>>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>>>> BR >>>>> Raju >>>>> From: Justin Uberti [mailto:juberti@google.com] >>>>> Sent: Thursday, January 22, 2015 4:45 PM >>>>> To: Makaraju, Maridi Raju (Raju) >>>>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas = Nandakumar; >>>>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? >>>>> The protocol is the same. We are just deciding what the = identifying string should be. >>>>> Given the amount of confusion in this space, I think it makes = sense to be as explicit as possible, and use DTLS instead of TLS for the = name. >>>>> On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) = wrote: >>>>> =46rom protocol stacks layering point of view, isn=E2=80=99t the = following more accurately represent them? >>>>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>>>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>>>> Per my understanding, independent of underlying transport (UDP; = or =E2=80=9CTCP over RFC4471=E2=80=9D framing mimicking datagram = transport) the DTLS protocol is same. >>>>> BR >>>>> Raju >>>>> _______________________________________________ >>>>> 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 >>>> _______________________________________________ >>>> 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 >=20 >=20 From nobody Thu Feb 5 03:40:09 2015 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 962771A7017 for ; Thu, 5 Feb 2015 03:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VanqDqsPkfFM for ; Thu, 5 Feb 2015 03:40:00 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4AA1A7013 for ; Thu, 5 Feb 2015 03:40:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 730D07C433C for ; Thu, 5 Feb 2015 12:39:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6baXcrqGP1c for ; Thu, 5 Feb 2015 12:39:56 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:dc35:b5cd:893a:f890] (unknown [IPv6:2001:470:de0a:27:dc35:b5cd:893a:f890]) by mork.alvestrand.no (Postfix) with ESMTPSA id 959AD7C3B82 for ; Thu, 5 Feb 2015 12:39:56 +0100 (CET) Message-ID: <54D3568B.2060609@alvestrand.no> Date: Thu, 05 Feb 2015 12:39:55 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> <54D1F710.4090504@nteczone.com> <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> In-Reply-To: <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? 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 Feb 2015 11:40:05 -0000 Den 04. feb. 2015 12:07, skrev Michael Tuexen: >> On 04 Feb 2015, at 11:40, Christian Groves wrote: >> >> Is it too late to add some explicit text indicating TCP rather than having to reply on another draft? It's easily missed by people reading the draft and given the real estate given in the data channel draft its possible to come to another conclusion. > The document is in the RFC Editor queue... I would think that it is clear that ICE can run over several > protocols, not only UDP. So it might have been better not show nothing below ICE. But it think ICE/UDP > will be the stack used in a lot of cases. > > We could still try to make sure the stack is clear in > https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07 > > That has the advantage that it also deals with the media channels. Completely BTW: The -transports draft is now on github: git@github.com:alvestrand/webrtc-specs.git Feel free to send me a pull request if you have specific language suggestions. > > Best regards > Michael >> >> Christian >> >> On 28/01/2015 5:15 AM, Michael Tuexen wrote: >>>> On 27 Jan 2015, at 18:44, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>>> Well, if you are doing ICE-TCP, I would expect you to run >DataChannels over that. ISTM that that suggests that the marker >should be TCP/DTLS/SCTP. >>>> I am not arguing against that. I just wonder why the data channel draft doesn’t say anything about TCP, while explicitly talking about UDP. >>> That is correct. However, >>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09 >>> says in the Abstract: >>> Using the >>> encapsulation method described in this document, SCTP is unaware of >>> the protocols being used below DTLS; >>> So it is clear that you can use other protocols like ICE/TCP. However, this >>> is not explicitly discussed and using TCP has the known drawback of running >>> a CC (in SCTP) over a CC (in TCP). >>> >>> I guess the reason why TCP is not mentioned explicitly is that noone brought >>> the issue up. It was always meant that you run over ICE no matter what ICE is running over... >>> >>> Best regards >>> Michael >>>> Regards, >>>> Christer >>>> On Tue, Jan 27, 2015 at 4:18 AM, Christer Holmberg wrote: >>>> Hi, >>>> Related to this, when I read the data channel draft, it explicitly talks about UDP. TCP is not even mentioned. >>>> So, does that mean that TCP/DTLS/SCTP is not “officially” a part of the data channel spec? >>>> Regards, >>>> Christer >>>> From: Makaraju, Maridi Raju (Raju) [mailto:Raju.Makaraju@alcatel-lucent.com] >>>> Sent: 24. tammikuuta 2015 15:35 >>>> To: Christer Holmberg; Justin Uberti >>>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> I am ok to use UDP/DTLS/SCTP and TCP/DTLS/SCTP. >>>> I agree that use of RFC #s is not the best option. >>>> However, I find some unease in the discussions about “TCP/DTLS” part, which seems to suggest why not use “TCP/TLS”? We understand that it can’t be called that way because of the RFC 4571 “shim layer” in between DTLS and TCP layers. Unfortunately, unlike TPKT, RFC 4571 did not give a name to the protocol, which would have been easy to use than the RFC directly. >>>> BR >>>> Raju >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Friday, January 23, 2015 1:22 AM >>>> To: Justin Uberti; Makaraju, Maridi Raju (Raju) >>>> Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> Hi, >>>> I agree that we should not use RFC numbers in proto values. >>>> Also keep in mind that UDP/DTLS/SCTP does not mean “ICE based”. ICE is optional for UDP/DTLS/SCTP (that fact that we mandate ICE for RTCWEB is a separate issue). >>>> Regards, >>>> Christer >>>> From: Justin Uberti [mailto:juberti@google.com] >>>> Sent: 23. tammikuuta 2015 5:57 >>>> To: Makaraju, Maridi Raju (Raju) >>>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> No, I don't think including RFC4571 is reasonable. That ship has already sailed. >>>> On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) wrote: >>>> I was also suggesting the following identifying string to make it unambiguous up to L4 protocol. >>>> I don’t hear any objections to it explicitly. Or did I misinterpret the response? >>>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>>> BR >>>> Raju >>>> From: Justin Uberti [mailto:juberti@google.com] >>>> Sent: Thursday, January 22, 2015 4:45 PM >>>> To: Makaraju, Maridi Raju (Raju) >>>> Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; >>>> Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? >>>> The protocol is the same. We are just deciding what the identifying string should be. >>>> Given the amount of confusion in this space, I think it makes sense to be as explicit as possible, and use DTLS instead of TLS for the name. >>>> On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) wrote: >>>> From protocol stacks layering point of view, isn’t the following more accurately represent them? >>>> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >>>> For UDP ICE based data channel transport: UDP/DTLS/SCTP >>>> Per my understanding, independent of underlying transport (UDP; or “TCP over RFC4471” framing mimicking datagram transport) the DTLS protocol is same. >>>> 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 >> >> _______________________________________________ >> 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 Feb 5 03:46:52 2015 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 63CE81A6FEF for ; Thu, 5 Feb 2015 03:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thkdzWsxeDQB for ; Thu, 5 Feb 2015 03:46:50 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 09F181A1AAC for ; Thu, 5 Feb 2015 03:46:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2229E7C4333 for ; Thu, 5 Feb 2015 12:46:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZGoM8q2DkVy for ; Thu, 5 Feb 2015 12:46:48 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:dc35:b5cd:893a:f890] (unknown [IPv6:2001:470:de0a:27:dc35:b5cd:893a:f890]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2C4C57C3E96 for ; Thu, 5 Feb 2015 12:46:48 +0100 (CET) Message-ID: <54D35827.6060001@alvestrand.no> Date: Thu, 05 Feb 2015 12:46:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> <54D1F710.4090504@nteczone.com> <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> <54D3568B.2060609@alvestrand.no> In-Reply-To: <54D3568B.2060609@alvestrand.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? 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 Feb 2015 11:46:51 -0000 Den 05. feb. 2015 12:39, skrev Harald Alvestrand: > Den 04. feb. 2015 12:07, skrev Michael Tuexen: >>> On 04 Feb 2015, at 11:40, Christian Groves wrote: >>> >>> Is it too late to add some explicit text indicating TCP rather than having to reply on another draft? It's easily missed by people reading the draft and given the real estate given in the data channel draft its possible to come to another conclusion. >> The document is in the RFC Editor queue... I would think that it is clear that ICE can run over several >> protocols, not only UDP. So it might have been better not show nothing below ICE. But it think ICE/UDP >> will be the stack used in a lot of cases. >> >> We could still try to make sure the stack is clear in >> https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07 >> >> That has the advantage that it also deals with the media channels. > > Completely BTW: The -transports draft is now on github: > > git@github.com:alvestrand/webrtc-specs.git Self-correcting: The master master is at this URL: git@github.com:rtcweb-wg/rtcweb-transport.git There is no issue tracker, and I can't enable one - seems the site admins have to do that. > > Feel free to send me a pull request if you have specific language > suggestions. This still applies. From nobody Thu Feb 5 12:05:55 2015 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 1B6D71A8A4E for ; Thu, 5 Feb 2015 12:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Twws1Ouq8Z5X for ; Thu, 5 Feb 2015 12:05:41 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADA11A1AE3 for ; Thu, 5 Feb 2015 12:05:31 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id l13so561383iga.0 for ; Thu, 05 Feb 2015 12:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0TF/1x0HN+AR25/mCULytKly/FCQwB4A1JJ5UG09g2A=; b=f2WPoZOu2oKIPUem3sT4CBJeHl+nD9gXT0dl1KgOWNimQjwD60Wb+2KIEV+rZpeWyq F4/afAKhh2WU8tZcFxhl3ruueK47VapYzOPRLeEgV2OolCXenP6sNGVx/qpdICaeyfWo WRBSwfjrL1PCj0Yr1XZFNoit8aEQbAEs+3r2L0XmdOD6gwVmjyY3pBFMhohkK0tUs5Tz 2isEjpDkJu4ebafn6JovnsNmAwnx+Gesy9Q6Xq09twh1ZH6s6DRDDTHUgzRoLjMV8ynz YU454ZIqvpAQ/DxjeNJAYbF5LGI5OKuSoCZGZCr7599DF2P80GNv4dHF2TrVm83YZulY 6IZQ== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr269604igb.6.1423166729788; Thu, 05 Feb 2015 12:05:29 -0800 (PST) Received: by 10.42.35.142 with HTTP; Thu, 5 Feb 2015 12:05:29 -0800 (PST) In-Reply-To: <54D35827.6060001@alvestrand.no> References: <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> <54D1F710.4090504@nteczone.com> <5752B8EC-EBC3-4D97-BD39-902E78AB31BF@lurchi.franken.de> <54D3568B.2060609@alvestrand.no> <54D35827.6060001@alvestrand.no> Date: Thu, 5 Feb 2015 12:05:29 -0800 Message-ID: From: Ted Hardie To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b41444c62a1de050e5cd34c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? 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 Feb 2015 20:05:46 -0000 --047d7b41444c62a1de050e5cd34c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 5, 2015 at 3:46 AM, Harald Alvestrand wrote: > > Self-correcting: The master master is at this URL: > > git@github.com:rtcweb-wg/rtcweb-transport.git > > There is no issue tracker, and I can't enable one - seems the site > admins have to do that. > =E2=80=8BI believe the issue tracker should be working now. regards, Ted=E2=80=8B --047d7b41444c62a1de050e5cd34c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 5, 2015 at 3:46 AM,= Harald Alvestrand <harald@alvestrand.no> wrote:

Self-correcting: The master master is at this URL:

git@github.com:rtcweb-wg/rtcweb-transport.git

There is no issue tracker, and I can't enable one - seems the site
admins have to do that.

=E2= =80=8BI believe the issue tracker should be working now.

regards,
Ted=E2=80=8B
=C2=A0
--047d7b41444c62a1de050e5cd34c-- From nobody Thu Feb 5 15:40:05 2015 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 EDC571A1ABC for ; Thu, 5 Feb 2015 15:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.312 X-Spam-Level: X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NsvKn-nEZ-c for ; Thu, 5 Feb 2015 15:39:55 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B82361A0018 for ; Thu, 5 Feb 2015 15:39:55 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 6000) id 3935D187E26; Thu, 5 Feb 2015 15:39:35 -0800 (PST) Date: Thu, 5 Feb 2015 15:39:35 -0800 From: RFC Editor To: Barry Dingle Message-ID: <20150205233935.GA32519@rfc-editor.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: rtcweb mailing list , rtcweb chair , RFC Editor Subject: Re: [rtcweb] Consistent WebRTC Descriptions in WebRTC RFC Abstracts 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 Feb 2015 23:39:59 -0000 Hi Barry, On Tue, Jan 13, 2015 at 12:15:27PM +1100, Barry Dingle wrote: > The recently proposed Standards *WebRTC Data Channel RFC* and *WebRTC Data > Channel Establishment Protocol RFC* have a consistent single sentence > describing what WebRTC is in their Abstracts. They both say: > > The WebRTC framework specifies protocol support for direct interactive > rich communication using audio, > video, and data between two peers' web-browsers. > > I notice that several other WebRTC proposed RFCs have single sentence > WebRTC descriptions in their Abstract *but they are differen*t e.g. WebRTC > Overview RFC; Media Transport + Use of RTP; Security; Security Architecture > > All the others have *NO WebRTC description*. > > *Do we need a consistent single sentence in the Abstract of all WebRTC > RFCs?* We did not see any further discusison on this topic. The RFC Editor does not have a requirement here. We suggest discussing this with your WG group and chairs. Thank you, RFC Editor/sg > > If so, what should the wording be? > > Should the wording be in the Abstract of ALL WebRTC RFCs? > > > Barry Dingle > > Fellow of University of Melbourne, Australia > > On Fri, Jan 9, 2015 at 1:38 AM, The IESG wrote: > > > The IESG has approved the following document: > > - 'WebRTC Data Channels' > > (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard > > > > This document is the product of the Real-Time Communication in > > WEB-browsers Working Group. > > > > The IESG contact persons are Richard Barnes and Alissa Cooper. > > > > A URL of this Internet Draft is: > > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ > > > > > > > > > > Technical Summary: > > > > This document specifies the non??media data transport aspects of the WebRTC > > framework. It provides an architectural overview of how the Stream Control > > Transmission > > Protocol (SCTP) is used in the WebRTC context as a generic transport > > service. > > > > Working Group Summary: > > > > There was early discussion of the stacking order, but there has been no > > significant > > controversy since that was fixed. There have been a number of discussion > > on how to manage > > particular aspects of the larger context (e.g. WebRTC??level congestion > > control, since SCTP > > manages congestion control at the association level) and this has played a > > part in those, but > > not in any way that mde it the focus of controversy. > > > > Document Quality: > > > > There are implmentations of previous versions of this document, and we > > expect updates to > > them to the final version. Vendor support seems solid. This document did > > not require > > expert review of the types noted. > > > > Personnel: > > > > The document shepherd is Ted Hardie; the responsible Area Director is > > Richard Barnes. > > > > > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > From nobody Thu Feb 5 17:02:06 2015 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 0BDB31A0097 for ; Thu, 5 Feb 2015 17:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L__6hloUHJdV for ; Thu, 5 Feb 2015 17:02:01 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680CA1A00E5 for ; Thu, 5 Feb 2015 17:01:57 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id l13so3529173iga.5 for ; Thu, 05 Feb 2015 17:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C5lIYaFsvobqFcRniolxJsA/UM3gHa1Iq/iHPmpAnkc=; b=bg2VkcdQCsYAEbiUakgDS4UNpxPyJUiHgpqd4Hv0qRaDHVfvdbkoOj9QldPD5i+qs4 sx6lhodo8r4es0Gxoo9ctmFBXREad2NWvDWIZM7UKcVKHziMXZLv1RIzU+m6MIMkv1Il +B6U4ZyFRnkZUTOMNQAss/gJu9mtiYXAdsWfHAft46U5TMExeLFeosXUPtyURPCNHT5C 9ufyEUlhAIA0zx56rYoVKJL0bl6kUdVCJNA0IEnK5fM5A6ETJ0KNSw2qUozzBGQKgKn+ o5e2MH+JkHhmXgcMcsfbuxmNtID+ZqZoInZ4OjAPXfC+N8jWbOeD+6NHkHAIi2dv0ngI kUSg== 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=C5lIYaFsvobqFcRniolxJsA/UM3gHa1Iq/iHPmpAnkc=; b=cOfvQHiq5GxfygLTU3wDC6phQ56hUc1UN2zfxnyDY+eAVWCa6eCI+q5ctg8RSy2ygT uodEKvomaQdWiQwxO6u0z/LBsK7X9OeEFK3EV9RMLQRfyCLpT1wbtVrrS730XOYzfoLE p+qhbgIyb92VClxrRyX4kn51HlOr/MHiUZ1Qft9AfJwvpAU7/SlCWa8Ko2xgbz6v1+KW V9+K45AY+p4p/UpnVBxUVpCdy6ujc9Wubp7tIELSdCHSfsbJxk3q/r8HDTq68GQ/N6Ny naLu8DPbbG/52RMoo759r52kxVNlVowO2oI08AhWnNhQ6r9ezejQ5dliclNw1Bvx8Qon 9+/Q== X-Gm-Message-State: ALoCoQk40wd6lpWxccDuj7pvrEKrw5VuCVwnXi4tUiwlxITiqRW5XYE088nLydzcjqCs3l+X5sn+ X-Received: by 10.43.6.71 with SMTP id oj7mr10617653icb.87.1423184516439; Thu, 05 Feb 2015 17:01:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Thu, 5 Feb 2015 17:01:36 -0800 (PST) In-Reply-To: References: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> <54CBACE1.2090104@ericsson.com> From: Justin Uberti Date: Thu, 5 Feb 2015 17:01:36 -0800 Message-ID: To: Varun Singh Content-Type: multipart/alternative; boundary=bcaec5158d918d94a9050e60f753 Archived-At: Cc: "Cullen Jennings \(fluffy\)" , Ted Hardie , "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for WG adoption of draft-uberti-rtcweb-fec 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, 06 Feb 2015 01:02:03 -0000 --bcaec5158d918d94a9050e60f753 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just resubmitted the current draft as a -00 WG draft. Once that is accepted, I will work on a -01 with the feedback from Honolulu= . On Fri, Jan 30, 2015 at 10:21 AM, Varun Singh wrote= : > I support this too. The corresponding RTP payload draft was recently > adopted as well. > On 30-Jan-2015 6:10 pm, "Magnus Westerlund" < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> I support this. Considering that the deadline is passed. Is this now >> adopted? >> >> /Magnus >> >> On 2015-01-08 19:57, Cullen Jennings (fluffy) wrote: >> > >> > At the last meeting there was strong support for adopting >> > draft-uberti-rtcweb-fec as a WG draft. Unless we hear significant >> > objections to this, the chairs plan to more forward with adopting >> > this. If you have objection to this, please reply to this thread >> > before Jan 15. >> > >> > Thanks, >> > >> > Cullen, Sean, & Ted >> > >> > >> > >> > >> > _______________________________________________ rtcweb mailing list >> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> >> -- >> >> 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 >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec5158d918d94a9050e60f753 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just resubmitted the current draft as a -00 WG draft.
Once that is accepted, I will work on a -01 with the feedb= ack from Honolulu.

On Fri, Jan 30, 2015 at 10:21 AM, Varun Singh <vsingh.iet= f@gmail.com> wrote:

I support this too.=C2=A0 The corresponding RTP payload draft was = recently adopted as well.

On 30-Jan-2015 6:10 pm, "Magnus Westerlund&= quot; <magnus.westerlund@ericsson.com> wrote:
Hi,

I support this. Considering that the deadline is passed. Is this now
adopted?

/Magnus

On 2015-01-08 19:57, Cullen Jennings (fluffy) wrote:
>
> At the last meeting there was strong support for adopting
> draft-uberti-rtcweb-fec as a WG draft. Unless we hear significant
> objections to this, the chairs plan to more forward with adopting
> this. If you have objection to this, please reply to this thread
> before Jan 15.
>
> Thanks,
>
> Cullen, Sean, & Ted
>
>
>
>
> _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>


--

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

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


--bcaec5158d918d94a9050e60f753-- From nobody Fri Feb 6 08:56:27 2015 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 1FC821A7005; Fri, 6 Feb 2015 08:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzFVbA0xGc2d; Fri, 6 Feb 2015 08:56:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FEC1A700C; Fri, 6 Feb 2015 08:56:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 08:56:14 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-00.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: Fri, 06 Feb 2015 16:56: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 : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-00.txt Pages : 7 Date : 2015-02-05 Abstract: This document makes recommendations for how Forward Error Correction (FEC) should be used by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 6 23:49:16 2015 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 DF5601A7026 for ; Fri, 6 Feb 2015 23:49:14 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Bzqjj2QEi-wM for ; Fri, 6 Feb 2015 23:49:13 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0371A1B3E for ; Fri, 6 Feb 2015 23:49:12 -0800 (PST) X-Halon-ID: d4858948-ae9d-11e4-acbf-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 7 Feb 2015 08:49:22 +0100 (CET) Message-ID: <54D5C372.2070606@omnitor.se> Date: Sat, 07 Feb 2015 08:49:06 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> In-Reply-To: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [rtcweb] Use of redundancy and RFC 2119 language in draft-ietf-rtcweb-fec-00 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, 07 Feb 2015 07:49:15 -0000 I have two comments to draft-ietf-rtcweb-fec-00 1. Use of redundancy. Section 3.2 "Redundant encoding" informs about RFC 2198 . The last sentence says "This approach is also only applicable to audio content." RFC 2198 redundancy is successfully used in SIP and RTP for real-time text content (RFC 4103), because of its robustness, very low cost in bandwidth for low bandwidth media, and no risk for excessive delays. Chapter 3 seems to be a general overview of available methods without specific scope to WebRTC. Therefore, I suggest to either replace the sentence "This approach is also only applicable to audio content." with "This approach is also not applicable to video content." or delete it. 2. Use of SHOULD and MUST in abstract and introduction There are a couple of places in the document where the use of "must" and "should" may be confusing and should be avoided. The last sentence in the introduction says: "This document describes what FEC mechanisms should be used by WebRTC client implementations." There is a similar sentence in the abstract. There is also a "must" in the first sentence of the introduction, even if it is not thought to be normative. In the document body, there are varying normative levels on the different methods. Therefore I suggest to avoid the must and should in the abstract and introduction. 2.1 The last sentence of the introduction can be changed to: "This document provides information and requirements on the use of FEC mechanisms by WebRTC client implementations." 2.2 The abstract could be changed from: "This document makes recommendations for how Forward Error Correction (FEC) should be used by WebRTC applications." to "This document provides information and requirements on the use of Forward Error Correction (FEC) mechanisms by WebRTC applications." 2.3 The first sentence in the introduction, starting: "In situations where packet loss is high, or media quality must be perfect," could be changed to: "In situations where packet loss is high, or high media quality is essential," to avoid the use of "must" that apparently is not intended to be normative. Regards Gunnar Hellstrm internet-drafts@ietf.org skrev den 2015-02-06 17:56: > 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 : WebRTC Forward Error Correction Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-fec-00.txt > Pages : 7 > Date : 2015-02-05 > > Abstract: > This document makes recommendations for how Forward Error Correction > (FEC) should be used by WebRTC applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00 > > > 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/ > > _______________________________________________ > 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 -- ----------------------------------------- Gunnar Hellstrm Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sat Feb 7 10:24:48 2015 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 4438F1A6EFB for ; Sat, 7 Feb 2015 10:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlMWaxJX1LQb for ; Sat, 7 Feb 2015 10:24:43 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6811A6F38 for ; Sat, 7 Feb 2015 10:24:43 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so9080802igb.2 for ; Sat, 07 Feb 2015 10:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=As6DKS9EWp50NgWK49WbkjA4GSoAbeoMEZs8veAcnsE=; b=eH748TpCOj1C0SKo+4WWczGRp1slVWhRwzdTnv1ceDD6IxoM2HYezAi2wTOUJoBHOX aI5METFzsAgyz9FZb4qJ2iSPOyIJ2KnJ4Uz0u4JCu8thdnK9kqPpmLFndvETlQjLBUNS sahtWiVQ10AkgU2IiNE980I//H4a6PNn4A9Ls4xcE0wU22XFMdbOJCbt+R2FBqRwvE3U c+lv5Z+OUIaqzhzMjS1F6J6klU2PLnWUCjqzxDG9RtASiOuPq9SLtsJh6F5bZ2jCrhls VIwn7DEHmdy7jmhgNAqexsuLdw1mU1yRC3bOMjVYudMYO+0nPfocmKCSXXyApTNb+B/R R0rA== 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=As6DKS9EWp50NgWK49WbkjA4GSoAbeoMEZs8veAcnsE=; b=N2biJChOrGxF8dWAm5RW2rKMlY6PO4eNGkX4uWbflLa88YJjiC7S2SrZ26Gz/xMwB3 KfHVSeykkUGPDneXdEGIjXp0bJPlzVGWueGgruYNlQECklE0JyZHiOu2GDsAPBc1Uh9/ IfrSjI7AIkFTUEOXh1Ik3ySXxnutr0wMYvKlRWUyFjCI0cH4cwWJ6yAnpx5FJFaF6ec4 tkdsBeRXOzo+Mjnz0o95R1yVU0+6P3A8jl41M6BCfVYJAILBKw8Li7xLTghcG2WCslb/ J0tF6tBL4JTRci8aqjOrbQb5Y+gmM8nXh26KqjaZnNLvvFJcjO5B4nFMGLTXnlLZ0Nou ODkg== X-Gm-Message-State: ALoCoQk8Lan8CJka6ANJ/YUqeweUMcaVJ9ckfTIBSZxagoD9hr4z8wnF/sP0E+TP6HMysm/YMBwh X-Received: by 10.42.199.211 with SMTP id et19mr18888701icb.9.1423333482219; Sat, 07 Feb 2015 10:24:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Sat, 7 Feb 2015 10:24:22 -0800 (PST) In-Reply-To: <54D5C372.2070606@omnitor.se> References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> <54D5C372.2070606@omnitor.se> From: Justin Uberti Date: Sat, 7 Feb 2015 10:24:22 -0800 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=20cf30223eaf9ae8d3050e83a6b4 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use of redundancy and RFC 2119 language in draft-ietf-rtcweb-fec-00 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, 07 Feb 2015 18:24:45 -0000 --20cf30223eaf9ae8d3050e83a6b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the quick review and comments. I'll incorporate this into the -01 version I am working on. On Fri, Feb 6, 2015 at 11:49 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > I have two comments to draft-ietf-rtcweb-fec-00 > > 1. Use of redundancy. > Section 3.2 "Redundant encoding" informs about RFC 2198 . > The last sentence says "This approach is also only applicable to audio > content." > RFC 2198 redundancy is successfully used in SIP and RTP for real-time tex= t > content (RFC 4103), because of its robustness, very low cost in bandwidth > for low bandwidth media, and no risk for excessive delays. > Chapter 3 seems to be a general overview of available methods without > specific scope to WebRTC. > Therefore, I suggest to either replace the sentence > > "This approach is also only applicable to audio content." > with > "This approach is also not applicable to video content." > or delete it. > > 2. Use of SHOULD and MUST in abstract and introduction > There are a couple of places in the document where the use of "must" and > "should" may be confusing and should be avoided. > > The last sentence in the introduction says: > "This document describes what FEC mechanisms should be used by WebRTC > client implementations." > There is a similar sentence in the abstract. > There is also a "must" in the first sentence of the introduction, even if > it is not thought to be normative. > In the document body, there are varying normative levels on the different > methods. > Therefore I suggest to avoid the must and should in the abstract and > introduction. > > 2.1 The last sentence of the introduction can be changed to: > "This document provides information and requirements on the use of FEC > mechanisms by WebRTC client implementations." > > 2.2 The abstract could be changed from: > "This document makes recommendations for how Forward Error Correction > (FEC) should be used by WebRTC applications." > to > "This document provides information and requirements on the use of Forwar= d > Error Correction (FEC) mechanisms by WebRTC applications." > > 2.3 The first sentence in the introduction, starting: > "In situations where packet loss is high, or media quality must be > perfect," > could be changed to: > "In situations where packet loss is high, or high media quality is > essential," > to avoid the use of "must" that apparently is not intended to be normativ= e. > > Regards > > Gunnar Hellstr=C3=B6m > > > > > > > internet-drafts@ietf.org skrev den 2015-02-06 17:56: > >> 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 : WebRTC Forward Error Correction Requirements >> Author : Justin Uberti >> Filename : draft-ietf-rtcweb-fec-00.txt >> Pages : 7 >> Date : 2015-02-05 >> >> Abstract: >> This document makes recommendations for how Forward Error Correction >> (FEC) should be used by WebRTC applications. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00 >> >> >> 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/ >> >> _______________________________________________ >> 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 >> > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30223eaf9ae8d3050e83a6b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the quick review and comments. I'll incorpo= rate this into the -01 version I am working on.

On Fri, Feb 6, 2015 at 11:49 PM, Gunnar= Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrot= e:
I have two comments to draft-ietf-rtcw= eb-fec-00

1. Use of redundancy.
Section 3.2 "Redundant encoding" informs about RFC 2198 .
The last sentence says "This approach is also only applicable to audio= content."
RFC 2198 redundancy is successfully used in SIP and RTP for real-time text = content (RFC 4103), because of its robustness, very low cost in bandwidth f= or low bandwidth media, and no risk for excessive delays.
Chapter 3 seems to be a general overview of available methods without speci= fic scope to WebRTC.
Therefore, I suggest to either replace the sentence

"This approach is also only applicable to audio content."
with
"This approach is also not applicable to video content."
or delete it.

2. Use of SHOULD and MUST in abstract and introduction
There are a couple of places in the document where the use of "must&qu= ot; and "should" may be confusing and should be avoided.

The last sentence in the introduction says:
"This document describes what FEC mechanisms should be used by WebRTC = client implementations."
There is a similar sentence in the abstract.
There is also a "must" in the first sentence of the introduction,= even if it is not thought to be normative.
In the document body, there are varying normative levels on the different m= ethods.
Therefore I suggest to avoid the must and should in the abstract and introd= uction.

2.1 The last sentence of the introduction can be changed to:
"This document provides information and requirements on the use of FEC= mechanisms by WebRTC client implementations."

2.2 The abstract could be changed from:
"This document makes recommendations for how Forward Error Correction = (FEC) should be used by WebRTC applications."
to
"This document provides information and requirements on the use of For= ward Error Correction (FEC) mechanisms by WebRTC applications."

2.3 The first sentence in the introduction, starting:
"In situations where packet loss is high, or media quality must be per= fect,"
could be changed to:
"In situations where packet loss is high, or high media quality is ess= ential,"
to avoid the use of "must" that apparently is not intended to be = normative.

Regards

Gunnar Hellstr=C3=B6m






internet-draf= ts@ietf.org skrev den 2015-02-06 17:56:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0 This draft is a work item of the Real-Time Communication in WEB-brow= sers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Justin Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-02-05

Abstract:
=C2=A0 =C2=A0 This document makes recommendations for how Forward Error Cor= rection
=C2=A0 =C2=A0 (FEC) should be used by WebRTC applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-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@iet= f.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=

--
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hel= lstrom@omnitor.se
+46 708 204 288

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

--20cf30223eaf9ae8d3050e83a6b4-- From nobody Sat Feb 7 17:46:21 2015 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 233441A1A90 for ; Sat, 7 Feb 2015 17:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGZ-wU4vENws for ; Sat, 7 Feb 2015 17:44:56 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1F41A00C6 for ; Sat, 7 Feb 2015 17:44:55 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so24127639lbj.0 for ; Sat, 07 Feb 2015 17:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hkNzGNjVwPUW6utgf/sVIKC5pEnXLfoKMVzCU4ZXoVE=; b=GWf/b10UJYchcXWnS2sZOzxUCo7UJ9VZmQcQYFkChJe1qR3mxHd86IzN7LxU57G+6R iu7+nBzun4yfxwZexllYmcC22wdWB953qcgEtAdGxHNZd9jtixnXVmxpXgW4LUyO16ZZ WlCjmqQj3CSCfFin27VPe/0YqvcR7TGQ6JmQQr+O5dPgkX5jjmhpPvCt4/Ar+Htury4D ToFxf2yBfPdDgUDY6FhdAi5+wCZFWISAf7ZmslKAfqUktAPgsdpKSCA0ONYnw2o+zdRh 595nNNj3qIonWgrw+SwO5HxBt3zUUrdxjUBoNdLgXeOXjh9e/Gz9Qsuv3fKCo3ugs4gR I/2Q== X-Received: by 10.152.6.37 with SMTP id x5mr9879866lax.44.1423359894412; Sat, 07 Feb 2015 17:44:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.88.79 with HTTP; Sat, 7 Feb 2015 17:44:34 -0800 (PST) In-Reply-To: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> From: Barry Dingle Date: Sun, 8 Feb 2015 12:44:34 +1100 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01494026e4e118050e89ccc1 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Sun, 08 Feb 2015 01:44:59 -0000 --089e01494026e4e118050e89ccc1 Content-Type: text/plain; charset=UTF-8 The new "WebRTC Forward Error Correction Requirements" draft refers solely to 'media' FEC requirements. It does not refer to non-media (or DataChannel) uses of FEC. If this draft is intended to concentrate on the media FEC requirements, then the Title should be changed to reflect that, namely: "WebRTC *Media* Forward Error Correction Requirements", If it intended to also cover DataChannel uses of FEC then the draft should have a new section after Section 5 with a Heading of "FEC for DataChannel Content". /Barry Dingle On Sat, Feb 7, 2015 at 3:56 AM, wrote: > > 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 : WebRTC Forward Error Correction Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-fec-00.txt > Pages : 7 > Date : 2015-02-05 > > Abstract: > This document makes recommendations for how Forward Error Correction > (FEC) should be used by WebRTC applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00 > > > 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 > --089e01494026e4e118050e89ccc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The new "WebRTC Forward Error Correction Re= quirements" draft refers solely to 'media' FEC requirements. <= br>
It does not refer to non-media (or DataChannel) uses of FEC. <= br>
If this draft is intended to concentrate on the media FEC requ= irements, then the Title should be changed to reflect that, namely:

=
"WebRTC Media Fo= rward Error Correction Requirements",

If it intended to also cover DataChannel uses of FEC then the draft= should have a new section after Section 5 with a Heading of "FEC for = DataChannel Content".
=C2=A0
<= div>
/Barry Dingle


On Sat, Feb 7, 2015 at 3:56 AM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-02-05

Abstract:
=C2=A0 =C2=A0This document makes recommendations for how Forward Error Corr= ection
=C2=A0 =C2=A0(FEC) should be used by WebRTC applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-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/

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

--089e01494026e4e118050e89ccc1-- From nobody Sat Feb 7 22:18:13 2015 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 AFC071A8A5A for ; Sat, 7 Feb 2015 22:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbGeluZ33Y01 for ; Sat, 7 Feb 2015 22:18:11 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06E91A8A57 for ; Sat, 7 Feb 2015 22:18:10 -0800 (PST) Received: by iebtr6 with SMTP id tr6so10085613ieb.4 for ; Sat, 07 Feb 2015 22:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F/mMAWVQEdaeMrNfGq8tZV/jqf2h5FgiRRv84bk/U5M=; b=FUz5a3Wg62agE5uHNH5smm1PRJ3w3W1kR/nEWlP93GQLDoymEVPRYaFCkcBvfT+uRE kXGRe7UkVp5paApFVJTSzJ00pZIBq6wabhGvgydJfZ/v1+9JcjcoT6uuaxro9MXFGCJZ Hw5kBCu9LfCqHeeHywY9CfUcCqPRZ5iheQpBjHjWDfRc4u68qUosuMW+yRdKThYSu11O jR/W0W9HYn9nXGUY1Zp04Xz+koNsFL9Q/bzuJ1owgLY+thA1n4XdnavVOpEFqq8oBpMQ ZziP+HgBi29IYkjb0bC8yrT6RGn1yKOO+5GncHnJTEIoMDK+gXxUjUv3HZ1c1SXpoVQ8 P23Q== 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=F/mMAWVQEdaeMrNfGq8tZV/jqf2h5FgiRRv84bk/U5M=; b=AnW3Uu7LXv9y/yAqq1a0EMB556PAXGvpPbJjx9h8nWeLiaS3QP0jVh9q6R/Wx3HJQq 46PNlsroxYRnY92f1jVHE7iVhNkvpt8Kl+U4Ba0/QkkBdJ9K7jGpICi5TGVKaM8KGVW+ /Sf+yvzor1a5TRQ/2DODm0UHREv8KULI7ZcRHt6nADjcJYst25tWeckyGIcvCYH/2PIo 1geHKx+Aguse6UXFLuJPXGxYc/NlpKvEA/28XhlV1W8BCLP43QhxAj9FbI+6cUdbcU0y L48vzP57J412D1/wkDhk9SV/IFRRpZ80OfL37JehKekt5Nr4KdNoWI4Tjb/Ato8tjgDU duOQ== X-Gm-Message-State: ALoCoQkl8cH2mx/qM0DPy59hNS9mUVlvnhcZCBknhNgqZfUKTynAMg5+ggc7xdBzVgFkI5QnC8ch X-Received: by 10.107.129.32 with SMTP id c32mr19018286iod.60.1423376290022; Sat, 07 Feb 2015 22:18:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Sat, 7 Feb 2015 22:17:49 -0800 (PST) In-Reply-To: References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Sat, 7 Feb 2015 22:17:49 -0800 Message-ID: To: Barry Dingle Content-Type: multipart/alternative; boundary=001a113ec9282637e4050e8d9e63 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Sun, 08 Feb 2015 06:18:12 -0000 --001a113ec9282637e4050e8d9e63 Content-Type: text/plain; charset=UTF-8 Interesting point. I don't think the WG has really discussed data FEC in detail yet, so your title suggestion makes sense to me. On Sat, Feb 7, 2015 at 5:44 PM, Barry Dingle wrote: > The new "WebRTC Forward Error Correction Requirements" draft refers solely > to 'media' FEC requirements. > > It does not refer to non-media (or DataChannel) uses of FEC. > > If this draft is intended to concentrate on the media FEC requirements, > then the Title should be changed to reflect that, namely: > > "WebRTC *Media* Forward Error Correction Requirements", > > If it intended to also cover DataChannel uses of FEC then the draft should > have a new section after Section 5 with a Heading of "FEC for DataChannel > Content". > > /Barry Dingle > > > > On Sat, Feb 7, 2015 at 3:56 AM, wrote: > >> >> 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 : WebRTC Forward Error Correction Requirements >> Author : Justin Uberti >> Filename : draft-ietf-rtcweb-fec-00.txt >> Pages : 7 >> Date : 2015-02-05 >> >> Abstract: >> This document makes recommendations for how Forward Error Correction >> (FEC) should be used by WebRTC applications. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00 >> >> >> 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 > > --001a113ec9282637e4050e8d9e63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting point. I don't think the WG has really dis= cussed data FEC in detail yet, so your title suggestion makes sense to me.<= /div>

On Sat, Feb = 7, 2015 at 5:44 PM, Barry Dingle <btdingle@gmail.com> wrote= :
The new &quo= t;WebRTC Forward Error Correction Requirements" draft refers solely to= 'media' FEC requirements.

It does not refer to non-m= edia (or DataChannel) uses of FEC.

If this draft is intended = to concentrate on the media FEC requirements, then the Title should be chan= ged to reflect that, namely:

"WebRTC Media Forward Error Correction Requirements&quo= t;,

If it intended to also cover Da= taChannel uses of FEC then the draft should have a new section after Sectio= n 5 with a Heading of "FEC for DataChannel Content".
=C2=A0
/Barry Dingle



On Sat, Feb 7, 2015 at 3:56 AM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-02-05

Abstract:
=C2=A0 =C2=A0This document makes recommendations for how Forward Error Corr= ection
=C2=A0 =C2=A0(FEC) should be used by WebRTC applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-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/

_______________________________________________
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


--001a113ec9282637e4050e8d9e63-- From nobody Sun Feb 8 04:47:08 2015 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 092271A8ABD for ; Sun, 8 Feb 2015 04:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHKptiP5AYVL for ; Sun, 8 Feb 2015 04:47:03 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64221A8ABB for ; Sun, 8 Feb 2015 04:47:03 -0800 (PST) Received: from [192.168.2.76] (107-128-214-154.lightspeed.sntcca.sbcglobal.net [107.128.214.154]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9B9E6F262E for ; Sun, 8 Feb 2015 04:47:02 -0800 (PST) Message-ID: <54D75AC5.4070202@mozilla.com> Date: Sun, 08 Feb 2015 04:47:01 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Sun, 08 Feb 2015 12:47:06 -0000 Justin Uberti wrote: > Interesting point. I don't think the WG has really discussed data FEC in > detail yet, so your title suggestion makes sense to me. Wouldn't we just use SCTP retransmissions? Something more sophisticated than that seems like it would require application knowledge, so it should probably be handled at the application layer. From nobody Sun Feb 8 05:11:09 2015 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 AE61F1A8AEB for ; Sun, 8 Feb 2015 05:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OjDXmwZ9pim for ; Sun, 8 Feb 2015 05:11:04 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4ED1A8AE9 for ; Sun, 8 Feb 2015 05:11:04 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so25278771lbj.0 for ; Sun, 08 Feb 2015 05:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=GsoBHze1wz2Af1Czz2/TY6MONdcUtzGvDommr2D6r1c=; b=Bch9eBMUW2SkuEN9WL8lL6/8JWlC9qedu3ABZS9lE3htlVTPdHFBKu/qooLyDmXRQ1 RKBx03yaj6fuiprPjQj4Ncrv3WDD5W/ptPHF7x7+YXivfuztfX1fCHGHrXuNvU3d7vNK qfc5EBAS+xjhqn4rqDNzu761s3HD2X66aZzkFzH3TnNoc+c2f51ufbHohyAHvhPPmE02 28RShmrA1If+NCgfbdNEqTU0K6AFu6kwIQuYrZywjVbv6P+QwgJTNz1TVh/eNJNZs+r4 Ki6e0s5S6ycyqI1WqJuOEPuZPoDzezBV8UTkUWq8S3DqydkwxR21NGbuVAUwxLLtg6ww VOhg== X-Received: by 10.152.10.238 with SMTP id l14mr11746222lab.68.1423401062872; Sun, 08 Feb 2015 05:11:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.88.79 with HTTP; Sun, 8 Feb 2015 05:10:41 -0800 (PST) In-Reply-To: <54D75AC5.4070202@mozilla.com> References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> <54D75AC5.4070202@mozilla.com> From: Barry Dingle Date: Mon, 9 Feb 2015 00:10:41 +1100 Message-ID: To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11333d46b9be17050e936267 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Sun, 08 Feb 2015 13:11:07 -0000 --001a11333d46b9be17050e936267 Content-Type: text/plain; charset=UTF-8 Justin Uberti wrote: > Interesting point. I don't think the WG has really discussed data FEC in >> detail yet, so your title suggestion makes sense to me. >> > > Wouldn't we just use SCTP retransmissions? Something more sophisticated > than that seems like it would require application knowledge, so it should > probably be handled at the application layer. > > For non-realtime data - Yes. For realtime data applications - such as realtime text - with low delay requirements from text entry a Sender to display at Receiver, you often need FEC particularly on wireless connections. /Barry Dingle --001a11333d46b9be17050e936267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin Uberti wrote:
Interesting point. I don't think the WG has really discussed data FEC i= n
detail yet, so your title suggestion makes sense to me.

 Wouldn't we just use SCTP retransmissions? Something more sophisticated= than that seems like it would require application knowledge, so it should = probably be handled at the application layer.

For non-realtime data - Yes.

<= div class=3D"gmail_extra">For realtime data applications - such as realtime= text - with low delay requirements from text entry a Sender to display at = Receiver, you often need FEC particularly on wireless connections.

=
/Barry Dingle
--001a11333d46b9be17050e936267-- From nobody Sun Feb 8 06:54:25 2015 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 61CDA1A90A1 for ; Sun, 8 Feb 2015 06:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQWecEIW98WI for ; Sun, 8 Feb 2015 06:54:22 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5DB1A90C3 for ; Sun, 8 Feb 2015 06:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4016; q=dns/txt; s=iport; t=1423407262; x=1424616862; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gXm6wCRVTXxrdQXH+v6FamUDGJZBLhsdLwJgXTJHhps=; b=JkYalDhVqQ22Ol1EfMlMVZnnqDbWc+FNqBTzN4Z/uPKMJu3Ig1sdwHdt z50FKhxaMTl/cVedKVjGT7ioR9Q7DT9WEcpFzQithl8gYMAlBXKr4XyGz X+2X3moygw3r/IwcgyZdicedXw0krTmBFFA7yLharXt0Pjf/V5WNJH4Ww s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAPl311StJV2U/2dsb2JhbABcgwZSWsJwAQmFJ0oCgQ9DAQEBAQEBfIQNAQEEAQEBawsQAgEIBAoxByEGCxQRAgQOBYgZAxENwisNhWUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI1OgiYEB4MWgRQFjxuHZoFGgRiLWIJCgz4ig25vgkIBAQE X-IronPort-AV: E=Sophos;i="5.09,539,1418083200"; d="scan'208,217";a="394764914" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 08 Feb 2015 14:54:21 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t18EsLqk004821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Feb 2015 14:54:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Sun, 8 Feb 2015 08:54:21 -0600 From: "Mo Zanaty (mzanaty)" To: Barry Dingle Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-00.txt Thread-Index: AQHQQ0DfKBCtXiiMSE+NLbCHi2PYWJzmq/+AgABsvoCAAAadgP//uGI5 Date: Sun, 8 Feb 2015 14:54:21 +0000 Message-ID: <1F482390-7831-4A72-8B5D-2A11B8A01CA6@cisco.com> References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> <54D75AC5.4070202@mozilla.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1F48239078314A728B5D2A11B8A01CA6ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Sun, 08 Feb 2015 14:54:24 -0000 --_000_1F48239078314A728B5D2A11B8A01CA6ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Media FEC is necessary within WebRTC internals because apps have no access = to the RTP media. Apps obviously have full access to data channel messages,= as well as reliability settings, so app layer FEC is always possible. It m= ay be useful to extend SCTP reliability settings with FEC options, but that= would need new tsvwg work before any rtcweb work. I would not support norm= ative dependencies on such work in this draft, although I would support the= new work. Mo On Feb 8, 2015, at 8:11 AM, "Barry Dingle" > wrote: Justin Uberti wrote: Interesting point. I don't think the WG has really discussed data FEC in detail yet, so your title suggestion makes sense to me. Wouldn't we just use SCTP retransmissions? Something more sophisticated tha= n that seems like it would require application knowledge, so it should prob= ably be handled at the application layer. For non-realtime data - Yes. For realtime data applications - such as realtime text - with low delay req= uirements from text entry a Sender to display at Receiver, you often need F= EC particularly on wireless connections. /Barry Dingle _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_1F48239078314A728B5D2A11B8A01CA6ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Media FEC is necessary within WebRTC internals because apps have no ac= cess to the RTP media. Apps obviously have full access to data channel mess= ages, as well as reliability settings, so app layer FEC is always possible.= It may be useful to extend SCTP reliability settings with FEC options, but that would need new tsvwg work = before any rtcweb work. I would not support normative dependencies on such = work in this draft, although I would support the new work. 

Mo

On Feb 8, 2015, at 8:11 AM, "Barry Dingle" <btdingle@gmail.com> wrote:

Justin Uberti wrote:
Interesting point. I don't think the WG has really discussed data FEC in detail yet, so your title suggestion makes sense to me.

Wouldn't we just use SCTP retransmissions? Something more sophistica= ted than that seems like it would require application knowledge, so it shou= ld probably be handled at the application layer.

For non-realtime data - Yes.

For realtime data applications - such as realtim= e text - with low delay requirements from text entry a Sender to display at= Receiver, you often need FEC particularly on wireless connections.

/Barry Dingle
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_1F48239078314A728B5D2A11B8A01CA6ciscocom_-- From nobody Mon Feb 9 03:22:05 2015 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 D05D41A02BE; Mon, 9 Feb 2015 03:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yjmpCf-h5jr; Mon, 9 Feb 2015 03:19:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 273B41A026F; Mon, 9 Feb 2015 03:19:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209111918.2334.99409.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 03:19:18 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-22.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: Mon, 09 Feb 2015 11:19:21 -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 : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-22.txt Pages : 45 Date : 2015-02-09 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 9 03:23:47 2015 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 6F1CC1A0123 for ; Mon, 9 Feb 2015 03:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvdBP2p7a1vq for ; Mon, 9 Feb 2015 03:23:43 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0C01A026F for ; Mon, 9 Feb 2015 03:23:43 -0800 (PST) Received: from [130.209.247.112] (port=56591 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YKmRE-0000bY-Bs for rtcweb@ietf.org; Mon, 09 Feb 2015 11:23:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <20150209111918.2334.99409.idtracker@ietfa.amsl.com> Date: Mon, 9 Feb 2015 11:23:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3B985347-E291-42BF-AB3E-2F253243261C@csperkins.org> References: <20150209111918.2334.99409.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-22.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, 09 Feb 2015 11:23:45 -0000 This version changes the reference to draft-uberti-rtcweb-fec to a = reference to draft-ietf-rtcweb-fec.=20 Colin On 9 Feb 2015, at 11:19, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Authors : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-22.txt > Pages : 45 > Date : 2015-02-09 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-22 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-22 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ From nobody Wed Feb 11 09:02:43 2015 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 5F1661A89AF for ; Wed, 11 Feb 2015 09:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 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, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIJUWDB0WoqV for ; Wed, 11 Feb 2015 09:02:40 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D7F1A89A7 for ; Wed, 11 Feb 2015 09:01:59 -0800 (PST) Received: by iecar1 with SMTP id ar1so5499264iec.0 for ; Wed, 11 Feb 2015 09:01:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dcvRKjXjvnnONHLNHAqJN1DBVbCX8cVj/PBBSoMKVGU=; b=aGRmDtkzHQ/TIhuB/QE5wEgIE2g1zrz6ga9XLmaTRmrJRFt89jLRVaJojfoo3EnfGX dgN488mi1PCGTXNHU6t23+jZU5l473vfjsOM6vtAAk8Yg6LdlR+zoxgPy/icERxHbWbr WgNwi60XM/qUYno9W2v4L2K2UOGmvPNQTqpfDHaeKjstnehNAPmuWAhdctVzt22AzSIc iYYHyVBDZpF0xBJOGUTd2VWHKbHtKlkC8x6dK2xpMIipj6u9Dzo+P8dx4hCPsteZRUbJ fYD/fzsELOigcl7VhCyrGt+0auX+z4jZKFyrIJ7PZCUg56wDL+ftosZ1X9eBkpwlYRjx s3GA== X-Gm-Message-State: ALoCoQkQkQc0spa1CvM+n4mzR+PLG/iw5c8p+KdOYiFVABjUAIwyGMiEc6ULK+YR2j6HyduzEDLj MIME-Version: 1.0 X-Received: by 10.107.162.7 with SMTP id l7mr21775215ioe.20.1423674119225; Wed, 11 Feb 2015 09:01:59 -0800 (PST) Received: by 10.64.169.38 with HTTP; Wed, 11 Feb 2015 09:01:59 -0800 (PST) In-Reply-To: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 09:01:59 -0800 Message-ID: From: Jozsef Vass To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a1140e638271f51050ed2f615 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Wed, 11 Feb 2015 17:02:42 -0000 --001a1140e638271f51050ed2f615 Content-Type: text/plain; charset=UTF-8 I just wondering what kind of FEC is recommended (or will be supported) for G.711. The draft does not recommend neither redundant encoding nor a separate FEC stream. Jozsef Jozsef Vass SDK Engineering [image: twilio] MOBILE(415) 216-6603EMAILjvass@twilio.com SIGNAL: The modern communications conference May 19/20 2015, Fort Mason Festival Pavilion, SF, CA On Fri, Feb 6, 2015 at 8:56 AM, wrote: > > 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 : WebRTC Forward Error Correction Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-fec-00.txt > Pages : 7 > Date : 2015-02-05 > > Abstract: > This document makes recommendations for how Forward Error Correction > (FEC) should be used by WebRTC applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00 > > > 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 > --001a1140e638271f51050ed2f615 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just wondering what kind of FEC is recommended (or will = be supported) for G.711. The draft does not recommend neither redundant enc= oding nor a separate FEC stream.

Jozsef


On Fri, Feb 6, 2015 at 8:56 AM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-02-05

Abstract:
=C2=A0 =C2=A0This document makes recommendations for how Forward Error Corr= ection
=C2=A0 =C2=A0(FEC) should be used by WebRTC applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-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/

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

--001a1140e638271f51050ed2f615-- From nobody Wed Feb 11 11:39:24 2015 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 451581A8ACA for ; Wed, 11 Feb 2015 11:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3HsD5wUmxxW for ; Wed, 11 Feb 2015 11:39:19 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA01D1A036A for ; Wed, 11 Feb 2015 11:39:18 -0800 (PST) Received: by labpv20 with SMTP id pv20so5563692lab.8 for ; Wed, 11 Feb 2015 11:39:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j/Jr+boOwMyYFoNjWFw2W1lNmUDrVZ/aeLaagTTbTWI=; b=Ug7tUCq1km6Ar+4lboJhJ5NSnuxHJ6oeiLcur/vnQlGgvYnSTonZVMKSuBZ7KeQFPC WPjva+moiYyplbnsnE36fOEMgwjF0mwn0GsSnpzqdJr1mQkz+Lyo4L22FJnnrfQeT0sf J8bG4r/3GnjcEFx8ibayUzE6/7uOmSbNFAM79ep6SfcE4ptdAbQnk25lX7b82EfFp8L3 u2ZWSMuoyQCxUQGw+iyItN6MevU9cEEV0VZOHH3d4tmlx8tB8vOlR6Y3T+lXXddGC0Kj QAV7FKHVCyQuiPoXBeLGXzfgTGOngmufuus9jsh8ng4gq3MXom4tR4Ht4VZ34/lZEvHF cFtA== X-Gm-Message-State: ALoCoQnZoSFUTOb/CI0kmCkIZ2m3DzfMsJhZx4pZDg6LHz0PhkFdepxrjAQC0S+jKNSBMaYl6csR MIME-Version: 1.0 X-Received: by 10.112.155.168 with SMTP id vx8mr179345lbb.110.1423683557243; Wed, 11 Feb 2015 11:39:17 -0800 (PST) Received: by 10.25.205.135 with HTTP; Wed, 11 Feb 2015 11:39:17 -0800 (PST) In-Reply-To: References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 14:39:17 -0500 Message-ID: From: Simon Perreault To: Jozsef Vass Content-Type: multipart/alternative; boundary=089e01176fa1b3d397050ed5289d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Wed, 11 Feb 2015 19:39:21 -0000 --089e01176fa1b3d397050ed5289d Content-Type: text/plain; charset=UTF-8 On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass wrote: > I just wondering what kind of FEC is recommended (or will be supported) > for G.711. The draft does not recommend neither redundant encoding nor a > separate FEC stream. Isn't this what you're looking for? 3.1 . Separate FEC Stream This approach, as described in [RFC5956], Section 4.3 , sends FEC packets as an independent SSRC-multiplexed stream, with its own SSRC and payload type. While by far the most flexible, each FEC packet will have its own IP+UDP+RTP+FEC header, leading to additional overhead of the FEC stream. Simon --089e01176fa1b3d397050ed5289d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass <jvass@twilio.com> wrote:
I just wondering what kind of FEC is recomme= nded (or will be supported) for G.711. The draft does not recommend neither= redundant encoding nor a separate FEC stream.

<= div>Isn't this what you're looking for?=C2=A0

3.1.  Separate FEC Stream


   This approach, as described in [RFC5956], Section=C2=A04.3, sends FEC
   packets as an independent SSRC-multiplexed stream, with its own SSRC
   and payload type.  While by far the most flexible, each FEC packet
   will have its own IP+UDP+RTP+FEC header, leading to additional
   overhead of the FEC stream.

Simon
--089e01176fa1b3d397050ed5289d-- From nobody Wed Feb 11 11:45:01 2015 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 74AE31A1B28 for ; Wed, 11 Feb 2015 11:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 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, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHHvUUR1Q1R7 for ; Wed, 11 Feb 2015 11:44:54 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCD71A024E for ; Wed, 11 Feb 2015 11:44:54 -0800 (PST) Received: by iecrp18 with SMTP id rp18so6606427iec.7 for ; Wed, 11 Feb 2015 11:44:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2lcefM+gf+k/+0BW47B7SzYLI1HjstkgOBZmX5c67es=; b=O55aNPGFthveRgc9JF4rU2HYzDNLKJ32NRH+C00HTnPpNhdsLJOMe3dVirZ7n79cPL YVRGalnkj08Y0Hsc7iCOxxU7XP/Xl9bHijcZ3iHEkxrmMwgehkelf+t2TX7iNxa+XhWZ HtQ5Lf/v+1+5/dZQ9f1WyY1qt82YkLZN2qoBGUYW8FjM+2wULvVuDG4qXhma/mT0TeKV ZxRwvzvjAvpWXV8TOL2Bv+8QDwUb4itv0iZa5oPup9R1cqv+tuji+l5jchtQa8Byz+8A z2RKaNNlwcvh0mVBRDv2/jezqC8KKTPrGoaqikWPcd6vJTknfmDFWOi9yN3Q7hgnfsSq Lj4A== X-Gm-Message-State: ALoCoQlh8V66ASe6A0kCRHQ88GTTlEqJCS9sXEKgKPzyAmcaHGiGgOd3DZBJZafFg63ve3pJrBY0 MIME-Version: 1.0 X-Received: by 10.50.28.8 with SMTP id x8mr5752894igg.19.1423683893986; Wed, 11 Feb 2015 11:44:53 -0800 (PST) Received: by 10.64.240.69 with HTTP; Wed, 11 Feb 2015 11:44:53 -0800 (PST) In-Reply-To: References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 11:44:53 -0800 Message-ID: From: Jozsef Vass To: Simon Perreault Content-Type: multipart/alternative; boundary=089e015386d6c62995050ed53c4f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Wed, 11 Feb 2015 19:44:58 -0000 --089e015386d6c62995050ed53c4f Content-Type: text/plain; charset=UTF-8 Later, in 4.1 Recommended Mechanisms: When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198 ] redundant encoding is NOT RECOMMENDED, as this will result in a potentially significant bitrate increase. Furthermore, suddenly increasing the bitrate to deal with packet losses may actually make things worse. Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED. So what is recommended for PCMU? Jozsef Jozsef Vass SDK Engineering [image: twilio] MOBILE(415) 216-6603EMAILjvass@twilio.com SIGNAL: The modern communications conference May 19/20 2015, Fort Mason Festival Pavilion, SF, CA On Wed, Feb 11, 2015 at 11:39 AM, Simon Perreault wrote: > > On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass wrote: > >> I just wondering what kind of FEC is recommended (or will be supported) >> for G.711. The draft does not recommend neither redundant encoding nor a >> separate FEC stream. > > > Isn't this what you're looking for? > > 3.1 . Separate FEC Stream > > This approach, as described in [RFC5956], Section 4.3 , sends FEC > packets as an independent SSRC-multiplexed stream, with its own SSRC > and payload type. While by far the most flexible, each FEC packet > will have its own IP+UDP+RTP+FEC header, leading to additional > overhead of the FEC stream. > > > Simon > --089e015386d6c62995050ed53c4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Later, in 4.1 Recommended Mechanisms:

<= pre class=3D"" style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;colo= r:rgb(0,0,0)"> When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198] redundant encoding is NOT RECOMMENDED, as this will result in a potentially significant bitrate increase. Furthermore, suddenly increasing the bitrate to deal with packet losses may actually make things worse. Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED.<= div>
So what is recommended for PCMU?

Jozsef


Jozsef Vass=
SDK E= ngineering
3D"twilio"
= <= td style=3D"padding:0px;font-size:12px">jvass@twilio.com
MOBILE(415) 216-6603
EMAIL
=

On Wed, Feb 11, 2015 at 11:39 AM, Simon Perr= eault <sperreault@jive.com> wrote:

On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass <jvass@twilio.c= om> wrote:
I just wondering what kind of = FEC is recommended (or will be supported) for G.711. The draft does not rec= ommend neither redundant encoding nor a separate FEC stream.

Isn't this what you're looking for?=C2=A0

<=
a name=3D"14b7a271b939f06e_section-3.1" href=3D"http://tools.ietf.org/html/=
draft-ietf-rtcweb-fec-00#section-3.1" style=3D"color:black;text-decoration:=
none" target=3D"_blank">3.1.  Separate FEC Stream


   This approach, as described in [RFC5956], Section=C2=A04.3, sends =
FEC
   packets as an independent SSRC-multiplexed stream, with its own SSRC
   and payload type.  While by far the most flexible, each FEC packet
   will have its own IP+UDP+RTP+FEC header, leading to additional
   overhead of the FEC stream.

Simon

--089e015386d6c62995050ed53c4f-- From nobody Wed Feb 11 23:56:11 2015 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 BAE7C1A1B74 for ; Wed, 11 Feb 2015 23:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 mB20-lr8lLQC for ; Wed, 11 Feb 2015 23:56:05 -0800 (PST) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B850F1A0399 for ; Wed, 11 Feb 2015 23:56:05 -0800 (PST) Received: by pdjg10 with SMTP id g10so10343791pdj.1 for ; Wed, 11 Feb 2015 23:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=JiFOQJfK5m64GISM3+Px/iVPS/VSztBPhMZB6gaNxNk=; b=alO5D8y1Q74wfKi2TAAfY7vOBThS8vQ+fpUZkMK8ucAfWFarz42V7DRtEoKwwx6MHm zwWSlmL5Ncqgr0nyU06TO7XORXTbRrvlZ5aVGRSvHr0JuGH+GEaCqDFNLwpYbqckcuZZ PugqCYtLDGDpHZcwrcmYRjvmAvrM5H6GDd88crJwOOHGDt6aGUK2bBnNLQeycSGNP47F U4SGMmW6nTCgYLh4kPkVmDOgYDLGshEk5G7WeJU5pvLaN9vN5cuIPyPOkEpd/BvwUsw5 /g49SB9BEKOLnQPU2cw7JwxcJNAzj4LtAZgOb8hHbpxCZzDymgj7I6KLoriXAJzOQ54s yDXQ== MIME-Version: 1.0 X-Received: by 10.70.43.236 with SMTP id z12mr4637896pdl.22.1423727765454; Wed, 11 Feb 2015 23:56:05 -0800 (PST) Received: by 10.70.47.37 with HTTP; Wed, 11 Feb 2015 23:56:05 -0800 (PST) Date: Wed, 11 Feb 2015 23:56:05 -0800 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfeb34cb7836a050edf73de Archived-At: Cc: Cullen Jennings Subject: [rtcweb] RTCWeb SDP Examples Draft 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 Feb 2015 07:56:09 -0000 --047d7bfeb34cb7836a050edf73de Content-Type: text/plain; charset=UTF-8 Hello All We are looking to get feedback/thoughts on the RTCWeb Examples draft. Draft Location: http://tools.ietf.org/id/draft-nandakumar-rtcweb-sdp-07.html (HTML version is more easier to read) Below is the list of examples currently covered in this draft 5.2. Basic Examples . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Audio Only Session . . . . . . . . . . . . . . . . . 8 5.2.2. Audio/Video Session . . . . . . . . . . . . . . . . . 11 5.2.3. Data Only Session . . . . . . . . . . . . . . . . . . 16 5.2.4. Audio Call On Hold . . . . . . . . . . . . . . . . . 19 5.2.5. Audio with DTMF Session . . . . . . . . . . . . . . . 23 5.2.6. One Way Audio/Video Session - Document Camera . . . . 27 5.2.7. Audio, Video Session with BUNDLE Support Unknown . . 31 5.2.8. Audio, Video and Data Session . . . . . . . . . . . . 38 5.2.9. Audio, Video Session with BUNDLE Unsupported . . . . 43 5.2.10. Audio, Video BUNDLED, but Data (Not BUNDLED) . . . . 47 5.2.11. Audio Only, Add Video to BUNDLE . . . . . . . . . . . 52 5.3. MultiResolution, RTX, FEC Examples . . . . . . . . . . . 59 5.3.1. Sendonly Simulcast Session with 2 cameras and 2 encodings per camera . . . . . . . . . . . . . . 59 5.3.2. Successful SVC Video Session . . . . . . . . . . . . 65 5.3.3. Successful Simulcast Video Session with Retransmission . . . . . . . . . . . . . . . . . . . 70 5.3.4. Successful 1-way Simulcast Sessio with 2 resolutions and RTX - One resolution rejected . . . . . . 74 5.3.5. Simulcast Video Session with Forward Error Correction 79 5.4. Others . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.4.1. Audio Session - Voice Activity Detection . . . . . . 83 5.4.2. Audio Conference - Voice Activity Detection . . . . . 86 5.4.3. Successful legacy Interop Fallaback with bundle-only 90 Given that it is quite impossible to cover all the possible combinations of the use-cases , we would like to get the group's inputs on the following: - Do the examples capture the breadth of common RTCWeb use-cases ? - Are the examples clear enough in terms of text and SDP provided ? - Any new examples/use-cases that would be worthy of adding to the existing draft ? - Is this draft helpful in meeting its said objective of Information document ? Look forward for the feedback. Thanks in Advance Suhas --047d7bfeb34cb7836a050edf73de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 We are looking to get = feedback/thoughts on the RTCWeb Examples draft.

=C2=A0 =C2=A0(HTML version is more easier to rea= d)

Below is the list of examples currently covered= in this draft=C2=A0
5.2.  =
Basic Examples  . . . . . . . . . . . . . . . . . . . . .   8
       5.2.1.  Audio Only Session  . . . . . . . . . . . . . . . . .   8
       5.2.2.  Audio/Video Session . . . . . . . . . . . . . . . . .  11
       5.2.3.  Data Only Session . . . . . . . . . . . . . . . . . .  16
       5.2.4.  Audio Call On Hold  . . . . . . . . . . . . . . . . .  19
       5.2.5.  Audio with DTMF Session . . . . . . . . . . . . . . .  23
       5.2.6.  One Way Audio/Video Session - Document Camera . . . .  27
       5.2.7.  Audio, Video Session with BUNDLE Support Unknown  . .  31
       5.2.8.  Audio, Video and Data Session . . . . . . . . . . . .  38
       5.2.9.  Audio, Video Session with BUNDLE Unsupported  . . . .  43
       5.2.10. Audio, Video BUNDLED, but Data (Not BUNDLED)  . . . .  47
       5.2.11. Audio Only, Add Video to BUNDLE . . . . . . . . . . .  52
5.3.  MultiResolution, RTX, FEC Examples  . . . . . . . . . . .  59
       5.3.1.  Sendonly Simulcast Session with 2 cameras and 2
               encodings     per camera  . . . . . . . . . . . . . .  59
       5.3.2.  Successful SVC Video Session  . . . . . . . . . . . .  65
       5.3.3.  Successful Simulcast Video Session with
               Retransmission  . . . . . . . . . . . . . . . . . . .  70
       5.3.4.  Successful 1-way Simulcast Sessio with 2 resolutions
               and         RTX - One resolution rejected . . . . . .  74
       5.3.5.  Simulcast Video Session with Forward Error Correction  79
5.4.  Others  . . . . . . . . . . . . . . . . . . . . . . . . .  83
       5.4.1.  Audio Session - Voice Activity Detection  . . . . . .  83
       5.4.2.  Audio Conference - Voice Activity Detection . . . . .  86
       5.4.3.  Successful legacy Interop Fallaback with bundle-only   90


Given that it is qu= ite impossible to cover all the possible combinations of the use-cases , we= would like to get the group's inputs on the following:

<= /div>
=C2=A0 =C2=A0- Do the examples capture the breadth of common RTCW= eb use-cases ?
=C2=A0 =C2=A0- Are the examples clear enough i= n terms of text and SDP provided ?
=C2=A0 =C2=A0- Any new example= s/use-cases that would be worthy of adding to the existing draft ?
=C2=A0 =C2=A0- Is this draft helpful in meeting its said objective of Inf= ormation document ?


Look forward fo= r the feedback.

Thanks in Advance
Suhas<= br>
=C2=A0=C2=A0
--047d7bfeb34cb7836a050edf73de-- From nobody Thu Feb 12 04:17:29 2015 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 D06E71A1B8C for ; Thu, 12 Feb 2015 04:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjrY0u-grXCI for ; Thu, 12 Feb 2015 04:17:23 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9845B1A1A8D for ; Thu, 12 Feb 2015 04:17:22 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-65-54dc99d07b48 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6E.16.04484.0D99CD45; Thu, 12 Feb 2015 13:17:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Thu, 12 Feb 2015 13:17:20 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: SCTP-SDP and BUNDLE Thread-Index: AdBGu+eqdKtuZ6RBSQWtWK8MlDLQJwAAbeqQ Date: Thu, 12 Feb 2015 12:17:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CFDFD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6CFD36@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6CFD36@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6CFDFDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje6FmXdCDI7sV7VY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGWu+XGMsWKRXsfvbHLYGxmbNLkZODgkBE4n2n0fYIGwxiQv3 1gPZXBxCAkcYJf6fncAE4SxhlNjVvQTI4eBgE7CQ6P6nDdIgIqAucfnhBXYQW1hAQWLS5T1s ICUiAooSMw/JQpQYSTRuPMMIYrMIqEqcufaUCcTmFfCVuHVjLiuILQRkf1jexQxicwr4SUw6 cQPsHkage76fWgNWzywgLnHryXwmiDsFJJbsOc8MYYtKvHz8jxXCVpTYebadGaI+X2Lj59ns ELsEJU7OfMIygVFkFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2Vcxihan FiflphsZ6aUWZSYXF+fn6eWllmxiBEbQwS2/DXYwvnzueIhRgINRiYe3wP9OiBBrYllxZe4h RmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGJnj1RepKTzocwnddevY6ny5 gsDrv9a+tO1LseIteXu+57fEhnfv5m2cZqD1ak2X5Yrl79NuOS/KjD66/kLg7x+fltfrXD3A f8LqLo8wh3Xopo2a77xPnA3RYznPOWNb8trQ/y+Z105KLdvLkZ0q9Xkv47kn9bc+H4mO5zb3 5IzqX2ArWNumNluJpTgj0VCLuag4EQBnEiwVgQIAAA== Archived-At: Subject: [rtcweb] FW: SCTP-SDP and BUNDLE 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 Feb 2015 12:17:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6CFDFDESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I sent this to the MMUSIC list, but it may also be in interest to the RTCWE= B community. If you have any opinions regarding this, please post them on the MMUSIC lis= t. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 12. helmikuuta 2015 14:15 To: mmusic@ietf.org Subject: [MMUSIC] SCTP-SDP and BUNDLE Hi, We may have discussed this before, but I'd like to verify. According to the SCTP RFC, there can only be one SCTP association between t= wo SCTP endpoints. I ASSUME that applies also to DTLS/SCTP and SCTP/DTLS. If so, I would expli= citly indicate that in the SCTP-SDP draft, as I have been asked to add a "B= UNDLE considerations" section. Regards, Chrsiter --_000_7594FB04B1934943A5C02806D1A2204B1D6CFDFDESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

I sent = this to the MMUSIC list, but it may also be in interest to the RTCWEB commu= nity.

&n= bsp;

If you = have any opinions regarding this, please post them on the MMUSIC list.=

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

mmusi= c [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 12. helmikuuta 2015 14:15
To: mmusic@ietf.org
Subject: [MMUSIC] SCTP-SDP and BUNDLE

 

Hi,

 

We may have discussed this befo= re, but I’d like to verify.

 

According to the SCTP RFC, ther= e can only be one SCTP association between two SCTP endpoints.

 

I ASSUME that applies also to D= TLS/SCTP and SCTP/DTLS. If so, I would explicitly indicate that in the SCTP= -SDP draft, as I have been asked to add a “BUNDLE considerations̶= 1; section.

 

Regards,

 

Chrsiter

--_000_7594FB04B1934943A5C02806D1A2204B1D6CFDFDESESSMB209erics_-- From nobody Thu Feb 12 12:43:58 2015 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 0411E1A6F10 for ; Thu, 12 Feb 2015 12:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS7rV_NnhcnN for ; Thu, 12 Feb 2015 12:43:55 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B2C1A0250 for ; Thu, 12 Feb 2015 12:43:55 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1CKhsgP031101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Feb 2015 14:43:55 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DD108A.3090906@nostrum.com> Date: Thu, 12 Feb 2015 14:43:54 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Video Open issue #1: Color space 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 Feb 2015 20:43:57 -0000 Based on a lack of objection, I will be removing the "TODO" from the color space statement in section 3 of draft-ietf-rtcweb-video. I am also incorporating the suggestion to reference the ISO/IEC definition of media description code points for additional clarity. The revised text reads: Unless specified otherwise by the SDP or codec, the color space SHOULD be sRGB [SRGB]. For clarity, this the color space indicated by codepoint 1 from "ColourPrimaries" as defined in [IEC23001-8]. I am removing this from my list of open issues. /a From nobody Thu Feb 12 12:48:58 2015 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 4E3951A6FF0 for ; Thu, 12 Feb 2015 12:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TSBANMeCzLd for ; Thu, 12 Feb 2015 12:48:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5B11A6F10 for ; Thu, 12 Feb 2015 12:48:55 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1CKms3q031486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Feb 2015 14:48:55 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DD11B6.8060201@nostrum.com> Date: Thu, 12 Feb 2015 14:48:54 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Video Open issue #4: VP8 filters 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 Feb 2015 20:48:57 -0000 In Toronto, there was a claim that specification that "bilinear" and "none" filters is superfluous, as they are already required as part of the VP8 spec. Since that time, I have repeatedly asked for a concrete pointer to the text that would make this unnecessary. No one has come forth with such a pointer. Given the harmless nature of redundantly specifying this requirement on implementations and the lack of concrete evidence for its removal, I am leaving the text as-is and removing the open issue from my list. /a From nobody Thu Feb 12 13:00:54 2015 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 458D71A6F20 for ; Thu, 12 Feb 2015 13:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yT82M8PagCH for ; Thu, 12 Feb 2015 13:00:49 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C34A71A026E for ; Thu, 12 Feb 2015 13:00:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 571C97C3F6F for ; Thu, 12 Feb 2015 22:00:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3Z2jZWKM5os for ; Thu, 12 Feb 2015 22:00:46 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:298c:a872:c88:f863]) by mork.alvestrand.no (Postfix) with ESMTPSA id 494F17C3F64 for ; Thu, 12 Feb 2015 22:00:46 +0100 (CET) Message-ID: <54DD147D.504@alvestrand.no> Date: Thu, 12 Feb 2015 22:00:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54DD11B6.8060201@nostrum.com> In-Reply-To: <54DD11B6.8060201@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Video Open issue #4: VP8 filters 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 Feb 2015 21:00:53 -0000 On 02/12/2015 09:48 PM, Adam Roach wrote: > In Toronto, there was a claim that specification that "bilinear" and > "none" filters is superfluous, as they are already required as part of > the VP8 spec. Since that time, I have repeatedly asked for a concrete > pointer to the text that would make this unnecessary. > > No one has come forth with such a pointer. Given the harmless nature > of redundantly specifying this requirement on implementations and the > lack of concrete evidence for its removal, I am leaving the text as-is > and removing the open issue from my list. Please. This is not harmless. The text under consideration is 6.1. VP8 For the VP8 codec, defined in [RFC6386], endpoints MUST support the payload formats defined in [I-D.ietf-payload-vp8]. In addition they MUST support the 'bilinear' and 'none' reconstruction filters. The problem with the text is not that it specifies that one MUST support the "bilinear" and "none" filters. The problem with the text is that in order for it to make any sense at all, one must believe that you can be conformant with RFC 6386 without the ability to decode all the specified reconstruction filters - that is, in order for the second sentence to make any sense at all, one must believe that filters are optional. There is no hint in any place in RFC 6386 that a conformant decoder can be conformant without the ability to decode bitstreams using all the filter types. Filters are not optional for the decoder. This is the point I'm objecting to. Harald From nobody Thu Feb 12 13:06:09 2015 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 76BB01A026E for ; Thu, 12 Feb 2015 13:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWVaxojh5Cbi for ; Thu, 12 Feb 2015 13:06:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F241A0AFE for ; Thu, 12 Feb 2015 13:05:58 -0800 (PST) Received: from netb ([82.113.121.96]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LoKHN-1Xg4Mc016X-00gExJ; Thu, 12 Feb 2015 22:05:55 +0100 From: Bjoern Hoehrmann To: Adam Roach Date: Thu, 12 Feb 2015 22:05:55 +0100 Message-ID: References: <54DD11B6.8060201@nostrum.com> In-Reply-To: <54DD11B6.8060201@nostrum.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:3DE9CxP4YxWo8Z5kLf5qskOD/zKZXN3KRnrGj+8M8VBTmdsmNXr NOF9jHQPFZEM7aFpw2rSjm4jSIL52/aGdiTovIiTGmwvoWf5dci90Qa4l8PicmcrN1ZL2/4 qmmDRAzma3b/qRemiqcRUDfZjijW5PSkCsYbmstF4nhAUbI6Ll5AopoqVRDUN2kCJ7fOW6e xNK+jvEKjfdEyrWo2Zj1w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Open issue #4: VP8 filters 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 Feb 2015 21:06:07 -0000 * Adam Roach wrote: >Given the harmless nature of redundantly specifying this requirement I do not see how that could be harmless, whatever the requirement. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Thu Feb 12 13:25:38 2015 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 9A2F41A1A39 for ; Thu, 12 Feb 2015 13:25:35 -0800 (PST) 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 j1CJRR4FRbSV for ; Thu, 12 Feb 2015 13:25:32 -0800 (PST) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C1B1A00FA for ; Thu, 12 Feb 2015 13:25:32 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id p10so12877692wes.2 for ; Thu, 12 Feb 2015 13:25:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9mDhofbhIdv552Trycwjj4kQpI2qpNZiOcbhrxkhip0=; b=DmUo0HeIstsjNUMS4unKLNvAnsKABgSjly+vH2b8FfMcXa+BPbrbl/z+JU6kiFmy9q Ux00uWQSvDK6rf1SotIBv/94xc39Hbh/97vM5TtNwqrYfR3gB+hEuy1xVj/e7df2ix3+ gcmHWcnJiFG5qeeiVQZMsZgVZKX8C8DJ95/lQ+0QnX4zbI7O/rzxrwg3dFZ4dVNqstMG mt0GmF8c3WTj+DX+RnGa3qmybtYZRHHYUa02Uau1oihnFmcnHSH7ucQWK8fBM9LmCmh7 DqwbEy/y3VMco4Ya19qmKh8BH8KUZKzFnXG5Nk/qnAHZ0Wn5AkrqTLPi0jqgVWI5kcyh Ip5g== X-Gm-Message-State: ALoCoQnVblz43HJpW9//iq3UnQZJf2SRvwQ2m/pcAPpWeTh0llmw2ojj75KTZgis91++008Zawax MIME-Version: 1.0 X-Received: by 10.194.171.136 with SMTP id au8mr12346981wjc.6.1423776330685; Thu, 12 Feb 2015 13:25:30 -0800 (PST) Received: by 10.194.14.129 with HTTP; Thu, 12 Feb 2015 13:25:30 -0800 (PST) In-Reply-To: <54DD147D.504@alvestrand.no> References: <54DD11B6.8060201@nostrum.com> <54DD147D.504@alvestrand.no> Date: Thu, 12 Feb 2015 23:25:30 +0200 Message-ID: From: Mohammed Raad To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e0122f58c6e3741050eeac275 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Open issue #4: VP8 filters 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 Feb 2015 21:25:35 -0000 --089e0122f58c6e3741050eeac275 Content-Type: text/plain; charset=UTF-8 Hi, Why not remove the second sentence? It clearly introduces an implied interpretation to RFC 6386 that is incorrect. Mohammed On Thu, Feb 12, 2015 at 11:00 PM, Harald Alvestrand wrote: > On 02/12/2015 09:48 PM, Adam Roach wrote: > >> In Toronto, there was a claim that specification that "bilinear" and >> "none" filters is superfluous, as they are already required as part of the >> VP8 spec. Since that time, I have repeatedly asked for a concrete pointer >> to the text that would make this unnecessary. >> >> No one has come forth with such a pointer. Given the harmless nature of >> redundantly specifying this requirement on implementations and the lack of >> concrete evidence for its removal, I am leaving the text as-is and removing >> the open issue from my list. >> > > Please. This is not harmless. > > The text under consideration is > > 6.1. VP8 > > For the VP8 codec, defined in [RFC6386], endpoints MUST support the > payload formats defined in [I-D.ietf-payload-vp8]. In addition they > MUST support the 'bilinear' and 'none' reconstruction filters. > > The problem with the text is not that it specifies that one MUST support > the "bilinear" and "none" filters. > > The problem with the text is that in order for it to make any sense at > all, one must believe that you can be conformant with RFC 6386 without the > ability to decode all the specified reconstruction filters - that is, in > order for the second sentence to make any sense at all, one must believe > that filters are optional. > > There is no hint in any place in RFC 6386 that a conformant decoder can be > conformant without the ability to decode bitstreams using all the filter > types. Filters are not optional for the decoder. > > This is the point I'm objecting to. > > Harald > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: mohammedsraad@raadtech.com --089e0122f58c6e3741050eeac275 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Why not remove the second sentence?= It clearly introduces an implied interpretation to RFC 6386 that is incorr= ect.

Mohammed

On Thu, Feb 12, 2015 at 11:00 PM, Harald A= lvestrand <harald@alvestrand.no> wrote:
On 02/12/2015 09:48 PM, Adam Roach wrote:=
In Toronto, there was a claim that specification that "bilinear" = and "none" filters is superfluous, as they are already required a= s part of the VP8 spec. Since that time, I have repeatedly asked for a conc= rete pointer to the text that would make this unnecessary.

No one has come forth with such a pointer. Given the harmless nature of red= undantly specifying this requirement on implementations and the lack of con= crete evidence for its removal, I am leaving the text as-is and removing th= e open issue from my list.

 Please. This is not harmless.

The text under consideration is

6.1.=C2=A0 VP8

=C2=A0 =C2=A0For the VP8 codec, defined in [RFC6386], endpoints MUST suppor= t the
=C2=A0 =C2=A0payload formats defined in [I-D.ietf-payload-vp8].=C2=A0 In ad= dition they
=C2=A0 =C2=A0MUST support the 'bilinear' and 'none' reconst= ruction filters.

The problem with the text is not that it specifies that one MUST support th= e "bilinear" and "none" filters.

The problem with the text is that in order for it to make any sense at all,= one must believe that you can be conformant with RFC 6386 without the abil= ity to decode all the specified reconstruction filters - that is, in order = for the second sentence to make any sense at all, one must believe that fil= ters are optional.

There is no hint in any place in RFC 6386 that a conformant decoder can be = conformant without the ability to decode bitstreams using all the filter ty= pes. Filters are not optional for the decoder.

This is the point I'm objecting to.

Harald


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



--
=
Mohammed Raad, PhD.
Partner
RAADTECH C= ONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 = 414451478
Email: mohammedsraad@raadtech.com
--089e0122f58c6e3741050eeac275-- From nobody Thu Feb 12 13:32:58 2015 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 B65BF1A1A9B for ; Thu, 12 Feb 2015 13:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2URDOsUVxnNB for ; Thu, 12 Feb 2015 13:32:52 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D18E1A1AA8 for ; Thu, 12 Feb 2015 13:32:52 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1CLWnuu034721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 15:32:51 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DD1C01.7000202@nostrum.com> Date: Thu, 12 Feb 2015 15:32:49 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------060006040601070408000906" Archived-At: Subject: [rtcweb] Stephan Wenger's Video Document Comments 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 Feb 2015 21:32:54 -0000 This is a multi-part message in MIME format. --------------060006040601070408000906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Splitting this off from the thread it was posted on for the sake of cleanliness. Thanks, Stefan, for the very useful feedback. I've incorporated it into the upcoming -04 version of the document as described below. On 11/25/14 23:16, Stephan Wenger wrote: > 1. Section 3: sRGB is fine. Done. > 2. Section 3: Add something like dynamic frame rate / frame interval based > on user locale, available bandwidth, and so on. For example, in low light > conditions, it almost never makes sense to run a full 30 fps camera when > your transport has only bandwidth for 15 fps. I think I follow what you're saying, but not 100% sure. What I've added is: * Dynamic frame rate for video capture based on actual encoding in use (e.g., if encoding at 15 fps due to bandwidth constraints, the camera will ideally capture at 15 fps rather than a higher rate). > 3. Section 3: Possibly missing: mention that the video scan pattern for > both VP8 and H.264 is YCrCb 4:2:0. Added: "Unless specified otherwise by the SDP or codec, the video scan pattern for video codecs is Y'CbCr 4:2:0". > 4. Section 3: Possibly missing: the screen content section should mention > that the scan format of video (YCrCb 4:2:0) is known to be suboptimal for > the representation of screen content as produced by systems at the time of > publication, which generally use at least 24 bits per sample RGB. Perhaps > a forward looking statement: ³In the future, it may become advisable to > use video codecs optimized for screen content (scan pattern, color space, > signal characteristics) for the representation of this type of content.² Added: Note that the default video scan format (Y'CrCb 4:2:0) is known to be less than optimal for the representation of screen content produced by most systems in use at the time of this document's publication, which generally use RGB with at least 24 bits per sample. In the future, it may be advisable to use video codecs optimized for screen content for the representation of this type of content. > 5. Section 5 second and third paragraphs: Mention Constrained Baseline > Profile here. Otherwise, section 5 seems fine to me. (I know that > constrained baseline is mentioned as a MUST later, but H.264 in isolation > is insufficient even in this overview part of the document). Done. > 6. Section 6, 3rd para, 1st and 2nd line, nit: "are MUST² Fixed. > 5. Section 6.2, profile_level_id, suggest to change the receiving side to > a MUST. The decoder interprets the value anyway as presented in-band. > What¹s the point that a receiver accepts a bitstream (without checking > profile_level_id), and the croaks because the decoder cannot handle the > bitstream complexity as communicated in-band? done. > 6. Section 6.2, max_mbps..., nit: par ameters (1st and second line) That's a very strange tooling issue (it's fine in the source). I'm going to see if I can untangle what's going on here. Thanks for catching it. > > Normative reference to H.264: depending on the timing, it may be better to > reference H.264v9. That version is currently in ³pre-published² state and > not freely downloadable, but should be generally available rather sooner > than later (and almost certainly before we are through with this draft). Updated the reference. Thanks for catching this. > 7. Section 6.2, sprop_parameter_sets: For avoidance of doubt, I would > rephrase that as ³this parameter MUST NOT be present². It is possible to > have that parameter and later change parameter sets in-band, and that is a > condition I think you want to avoid. That seems like a good point. I've taken the suggestion as: : H.264 allows sequence and picture information to be sent both in-band, and out-of-band. WebRTC implementations MUST signal this information in-band. This means that WebRTC implementations MUST NOT include this parameter in the SDP they generate. > 8. Section 6.2, Possibly missing: for H.264, should we specify a pixel > aspect ratio? VP8 uses square pixels, right? Perhaps follow that lead? Added: "Unless otherwise signaled, implementations that use H.264 MUST encode and decode pixels with a implied 1:1 (square) aspect ratio." > 9. Section 7: point to the payload formats also. H.264 allows for active > content in SEI messages... and the payload formats contain the necessary > caveats. Added: Implementors making use of H.264 are also advised to take careful note of the "Security Considerations" section of {{RFC6184}}, paying special regard to the normative requirement pertaining to SEI messages. /a --------------060006040601070408000906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Splitting this off from the thread it was posted on for the sake of cleanliness.

Thanks, Stefan, for the very useful feedback. I've incorporated it into the upcoming -04 version of the document as described below.

On 11/25/14 23:16, Stephan Wenger wrote:
1. Section 3: sRGB is fine.

Done.

2. Section 3: Add something like dynamic frame rate / frame interval based
on user locale, available bandwidth, and so on.  For example, in low light
conditions, it almost never makes sense to run a full 30 fps camera when
your transport has only bandwidth for 15 fps.

I think I follow what you're saying, but not 100% sure. What I've added is:


* Dynamic frame rate for video capture based on actual encoding in use
  (e.g., if encoding at 15 fps due to bandwidth constraints, the camera will
  ideally capture at 15 fps rather than a higher rate).


3. Section 3: Possibly missing: mention that the video scan pattern for
both VP8 and H.264 is YCrCb 4:2:0.

Added: "Unless specified otherwise by the SDP or codec, the video scan pattern for
video codecs is Y'CbCr 4:2:0".

4. Section 3: Possibly missing: the screen content section should mention
that the scan format of video (YCrCb 4:2:0) is known to be suboptimal for
the representation of screen content as produced by systems at the time of
publication, which generally use at least 24 bits per sample RGB.  Perhaps
a forward looking statement: ³In the future, it may become advisable to
use video codecs optimized for screen content (scan pattern, color space,
signal characteristics) for the representation of this type of content.²

Added:

Note that the default video scan format (Y'CrCb 4:2:0) is known to be
less than optimal for the representation of screen content produced by
most systems in use at the time of this document's publication, which
generally use RGB with at least 24 bits per sample. In the future, it
may be advisable to use video codecs optimized for screen content for the
representation of this type of content.

5. Section 5 second and third paragraphs: Mention Constrained Baseline
Profile here.   Otherwise, section 5 seems fine to me.  (I know that
constrained baseline is mentioned as a MUST later, but H.264 in isolation
is insufficient even in this overview part of the document).

Done.

6. Section 6, 3rd para, 1st and 2nd line, nit: "are MUST²

Fixed.

5. Section 6.2, profile_level_id, suggest to change the receiving side to
a MUST.  The decoder interprets the value anyway as presented in-band.
What¹s the point that a receiver accepts a bitstream (without checking
profile_level_id), and the croaks because the decoder cannot handle the
bitstream complexity as communicated in-band?

done.

6. Section 6.2, max_mbps..., nit: par ameters (1st and second line)

That's a very strange tooling issue (it's fine in the source). I'm going to see if I can untangle what's going on here. Thanks for catching it.


Normative reference to H.264: depending on the timing, it may be better to
reference H.264v9.  That version is currently in ³pre-published² state and
not freely downloadable, but should be generally available rather sooner
than later (and almost certainly before we are through with this draft).

Updated the reference. Thanks for catching this.

7. Section 6.2, sprop_parameter_sets: For avoidance of doubt, I would
rephrase that as ³this parameter MUST NOT be present².  It is possible to
have that parameter and later change parameter sets in-band, and that is a
condition I think you want to avoid.

That seems like a good point. I've taken the suggestion as:

: H.264 allows sequence and picture information to be sent both in-band, and
  out-of-band.  WebRTC implementations MUST signal this information in-band.
  This means that WebRTC implementations MUST NOT include this parameter in
  the SDP they generate.


8. Section 6.2, Possibly missing: for H.264, should we specify a pixel
aspect ratio?  VP8 uses square pixels, right?  Perhaps follow that lead?

Added: "Unless otherwise signaled, implementations that use H.264 MUST encode and decode pixels with a implied 1:1 (square) aspect ratio."

9. Section 7: point to the payload formats also.  H.264 allows for active
content in SEI messages... and the payload formats contain the necessary
caveats.

Added:

Implementors making use of H.264 are also advised to take careful note of the
"Security Considerations" section of {{RFC6184}}, paying special regard to the
normative requirement pertaining to SEI messages.

/a
--------------060006040601070408000906-- From nobody Thu Feb 12 14:18:46 2015 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 597661A0377 for ; Thu, 12 Feb 2015 14:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf6lFRuVvHcq for ; Thu, 12 Feb 2015 14:18:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC8D1A0371 for ; Thu, 12 Feb 2015 14:18:41 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1CMIdbZ038159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 16:18:40 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DD26BF.4070408@nostrum.com> Date: Thu, 12 Feb 2015 16:18:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [rtcweb] Video Open Issue #6: H.264 SEI messages 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 Feb 2015 22:18:43 -0000 Also breaking this one off from the previous thread... On 11/25/14 23:27, Stephan Wenger wrote: > Hi, > > I meant to copy the mailing list on two emails regarding my (and > Bernard’s) action items. I mis-spelled rtcweb. So here the content > integrated into a single email. (Bernard and Adam: there’s nothing new > herein.) > > Hi, > So here my proposal, with respect to H.264 baseline: > > MUST: > Filler payload. You see this occasionally from mostly early generation) > encoder chips. It¹s basically a way to waste bits so to fulfill buffer > constraints. Implementation complexity is zero: throw away bits. > > Full frame freeze: used in video switching MCUs, to ensure a stable > decoded displayed picture while switching channels in probably a > media-unaware way. Commonly used in H.32x legacy environments and also in > some SIP MCUs. To be clear, you are specifically leaving off "full frame freeze release" on purpose, right? > MAY: > User data T.35 registered, and user data unregistered > Especially the latter you see occasionally for proprietary extensions. > It¹s a good idea to advise implementers that a bitstream may contain that > kind of stuff, even if they don¹t act on it. > > Display orientation SEI, as it is referenced in section 4. Seems reasonable to me. Based on this advice, I have added the following text to -04: H.264 codecs MAY send and MUST support proper interpretation of SEI "filler payload" and "full frame freeze" messages. "Full frame freeze" messages are used in video switching MCUs, to ensure a stable decoded displayed picture while switching among various input streams. When video orientation (CVO) is not signaled as part of the SDP, H.264 implementations MAY send and SHOULD support proper interpretation of Display Orientation SEI messages. Implementations MAY send and act upon "User data registered by Rec. ITU-T T.35" and "User data unregistered" messages. Even if they do not act on them, implementations MUST be prepared to receive such messages without any ill effects. Stephan: could you sanity-check that this captures your recommendations accurately? Thanks! /a From nobody Thu Feb 12 16:02:01 2015 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 DBCA21A1A6C for ; Thu, 12 Feb 2015 16:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDd9GBGxbzXP for ; Thu, 12 Feb 2015 16:01:56 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC73F1A014C for ; Thu, 12 Feb 2015 16:01:56 -0800 (PST) Received: by iecrd18 with SMTP id rd18so16002918iec.5 for ; Thu, 12 Feb 2015 16:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TWW4AAssJGQaBb+Cp667lzQk5LYsj3epoLBhTO0IRd8=; b=a7mwOArL3X8PhLExev6dD3XOuissnt4oiO4XstQuIo/B6EhhLyiVGkSQw+4nLzlqXN EkCFbt6VvKjih9Tjm7ZgdBQLgfGmoPr+yE+1+CP+amtARSm7VFwCS6rArjh6h817lONF VOnitII+4V52Q8afcCgPNilzu8mHymPX+p6ikNlRjSSXLog3dJJJlOkEpRdjxVbRKik5 jzllCIw85clCji+omikHlvcnG2gyQ7uX6Js2VIowQPSyF3UzPc5pPoaOoDa6labBSLXC QqcryWNjtWAPDrjHjDQUjSSr5rByojDVUOB9AoBiKIlwKdDxmv89MrzvswNwNJJnc3/K ABKw== 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=TWW4AAssJGQaBb+Cp667lzQk5LYsj3epoLBhTO0IRd8=; b=IV+foZvScxcsFnNZraTukAzbsCOy6zMqOfudSqvqnS+PT39qCnRjyAvFAzPpms1hka 8smv5HrzacvOmPJ3I7TZ2TCYkjn9sS2WxqHN4YRp5OufAT0Wxp/g2cwOasDgKN2vz7cu VOIEF1Us6+nsp0cfSEjV1z22wjkqH/S/2rnyBcv+4an6WjiV99v6BcVG2X98LRkkSp9s 0YYKOHYibjOgLN8EL8duKcYQYXkvDCHYGfORcJO6SFRB5G2RSxzVzbEwvhAuKHIB02XK c2NYgPSm1VleGKEbV7O52TErE+G5rgjeby7xklUI1A6GF4BosEcm35bn5ZC10QA5JjCV 4ZYA== X-Gm-Message-State: ALoCoQkKXx30Ijv20mC8BGJno3/ifbVmT7TDDUCQ3g4milQHSmOt1WaFJmfQOuQ1yKb0UOe8VSHj X-Received: by 10.107.12.196 with SMTP id 65mr8338503iom.71.1423785716018; Thu, 12 Feb 2015 16:01:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Thu, 12 Feb 2015 16:01:35 -0800 (PST) In-Reply-To: References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Thu, 12 Feb 2015 16:01:35 -0800 Message-ID: To: Jozsef Vass Content-Type: multipart/alternative; boundary=001a113f8fd2d719b0050eecf13d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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, 13 Feb 2015 00:02:00 -0000 --001a113f8fd2d719b0050eecf13d Content-Type: text/plain; charset=UTF-8 If we do any FEC with PCMU, it would probably be 2198-style for simplicity (counter to what the current text says). Is this something that you would use? On Wed, Feb 11, 2015 at 11:44 AM, Jozsef Vass wrote: > Later, in 4.1 Recommended Mechanisms: > > When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198 ] > redundant encoding is NOT RECOMMENDED, as this will result in a > potentially significant bitrate increase. Furthermore, suddenly > increasing the bitrate to deal with packet losses may actually make > things worse. > > Because of the lower packet rate of audio encodings, usually a single > packet per frame, use of a separate FEC stream comes with a higher > overhead than other mechanisms, and therefore is NOT RECOMMENDED. > > > So what is recommended for PCMU? > > Jozsef > > > Jozsef Vass > SDK Engineering > [image: twilio] > MOBILE(415) 216-6603EMAILjvass@twilio.com > SIGNAL: The modern communications conference > > May 19/20 2015, Fort Mason Festival Pavilion, SF, CA > > > > > > > On Wed, Feb 11, 2015 at 11:39 AM, Simon Perreault > wrote: > >> >> On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass wrote: >> >>> I just wondering what kind of FEC is recommended (or will be supported) >>> for G.711. The draft does not recommend neither redundant encoding nor a >>> separate FEC stream. >> >> >> Isn't this what you're looking for? >> >> 3.1 . Separate FEC Stream >> >> This approach, as described in [RFC5956], Section 4.3 , sends FEC >> packets as an independent SSRC-multiplexed stream, with its own SSRC >> and payload type. While by far the most flexible, each FEC packet >> will have its own IP+UDP+RTP+FEC header, leading to additional >> overhead of the FEC stream. >> >> >> Simon >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113f8fd2d719b0050eecf13d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we do any FEC with PCMU, it would probably be 2198-styl= e for simplicity (counter to what the current text says). Is this something= that you would use?

On Wed, Feb 11, 2015 at 11:44 AM, Jozsef Vass &l= t;jvass@twilio.com> wrote:
Late= r, in 4.1 Recommended Mechanisms:

   When using cons=
tant-bitrate codecs, e.g.  PCMU, use of [RFC2198]
   redundant encoding is NOT RECOMMENDED, as this will result in a
   potentially significant bitrate increase.  Furthermore, suddenly
   increasing the bitrate to deal with packet losses may actually make
   things worse.

   Because of the lower packet rate of audio encodings, usually a single
   packet per frame, use of a separate FEC stream comes with a higher
   overhead than other mechanisms, and therefore is NOT RECOMMENDED.
<= div>
So what is recommended for PCMU?

Jozsef



On Wed, Feb 11= , 2015 at 11:39 AM, Simon Perreault <sperreault@jive.com> = wrote:

On Wed, Feb 11, 2015 at 12:01 PM, = Jozsef Vass <jvass@twilio.com> wrote:
I j= ust wondering what kind of FEC is recommended (or will be supported) for G.= 711. The draft does not recommend neither redundant encoding nor a separate= FEC stream.

Isn't this what you're= looking for?=C2=A0

3.1=
.  Separate FEC Stream


   This approach, as described in [RFC5956], Section=C2=A04.3, sends =
FEC
   packets as an independent SSRC-multiplexed stream, with its own SSRC
   and payload type.  While by far the most flexible, each FEC packet
   will have its own IP+UDP+RTP+FEC header, leading to additional
   overhead of the FEC stream.

<=
/pre>Simon


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


--001a113f8fd2d719b0050eecf13d-- From nobody Fri Feb 13 01:48:16 2015 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 909FA1A3BA5 for ; Fri, 13 Feb 2015 01:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rshk_eriCYUt for ; Fri, 13 Feb 2015 01:48:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EE41A3B9B for ; Fri, 13 Feb 2015 01:48:10 -0800 (PST) Received: from CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) by CY1PR0701MB1306.namprd07.prod.outlook.com (25.160.149.25) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 13 Feb 2015 09:47:51 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) with Microsoft SMTP Server (TLS) id 15.1.87.18; Fri, 13 Feb 2015 09:47:49 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0087.013; Fri, 13 Feb 2015 09:47:49 +0000 From: Stephan Wenger To: Adam Roach , "rtcweb@ietf.org" Thread-Topic: Stephan Wenger's Video Document Comments Thread-Index: AQHQRwt38145cLuh5kSTeQXJxcXOuZzuZucA Date: Fri, 13 Feb 2015 09:47:48 +0000 Message-ID: References: <54DD1C01.7000202@nostrum.com> In-Reply-To: <54DD1C01.7000202@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.106.216.55] authentication-results: nostrum.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1273;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1273; x-forefront-prvs: 0486A0CB86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(2501002)(40100003)(2900100001)(2950100001)(92566002)(86362001)(106116001)(99286002)(66066001)(46102003)(36756003)(122556002)(54356999)(19580395003)(62966003)(102836002)(107886001)(2656002)(50986999)(87936001)(16236675004)(76176999)(77156002)(19580405001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1273; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D10384D750017stewesteweorg_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2015 09:47:48.8664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1273 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1306; X-OriginatorOrg: stewe.org Archived-At: Subject: Re: [rtcweb] Stephan Wenger's Video Document Comments 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 Feb 2015 09:48:14 -0000 --_000_D10384D750017stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We seem to be in agreement. There is just one point where I have additiona= l input; see below (including suggested text). Stephan From: Adam Roach > Date: Thursday, February 12, 2015 at 22:32 To: "rtcweb@ietf.org" > Cc: Stephan Wenger > Subject: Stephan Wenger's Video Document Comments Splitting this off from the thread it was posted on for the sake of cleanli= ness. Thanks, Stefan, for the very useful feedback. I've incorporated it into the= upcoming -04 version of the document as described below. [...] 2. Section 3: Add something like dynamic frame rate / frame interval based on user locale, available bandwidth, and so on. For example, in low light conditions, it almost never makes sense to run a full 30 fps camera when your transport has only bandwidth for 15 fps. I think I follow what you're saying, but not 100% sure. What I've added is: * Dynamic frame rate for video capture based on actual encoding in use (e.g., if encoding at 15 fps due to bandwidth constraints, the camera wil= l ideally capture at 15 fps rather than a higher rate). Transmission bandwidth (which comes to play only after encoding, and where = the encoder generally has many choices in addition to dealing down the fram= e rate) is just one reason to go down with the capture frame rate. Applica= tion needs/settings is another and probably a more common one. Yet another= is light conditions: in low light conditions, one is better off to sample = at low frame rate, for two reasons: first, the human eye is not particularl= y good in observing fast movement in low light, so why bother capturing/cod= ing it? And second, a camera sensor creates more noise at low light condit= ions, which can be mitigated by allowing more photons to hit the sensor ele= ment in question over time. Also, capture frame rate can be dictated not only by the codec (as a result= of bandwidth starvation), but also by the environment (light/applications = setting). Your text suggests that the frame rate adjustment trickles down = from transmission needs, but that's not the only source (and perhaps not ev= en the most relevant one). Suggested text: * Dynamic frame rate for video capture based on actual encoding in use = (e.g., if encoding at 15 fps due to bandwidth constraints, low light condit= ions, or application settings, the camera will ideally capture at 15 fps ra= ther than a higher rate). --_000_D10384D750017stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2D40C541144F3E47B9633139A3CFD85A@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi,
We seem to be in agreement.  There is just one point where I have= additional input; see below (including suggested text).
Stephan


From: Adam Roach <adam@nostrum.com>
Date: Thursday, February 12, 2015 a= t 22:32
To: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Cc: Stephan Wenger <stewe@stewe.org>
Subject: Stephan Wenger's Video Doc= ument Comments

Splitting this off from the threa= d it was posted on for the sake of cleanliness.

Thanks, Stefan, for the very useful feedback. I've incorporated it into the= upcoming -04 version of the document as described below.

[…]

2. Section 3: Add something like dynamic frame rate / frame =
interval based
on user locale, available bandwidth, and so on.  For example, in low light
conditions, it almost never makes sense to run a full 30 fps camera when
your transport has only bandwidth for 15 fps.

I think I follow what you're saying, but not 100% sure. What I've added is:=


* Dynamic frame rate for video capture based on actual encoding in use
  (e.g., if encoding at 15 fps due to bandwidth constraints, the camer= a will
  ideally capture at 15 fps rather than a higher rate).

Transmission bandwidth (which comes to play only after encoding, and w= here the encoder generally has many choices in addition to dealing down the= frame rate) is just one reason to go down with the capture frame rate. &nb= sp;Application needs/settings is another and probably a more common one.  Yet another is light conditions: in = low light conditions, one is better off to sample at low frame rate, for tw= o reasons: first, the human eye is not particularly good in observing fast = movement in low light, so why bother capturing/coding it?  And second, a camera sensor creates more noise = at low light conditions, which can be mitigated by allowing more photons to= hit the sensor element in question over time.  
Also, capture frame rate can be dictated not only by the codec (as a r= esult of bandwidth starvation), but also by the environment (light/applicat= ions setting).  Your text suggests that the frame rate adjustment tric= kles down from transmission needs, but that’s not the only source (and perhaps not even the most relevant o= ne). 

Suggested text:

  • Dynamic frame rate for video capture based on actual encoding in use&nb= sp;(e.g., if encoding at 15 fps due to bandwidth constraints, low light con= ditions, or application settings, the camera will ideally capture at 15 fps= rather than a higher rate). 

 --_000_D10384D750017stewesteweorg_-- From nobody Fri Feb 13 01:54:50 2015 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 84FCE1A6EF9 for ; Fri, 13 Feb 2015 01:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MAhj1dfA5lD for ; Fri, 13 Feb 2015 01:54:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469661A6F03 for ; Fri, 13 Feb 2015 01:54:45 -0800 (PST) Received: from CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) by CY1PR0701MB1194.namprd07.prod.outlook.com (25.160.146.147) with Microsoft SMTP Server (TLS) id 15.1.87.18; Fri, 13 Feb 2015 09:54:42 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) with Microsoft SMTP Server (TLS) id 15.1.87.18; Fri, 13 Feb 2015 09:54:41 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0087.013; Fri, 13 Feb 2015 09:54:41 +0000 From: Stephan Wenger To: Adam Roach , "rtcweb@ietf.org" Thread-Topic: Video Open Issue #6: H.264 SEI messages Thread-Index: AQHQRxHe02CXWeM8C0qQIUxCFAIQdpzuaMSA Date: Fri, 13 Feb 2015 09:54:41 +0000 Message-ID: References: <54DD26BF.4070408@nostrum.com> In-Reply-To: <54DD26BF.4070408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.106.216.55] authentication-results: nostrum.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1273;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1273; x-forefront-prvs: 0486A0CB86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5383001)(479174004)(41574002)(51704005)(24454002)(36756003)(46102003)(19580395003)(54356999)(122556002)(66066001)(76176999)(19580405001)(77156002)(62966003)(2656002)(87936001)(50986999)(107886001)(102836002)(2950100001)(2900100001)(92566002)(561944003)(2501002)(40100003)(106116001)(99286002)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1273; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2015 09:54:41.4730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1273 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1194; X-OriginatorOrg: stewe.org Archived-At: Subject: Re: [rtcweb] Video Open Issue #6: H.264 SEI messages 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 Feb 2015 09:54:48 -0000 SGksDQpBIGZldyBjb21tZW50cyBpbmxpbmUuDQpTdGVwaGFuDQoNCk9uIDIvMTIvMTUsIDIzOjE4 LCAiQWRhbSBSb2FjaCIgPGFkYW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KDQo+QWxzbyBicmVha2lu ZyB0aGlzIG9uZSBvZmYgZnJvbSB0aGUgcHJldmlvdXMgdGhyZWFkLi4uDQo+DQo+T24gMTEvMjUv MTQgMjM6MjcsIFN0ZXBoYW4gV2VuZ2VyIHdyb3RlOg0KPj4gSGksDQo+Pg0KPj4gSSBtZWFudCB0 byBjb3B5IHRoZSBtYWlsaW5nIGxpc3Qgb24gdHdvIGVtYWlscyByZWdhcmRpbmcgbXkgKGFuZA0K Pj4gQmVybmFyZKGvcykgYWN0aW9uIGl0ZW1zLiAgSSBtaXMtc3BlbGxlZCBydGN3ZWIuICBTbyBo ZXJlIHRoZSBjb250ZW50DQo+PiBpbnRlZ3JhdGVkIGludG8gYSBzaW5nbGUgZW1haWwuICAoQmVy bmFyZCBhbmQgQWRhbTogdGhlcmWhr3Mgbm90aGluZyBuZXcNCj4+IGhlcmVpbi4pDQo+Pg0KPj4g SGksDQo+PiBTbyBoZXJlIG15IHByb3Bvc2FsLCB3aXRoIHJlc3BlY3QgdG8gSC4yNjQgYmFzZWxp bmU6DQo+Pg0KPj4gTVVTVDoNCj4+IEZpbGxlciBwYXlsb2FkLiAgWW91IHNlZSB0aGlzIG9jY2Fz aW9uYWxseSBmcm9tIG1vc3RseSBlYXJseSBnZW5lcmF0aW9uKQ0KPj4gZW5jb2RlciBjaGlwcy4g IEl0qfZzIGJhc2ljYWxseSBhIHdheSB0byB3YXN0ZSBiaXRzIHNvIHRvIGZ1bGZpbGwgYnVmZmVy DQo+PiBjb25zdHJhaW50cy4gIEltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgaXMgemVybzogdGhy b3cgYXdheSBiaXRzLg0KPj4NCj4+IEZ1bGwgZnJhbWUgZnJlZXplOiB1c2VkIGluIHZpZGVvIHN3 aXRjaGluZyBNQ1VzLCB0byBlbnN1cmUgYSBzdGFibGUNCj4+IGRlY29kZWQgZGlzcGxheWVkIHBp Y3R1cmUgd2hpbGUgc3dpdGNoaW5nIGNoYW5uZWxzIGluIHByb2JhYmx5IGENCj4+IG1lZGlhLXVu YXdhcmUgd2F5LiAgQ29tbW9ubHkgdXNlZCBpbiBILjMyeCBsZWdhY3kgZW52aXJvbm1lbnRzIGFu ZCBhbHNvDQo+PmluDQo+PiBzb21lIFNJUCBNQ1VzLg0KPg0KPlRvIGJlIGNsZWFyLCB5b3UgYXJl IHNwZWNpZmljYWxseSBsZWF2aW5nIG9mZiAiZnVsbCBmcmFtZSBmcmVlemUNCj5yZWxlYXNlIiBv biBwdXJwb3NlLCByaWdodD8NCg0KWWVzLiAgSaGvbSBub3QgYXdhcmUgb2YgYW55IHByb2R1Y3Qg dGhhdCB1c2VzIGZ1bGwgZnJhbWUgZnJlZXplIHJlbGVhc2UgaW4NCmFuIFNFSSBtZXNzYWdlLiAg SC4zMjMgc3lzdGVtcyBzZW5kIHRoaXMgY29tbWFuZCBvdmVyIEguMjQ1IHNpZ25hbGluZyAoYW5k DQp0aGVyZSBpcyBhIHJlYXNvbiBmb3IgaXQsIGJ1dCB0aGF0IHdvdWxkIHByb2JhYmx5IGdvIGEg Yml0IHRvbyBmYXIgZm9yIHRoZQ0KZGlzY3Vzc2lvbiBoZXJlLikNCg0KPg0KPj4gTUFZOg0KPj4g VXNlciBkYXRhIFQuMzUgcmVnaXN0ZXJlZCwgYW5kIHVzZXIgZGF0YSB1bnJlZ2lzdGVyZWQNCj4+ IEVzcGVjaWFsbHkgdGhlIGxhdHRlciB5b3Ugc2VlIG9jY2FzaW9uYWxseSBmb3IgcHJvcHJpZXRh cnkgZXh0ZW5zaW9ucy4NCj4+IEl0qfZzIGEgZ29vZCBpZGVhIHRvIGFkdmlzZSBpbXBsZW1lbnRl cnMgdGhhdCBhIGJpdHN0cmVhbSBtYXkgY29udGFpbg0KPj50aGF0DQo+PiBraW5kIG9mIHN0dWZm LCBldmVuIGlmIHRoZXkgZG9uqfZ0IGFjdCBvbiBpdC4NCj4+DQo+PiBEaXNwbGF5IG9yaWVudGF0 aW9uIFNFSSwgYXMgaXQgaXMgcmVmZXJlbmNlZCBpbiBzZWN0aW9uIDQuDQo+DQo+U2VlbXMgcmVh c29uYWJsZSB0byBtZS4NCj4NCj5CYXNlZCBvbiB0aGlzIGFkdmljZSwgSSBoYXZlIGFkZGVkIHRo ZSBmb2xsb3dpbmcgdGV4dCB0byAtMDQ6DQo+DQo+SC4yNjQgY29kZWNzIE1BWSBzZW5kIGFuZCBN VVNUIHN1cHBvcnQgcHJvcGVyIGludGVycHJldGF0aW9uIG9mIFNFSQ0KPiJmaWxsZXINCj5wYXls b2FkIiBhbmQgImZ1bGwgZnJhbWUgZnJlZXplIiBtZXNzYWdlcy4gIkZ1bGwgZnJhbWUgZnJlZXpl IiBtZXNzYWdlcw0KPmFyZQ0KPnVzZWQgaW4gdmlkZW8gc3dpdGNoaW5nIE1DVXMsIHRvIGVuc3Vy ZSBhIHN0YWJsZSBkZWNvZGVkIGRpc3BsYXllZCBwaWN0dXJlDQo+d2hpbGUgc3dpdGNoaW5nIGFt b25nIHZhcmlvdXMgaW5wdXQgc3RyZWFtcy4NCj4NCj5XaGVuIHZpZGVvIG9yaWVudGF0aW9uIChD Vk8pIGlzIG5vdCBzaWduYWxlZCBhcyBwYXJ0IG9mIHRoZSBTRFAsIEguMjY0DQo+aW1wbGVtZW50 YXRpb25zIE1BWSBzZW5kIGFuZCBTSE9VTEQgc3VwcG9ydCBwcm9wZXIgaW50ZXJwcmV0YXRpb24g b2YNCj5EaXNwbGF5DQo+T3JpZW50YXRpb24gU0VJIG1lc3NhZ2VzLg0KPg0KPkltcGxlbWVudGF0 aW9ucyBNQVkgc2VuZCBhbmQgYWN0IHVwb24gIlVzZXIgZGF0YSByZWdpc3RlcmVkIGJ5IFJlYy4g SVRVLVQNCj5ULjM1IiBhbmQgIlVzZXIgZGF0YSB1bnJlZ2lzdGVyZWQiIG1lc3NhZ2VzLiBFdmVu IGlmIHRoZXkgZG8gbm90IGFjdCBvbg0KPnRoZW0sDQo+aW1wbGVtZW50YXRpb25zIE1VU1QgYmUg cHJlcGFyZWQgdG8gcmVjZWl2ZSBzdWNoIG1lc3NhZ2VzIHdpdGhvdXQgYW55IGlsbA0KPmVmZmVj dHMuDQo+DQo+DQo+U3RlcGhhbjogY291bGQgeW91IHNhbml0eS1jaGVjayB0aGF0IHRoaXMgY2Fw dHVyZXMgeW91ciByZWNvbW1lbmRhdGlvbnMNCj5hY2N1cmF0ZWx5PyBUaGFua3MhDQoNClNvdW5k cyBPSy4gIFF1aWNrIHF1ZXN0aW9uIGZvciBteSBlZHVjYXRpb24gYW5kIHRvIG1ha2Ugc3VyZTog U0RQIENWTw0KcmVmZXJzIHRvIHRoZSBwcmVzZW5jZSBvZiB0aGF0IFJUUCBoZWFkZXIgZXh0ZW5z aW9uIHRoYXQgaW5kaWNhdGVzIHBpY3R1cmUNCm9yaWVudGF0aW9uLCBhbmQgbm90IHRvIGEgZml4 ZWQgb3JpZW50YXRpb24gc2lnbmFsZWQgaW4gdGhlIFNEUCwgcmlnaHQ/DQoNClRoZSByZWFzb24g SaGvbSBhc2tpbmcgaXMgdGhhdCB0aGUgU0VJIG1lc3NhZ2UgYW5kIHRoZSBSVFAgaGVhZGVyIGV4 dGVuc2lvbg0KYm90aCBhbGxvdyB0byBjaGFuZ2UgZGlzcGxheSBvcmllbnRhdGlvbiBvbiB0aGUg Zmx5LCB3aGljaCBpcyBvYnZpb3VzbHkNCnVzZWZ1bCBmb3IgaGFuZGhlbGQgZGV2aWNlcy4gIFRo YXShr3Mgd2hhdCB3ZSBuZWVkLiBBIGZpeGVkIG9yaWVudGF0aW9uIGlzDQp0b28gaW5mbGV4aWJs ZSBmb3IgYWxtb3N0IGFsbCBhcHBsaWNhdGlvbnMgdGhhdCBtYXR0ZXIuDQoNCg0KPg0KPi9hDQoN Cg== From nobody Fri Feb 13 05:28:38 2015 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 D11201A70E1 for ; Fri, 13 Feb 2015 05:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFRe-ntw4myy for ; Fri, 13 Feb 2015 05:28:33 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DCE1A6F29 for ; Fri, 13 Feb 2015 05:28:33 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-97-54ddfbfeb784 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.49.04076.EFBFDD45; Fri, 13 Feb 2015 14:28:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 14:28:30 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: SDP-SCTP: Max value for SDP max-message-size attribute? Thread-Index: AdBHkN3ArHPuixe0RQm4iuYSV2Xepg== Date: Fri, 13 Feb 2015 13:28:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D1CA5@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6D1CA5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje7/33dDDOZuYLFY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGZ/Oz2Iv+KBUsfvcHJYGxr1yXYycHBICJhLXmjtYIWwxiQv3 1rN1MXJxCAkcYZR4t2s9M4SzhFHi3u2rQFUcHGwCFhLd/7RBGkQE1CUuP7zADmILCzhInL/W yw4Rd5Vo+b2CCaRcREBP4vonS5Awi4CqxOO+88wgNq+Ar8TxnnlgexmB9n4/tYYJxGYWEJe4 9WQ+E8Q9AhJL9kDUSwiISrx8/A/qTkWJnWfbmSHq8yWev7rECjFTUOLkzCcsExiFZiEZNQtJ 2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo2hxanFxbrqRkV5qUWZycXF+nl5e askmRmBEHNzy22oH48HnjocYBTgYlXh4N2TcDRFiTSwrrsw9xCjNwaIkzmtnfChESCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA2PuHkc9/c12a9l+zxK43ZJ4LdZ5h82fH7eti9fpq2/138kj 9SLc7/SaeWv9795gXbGYx7dCk+2CRFPi386FAWc+SYqrpW5bP+eSxowrYdNWrE521Ysw3M/6 iknzYnLX+aJrxxbe9fpb1feqhV993p3+fUwbbt06lpwgaJg20emdXti9SkFZc3UlluKMREMt 5qLiRAAisj0xaQIAAA== Archived-At: Subject: [rtcweb] SDP-SCTP: Max value for SDP max-message-size attribute? 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 Feb 2015 13:28:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6D1CA5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The MMUSIC SCTP-SDP draft defines the SDP max-message-size attribute, which= can be used to indicate the maximum size of message that an entity is will= ing to receive on an SCTP association I have received a comment on whether we should define a max value for the a= ttribute. When reading the rtcweb-data-channel draft, it says that a sender should no= t send messages bigger than 16 KB, unless interleaving is used. As an entity can choose how big messages to send (as long as the message si= ze is smaller than the max-message-size value), but suggestion would be to = NOT define an attribute max value in the SCTP-SDP draft. Different usages (= e.g. webrtc data channels) need to choose the size based on SCTP features s= upported etc. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D6D1CA5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The MMUSIC SCTP-SDP draft defin= es the SDP max-message-size attribute, which can be used to indicate the ma= ximum size of message that an entity is willing to receive on an SCTP assoc= iation

 

I have received a comment on wh= ether we should define a max value for the attribute.

 

When reading the rtcweb-data-ch= annel draft, it says that a sender should not send messages bigger than 16 = KB, unless interleaving is used.

 

As an entity can choose how big= messages to send (as long as the message size is smaller than the max-mess= age-size value), but suggestion would be to NOT define an attribute max val= ue in the SCTP-SDP draft. Different usages (e.g. webrtc data channels) need to choose the size based on SCTP f= eatures supported etc.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D6D1CA5ESESSMB209erics_-- From nobody Fri Feb 13 05:55:58 2015 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 4841F1A701C for ; Fri, 13 Feb 2015 05:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmoIlEOCiLeH for ; Fri, 13 Feb 2015 05:55:50 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE121A702C for ; Fri, 13 Feb 2015 05:55:50 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-97-54de026460d8 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.BE.04076.4620ED45; Fri, 13 Feb 2015 14:55:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 14:55:47 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? Thread-Index: AdBHkzCQyzSQhofyQHmttIgUsDEyWA== Date: Fri, 13 Feb 2015 13:55:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6D1E74ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW4K070Qg84ecYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fzAbbaCZuOKxz0bWBoYD+h0MXJwSAiYSHzaHNDFyAlkiklc uLeerYuRi0NI4AijxI6Vz1ghnCUgzgxGkAY2AQuJ7n/aIA0iAuoSlx9eYAexhQXSJU5uu8oM Ec+R6G7sYoWw9SSOve9hArFZBFQlTp/cywJi8wr4SrQuuwtWwwi0+PupNWA1zALiEreezGeC OEhAYsme88wQtqjEy8f/WCFsRYmdZ9uZIerzJe4d3cMKMVNQ4uTMJywTGIVmIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZG YEQc3PLbagfjweeOhxgFOBiVeHg3ZNwNEWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDo9mDwn9xS0OT1+07XfpP4nmr/8aKnYbVTPPjvbPi3y/LW1t9/vNy pnyL1n3yy2ccWJLT+ez9vceWjNb5J4xCX1p3SQs+6+2pVRfbI9D664VCovWsEramAiZj3mbF fNVwMQuedY3TM/7c8lzHeXFdWoR5pFrMPv/8dck3215ZmFpzLuEr0dRRYinOSDTUYi4qTgQA VXyH+GkCAAA= Archived-At: Subject: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 13:55:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6D1E74ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In the TLS role determination section of the SDP-SCTP draft, the text says: "Once a DTLS connection has been established, = if the 'active/passive' status of the endpoints change (as result of an offer/answer= exchange) during a session, a new DTLS connection MUST be established. There= fore, endpoints SHOULD NOT change the 'active/passive' status during a session, = unless they want to establish a new DTLS connection." I have received a question whether this also affects the underlying TCP con= nection (in case of 'TCP/DTLS/SCTP') and the SCTP association (in case of '= SCTP/DTLS'). My suggestion would be to NOT re-establish the underlying TCP/SCTP associat= ion just because the DTLS connection is re-established. Also, I could not f= ind anything in RFC 6083 that would indicate that the SCTP association woul= d have to be re-established. (IF a user also wants the underlying TCP/SCTP association to be re-establis= hed, he/she uses the SDP connection attribute with a 'new' value.) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D6D1E74ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the TLS role determination s= ection of the SDP-SCTP draft, the text says:

 

     &= nbsp;           &nbs= p;           “Once = a DTLS connection has been established, if the 'active/passive' status of t= he

     &= nbsp;           &nbs= p;           endpoints ch= ange (as result of an offer/answer exchange) during a session, a

     &= nbsp;           &nbs= p;           new DTLS con= nection MUST be established. Therefore, endpoints SHOULD NOT change

     &= nbsp;           &nbs= p;           the 'active/= passive' status during a session, unless they want to establish a

     &= nbsp;           &nbs= p;           new DTLS con= nection.”

 

I have received a question whet= her this also affects the underlying TCP connection (in case of ‘TCP/= DTLS/SCTP’) and the SCTP association (in case of ‘SCTP/DTLSR= 17;).

 

My suggestion would be to NOT r= e-establish the underlying TCP/SCTP association just because the DTLS conne= ction is re-established. Also, I could not find anything in RFC 6083 that w= ould indicate that the SCTP association would have to be re-established.

 

(IF a user also wants the under= lying TCP/SCTP association to be re-established, he/she uses the SDP connec= tion attribute with a ‘new’ value.)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D6D1E74ESESSMB209erics_-- From nobody Fri Feb 13 07:29:46 2015 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 5B94F1A0276 for ; Fri, 13 Feb 2015 07:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swl42NjI7j-p for ; Fri, 13 Feb 2015 07:29:38 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6738A1A872E for ; Fri, 13 Feb 2015 07:29:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 274C27C3C1E; Fri, 13 Feb 2015 16:29:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNTzjy1u5U01; Fri, 13 Feb 2015 16:29:35 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:1504:784:7a6b:dbe9]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5897F7C3C11; Fri, 13 Feb 2015 16:29:35 +0100 (CET) Message-ID: <54DE185D.9060402@alvestrand.no> Date: Fri, 13 Feb 2015 16:29:33 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------070906000807080205050003" Archived-At: Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 15:29:42 -0000 This is a multi-part message in MIME format. --------------070906000807080205050003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 02/13/2015 02:55 PM, Christer Holmberg wrote: > > Hi, > > In the TLS role determination section of the SDP-SCTP draft, the text > says: > > Once a DTLS connection has been established, if the 'active/passive' > status of the > > endpoints change (as result of an offer/answer exchange) during a > session, a > > new DTLS connection MUST be established. Therefore, endpoints SHOULD > NOT change > > the 'active/passive' status during a session, unless they want to > establish a > > new DTLS connection. > > I have received a question whether this also affects the underlying > TCP connection (in case of TCP/DTLS/SCTP) and the SCTP association > (in case of SCTP/DTLS). > > My suggestion would be to NOT re-establish the underlying TCP/SCTP > association just because the DTLS connection is re-established. Also, > I could not find anything in RFC 6083 that would indicate that the > SCTP association would have to be re-established. > Seems reasonable to me - but since this is an MMUSIC draft (draft-ietf-mmusic-sctp-sdp) and has the potential to be used outside of RTCWEB, shoudn't this go on the mmusic mailing list? > (IF a user also wants the underlying TCP/SCTP association to be > re-established, he/she uses the SDP connection attribute with a new > value.) > > Regards, > > Christer > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------070906000807080205050003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 02/13/2015 02:55 PM, Christer Holmberg wrote:

Hi,

In the TLS role determination section of the SDP-SCTP draft, the text says:

Once a DTLS connection has been established, if the 'active/passive' status of the

endpoints change (as result of an offer/answer exchange) during a session, a

new DTLS connection MUST be established. Therefore, endpoints SHOULD NOT change

the 'active/passive' status during a session, unless they want to establish a

new DTLS connection.

I have received a question whether this also affects the underlying TCP connection (in case of TCP/DTLS/SCTP) and the SCTP association (in case of SCTP/DTLS).

My suggestion would be to NOT re-establish the underlying TCP/SCTP association just because the DTLS connection is re-established. Also, I could not find anything in RFC 6083 that would indicate that the SCTP association would have to be re-established.


Seems reasonable to me - but since this is an MMUSIC draft (draft-ietf-mmusic-sctp-sdp) and has the potential to be used outside of RTCWEB, shoudn't this go on the mmusic mailing list?


(IF a user also wants the underlying TCP/SCTP association to be re-established, he/she uses the SDP connection attribute with a new value.)

Regards,

Christer



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

--------------070906000807080205050003-- From nobody Fri Feb 13 08:24:09 2015 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 47D121A8798 for ; Fri, 13 Feb 2015 08:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYe4N63ZOwc5 for ; Fri, 13 Feb 2015 08:23:54 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DEC01A876D for ; Fri, 13 Feb 2015 08:23:16 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so11634396igk.1 for ; Fri, 13 Feb 2015 08:23:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ISNjrxTvsfCePLJK9L4ue8wBtWkt79RSLGEg7WQkcs8=; b=k1N6mDt6cVDqcHJK3d8+vTKlJEiW5ILx3T+IV6LA76lRZdNuBDOR7o1Jgpe3ZNXV44 LtdwRaSZbwCvFu5mnYWsYIWKVgi8YfHVmmNdgHAjoNS1RdYSHjI4PTByuD3w16J6pM6j Ycolz+6pV0p0xynCIKJ85fCj2NWYJ3KcVvH74h7xtZyNYbKYnG4+RXk+utE1A6KG0owF tc6+MCmwhWXoJQyobRbw0K6tsiHQMEi1KmO9ygL2KZMHstr5SRhfzwYCsHoyBHzubuus SZtzGEajp+zJTpvD2bqABNxcgyW4JJqYU/3gs18aFGM1roFRMwTJ9EDWpnGmWZ084Lyu xmRw== X-Gm-Message-State: ALoCoQkZv87WXaWgpFgQStcFtdg2gQ6qFPbVRgMdA4c9q6KZQFeW53TxsBEinuN+cgTXUZUXExTi X-Received: by 10.42.200.82 with SMTP id ev18mr15494224icb.44.1423844590918; Fri, 13 Feb 2015 08:23:10 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by mx.google.com with ESMTPSA id f12sm4042488ioi.21.2015.02.13.08.23.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 08:23:09 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so11537837igb.3 for ; Fri, 13 Feb 2015 08:23:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.122.68 with SMTP id lq4mr4679640igb.10.1423844587823; Fri, 13 Feb 2015 08:23:07 -0800 (PST) Received: by 10.36.20.10 with HTTP; Fri, 13 Feb 2015 08:23:07 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> Date: Fri, 13 Feb 2015 11:23:07 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e015383fcdf7ff6050efaa6af Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 16:24:01 -0000 --089e015383fcdf7ff6050efaa6af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2015 at 8:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > In the TLS role determination section of the SDP-SCTP draft, the text > says: > > > > =E2=80=9COnce a DTLS connection has been est= ablished, > if the 'active/passive' status of the > > endpoints change (as result of an > offer/answer exchange) during a session, a > > new DTLS connection MUST be established. > Therefore, endpoints SHOULD NOT change > > the 'active/passive' status during a session= , > unless they want to establish a > > new DTLS connection.=E2=80=9D > > > > I have received a question whether this also affects the underlying TCP > connection (in case of =E2=80=98TCP/DTLS/SCTP=E2=80=99) and the SCTP asso= ciation (in case > of =E2=80=98SCTP/DTLS=E2=80=99). > > > > My suggestion would be to NOT re-establish the underlying TCP/SCTP > association just because the DTLS connection is re-established. Also, I > could not find anything in RFC 6083 that would indicate that the SCTP > association would have to be re-established. > > > > (IF a user also wants the underlying TCP/SCTP association to be > re-established, he/she uses the SDP connection attribute with a =E2=80=98= new=E2=80=99 > value.) > > > > > As far as I know the only way to demultiplex DTLS packets is based on the underlying transport. Unless you can guarantee that no packets from the previous DTLS connection will arrive on the new connection reusing the same underlying transport some interesting problems can occur. Unless someone proposes a way to demux two DTLS connections on the same transport, I would suggest that new underlying transport should always be used for new DTLS connection and that DTLS connection settings should not be changed unless the transport is changed as well. _____________ Roman Shpount --089e015383fcdf7ff6050efaa6af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 13, 2015 at 8:55 AM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:

In the TLS role determination section of the SDP-SCT= P draft, the text says:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9COn= ce a DTLS connection has been established, if the 'active/passive' = status of the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoints c= hange (as result of an offer/answer exchange) during a session, a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 new DTLS co= nnection MUST be established. Therefore, endpoints SHOULD NOT change

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the 'ac= tive/passive' status during a session, unless they want to establish a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 new DTLS co= nnection.=E2=80=9D

=C2=A0

I have received a question whet= her this also affects the underlying TCP connection (in case of =E2=80=98TC= P/DTLS/SCTP=E2=80=99) and the SCTP association (in case of =E2=80=98SCTP/DT= LS=E2=80=99).

=C2=A0

My suggestion would be to NOT r= e-establish the underlying TCP/SCTP association just because the DTLS conne= ction is re-established. Also, I could not find anything in RFC 6083 that w= ould indicate that the SCTP association would have to be re-established.

=C2=A0

(IF a user also wants the under= lying TCP/SCTP association to be re-established, he/she uses the SDP connec= tion attribute with a =E2=80=98new=E2=80=99 value.)

=C2=A0



As far as I know the only way to demultiplex DTLS packets is based on the = underlying transport. Unless you can guarantee that no packets from the pre= vious DTLS connection will arrive on the new connection reusing the same un= derlying transport some interesting problems can occur. Unless someone prop= oses a way to demux two DTLS connections on the same transport, I would sug= gest that new underlying transport should always be used for new DTLS conne= ction and that DTLS connection settings should not be changed unless the tr= ansport is changed as well.=C2=A0
= _____________
Roman Shpount
=C2=A0
--089e015383fcdf7ff6050efaa6af-- From nobody Fri Feb 13 09:10:21 2015 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 2B0871A0004 for ; Fri, 13 Feb 2015 09:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTYP63FALGEI for ; Fri, 13 Feb 2015 09:10:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDBC1A001B for ; Fri, 13 Feb 2015 09:10:08 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1DHA3d2035563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 11:10:03 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DE2FEA.6080805@nostrum.com> Date: Fri, 13 Feb 2015 11:10:02 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Harald Alvestrand , rtcweb@ietf.org References: <54DD11B6.8060201@nostrum.com> <54DD147D.504@alvestrand.no> In-Reply-To: <54DD147D.504@alvestrand.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Video Open issue #4: VP8 filters 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 Feb 2015 17:10:16 -0000 Well, I guess fifth time asking is the charm. Consensus seems to be to remove this sentence -- so it's gone. /a On 2/12/15 15:00, Harald Alvestrand wrote: > On 02/12/2015 09:48 PM, Adam Roach wrote: >> In Toronto, there was a claim that specification that "bilinear" and >> "none" filters is superfluous, as they are already required as part >> of the VP8 spec. Since that time, I have repeatedly asked for a >> concrete pointer to the text that would make this unnecessary. >> >> No one has come forth with such a pointer. Given the harmless nature >> of redundantly specifying this requirement on implementations and the >> lack of concrete evidence for its removal, I am leaving the text >> as-is and removing the open issue from my list. > > Please. This is not harmless. > > The text under consideration is > > 6.1. VP8 > > For the VP8 codec, defined in [RFC6386], endpoints MUST support the > payload formats defined in [I-D.ietf-payload-vp8]. In addition they > MUST support the 'bilinear' and 'none' reconstruction filters. > > The problem with the text is not that it specifies that one MUST > support the "bilinear" and "none" filters. > > The problem with the text is that in order for it to make any sense at > all, one must believe that you can be conformant with RFC 6386 without > the ability to decode all the specified reconstruction filters - that > is, in order for the second sentence to make any sense at all, one > must believe that filters are optional. > > There is no hint in any place in RFC 6386 that a conformant decoder > can be conformant without the ability to decode bitstreams using all > the filter types. Filters are not optional for the decoder. > > This is the point I'm objecting to. > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Feb 13 09:56:33 2015 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 8BCF31A01A9 for ; Fri, 13 Feb 2015 09:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk-nGvNZP8Tp for ; Fri, 13 Feb 2015 09:56:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686A91A0046 for ; Fri, 13 Feb 2015 09:56:19 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1DHuHEk038931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 11:56:18 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DE3AC1.9060606@nostrum.com> Date: Fri, 13 Feb 2015 11:56:17 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephan Wenger , "rtcweb@ietf.org" References: <54DD26BF.4070408@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Video Open Issue #6: H.264 SEI messages 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 Feb 2015 17:56:31 -0000 On 2/13/15 03:54, Stephan Wenger wrote: > Sounds OK. Quick question for my education and to make sure: SDP CVO > refers to the presence of that RTP header extension that indicates > picture orientation, and not to a fixed orientation signaled in the > SDP, right? Yes. I've added some more text to hopefully make this clearer: When the use of the video orientation (CVO) RTP header extension is not signaled as part of the SDP, H.264 implementations MAY send and SHOULD support proper interpretation of Display Orientation SEI messages. /a From nobody Fri Feb 13 10:13:09 2015 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 712CF1A0199; Fri, 13 Feb 2015 10:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj4NU1nQxsqY; Fri, 13 Feb 2015 10:13:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 509341A1BCF; Fri, 13 Feb 2015 10:12:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213181223.13651.63786.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 10:12:23 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-video-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: Fri, 13 Feb 2015 18:13:07 -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 : WebRTC Video Processing and Codec Requirements Author : Adam Roach Filename : draft-ietf-rtcweb-video-04.txt Pages : 9 Date : 2015-02-13 Abstract: This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, as well as video codecs and their parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-video-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-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 Fri Feb 13 10:21:24 2015 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 203A41A0162 for ; Fri, 13 Feb 2015 10:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDfXxQ_x2xtc for ; Fri, 13 Feb 2015 10:21:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289501A0161 for ; Fri, 13 Feb 2015 10:21:20 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1DILJ9v040803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Feb 2015 12:21:19 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54DE409E.6080305@nostrum.com> Date: Fri, 13 Feb 2015 12:21:18 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] New version of video draft 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 Feb 2015 18:21:22 -0000 I just uploaded a -04 version of the video draft. This closes all of the open issues of which I am aware (see yesterday's messages for the resolution to the few items that had remained open in -03). New version here: https://tools.ietf.org/html/draft-ietf-rtcweb-video-04 Diff from previous here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-04.txt At this point, I consider the document functionally complete and ready for WGLC. /a From nobody Fri Feb 13 15:35:32 2015 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 AE67C1A0076 for ; Fri, 13 Feb 2015 15:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxqn6W94U5-A for ; Fri, 13 Feb 2015 15:35:26 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5291A0058 for ; Fri, 13 Feb 2015 15:35:25 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-17-54de8a3b0105 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.DB.04076.B3A8ED45; Sat, 14 Feb 2015 00:35:23 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.149]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Sat, 14 Feb 2015 00:35:22 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? Thread-Index: AdBHkzCQyzSQhofyQHmttIgUsDEyWAADccmAABDsDZA= Date: Fri, 13 Feb 2015 23:35:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D6CB3@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6D6CB3ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rte6616IwYNXkhYzLkxltlj7r53d gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZSxd/Jut4FNRxdXHgQ2MT/K7GDk5JARMJKYf mMsGYYtJXLi3Hsjm4hASOMIoseXgKmYIZwmjxLzzKxm7GDk42AQsJLr/aYM0iAioSvz9PpkJ xGYWUJe4s/gcO0iJsECJxLFpOhAlpRLLrrYzQ9hWEv0X1rGD2CxArT2zHoHt5RXwlTj48iDU qimMEp0zr4IlOAUCJSa0vwezGYGO+35qDdQucYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtpLE iu2XGCHq8yXeHG9ihFgmKHFy5hOWCYyis5CMmoWkbBaSsllA7zALaEqs36UPUaIoMaX7ITuE rSHROmcuO7L4Akb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBkXZwy2+rHYwHnzseYhTg YFTi4d2QcTdEiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M +efnbNJ98t7jrPXm1sTdf04rzO5ZH6a/6t/JLeFtuVdDOpdzhujf/7DPp2JnUJNRKtNWi8zH 0gtzf31Ltl3dV9sUd7kxYI6uyPQrF/1/7LYxaQl7t87/Tc6UN3mV82KarvdUNRtN0V7Lud19 odtECZXjwvprjopfSvRL+2UXzMF3kqO1rPudEktxRqKhFnNRcSIAa5e4/ZUCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 23:35:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6D6CB3ESESSMB208erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQpJbiB0aGUgVExTIHJvbGUgZGV0ZXJtaW5hdGlvbiBzZWN0aW9uIG9mIHRoZSBT RFAtU0NUUCBkcmFmdCwgdGhlIHRleHQgc2F5czoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAg4oCcT25jZSBhIERUTFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgaWYgdGhl ICdhY3RpdmUvcGFzc2l2ZScgc3RhdHVzIG9mIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBlbmRwb2ludHMgY2hhbmdlIChhcyByZXN1bHQgb2YgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hh bmdlKSBkdXJpbmcgYSBzZXNzaW9uLCBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5l dyBEVExTIGNvbm5lY3Rpb24gTVVTVCBiZSBlc3RhYmxpc2hlZC4gVGhlcmVmb3JlLCBlbmRwb2lu dHMgU0hPVUxEIE5PVCBjaGFuZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlICdh Y3RpdmUvcGFzc2l2ZScgc3RhdHVzIGR1cmluZyBhIHNlc3Npb24sIHVubGVzcyB0aGV5IHdhbnQg dG8gZXN0YWJsaXNoIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3IERUTFMgY29u bmVjdGlvbi7igJ0NCkkgaGF2ZSByZWNlaXZlZCBhIHF1ZXN0aW9uIHdoZXRoZXIgdGhpcyBhbHNv IGFmZmVjdHMgdGhlIHVuZGVybHlpbmcgVENQIGNvbm5lY3Rpb24gKGluIGNhc2Ugb2Yg4oCYVENQ L0RUTFMvU0NUUOKAmSkgYW5kIHRoZSBTQ1RQIGFzc29jaWF0aW9uIChpbiBjYXNlIG9mIOKAmFND VFAvRFRMU+KAmSkuDQpNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIE5PVCByZS1lc3RhYmxpc2gg dGhlIHVuZGVybHlpbmcgVENQL1NDVFAgYXNzb2NpYXRpb24ganVzdCBiZWNhdXNlIHRoZSBEVExT IGNvbm5lY3Rpb24gaXMgcmUtZXN0YWJsaXNoZWQuIEFsc28sIEkgY291bGQgbm90IGZpbmQgYW55 dGhpbmcgaW4gUkZDIDYwODMgdGhhdCB3b3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBTQ1RQIGFzc29j aWF0aW9uIHdvdWxkIGhhdmUgdG8gYmUgcmUtZXN0YWJsaXNoZWQuDQooSUYgYSB1c2VyIGFsc28g d2FudHMgdGhlIHVuZGVybHlpbmcgVENQL1NDVFAgYXNzb2NpYXRpb24gdG8gYmUgcmUtZXN0YWJs aXNoZWQsIGhlL3NoZSB1c2VzIHRoZSBTRFAgY29ubmVjdGlvbiBhdHRyaWJ1dGUgd2l0aCBhIOKA mG5ld+KAmSB2YWx1ZS4pDQoNCj5BcyBmYXIgYXMgSSBrbm93IHRoZSBvbmx5IHdheSB0byBkZW11 bHRpcGxleCBEVExTIHBhY2tldHMgaXMgYmFzZWQgb24gdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0 LiBVbmxlc3MgeW91IGNhbiA+Z3VhcmFudGVlIHRoYXQgbm8gcGFja2V0cyBmcm9tIHRoZSBwcmV2 aW91cyBEVExTIGNvbm5lY3Rpb24gd2lsbCBhcnJpdmUgb24gdGhlIG5ldyBjb25uZWN0aW9uIHJl dXNpbmcgdGhlIHNhbWUgPnVuZGVybHlpbmcgdHJhbnNwb3J0IHNvbWUgaW50ZXJlc3RpbmcgcHJv YmxlbXMgY2FuIG9jY3VyLg0KDQpEb27igJl0IHlvdSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gaW4g Y2FzZSBvZiBEVExTIHJlLWtleWluZz8NCg0KQUZBSVIsIERUTFMgY292ZXJzIHRoYXQgYnkgc3Rh dGluZyB0aGUgb2xkIGtleXMgc2hhbGwgYmUgc3RvcmVkIGZvciBhIHdoaWxlLCBpbiBjYXNlIHRo ZXJlIGFyZSBzb21lIOKAnGxhdGXigJ0gcGFja2V0cy4NCg0KPlVubGVzcyBzb21lb25lIHByb3Bv c2VzIGEgd2F5IHRvIGRlbXV4IHR3byBEVExTIGNvbm5lY3Rpb25zIG9uIHRoZSBzYW1lIHRyYW5z cG9ydCwgSSB3b3VsZCBzdWdnZXN0IHRoYXQgbmV3ID51bmRlcmx5aW5nIHRyYW5zcG9ydCBzaG91 bGQgYWx3YXlzIGJlIHVzZWQgZm9yIG5ldyBEVExTIGNvbm5lY3Rpb24gYW5kIHRoYXQgRFRMUyBj b25uZWN0aW9uIHNldHRpbmdzIHNob3VsZCBub3QgPmJlIGNoYW5nZWQgdW5sZXNzIHRoZSB0cmFu c3BvcnQgaXMgY2hhbmdlZCBhcyB3ZWxsLg0KDQpEb2VzIGFueW9uZSBoYXZlIGFuIG9waW5pb24g b24gdGhpcz8NCg0KKEkgZG9u4oCZdCBleHBlY3QgRFRMUyBjb25uZWN0aW9ucyB0byBiZSByZS1l c3RhYmxpc2hlZCBkdXJpbmcgYSBzZXNzaW9uIHZlcnkgZnJlcXVlbnRseS4pDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D6D6CB3ESESSMB208erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSb21hbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTEuM3B0Ij4NCkluIHRoZSBU TFMgcm9sZSBkZXRlcm1pbmF0aW9uIHNlY3Rpb24gb2YgdGhlIFNEUC1TQ1RQIGRyYWZ0LCB0aGUg dGV4dCBzYXlzOjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcT25jZSBhIERU TFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgaWYgdGhlICdhY3RpdmUvcGFzc2l2 ZScgc3RhdHVzIG9mIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludHMgY2hhbmdlIChhcyByZXN1bHQgb2YgYW4g b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlKSBkdXJpbmcgYSBzZXNzaW9uLCBhDQo8L3NwYW4+PHNwYW4g bGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBuZXcgRFRMUyBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQu IFRoZXJlZm9yZSwgZW5kcG9pbnRzIFNIT1VMRCBOT1QgY2hhbmdlDQo8L3NwYW4+PHNwYW4gbGFu Zz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgJ2FjdGl2ZS9wYXNzaXZlJyBzdGF0dXMgZHVyaW5nIGEgc2Vzc2lv biwgdW5sZXNzIHRoZXkgd2FudCB0byBlc3RhYmxpc2ggYQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkZJ Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MTEuM3B0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV3IERUTFMgY29ubmVjdGlvbi7igJ08L3Nw YW4+PHNwYW4gbGFuZz0iRkkiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTEuM3B0Ij4NCjxzcGFu IGxhbmc9IkVOLVVTIj5JIGhhdmUgcmVjZWl2ZWQgYSBxdWVzdGlvbiB3aGV0aGVyIHRoaXMgYWxz byBhZmZlY3RzIHRoZSB1bmRlcmx5aW5nIFRDUCBjb25uZWN0aW9uIChpbiBjYXNlIG9mIOKAmFRD UC9EVExTL1NDVFDigJkpIGFuZCB0aGUgU0NUUCBhc3NvY2lhdGlvbiAoaW4gY2FzZSBvZiDigJhT Q1RQL0RUTFPigJkpLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjExLjNwdCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyI+TXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBOT1QgcmUtZXN0 YWJsaXNoIHRoZSB1bmRlcmx5aW5nIFRDUC9TQ1RQIGFzc29jaWF0aW9uIGp1c3QgYmVjYXVzZSB0 aGUgRFRMUyBjb25uZWN0aW9uIGlzIHJlLWVzdGFibGlzaGVkLiBBbHNvLCBJIGNvdWxkIG5vdCBm aW5kIGFueXRoaW5nIGluIFJGQyA2MDgzIHRoYXQgd291bGQgaW5kaWNhdGUgdGhhdCB0aGUgU0NU UCBhc3NvY2lhdGlvbiB3b3VsZCBoYXZlIHRvIGJlDQogcmUtZXN0YWJsaXNoZWQuPC9zcGFuPjxz cGFuIGxhbmc9IkZJIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjExLjNwdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+KElGIGEgdXNlciBhbHNvIHdhbnRzIHRoZSB1bmRlcmx5aW5nIFRDUC9TQ1RQIGFz c29jaWF0aW9uIHRvIGJlIHJlLWVzdGFibGlzaGVkLCBoZS9zaGUgdXNlcyB0aGUgU0RQIGNvbm5l Y3Rpb24gYXR0cmlidXRlIHdpdGggYSDigJhuZXfigJkgdmFsdWUuKTwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPkFzIGZhciBhcyBJIGtub3cgdGhlIG9ubHkgd2F5 IHRvIGRlbXVsdGlwbGV4IERUTFMgcGFja2V0cyBpcyBiYXNlZCBvbiB0aGUgdW5kZXJseWluZyB0 cmFuc3BvcnQuIFVubGVzcyB5b3UgY2FuDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0 Ozwvc3Bhbj5ndWFyYW50ZWUgdGhhdCBubyBwYWNrZXRzIGZyb20gdGhlIHByZXZpb3VzIERUTFMg Y29ubmVjdGlvbiB3aWxsIGFycml2ZSBvbiB0aGUgbmV3IGNvbm5lY3Rpb24gcmV1c2luZyB0aGUg c2FtZQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+dW5kZXJseWluZyB0 cmFuc3BvcnQgc29tZSBpbnRlcmVzdGluZyBwcm9ibGVtcyBjYW4gb2NjdXIuPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+RG9u4oCZdCB5b3UgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtIGluIGNhc2Ugb2YgRFRMUyByZS1r ZXlpbmc/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFGQUlS LCBEVExTIGNvdmVycyB0aGF0IGJ5IHN0YXRpbmcgdGhlIG9sZCBrZXlzIHNoYWxsIGJlIHN0b3Jl ZCBmb3IgYSB3aGlsZSwgaW4gY2FzZSB0aGVyZSBhcmUgc29tZSDigJxsYXRl4oCdIHBhY2tldHMu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+VW5s ZXNzIHNvbWVvbmUgcHJvcG9zZXMgYSB3YXkgdG8gZGVtdXggdHdvIERUTFMgY29ubmVjdGlvbnMg b24gdGhlIHNhbWUgdHJhbnNwb3J0LCBJIHdvdWxkIHN1Z2dlc3QgdGhhdCBuZXcNCjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnVuZGVybHlpbmcgdHJhbnNwb3J0IHNob3Vs ZCBhbHdheXMgYmUgdXNlZCBmb3IgbmV3IERUTFMgY29ubmVjdGlvbiBhbmQgdGhhdCBEVExTIGNv bm5lY3Rpb24gc2V0dGluZ3Mgc2hvdWxkIG5vdA0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZndDs8L3NwYW4+YmUgY2hhbmdlZCB1bmxlc3MgdGhlIHRyYW5zcG9ydCBpcyBjaGFuZ2VkIGFz IHdlbGwuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+RG9lcyBhbnlvbmUgaGF2ZSBhbiBvcGluaW9uIG9uIHRoaXM/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4oSSBkb27igJl0IGV4 cGVjdCBEVExTIGNvbm5lY3Rpb25zIHRvIGJlIHJlLWVzdGFibGlzaGVkIGR1cmluZyBhIHNlc3Np b24gdmVyeSBmcmVxdWVudGx5Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D6D6CB3ESESSMB208erics_-- From nobody Fri Feb 13 15:38:17 2015 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 272EF1A0076 for ; Fri, 13 Feb 2015 15:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Sa785AnRp2 for ; Fri, 13 Feb 2015 15:38:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F93E1A0058 for ; Fri, 13 Feb 2015 15:38:08 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-e0-54de8ade4f97 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AD.1C.04076.EDA8ED45; Sat, 14 Feb 2015 00:38:06 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.149]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Sat, 14 Feb 2015 00:38:06 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? Thread-Index: AdBHkzCQyzSQhofyQHmttIgUsDEyWAABkt2AABMR47A= Date: Fri, 13 Feb 2015 23:38:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <54DE185D.9060402@alvestrand.no> In-Reply-To: <54DE185D.9060402@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvje69rnshBlfnqFoc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4MrY1n2cvWARX0XPwdXsDYy9PF2MHBwSAiYS F95ZdTFyApliEhfurWfrYuTiEBI4wijx41s/K0hCSGAJo8Tt19Ig9WwCFhLd/7RBwiICwRK9 z98zgoSFBUokjk3TgQiXSiy72s7cxcgOZFtJzEkHibIIqEqc6b7AAmLzCvhKHDs4hxFidoHE 9XM7wPZwCuhKvD3ykBnEZgQ65vupNUwgNrOAuMStJ/OZII4UkFiy5zwzhC0q8fLxP1YIW0li xfZLjBD1ehI3pk5hg7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxa XJybbmSkl1qUmVxcnJ+nl5dasokRGB0Ht/y22sF48LnjIUYBDkYlHt4NGXdDhFgTy4orcw8x SnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6Bhy/uOVqVIfRU153nLM+X2Y e9n2iPAX1f5FuboqRpW9YmXFspFe/z1qrk0XC9umHukyp+jy28fTsqUEVyo5vuXi7tGZG8zp fbIi1jJdT3rD4Yfdx3V+Pjrz4LAF/8mSvswnwbaXvfYKn71X2Kv4fvlLCQerVGPV/a5OTeVn J6u2SSzzmLtMiaU4I9FQi7moOBEA8Qbnfm8CAAA= Archived-At: Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 23:38:11 -0000 Hi Harald, =A0 >>In the TLS role determination section of the SDP-SCTP draft, the text say= s: >>=A0 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 "Once a DTLS connection has been established, if the 'active/p= assive' status of the >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 endpoints change (as result of an offer/answer exchange) durin= g a session, a=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 new DTLS connection MUST be established. Therefore, endpoints = SHOULD NOT change=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 the 'active/passive' status during a session, unless they want= to establish a=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 new DTLS connection." >>=A0 >> I have received a question whether this also affects the underlying TCP = connection (in case of 'TCP/DTLS/SCTP') and the SCTP=20 >> association (in case of 'SCTP/DTLS'). >> >>My suggestion would be to NOT re-establish the underlying TCP/SCTP associ= ation just because the DTLS connection is re->>established. Also, I could n= ot find anything in RFC 6083 that would indicate that the SCTP association = would have to be re->>established. > >Seems reasonable to me - but since this is an MMUSIC draft (draft-ietf-mmu= sic-sctp-sdp) and has the potential to be used >outside of RTCWEB, shoudn't= this go on the mmusic mailing list? They will have their chance to comment during WGLC :) Seriously, the reason I brought it here first is because the people actuall= y implementing this (for WebRTC Data Channels) are more likely to be found = here. Regards, Christer From nobody Fri Feb 13 16:14:35 2015 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 EDAE61A00F9 for ; Fri, 13 Feb 2015 16:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_ZAHS24EuPu for ; Fri, 13 Feb 2015 16:14:32 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C611A00A9 for ; Fri, 13 Feb 2015 16:14:32 -0800 (PST) Received: by iecrl12 with SMTP id rl12so20930986iec.4 for ; Fri, 13 Feb 2015 16:14:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sNmBBrkjgZ9gT6DHrvqJbzBlHLZXDUHsgGDi2XgavlY=; b=Belm9ZPiEMUUzv4NBfiJICXe+NPPgy0lt0UPMj5pzi5HKuaebAR8jqlUIzOgFz3Mi3 mxij3yaln8UrgRbpHcXDKN/JEg3I0ghgw+nMmri/MRJvYtfxdrqHrkU/TZZHTF1dvBTd 3b7z2f7CoHKvlNyySxsmB1IrHBz8had+lcymCmzA53NFQO0UV0DfKRt0nkV5ECEUeqv9 T/GZgMINe45TmcITQB2UN2W5CvQrgFdNydbzYSj+M+7NvcLhKQLo+dESKbnNWWYcwQ7K Q7Gn9yjPBFwxmn3NuJmuK4F0zOdXF2Vwq1Ypdjimow4ZAJ/2lMFV8hEgMoO3c4mSeqkz JFDA== X-Gm-Message-State: ALoCoQnCBJlx9UeXP4ybvkDbeoZO0DPbdd6LK/GEkCIWcYG7jbPHqq6AHZB+wT2rheI0zOJc5Aw7 X-Received: by 10.43.78.132 with SMTP id zm4mr12272173icb.81.1423872871534; Fri, 13 Feb 2015 16:14:31 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by mx.google.com with ESMTPSA id k13sm2073676iod.38.2015.02.13.16.14.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 16:14:30 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id l13so19324436iga.1 for ; Fri, 13 Feb 2015 16:14:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.136.69 with SMTP id k66mr8595524iod.18.1423872869328; Fri, 13 Feb 2015 16:14:29 -0800 (PST) Received: by 10.36.20.10 with HTTP; Fri, 13 Feb 2015 16:14:29 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D6CB3@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6D6CB3@ESESSMB208.ericsson.se> Date: Fri, 13 Feb 2015 19:14:29 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113ed13094f157050f013c14 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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, 14 Feb 2015 00:14:34 -0000 --001a113ed13094f157050f013c14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2015 at 6:35 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Don=E2=80=99t you have the same problem in case of DTLS re-keying? > You do have the same problem in case of DTLS re-key. This is why none of the current browser implementations actually support it. At this point I would be very curious to see if anybody implemented DTLS re-key or re-negotiation over the same transport and would very much appreciate if they tell us how exactly they did this. Regards, _____________ Roman Shpount --001a113ed13094f157050f013c14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 13, 2015 at 6:35 PM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:

Don=E2=80=99t you have the same problem in c= ase of DTLS re-keying?


You do have the same problem in case of DTLS re-key. This is why none of= the current browser implementations actually support it. At this point I w= ould be very curious to see if anybody implemented DTLS re-key or re-negoti= ation over the same transport and would very much appreciate if they tell u= s how exactly they did this.

Regards,=C2=A0
<= div>
_____________
Roman Shpount
=C2=A0
--001a113ed13094f157050f013c14-- From nobody Fri Feb 13 16:30:05 2015 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 2577F1A00A9 for ; Fri, 13 Feb 2015 16:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jHYz2lKUorX for ; Fri, 13 Feb 2015 16:30:01 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBAC1A038C for ; Fri, 13 Feb 2015 16:30:00 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id l18so16627504wgh.7 for ; Fri, 13 Feb 2015 16:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VmguVBNFom1gwGXigi7CMYCNbtWksIgOKTfyhnG039A=; b=yVGuF512jZ20jdoWUsZilmikKPaj/qYHcLRoEeQL8SDnEc31puBNavC/NHVMeU5tuL Zw2HXA6wr9w3NQFvfcUno8PCeO+jN/bVseIq+NFJQUCXHIJ81sw/yaRM9oBecl9SPrOj Giv/JRgjvUNwct+MeFDaqdF9LqiGGjxZPg1SXIM8/EVHXl1cY1YrGpwHVJmhF20P7Xpo JWAGmjDTkg+huK+LRgmP6fyzyr+beJKmCXPKgpZJdb6xSO0RrFwHWIflkS/SZ8tnKDqs +xllp3n6e4LU0CSwMsbThpvg8MItRVPXWG5w7ayCa47u2R8cJo0P1vCmevhVe7Agkjuu CoTA== X-Received: by 10.180.20.52 with SMTP id k20mr1908696wie.15.1423873799091; Fri, 13 Feb 2015 16:29:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.8 with HTTP; Fri, 13 Feb 2015 16:29:38 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <54DE185D.9060402@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.ericsson.se> From: Bernard Aboba Date: Fri, 13 Feb 2015 16:29:38 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec53f3717fffc93050f0173fc Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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, 14 Feb 2015 00:30:04 -0000 --bcaec53f3717fffc93050f0173fc Content-Type: text/plain; charset=UTF-8 Harald said: "My suggestion would be to NOT re-establish the underlying TCP/SCTP association just because the DTLS connection is re->>established. Also, I could not find anything in RFC 6083 that would indicate that the SCTP association would have to be re->>established." [BA] There is no reason to re-establish the underlying TCP/SCTP association due to DTLS connection re-establishment or ICE re-start. Similarly, there is no reason a DTLS connection should need to be re-established just because of an ICE re-start. On Fri, Feb 13, 2015 at 3:38 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Harald, > > >>In the TLS role determination section of the SDP-SCTP draft, the text > says: > >> > >> "Once a DTLS connection has been > established, if the 'active/passive' status of the > >> endpoints change (as result of an > offer/answer exchange) during a session, a > >> new DTLS connection MUST be established. > Therefore, endpoints SHOULD NOT change > >> the 'active/passive' status during a > session, unless they want to establish a > >> new DTLS connection." > >> > >> I have received a question whether this also affects the underlying TCP > connection (in case of 'TCP/DTLS/SCTP') and the SCTP > >> association (in case of 'SCTP/DTLS'). > >> > >>My suggestion would be to NOT re-establish the underlying TCP/SCTP > association just because the DTLS connection is re->>established. Also, I > could not find anything in RFC 6083 that would indicate that the SCTP > association would have to be re->>established. > > > >Seems reasonable to me - but since this is an MMUSIC draft > (draft-ietf-mmusic-sctp-sdp) and has the potential to be used >outside of > RTCWEB, shoudn't this go on the mmusic mailing list? > > They will have their chance to comment during WGLC :) > > Seriously, the reason I brought it here first is because the people > actually implementing this (for WebRTC Data Channels) are more likely to be > found here. > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec53f3717fffc93050f0173fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Harald said:=C2=A0

"My suggestion would be to NOT re-establish t= he underlying TCP/SCTP association just because the DTLS connection is re-&= gt;>established. Also, I could not find anything in RFC 6083 that would = indicate that the SCTP association would have to be re->>established.= "

[BA] There is no reason to re-establ= ish the underlying TCP/SCTP association due to DTLS connection re-establish= ment or ICE re-start.=C2=A0 Similarly, there is no reason a DTLS connection= should need to be re-established just because of an ICE re-start. =C2=A0

On Fri,= Feb 13, 2015 at 3:38 PM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi= Harald,
=C2=A0
>>In the TLS role determination section of the SDP-SCTP draft, the te= xt says:
>>=C2=A0
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "Once a DTLS connection has been establish= ed, if the 'active/passive' status of the
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoints change (as result of an offer/answer = exchange) during a session, a
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 new DTLS connection MUST be established. Theref= ore, endpoints SHOULD NOT change
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 the 'active/passive' status during a se= ssion, unless they want to establish a
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 new DTLS connection."
>>=C2=A0
>> I have received a question whether this also affects the underlyin= g TCP connection (in case of 'TCP/DTLS/SCTP') and the SCTP
>> association (in case of 'SCTP/DTLS').
>>
>>My suggestion would be to NOT re-establish the underlying TC= P/SCTP association just because the DTLS connection is re->>establish= ed. Also, I could not find anything in RFC 6083 that would indicate that th= e SCTP association would have to be re->>established.
>
>Seems reasonable to me - but since this is an MMUSIC draft (draft-ietf-= mmusic-sctp-sdp) and has the potential to be used >outside of RTCWEB, sh= oudn't this go on the mmusic mailing list?

They will have their chance to comment during WGLC :)

Seriously, the reason I brought it here first is because the people actuall= y implementing this (for WebRTC Data Channels) are more likely to be found = here.

Regards,

Christer

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

--bcaec53f3717fffc93050f0173fc-- From nobody Sat Feb 14 14:19:23 2015 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 46E841A01F4 for ; Sat, 14 Feb 2015 14:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 2HKyWPBSAjtH for ; Sat, 14 Feb 2015 14:19:20 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641611A01D8 for ; Sat, 14 Feb 2015 14:19:20 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id k14so13132354wgh.3 for ; Sat, 14 Feb 2015 14:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/AZf0s/yP0fvYBCfx5Q3Bw/v92T+82hRR18jnlvUXII=; b=jkG5T2AEAgaX/CcWHRcFeqnqq7wi3X4MtVo3t/sNlbIRzpkXLGHboQpWOnfzjGbtmk yesGMyb0Wy0OIV9uQREHM3VVnRh0EAHEl1qoavcPs1/wbzbtD3XcM8j8iArrT3mCCKrj QLf65sgWOjfC+Ht1LhHD4lEELHkRl0FBo4TdRldQQpFm1x/q9ngz1jJuZV3+UzgBRznh 2YR+aS/3XHwdnDXRFkLod+5M1o8R3RzPENpDe7FXc5m2coRvojkOHx+sOUuEKRxVtzfu vFXwXtXXc/J6t+ssIdpWEOzdmHMGlqfJolYnie3WEw6wzQIn09O2jsXb/56UDl3jebmH V6PQ== X-Received: by 10.194.243.1 with SMTP id wu1mr34684582wjc.69.1423952359135; Sat, 14 Feb 2015 14:19:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.8 with HTTP; Sat, 14 Feb 2015 14:18:58 -0800 (PST) From: Bernard Aboba Date: Sat, 14 Feb 2015 14:18:58 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1d528b1ed0050f13befd Archived-At: Subject: [rtcweb] Question about draft-ietf-rtcweb-stun-consent-freshness-11 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, 14 Feb 2015 22:19:22 -0000 --089e013d1d528b1ed0050f13befd Content-Type: text/plain; charset=UTF-8 >From Section 4.1: Initial consent to send traffic is obtained using ICE. Consent expires after 30 seconds. That is, if a valid STUN binding response corresponding to any STUN request sent in the last 30 seconds has not been received from the remote peer's transport address, the endpoint MUST cease transmission on that 5-tuple. STUN consent responses received after consent expiry do not re-establish consent, and may be discarded or cause an ICMP error. [BA] Let us say that peer A sends STUN requests to peer B. Request 1 does not receive a response within 30 seconds, but Request 2 (sent 5 seconds later) does receive a response. Does that mean that peer A considers consent revoked 30 seconds after sending Request 1, even though it has since gotten a response? This does not make sense to me. --089e013d1d528b1ed0050f13befd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From Section 4.1:=C2=A0

=
   Initial consent to send traffic is obtained using ICE.  Consent
   expires after 30 seconds.  That is, if a valid STUN binding response
   corresponding to any STUN request sent in the last 30 seconds has not
   been received from the remote peer's transport address, the endpoint
   MUST cease transmission on that 5-tuple.  STUN consent responses
   received after consent expiry do not re-establish consent, and may be
   discarded or cause an ICMP error.

[BA] Let us say that peer A sends STUN requests to peer B.  Request =
1
does not receive a response within 30 seconds, but Re=
quest 2 (sent 5 seconds later) does receive a response.  Does that mean tha=
t peer A considers consent revoked 30 seconds after sending Request 1, even=
 though it has since gotten a response? =C2=A0

This does not make sense to me.
--089e013d1d528b1ed0050f13befd-- From nobody Sat Feb 14 14:46:13 2015 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 16F5D1A0217 for ; Sat, 14 Feb 2015 14:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4YJK2P3IPpS for ; Sat, 14 Feb 2015 14:46:07 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33651A01D8 for ; Sat, 14 Feb 2015 14:46:06 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-95-54dfd02c3ca3 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CC.A8.04231.C20DFD45; Sat, 14 Feb 2015 23:46:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Sat, 14 Feb 2015 23:46:03 +0100 From: Christer Holmberg To: Bernard Aboba , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question about draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQSKRNlKytiS9vqECbLcvShiZO+Zzwvrya Date: Sat, 14 Feb 2015 22:46:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6ED86E@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6ED86EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja7OhfshBpsbRSw27PvPbLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxf4VXwUu1ivWr7jE2MP5S6GLk5JAQMJF4 9u8rO4QtJnHh3nq2LkYuDiGBI4wS+5o6WCCcJYwS+5dvYu5i5OBgE7CQ6P6nDdIgIhAk0da1 kBHEFgayt65rZIeIB0vs3LGcFaRcRMBIomkNB0iYRUBV4lbPIjaQMK+Ar0Tjbz2QsJBAgMTr 92vApnAKBErcPNnKBGIzAp3z/dQaMJtZQFyi6ctKVogzBSSW7DnPDGGLSrx8/I8VoiZf4vDM ZrA4r4CgxMmZT1gmMArPQtI+C0nZLCRlEHEDiS/vb0PZ2hLLFr5mhrD1Jbrfn2ZCFl/AyL6K UbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzByDm75rbuDcfVrx0OMAhyMSjy8BrvuhQixJpYV V+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTG7wWaniBnruUMXCg9n JXi+2VokxPcv8tHStyfyVUQf77yVYWBnb3tDqN/PTmkGF+9VvU+nWq3OPM290KDzoFknY51+ UmPWz/q9W8VZnkiceMYUV7KW98QFbW3rX//lNr3YKbPh2Ja6pE88372kb7y+dvHDkqsSUx/u d2PY+7dmedz9N00fN4UpsRRnJBpqMRcVJwIA8c23in0CAAA= Archived-At: Subject: Re: [rtcweb] Question about draft-ietf-rtcweb-stun-consent-freshness-11 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, 14 Feb 2015 22:46:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6ED86EESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Bernard, I had the same comment some time ago. But, note that the text now says "response to *any* STUN request", meaning = that as long as you receive a response to at least one STUN request that wa= s sent in the last 30 seconds you are ok, and consent will not expire. Regards, Christer Sent from my Windows Phone ________________________________ From: Bernard Aboba Sent: =FD15/=FD02/=FD2015 00:19 To: rtcweb@ietf.org Subject: [rtcweb] Question about draft-ietf-rtcweb-stun-consent-freshness-1= 1 >From Section 4.1: Initial consent to send traffic is obtained using ICE. Consent expires after 30 seconds. That is, if a valid STUN binding response corresponding to any STUN request sent in the last 30 seconds has not been received from the remote peer's transport address, the endpoint MUST cease transmission on that 5-tuple. STUN consent responses received after consent expiry do not re-establish consent, and may be discarded or cause an ICMP error. [BA] Let us say that peer A sends STUN requests to peer B. Request 1 does not receive a response within 30 seconds, but Request 2 (sent 5 second= s later) does receive a response. Does that mean that peer A considers con= sent revoked 30 seconds after sending Request 1, even though it has since g= otten a response? This does not make sense to me. --_000_7594FB04B1934943A5C02806D1A2204B1D6ED86EESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Bernard,
I had the same comment some time ago.

But, note that the text now says "response to *any* STUN request"= , meaning that as long as you receive a response to at least one STUN reque= st that was sent in the last 30 seconds you are ok, and consent will not ex= pire.

Regards,

Christer

Sent from my Windows Phone
From: Bernard Aboba
Sent: =FD15= /=FD02/=FD2015 00:19
To: rtcweb@ietf.org
Subject: [rtcw= eb] Question about draft-ietf-rtcweb-stun-consent-freshness-11

From Section 4.1:  

   Initial consent to send traffic is obtained using ICE.=
  Consent
   expires after 30 seconds.  That is, if a valid STUN binding response
   corresponding to any STUN request sent in the last 30 seconds has not
   been received from the remote peer's transport address, the endpoint
   MUST cease transmission on that 5-tuple.  STUN consent responses
   received after consent expiry do not re-establish consent, and may be
   discarded or cause an ICMP error.

[BA] Let us say that peer A sends STUN requests to peer B=
.  Request 1
does not receive a response within 30 seconds, but Reques=
t 2 (sent 5 seconds later) does receive a response.  Does that mean that pe=
er A considers consent revoked 30 seconds after sending Request 1, even tho=
ugh it has since gotten a response?  

This does not make sense to me.
--_000_7594FB04B1934943A5C02806D1A2204B1D6ED86EESESSMB209erics_-- From nobody Mon Feb 16 05:55:33 2015 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 E55091A1B07 for ; Mon, 16 Feb 2015 05:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHOJ-4x3-h12 for ; Mon, 16 Feb 2015 05:55:29 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB8E1A1ADA for ; Mon, 16 Feb 2015 05:55:28 -0800 (PST) Received: by labms9 with SMTP id ms9so22688234lab.10 for ; Mon, 16 Feb 2015 05:55:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YMFgfpzEpRseQFw6rZ8ZCCystimFmoXk7Chov55MspM=; b=YPMgmgjrqwAXFObcxTYXeNh12fyb/oxSX4MapA8y+nQd4qOAGFbBFbEXs8WgqpoJAz 4BvwjCjWaPGyW/ePMSyEEFkhJFi/xtaFCpDXH6NXVroErftphIWforP4UcnBwwi1cbUY Hbtrw/szevAbeI7mlLDPh0tiMVaEm31FfMoVVCbXWgzampLrVBhlDb4q10RRMAnKfZTp D9d+caVJ3XObOTz7eH7xUG13r+RZ2j2kPx2hApZUjK3WSp31lXNJAGKCBiaTuVyVrRN3 eykUFmYTV7DvUKivLvCYh6cEmIRFH2XYxHwooXPD10xOXL2KZ6/S21Z335cUjUCJvYk+ 5LFg== X-Gm-Message-State: ALoCoQmmr2WwAvcz51kE5nKzLGhOFrfHc2QvI165rc5v+XgdQq/hWD5fgL7K4Gn77GD5YGHhe1Yx MIME-Version: 1.0 X-Received: by 10.152.36.232 with SMTP id t8mr22492694laj.90.1424094927239; Mon, 16 Feb 2015 05:55:27 -0800 (PST) Received: by 10.25.205.135 with HTTP; Mon, 16 Feb 2015 05:55:27 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6D6CB3@ESESSMB208.ericsson.se> Date: Mon, 16 Feb 2015 08:55:27 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=089e0160a9d243d0dc050f34f04a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 13:55:32 -0000 --089e0160a9d243d0dc050f34f04a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2015 at 7:14 PM, Roman Shpount wrote: > On Fri, Feb 13, 2015 at 6:35 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Don=E2=80=99t you have the same problem in case of DTLS re-keying? >> > > You do have the same problem in case of DTLS re-key. This is why none of > the current browser implementations actually support it. At this point I > would be very curious to see if anybody implemented DTLS re-key or > re-negotiation over the same transport and would very much appreciate if > they tell us how exactly they did this. > Uh? I did implement DTLS re-key / re-negotiation as specified. Then I tested it. It works. I don't know what problem you're alluding to. Simon --089e0160a9d243d0dc050f34f04a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Feb 13, 2015 at 7:14 PM, Roman Shpount <roman@telurix.com><= /span> wrote:
On Fri, Fe= b 13, 2015 at 6:35 PM, Christer Holmberg <christer.holmberg@e= ricsson.com> wrote:

Don=E2=80=99t you have the same problem in c= ase of DTLS re-keying?


You do have the same problem in case of DTLS re-key. This is why = none of the current browser implementations actually support it. At this po= int I would be very curious to see if anybody implemented DTLS re-key or re= -negotiation over the same transport and would very much appreciate if they= tell us how exactly they did this.

Uh?

I did impleme= nt DTLS re-key / re-negotiation as specified. Then I tested it. It works. I= don't know what problem you're alluding to.

Simon
--089e0160a9d243d0dc050f34f04a-- From nobody Mon Feb 16 06:44:53 2015 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 CAE9D1A1B0A for ; Mon, 16 Feb 2015 06:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOrhoZ0hUO6Z for ; Mon, 16 Feb 2015 06:44:48 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BB41A1B5F for ; Mon, 16 Feb 2015 06:44:46 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 683B94CA4A621; Mon, 16 Feb 2015 14:44:40 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t1GEifgS022894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 09:44:41 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 09:44:41 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Bernard Aboba , Christer Holmberg Thread-Topic: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? Thread-Index: AdBHkzCQyzSQhofyQHmttIgUsDEyWAAOJYOAABEP+wAAAcy+AAB3JSvA Date: Mon, 16 Feb 2015 14:44:40 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <54DE185D.9060402@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.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.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E6F8D11US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 14:44:52 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E6F8D11US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+PiJNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIE5PVCByZS1lc3RhYmxpc2ggdGhlIHVuZGVy bHlpbmcgVENQL1NDVFAgYXNzb2NpYXRpb24ganVzdCBiZWNhdXNlIHRoZSBEVExTIGNvbm5lY3Rp b24gaXMgcmUtPj5lc3RhYmxpc2hlZC4gQWxzbywgSSBjb3VsZCBub3QgZmluZCBhbnl0aGluZyBp biBSRkMgNjA4MyB0aGF0IHdvdWxkIGluZGljYXRlIHRoYXQgdGhlIFNDVFAgYXNzb2NpYXRpb24g d291bGQgaGF2ZSB0byBiZSByZS0+PmVzdGFibGlzaGVkLiINCltSYWp1XSBJIHRoaW5rIHRoZSBk ZWNpc2lvbiB0byByZS1lc3RhYmxpc2ggVENQL1NDVFAgc2hvdWxkIGJlIHBlciBhPWNvbm5lY3Rp b24gYXR0cmlidXRlLiBBIHZhbHVlIOKAnG5ld+KAnSBzaG91bGQgdHJpZ2dlciBib3RoIFRDUCBh bmQgU0NUUCByZS1lc3RhYmxpc2htZW50IChpbmRlcGVuZGVudCBvZiBEVExTIHJlLWVzdGFibGlz aG1lbnQpLg0KUGVyIHRoZSBTRFAtU0NUUCAxMC4zIGFuZCAxMC40Og0KDQotICAgICAgICAgIGE9 c2V0dXAgYXBwbGllcyB0byBUQ1AgYW5kIERUTFMgb25seSAobm90IFNDVFApLg0KDQotICAgICAg ICAgIGE9Y29ubmVjdGlvbiBhcHBsaWVzIHRvIFRDUCBhbmQgU0NUUCAobm90IERUTFMpDQpTbywg aWYgYSBjbGllbnQgd2FudHMgdG8gcmUtZXN0YWJsaXNoIERUTFMgb25seSB0aGVuIGl0IHNob3Vs ZCBpbmNsdWRlIOKAnGE9Y29ubmVjdGlvbjpleGlzdGluZ+KAnS4NCklmIGEgY2xpZW50IHdhbnRz IHRvIHJlLWVzdGFibGlzaCBEVExTIGFsb25nIHdpdGggVENQL1NDVFAgdGhlbiBpdCBzaG91bGQg aW5jbHVkZSDigJxhPWNvbm5lY3Rpb246bmV34oCdLg0KSW4gZWl0aGVyIGNhc2UgcmVsZXZhbnQg YT1zZXR1cCBhdHRyaWJ1dGVzIG11c3QgYmUgaW5jbHVkZSB0byB0cmlnZ2VyIERUTFMgcmUtZXN0 YWJsaXNobWVudC4NCg0KPkFzIGZhciBhcyBJIGtub3cgdGhlIG9ubHkgd2F5IHRvIGRlbXVsdGlw bGV4IERUTFMgcGFja2V0cyBpcyBiYXNlZCBvbiB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQuID5V bmxlc3MgeW91IGNhbiA+Z3VhcmFudGVlIHRoYXQgbm8gcGFja2V0cyBmcm9tIHRoZSBwcmV2aW91 cyBEVExTIGNvbm5lY3Rpb24gd2lsbCBhcnJpdmUgb24gdGhlID5uZXcgY29ubmVjdGlvbiByZXVz aW5nIHRoZSBzYW1lID51bmRlcmx5aW5nIHRyYW5zcG9ydCBzb21lIGludGVyZXN0aW5nIHByb2Js ZW1zIGNhbiBvY2N1ci4NCltSYWp1XSBJIGJlbGlldmUgcGFja2V0cyBmcm9tIG9sZCBEVExTIGNv bm5lY3Rpb24gYXBwZWFyaW5nIG9uIG5ldyB3aWxsIGJlIGRyb3BwZWQgdGhlIHNhbWUgd2F5IERU TFMgcmVrZXlpbmcgaGFuZGxlcyBwYWNrZXRzIHVzaW5nIG9sZCBrZXkgYWZ0ZXIgTVNMIHRpbWVv dXQgWzFdLiBTbywgSSBkb27igJl0IHRoaW5rIGEgbmV3IFRDUC9TQ1RQIHRyYW5zcG9ydCBjb25u ZWN0aW9uIG5lZWQgdG8gYmUgZXN0YWJsaXNoZWQuDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNTc2NCNzZWN0aW9uLTUuMg0KICAgQmVjYXVzZSBvZiBwYWNrZXQgcmVvcmRl cmluZywgcGFja2V0cyBwcm90ZWN0ZWQgYnkgdGhlIHByZXZpb3VzIHNldA0KICAgb2Yga2V5cyBj YW4gYXBwZWFyIG9uIHRoZSB3aXJlIGFmdGVyIHRoZSBoYW5kc2hha2UgaGFzIGNvbXBsZXRlZC4g IFRvDQogICBjb21wZW5zYXRlIGZvciB0aGlzIGZhY3QsIHJlY2VpdmVycyBTSE9VTEQgbWFpbnRh aW4gYm90aCBzZXRzIG9mIGtleXMNCiAgIGZvciBzb21lIHRpbWUgaW4gb3JkZXIgdG8gYmUgYWJs ZSB0byBkZWNyeXB0IGFuZCB2ZXJpZnkgb2xkZXINCiAgIHBhY2tldHMuICBUaGUga2V5cyBzaG91 bGQgYmUgbWFpbnRhaW5lZCBmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZQ0KICAgbWF4aW11bSBzZWdt ZW50IGxpZmV0aW1lIChNU0wpLg0K4oCmDQoNCklmIHRoZSBhdXRoZW50aWNhdGlvbiBjaGVjayBv biB0aGUgcGFja2V0IGZhaWxzDQoNCiAgIGFuZCBubyBNS0kgaXMgYmVpbmcgdXNlZCwgdGhlbiB0 aGUgcmVjZWl2ZXIgTUFZIHByb2Nlc3MgdGhlIHBhY2tldA0KDQogICB3aXRoIHRoZSBvbGRlciBz ZXQgb2Yga2V5cy4gIElmIHRoYXQgYXV0aGVudGljYXRpb24gY2hlY2sgaW5kaWNhdGVzDQoNCiAg IHRoYXQgdGhlIHBhY2tldCBpcyB2YWxpZCwgdGhlIHBhY2tldCBzaG91bGQgYmUgYWNjZXB0ZWQ7 IG90aGVyd2lzZSwNCg0KICAgdGhlIHBhY2tldCBNVVNUIGJlIGRpc2NhcmRlZCBhbmQgcmVqZWN0 ZWQuDQoNCg0KQlINClJhanUNCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E6F8D11US70UWXCHMBA02z_ 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 dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTkwNjgzNjMz Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MDkyNjY3 ODQgLTIyNzM2NDg4NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjIxNTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZxdW90OzxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPk15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gTk9UIHJl LWVzdGFibGlzaCB0aGUgdW5kZXJseWluZyBUQ1AvU0NUUCBhc3NvY2lhdGlvbiBqdXN0IGJlY2F1 c2UgdGhlIERUTFMgY29ubmVjdGlvbiBpcyByZS0mZ3Q7Jmd0O2VzdGFibGlzaGVkLiBBbHNvLCBJ IGNvdWxkIG5vdCBmaW5kIGFueXRoaW5nIGluIFJGQyA2MDgzIHRoYXQgd291bGQgaW5kaWNhdGUg dGhhdCB0aGUNCiBTQ1RQIGFzc29jaWF0aW9uIHdvdWxkIGhhdmUgdG8gYmUgcmUtJmd0OyZndDtl c3RhYmxpc2hlZC48L3NwYW4+JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1JhanVdIEkg dGhpbmsgdGhlIGRlY2lzaW9uIHRvIHJlLWVzdGFibGlzaCBUQ1AvU0NUUCBzaG91bGQgYmUgcGVy IGE9Y29ubmVjdGlvbiBhdHRyaWJ1dGUuIEEgdmFsdWUg4oCcbmV34oCdIHNob3VsZCB0cmlnZ2Vy IGJvdGggVENQIGFuZCBTQ1RQIHJlLWVzdGFibGlzaG1lbnQgKGluZGVwZW5kZW50DQogb2YgRFRM UyByZS1lc3RhYmxpc2htZW50KS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBlciB0 aGUgU0RQLVNDVFAgMTAuMyBhbmQgMTAuNDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5hPXNldHVwIGFwcGxpZXMgdG8gVENQIGFuZCBEVExTIG9ubHkgKG5vdCBTQ1RQKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hPWNvbm5lY3Rpb24gYXBwbGll cyB0byBUQ1AgYW5kIFNDVFAgKG5vdCBEVExTKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TbywgaWYgYSBjbGllbnQgd2FudHMgdG8gcmUtZXN0YWJsaXNoIERUTFMgb25seSB0aGVuIGl0 IHNob3VsZCBpbmNsdWRlIOKAnGE9Y29ubmVjdGlvbjpleGlzdGluZ+KAnS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SWYgYSBjbGllbnQgd2FudHMgdG8gcmUtZXN0YWJsaXNoIERUTFMg YWxvbmcgd2l0aCBUQ1AvU0NUUCB0aGVuIGl0IHNob3VsZCBpbmNsdWRlIOKAnGE9Y29ubmVjdGlv bjpuZXfigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGVpdGhlciBjYXNlIHJl bGV2YW50IGE9c2V0dXAgYXR0cmlidXRlcyBtdXN0IGJlIGluY2x1ZGUgdG8gdHJpZ2dlciBEVExT IHJlLWVzdGFibGlzaG1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ QXMgZmFyIGFzIEkga25vdyB0aGUgb25seSB3YXkgdG8gZGVtdWx0aXBsZXggRFRMUyBwYWNrZXRz IGlzIGJhc2VkIG9uIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydC4gJmd0O1VubGVzcyB5b3UgY2Fu DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5ndWFyYW50ZWUgdGhhdCBu byBwYWNrZXRzIGZyb20gdGhlIHByZXZpb3VzIERUTFMgY29ubmVjdGlvbiB3aWxsIGFycml2ZSBv biB0aGUgJmd0O25ldyBjb25uZWN0aW9uIHJldXNpbmcgdGhlIHNhbWUNCjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnVuZGVybHlpbmcgdHJhbnNwb3J0IHNvbWUgaW50ZXJl c3RpbmcgcHJvYmxlbXMgY2FuIG9jY3VyLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltSYWp1XSBJIGJlbGlldmUgcGFja2V0 cyBmcm9tIG9sZCBEVExTIGNvbm5lY3Rpb24gYXBwZWFyaW5nIG9uIG5ldyB3aWxsIGJlIGRyb3Bw ZWQgdGhlIHNhbWUgd2F5IERUTFMgcmVrZXlpbmcgaGFuZGxlcyBwYWNrZXRzIHVzaW5nIG9sZCBr ZXkgYWZ0ZXIgTVNMIHRpbWVvdXQNCiBbMV0uIFNvLCBJIGRvbuKAmXQgdGhpbmsgYSBuZXcgVENQ L1NDVFAgdHJhbnNwb3J0IGNvbm5lY3Rpb24gbmVlZCB0byBiZSBlc3RhYmxpc2hlZC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+WzFdDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NCNz ZWN0aW9uLTUuMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NjQjc2VjdGlvbi01 LjI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQmVjYXVzZSBvZiBw YWNrZXQgcmVvcmRlcmluZywgcGFja2V0cyBwcm90ZWN0ZWQgYnkgdGhlIHByZXZpb3VzIHNldDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9mIGtleXMgY2FuIGFwcGVhciBv biB0aGUgd2lyZSBhZnRlciB0aGUgaGFuZHNoYWtlIGhhcyBjb21wbGV0ZWQuJm5ic3A7IFRvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY29tcGVuc2F0ZSBmb3IgdGhpcyBm YWN0LCByZWNlaXZlcnMgU0hPVUxEIG1haW50YWluIGJvdGggc2V0cyBvZiBrZXlzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZm9yIHNvbWUgdGltZSBpbiBvcmRlciB0byBi ZSBhYmxlIHRvIGRlY3J5cHQgYW5kIHZlcmlmeSBvbGRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHBhY2tldHMuJm5ic3A7IFRoZSBrZXlzIHNob3VsZCBiZSBtYWludGFp bmVkIGZvciB0aGUgZHVyYXRpb24gb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgbWF4aW11bSBzZWdtZW50IGxpZmV0aW1lIChNU0wpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5JZiB0aGUgYXV0aGVudGljYXRpb24gY2hlY2sgb24gdGhlIHBhY2tldCBmYWlsczxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGFuZCBubyBNS0kgaXMgYmVpbmcgdXNlZCwgdGhlbiB0aGUgcmVjZWl2ZXIgTUFZIHByb2Nl c3MgdGhlIHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IHdpdGggdGhlIG9sZGVyIHNldCBvZiBrZXlzLiZuYnNwOyBJZiB0 aGF0IGF1dGhlbnRpY2F0aW9uIGNoZWNrIGluZGljYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIHBhY2tldCBp cyB2YWxpZCwgdGhlIHBhY2tldCBzaG91bGQgYmUgYWNjZXB0ZWQ7IG90aGVyd2lzZSw8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0 aGUgcGFja2V0IE1VU1QgYmUgZGlzY2FyZGVkIGFuZCByZWplY3RlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJhanU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E6F8D11US70UWXCHMBA02z_-- From nobody Mon Feb 16 09:47:48 2015 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 D64061A3BA3 for ; Mon, 16 Feb 2015 09:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-BLmW_e6CGg for ; Mon, 16 Feb 2015 09:47:44 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C6E1A1B6A for ; Mon, 16 Feb 2015 09:47:43 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so25037025igk.1 for ; Mon, 16 Feb 2015 09:47:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BnrxhEoW9towSWhlH+ruUaFejkv4891QDcHQs2p3h6k=; b=CHqQPBxZWsCXd1pkGjvNLl5+fuz8RddyM5KnwRR5MbE56YFhUOT9QTmoJbivmsmwGS Qyd4/jJz1QDnTLox9cVLxzyaXeZv2D4DsrJXR0eYiqtS9Dk1igl6ojnenlaNPDdiEnH8 H6neiBSi3mWhkR/Nwfhuj5Mztk8eCkktmwMBP6O2xR2KW+eOKIXvn/v/oK+H24WSS+E/ dI9KwHhmlPTptq0qlhdpBkETyQc6RT0qih0YkHnURWIFy+rSUb29oXv8HvBdIcR4fSV5 igINsWNnB9Vs2pRvoH3Tvo4TQhVkNkwQQ6B7Xl86vdDQrDw0XDBlKytS1YbdNKRo5e5i y0dg== X-Gm-Message-State: ALoCoQkp889nxZZ6NtgN6jRnVYc2+s9365lc8LcCRjn3iRYcALys52E6dts94Lawzpg8qQi7VKQF X-Received: by 10.50.112.98 with SMTP id ip2mr22669989igb.15.1424108863259; Mon, 16 Feb 2015 09:47:43 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by mx.google.com with ESMTPSA id o198sm3632022ioo.34.2015.02.16.09.47.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Feb 2015 09:47:42 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id b16so25007058igk.1 for ; Mon, 16 Feb 2015 09:47:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.136.69 with SMTP id k66mr24171385iod.18.1424108860940; Mon, 16 Feb 2015 09:47:40 -0800 (PST) Received: by 10.36.20.10 with HTTP; Mon, 16 Feb 2015 09:47:40 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6D6CB3@ESESSMB208.ericsson.se> Date: Mon, 16 Feb 2015 12:47:40 -0500 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113ed130c72bf8050f382e18 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 17:47:46 -0000 --001a113ed130c72bf8050f382e18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 16, 2015 at 8:55 AM, Simon Perreault wrote: > > On Fri, Feb 13, 2015 at 7:14 PM, Roman Shpount wrote: > >> On Fri, Feb 13, 2015 at 6:35 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Don=E2=80=99t you have the same problem in case of DTLS re-keying? >>> >> >> You do have the same problem in case of DTLS re-key. This is why none of >> the current browser implementations actually support it. At this point I >> would be very curious to see if anybody implemented DTLS re-key or >> re-negotiation over the same transport and would very much appreciate if >> they tell us how exactly they did this. >> > > Uh? > > I did implement DTLS re-key / re-negotiation as specified. Then I tested > it. It works. I don't know what problem you're alluding to. > > > How do you deal with late DTLS data packets or alerts for the previous connection received on the new connection? If it is an open source, you can simply point me to the relevant code. I do know how to implement DTLS-SRTP re-key. It is dealing with new DTLS session running over existing connection where packets from the previous DTLS session can be present which is not completely clear to me. _____________ Roman Shpount --001a113ed130c72bf8050f382e18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 16, 2015 at 8:55 AM, Simon Perreault <= ;sperreault@jive.c= om> wrote:

On Fri, Feb 13, 2015 at 7:14 PM, Roman Shpo= unt <roman@telurix.com> wrote:
On = Fri, Feb 13, 2015 at 6:35 PM, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:

Don=E2=80=99t you have the same problem in c= ase of DTLS re-keying?


You do have the same problem in case of DTLS re-key. This is why = none of the current browser implementations actually support it. At this po= int I would be very curious to see if anybody implemented DTLS re-key or re= -negotiation over the same transport and would very much appreciate if they= tell us how exactly they did this.

Uh?

I= did implement DTLS re-key / re-negotiation as specified. Then I tested it.= It works. I don't know what problem you're alluding to.


How do you deal with late DTLS data packets or alerts for the = previous connection received on the new connection? If it is an open source= , you can simply point me to the relevant code.

I = do know how to implement DTLS-SRTP re-key. It is dealing with new DTLS sess= ion running over existing connection where packets from the previous DTLS s= ession can be present which is not completely clear to me.
_____________
Roman Shpount

=C2=A0
--001a113ed130c72bf8050f382e18-- From nobody Mon Feb 16 09:51:25 2015 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 216051A3B9C for ; Mon, 16 Feb 2015 09:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx32KADzMUUl for ; Mon, 16 Feb 2015 09:51:22 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7311A1BBC for ; Mon, 16 Feb 2015 09:51:21 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so24908213igb.3 for ; Mon, 16 Feb 2015 09:51:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CzksrIHd2SfzbcswyIobzdKEG/SyRx47A9J0R68vTWc=; b=bU+4xGefxOki/oAkMCIFcxs4mMv8/uLxP1PcriWw+MGFXohuiybjv0gzsgbbH2O4YS /r7CRNdkUFGtQaTXMtREugVu/+nXqpmCrlY2F2BIpYGyOY+3XIqjjIvHuv8fi08Mgwtm xUIaVLt2jeP3NXEK5/TMOpNfca66V300UYNS4hCgUU+fuXB6OAe9Q2Yn0tFUQ/vDFXw7 tKLoSuxdWMitT5VIKjhTLe1Af4YEffKwF4G6Uzn0ygWRbrottL9a+C9EssLMxptzeRF+ 2g7UDIU5KopW8bC7XVbfi/oyOOACDq0LJOSAFQG3DKoXwDTsPbdrAW2cxO8XLru1QXVO jF1g== X-Gm-Message-State: ALoCoQk6G/2w7aBCW1zValvBNxEdnv6fJ/DQBJUBFxKLleyXAbtsQHjGSj5WsI6wUjI7+117kzPn X-Received: by 10.50.142.106 with SMTP id rv10mr23395041igb.18.1424109081160; Mon, 16 Feb 2015 09:51:21 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by mx.google.com with ESMTPSA id h15sm3037771ioe.23.2015.02.16.09.51.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Feb 2015 09:51:20 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so24908009igb.3 for ; Mon, 16 Feb 2015 09:51:19 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.36.12 with SMTP id k12mr32513692iok.41.1424109079111; Mon, 16 Feb 2015 09:51:19 -0800 (PST) Received: by 10.36.20.10 with HTTP; Mon, 16 Feb 2015 09:51:19 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <54DE185D.9060402@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.ericsson.se> Date: Mon, 16 Feb 2015 12:51:19 -0500 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=001a11403ab2c8316b050f383b5c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 17:51:24 -0000 --001a11403ab2c8316b050f383b5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 16, 2015 at 9:44 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > > >As far as I know the only way to demultiplex DTLS packets is based on > the underlying transport. >Unless you can >guarantee that no packets from > the previous DTLS connection will arrive on the >new connection reusing t= he > same >underlying transport some interesting problems can occur. > > [Raju] I believe packets from old DTLS connection appearing on new will b= e > dropped the same way DTLS rekeying handles packets using old key after MS= L > timeout [1]. So, I don=E2=80=99t think a new TCP/SCTP transport connectio= n need to > be established. > > > > [1] https://tools.ietf.org/html/rfc5764#section-5.2 > > Because of packet reordering, packets protected by the previous set > > of keys can appear on the wire after the handshake has completed. To > > compensate for this fact, receivers SHOULD maintain both sets of keys > > for some time in order to be able to decrypt and verify older > > packets. The keys should be maintained for the duration of the > > maximum segment lifetime (MSL). > > =E2=80=A6 > > If the authentication check on the packet fails > > and no MKI is being used, then the receiver MAY process the packet > > with the older set of keys. If that authentication check indicates > > that the packet is valid, the packet should be accepted; otherwise, > > the packet MUST be discarded and rejected. > > > This actually talks about DTLS-SRTP re-key that I have implemented before. What is unclear to me is how DTLS is dealing with multiple DTLS sessions (i.e. DTLS data and alerts) on the same transport connection. I cannot find any documentation or implementations of such feature. _____________ Roman Shpount --001a11403ab2c8316b050f383b5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 16, 2015 at 9:44 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

=C2=A0

= >As far as I know the only way to demultiple= x DTLS packets is based on the underlying transport. >Unless you can >guarantee that no packets f= rom the previous DTLS connection will arrive on the >new connection reus= ing the same >underlying transport some i= nteresting problems can occur.

= [Raju] I believe packets from old DTLS connection appearing on new = will be dropped the same way DTLS rekeying handles packets using old key af= ter MSL timeout [1]. So, I don=E2=80=99t think a new TCP/SCTP transport connection need to= be established.

=C2=A0

[1] https://tools.ietf.org/html/rfc5764#section-5.2=

=C2=A0=C2=A0 Because of packet reordering, packets protected by t= he previous set

=C2=A0=C2=A0 of keys can appear on the wire after the handshake h= as completed.=C2=A0 To

=C2=A0=C2=A0 compensate for this fact, receivers SHOULD maintain = both sets of keys

=C2=A0=C2=A0 for some time in order to be able to decrypt and ver= ify older

=C2=A0=C2=A0 packets.=C2=A0 The keys should be maintained for the= duration of the

=C2=A0=C2=A0 maximum segment lifetime (MSL).=

=E2=80=A6

If the authentication check=
 on the packet fails
=C2=A0=C2=A0 and no MKI is =
being used, then the receiver MAY process the packet

=C2=A0=C2=A0 with the older=
 set of keys.=C2=A0 If that authentication check indicates


=C2=A0=C2=A0 that the packe=
t is valid, the packet should be accepted; otherwise,<=
/pre>

=C2=A0=C2=A0 the packet MUS=
T be discarded and rejected.


This actually talks about DTLS-SRTP re-key that I have implemented before.= What is unclear to me is how DTLS is dealing with multiple DTLS sessions (= i.e. DTLS data and alerts) on the same transport connection. I cannot find = any documentation or implementations of such feature.
_____________
Roman Shpount

=C2= =A0
--001a11403ab2c8316b050f383b5c-- From nobody Mon Feb 16 09:56:56 2015 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 51A101A1BB3 for ; Mon, 16 Feb 2015 09:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbUDiZ1Rlwcr for ; Mon, 16 Feb 2015 09:56:53 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A1B1A1BAF for ; Mon, 16 Feb 2015 09:56:53 -0800 (PST) Received: by labhz20 with SMTP id hz20so31160667lab.0 for ; Mon, 16 Feb 2015 09:56:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=E1N0UKeQB9DiugBTD0sQSpvsVUr/OEGt9oI6KVx2P10=; b=kh/Lyl+yEUbTD7/5lBNPCtgVnYwg3W3BbHFk86edYZ506w5gywCCS5Bz/1lITOy2uP 0Mm0EC5/CRqmdm3zlf8r6fg2ptNbFDeorIQfM/iBHyRAa/LOGBCb7zq4/990pmRkfWYr jZ7ZvcY/ai5Tpm4i2Z+EDDTwIMA3sc1R3oSTrcGYX7gHpNRrWteFZM4n2kme7iVt/vZj +Neg+CW1GuIEU+ZQnkvQr/l/4OZrN//bAUvAEg992amjxa/Bwwkc6IeD9rL2Von3fyvT 90yjKrfWbfnbBpoo2ZAfGSwr/DTfk1308hEb/oofVp23gPSpAY+m0AHV2et/J8uNQfG+ 4L8Q== X-Gm-Message-State: ALoCoQnr6kg1T3uq4Ap9IOfzKgj6k6kiIa9KVouQcXCOY/GMblDQtP8RSMT4OepQjDj0painl5N9 MIME-Version: 1.0 X-Received: by 10.112.139.168 with SMTP id qz8mr8960112lbb.84.1424109411844; Mon, 16 Feb 2015 09:56:51 -0800 (PST) Received: by 10.25.205.135 with HTTP; Mon, 16 Feb 2015 09:56:51 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6D6CB3@ESESSMB208.ericsson.se> Date: Mon, 16 Feb 2015 12:56:51 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c29ce49d5882050f384f61 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 17:56:55 -0000 --001a11c29ce49d5882050f384f61 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 16, 2015 at 12:47 PM, Roman Shpount wrote: > > I did implement DTLS re-key / re-negotiation as specified. Then I tested >> it. It works. I don't know what problem you're alluding to. >> > > How do you deal with late DTLS data packets or alerts for the previous > connection received on the new connection? If it is an open source, you can > simply point me to the relevant code. > This may just be a terminology issue... DTLS re-key / re-negotiation doesn't create a new connection. I do know how to implement DTLS-SRTP re-key. It is dealing with new DTLS > session running over existing connection where packets from the previous > DTLS session can be present which is not completely clear to me. > Packets from an unrelated DTLS connection will simply be discarded. What else are you looking for? Simon --001a11c29ce49d5882050f384f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 16, 2015 at 12:47 PM, Roman Shpount <roman@telurix.com>= wrote:
I did i= mplement DTLS re-key / re-negotiation as specified. Then I tested it. It wo= rks. I don't know what problem you're alluding to.

How do you deal with late DTLS data= packets or alerts for the previous connection received on the new connecti= on? If it is an open source, you can simply point me to the relevant code.<= /div>

This may just be a terminology = issue... DTLS re-key / re-negotiation doesn't create a new connection.= =C2=A0

I do know how to implement DTLS-SRTP re-key. It is dealing w= ith new DTLS session running over existing connection where packets from th= e previous DTLS session can be present which is not completely clear to me.=

Packets from an unrelated DTLS connectio= n will simply be discarded. What else are you looking for?

Simon
--001a11c29ce49d5882050f384f61-- From nobody Mon Feb 16 09:58:05 2015 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 9F8B11A1B6A for ; Mon, 16 Feb 2015 09:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhQIU-Mm7DyZ for ; Mon, 16 Feb 2015 09:58:03 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E251F1A1BAF for ; Mon, 16 Feb 2015 09:58:02 -0800 (PST) Received: by labms9 with SMTP id ms9so25334735lab.10 for ; Mon, 16 Feb 2015 09:58:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vFw/tn5WlMnugGLDM1gCesXUZ2TCtCqAurrnAZ+bzlg=; b=eP186IeadC9upMRGdZGQMWMaK8FUHYHO26fxOsTtn9t0HbbUNc9xhy3gLzQgN6N+XL n3V2BpWoc9Wgvul1+Ic5zm/B0bW9dXrsJjcjBH6Hwx9Br9GjxTk/v0g1cY0L1owviEW1 R93N1g1y1Ns25XRT6jQuGP+CwR3syFMR/WhH2b5ZZIggqxrwRVF3LUk9yi3mLzH4xyV2 sd5z/4tppM1Y46C9kCr88vm9srxAnjKYj+IsJja1YXOBRWa/6K0apcxMKW11vjJ2hS72 l/mqE7XUC5oobx5G9snGD6Nl6aSYPOHCPJrPl3Ss5zSa77Fn3hreVIAyZsiPvvqsfUkI lZJw== X-Gm-Message-State: ALoCoQnYMERlK00AweSr+1mbG7tqU0XdiewzdrINplaXDPpUXxTYVkZn6/ksg3TstCvhSpu1+MMS MIME-Version: 1.0 X-Received: by 10.152.36.232 with SMTP id t8mr24393804laj.90.1424109481270; Mon, 16 Feb 2015 09:58:01 -0800 (PST) Received: by 10.25.205.135 with HTTP; Mon, 16 Feb 2015 09:58:01 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <54DE185D.9060402@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.ericsson.se> Date: Mon, 16 Feb 2015 12:58:01 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=089e0160a9d2c0b8b5050f385338 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 17:58:04 -0000 --089e0160a9d2c0b8b5050f385338 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 16, 2015 at 12:51 PM, Roman Shpount wrote: > What is unclear to me is how DTLS is dealing with multiple DTLS sessions > (i.e. DTLS data and alerts) on the same transport connection. I cannot find > any documentation or implementations of such feature. You can't do this, just like you can't have more than one TCP connection per 5-tuple. Simon --089e0160a9d2c0b8b5050f385338 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 16, 2015 at 12:51 PM, Roman Shpount <roman@telurix.com>= wrote:
What is unclear to me is h= ow DTLS is dealing with multiple DTLS sessions (i.e. DTLS data and alerts) = on the same transport connection. I cannot find any documentation or implem= entations of such feature.

You can't do this, jus= t like you can't have more than one TCP connection per 5-tuple.

Simon
--089e0160a9d2c0b8b5050f385338-- From nobody Mon Feb 16 12:01:52 2015 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 D1C4D1A8769 for ; Mon, 16 Feb 2015 12:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYsx44rbPtId for ; Mon, 16 Feb 2015 12:01:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42251A016C for ; Mon, 16 Feb 2015 12:01:45 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 01B6862E3AF9E; Mon, 16 Feb 2015 20:01:40 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t1GK1a1t023309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 15:01:36 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 15:01:36 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Simon Perreault , Roman Shpount Thread-Topic: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? Thread-Index: AdBHkzCQyzSQhofyQHmttIgUsDEyWAAOJYOAABEP+wAAAcy+AAB3JSvAABHRaoAAADvngAAInsAQ Date: Mon, 16 Feb 2015 20:01:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <54DE185D.9060402@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.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.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E6FB28AUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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 Feb 2015 20:01:51 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E6FB28AUS70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBNb24sIEZlYiAxNiwgMjAxNSBhdCAxMjo1MSBQTSwgUm9tYW4gU2hwb3VudCA8cm9tYW5A dGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQpXaGF0IGlzIHVu Y2xlYXIgdG8gbWUgaXMgaG93IERUTFMgaXMgZGVhbGluZyB3aXRoIG11bHRpcGxlIERUTFMgc2Vz c2lvbnMgKGkuZS4gRFRMUyBkYXRhIGFuZCBhbGVydHMpIG9uIHRoZSBzYW1lIHRyYW5zcG9ydCBj b25uZWN0aW9uLiBJIGNhbm5vdCBmaW5kIGFueSBkb2N1bWVudGF0aW9uIG9yIGltcGxlbWVudGF0 aW9ucyBvZiBzdWNoIGZlYXR1cmUuDQoNCltSYWp1XSBEVExTIGlzIGEgcHJvdG9jb2wgd2hpY2gg aXMgdHlwaWNhbGx5IHJ1bnMgaW4gYXBwbGljYXRpb24tc3BhY2UuIFlvdSB0eXBpY2FsbHkgcnVu IGp1c3Qgb25lIERUTFMgc2Vzc2lvbiBvbiB0b3Agb2YgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5 ZXIgKFRDUCBvciBVRFApLiBBcyBleHBsYWluZWQgYnkgU2ltb24sIERUTFMgcmVrZXlpbmcgZG9l cyBub3QgcmVzdWx0IGluIGEgbmV3IERUTFMgYXNzb2NpYXRpb24sIGJ1dCByYXRoZXIgbmV3IGhh bmRzaGFrZSBzZXF1ZW5jZSBvbiB0b3Agb2YgZXhpc3RpbmcgYXNzb2NpYXRpb24uDQoNCkhvd2V2 ZXIsIGR1cmluZyBzdWJzZXF1ZW50IFNEUCBPL0Egcm9sZSBjaGFuZ2UgbWF5IHRyaWdnZXIgYSBu ZXcgRFRMUyBhc3NvY2lhdGlvbiB0byBiZSBzZXR1cC4gSW4gc3VjaCBhIGNhc2UgcHJldmlvdXMg YXNzb2NpYXRpb24gc2hvdWxkIGJlIGdvbmUgYW5kIGFueSB0cmFuc3BvcnQgbGF5ZXIgcGFja2V0 cyAoVENQIG9yIFVEUCkgZnJvbSB0aGUgcHJldmlvdXMgRFRMUyBhc3NvY2lhdGlvbiBtYXkgYXJy aXZlIG9uIG5ldyBEVExTIGFzc29jaWF0aW9uLCBidXQgSSB0aGluayB0aGV5IHdpbGwgYW5kIHNo b3VsZCBiZSBkaXNjYXJkZWQgZHVlIHRvIE1BQyBmYWlsdXJlICh3aXRoIGJhZF9yZWNvcmRfbWFj IGFsZXJ0PykuDQoNClBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBub3QgdW5pcXVlIHRvIFRDUDsg dGhvdWdoIHVucmVsaWFibGUsIFVEUCB0cmFuc3BvcnQgY291bGQgYWxzbyByZWNlaXZlIGRlbGF5 ZWQgcGt0cyBmcm9tIHByZXZpb3VzIERUTFMgYXNzb2NpYXRpb24uIE9yIHNvbWVvbmUgY291bGQg c2ltcGx5IGluamVjdCBVUEQgcGt0cyBpbnRvIG1peC4gU28sIHJlLWVzdGFibGlzaGluZyBUQ1Ag Y29ubmVjdGlvbiBpcyBub3QgYSBzb2x1dGlvbiBhbmQgd29u4oCZdCBoZWxwIHdoZW4gVURQIGlz IHVzZWQuDQoNClNvLCBJTU8gYSBEVExTIGltcGxlbWVudGF0aW9uIHNob3VsZCBoYW5kbGUgc3Vj aCBvdXQtb2YtYmFuZCAoT09CKSBwa3RzIGluIGEgZ3JhY2VmdWwgd2F5IChpLmUuIHdpdGhvdXQg ZHJvcHBpbmcgdGhlIERUTFMgYXNzb2NpYXRpb24pLg0KDQoNCg0KSG9wZSB0aGlzIGhlbHBzIQ0K DQpSYWp1DQoNCg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E6FB28AUS70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDE2 LCAyMDE1IGF0IDEyOjUxIFBNLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9t YW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBpcyB1bmNs ZWFyIHRvIG1lIGlzIGhvdyBEVExTIGlzIGRlYWxpbmcgd2l0aCBtdWx0aXBsZSBEVExTIHNlc3Np b25zIChpLmUuIERUTFMgZGF0YSBhbmQgYWxlcnRzKSBvbiB0aGUgc2FtZSB0cmFuc3BvcnQgY29u bmVjdGlvbi4gSSBjYW5ub3QgZmluZCBhbnkgZG9jdW1lbnRhdGlvbiBvciBpbXBsZW1lbnRhdGlv bnMgb2Ygc3VjaCBmZWF0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxicj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W1JhanVdIDwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EVExTIGlzIGEgcHJvdG9jb2wgd2hp Y2ggaXMgdHlwaWNhbGx5IHJ1bnMgaW4gYXBwbGljYXRpb24tc3BhY2UuIFlvdSB0eXBpY2FsbHkg cnVuIGp1c3Qgb25lIERUTFMgc2Vzc2lvbiBvbiB0b3Agb2YgdW5kZXJseWluZyB0cmFuc3BvcnQg bGF5ZXIgKFRDUCBvciBVRFApLiBBcyBleHBsYWluZWQgYnkgU2ltb24sIERUTFMgcmVrZXlpbmcg ZG9lcyBub3QgcmVzdWx0IGluIGEgbmV3IERUTFMgYXNzb2NpYXRpb24sIGJ1dCByYXRoZXIgbmV3 IGhhbmRzaGFrZSBzZXF1ZW5jZSBvbiB0b3Agb2YgZXhpc3RpbmcgYXNzb2NpYXRpb24uIDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Ib3dldmVyLCBkdXJpbmcgc3Vic2VxdWVudCBTRFAgTy9BIHJvbGUgY2hhbmdlIG1heSB0cmln Z2VyIGEgbmV3IERUTFMgYXNzb2NpYXRpb24gdG8gYmUgc2V0dXAuIEluIHN1Y2ggYSBjYXNlIHBy ZXZpb3VzIGFzc29jaWF0aW9uIHNob3VsZCBiZSBnb25lIGFuZCBhbnkgdHJhbnNwb3J0IGxheWVy IHBhY2tldHMgKFRDUCBvciBVRFApIGZyb20gdGhlIHByZXZpb3VzIERUTFMgYXNzb2NpYXRpb24g bWF5IGFycml2ZSBvbiBuZXcgRFRMUyBhc3NvY2lhdGlvbiwgYnV0IEkgdGhpbmsgdGhleSB3aWxs IGFuZCBzaG91bGQgYmUgZGlzY2FyZGVkIGR1ZSB0byBNQUMgZmFpbHVyZSAod2l0aCBiYWRfcmVj b3JkX21hYyBhbGVydD8pLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgbm90IHVuaXF1 ZSB0byBUQ1A7IHRob3VnaCB1bnJlbGlhYmxlLCBVRFAgdHJhbnNwb3J0IGNvdWxkIGFsc28gcmVj ZWl2ZSBkZWxheWVkIHBrdHMgZnJvbSBwcmV2aW91cyBEVExTIGFzc29jaWF0aW9uLiBPciBzb21l b25lIGNvdWxkIHNpbXBseSBpbmplY3QgVVBEIHBrdHMgaW50byBtaXguIFNvLCByZS1lc3RhYmxp c2hpbmcgVENQIGNvbm5lY3Rpb24gaXMgbm90IGEgc29sdXRpb24gYW5kIHdvbuKAmXQgaGVscCB3 aGVuIFVEUCBpcyB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgSU1PIGEgRFRMUyBpbXBsZW1lbnRhdGlvbiBzaG91 bGQgaGFuZGxlIHN1Y2ggb3V0LW9mLWJhbmQgKE9PQikgcGt0cyBpbiBhIGdyYWNlZnVsIHdheSAo aS5lLiB3aXRob3V0IGRyb3BwaW5nIHRoZSBEVExTIGFzc29jaWF0aW9uKS48bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhvcGUgdGhpcyBoZWxwcyE8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcHJlPg0K PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqdTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E6FB28AUS70UWXCHMBA02z_-- From nobody Tue Feb 17 15:07:04 2015 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 7C4E01A90BD for ; Tue, 17 Feb 2015 15:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.732 X-Spam-Level: X-Spam-Status: No, score=0.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-3UAP59EQTI for ; Tue, 17 Feb 2015 15:07:01 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9AB31A8A7A for ; Tue, 17 Feb 2015 15:07:00 -0800 (PST) Received: by iecrd18 with SMTP id rd18so44714145iec.5 for ; Tue, 17 Feb 2015 15:07:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BNY8ZcZ9rv7vQwFL0z1h6MWS73OtWYzQ+U4tqPStn1E=; b=eV7+dAMjfoiQCkhr09PnTwvsOHg6NCIvSSu/tqnV4XtdZNKjcyLiiQYKNnfbzy1ilT BJ5WtXV7xVEnFm6r/3dZ7gasPDc0XAK0qEuP/aq/YXOgb2YCcV9/6aBFfJDNTy5MeqCf 4wh+lckYW1CZ3UhieU2P0s9ZJFhbIFWVJH8JfcQPCVsXn2vXLv9gUFOI6dMg4DFvqldZ /6tzCup/lLqwyIin1XCtHY35wL7jrolcDoswXKHDNgFvpBQFvYtjiJT7qqpafrg5+Xcz MOIoIwtmnszzYzopDC8zruWcoROvPNKkbTgU36k7Jj3M4WcgkmFDYLcJqN1qSe1guHVg qyQQ== X-Gm-Message-State: ALoCoQkmk7CDDq66lZeh+cYIcZKEVAiGMu5A9AFXMqJuCrRrxv9Ka/DBqphLnssedeJ599uvqete MIME-Version: 1.0 X-Received: by 10.42.102.5 with SMTP id g5mr36777798ico.74.1424214420157; Tue, 17 Feb 2015 15:07:00 -0800 (PST) Received: by 10.64.240.69 with HTTP; Tue, 17 Feb 2015 15:07:00 -0800 (PST) In-Reply-To: References: <20150206165614.3979.58417.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 15:07:00 -0800 Message-ID: From: Jozsef Vass To: Justin Uberti Content-Type: multipart/alternative; boundary=20cf30050eec992fc4050f50c297 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-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: Tue, 17 Feb 2015 23:07:03 -0000 --20cf30050eec992fc4050f50c297 Content-Type: text/plain; charset=UTF-8 Yes, that would work for us. Our main use case is audio only. In addition, implementers may add PLC (Appendix I) to G.711. Jozsef Jozsef Vass SDK Engineering [image: twilio] MOBILE(415) 216-6603EMAILjvass@twilio.com SIGNAL: The modern communications conference May 19/20 2015, Fort Mason Festival Pavilion, SF, CA On Thu, Feb 12, 2015 at 4:01 PM, Justin Uberti wrote: > If we do any FEC with PCMU, it would probably be 2198-style for simplicity > (counter to what the current text says). Is this something that you would > use? > > On Wed, Feb 11, 2015 at 11:44 AM, Jozsef Vass wrote: > >> Later, in 4.1 Recommended Mechanisms: >> >> When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198 ] >> redundant encoding is NOT RECOMMENDED, as this will result in a >> potentially significant bitrate increase. Furthermore, suddenly >> increasing the bitrate to deal with packet losses may actually make >> things worse. >> >> Because of the lower packet rate of audio encodings, usually a single >> packet per frame, use of a separate FEC stream comes with a higher >> overhead than other mechanisms, and therefore is NOT RECOMMENDED. >> >> >> So what is recommended for PCMU? >> >> Jozsef >> >> >> Jozsef Vass >> SDK Engineering >> [image: twilio] >> MOBILE(415) 216-6603EMAILjvass@twilio.com >> SIGNAL: The modern communications conference >> >> May 19/20 2015, Fort Mason Festival Pavilion, SF, CA >> >> >> >> >> >> >> On Wed, Feb 11, 2015 at 11:39 AM, Simon Perreault >> wrote: >> >>> >>> On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass wrote: >>> >>>> I just wondering what kind of FEC is recommended (or will be supported) >>>> for G.711. The draft does not recommend neither redundant encoding nor a >>>> separate FEC stream. >>> >>> >>> Isn't this what you're looking for? >>> >>> 3.1 . Separate FEC Stream >>> >>> This approach, as described in [RFC5956], Section 4.3 , sends FEC >>> packets as an independent SSRC-multiplexed stream, with its own SSRC >>> and payload type. While by far the most flexible, each FEC packet >>> will have its own IP+UDP+RTP+FEC header, leading to additional >>> overhead of the FEC stream. >>> >>> >>> Simon >>> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --20cf30050eec992fc4050f50c297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, that would work for us. Our main use case is audio on= ly. In addition, implementers may add PLC (Appendix I) to G.711.

Jozsef

Jozsef Vass
SDK Engineering
3D"twilio"
<= td style=3D"padding:12px 16px;border-style:solid;border-color:rgb(216,214,2= 08);border-width:2px 0px">
<= /div>

On Thu, Feb 12, 2015 at 4:01 PM, Justin Uber= ti <juberti@google.com> wrote:
If we do any FEC with PCMU, it would probably be 219= 8-style for simplicity (counter to what the current text says). Is this som= ething that you would use?

On Wed, Feb 11, 2015 at 11:44 AM, Jozsef Vass <jvass@twili= o.com> wrote:
Later, in 4.1 Recommended Mechanisms:

   When us=
ing constant-bitrate codecs, e.g.  PCMU, use of [RFC2198]
   redundant encoding is NOT RECOMMENDED, as this will result in a
   potentially significant bitrate increase.  Furthermore, suddenly
   increasing the bitrate to deal with packet losses may actually make
   things worse.

   Because of the lower packet rate of audio encodings, usually a single
   packet per frame, use of a separate FEC stream comes with a higher
   overhead than other mechanisms, and therefore is NOT RECOMMENDED.
<= div>
So what is recommended for PCMU?

Jozsef

<= /div>


On Wed, Feb 11, 2015 at 11:= 39 AM, Simon Perreault <sperreault@jive.com> wrote:
On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass <= span dir=3D"ltr"><= jvass@twilio.com> wrote:
I just wondering= what kind of FEC is recommended (or will be supported) for G.711. The draf= t does not recommend neither redundant encoding nor a separate FEC stream.<= /blockquote>

Isn't this what you're looking for?= =C2=A0

3.1=
.  Separate FEC Stream


   This approach, as described in [RFC5956], Section=C2=A04.3, sends =
FEC
   packets as an independent SSRC-multiplexed stream, with its own SSRC
   and payload type.  While by far the most flexible, each FEC packet
   will have its own IP+UDP+RTP+FEC header, leading to additional
   overhead of the FEC stream.

<=
/pre>Simon


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



--20cf30050eec992fc4050f50c297-- From nobody Sun Feb 22 05:26:51 2015 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 574601A034C for ; Sun, 22 Feb 2015 05:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 s2dId-YmYlC4 for ; Sun, 22 Feb 2015 05:26:48 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B381A0270 for ; Sun, 22 Feb 2015 05:26:46 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-17-54e9d9147245 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id ED.07.04076.419D9E45; Sun, 22 Feb 2015 14:26:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Sun, 22 Feb 2015 14:26:43 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Simon Perreault" , Roman Shpount Thread-Topic: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? Thread-Index: AdBHkzCQyzSQhofyQHmttIgUsDEyWAABkt2AABMR47D///5WAIAEE48AgAA0JoCAAAHfgIAAIoaA//byyyA= Date: Sun, 22 Feb 2015 13:26:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7105D9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1E74@ESESSMB209.ericsson.se> <54DE185D.9060402@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D6D8CD2@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D7105D9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvja7IzZchBm2H1C0aNl5htZhxYSqz xdp/7ewW16+EOrB4tD7by+qxZMlPJo9/c54ye9yaUhDAEsVlk5Kak1mWWqRvl8CV0dJ/lr3g mnHFj1mL2RoYZxh1MXJySAiYSJxZe5kZwhaTuHBvPRuILSRwhFGi50FwFyMXkL2EUWLety6g Ig4ONgELie5/2iBxEYHJjBJP/vwGa2YWUJe4s/gcO0iNsECJxLFpOiBhEYFSiWVX25kh7CSJ 76veg81nEVCV2Nj0GCzOK+Ar8e77ZGaIvetZJOYfVwexOQViJfbePsMKYjMC3fb91BomiFXi EreezGeCuFlAYsme81D3i0q8fPyPFcJWklh0+zNUfb7E/393oXYJSpyc+YRlAqPoLCSjZiEp m4WkbBbQN8wCmhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxcW66kZFealFmcnFx fp5eXmrJJkZgPB7c8ttqB+PB546HGAU4GJV4eDdsexkixJpYVlyZe4hRmoNFSZzXzvhQiJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbG7A9Hu5oPSodnM0VYRD1rYliwZduzT4/77HTEvolF O0kxajyfOmWWxgJBVZnPhiFbYy7Hst6y8Vq6+k/P/hqrCVPb33bd/cguoNWa3lVyWFTh1r2/ HPZLtv5bNt1Je1F3vYLouvvMiw05GKqNu4QFOm6vvtbpVLv28ozOlTxz7doktEwjq28psRRn JBpqMRcVJwIAkCNx/KgCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP-SCTP: Does re-establishment of DTLS connection affect underlying SCTP or TCP connection? 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, 22 Feb 2015 13:26:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D7105D9ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJhc2VkIG9uIHRoZSBpbnB1dCwgbXkgc3VnZ2VzdGlvbiBpcyB0byBhZGQgdGhlIGZv bGxvd2luZyBub3RlIHRvIHNlY3Rpb24gMTAuMy4zIChUTFMgUm9sZSBEZXRlcm1pbmF0aW9uKToN Cg0K4oCcTk9URTogVGhlIHJlLWVzdGFibGlzaG1lbnQgb2YgYSBEVExTIGNvbm5lY3Rpb24gYXMg c3VjaCBkb2VzIG5vdCBhZmZlY3QgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IHByb3RvY29sIGNv bm5lY3Rpb24uIEhvd2V2ZXIsIGFzIGRlc2NyaWJlZCBhYm92ZSwgdGhlIHJlYXNvbiBhIG5ldyBE VExTIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQgbWlnaHQgYmUgYmVjYXVzZSBzb21lIHRyYW5z cG9ydCBwcm90b2NvbCBwYXJhbWV0ZXJzIGhhdmUgY2hhbmdlZC7igJ0NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D7105D9ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ QmFzZWQgb24gdGhlIGlucHV0LCBteSBzdWdnZXN0aW9uIGlzIHRvIGFkZCB0aGUgZm9sbG93aW5n IG5vdGUgdG8gc2VjdGlvbiAxMC4zLjMgKFRMUyBSb2xlIERldGVybWluYXRpb24pOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+4oCcTk9URTogVGhlIHJlLWVzdGFi bGlzaG1lbnQgb2YgYSBEVExTIGNvbm5lY3Rpb24gYXMgc3VjaCBkb2VzIG5vdCBhZmZlY3QgdGhl IHVuZGVybHlpbmcgdHJhbnNwb3J0IHByb3RvY29sIGNvbm5lY3Rpb24uIEhvd2V2ZXIsDQogYXMg ZGVzY3JpYmVkIGFib3ZlLCB0aGUgcmVhc29uIGEgbmV3IERUTFMgY29ubmVjdGlvbiBpcyBlc3Rh Ymxpc2hlZCBtaWdodCBiZSBiZWNhdXNlIHNvbWUgdHJhbnNwb3J0IHByb3RvY29sIHBhcmFtZXRl cnMgaGF2ZSBjaGFuZ2VkLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5D aHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D7105D9ESESSMB209erics_-- From nobody Sun Feb 22 08:20:09 2015 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 20C851A1BDC for ; Sun, 22 Feb 2015 08:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pptZgCJ8yIPJ for ; Sun, 22 Feb 2015 08:20:06 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5981A1BDB for ; Sun, 22 Feb 2015 08:20:05 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-61-54ea01b25cbb Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.31.04231.2B10AE45; Sun, 22 Feb 2015 17:20:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Sun, 22 Feb 2015 17:20:02 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: SCTP-SDP: Mux category for SDP sctp-port and max-message-size attributes Thread-Index: AdBOuOsQLa3mcLr2T9erX6W+Nd8eKQAAl22Q Date: Sun, 22 Feb 2015 16:20:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D710736@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7106D8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7106D8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/mixed; boundary="_004_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM+Jvje5mxlchBkfX81is/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFOvWpgK3uZWnDv5j7GB8V9CFyMnh4SAicSaCzuYIWwxiQv3 1rN1MXJxCAkcYZS4OfckI4SzhFFi4qk3TF2MHBxsAhYS3f+0QRpEBNQlLj+8wA5iCwuES1z+ cZIZIh4hsf3SWVYI20ji/LxFjCA2i4CqxLyzj5lAbF4BX4lXP5aC2UJA9rsNd9hAbE4BP4kd Z76wgNiMQAd9P7UGrIZZQFzi1pP5TBCHikg8vHiaDcIWlXj5+B8rhK0ksej2Z6j6TIlv24+x Q+wSlDg58wnLBEaRWUhGzUJSNgtJGUQ8X+L2+i1Qto7Egt2f2CBsbYllC18zw9hnDjxmwhTX lThyHmIms4CiRNv2ZqBeLiB7BaPE3t7dQEUcQI61xKETcjA1U7ofsi9g5F3FKFqcWlycm25k rJdalJlcXJyfp5eXWrKJERjTB7f81t3BuPq14yFGAQ5GJR7eDdtehgixJpYVV+YeYpTmYFES 57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVH6/IMWcc9rG3I0GGbxdbTyffVx/Sa0 OmiK6s0csdK/5U82XlgX+0T3dnBCaveL7C1yp3SL7NT8v/y58UD/teWnsp8tW8TkPn2oMGfk fpX0eoKP/IcFC79NmD7x66HfwQkGCy/0WBdsav6bcJbBW+1EcU3PoZ2Tvl3/aXzhfcOUjadE z4ZW6W1TYinOSDTUYi4qTgQAHwPTI8oCAAA= Archived-At: Subject: [rtcweb] FW: SCTP-SDP: Mux category for SDP sctp-port and max-message-size attributes 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, 22 Feb 2015 16:20:08 -0000 --_004_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_ Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_" --_000_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I sent this to MMUSIC, but it may be of interest for RTCWEB folks too. If you have any comments, please post them on the MMUSIC list. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 22 February 2015 18:19 To: mmusic@ietf.org Subject: [MMUSIC] SCTP-SDP: Mux category for SDP sctp-port and max-message-= size attributes Hi, I've been asked to include the MUX category (as defined in draft-ietf-mmusi= c-sdp-mux-attributes) for the SDP attributes defined in the SCTP-SDP draft:= sctp-port and max-message-size. For 'SCTP' and 'SCTP/DTLS' I assume it is rather straight forward. The sctp= -port attribute is not used to begin with, and the max-message-size applies= to the transport layer SCTP association. '(UDP | TCP)/DTLS/SCTP' is a little different. The draft says (or, *will* = say, based on the agreement in Honolulu) that multiple SCTP associations ov= er a single '(UDP | TCP)/DTLS' connection is outside the scope of the docum= ent, which means it is not possible to have multiple '(UDP | TCP)/DTLS/SCTP= ' m- lines within a BUNDLE group. Currently, unless I've missed something, there is however no category for a= ttributes that can't be bundled, eventhough one could perhaps claim that th= e NOT RECOMMENDED category fits. So, I see three options: 1) Allocate SPECIAL category, with a description saying that they can'= t be bundled 2) Allocate NOT RECOMMENDED category 3) Define a new mux category, for attributes that can't be bundled Comments? My personal preference would be either 2) or 3). SCTP: =3D=3D=3D=3D=3D Attribute: Mux category: sctp-port Not applicable max-message-size TRANSPORT SCTP/DTLS: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sctp-port Not applicable max-message-size TRANSPORT (UDP | TCP)/DTLS/SCTP: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Attribute: Mux category: sctp-port SPECIAL | New category max-message-size SPECIAL | New category Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

I sent this to MMUSIC,= but it may be of interest for RTCWEB folks too.

 

If you have any commen= ts, please post them on the MMUSIC list.

 

Regards,

 

Christer

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 22 February 2015 18:19
To: mmusic@ietf.org
Subject: [MMUSIC] SCTP-SDP: Mux category for SDP sctp-port and max-m= essage-size attributes

 

Hi,

 

I’ve been asked to include the MUX category (a= s defined in draft-ietf-mmusic-sdp-mux-attributes) for the SDP attributes d= efined in the SCTP-SDP draft: sctp-port and max-message-size.

 

For ‘SCTP’ and ‘SCTP/DTLS’ I= assume it is rather straight forward. The sctp-port attribute is not used = to begin with, and the max-message-size applies to the transport layer SCTP= association.

 

‘(UDP | TCP)/DTLS/SCTP’ is a little diff= erent.  The draft says (or, *will* say, based on the agreement = in Honolulu) that multiple SCTP associations over a single ‘(UDP | TC= P)/DTLS’ connection is outside the scope of the document, which means it is not possible to have multiple ‘(UDP | TCP)/DTLS/SC= TP’ m- lines within a BUNDLE group.

 

Currently, unless I’ve missed something, there= is however no category for attributes that can’t be bundled, eventho= ugh one could perhaps claim that the NOT RECOMMENDED category fits. So, I s= ee three options:

 

1)      Allocate SPECIAL category, with a description sayin= g that they can’t be bundled

2)      Allocate NOT RECOMMENDED category

3)      Define a new mux category, for attributes that can&= #8217;t be bundled

 

Comments? My personal preference would be either 2) = or 3).

 

SCTP:

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

 

Attribute:       =             &nb= sp;      Mux category:

 

sctp-port       &= nbsp;           &nbs= p;       Not applicable

max-message-size      =     TRANSPORT

 

 

SCTP/DTLS:

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

 

sctp-port       &= nbsp;           &nbs= p;       Not applicable

max-message-size      =     TRANSPORT

 

(UDP | TCP)/DTLS/SCTP:

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

 

Attribute:       =             &nb= sp;      Mux category:

 

sctp-port       &= nbsp;           &nbs= p;       SPECIAL | New category  &n= bsp;            = ;            &n= bsp;

max-message-size      =     SPECIAL | New category

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_-- --_004_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Sun, 22 Feb 2015 16:18:49 GMT"; modification-date="Sun, 22 Feb 2015 16:18:49 GMT" Content-ID: <6638320AFCA2224DBB77E7E2276FE088@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7594FB04B1934943A5C02806D1A2204B1D710736ESESSMB209erics_-- From nobody Sun Feb 22 09:43:48 2015 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 3F6D21A1C06 for ; Sun, 22 Feb 2015 09:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 TYTFE4LY70hA for ; Sun, 22 Feb 2015 09:43:45 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABF81A1C05 for ; Sun, 22 Feb 2015 09:43:44 -0800 (PST) Received: by iecrd18 with SMTP id rd18so18552872iec.5 for ; Sun, 22 Feb 2015 09:43:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=ekWW6Uw6kho/G+3x9m1A6cRPj7D0cTP3XGocE4sQsd0=; b=dgNknxWPpAuauOVhvovO7eyUX/fuMSN2WS8ahqgscYxblxicoCiyTZVtvjmMoa9/F6 eoLoYdAq1nvv8qjU8jFDWZsMIhDAbxOSePGYCMPhBKHUgYC9mNKInshm8MNxR4vX+XnA 26aggodP0nhkOJ/Ir6HGzTUr5Jif1sOjcUaCVGfOkKrHWZJ5G57muDpEmR+g8RVd6aHL OTyDiSKVpLUqATpyhjl+TRgqMeT8s5hkUeP0xYA5QcQ6aIGwzIz/E9UQYridhAPnSxeh bPqxU7zYGbvz3U+JyION1CDRZfsT1UEkwxL+PCgOz5UxATbnk6XX/UbrIgZZUw03e5rc jH/g== X-Gm-Message-State: ALoCoQlc0q3ppJzW60PTQXJaIIxbuqwwQLEd8yYh+zQb/r4uQrtZ3IdaNo5UW2Iah7nsKdd8gGPK X-Received: by 10.50.114.4 with SMTP id jc4mr8480938igb.14.1424627024160; Sun, 22 Feb 2015 09:43:44 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com. [209.85.223.176]) by mx.google.com with ESMTPSA id ip8sm4762994igb.17.2015.02.22.09.43.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 09:43:43 -0800 (PST) Received: by iebtr6 with SMTP id tr6so18406336ieb.10 for ; Sun, 22 Feb 2015 09:43:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.79.230 with SMTP id m6mr8333819igx.33.1424627021897; Sun, 22 Feb 2015 09:43:41 -0800 (PST) Received: by 10.36.20.10 with HTTP; Sun, 22 Feb 2015 09:43:41 -0800 (PST) Date: Sun, 22 Feb 2015 12:43:41 -0500 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=089e01229aaa93efd9050fb0d37c Archived-At: Cc: "rtcweb@ietf.org" Subject: [rtcweb] Offer/Answer and DTLS 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, 22 Feb 2015 17:43:47 -0000 --089e01229aaa93efd9050fb0d37c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let me try to explain what my issue is with offer/answer, DTLS and multiple sessions over the same transport. First of all, as far as I understand, based on the specifications, an end point is supposed to start a new DTLS session (not re-key) if the setup role or fingerprint changes. Imagine the following situation: An end point has no intent to create a new DTLS session, it send an offer with the existing fingerprint and actpass setup role. Since it does not intend to change anything DTLS related, existing DTLS session continues to run. Remote party maintains the transport parameters but changes either role or fingerprint. This implies new DTLS session. So remote party closes the existing DTLS session (sends an alert) and starts negotiating a new session (potentially sends Client Hello). All of this happens at the same time as the answer is being generated and sent out to the offering pary. Offering party might not get this answer before new DTLS session handshake is received, so this handshake is most likely to be ignored, potentially delaying the session setup by DTLS timeout. Another problem: Offering party desires to change the DTLS session settings without changing the transport parameters and sends a new offer with new fingerprint and/or setup role. It cannot simply close the existing DTLS session, since offer might still fail for unrelated reason. If setup role is passive or actpass, offering party can still get the Client Hello before the successful answer was received, which means it should be able to process DTLS client offers while still processing data for the existing DTLS session. based on this, it looks like anything that runs offer/answer in combination with DTLS, should be able to handle a new DTLS session setup while an existing session is still running. At the very least, it should queue the Client Hello packets to be processed when signaling level decides to start a new session. Alternative would be loss of data or media for the duration of DTLS timeout. Finally, data and alerts from the previous session can be received after new session is setup. These two DTLS sessions can be demultiplexed based on their signatures or packets from an old session can simply be ignored since they failed the signature verification, which would be much less graceful. I think the better solution would be for an end point to maintain the list of recent DTLS sessions and try to dispatch a DTLS packet to the right session based on the packet signature. Having some sort of session indicator (similar to MKI) would make this process more transparent and less resource intensive but I do not think this is available for DTLS. So, my questions are: 1. Am I missing something in regard to DTLS session mulitplexing? 2. Is DTLS session multiplexing defined somewhere? 3. Have anybody implemented something similar to this? I am primarily interested in this in regard to WebRTC implementations. In particular I am interested in what is going to be supported or implemented by web browsers. As far as I know, current browser implementations do not support such renegotiation at all. If this is the intent for the foreseeable future, then prohibiting changes (at least with a SHOULD) to DTLS session without change to the underlying transport might not be a bad option. _____________ Roman Shpount On Mon, Feb 16, 2015 at 3:01 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > > On Mon, Feb 16, 2015 at 12:51 PM, Roman Shpount wrote= : > > What is unclear to me is how DTLS is dealing with multiple DTLS sessions > (i.e. DTLS data and alerts) on the same transport connection. I cannot fi= nd > any documentation or implementations of such feature. > > > *[Raju] **DTLS is a protocol which is typically runs in application-space= . You typically run just one DTLS session on top of underlying transport la= yer (TCP or UDP). As explained by Simon, DTLS rekeying does not result in a= new DTLS association, but rather new handshake sequence on top of existing= association. * > > *However, during subsequent SDP O/A role change may trigger a new DTLS as= sociation to be setup. In such a case previous association should be gone a= nd any transport layer packets (TCP or UDP) from the previous DTLS associat= ion may arrive on new DTLS association, but I think they will and should be= discarded due to MAC failure (with bad_record_mac alert?).* > > *Please note that this is not unique to TCP; though unreliable, UDP trans= port could also receive delayed pkts from previous DTLS association. Or som= eone could simply inject UPD pkts into mix. So, re-establishing TCP connect= ion is not a solution and won=E2=80=99t help when UDP is used.* > > *So, IMO a DTLS implementation should handle such out-of-band (OOB) pkts = in a graceful way (i.e. without dropping the DTLS association).* > > > > *Hope this helps!* > > *Raju* > > > > --089e01229aaa93efd9050fb0d37c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me try to explain what my issue is with offer/answer, = DTLS and multiple sessions over the same transport. First of all, as far as= I understand, based on the specifications, an end point is supposed to sta= rt a new DTLS session (not re-key) if the setup role or fingerprint changes= .=C2=A0

Imagine the following situation: An end point ha= s no intent to create a new DTLS session, it send an offer with the existin= g fingerprint and actpass setup role. Since it does not intend to change an= ything DTLS related, existing DTLS session continues to run. Remote party m= aintains the transport parameters but changes either role or fingerprint. T= his implies new DTLS session. So remote party closes the existing DTLS sess= ion (sends an alert) and starts negotiating a new session (potentially send= s Client Hello). All of this happens at the same time as the answer is bein= g generated and sent out to the offering pary. Offering party might not get= this answer before new DTLS session handshake is received, so this handsha= ke is most likely to be ignored, potentially delaying the session setup by = DTLS timeout.

Another problem: Offering party desires to= change the DTLS session settings without changing the transport parameters= and sends a new offer with new fingerprint and/or setup role. It cannot si= mply close the existing DTLS session, since offer might still fail for unre= lated reason. If setup role is passive or actpass, offering party can still= get the Client Hello before the successful answer was received, which mean= s it should be able to process DTLS client offers while still processing da= ta for the existing DTLS session.

<= div class=3D"gmail_extra">based on this, it looks like anything that runs o= ffer/answer in combination with DTLS, should be able to handle a new DTLS s= ession setup while an existing session is still running. At the very least,= it should queue the Client Hello packets to be processed when signaling le= vel decides to start a new session. Alternative would be loss of data or me= dia for the duration of DTLS timeout.
<= br>
Finally, data and alerts from the previ= ous session can be received after new session is setup. These two DTLS sess= ions can be demultiplexed based on their signatures or packets from an old = session can simply be ignored since they failed the signature verification,= which would be much less graceful. I think the better solution would be fo= r an end point to maintain the list of recent DTLS sessions and try to disp= atch a DTLS packet to the right session based on the packet signature. Havi= ng some sort of session indicator (similar to MKI) would make this process = more transparent and less resource intensive but I do not think this is ava= ilable for DTLS.

So, my questions are:
1. Am = I missing something in regard to DTLS session mulitplexing?
2. Is DTLS session multiplexing defined somewhere?
3. Have anybody implemented something similar to t= his?

I= am primarily interested in this in regard to WebRTC implementations. In pa= rticular I am interested in what is going to be supported or implemented by= web browsers. As far as I know, current browser implementations do not sup= port such renegotiation at all. If this is the intent for the foreseeable f= uture, then prohibiting changes (at least with a SHOULD) to DTLS session wi= thout change to the underlying transport might not be a bad option.
_____________<= br>Roman Shpount

On Mon, Feb 16, 2015 at 3:01 PM, Makaraju, M= aridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>= wrote:

=C2=A0


[Raju] DTLS is a=
 protocol which is typically runs in application-space. You typically run j=
ust one DTLS session on top of underlying transport layer (TCP or UDP). As =
explained by Simon, DTLS rekeying does not result in a new DTLS association=
, but rather new handshake sequence on top of existing association. =

However, during subsequent SDP O/A role change may trigg=
er a new DTLS association to be setup. In such a case previous association =
should be gone and any transport layer packets (TCP or UDP) from the previo=
us DTLS association may arrive on new DTLS association, but I think they wi=
ll and should be discarded due to MAC failure (with bad_record_mac alert?).=

Please note that this is not unique to TCP; though unrel=
iable, UDP transport could also receive delayed pkts from previous DTLS ass=
ociation. Or someone could simply inject UPD pkts into mix. So, re-establis=
hing TCP connection is not a solution and won=E2=80=99t help when UDP is us=
ed.
So, IMO a DTLS implementation should handle such out-of-=
band (OOB) pkts in a graceful way (i.e. without dropping the DTLS associati=
on).
=C2=A0
Hope this helps!
Raju
=C2=A0

--089e01229aaa93efd9050fb0d37c-- From nobody Sun Feb 22 10:40:02 2015 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 098E31A3BA7 for ; Sun, 22 Feb 2015 10:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=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 mjCtHdYn-PeT for ; Sun, 22 Feb 2015 10:40:00 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56AE1A039D for ; Sun, 22 Feb 2015 10:39:59 -0800 (PST) Received: by mail-oi0-f41.google.com with SMTP id z81so10262494oif.0 for ; Sun, 22 Feb 2015 10:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zQcQ+mGA3RAktoTyinBvJNe2tOIroDSXrKsod+HMp4g=; b=e/jBeczsqcdlsjqzccbjHvSdTtflOccmJLqigM/CYLGrhfhifwyj2Q7nCszCGIhvcs UtVsbe7tFhKuSj9t8G415vKTiUysSlFHCLloPlJNFiee6V/bgpNmf+SdaEFVxcQeJfgN ggKx84FXcagXNiQrkQqw2lC3v8Ud9vH9aW39ei84n7WaXE1nrdaKVPT/w0IcWUsrFHAY qA4ZfuVGwd/57o/JQlvzlty36OjZ2tPjnvxrzJo1CmAJUem6UBNAPVt4okvwAwPNmNYo UyAyYYtEFSqalVdKnMK4YQb7a27ZMvzT7Cr3pWrlkY3kfdBl8mI5ftMXSSRePXJzgEPj /cVQ== MIME-Version: 1.0 X-Received: by 10.202.185.198 with SMTP id j189mr4899497oif.72.1424630399192; Sun, 22 Feb 2015 10:39:59 -0800 (PST) Received: by 10.202.225.135 with HTTP; Sun, 22 Feb 2015 10:39:59 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Feb 2015 07:39:59 +1300 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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, 22 Feb 2015 18:40:01 -0000 On 23 February 2015 at 06:43, Roman Shpount wrote: > Let me try to explain what my issue is with offer/answer, DTLS and multiple > sessions over the same transport. First of all, as far as I understand, > based on the specifications, an end point is supposed to start a new DTLS > session (not re-key) if the setup role or fingerprint changes. Or you could not do that. The feature exists to support a change to a new communication endpoint. A new DTLS association should not be needed if the two endpoints are the same. A different endpoint will have different a transport addresses and different ICE credentials, meaning that the whole demux issue is addressed at lower layers of the stack. The only thing we would need to do in that case is say that you MUST NOT change a=setup during renegotiation unless the endpoint (and therefore the transport parameters) needs to change. From nobody Sun Feb 22 10:52:43 2015 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 06A3D1A6EE6 for ; Sun, 22 Feb 2015 10:52:42 -0800 (PST) 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, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 tubzHOU0czG7 for ; Sun, 22 Feb 2015 10:52:40 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B025A1A6EE0 for ; Sun, 22 Feb 2015 10:52:40 -0800 (PST) Received: by iecvy18 with SMTP id vy18so18621598iec.13 for ; Sun, 22 Feb 2015 10:52:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vhErUqlPtvG1fvhg4zJXPjKUQsOPcFkMlrLWukOzG84=; b=HusCW2GEy5LoEIkOErsswv2zj2S4v0Oom7+uS35CFEOjVEkVcFc4CGBVpOKhDia9Hs DOtKvr1aUeIMCWlqXQ+ZHGAVLuLKBNnVmX/lG9fcgK06f/H5JQw0a/WyLzeKXuWBWdN5 7Z7PBszYdgQitcFcwWrZ6PsPEXN/ilbU/BFJ1S36n/4sPsZNkiBRBcQbTrRb4Q9L9tTj n/5re4qb71VMbqprAqXVHjXsPFCmRCJNZi81qciRBTWLl97TjR2o+cH4l05b+rRPfXbk KRI18F4UmZTfIkfG4lqlPGnyJ/YW6sqsbtMp3aCckt5jFQcawOQqf82Y5T/+sc0ll8JY nLjw== X-Gm-Message-State: ALoCoQlALJCWSZkXyBK51x8tIm9WHG8mcnyV4aQdPsWDM7FHDnCmT1puK6ZgTz8yPivA/vF5NNjj X-Received: by 10.42.60.193 with SMTP id r1mr7796989ich.97.1424631160074; Sun, 22 Feb 2015 10:52:40 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by mx.google.com with ESMTPSA id qs3sm4860717igb.8.2015.02.22.10.52.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 10:52:39 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so13654841igd.4 for ; Sun, 22 Feb 2015 10:52:37 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.106.203 with SMTP id a11mr8121895icp.2.1424631157873; Sun, 22 Feb 2015 10:52:37 -0800 (PST) Received: by 10.36.20.10 with HTTP; Sun, 22 Feb 2015 10:52:37 -0800 (PST) In-Reply-To: References: Date: Sun, 22 Feb 2015 13:52:37 -0500 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf304352c819e71b050fb1cad4 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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, 22 Feb 2015 18:52:42 -0000 --20cf304352c819e71b050fb1cad4 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 22, 2015 at 1:39 PM, Martin Thomson wrote: > On 23 February 2015 at 06:43, Roman Shpount wrote: > > Let me try to explain what my issue is with offer/answer, DTLS and > multiple > > sessions over the same transport. First of all, as far as I understand, > > based on the specifications, an end point is supposed to start a new DTLS > > session (not re-key) if the setup role or fingerprint changes. > > Or you could not do that. The feature exists to support a change to a > new communication endpoint. A new DTLS association should not be > needed if the two endpoints are the same. A different endpoint will > have different a transport addresses and different ICE credentials, > meaning that the whole demux issue is addressed at lower layers of the > stack. > > The only thing we would need to do in that case is say that you MUST > NOT change a=setup during renegotiation unless the endpoint (and > therefore the transport parameters) needs to change. > I actually agree. I would really like to see that specified somewhere that *fingerprint* and *setup role* SHOULD NOT, or better yet, MUST NOT change if end points and transport parameters did not change as well. This will address all necessary use cases and simplify the implementations. In fact I have suggested this on multiple occasions. Other people keep insisting that these things can change independently. Alternatively, which I do like a lot less, it is possible to define how DTLS sessions can be setup and demultiplexed over the same connection. Unless someone provides a good reason why this is needed and comes up with a plausible implementation I would prefer not to have multiple DTLS sessions over the same connection. _____________ Roman Shpount --20cf304352c819e71b050fb1cad4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 23 February 2015 at 06:43, Roman Shpo= unt <roman@telurix.com> wrot= e:
> Let me try to explain what my issue is with offer/answer, DTLS and mul= tiple
> sessions over the same transport. First of all, as far as I understand= ,
> based on the specifications, an end point is supposed to start a new D= TLS
> session (not re-key) if the setup role or fingerprint changes.

Or you could not do that.=C2=A0 The feature exists to support a chan= ge to a
new communication endpoint.=C2=A0 A new DTLS association should not be
needed if the two endpoints are the same.=C2=A0 A different endpoint will have different a transport addresses and different ICE credentials,
meaning that the whole demux issue is addressed at lower layers of the
stack.

The only thing we would need to do in that case is say that you MUST
NOT change a=3Dsetup during renegotiation unless the endpoint (and
therefore the transport parameters) needs to change.

I actually agree. I= would really like to see that specified somewhere that fingerprint = and setup role SHOULD NOT, or better yet, MUST NOT change if end poi= nts and transport parameters did not change as well. This will address all = necessary use cases and simplify the implementations. In fact I have sugges= ted this on multiple occasions. Other people keep insisting that these thin= gs can change independently.

Alternatively, which I do like a lot less, it is pos= sible to define how DTLS sessions can be setup and demultiplexed over the s= ame connection. Unless someone provides a good reason why this is needed an= d comes up with a plausible implementation I would prefer not to have multi= ple DTLS sessions over the same connection.
_____________
Roman Shpount

--20cf304352c819e71b050fb1cad4-- From nobody Sun Feb 22 21:06:40 2015 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 BDC651A01A5 for ; Sun, 22 Feb 2015 21:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al7plKqrd1hd for ; Sun, 22 Feb 2015 21:06:37 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45DD1A01AA for ; Sun, 22 Feb 2015 21:06:36 -0800 (PST) X-AuditID: c1b4fb30-f79626d000003cf6-86-54eab55af0f7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.1A.15606.A55BAE45; Mon, 23 Feb 2015 06:06:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 06:06:34 +0100 From: Christer Holmberg To: Roman Shpount , Martin Thomson Thread-Topic: [rtcweb] Offer/Answer and DTLS Thread-Index: AQHQTscg+zO/WiBUDE6I3wOpBInhbZz875qAgAADh4CAALjJ8A== Date: Mon, 23 Feb 2015 05:06:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7112D0@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvjW7U1lchBqvvaFlcO/OP0WLGhanM Fmv/tbM7MHvsnHWX3WPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlPN/5jKXgkGzFq3m7WRoY H8h0MXJySAiYSHx/e4MNwhaTuHBvPZDNxSEkcIRR4lDjHGYIZwmjxOJVb4EyHBxsAhYS3f+0 QRpEBIIknk+fzwRiMwuoS9xZfI4dxBYW0JboXtLDCFGjI9H2czobhO0ksfpOJ1icRUBV4m5H OzOIzSvgK3Fs5kuoXfcYJSZMfQiW4BQIlLi55jkLiM0IdN33U2uglolL3HoCsVhCQEBiyZ7z zBC2qMTLx/9YIWwlicYlT1hBbmYW0JRYv0sfolVRYkr3Q3aIvYISJ2c+YZnAKDYLydRZCB2z kHTMQtKxgJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgPB3c8ttgB+PL546HGAU4GJV4 eDdMfxUixJpYVlyZe4hRmoNFSZzXzvhQiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG5pMi 68UnHs+7Gyb5rqI2XmyS0/fvfx58V/r9eNqHjU9E2l6HX1sdav9gmeLz7uY2vZLHqnumW814 5qIsIFXkdkrjTfH3w18Md8/jX1Km8P5JzLbf2hxPu/M0ZDoPL/gibmp7KvZFn9f+lgkzz860 tnptbWtQuTXnhexORd/YxhAz4VcBhXs7lFiKMxINtZiLihMBDjf8uogCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 05:06:38 -0000 SGksDQoNCj4+PiBMZXQgbWUgdHJ5IHRvIGV4cGxhaW4gd2hhdCBteSBpc3N1ZSBpcyB3aXRoIG9m ZmVyL2Fuc3dlciwgRFRMUyBhbmQgbXVsdGlwbGUNCj4+PiBzZXNzaW9ucyBvdmVyIHRoZSBzYW1l IHRyYW5zcG9ydC4gRmlyc3Qgb2YgYWxsLCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kLA0KPj4+IGJh c2VkIG9uIHRoZSBzcGVjaWZpY2F0aW9ucywgYW4gZW5kIHBvaW50IGlzIHN1cHBvc2VkIHRvIHN0 YXJ0IGEgbmV3IERUTFMNCj4+PiBzZXNzaW9uIChub3QgcmUta2V5KSBpZiB0aGUgc2V0dXAgcm9s ZSBvciBmaW5nZXJwcmludCBjaGFuZ2VzLg0KPj4NCj4+IE9yIHlvdSBjb3VsZCBub3QgZG8gdGhh dC7CoCBUaGUgZmVhdHVyZSBleGlzdHMgdG8gc3VwcG9ydCBhIGNoYW5nZSB0byBhDQo+PiBuZXcg Y29tbXVuaWNhdGlvbiBlbmRwb2ludC7CoCBBIG5ldyBEVExTIGFzc29jaWF0aW9uIHNob3VsZCBu b3QgYmUNCj4+IG5lZWRlZCBpZiB0aGUgdHdvIGVuZHBvaW50cyBhcmUgdGhlIHNhbWUuwqAgQSBk aWZmZXJlbnQgZW5kcG9pbnQgd2lsbA0KPj4gaGF2ZSBkaWZmZXJlbnQgYSB0cmFuc3BvcnQgYWRk cmVzc2VzIGFuZCBkaWZmZXJlbnQgSUNFIGNyZWRlbnRpYWxzLA0KPj4gbWVhbmluZyB0aGF0IHRo ZSB3aG9sZSBkZW11eCBpc3N1ZSBpcyBhZGRyZXNzZWQgYXQgbG93ZXIgbGF5ZXJzIG9mIHRoZQ0K Pj4gc3RhY2suDQo+Pg0KPj4gVGhlIG9ubHkgdGhpbmcgd2Ugd291bGQgbmVlZCB0byBkbyBpbiB0 aGF0IGNhc2UgaXMgc2F5IHRoYXQgeW91IE1VU1QNCj4+IE5PVCBjaGFuZ2UgYT1zZXR1cCBkdXJp bmcgcmVuZWdvdGlhdGlvbiB1bmxlc3MgdGhlIGVuZHBvaW50IChhbmQNCj4+IHRoZXJlZm9yZSB0 aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMpIG5lZWRzIHRvIGNoYW5nZS4NCj4NCj4gSSBhY3R1YWxs eSBhZ3JlZS4gSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgdGhhdCBzcGVjaWZpZWQgc29tZXdo ZXJlIHRoYXQgZmluZ2VycHJpbnQgYW5kIA0KPiBzZXR1cCByb2xlIFNIT1VMRCBOT1QsIG9yIGJl dHRlciB5ZXQsIE1VU1QgTk9UIGNoYW5nZSBpZiBlbmQgcG9pbnRzIGFuZCB0cmFuc3BvcnQgDQo+ IHBhcmFtZXRlcnMgZGlkIG5vdCBjaGFuZ2UgYXMgd2VsbC4gVGhpcyB3aWxsIGFkZHJlc3MgYWxs IG5lY2Vzc2FyeSB1c2UgY2FzZXMgYW5kIHNpbXBsaWZ5IA0KPiB0aGUgaW1wbGVtZW50YXRpb25z LiBJbiBmYWN0IEkgaGF2ZSBzdWdnZXN0ZWQgdGhpcyBvbiBtdWx0aXBsZSBvY2Nhc2lvbnMuIE90 aGVyIHBlb3BsZSANCj4ga2VlcCBpbnNpc3RpbmcgdGhhdCB0aGVzZSB0aGluZ3MgY2FuIGNoYW5n ZSBpbmRlcGVuZGVudGx5Lg0KDQpUaGUgU0NUUC1TRFAgZHJhZnQgY3VycmVudGx5IGNvbnRhaW5z IHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6DQoNCgkiVGhlcmVmb3JlLCBlbmRwb2ludHMgU0hPVUxE IE5PVCBjaGFuZ2UgdGhlICdhY3RpdmUvDQogICAJcGFzc2l2ZScgc3RhdHVzIGR1cmluZyBhIHNl c3Npb24sIHVubGVzcyB0aGV5IHdhbnQgdG8gZXN0YWJsaXNoIGEgbmV3DQogICAJRFRMUyBjb25u ZWN0aW9uLiINCg0KQW5kLCBldmVuIGlmIGEgbmV3IERUTFMgY29ubmVjdGlvbiBpcyBlc3RhYmxp c2hlZCwgaXQgb2YgY291cnNlIGRvZXNuJ3QgbWVhbiB0aGF0IHRoZSBhY3RpdmUvcGFzc2l2ZSBz dGF0dXMgYXV0b21hdGljYWxseSB3aWxsIGJlIGNoYW5nZWQgLSBidXQgdGhlIHN0YXR1cyB3aWxs IGJlIHJlLW5lZ290aWF0ZWQuDQoNCgkiSWYgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIG9yIHRo ZSBrZXkgZmluZ2VycHJpbnRzIGNoYW5nZSwgdGhlDQogICAJZW5kcG9pbnRzIE1VU1QgZXN0YWJs aXNoIGEgbmV3IERUTFMgY29ubmVjdGlvbi4gIEluIHN1Y2ggY2FzZSB0aGUNCiAgIAknYWN0aXZl L3Bhc3NpdmUnIHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIHdpbGwgYWdhaW4gYmUgZGV0ZXJtaW5l ZA0KICAgCWZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbiBbUkZDNDE0NV0sIGFuZCB0aGUgbmV3 IHN0YXR1cyB3aWxsIGJlDQogICAJdXNlZCB0byBkZXRlcm1pbmUgdGhlIFRMUyByb2xlcyBvZiB0 aGUgZW5kcG9pbnRzIGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAgIAluZXcgRFRMUyBjb25uZWN0aW9u LiINCg0KPiBBbHRlcm5hdGl2ZWx5LCB3aGljaCBJIGRvIGxpa2UgYSBsb3QgbGVzcywgaXQgaXMg cG9zc2libGUgdG8gZGVmaW5lIGhvdyBEVExTIHNlc3Npb25zIGNhbiBiZSBzZXR1cCBhbmQgDQo+ IGRlbXVsdGlwbGV4ZWQgb3ZlciB0aGUgc2FtZSBjb25uZWN0aW9uLiBVbmxlc3Mgc29tZW9uZSBw cm92aWRlcyBhIGdvb2QgcmVhc29uIHdoeSB0aGlzIGlzIA0KPiBuZWVkZWQgYW5kIGNvbWVzIHVw IHdpdGggYSBwbGF1c2libGUgaW1wbGVtZW50YXRpb24gSSB3b3VsZCBwcmVmZXIgbm90IHRvIGhh dmUgbXVsdGlwbGUgDQo+IERUTFMgc2Vzc2lvbnMgb3ZlciB0aGUgc2FtZSBjb25uZWN0aW9uLg0K DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQsIHdoZW4gQlVORExFIGlzIHVzZWQsIGEgc2luZ2xl IERUTFMgY29ubmVjdGlvbiB3aWxsIGJlIHVzZWQgZm9yIGFsbCBidW5kbGVkIG1lZGlhL2RhdGEg d2l0aGluIHRoYXQgQlVORExFIGdyb3VwLg0KDQpJIGFtIG5vdCBldmVuIHN1cmUgaXQgd291bGQg YmUgYWxsb3dlZCB0byBoYXZlIG11bHRpcGxlIERUTFMgY29ubmVjdGlvbnMgb24gYSBzaW5nbGUg NS10dXBsZSwgYnV0IEkgZ3Vlc3Mgc29tZSBEVExTIGV4cGVydCBjYW4gYW5zd2VyIHRoYXQuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Mon Feb 23 08:54:31 2015 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 37DBF1A1B7F for ; Mon, 23 Feb 2015 08:54:31 -0800 (PST) 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_15=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 JU59sDOZRDuC for ; Mon, 23 Feb 2015 08:54:29 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF21A1A1B6E for ; Mon, 23 Feb 2015 08:54:28 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id h11so18993242wiw.1 for ; Mon, 23 Feb 2015 08:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5qYsQcIb7ANoIPPXIxgzdR8v99B0BcXrB4ekiEj0t/w=; b=WGk3rXUPpcYKlIN+V1Sqdt9f7o1e1tUm69iHik48MJbK2Xyw3zkmf/E25lE+TvioBY GYgLbXkpp4EMonS51UPYExg+IjYjBXbwnEnTDQPzYmibCXFUT2q1x6dS1vS8xCtbe/mt Y1KxxGpBLbs8wq+5FHztpxpfOdrKGbKRKgLxNMwkwOuhRdr3EccVnKbaS7hSzwbhBXxY yc8fhfXx7V9GrsaKsMi3ebMgxsNO9xmKAJ/63ldU25rfMeQy8N2/o+vJTRYcKzTLrPZm hqKObWaxtY/Y/qZgm16ng6qVtUQEEVXnAuIT1Oqt3ETbT/dau3BBmW0sGIMgkqnA8Zlp Rf1A== X-Received: by 10.180.108.177 with SMTP id hl17mr22290997wib.35.1424710467639; Mon, 23 Feb 2015 08:54:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.129.196 with HTTP; Mon, 23 Feb 2015 08:54:07 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Mon, 23 Feb 2015 08:54:07 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8f3ba43b54dfda050fc441b8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 16:54:31 -0000 --e89a8f3ba43b54dfda050fc441b8 Content-Type: text/plain; charset=UTF-8 Roman said: "I actually agree. I would really like to see that specified somewhere that *fingerprint* and *setup role* SHOULD NOT, or better yet, MUST NOT change if end points and transport parameters did not change as well. This will address all necessary use cases and simplify the implementations. In fact I have suggested this on multiple occasions. Other people keep insisting that these things can change independently." [BA] I'm generally supportive of this direction. Existing implementations don't support re-negotiation, so in general it won't work anyway. "Alternatively, which I do like a lot less, it is possible to define how DTLS sessions can be setup and demultiplexed over the same connection." [BA] This is much less desirable - and even if the standards work were done, who would implement it? On Sun, Feb 22, 2015 at 9:06 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> Let me try to explain what my issue is with offer/answer, DTLS and > multiple > >>> sessions over the same transport. First of all, as far as I understand, > >>> based on the specifications, an end point is supposed to start a new > DTLS > >>> session (not re-key) if the setup role or fingerprint changes. > >> > >> Or you could not do that. The feature exists to support a change to a > >> new communication endpoint. A new DTLS association should not be > >> needed if the two endpoints are the same. A different endpoint will > >> have different a transport addresses and different ICE credentials, > >> meaning that the whole demux issue is addressed at lower layers of the > >> stack. > >> > >> The only thing we would need to do in that case is say that you MUST > >> NOT change a=setup during renegotiation unless the endpoint (and > >> therefore the transport parameters) needs to change. > > > > I actually agree. I would really like to see that specified somewhere > that fingerprint and > > setup role SHOULD NOT, or better yet, MUST NOT change if end points and > transport > > parameters did not change as well. This will address all necessary use > cases and simplify > > the implementations. In fact I have suggested this on multiple > occasions. Other people > > keep insisting that these things can change independently. > > The SCTP-SDP draft currently contains the following sentence: > > "Therefore, endpoints SHOULD NOT change the 'active/ > passive' status during a session, unless they want to establish a > new > DTLS connection." > > And, even if a new DTLS connection is established, it of course doesn't > mean that the active/passive status automatically will be changed - but the > status will be re-negotiated. > > "If the transport parameters or the key fingerprints change, the > endpoints MUST establish a new DTLS connection. In such case the > 'active/passive' status of the endpoints will again be determined > following the procedures in [RFC4145], and the new status will be > used to determine the TLS roles of the endpoints associated with > the > new DTLS connection." > > > Alternatively, which I do like a lot less, it is possible to define how > DTLS sessions can be setup and > > demultiplexed over the same connection. Unless someone provides a good > reason why this is > > needed and comes up with a plausible implementation I would prefer not > to have multiple > > DTLS sessions over the same connection. > > My understanding is that, when BUNDLE is used, a single DTLS connection > will be used for all bundled media/data within that BUNDLE group. > > I am not even sure it would be allowed to have multiple DTLS connections > on a single 5-tuple, but I guess some DTLS expert can answer that. > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8f3ba43b54dfda050fc441b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Roman said:

"I actually agree. I would really like to see that specifi= ed somewhere that fingerprint and setup role SHOULD NOT, or b= etter yet, MUST NOT change if end points and transport parameters did not c= hange as well. This will address all necessary use cases and simplify the i= mplementations. In fact I have suggested this on multiple occasions. Other = people keep insisting that these things can change independently."

[BA] I= 9;m generally supportive of this direction.=C2=A0 Existing implementations = don't support re-negotiation, so in general it won't work anyway. <= /div>


"Alternatively, which I do like a lot l= ess, it is possible to define how DTLS sessions can be setup and demultiple= xed over the same connection."

[BA] This is much less desirable - and even i= f the standards work were done, who would implement it?

On Sun, Feb 22= , 2015 at 9:06 PM, Christer Holmberg <christer.holmberg@erics= son.com> wrote:
Hi,

>>> Let me try to explain what my issue is with offer/answer, DTLS= and multiple
>>> sessions over the same transport. First of all, as far as I un= derstand,
>>> based on the specifications, an end point is supposed to start= a new DTLS
>>> session (not re-key) if the setup role or fingerprint changes.=
>>
>> Or you could not do that.=C2=A0 The feature exists to support a ch= ange to a
>> new communication endpoint.=C2=A0 A new DTLS association should no= t be
>> needed if the two endpoints are the same.=C2=A0 A different endpoi= nt will
>> have different a transport addresses and different ICE credentials= ,
>> meaning that the whole demux issue is addressed at lower layers of= the
>> stack.
>>
>> The only thing we would need to do in that case is say that you MU= ST
>> NOT change a=3Dsetup during renegotiation unless the endpoint (and=
>> therefore the transport parameters) needs to change.
>
> I actually agree. I would really like to see that specified somewhere = that fingerprint and
> setup role SHOULD NOT, or better yet, MUST NOT change if end points an= d transport
> parameters did not change as well. This will address all necessary use= cases and simplify
> the implementations. In fact I have suggested this on multiple occasio= ns. Other people
> keep insisting that these things can change independently.

The SCTP-SDP draft currently contains the following sentence:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Therefore, endpoints SHOULD NOT change th= e 'active/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 passive' status during a session, unless th= ey want to establish a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS connection."

And, even if a new DTLS connection is established, it of course doesn't= mean that the active/passive status automatically will be changed - but th= e status will be re-negotiated.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "If the transport parameters or the key fi= ngerprints change, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 endpoints MUST establish a new DTLS connection.= =C2=A0 In such case the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 'active/passive' status of the endpoint= s will again be determined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 following the procedures in [RFC4145], and the = new status will be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used to determine the TLS roles of the endpoint= s associated with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new DTLS connection."

> Alternatively, which I do like a lot less, it is possible to define ho= w DTLS sessions can be setup and
> demultiplexed over the same connection. Unless someone provides a good= reason why this is
> needed and comes up with a plausible implementation I would prefer not= to have multiple
> DTLS sessions over the same connection.

My understanding is that, when BUNDLE is used, a single DTLS connect= ion will be used for all bundled media/data within that BUNDLE group.

I am not even sure it would be allowed to have multiple DTLS connections on= a single 5-tuple, but I guess some DTLS expert can answer that.

Regards,

Christer
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--e89a8f3ba43b54dfda050fc441b8-- From nobody Mon Feb 23 09:12:16 2015 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 DF9311A1BCA for ; Mon, 23 Feb 2015 09:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNd1JsLXKcDB for ; Mon, 23 Feb 2015 09:12:13 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F111A1B92 for ; Mon, 23 Feb 2015 09:12:12 -0800 (PST) Received: by iecat20 with SMTP id at20so24977447iec.12 for ; Mon, 23 Feb 2015 09:12:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bUmSPuvxY4bCgDRO6OOikzBOMiq3NwtUTxSOdd+SSi8=; b=N+a76qQ+VGbfTPCzK/mEFnkno6/y/SWpAD/W1dLKHWDc/xf7ie3TpoQDs37j9cCXIq BR8OthrqICsLNnRo+r11gxO05KqQHJZK6Mam0m64dZax6ckaDMFy2y/IsEcPrC+wK9gt P18Sp+sWEIvVi2jsOAB86tw3tpttAq38Cw8/YKaoHaGj3dkAae9aZj2v8TNogo5DFkt3 GSijW0aShr+Fi0xpajksODHJEP0mAkhkIW2j59mdLA+oRzGYkF0mLzc/9GOm5kU+JCkn Dbq32EcEXUnuIR72MC2TlLTQbk/2t4+nmLBpKDum0lbBtUpUUoACVNXrJ/PMFzPPGUOa rSMw== X-Gm-Message-State: ALoCoQlxRX2aRuEZp6iQ6d17SCzIBzCJP4mvbNkhJccMAmskVRXPzTfpGs17NM7GBGtx0sKR9bbW X-Received: by 10.107.10.148 with SMTP id 20mr14900058iok.79.1424711532338; Mon, 23 Feb 2015 09:12:12 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com. [209.85.223.178]) by mx.google.com with ESMTPSA id gz4sm6416086igb.19.2015.02.23.09.12.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 09:12:11 -0800 (PST) Received: by iecrd18 with SMTP id rd18so24976076iec.8 for ; Mon, 23 Feb 2015 09:12:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.167.3 with SMTP id q3mr15046469ioe.18.1424711530171; Mon, 23 Feb 2015 09:12:10 -0800 (PST) Received: by 10.36.20.10 with HTTP; Mon, 23 Feb 2015 09:12:10 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> Date: Mon, 23 Feb 2015 12:12:10 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1141ca9ea9f56f050fc48020 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 17:12:15 -0000 --001a1141ca9ea9f56f050fc48020 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 12:06 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > The SCTP-SDP draft currently contains the following sentence: > > "Therefore, endpoints SHOULD NOT change the 'active/ > passive' status during a session, unless they want to establish a > new > DTLS connection." > > And, even if a new DTLS connection is established, it of course doesn't > mean that the active/passive status automatically will be changed - but the > status will be re-negotiated. > > "If the transport parameters or the key fingerprints change, the > endpoints MUST establish a new DTLS connection. In such case the > 'active/passive' status of the endpoints will again be determined > following the procedures in [RFC4145], and the new status will be > used to determine the TLS roles of the endpoints associated with > the > new DTLS connection." > > My understand is that the current draft allows to establish new DTLS connection over the same transport connection if an endpoint wants to do this. I would like to make sure that the specification explicitly prohibits this and states somewhere that fingerprint and setup role MUST NOT change unless the transport parameters change as well. Unless this is prohibited, some sort of specification language needs to be provided stating how multiple DTLS connections can run over a single 5-tuple. This is not currently allowed or defined anywhere and it is required for DTLS to operate with offer/answer end transport connection reuse. As I have stated on several occasions, I do not like the option of allowing multiple DTLS connections over the same transport since it complicates implementations for no reason. Unless someone provides a compelling use case why this is needed I strongly believe this should not be allowed. _____________ Roman Shpount --001a1141ca9ea9f56f050fc48020 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 12:06 AM, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:
The SCTP-SDP d= raft currently contains the following sentence:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Therefore, endpoints SHOULD NOT change th= e 'active/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 passive' status during a session, unless th= ey want to establish a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS connection."

And, even if a new DTLS connection is established, it of course doesn't= mean that the active/passive status automatically will be changed - but th= e status will be re-negotiated.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "If the transport parameters or the key fi= ngerprints change, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 endpoints MUST establish a new DTLS connection.= =C2=A0 In such case the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 'active/passive' status of the endpoint= s will again be determined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 following the procedures in [RFC4145], and the = new status will be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used to determine the TLS roles of the endpoint= s associated with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new DTLS connection."


My understand = is that the current draft allows to establish new DTLS connection over the = same transport connection if an endpoint wants to do this. I would like to = make sure that the specification explicitly prohibits this and states somew= here that fingerprint and setup role MUST NOT change unless the transport p= arameters change as well.

Unless this is prohibite= d, some sort of specification language needs to be provided stating how mul= tiple DTLS connections can run over a single 5-tuple. This is not currently= allowed or defined anywhere and it is required for DTLS to operate with of= fer/answer end transport connection reuse. As I have stated on several occa= sions, I do not like the option of allowing multiple DTLS connections over = the same transport since it complicates implementations for no reason. Unle= ss someone provides a compelling use case why this is needed I strongly bel= ieve this should not be allowed.
_= ____________
Roman Shpount
=C2=A0
--001a1141ca9ea9f56f050fc48020-- From nobody Mon Feb 23 12:38:06 2015 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 359141A6F03 for ; Mon, 23 Feb 2015 12:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j08B-haUhUlw for ; Mon, 23 Feb 2015 12:38:04 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C3D1A6F02 for ; Mon, 23 Feb 2015 12:38:03 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-0a-54eb8fa85af6 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.FA.04076.8AF8BE45; Mon, 23 Feb 2015 21:38:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 21:38:00 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [rtcweb] Offer/Answer and DTLS Thread-Index: AQHQTscg+zO/WiBUDE6I3wOpBInhbZz875qAgAADh4CAALjJ8IAAvXsAgABG7mA= Date: Mon, 23 Feb 2015 20:37:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@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+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje7K/tchBs0bmSyunfnHaDHjwlRm i7X/2tkdmD12zrrL7rFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgy9i1ay16wRr7i1vutTA2M R+S6GDk5JARMJLq/nmGEsMUkLtxbz9bFyMUhJHCEUWJuUxsThLOEUaJz/XXWLkYODjYBC4nu f9ogDSICqhJ/v09mArGZBUIkHp59xwxiCwtoS3Qv6WGEqNGRaPs5nQ3C9pPY9mIjC4jNAtR7 dc1aVhCbV8BXovnbQ0aIXS+ZJLbv3w3WzCkQKPFt+zywBkag676fWgO1TFzi1pP5TBBXC0gs 2XOeGcIWlXj5+B8rhK0k0bjkCdjNzAKaEut36UO0KkpM6X7IDrFXUOLkzCcsExjFZiGZOguh YxaSjllIOhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyng1t+W+1gPPjc8RCjAAej Eg/vhumvQoRYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNhx bZngZa0H77J3v9LUkewtl3O/2hq3eMpjVhGXv0HdKUZXZhieUC0SkjJczsxqwGr1csJVU933 8rJhQR2pzzv1/pnbulQstVzyk/HC9GTp5dMrV++a6vv/Teh9h0Wcs7uUd/+cc3vBSofDDhOm PWt++jbdZ31BVS8DP2uuVH/6nbwnl6V33VdiKc5INNRiLipOBADo3PODiAIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 20:38:05 -0000 SGksDQoNCj5UaGUgU0NUUC1TRFAgZHJhZnQgY3VycmVudGx5IGNvbnRhaW5zIHRoZSBmb2xsb3dp bmcgc2VudGVuY2U6DQo+DQo+wqAgwqAgwqAgwqAgIlRoZXJlZm9yZSwgZW5kcG9pbnRzIFNIT1VM RCBOT1QgY2hhbmdlIHRoZSAnYWN0aXZlLw0KPsKgIMKgIMKgIMKgIHBhc3NpdmUnIHN0YXR1cyBk dXJpbmcgYSBzZXNzaW9uLCB1bmxlc3MgdGhleSB3YW50IHRvIGVzdGFibGlzaCBhIG5ldw0KPsKg IMKgIMKgIMKgIERUTFMgY29ubmVjdGlvbi4iDQo+DQo+QW5kLCBldmVuIGlmIGEgbmV3IERUTFMg Y29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCwgaXQgb2YgY291cnNlIGRvZXNuJ3QgbWVhbiB0aGF0 IHRoZSBhY3RpdmUvcGFzc2l2ZSBzdGF0dXMgYXV0b21hdGljYWxseSB3aWxsIGJlID5jaGFuZ2Vk IC0gYnV0IHRoZSBzdGF0dXMgd2lsbCBiZSByZS1uZWdvdGlhdGVkLg0KPg0KPsKgIMKgIMKgIMKg ICJJZiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgb3IgdGhlIGtleSBmaW5nZXJwcmludHMgY2hh bmdlLCB0aGUNCj7CoCDCoCDCoCDCoCBlbmRwb2ludHMgTVVTVCBlc3RhYmxpc2ggYSBuZXcgRFRM UyBjb25uZWN0aW9uLsKgIEluIHN1Y2ggY2FzZSB0aGUNCj7CoCDCoCDCoCDCoCAnYWN0aXZlL3Bh c3NpdmUnIHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIHdpbGwgYWdhaW4gYmUgZGV0ZXJtaW5lZA0K PsKgIMKgIMKgIMKgIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbiBbUkZDNDE0NV0sIGFuZCB0 aGUgbmV3IHN0YXR1cyB3aWxsIGJlDQo+wqAgwqAgwqAgwqAgdXNlZCB0byBkZXRlcm1pbmUgdGhl IFRMUyByb2xlcyBvZiB0aGUgZW5kcG9pbnRzIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj7CoCDCoCDC oCDCoCBuZXcgRFRMUyBjb25uZWN0aW9uLiINCj4NCj4gTXkgdW5kZXJzdGFuZCBpcyB0aGF0IHRo ZSBjdXJyZW50IGRyYWZ0IGFsbG93cyB0byBlc3RhYmxpc2ggbmV3IERUTFMgY29ubmVjdGlvbiAN Cj4gb3ZlciB0aGUgc2FtZSB0cmFuc3BvcnQgY29ubmVjdGlvbiBpZiBhbiBlbmRwb2ludCB3YW50 cyB0byBkbyB0aGlzLg0KDQpDb3JyZWN0Lg0KDQo+IEkgd291bGQgbGlrZSB0byBtYWtlIHN1cmUg dGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBleHBsaWNpdGx5IHByb2hpYml0cyB0aGlzIGFuZCBzdGF0 ZXMgDQo+IHNvbWV3aGVyZSB0aGF0IGZpbmdlcnByaW50IGFuZCBzZXR1cCByb2xlIE1VU1QgTk9U IGNoYW5nZSB1bmxlc3MgdGhlIHRyYW5zcG9ydCANCj4gcGFyYW1ldGVycyBjaGFuZ2UgYXMgd2Vs bC4NCg0KQXMgZmFyIGFzIFNDVFAtU0RQIGlzIGNvbmNlcm5lZCwgcGVyc29uYWxseSBJIGRvbid0 IChhdCBsZWFzdCBub3QgYXQgdGhpcyBtb21lbnQpIGhhdmUgYSBwcm9ibGVtIHdpdGggc3VjaCBy ZXN0cmljdGlvbi4NCg0KSG93ZXZlciwgd2hlbiBCVU5ETEUgaXMgdXNlZCwgU1JUUCBhbmQgU0NU UCBtYXkgc2hhcmUgYSBzaW5nbGUgRFRMUyBjb25uZWN0aW9uLiBJdCBjb3VsZCBjYXVzZSBwcm9i bGVtcyBpZiBTUlRQIGFuZCBTQ1RQIGRlZmluZSBkaWZmZXJlbnQgcnVsZXMgd2hlbiBhIERUTFMg Y29ubmVjdGlvbiBjYW4gYmUgcmUtZXN0YWJsaXNoZWQuIEFuZCwgU1JUUC1EVExTIGRvZXMgbm90 IGZvcmJpZCB0aGF0IGZpbmdlcnByaW50IGFuZCBzZXR1cCByb2xlIGNoYW5nZSwgdW5sZXNzIHRo ZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBhbHNvIGNoYW5nZS4NCg0KPlVubGVzcyB0aGlzIGlzIHBy b2hpYml0ZWQsIHNvbWUgc29ydCBvZiBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlIG5lZWRzIHRvIGJl IHByb3ZpZGVkIHN0YXRpbmcgaG93IA0KPm11bHRpcGxlIERUTFMgY29ubmVjdGlvbnMgY2FuIHJ1 biBvdmVyIGEgc2luZ2xlIDUtdHVwbGUuIFRoaXMgaXMgbm90IGN1cnJlbnRseSBhbGxvd2VkIG9y IA0KPmRlZmluZWQgYW55d2hlcmUgYW5kIGl0IGlzIHJlcXVpcmVkIGZvciBEVExTIHRvIG9wZXJh dGUgd2l0aCBvZmZlci9hbnN3ZXIgZW5kIHRyYW5zcG9ydCBjb25uZWN0aW9uIHJldXNlLg0KDQpE b2Vzbid0IHRoZSBEVExTIHNwZWMgc2F5IHRoYXQsIHdoZW4gYSBuZXcgRFRMUyBjb25uZWN0aW9u IGhhcyBiZWVuIGVzdGFibGlzaGVkLCB5b3UgbmVlZCB0byBtYWludGFpbiB0aGUga2V5cyBmb3Ig dGhlIHByZXZpb3VzIGNvbm5lY3Rpb24gZm9yIGEgd2hpbGUsIGluIG9yZGVyIHRvIGhhbmRsZSBs YXRlIHBhY2tldHM/DQoNCj5BcyBJIGhhdmUgc3RhdGVkIG9uIHNldmVyYWwgb2NjYXNpb25zLCBJ IGRvIG5vdCBsaWtlIHRoZSBvcHRpb24gb2YgYWxsb3dpbmcgbXVsdGlwbGUgRFRMUyBjb25uZWN0 aW9ucyANCj5vdmVyIHRoZSBzYW1lIHRyYW5zcG9ydCBzaW5jZSBpdCBjb21wbGljYXRlcyBpbXBs ZW1lbnRhdGlvbnMgZm9yIG5vIHJlYXNvbi4gVW5sZXNzIHNvbWVvbmUgcHJvdmlkZXMgDQo+YSBj b21wZWxsaW5nIHVzZSBjYXNlIHdoeSB0aGlzIGlzIG5lZWRlZCBJIHN0cm9uZ2x5IGJlbGlldmUg dGhpcyBzaG91bGQgbm90IGJlIGFsbG93ZWQuDQoNCkkgZG9uJ3QgaGF2ZSBhIHVzZS1jYXNlLCBi dXQgYmVjYXVzZSBvZiBCVU5ETEUgSSdkIGxpa2UgdG8gaGF2ZSB0aGUgc2FtZSBydWxlcyBmb3Ig U1JUUCBhbmQgU0NUUC4NCg0KT2YgY291cnNlLCB3ZSBjb3VsZCBhZGQgeW91ciBzdWdnZXN0ZWQg cmVzdHJpY3Rpb24gYWxzbyB0byBTUlRQLi4uDQoNCkJ1dCwgd291bGQgd2UgdGhlbiBuZWVkIGFk ZCB0aGUgcmVzdHJpY3Rpb24gYWxzbyB0byBvdGhlciBwcm90b2NvbHMgdXNpbmcgRFRMUz8gRS5n LiBCRkNQLg0KDQpUaGUgYmVzdCB0aGluZyB3b3VsZCBiZSB0byBoYXZlIGdlbmVyaWMgT2ZmZXIv QW5zd2VyIHJ1bGVzIGZvciBEVExTLCB3aGljaCBhbGwgdXNhZ2VzIChTUlRQLCBTQ1RQLCBCRkNQ IGV0YykgdGhlbiByZWZlcmVuY2UsIGJ1dCBpdCdzIHRvbyBsYXRlIGZvciB0aGF0Li4uDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Mon Feb 23 14:38:27 2015 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 7F5131A0404 for ; Mon, 23 Feb 2015 14:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PeBnWSgEMKI for ; Mon, 23 Feb 2015 14:38:25 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB4C1A0399 for ; Mon, 23 Feb 2015 14:38:25 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id h3so27133083qgf.4 for ; Mon, 23 Feb 2015 14:38:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=97BGOmyg89oFXXPj1YillLXKxvhhGxK3I4UrFdxDO3o=; b=IlVjGPud5WRWykh9AxGN602hOR58neF1sp006RLGEpkzp1mCJCIwaYAGM9ZecWq8+8 DBGAYupdmi+UmV18iPWQTji50DddqYiwee3WEHiAhej7zzo3GkZuB4yLxhemppxSC2Nh KwTxAlKIsqtefkk+ZrXmu+A9b2lioRl4OMPi7QGrPopEVoSfR4KwRbwv11cisMxchyxm 5x7G7GREx5z/NXNIExf6rVTucsV5t1diUiuPCj8ypdwr0dkM90iB0+Hh9O2AP0wXgAIS hnT/rhCAp9PwSGRns+BGj1qztdC4/FBg0+xEOMh/DGmsGMkW2fO63v9kAYxSnIS4GDnO HE9g== X-Gm-Message-State: ALoCoQkAheVYsPCY8kmDGXfcI1+rm6V9M3laLeeZ2hu4Zcl/BJxRQN+Tz4pUY1dMhcaJfVTVM5yz X-Received: by 10.140.93.139 with SMTP id d11mr28136173qge.101.1424731104341; Mon, 23 Feb 2015 14:38:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.200.4 with HTTP; Mon, 23 Feb 2015 14:38:04 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Feb 2015 23:38:04 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 22:38:26 -0000 2015-02-23 21:37 GMT+01:00 Christer Holmberg : > Doesn't the DTLS spec say that, when a new DTLS connection has been estab= lished, you need to maintain the keys for the previous connection for a whi= le, in order to handle late packets? AFAIK the spec states that just in the case of DTLS rekeying. --=20 I=C3=B1aki Baz Castillo From nobody Mon Feb 23 15:22:26 2015 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 4165F1A1A7E for ; Mon, 23 Feb 2015 15:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ip3zZd89ShC for ; Mon, 23 Feb 2015 15:22:23 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252171A1A45 for ; Mon, 23 Feb 2015 15:22:22 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id l13so22631427iga.0 for ; Mon, 23 Feb 2015 15:22:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8dhJ6J40yokNk1ito3vduzsKbLJOgAO8Zw4bTjXaMtA=; b=NSz1mqsyw0VMUsN3X0xrwZLfevk1JAQimdHBtJ6AOglirJSQPAxy2h3SKO/mYly8QR gcVxdi+UO6Cr0WgaeajMg8nJ4KKOCZdd+O4GE1ZhPZT7hSIPvHurQPgVZTOghVmjdJF7 fKhYERSauTacg2nJMvLNW6WgFqRVcuRIeXKw7lLHtK0IHsfZu93IHfc49j7ZXVY5ksjn nJmikz8aWHHJyH9AWoJwV1SaqxEbWOR5vjtu8TFtO7C1tnUi4v6aayQg0NokVHJ/ZW50 UB54T+WJkoDvSf+gpNJQRk9IMnUnFWbq/JuYndDYE48JQn/4RY/60xj4ICKWwqKkF5Rv qszg== X-Gm-Message-State: ALoCoQmNZmMpWMhNeycb1kYr/c54dxWJQnmrVn0cuHqd/H5xAyq0xjB/DpE2By6dAc6BhCcFH17t X-Received: by 10.50.253.12 with SMTP id zw12mr16146961igc.24.1424733742336; Mon, 23 Feb 2015 15:22:22 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com. [209.85.223.173]) by mx.google.com with ESMTPSA id z29sm22951657ioi.36.2015.02.23.15.22.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 15:22:21 -0800 (PST) Received: by iecrp18 with SMTP id rp18so27805114iec.1 for ; Mon, 23 Feb 2015 15:22:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.106.203 with SMTP id a11mr14541017icp.2.1424733740186; Mon, 23 Feb 2015 15:22:20 -0800 (PST) Received: by 10.36.20.10 with HTTP; Mon, 23 Feb 2015 15:22:20 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> Date: Mon, 23 Feb 2015 18:22:20 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf304352c87bc357050fc9ac3c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 23:22:25 -0000 --20cf304352c87bc357050fc9ac3c Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 3:37 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > I would like to make sure that the specification explicitly prohibits > this and states > > somewhere that fingerprint and setup role MUST NOT change unless the > transport > > parameters change as well. > > As far as SCTP-SDP is concerned, personally I don't (at least not at this > moment) have a problem with such restriction. > > However, when BUNDLE is used, SRTP and SCTP may share a single DTLS > connection. It could cause problems if SRTP and SCTP define different rules > when a DTLS connection can be re-established. And, SRTP-DTLS does not > forbid that fingerprint and setup role change, unless the transport > parameters also change. > > >Unless this is prohibited, some sort of specification language needs to > be provided stating how > >multiple DTLS connections can run over a single 5-tuple. This is not > currently allowed or > >defined anywhere and it is required for DTLS to operate with offer/answer > end transport connection reuse. > > Doesn't the DTLS spec say that, when a new DTLS connection has been > established, you need to maintain the keys for the previous connection for > a while, in order to handle late packets? > This is specific to DTLS re-key (not a complete new session establishment) in combination with SRTP. In case of DTLS re-key with DTLS data frames the epoch number can be used to reference the correct cipher settings. This would be used for SCTP or BFCP which run on top of DTLS data. Unlike re-key, creating a new session over the same transport at the same time as the existing session continues to run is not defined for DTLS. >As I have stated on several occasions, I do not like the option of > allowing multiple DTLS connections > >over the same transport since it complicates implementations for no > reason. Unless someone provides > >a compelling use case why this is needed I strongly believe this should > not be allowed. > > I don't have a use-case, but because of BUNDLE I'd like to have the same > rules for SRTP and SCTP. > I agree that common rules for DTLS offer/answer would be beneficial for everybody. It is currently either undefined or broken in a similar manner for both DTLS-SRTP and SCTP draft. New BFCP drafts actually reference DTLS-SRTP as far as DTLS session setup is concerned, so they will suffer from the same problem. Furthermore, I do not think anybody has any intent to implement DTLS changes without transport changes for any protocol. I think it would be better to define this correctly at some point vs to keep repeating the same uncertainty. > Of course, we could add your suggested restriction also to SRTP... > > But, would we then need add the restriction also to other protocols using > DTLS? E.g. BFCP. > > The best thing would be to have generic Offer/Answer rules for DTLS, which > all usages (SRTP, SCTP, BFCP etc) then reference, but it's too late for > that... > It might not be a bad idea to create such a document and use it to update DTLS-SRTP and other protocols which use DTLS with offer/answer. I am actually not sure what protocols are out there, since DTLS for BFCP is only mentioned in the new RFC 4583 bis drafts. RFC 4583 bis draft would actually benefit from a document that describes DTLS offer/answer setup, which it can reference instead of DTLS-SRTP. All the new work, such as SCTP, can reference this new document as well. I would guess this will need to go to MMUSIC. --20cf304352c87bc357050fc9ac3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 3:37 PM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:
> I would like to make sure that the specification explicitly prohibit= s this and states
> somewhere that fingerprint and setup role MUST NOT change unless the t= ransport
> parameters change as well.

As far as SCTP-SDP is concerned, personally I don't (at least no= t at this moment) have a problem with such restriction.

However, when BUNDLE is used, SRTP and SCTP may share a single DTLS connect= ion. It could cause problems if SRTP and SCTP define different rules when a= DTLS connection can be re-established. And, SRTP-DTLS does not forbid that= fingerprint and setup role change, unless the transport parameters also ch= ange.

>Unless this is prohibited, some sort of specification language needs to= be provided stating how
>multiple DTLS connections can run over a single 5-tuple. This is not cu= rrently allowed or
>defined anywhere and it is required for DTLS to operate with offer/answ= er end transport connection reuse.

Doesn't the DTLS spec say that, when a new DTLS connection has b= een established, you need to maintain the keys for the previous connection = for a while, in order to handle late packets?

This is specific to DTLS re-key (not a complete new session establis= hment) in combination with SRTP. In case of DTLS re-key with DTLS data fram= es the epoch number can be used to reference the correct cipher settings. T= his would be used for SCTP or BFCP which run on top of DTLS data.

Unlike re-key, creating a new session over the same transpo= rt at the same time as the existing session continues to run is not defined= for DTLS.

>As I h= ave stated on several occasions, I do not like the option of allowing multi= ple DTLS connections
>over the same transport since it complicates implementations for no rea= son. Unless someone provides
>a compelling use case why this is needed I strongly believe this should= not be allowed.

I don't have a use-case, but because of BUNDLE I'd like to h= ave the same rules for SRTP and SCTP.

I= agree that common rules for DTLS offer/answer would be beneficial for ever= ybody. It is currently either undefined or broken in a similar manner for b= oth DTLS-SRTP and SCTP draft. New BFCP drafts actually reference DTLS-SRTP = as far as DTLS session setup is concerned, so they will suffer from the sam= e problem. Furthermore, =C2=A0I do not think anybody has any intent to impl= ement DTLS changes without transport changes for any protocol. I think it w= ould be better to define this correctly at some point vs to keep repeating = the same uncertainty.
=C2=A0
Of course, we = could add your suggested restriction also to SRTP...

But, would we then need add the restriction also to other protocols using D= TLS? E.g. BFCP.

The best thing would be to have generic Offer/Answer rules for DTLS, which = all usages (SRTP, SCTP, BFCP etc) then reference, but it's too late for= that...

It might not be a bad idea to = create such a document and use it to update DTLS-SRTP and other protocols w= hich use DTLS with offer/answer. I am actually not sure what protocols are = out there, since DTLS for BFCP is only mentioned in the new RFC 4583 bis dr= afts.=C2=A0RFC 4583 bis draft would actually benefit from a document=C2=A0t= hat describes DTLS offer/answer setup, which it can reference instead of DT= LS-SRTP. All the new work, such as SCTP, can reference this new document as= well. I would guess this will need to go to MMUSIC.
--20cf304352c87bc357050fc9ac3c-- From nobody Tue Feb 24 07:13:00 2015 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 B32B61A87D4 for ; Tue, 24 Feb 2015 07:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGqP7ND_GZ94 for ; Tue, 24 Feb 2015 07:12:57 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACB01A003B for ; Tue, 24 Feb 2015 07:12:57 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-13-54ec94f6b1ca Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 47.CB.24955.6F49CE45; Tue, 24 Feb 2015 16:12:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Tue, 24 Feb 2015 16:12:54 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Offer/Answer and DTLS Thread-Index: AQHQTscg+zO/WiBUDE6I3wOpBInhbZz875qAgAADh4CAALjJ8IAAvXsAgABG7mCAABQgAIABJnMA Date: Tue, 24 Feb 2015 15:12:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D717148@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@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+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvje73KW9CDKY281pM32djMePCVGaL tf/a2R2YPc41vGf3WLLkJ5PHrSkFAcxRXDYpqTmZZalF+nYJXBm3dzaxF6xgrnj85hprA+Mc 5i5GTg4JAROJzUcuMELYYhIX7q1nA7GFBI4wStw6WdrFyAVkL2GU+Hz5BFARBwebgIVE9z9t kBoRARuJfxcusIPYzAJeEjcu9IL1CgtoS3Qv6WGEqNGRaPs5nQ3CjpL4cegGK4jNIqAqcfrL J7A4r4CvxI1rfawQu74wS1ye8o8JJMEpECix6c0eFhCbEei476fWMEEsE5e49WQ+E8TRAhJL 9pyHekZU4uXjf6wQtpJE45InrCA3MwtoSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUm4Vk6iyE jllIOmYh6VjAyLKKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCWDm75rbqD8fIbx0OMAhyM Sjy8BYpvQoRYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBh3 Pniays1uXtuavfdNS2T3HSi61TRfYkakjK2PR6jepq87GZ5lvPqVv15xWdLXi1zG1++fcSnv iOyMv8pbJXxTlpV1oVy0TGvvvKbiK2xJDbxRBe7B02auvGSyOO1EufW1BMmVu5V6j8zl2b+q qt++Q/Gy9nWriTxNThJZyvIx7C5xsz1OKbEUZyQaajEXFScCAMtFsUaGAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 15:12:58 -0000 SGksDQoNCj4+IERvZXNuJ3QgdGhlIERUTFMgc3BlYyBzYXkgdGhhdCwgd2hlbiBhIG5ldyBEVExT IGNvbm5lY3Rpb24gPj4gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIHlvdSBuZWVkIHRvIG1haW50YWlu IHRoZSBrZXlzIGZvciB0aGUgPj4gcHJldmlvdXMgY29ubmVjdGlvbiBmb3IgYSB3aGlsZSwgaW4g b3JkZXIgdG8gaGFuZGxlIGxhdGUgDQo+PiBwYWNrZXRzPw0KPg0KPiBBRkFJSyB0aGUgc3BlYyBz dGF0ZXMgdGhhdCBqdXN0IGluIHRoZSBjYXNlIG9mIERUTFMgcmVrZXlpbmcuDQoNCk9rLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KIA0K From nobody Tue Feb 24 07:20:53 2015 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 875241A87E2 for ; Tue, 24 Feb 2015 07:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ytz3Djx2MU for ; Tue, 24 Feb 2015 07:20:48 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C98B1A8827 for ; Tue, 24 Feb 2015 07:20:08 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-cc-54ec96a68330 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 00.32.04076.6A69CE45; Tue, 24 Feb 2015 16:20:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Tue, 24 Feb 2015 16:20:06 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [rtcweb] Offer/Answer and DTLS Thread-Index: AQHQTscg+zO/WiBUDE6I3wOpBInhbZz875qAgAADh4CAALjJ8IAAvXsAgABG7mCAACB/AIABGmHw Date: Tue, 24 Feb 2015 15:20:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D717168ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rnf5tDchBueec1lcO/OP0WLGhanM Fmv/tbM7MHvsnHWX3WPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlrGydzlbQ0s1YsWp2cAPj inbGLkZODgkBE4npX7ZC2WISF+6tZwOxhQSOMEo8/p3TxcgFZC9hlDixvJm1i5GDg03AQqL7 nzZIjYiAqsTf75OZQGxmgRCJh2ffMYPYwgLaEt1LehghanQk2n5OZ4OwoyRunpwNFmcB6v33 bTlLFyM7B6+Ar8TvCohNX5gl5p64zQpSwikQKLH3+lqwckag076fWgO1Slzi1pP5TBAnC0gs 2XOeGcIWlXj5+B8rhK0k0bjkCStEfb7E91Wz2EFsXgFBiZMzn7BMYBSdhWTULCRls5CUzQJ6 mFlAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3Z xAiMvoNbflvtYDz43PEQowAHoxIPb4HimxAh1sSy4srcQ4zSHCxK4rx2xodChATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTC6p+95v+Pxgpqd/1dnhBySNTpbp7XtkbFIhWEGy4KacvU3Lz7u krLNXvb35NLiL3PWNKgcLInxuByxh6PCa0HhEvHgoLumDDsnXvR/+q5k+z3W3nUzbTk2Pl/x 6If4hoXJUzflGhvnczaWr7OKUkgXDPBk4VJ8NS83S9CC2aedcdfBiYZP33orsRRnJBpqMRcV JwIA2h6bvZ8CAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 15:20:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D717168ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4gSSB3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBzcGVjaWZpY2F0aW9u IGV4cGxpY2l0bHkgcHJvaGliaXRzIHRoaXMgYW5kIHN0YXRlcw0KPiBzb21ld2hlcmUgdGhhdCBm aW5nZXJwcmludCBhbmQgc2V0dXAgcm9sZSBNVVNUIE5PVCBjaGFuZ2UgdW5sZXNzIHRoZSB0cmFu c3BvcnQNCj4gcGFyYW1ldGVycyBjaGFuZ2UgYXMgd2VsbC4NCg0KQXMgZmFyIGFzIFNDVFAtU0RQ IGlzIGNvbmNlcm5lZCwgcGVyc29uYWxseSBJIGRvbid0IChhdCBsZWFzdCBub3QgYXQgdGhpcyBt b21lbnQpIGhhdmUgYSBwcm9ibGVtIHdpdGggc3VjaCByZXN0cmljdGlvbi4NCg0KSG93ZXZlciwg d2hlbiBCVU5ETEUgaXMgdXNlZCwgU1JUUCBhbmQgU0NUUCBtYXkgc2hhcmUgYSBzaW5nbGUgRFRM UyBjb25uZWN0aW9uLiBJdCBjb3VsZCBjYXVzZSBwcm9ibGVtcyBpZiBTUlRQIGFuZCBTQ1RQIGRl ZmluZSBkaWZmZXJlbnQgcnVsZXMgd2hlbiBhIERUTFMgY29ubmVjdGlvbiBjYW4gYmUgcmUtZXN0 YWJsaXNoZWQuIEFuZCwgU1JUUC1EVExTIGRvZXMgbm90IGZvcmJpZCB0aGF0IGZpbmdlcnByaW50 IGFuZCBzZXR1cCByb2xlIGNoYW5nZSwgdW5sZXNzIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBh bHNvIGNoYW5nZS4NCg0KPlVubGVzcyB0aGlzIGlzIHByb2hpYml0ZWQsIHNvbWUgc29ydCBvZiBz cGVjaWZpY2F0aW9uIGxhbmd1YWdlIG5lZWRzIHRvIGJlIHByb3ZpZGVkIHN0YXRpbmcgaG93DQo+ bXVsdGlwbGUgRFRMUyBjb25uZWN0aW9ucyBjYW4gcnVuIG92ZXIgYSBzaW5nbGUgNS10dXBsZS4g VGhpcyBpcyBub3QgY3VycmVudGx5IGFsbG93ZWQgb3INCj5kZWZpbmVkIGFueXdoZXJlIGFuZCBp dCBpcyByZXF1aXJlZCBmb3IgRFRMUyB0byBvcGVyYXRlIHdpdGggb2ZmZXIvYW5zd2VyIGVuZCB0 cmFuc3BvcnQgY29ubmVjdGlvbiByZXVzZS4NCg0KRG9lc24ndCB0aGUgRFRMUyBzcGVjIHNheSB0 aGF0LCB3aGVuIGEgbmV3IERUTFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgeW91 IG5lZWQgdG8gbWFpbnRhaW4gdGhlIGtleXMgZm9yIHRoZSBwcmV2aW91cyBjb25uZWN0aW9uIGZv ciBhIHdoaWxlLCBpbiBvcmRlciB0byBoYW5kbGUgbGF0ZSBwYWNrZXRzPw0KDQo+VGhpcyBpcyBz cGVjaWZpYyB0byBEVExTIHJlLWtleSAobm90IGEgY29tcGxldGUgbmV3IHNlc3Npb24gZXN0YWJs aXNobWVudCkgaW4gY29tYmluYXRpb24gd2l0aCBTUlRQLiBJbiBjYXNlIG9mID5EVExTIHJlLWtl eSB3aXRoIERUTFMgZGF0YSBmcmFtZXMgdGhlIGVwb2NoIG51bWJlciBjYW4gYmUgdXNlZCB0byBy ZWZlcmVuY2UgdGhlIGNvcnJlY3QgY2lwaGVyIHNldHRpbmdzLiBUaGlzID53b3VsZCBiZSB1c2Vk IGZvciBTQ1RQIG9yIEJGQ1Agd2hpY2ggcnVuIG9uIHRvcCBvZiBEVExTIGRhdGEuDQo+DQo+VW5s aWtlIHJlLWtleSwgY3JlYXRpbmcgYSBuZXcgc2Vzc2lvbiBvdmVyIHRoZSBzYW1lIHRyYW5zcG9y dCBhdCB0aGUgc2FtZSB0aW1lIGFzIHRoZSBleGlzdGluZyBzZXNzaW9uIGNvbnRpbnVlcyB0byBy dW4gPmlzIG5vdCBkZWZpbmVkIGZvciBEVExTLg0KDQpPay4gV291bGQgaXQgYmUgdXNlZnVsIHRv IG1lbnRpb24gdGhhdCByZS1rZXlpbmcgY2FuIGJlIGRvbmUgd2l0aG91dCByZS1uZWdvdGlhdGlv biB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQ/IE9yLCBpcyBpdCBvYnZpb3VzPw0KDQpCZWNhdXNl LCBJIGFzc3VtZSB3ZSBzdGlsbCB3YW50IHRvIGFsbG93IHJlLWtleWluZywgb3I/DQoNCj5BcyBJ IGhhdmUgc3RhdGVkIG9uIHNldmVyYWwgb2NjYXNpb25zLCBJIGRvIG5vdCBsaWtlIHRoZSBvcHRp b24gb2YgYWxsb3dpbmcgbXVsdGlwbGUgRFRMUyBjb25uZWN0aW9ucw0KPm92ZXIgdGhlIHNhbWUg dHJhbnNwb3J0IHNpbmNlIGl0IGNvbXBsaWNhdGVzIGltcGxlbWVudGF0aW9ucyBmb3Igbm8gcmVh c29uLiBVbmxlc3Mgc29tZW9uZSBwcm92aWRlcw0KPmEgY29tcGVsbGluZyB1c2UgY2FzZSB3aHkg dGhpcyBpcyBuZWVkZWQgSSBzdHJvbmdseSBiZWxpZXZlIHRoaXMgc2hvdWxkIG5vdCBiZSBhbGxv d2VkLg0KDQpJIGRvbid0IGhhdmUgYSB1c2UtY2FzZSwgYnV0IGJlY2F1c2Ugb2YgQlVORExFIEkn ZCBsaWtlIHRvIGhhdmUgdGhlIHNhbWUgcnVsZXMgZm9yIFNSVFAgYW5kIFNDVFAuDQoNCj5JIGFn cmVlIHRoYXQgY29tbW9uIHJ1bGVzIGZvciBEVExTIG9mZmVyL2Fuc3dlciB3b3VsZCBiZSBiZW5l ZmljaWFsIGZvciBldmVyeWJvZHkuIEl0IGlzIGN1cnJlbnRseSBlaXRoZXIgdW5kZWZpbmVkID5v ciBicm9rZW4gaW4gYSBzaW1pbGFyIG1hbm5lciBmb3IgYm90aCBEVExTLVNSVFAgYW5kIFNDVFAg ZHJhZnQuIE5ldyBCRkNQIGRyYWZ0cyBhY3R1YWxseSByZWZlcmVuY2UgRFRMUy1TUlRQID5hcyBm YXIgYXMgRFRMUyBzZXNzaW9uIHNldHVwIGlzIGNvbmNlcm5lZCwgc28gdGhleSB3aWxsIHN1ZmZl ciBmcm9tIHRoZSBzYW1lIHByb2JsZW0uIEZ1cnRoZXJtb3JlLCAgSSBkbyBub3QgdGhpbmsgPmFu eWJvZHkgaGFzIGFueSBpbnRlbnQgdG8gaW1wbGVtZW50IERUTFMgY2hhbmdlcyB3aXRob3V0IHRy YW5zcG9ydCBjaGFuZ2VzIGZvciBhbnkgcHJvdG9jb2wuIEkgdGhpbmsgaXQgd291bGQgYmUgPmJl dHRlciB0byBkZWZpbmUgdGhpcyBjb3JyZWN0bHkgYXQgc29tZSBwb2ludCB2cyB0byBrZWVwIHJl cGVhdGluZyB0aGUgc2FtZSB1bmNlcnRhaW50eS4NCg0KU28sIHdvdWxkIGFueW9uZSAqb2JqZWN0 KiB0byBzdWNoIHJlc3RyaWN0aW9uPyBJIGhhdmUgc2VlbiBubyBvYmplY3Rpb25zIHNvIGZhci4N Cg0KDQpPZiBjb3Vyc2UsIHdlIGNvdWxkIGFkZCB5b3VyIHN1Z2dlc3RlZCByZXN0cmljdGlvbiBh bHNvIHRvIFNSVFAuLi4NCg0KQnV0LCB3b3VsZCB3ZSB0aGVuIG5lZWQgYWRkIHRoZSByZXN0cmlj dGlvbiBhbHNvIHRvIG90aGVyIHByb3RvY29scyB1c2luZyBEVExTPyBFLmcuIEJGQ1AuDQoNClRo ZSBiZXN0IHRoaW5nIHdvdWxkIGJlIHRvIGhhdmUgZ2VuZXJpYyBPZmZlci9BbnN3ZXIgcnVsZXMg Zm9yIERUTFMsIHdoaWNoIGFsbCB1c2FnZXMgKFNSVFAsIFNDVFAsIEJGQ1AgZXRjKSB0aGVuIHJl ZmVyZW5jZSwgYnV0IGl0J3MgdG9vIGxhdGUgZm9yIHRoYXQuLi4NCg0KPkl0IG1pZ2h0IG5vdCBi ZSBhIGJhZCBpZGVhIHRvIGNyZWF0ZSBzdWNoIGEgZG9jdW1lbnQgYW5kIHVzZSBpdCB0byB1cGRh dGUgRFRMUy1TUlRQIGFuZCBvdGhlciBwcm90b2NvbHMgd2hpY2ggdXNlID5EVExTIHdpdGggb2Zm ZXIvYW5zd2VyLiBJIGFtIGFjdHVhbGx5IG5vdCBzdXJlIHdoYXQgcHJvdG9jb2xzIGFyZSBvdXQg dGhlcmUsIHNpbmNlIERUTFMgZm9yIEJGQ1AgaXMgb25seSBtZW50aW9uZWQgPmluIHRoZSBuZXcg UkZDIDQ1ODMgYmlzIGRyYWZ0cy4gUkZDIDQ1ODMgYmlzIGRyYWZ0IHdvdWxkIGFjdHVhbGx5IGJl bmVmaXQgZnJvbSBhIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIERUTFMgPm9mZmVyL2Fuc3dlciBz ZXR1cCwgd2hpY2ggaXQgY2FuIHJlZmVyZW5jZSBpbnN0ZWFkIG9mIERUTFMtU1JUUC4gQWxsIHRo ZSBuZXcgd29yaywgc3VjaCBhcyBTQ1RQLCBjYW4gcmVmZXJlbmNlIHRoaXMgPm5ldyBkb2N1bWVu dCBhcyB3ZWxsLiBJIHdvdWxkIGd1ZXNzIHRoaXMgd2lsbCBuZWVkIHRvIGdvIHRvIE1NVVNJQy4N Cg0KWWVzLiBJZiB3ZSwgd2l0aGluIHRoZSBSVENXRUIgY29tbXVuaXR5LCBhZ3JlZSB0aGF0IHdl IHdhbnQgdGhlIHJlc3RyaWN0aW9uIHlvdeKAmXZlIHN1Z2dlc3RlZCwgSSB3aWxsIGJyaW5nIHRo ZSBkaXNjdXNzaW9uIHRvIE1NVVNJQy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D717168ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEkg d291bGQgbGlrZSB0byBtYWtlIHN1cmUgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBleHBsaWNpdGx5 IHByb2hpYml0cyB0aGlzIGFuZCBzdGF0ZXM8YnI+DQomZ3Q7IHNvbWV3aGVyZSB0aGF0IGZpbmdl cnByaW50IGFuZCBzZXR1cCByb2xlIE1VU1QgTk9UIGNoYW5nZSB1bmxlc3MgdGhlIHRyYW5zcG9y dDxicj4NCiZndDsgcGFyYW1ldGVycyBjaGFuZ2UgYXMgd2VsbC48YnI+DQo8YnI+DQpBcyBmYXIg YXMgU0NUUC1TRFAgaXMgY29uY2VybmVkLCBwZXJzb25hbGx5IEkgZG9uJ3QgKGF0IGxlYXN0IG5v dCBhdCB0aGlzIG1vbWVudCkgaGF2ZSBhIHByb2JsZW0gd2l0aCBzdWNoIHJlc3RyaWN0aW9uLjxi cj4NCjxicj4NCkhvd2V2ZXIsIHdoZW4gQlVORExFIGlzIHVzZWQsIFNSVFAgYW5kIFNDVFAgbWF5 IHNoYXJlIGEgc2luZ2xlIERUTFMgY29ubmVjdGlvbi4gSXQgY291bGQgY2F1c2UgcHJvYmxlbXMg aWYgU1JUUCBhbmQgU0NUUCBkZWZpbmUgZGlmZmVyZW50IHJ1bGVzIHdoZW4gYSBEVExTIGNvbm5l Y3Rpb24gY2FuIGJlIHJlLWVzdGFibGlzaGVkLiBBbmQsIFNSVFAtRFRMUyBkb2VzIG5vdCBmb3Ji aWQgdGhhdCBmaW5nZXJwcmludCBhbmQgc2V0dXAgcm9sZSBjaGFuZ2UsDQogdW5sZXNzIHRoZSB0 cmFuc3BvcnQgcGFyYW1ldGVycyBhbHNvIGNoYW5nZS48YnI+DQo8YnI+DQomZ3Q7VW5sZXNzIHRo aXMgaXMgcHJvaGliaXRlZCwgc29tZSBzb3J0IG9mIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UgbmVl ZHMgdG8gYmUgcHJvdmlkZWQgc3RhdGluZyBob3c8YnI+DQomZ3Q7bXVsdGlwbGUgRFRMUyBjb25u ZWN0aW9ucyBjYW4gcnVuIG92ZXIgYSBzaW5nbGUgNS10dXBsZS4gVGhpcyBpcyBub3QgY3VycmVu dGx5IGFsbG93ZWQgb3I8YnI+DQomZ3Q7ZGVmaW5lZCBhbnl3aGVyZSBhbmQgaXQgaXMgcmVxdWly ZWQgZm9yIERUTFMgdG8gb3BlcmF0ZSB3aXRoIG9mZmVyL2Fuc3dlciBlbmQgdHJhbnNwb3J0IGNv bm5lY3Rpb24gcmV1c2UuPGJyPg0KPGJyPg0KRG9lc24ndCB0aGUgRFRMUyBzcGVjIHNheSB0aGF0 LCB3aGVuIGEgbmV3IERUTFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgeW91IG5l ZWQgdG8gbWFpbnRhaW4gdGhlIGtleXMgZm9yIHRoZSBwcmV2aW91cyBjb25uZWN0aW9uIGZvciBh IHdoaWxlLCBpbiBvcmRlciB0byBoYW5kbGUgbGF0ZSBwYWNrZXRzPzxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1RoaXMgaXMg c3BlY2lmaWMgdG8gRFRMUyByZS1rZXkgKG5vdCBhIGNvbXBsZXRlIG5ldyBzZXNzaW9uIGVzdGFi bGlzaG1lbnQpIGluIGNvbWJpbmF0aW9uIHdpdGggU1JUUC4gSW4gY2FzZSBvZiAmZ3Q7RFRMUyBy ZS1rZXkgd2l0aCBEVExTIGRhdGEgZnJhbWVzIHRoZSBlcG9jaCBudW1iZXIgY2FuIGJlIHVzZWQg dG8gcmVmZXJlbmNlIHRoZSBjb3JyZWN0IGNpcGhlciBzZXR0aW5ncy4gVGhpcyAmZ3Q7d291bGQg YmUgdXNlZA0KIGZvciBTQ1RQIG9yIEJGQ1Agd2hpY2ggcnVuIG9uIHRvcCBvZiBEVExTIGRhdGEu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7VW5saWtlIHJlLWtleSwgY3JlYXRpbmcgYSBuZXcgc2Vzc2lvbiBvdmVyIHRoZSBzYW1l IHRyYW5zcG9ydCBhdCB0aGUgc2FtZSB0aW1lIGFzIHRoZSBleGlzdGluZyBzZXNzaW9uIGNvbnRp bnVlcyB0byBydW4gJmd0O2lzIG5vdCBkZWZpbmVkIGZvciBEVExTLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9rLiBXb3Vs ZCBpdCBiZSB1c2VmdWwgdG8gbWVudGlvbiB0aGF0IHJlLWtleWluZyBjYW4gYmUgZG9uZSB3aXRo b3V0IHJlLW5lZ290aWF0aW9uIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydD8gT3IsIGlzIGl0IG9i dmlvdXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJlY2F1c2UsIEkgYXNzdW1lIHdlIHN0aWxsIHdhbnQgdG8g YWxsb3cgcmUta2V5aW5nLCBvcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtBcyBJIGhhdmUgc3RhdGVkIG9uIHNl dmVyYWwgb2NjYXNpb25zLCBJIGRvIG5vdCBsaWtlIHRoZSBvcHRpb24gb2YgYWxsb3dpbmcgbXVs dGlwbGUgRFRMUyBjb25uZWN0aW9uczxicj4NCiZndDtvdmVyIHRoZSBzYW1lIHRyYW5zcG9ydCBz aW5jZSBpdCBjb21wbGljYXRlcyBpbXBsZW1lbnRhdGlvbnMgZm9yIG5vIHJlYXNvbi4gVW5sZXNz IHNvbWVvbmUgcHJvdmlkZXM8YnI+DQomZ3Q7YSBjb21wZWxsaW5nIHVzZSBjYXNlIHdoeSB0aGlz IGlzIG5lZWRlZCBJIHN0cm9uZ2x5IGJlbGlldmUgdGhpcyBzaG91bGQgbm90IGJlIGFsbG93ZWQu PGJyPg0KPGJyPg0KSSBkb24ndCBoYXZlIGEgdXNlLWNhc2UsIGJ1dCBiZWNhdXNlIG9mIEJVTkRM RSBJJ2QgbGlrZSB0byBoYXZlIHRoZSBzYW1lIHJ1bGVzIGZvciBTUlRQIGFuZCBTQ1RQLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0O0kgYWdyZWUgdGhhdCBjb21tb24gcnVsZXMgZm9yIERUTFMgb2ZmZXIvYW5zd2VyIHdvdWxk IGJlIGJlbmVmaWNpYWwgZm9yIGV2ZXJ5Ym9keS4gSXQgaXMgY3VycmVudGx5IGVpdGhlciB1bmRl ZmluZWQgJmd0O29yIGJyb2tlbiBpbiBhIHNpbWlsYXIgbWFubmVyIGZvciBib3RoIERUTFMtU1JU UCBhbmQgU0NUUCBkcmFmdC4gTmV3IEJGQ1AgZHJhZnRzIGFjdHVhbGx5IHJlZmVyZW5jZSBEVExT LVNSVFAgJmd0O2FzIGZhcg0KIGFzIERUTFMgc2Vzc2lvbiBzZXR1cCBpcyBjb25jZXJuZWQsIHNv IHRoZXkgd2lsbCBzdWZmZXIgZnJvbSB0aGUgc2FtZSBwcm9ibGVtLiBGdXJ0aGVybW9yZSwgJm5i c3A7SSBkbyBub3QgdGhpbmsgJmd0O2FueWJvZHkgaGFzIGFueSBpbnRlbnQgdG8gaW1wbGVtZW50 IERUTFMgY2hhbmdlcyB3aXRob3V0IHRyYW5zcG9ydCBjaGFuZ2VzIGZvciBhbnkgcHJvdG9jb2wu IEkgdGhpbmsgaXQgd291bGQgYmUgJmd0O2JldHRlciB0byBkZWZpbmUgdGhpcyBjb3JyZWN0bHkg YXQNCiBzb21lIHBvaW50IHZzIHRvIGtlZXAgcmVwZWF0aW5nIHRoZSBzYW1lIHVuY2VydGFpbnR5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlNvLCB3b3VsZCBhbnlvbmUgKjxiPm9iamVjdDwvYj4qIHRvIHN1Y2ggcmVzdHJpY3Rpb24/IEkg aGF2ZSBzZWVuIG5vIG9iamVjdGlvbnMgc28gZmFyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9mIGNvdXJzZSwgd2UgY291 bGQgYWRkIHlvdXIgc3VnZ2VzdGVkIHJlc3RyaWN0aW9uIGFsc28gdG8gU1JUUC4uLjxicj4NCjxi cj4NCkJ1dCwgd291bGQgd2UgdGhlbiBuZWVkIGFkZCB0aGUgcmVzdHJpY3Rpb24gYWxzbyB0byBv dGhlciBwcm90b2NvbHMgdXNpbmcgRFRMUz8gRS5nLiBCRkNQLjxicj4NCjxicj4NClRoZSBiZXN0 IHRoaW5nIHdvdWxkIGJlIHRvIGhhdmUgZ2VuZXJpYyBPZmZlci9BbnN3ZXIgcnVsZXMgZm9yIERU TFMsIHdoaWNoIGFsbCB1c2FnZXMgKFNSVFAsIFNDVFAsIEJGQ1AgZXRjKSB0aGVuIHJlZmVyZW5j ZSwgYnV0IGl0J3MgdG9vIGxhdGUgZm9yIHRoYXQuLi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtJdCBtaWdodCBub3QgYmUg YSBiYWQgaWRlYSB0byBjcmVhdGUgc3VjaCBhIGRvY3VtZW50IGFuZCB1c2UgaXQgdG8gdXBkYXRl IERUTFMtU1JUUCBhbmQgb3RoZXIgcHJvdG9jb2xzIHdoaWNoIHVzZSAmZ3Q7RFRMUyB3aXRoIG9m ZmVyL2Fuc3dlci4gSSBhbSBhY3R1YWxseSBub3Qgc3VyZSB3aGF0IHByb3RvY29scyBhcmUgb3V0 IHRoZXJlLCBzaW5jZSBEVExTIGZvciBCRkNQIGlzIG9ubHkgbWVudGlvbmVkICZndDtpbiB0aGUN CiBuZXcgUkZDIDQ1ODMgYmlzIGRyYWZ0cy4mbmJzcDtSRkMgNDU4MyBiaXMgZHJhZnQgd291bGQg YWN0dWFsbHkgYmVuZWZpdCBmcm9tIGEgZG9jdW1lbnQmbmJzcDt0aGF0IGRlc2NyaWJlcyBEVExT ICZndDtvZmZlci9hbnN3ZXIgc2V0dXAsIHdoaWNoIGl0IGNhbiByZWZlcmVuY2UgaW5zdGVhZCBv ZiBEVExTLVNSVFAuIEFsbCB0aGUgbmV3IHdvcmssIHN1Y2ggYXMgU0NUUCwgY2FuIHJlZmVyZW5j ZSB0aGlzICZndDtuZXcgZG9jdW1lbnQgYXMgd2VsbC4gSSB3b3VsZCBndWVzcw0KIHRoaXMgd2ls bCBuZWVkIHRvIGdvIHRvIE1NVVNJQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ZZXMuIElmIHdlLCB3aXRoaW4gdGhlIFJU Q1dFQiBjb21tdW5pdHksIGFncmVlIHRoYXQgd2Ugd2FudCB0aGUgcmVzdHJpY3Rpb24geW914oCZ dmUgc3VnZ2VzdGVkLCBJIHdpbGwgYnJpbmcgdGhlIGRpc2N1c3Npb24gdG8gTU1VU0lDLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D717168ESESSMB209erics_-- From nobody Tue Feb 24 07:31:01 2015 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 208EC1A87D7 for ; Tue, 24 Feb 2015 07:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPYFaQm3J8HC for ; Tue, 24 Feb 2015 07:30:55 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE0E1A87D1 for ; Tue, 24 Feb 2015 07:30:55 -0800 (PST) Received: by iecrp18 with SMTP id rp18so32802809iec.9 for ; Tue, 24 Feb 2015 07:30:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BmYFWOxINYA6bpufed+BYjergP3ZybdexyoCOjj+ZKk=; b=fqyDB7XWeORxnPRZx9T+w1wuaaUTX/YmIjyTFAaCtzBzRPaKJLG54bifBK2xGwR7C7 rgTnJ4d0iCRX8bAZV/tjb7TfVS142DlVdLBra5e4yp52qGxVYbSXyTWAs1owF4qupnsL Ejkf10EpjdBVJse0IzYceClkLdoS0d8s2QjVj8ZqNNNF6EAnl5NMTYl1/YDnNP3BxDWx yv90LRfmjN4ijXfc9qhbFXauF9FwOsNBonRqoxfhHF+S9kpmqfUlXovP4akK9s1L9Ojh 9ZEF8DYBsPQ4o25Dv3nAyO85qARvccyqR8PgdLUTYZql7Chq98eCMjYJEmJqNgWt6/QE WZRw== X-Gm-Message-State: ALoCoQlyvz/+CxEkF7t/40VNKqsC9uz83OCSTYgGzCScCzy50NMxLOLGOCRdGvdRNDw7JlFomIpw X-Received: by 10.50.79.161 with SMTP id k1mr20616978igx.14.1424791855044; Tue, 24 Feb 2015 07:30:55 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by mx.google.com with ESMTPSA id ip8sm8106691igb.17.2015.02.24.07.30.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 07:30:54 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so27424041igd.4 for ; Tue, 24 Feb 2015 07:30:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.254.4 with SMTP id ae4mr20498428igd.10.1424791852739; Tue, 24 Feb 2015 07:30:52 -0800 (PST) Received: by 10.36.20.10 with HTTP; Tue, 24 Feb 2015 07:30:52 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 10:30:52 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11343b92431840050fd73463 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 15:31:00 -0000 --001a11343b92431840050fd73463 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 10:20 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >This is specific to DTLS re-key (not a complete new session > establishment) in combination with SRTP. In case of >DTLS re-key with DTLS > data frames the epoch number can be used to reference the correct cipher > settings. This >would be used for SCTP or BFCP which run on top of DTLS > data. > > > > > >Unlike re-key, creating a new session over the same transport at the same > time as the existing session continues to run >is not defined for DTLS. > > > > Ok. Would it be useful to mention that re-keying can be done without > re-negotiation the underlying transport? Or, is it obvious? > > > > Because, I assume we still want to allow re-keying, or? > I think re-key is something that has a real value for long duration connections and should be allowed. Furthermore, DTLS re-key can be done at any time at the DTLS session layer without the need for the offer/answer exchange. Re-key is an integral part of DTLS protocol and it is well defined for both DTLS data (used by SCTP and BFCP) and DTLS-SRTP. Since it is an integral part of DTLS protocol, I would assume we do not need to explicitly state that it is allowed. _____________ Roman Shpount --001a11343b92431840050fd73463 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 24, 2015 at 10:20 AM, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:

>This is specific to DTLS re-key (not a complete = new session establishment) in combination with SRTP. In case of >DTLS re= -key with DTLS data frames the epoch number can be used to reference the co= rrect cipher settings. This >would be used for SCTP or BFCP which run on top of DTLS data.

>=C2=A0

>Unlike re-key, creating a new session over the s= ame transport at the same time as the existing session continues to run >= ;is not defined for DTLS.

=C2=A0

Ok. Would it be useful to mention that re-keying can be do= ne without re-negotiation the underlying transport? Or, is it obvious?

=C2=A0

Because, I assume we still want to allow re-keying, or?


I thi= nk re-key is something that has a real value for long duration connections = and should be allowed. Furthermore, DTLS re-key can be done at any time at = the DTLS session layer without the need for the offer/answer exchange. Re-k= ey is an integral part of DTLS protocol and it is well defined for both DTL= S data (used by SCTP and BFCP) and DTLS-SRTP. Since it is an integral part = of DTLS protocol, I would assume we do not need to explicitly state that it= is allowed.

_= ____________
Roman Shpount

<= /div> --001a11343b92431840050fd73463-- From nobody Tue Feb 24 07:34:51 2015 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 EA1051A1AC6 for ; Tue, 24 Feb 2015 07:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4QUaBrsv_3l for ; Tue, 24 Feb 2015 07:34:46 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4040C1A1A72 for ; Tue, 24 Feb 2015 07:34:46 -0800 (PST) Received: by lbiz11 with SMTP id z11so25674573lbi.8 for ; Tue, 24 Feb 2015 07:34:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8oI7GXA311sSiEAmFeoSGap/Dy8hn3nh4lYR10OAL4w=; b=aFoHNNnpk0JkR15hG8D4WL87YzOMZXFiE56XKhPRxz3OVfKORE0Qg4+HhiRu0QRZMG Ap73a/BeRpTXhr2W/mnVfB1PJqZ8+hGnupcvllIF/enngQfMHoIPLktpcI31wtM27Gar 0i2u90KUcqn6QHOqH4F+zM68Hwnpt2ONxsHrgBQNYlRInVXbIIS8GmNiItv+Or6mhFw9 wz8CYDzt76LGGbrb+SBcwLy4X86tBXgaXZfHaE8z0xu5bFsiaBQxG2J6Rehh2436knFA 8MgzJ2BCRNsihH98mGR6GQNhiTuZgQdqWhPkWsfEc77rh2Y8iGTPUGQHAb4DCKk5rZnG i2NA== X-Gm-Message-State: ALoCoQmgOLbUcvXhbr/5yCpyN0EEO5Cf9ZZpj3GmhTG3dfGir+djVQqyRxsk0pqSdNPubAN1zhiq MIME-Version: 1.0 X-Received: by 10.152.43.101 with SMTP id v5mr14793688lal.83.1424792084591; Tue, 24 Feb 2015 07:34:44 -0800 (PST) Received: by 10.25.205.144 with HTTP; Tue, 24 Feb 2015 07:34:44 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 10:34:44 -0500 Message-ID: From: Simon Perreault To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3645014ccdb050fd742d6 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 15:34:51 -0000 --001a11c3645014ccdb050fd742d6 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 10:20 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >As I have stated on several occasions, I do not like the option of > allowing multiple DTLS connections > >over the same transport since it complicates implementations for no > reason. Unless someone provides > >a compelling use case why this is needed I strongly believe this should > not be allowed. > > I don't have a use-case, but because of BUNDLE I'd like to have the same > rules for SRTP and SCTP. > > > > >I agree that common rules for DTLS offer/answer would be beneficial for > everybody. It is currently either undefined >or broken in a similar manner > for both DTLS-SRTP and SCTP draft. New BFCP drafts actually reference > DTLS-SRTP >as far as DTLS session setup is concerned, so they will suffer > from the same problem. Furthermore, I do not think >anybody has any intent > to implement DTLS changes without transport changes for any protocol. I > think it would be >better to define this correctly at some point vs to keep > repeating the same uncertainty. > > > > So, would anyone **object** to such restriction? I have seen no > objections so far. > Are you referring specifically to *simultaneous* DTLS connections over the same transport? I wouldn't object to prohibiting those, but objecting would be pointless anyway because it's just impossible to have multiple simultaneous DTLS connections over the same transport. It's like saying "packets MUST NOT travel faster than the speed of light." If you're instead referring to multiple *non-simultaneous* DTLS connections over the same transport, then yes I would object. There's no valid reason to prohibit those. Simon --001a11c3645014ccdb050fd742d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 24, 2015 at 10:20 AM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:
>As I have stated on several occasions, I do not li= ke the option of allowing multiple DTLS connections
>over the same transport since it complicates implementations for no rea= son. Unless someone provides
>a compelling use case why this is needed I strongly believe this should= not be allowed.

I don't have a use-case, but because of BUNDLE I'd like to have the= same rules for SRTP and SCTP.

=C2=A0

>I agree that common rules for DTLS offer/answer = would be beneficial for everybody. It is currently either undefined >or = broken in a similar manner for both DTLS-SRTP and SCTP draft. New BFCP draf= ts actually reference DTLS-SRTP >as far as DTLS session setup is concerned, so they will suffer from the same prob= lem. Furthermore, =C2=A0I do not think >anybody has any intent to implem= ent DTLS changes without transport changes for any protocol. I think it wou= ld be >better to define this correctly at some point vs to keep repeating the same uncertainty.

=C2=A0

So, would anyone *object* to such restrictio= n? I have seen no objections so far.

Are you referring specifically to *simultaneous* DTLS connections over the= same transport? I wouldn't object to prohibiting those, but objecting = would be pointless anyway because it's just impossible to have multiple= simultaneous DTLS connections over the same transport. It's like sayin= g "packets MUST NOT travel faster than the speed of light."
=

If you'= re instead referring to multiple *non-simultaneous* DTLS connections over t= he same transport, then yes I would object. There's no valid reason to = prohibit those.

Simon
--001a11c3645014ccdb050fd742d6-- From nobody Tue Feb 24 07:36:42 2015 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 0D7B81A8794 for ; Tue, 24 Feb 2015 07:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVal2Cey-vCW for ; Tue, 24 Feb 2015 07:36:37 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E80B1A1BB3 for ; Tue, 24 Feb 2015 07:36:36 -0800 (PST) Received: by lams18 with SMTP id s18so26488438lam.11 for ; Tue, 24 Feb 2015 07:36:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PfBThY85D0upreZcXWUe1xHPtG/L4oOAG8WJNLqqApw=; b=CASEvdknf9J79f8bO5kDeNjcbmag8kZ+05ETpYg6VL+/ZK0m0R49wPobMiz0vhbbF6 Oqq5BIMBcoebwCxdj93ncDV1c/0gEh8wlA003bAtUDaAwt/bhHTNR5bpkzHTnb6BCmvs 7Y8KHbHfnZBqDgpwKWGbKZZLS/pz1F0uRW8jbelW6VEg3XVtpaawUdnM3HLu1MDw4tmj CQuBz0wRWEWsmhKmMcbqOraQAmDDaMor9TulguI6soDf0BQxMRHWnSGC/MCKDwyyxqWG g8Q9RYxdYGQ7N+Ep8j6pNq0Y7zt7LPuE00UgTczBnHJ9ZdLmTX3tl4DbZSjC6Pc3zGC6 V8lw== X-Gm-Message-State: ALoCoQmBBtyOCusyM9uGgmgNx4vhyIWa2dcQ0gSyflDs5qT3KkSBD7GDtuk/+U9JVdYZVZfLKe/q MIME-Version: 1.0 X-Received: by 10.112.132.67 with SMTP id os3mr14828966lbb.90.1424792194871; Tue, 24 Feb 2015 07:36:34 -0800 (PST) Received: by 10.25.205.144 with HTTP; Tue, 24 Feb 2015 07:36:34 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 10:36:34 -0500 Message-ID: From: Simon Perreault To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b3a8192a788c6050fd748fe Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 15:36:41 -0000 --047d7b3a8192a788c6050fd748fe Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 10:34 AM, Simon Perreault wrote: > On Tue, Feb 24, 2015 at 10:20 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >As I have stated on several occasions, I do not like the option of >> allowing multiple DTLS connections >> >over the same transport since it complicates implementations for no >> reason. Unless someone provides >> >a compelling use case why this is needed I strongly believe this should >> not be allowed. >> >> I don't have a use-case, but because of BUNDLE I'd like to have the same >> rules for SRTP and SCTP. >> >> >> >> >I agree that common rules for DTLS offer/answer would be beneficial for >> everybody. It is currently either undefined >or broken in a similar manner >> for both DTLS-SRTP and SCTP draft. New BFCP drafts actually reference >> DTLS-SRTP >as far as DTLS session setup is concerned, so they will suffer >> from the same problem. Furthermore, I do not think >anybody has any intent >> to implement DTLS changes without transport changes for any protocol. I >> think it would be >better to define this correctly at some point vs to keep >> repeating the same uncertainty. >> >> >> >> So, would anyone **object** to such restriction? I have seen no >> objections so far. >> > > Are you referring specifically to *simultaneous* DTLS connections over the > same transport? I wouldn't object to prohibiting those, but objecting would > be pointless anyway because it's just impossible to have multiple > simultaneous DTLS connections over the same transport. It's like saying > "packets MUST NOT travel faster than the speed of light." > > If you're instead referring to multiple *non-simultaneous* DTLS > connections over the same transport, then yes I would object. There's no > valid reason to prohibit those. > Oh, and by "transport" I'm assuming you mean "5-tuple". If that's not correct then... I object, your honour! ;) Simon --047d7b3a8192a788c6050fd748fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 24, 2015 at 10:34 AM, Simon Perreault <sperreault@jive.com> wrote:
On Tue, Feb 24, 2015 at = 10:20 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

>As I have = stated on several occasions, I do not like the option of allowing multiple = DTLS connections
>over the same transport since it complicates implementations for no rea= son. Unless someone provides
>a compelling use case why this is needed I strongly believe this should= not be allowed.

I don't have a use-case, but because of BUNDLE I'd like to have the= same rules for SRTP and SCTP.

=C2=A0

>I agree that common rules for DTLS offer/answer = would be beneficial for everybody. It is currently either undefined >or = broken in a similar manner for both DTLS-SRTP and SCTP draft. New BFCP draf= ts actually reference DTLS-SRTP >as far as DTLS session setup is concerned, so they will suffer from the same prob= lem. Furthermore, =C2=A0I do not think >anybody has any intent to implem= ent DTLS changes without transport changes for any protocol. I think it wou= ld be >better to define this correctly at some point vs to keep repeating the same uncertainty.

=C2=A0

So, would anyone *object* to such restrictio= n? I have seen no objections so far.

Are you referring specifically to *simultaneous* DTLS connections o= ver the same transport? I wouldn't object to prohibiting those, but obj= ecting would be pointless anyway because it's just impossible to have m= ultiple simultaneous DTLS connections over the same transport. It's lik= e saying "packets MUST NOT travel faster than the speed of light."= ;

If y= ou're instead referring to multiple *non-simultaneous* DTLS connections= over the same transport, then yes I would object. There's no valid rea= son to prohibit those.

Oh, and by "transpo= rt" I'm assuming you mean "5-tuple". If that's not c= orrect then... I object, your honour! ;)
Simon
--047d7b3a8192a788c6050fd748fe-- From nobody Tue Feb 24 07:44:48 2015 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 D80261A8746 for ; Tue, 24 Feb 2015 07:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npw_M3ZM4O7f for ; Tue, 24 Feb 2015 07:44:45 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6123F1A1AFF for ; Tue, 24 Feb 2015 07:44:45 -0800 (PST) Received: by iecar1 with SMTP id ar1so32978987iec.11 for ; Tue, 24 Feb 2015 07:44:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YlRvxnWuaxEeccMNns4a7l0nbYe9oKGB1kuj/hyUOhA=; b=nE0lFiwwzeCkS115OS2aZeJ8Yggq8okJw6NWzcJrphHdbFpz4BpCpzIrF6+vjBiLb3 oygK6BtgK2wJoO4ihovEbeFSkUpJfOQAxVFWNXxi/oUDbaMs4Ff9CfnnPZuYe6RT0O0z bVfcyPxTmn56zcQirDJqihidaZGtFaOrcJO0KsRvwHsTw3CbhCCKTlWiGiGkqAH44skE JUHG3XMpcswqqzCUTB8FXJ+JeJDWOYcw1K9kKI2BQt+870lwH/sTurXBJkfKxRq37gHO lb+bDT7uYeMjLNyRuG5Om+I5slzKyA3FBscs8Mk7KK8QGQGUKckrTGz/hP48Ozl55cl8 CHBw== X-Gm-Message-State: ALoCoQn0Sl6HkFZQAdhj7C1rZ7qPJXyRVkuKNc4Rc4uIhVe8K57hcj2wIPtDqTDuwgnto5VmnSer X-Received: by 10.107.47.216 with SMTP id v85mr21283277iov.86.1424792684639; Tue, 24 Feb 2015 07:44:44 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by mx.google.com with ESMTPSA id m5sm8142290ige.5.2015.02.24.07.44.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 07:44:43 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so27542544igd.4 for ; Tue, 24 Feb 2015 07:44:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.106.203 with SMTP id a11mr18203067icp.2.1424792682482; Tue, 24 Feb 2015 07:44:42 -0800 (PST) Received: by 10.36.20.10 with HTTP; Tue, 24 Feb 2015 07:44:42 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 10:44:42 -0500 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf304352c8b817ca050fd765a1 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 15:44:47 -0000 --20cf304352c8b817ca050fd765a1 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 10:36 AM, Simon Perreault wrote: > Are you referring specifically to *simultaneous* DTLS connections over the >> same transport? I wouldn't object to prohibiting those, but objecting would >> be pointless anyway because it's just impossible to have multiple >> simultaneous DTLS connections over the same transport. It's like saying >> "packets MUST NOT travel faster than the speed of light." >> >> If you're instead referring to multiple *non-simultaneous* DTLS >> connections over the same transport, then yes I would object. There's no >> valid reason to prohibit those. >> > > Oh, and by "transport" I'm assuming you mean "5-tuple". If that's not > correct then... I object, your honour! ;) > > So, do you want to allow setting up new DTLS session over the same underlying transport ("5-tuple" or ICE connection)? If you do, can explain how can you ensure that only one DTLS connection would be running over this transport at any given time during the offer/answer re-negotiation? For the description of the problems please see my original email that started this thread. By very nature of offer/answer multiple simultaneous DTLS sessions must be supported during the re-negotiation, and as you said yourself, those are not possible. Also, what is the use case for which you would need to setup new DTLS session when underlying transport stays the same? _____________ Roman Shpount --20cf304352c8b817ca050fd765a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 24, 2015 at 10:36 AM, Simon Perreault <sperreault@jive.com&g= t; wrote:
=
Are you referring specifically to *simultaneous*= DTLS connections over the same transport? I wouldn't object to prohibi= ting those, but objecting would be pointless anyway because it's just i= mpossible to have multiple simultaneous DTLS connections over the same tran= sport. It's like saying "packets MUST NOT travel faster than the s= peed of light."

If you're instead referring to multiple *non-simultane= ous* DTLS connections over the same transport, then yes I would object. The= re's no valid reason to prohibit those.

Oh, and by "transport" I'm assuming you mean "5= -tuple". If that's not correct then... I object, your honour! ;)

So, do you want= to allow setting up new DTLS session over the same underlying transport (&= quot;5-tuple" or ICE connection)? If you do, can explain how can you e= nsure that only one DTLS connection would be running over this transport at= any given time during the offer/answer re-negotiation? For the description= of the problems please see my original email that started this thread. By = very nature of offer/answer multiple simultaneous DTLS sessions must be sup= ported during the re-negotiation, and as you said yourself, those are not p= ossible.=C2=A0

Also, what is the use case for whic= h you would need to setup new DTLS session when underlying transport stays = the same?
_____________
Roman S= hpount
=C2=A0
--20cf304352c8b817ca050fd765a1-- From nobody Tue Feb 24 07:57:45 2015 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 D31861A0193 for ; Tue, 24 Feb 2015 07:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0rU_Matt3Sk for ; Tue, 24 Feb 2015 07:57:42 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330DE1A8828 for ; Tue, 24 Feb 2015 07:57:42 -0800 (PST) Received: by lbvp9 with SMTP id p9so25900814lbv.3 for ; Tue, 24 Feb 2015 07:57:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gMhgGhO+bjTSP5iruoHICdGxiu7oR8PJBoNQQG+n4SY=; b=ILRrUdx8/j4513u4yXN77oOSUkbCLW8zASFHtsq700RnpTp5ImnA/C1IjLWMY1uxhF VYEaXoJ3KvL02dqk4kngWwFC3pqHusAYt3glFlh9eFUlwTF881fuCiWfRwGIAXEsTrDx nZXMUOjCHKIthJ9LecEGu6jtMyzaWB7gu4uTNJe7aEOM91T/SrAlgmhPlqTRkCZy4rvS D5LTon0fPZZLPqvbKA10hEVbHmh3xkXNsSjlEW80+59fB9uOFi+lYEMLVtNh2moMJIbm R99Rfb0z7H7mfBLNxcnk6I9pwLMNDLa0KUb1bYLGBeIRlWA9LfQWz8ZCo14mriRTAFVx IgMQ== X-Gm-Message-State: ALoCoQl8IQg1L/LvzbTQWit1yyrNrqv0506c3GBBy6NL8N0s4jMpoeMkcHDvVI5GY9QslbNiwi5K MIME-Version: 1.0 X-Received: by 10.152.36.232 with SMTP id t8mr14901446laj.90.1424793460678; Tue, 24 Feb 2015 07:57:40 -0800 (PST) Received: by 10.25.205.144 with HTTP; Tue, 24 Feb 2015 07:57:40 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 10:57:40 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=089e0160a9d21a37cc050fd794e7 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 15:57:44 -0000 --089e0160a9d21a37cc050fd794e7 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 10:44 AM, Roman Shpount wrote: > > So, do you want to allow setting up new DTLS session over the same > underlying transport ("5-tuple" or ICE connection)? > I don't, but that's besides the point. The point is that when there's no reason to prohibit doing something, then we must not prohibit it. > If you do, can explain how can you ensure that only one DTLS connection > would be running over this transport at any given time during the > offer/answer re-negotiation? For the description of the problems please see > my original email that started this thread. By very nature of offer/answer > multiple simultaneous DTLS sessions must be supported during the > re-negotiation, and as you said yourself, those are not possible. > This is not specific to DTLS. All UDP-based protocols are affected by this. When you want to set-up a new session over the same transport, either you implement something like TCP's TIME_WAIT state, or you define a way to unambiguously differentiate sessions. Various protocols do it in various ways. For DTLS, packets from to the old session would be automatically rejected. This can be acceptable depending on the use case. Simon --089e0160a9d21a37cc050fd794e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 24, 2015 at 10:44 AM, Roman Shpount <roman@telurix.com>= wrote:
So, do you want to allow = setting up new DTLS session over the same underlying transport ("5-tup= le" or ICE connection)?

I don= 9;t, but that's besides the point. The point is that when there's n= o reason to prohibit doing something, then we must not prohibit it.
=C2=A0
If you do, can explain = how can you ensure that only one DTLS connection would be running over this= transport at any given time during the offer/answer re-negotiation? For th= e description of the problems please see my original email that started thi= s thread. By very nature of offer/answer multiple simultaneous DTLS session= s must be supported during the re-negotiation, and as you said yourself, th= ose are not possible.=C2=A0

This is n= ot specific to DTLS. All UDP-based protocols are affected by this. When you= want to set-up a new session over the same transport, either you implement= something like TCP's TIME_WAIT state, or you define a way to unambiguo= usly differentiate sessions. Various protocols do it in various ways. For D= TLS, packets from to the old session would be automatically rejected. This = can be acceptable depending on the use case.

Simon=
--089e0160a9d21a37cc050fd794e7-- From nobody Tue Feb 24 08:08:59 2015 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 21A8D1A1AE8 for ; Tue, 24 Feb 2015 08:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swz773rm5WtC for ; Tue, 24 Feb 2015 08:08:57 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4BD1A1A48 for ; Tue, 24 Feb 2015 08:08:57 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so27976272igb.2 for ; Tue, 24 Feb 2015 08:08:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vsqBE10NByrdTmIcxng4WFqmY6YhFD7P9OW8ytCl2q4=; b=drKy56hmX/tS37MupHy7d2fScidXQF6DiD4ENBJDVnnzSkMAGl2SXPtIfe3K+QbgB2 xW+x4AKeND2SotrhnaMmU4KfRt/ZEfGXAcdD7jAgmNI1SEKHP9OsxL2/3IP/OKVtRuW+ T8oe/RRq5WoM/kPaLux8WotOZaMcZZd3/l+QKIG6bXue4Ni2Bqc32tkGp97Kn7j2DKxG B8jW8LeXYpaeB3R4bHxTo52LJrAgvH9WqNvWIt1JrQqvk0vh/flF7OcBwc18hMqA5qjy 4CDfScUO7R+uFQC2pkxloYfg7n0PLKqDFSER8WREM9tjxT+T7XtVFicKs7gCC2A2FYys AJbw== X-Gm-Message-State: ALoCoQl6nPm+31IfL5q19O+EMaandYB9Zpl9QBR9yn2O3rIX4C/O6Pp+s9W4SkAZEgKmJC6BsamG X-Received: by 10.107.12.13 with SMTP id w13mr21596971ioi.28.1424794136870; Tue, 24 Feb 2015 08:08:56 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com. [209.85.223.171]) by mx.google.com with ESMTPSA id f12sm23465654ioi.21.2015.02.24.08.08.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 08:08:55 -0800 (PST) Received: by ierx19 with SMTP id x19so33206253ier.3 for ; Tue, 24 Feb 2015 08:08:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.74.201 with SMTP id yx9mr17800105icb.96.1424794134789; Tue, 24 Feb 2015 08:08:54 -0800 (PST) Received: by 10.36.20.10 with HTTP; Tue, 24 Feb 2015 08:08:54 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 11:08:54 -0500 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c396ce48546e050fd7bcf3 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 16:08:59 -0000 --001a11c396ce48546e050fd7bcf3 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 10:57 AM, Simon Perreault wrote: > > On Tue, Feb 24, 2015 at 10:44 AM, Roman Shpount wrote: >> >> So, do you want to allow setting up new DTLS session over the same >> underlying transport ("5-tuple" or ICE connection)? >> > > I don't, but that's besides the point. The point is that when there's no > reason to prohibit doing something, then we must not prohibit it. > At this point none of the webrtc implementations plan to support this. Why specify something that no one will support? > This is not specific to DTLS. All UDP-based protocols are affected by > this. When you want to set-up a new session over the same transport, either > you implement something like TCP's TIME_WAIT state, or you define a way to > unambiguously differentiate sessions. Various protocols do it in various > ways. For DTLS, packets from to the old session would be automatically > rejected. This can be acceptable depending on the use case. > > Can you please read the problem description from my original email and reply to it? I think you are missing the point that I am raising. This is not about late packets, even though late packets are also somewhat of an issue. This is about the fact that the new session would need to be negotiated at the same time as the old session is running. Furthermore, this can very often happen when an end point is not expecting it. _____________ Roman Shpount --001a11c396ce48546e050fd7bcf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 24, 2015 at 10:57 AM, Simon Perreault &l= t;sperreault@jive.= com> wrote:

On Tue, Feb 24, 2015 at 10:44 AM, Roman Shpount = <roman@telurix.com> wrote:
So, do you w= ant to allow setting up new DTLS session over the same underlying transport= ("5-tuple" or ICE connection)?

=
I don't, but that's besides the point. The point is tha= t when there's no reason to prohibit doing something, then we must not = prohibit it.

At thi= s point none of the webrtc implementations plan to support this. Why specif= y something that no one will support?
=C2=A0
This is not specific to DTLS. All UDP-based protocols a= re affected by this. When you want to set-up a new session over the same tr= ansport, either you implement something like TCP's TIME_WAIT state, or = you define a way to unambiguously differentiate sessions. Various protocols= do it in various ways. For DTLS, packets from to the old session would be = automatically rejected. This can be acceptable depending on the use case.



Can you please rea= d the problem description from my original email and reply to it? I think y= ou are missing the point that I am raising. This is not about late packets,= even though late packets are also somewhat of an issue. This is about the = fact that the new session would need to be negotiated at the same time as t= he old session is running. Furthermore, this can very often happen when an = end point is not expecting it.

__________= ___
Roman Shpount

--001a11c396ce48546e050fd7bcf3-- From nobody Tue Feb 24 08:17:29 2015 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 445D71A8786 for ; Tue, 24 Feb 2015 08:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO1oH-NpHN3M for ; Tue, 24 Feb 2015 08:17:23 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734F91A1A25 for ; Tue, 24 Feb 2015 08:17:23 -0800 (PST) Received: by labgq15 with SMTP id gq15so26943619lab.3 for ; Tue, 24 Feb 2015 08:17:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gQGC5vI9KlSczOuB12LljvhudXCppEFLCEo+1rAEsa8=; b=eBhI6Rw5guaFC5tG/rAF5DkY0aDlKlN7/hAzwccyaLQdR0wdA+bTp+v+dSA80i5u1e MB8u5MZ3I2PHzvreA/TUmcFiKgUaB7FlXfXgcO0WMeDvifEuMXol4IwsaD44+lScpKLa /RWioXiuaRD1iRd0snj6iggVZnka9TfllKrKSLFc2pqpsWDuTc9FBEF6aMBUtkgtlFCk kuXa32WcWKPAKtdtPAsF+ZgrFpl+2JiQMdbo9dl+Nt91jfKdgtR089iHYg74DbZ6RHsH scc/mdH/xoJa5sRBIcNuIDBDvbjEB66gDPzWyXypbMU2ICM3U+MEGcZKLVPuq+BxlLDr nZWA== X-Gm-Message-State: ALoCoQn114twsmhl9JS6mDEYhJyl3QyMLCoWwsyB8RAUGhgG3TGrzRpLPylvudCWaXdIF5uYwYfk MIME-Version: 1.0 X-Received: by 10.112.223.7 with SMTP id qq7mr15044055lbc.81.1424794641937; Tue, 24 Feb 2015 08:17:21 -0800 (PST) Received: by 10.25.205.144 with HTTP; Tue, 24 Feb 2015 08:17:21 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 11:17:21 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=001a113464ac82d117050fd7dad9 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 16:17:25 -0000 --001a113464ac82d117050fd7dad9 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 11:08 AM, Roman Shpount wrote: > On Tue, Feb 24, 2015 at 10:57 AM, Simon Perreault > wrote: > >> >> On Tue, Feb 24, 2015 at 10:44 AM, Roman Shpount >> wrote: >>> >>> So, do you want to allow setting up new DTLS session over the same >>> underlying transport ("5-tuple" or ICE connection)? >>> >> >> I don't, but that's besides the point. The point is that when there's no >> reason to prohibit doing something, then we must not prohibit it. >> > > At this point none of the webrtc implementations plan to support this. Why > specify something that no one will support? > That's exactly what I'm saying! Let's not "specify" it. Let's just say nothing at all about this topic. This is not specific to DTLS. All UDP-based protocols are affected by this. >> When you want to set-up a new session over the same transport, either you >> implement something like TCP's TIME_WAIT state, or you define a way to >> unambiguously differentiate sessions. Various protocols do it in various >> ways. For DTLS, packets from to the old session would be automatically >> rejected. This can be acceptable depending on the use case. >> > > Can you please read the problem description from my original email and > reply to it? I think you are missing the point that I am raising. This is > not about late packets, even though late packets are also somewhat of an > issue. This is about the fact that the new session would need to be > negotiated at the same time as the old session is running. Furthermore, > this can very often happen when an end point is not expecting it. > Look, I think we're agreeing on maybe 95% of the things. I think what we need at this point is a verbatim text proposal. Then we can wordsmith it as we like. Simon --001a113464ac82d117050fd7dad9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 24, 2015 at 11:08 AM, Roman Shpount <roman@telurix.com>= wrote:
On Tue, Feb 24, 2015 at 10:57 AM, Simon Perreau= lt <sperreault@jive.com> wrote:
<= div class=3D"gmail_extra">
On Tue, Feb = 24, 2015 at 10:44 AM, Roman Shpount <roman@telurix.com> wrot= e:
So, do you want to allow setting up new DTLS sessio= n over the same underlying transport ("5-tuple" or ICE connection= )?

I don't, but that's= besides the point. The point is that when there's no reason to prohibi= t doing something, then we must not prohibit it.

At this point none of the webrtc imple= mentations plan to support this. Why specify something that no one will sup= port?

That's exactly = what I'm saying! Let's not "specify" it. Let's just s= ay nothing at all about this topic.

This is not specific to DTLS. All UDP-bas= ed protocols are affected by this. When you want to set-up a new session ov= er the same transport, either you implement something like TCP's TIME_W= AIT state, or you define a way to unambiguously differentiate sessions. Var= ious protocols do it in various ways. For DTLS, packets from to the old ses= sion would be automatically rejected. This can be acceptable depending on t= he use case.
=

Can you ple= ase read the problem description from my original email and reply to it? I = think you are missing the point that I am raising. This is not about late p= ackets, even though late packets are also somewhat of an issue. This is abo= ut the fact that the new session would need to be negotiated at the same ti= me as the old session is running. Furthermore, this can very often happen w= hen an end point is not expecting it.

Look, I t= hink we're agreeing on maybe 95% of the things. I think what we need at= this point is a verbatim text proposal. Then we can wordsmith it as we lik= e.

Sim= on
--001a113464ac82d117050fd7dad9-- From nobody Tue Feb 24 08:22:19 2015 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 ADD941A877B for ; Tue, 24 Feb 2015 08:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpqGNsOzQU-4 for ; Tue, 24 Feb 2015 08:22:16 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7665A1A1B3F for ; Tue, 24 Feb 2015 08:22:16 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so29636137igb.0 for ; Tue, 24 Feb 2015 08:22:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jB1a9NWsc63WC1BvCw86MlzhEZHW0ykwUAWrO4Zonjs=; b=XWa+3v0KJCdG7s0DTCl6Ih9f1SBzVZ0vfrAbEpqjslruYNF1SScIhTE990tpLP5vZW rQyLfoY54p3DQh37dZVo0rryzjkBnwiQDTnYMt/LMbZr80zM9W9UY26Lnr0+hdwiHwr4 YeJiT/ayt5Q/DhcbaqsY4Iqd0uRaxyGNCbiRNFsaGSNKrPIqJA4w4FemDJJjNOmubkPx OjRIiKqrWNm3sE61nB1VyY9yVqFtgH8coyce0sFLkFieqSIYp3OM3w+kmvBkykwfRZoD XQ7r+UpyoaA1O/PodGJlV8DHGm44ms9I38zZ5X6npTM9DM+f292P+wTpliv6zn2OoroB HbNA== X-Gm-Message-State: ALoCoQk7/71kcxYNAi/kvzgVK3PrTyO5yXxEYvvg8Eu/lK6E/BIOUI4wIDVRbUidOQxpnF6wvDDQ X-Received: by 10.107.129.138 with SMTP id l10mr22313847ioi.37.1424794935725; Tue, 24 Feb 2015 08:22:15 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by mx.google.com with ESMTPSA id n31sm24134517ioe.18.2015.02.24.08.22.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 08:22:15 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so29635742igb.0 for ; Tue, 24 Feb 2015 08:22:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.1.67 with SMTP id np3mr15416738icb.24.1424794933154; Tue, 24 Feb 2015 08:22:13 -0800 (PST) Received: by 10.36.20.10 with HTTP; Tue, 24 Feb 2015 08:22:13 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 11:22:13 -0500 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=bcaec50e5f1dde7e26050fd7eb9c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 16:22:17 -0000 --bcaec50e5f1dde7e26050fd7eb9c Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 11:17 AM, Simon Perreault wrote: > > Look, I think we're agreeing on maybe 95% of the things. I think what we > need at this point is a verbatim text proposal. Then we can wordsmith it as > we like. > > My text proposal is: "DTLS fingerprint and setup role MUST NOT change unless underlying transport did not change as well." You have just said that you disagree with this. _____________ Roman Shpount --bcaec50e5f1dde7e26050fd7eb9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 24, 2015 at 11:17 AM, Simon Perreault <sperreault@jive.com&g= t; wrote:

Look, I think we're agreeing on ma= ybe 95% of the things. I think what we need at this point is a verbatim tex= t proposal. Then we can wordsmith it as we like.

<= /span>

My text proposal is: "DTL= S fingerprint and setup role MUST NOT change unless underlying transport di= d not change as well." You have just said that you disagree with this.=
_____________
Roman Shpount
=C2=A0
--bcaec50e5f1dde7e26050fd7eb9c-- From nobody Tue Feb 24 08:36:49 2015 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 3B35D1A8799 for ; Tue, 24 Feb 2015 08:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5ixCN2bBgnp for ; Tue, 24 Feb 2015 08:36:48 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01721A8792 for ; Tue, 24 Feb 2015 08:36:47 -0800 (PST) Received: by labhv19 with SMTP id hv19so4269871lab.10 for ; Tue, 24 Feb 2015 08:36:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pdqENvYTKfutIJc2CjP74oz81kthhcfreQaQecl8jfM=; b=Co+Ek52JDNP6/dYdwKUrbcnztt0KDeXpp9/3UeMsfkWyn75lGrSuDE5+8NfRUD1J6u sUGe31rSdUBDfbcaSLfk1qX/BaBTBPjd7G+WbN9IO+JlMitfXbc3XfsB1ilNq3zzXLt+ /lUcl6s6t+0Kga+TbzfEPGPymTLQA+hqA+eNk73Gd49uWjtE7S2TmiZUibqmfRXy6swR oNOdg4sgDFEe3O/xV4NPR2CFgx+JI3i+a/ovcjAcGCazZtR6jPo11H76SFJG/QfPM6Pk TEy1UXipw88c6jq4176RqoP1+nQNfuS+LXjda1WpJAoAXjVaWRXrfOYdHL9D3JL5BZ3L bu4Q== X-Gm-Message-State: ALoCoQn9dFkC+KQHrSAtXjs47vPl63muqto5HfJp8Wds6hjbjm65C57L7sgp1xwaJI3+NTrlfQAz MIME-Version: 1.0 X-Received: by 10.152.43.101 with SMTP id v5mr15029632lal.83.1424795806175; Tue, 24 Feb 2015 08:36:46 -0800 (PST) Received: by 10.25.205.144 with HTTP; Tue, 24 Feb 2015 08:36:46 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 11:36:46 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c36450e7ab1c050fd81fc7 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 16:36:49 -0000 --001a11c36450e7ab1c050fd81fc7 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 11:22 AM, Roman Shpount wrote: > My text proposal is: "DTLS fingerprint and setup role MUST NOT change > unless underlying transport did not change as well." You have just said > that you disagree with this. I don't disagree, as I said I think I agree with about 95% of it. One negation needs to be reversed: "DTLS fingerprint and setup role MUST NOT change unless underlying transport did change as well." In what draft would this go? Which section? I'm sorry but after re-reading the whole thread I still can't find this. Simon --001a11c36450e7ab1c050fd81fc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 24, 2015 at 11:22 AM, Roman Shpount <roman@telurix.com>= wrote:
My text proposal is: "DTLS fingerpr= int and setup role MUST NOT change unless underlying transport did not chan= ge as well." You have just said that you disagree with this.

I = don't disagree, as I said I think I agree with about 95% of it.

One negation needs to be reversed: "= ;DTLS fingerprint and setup role MUST NOT change unless underlying transpor= t did change as well."

In what draft would this go? Which section? I'm s= orry but after re-reading the whole thread I still can't find this.

Simon
--001a11c36450e7ab1c050fd81fc7-- From nobody Tue Feb 24 08:55:13 2015 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 169541A1B5E for ; Tue, 24 Feb 2015 08:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njl2SWvf6A3V for ; Tue, 24 Feb 2015 08:55:10 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2281A1B71 for ; Tue, 24 Feb 2015 08:55:10 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id l13so29837292iga.1 for ; Tue, 24 Feb 2015 08:55:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J5y9BOsvbQMKzOSKih8R38gh1pAAJ3iKhSrx6o4+uk8=; b=JZwF6iBYfVUcN6DNefhS/EablckRf1EuHuAGGF5d1ldCskjitRTo6ieWlF0TI5+Xev MzzGWquJkjK0xR5L2jSMpMnSTmAco/pv4u4oE6dy7+SiC/BjAnfzhUk3PkGnL7cxGBd6 uplWTY2o0/xdEbgkS0/dpL+ErxtFwcTR/JUEl1qe/Rf05qnSEsKP1qGpsqYOkisns1W/ TwIMq8JLcTPwHSZcJ9VgSnW/xtw6YlbMpP47ptbDqIDCnBMuepoCrF9homijiLIh0+89 1pTzhI+2S/Hez1t63oO6ro1pHVGXVp1DjRb9ieCRstGJFpHuYOxhaLpDgOqWv05X6MQJ Vpgw== X-Gm-Message-State: ALoCoQnASL18K/2jVO4Z/8DPES1s9v8YCwGksFBLNjLKr/8gtwhn90/WFzxLg8G+htTQd1n2A5je X-Received: by 10.50.25.225 with SMTP id f1mr20992014igg.29.1424796909295; Tue, 24 Feb 2015 08:55:09 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by mx.google.com with ESMTPSA id j39sm16492024iod.28.2015.02.24.08.55.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 08:55:08 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so28213944igb.3 for ; Tue, 24 Feb 2015 08:55:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.79.230 with SMTP id m6mr20952144igx.33.1424796906220; Tue, 24 Feb 2015 08:55:06 -0800 (PST) Received: by 10.36.20.10 with HTTP; Tue, 24 Feb 2015 08:55:06 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> Date: Tue, 24 Feb 2015 11:55:06 -0500 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=089e01229aaa7917f3050fd86172 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 16:55:12 -0000 --089e01229aaa7917f3050fd86172 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 11:36 AM, Simon Perreault wrote: > > On Tue, Feb 24, 2015 at 11:22 AM, Roman Shpount wrote: > >> My text proposal is: "DTLS fingerprint and setup role MUST NOT change >> unless underlying transport did not change as well." You have just said >> that you disagree with this. > > > I don't disagree, as I said I think I agree with about 95% of it. > > One negation needs to be reversed: "DTLS fingerprint and setup role MUST > NOT change unless underlying transport did change as well." > This is not I do not write drafts -- I can be dyslexic at times. In what draft would this go? Which section? I'm sorry but after re-reading > the whole thread I still can't find this. > > I think this particular discussion started because of draft-ietf-mmusic-sctp-sdp. The best alternative would be to have a separate new draft in MMUSIC which will define common offer/answer rules for DTLS. This draft can update RFC 5763 and it can be referenced by draft-ietf-mmusic-sctp-sdp and RFC 4583 bis. Another alternative would be to update DTLS-SRTP (update RFC 5763) and include this language in draft-ietf-mmusic-sctp-sdp. _____________ Roman Shpount --089e01229aaa7917f3050fd86172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 24, 2015 at 11:36 AM, Simon Perreault <sperreault@jive.com&g= t; wrote:

On Tue, Feb 24, 2015 = at 11:22 AM, Roman Shpount <roman@telurix.com> wrote:
My text proposal is: "DTLS fingerprint and setup role MU= ST NOT change unless underlying transport did not change as well." You= have just said that you disagree with this.

I don't di= sagree, as I said I think I agree with about 95% of it.

One negation needs to be reversed: "DTLS finger= print and setup role MUST NOT change unless underlying transport did change= as well."

This is not I d= o not write drafts -- I can be dyslexic at times.

In what draft would= this go? Which section? I'm sorry but after re-reading the whole threa= d I still can't find this.


I think this particular discussion started because of draft= -ietf-mmusic-sctp-sdp. The best alternative would be to have a separate new= draft in MMUSIC which will define common offer/answer rules for DTLS. This= draft can update RFC 5763 and it can be referenced by draft-ietf-mmusic-sc= tp-sdp and=C2=A0RFC 4583 bis. Another alternative would be=C2=A0to update DTLS-SR= TP (update RFC 5763) and include this language in draft-ietf-mmusic-sctp-sd= p.
____= _________
Roman Shpount
=C2=A0
--089e01229aaa7917f3050fd86172-- From nobody Tue Feb 24 09:36:13 2015 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 C69521A875C for ; Tue, 24 Feb 2015 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2QzNXzVflnB for ; Tue, 24 Feb 2015 09:36:10 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4241A00D0 for ; Tue, 24 Feb 2015 09:36:08 -0800 (PST) X-AuditID: c1b4fb30-f79626d000003cf6-a4-54ecb686aebb Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AD.EE.15606.686BCE45; Tue, 24 Feb 2015 18:36:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 24 Feb 2015 18:36:06 +0100 From: Christer Holmberg To: Roman Shpount , Simon Perreault Thread-Topic: [rtcweb] Offer/Answer and DTLS Thread-Index: AQHQTscg+zO/WiBUDE6I3wOpBInhbZz875qAgAADh4CAALjJ8IAAvXsAgABG7mCAACB/AIABGmHw///1TgCAAACDAIAAAkYAgAADnwCAAAMkAIAAAlyAgAABXICAAAQRAIAABR8AgAAbaUA= Date: Tue, 24 Feb 2015 17:36:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7172A0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7112D0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D7172A0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rrdt25sQg/OtZhYzLkxltlj7r53d 4vqVUAdmjyVLfjJ5/JvzlNnj1pSCAOYoLpuU1JzMstQifbsEroyJa3rZCi4lVty+mdrA+Ceu i5GTQ0LAROJ7x0lWCFtM4sK99WxdjFwcQgJHGCVmdh2FcpYwSmzvOsTSxcjBwSZgIdH9Txuk QUTAR+LU0inMIDazgLrEncXn2EFsYQFtie4lPYwQNToSbT+ns0HY8xglHv/IB7FZBFQljh89 AhbnFfCV2LewhxVi13ZOieNnZjKBJDgFAiWWPFwJNogR6Lrvp9YwQSwTl7j1ZD4TxNUCEkv2 nGeGsEUlXj7+B/WNkkTjkiesEPX5Ev+e/maHWCYocXLmE5YJjKKzkIyahaRsFpKyWUAvMwto SqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIHR d3DLb4MdjC+fOx5iFOBgVOLhLVB8EyLEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBsZNInlLRcPfH2lhutwnIWwUcjR526HDcf01//U95QpO9MZzb+2v/MWQ eO3VOqc5foby/rmTN+Yu55Nc85O7vdhDNFMj/GOY/oQG53U+19zXbp6i6cBzz9Az7sxCh+pV yhaz7rfuPT/11871zJNi+8K+FIZ3HX9e9HgV3/7nG2Y1zEyacefOnBlKLMUZiYZazEXFiQCP DADrnwIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 17:36:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D7172A0ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBhY3R1YWwgZG9jdW1lbnRhdGlvbiB3b3VsZCBiZSBkaXNjdXNzZWQgaW4gTU1V U0lDLCBhbmQgb2J2aW91c2x5IHRoZXkgbWF5IGhhdmUgb3BpbmlvbnMgb24gdGhlIHN1Z2dlc3Rl ZCByZXN0cmljdGlvbiB0b28uIEtlZXAgaW4gbWluZCB0aGF0IHRoaXMgaXMgbm90IGFuIFJUQ1dF QiBzcGVjaWZpYyBpc3N1ZS4NCg0KQnV0LCBhZ2FpbiwgYmVmb3JlIEkgbW92ZSB0aGUgZGlzY3Vz c2lvbiB0byBNTVVTSUMgSeKAmWQgbGlrZSB0byB2ZXJpZnkgd2hldGhlciB3ZSwgZnJvbSBhbiBS VENXRUIgcGVyc3BlY3RpdmUsIGFyZSBvayB3aXRoIHRoZSBzdWdnZXN0aW9uLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJp eC5jb21dDQpTZW50OiAyNCBGZWJydWFyeSAyMDE1IDE4OjU1DQpUbzogU2ltb24gUGVycmVhdWx0 DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmc7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFty dGN3ZWJdIE9mZmVyL0Fuc3dlciBhbmQgRFRMUw0KDQpPbiBUdWUsIEZlYiAyNCwgMjAxNSBhdCAx MTozNiBBTSwgU2ltb24gUGVycmVhdWx0IDxzcGVycmVhdWx0QGppdmUuY29tPG1haWx0bzpzcGVy cmVhdWx0QGppdmUuY29tPj4gd3JvdGU6DQoNCk9uIFR1ZSwgRmViIDI0LCAyMDE1IGF0IDExOjIy IEFNLCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJp eC5jb20+PiB3cm90ZToNCk15IHRleHQgcHJvcG9zYWwgaXM6ICJEVExTIGZpbmdlcnByaW50IGFu ZCBzZXR1cCByb2xlIE1VU1QgTk9UIGNoYW5nZSB1bmxlc3MgdW5kZXJseWluZyB0cmFuc3BvcnQg ZGlkIG5vdCBjaGFuZ2UgYXMgd2VsbC4iIFlvdSBoYXZlIGp1c3Qgc2FpZCB0aGF0IHlvdSBkaXNh Z3JlZSB3aXRoIHRoaXMuDQoNCkkgZG9uJ3QgZGlzYWdyZWUsIGFzIEkgc2FpZCBJIHRoaW5rIEkg YWdyZWUgd2l0aCBhYm91dCA5NSUgb2YgaXQuDQoNCk9uZSBuZWdhdGlvbiBuZWVkcyB0byBiZSBy ZXZlcnNlZDogIkRUTFMgZmluZ2VycHJpbnQgYW5kIHNldHVwIHJvbGUgTVVTVCBOT1QgY2hhbmdl IHVubGVzcyB1bmRlcmx5aW5nIHRyYW5zcG9ydCBkaWQgY2hhbmdlIGFzIHdlbGwuIg0KDQpUaGlz IGlzIG5vdCBJIGRvIG5vdCB3cml0ZSBkcmFmdHMgLS0gSSBjYW4gYmUgZHlzbGV4aWMgYXQgdGlt ZXMuDQoNCkluIHdoYXQgZHJhZnQgd291bGQgdGhpcyBnbz8gV2hpY2ggc2VjdGlvbj8gSSdtIHNv cnJ5IGJ1dCBhZnRlciByZS1yZWFkaW5nIHRoZSB3aG9sZSB0aHJlYWQgSSBzdGlsbCBjYW4ndCBm aW5kIHRoaXMuDQoNCg0KSSB0aGluayB0aGlzIHBhcnRpY3VsYXIgZGlzY3Vzc2lvbiBzdGFydGVk IGJlY2F1c2Ugb2YgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAuIFRoZSBiZXN0IGFsdGVybmF0 aXZlIHdvdWxkIGJlIHRvIGhhdmUgYSBzZXBhcmF0ZSBuZXcgZHJhZnQgaW4gTU1VU0lDIHdoaWNo IHdpbGwgZGVmaW5lIGNvbW1vbiBvZmZlci9hbnN3ZXIgcnVsZXMgZm9yIERUTFMuIFRoaXMgZHJh ZnQgY2FuIHVwZGF0ZSBSRkMgNTc2MyBhbmQgaXQgY2FuIGJlIHJlZmVyZW5jZWQgYnkgZHJhZnQt aWV0Zi1tbXVzaWMtc2N0cC1zZHAgYW5kIFJGQyA0NTgzIGJpcy4gQW5vdGhlciBhbHRlcm5hdGl2 ZSB3b3VsZCBiZSB0byB1cGRhdGUgRFRMUy1TUlRQICh1cGRhdGUgUkZDIDU3NjMpIGFuZCBpbmNs dWRlIHRoaXMgbGFuZ3VhZ2UgaW4gZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAuDQpfX19fX19f X19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D7172A0ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5UaGUgYWN0dWFsIGRvY3VtZW50YXRpb24gd291bGQgYmUgZGlzY3Vz c2VkIGluIE1NVVNJQywgYW5kIG9idmlvdXNseSB0aGV5IG1heSBoYXZlIG9waW5pb25zIG9uIHRo ZSBzdWdnZXN0ZWQgcmVzdHJpY3Rpb24gdG9vLiBLZWVwDQogaW4gbWluZCB0aGF0IHRoaXMgaXMg bm90IGFuIFJUQ1dFQiBzcGVjaWZpYyBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkJ1dCwgYWdhaW4sIGJlZm9yZSBJIG1vdmUgdGhlIGRpc2N1c3Npb24gdG8g TU1VU0lDIEnigJlkIGxpa2UgdG8gdmVyaWZ5IHdoZXRoZXIgd2UsIGZyb20gYW4gUlRDV0VCIHBl cnNwZWN0aXZlLCBhcmUgb2sgd2l0aCB0aGUgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiAyNCBGZWJydWFyeSAyMDE1IDE4OjU1PGJyPg0KPGI+VG86PC9iPiBTaW1vbiBQZXJyZWF1 bHQ8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBydGN3ZWJAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIE9mZmVyL0Fuc3dlciBhbmQgRFRMUzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBG ZWIgMjQsIDIwMTUgYXQgMTE6MzYgQU0sIFNpbW9uIFBlcnJlYXVsdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwZXJyZWF1bHRAaml2ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zcGVycmVhdWx0QGppdmUu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAyNCwgMjAxNSBhdCAxMToyMiBBTSwgUm9t YW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9 Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB0ZXh0IHByb3Bvc2FsIGlzOiAm cXVvdDtEVExTIGZpbmdlcnByaW50IGFuZCBzZXR1cCByb2xlIE1VU1QgTk9UIGNoYW5nZSB1bmxl c3MgdW5kZXJseWluZyB0cmFuc3BvcnQgZGlkIG5vdCBjaGFuZ2UgYXMgd2VsbC4mcXVvdDsgWW91 IGhhdmUganVzdCBzYWlkIHRoYXQgeW91IGRpc2FncmVlIHdpdGggdGhpcy48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBkb24ndCBkaXNhZ3JlZSwgYXMgSSBzYWlkIEkgdGhpbmsgSSBhZ3JlZSB3aXRoIGFib3V0IDk1 JSBvZiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P bmUgbmVnYXRpb24gbmVlZHMgdG8gYmUgcmV2ZXJzZWQ6ICZxdW90O0RUTFMgZmluZ2VycHJpbnQg YW5kIHNldHVwIHJvbGUgTVVTVCBOT1QgY2hhbmdlIHVubGVzcyB1bmRlcmx5aW5nIHRyYW5zcG9y dCBkaWQgY2hhbmdlIGFzIHdlbGwuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBu b3QgSSBkbyBub3Qgd3JpdGUgZHJhZnRzIC0tIEkgY2FuIGJlIGR5c2xleGljIGF0IHRpbWVzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIHdoYXQgZHJhZnQgd291bGQgdGhpcyBnbz8gV2hpY2ggc2VjdGlv bj8gSSdtIHNvcnJ5IGJ1dCBhZnRlciByZS1yZWFkaW5nIHRoZSB3aG9sZSB0aHJlYWQgSSBzdGls bCBjYW4ndCBmaW5kIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB0aGluayB0aGlzIHBhcnRpY3VsYXIgZGlzY3Vzc2lvbiBzdGFydGVkIGJl Y2F1c2Ugb2YgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAuIFRoZSBiZXN0IGFsdGVybmF0aXZl IHdvdWxkIGJlIHRvIGhhdmUgYSBzZXBhcmF0ZSBuZXcgZHJhZnQgaW4gTU1VU0lDIHdoaWNoIHdp bGwgZGVmaW5lIGNvbW1vbiBvZmZlci9hbnN3ZXIgcnVsZXMgZm9yIERUTFMuIFRoaXMgZHJhZnQg Y2FuIHVwZGF0ZSBSRkMgNTc2Mw0KIGFuZCBpdCBjYW4gYmUgcmVmZXJlbmNlZCBieSBkcmFmdC1p ZXRmLW1tdXNpYy1zY3RwLXNkcCBhbmQmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2NvbG9yOmJsYWNrIj5SRkMgNDU4MyBiaXMuIEFub3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUm bmJzcDs8L3NwYW4+dG8gdXBkYXRlIERUTFMtU1JUUCAodXBkYXRlIFJGQyA1NzYzKSBhbmQgaW5j bHVkZSB0aGlzIGxhbmd1YWdlIGluIGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D7172A0ESESSMB209erics_-- From nobody Tue Feb 24 09:49:08 2015 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 D8C571A1B23 for ; Tue, 24 Feb 2015 09:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCHn77rWg4Nc for ; Tue, 24 Feb 2015 09:49:03 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63E1A1B59 for ; Tue, 24 Feb 2015 09:49:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1472D7C43AF for ; Tue, 24 Feb 2015 18:49:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz1LlSaDmQ19 for ; Tue, 24 Feb 2015 18:48:59 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:51f6:d297:73ab:810] (unknown [IPv6:2001:470:de0a:27:51f6:d297:73ab:810]) by mork.alvestrand.no (Postfix) with ESMTPSA id CE0937C43AB for ; Tue, 24 Feb 2015 18:48:58 +0100 (CET) Message-ID: <54ECB98A.9080007@alvestrand.no> Date: Tue, 24 Feb 2015 18:48:58 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D71659B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D717168@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7172A0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7172A0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Offer/Answer and DTLS 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 Feb 2015 17:49:06 -0000 Den 24. feb. 2015 18:36, skrev Christer Holmberg: > Hi, > > > > The actual documentation would be discussed in MMUSIC, and obviously > they may have opinions on the suggested restriction too. Keep in mind > that this is not an RTCWEB specific issue. > > > > But, again, before I move the discussion to MMUSIC Id like to verify > whether we, from an RTCWEB perspective, are ok with the suggestion. Speaking as an RTCWEB participant, I'm happy with this resolution. It says that I can't do something I don't want to do, and don't have to write code for someone else doing it either. > > > > Regards, > > > > Christer > > > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 24 February 2015 18:55 > *To:* Simon Perreault > *Cc:* Christer Holmberg; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Offer/Answer and DTLS > > > > On Tue, Feb 24, 2015 at 11:36 AM, Simon Perreault > wrote: > > > > On Tue, Feb 24, 2015 at 11:22 AM, Roman Shpount > wrote: > > My text proposal is: "DTLS fingerprint and setup role MUST NOT > change unless underlying transport did not change as well." You > have just said that you disagree with this. > > > > I don't disagree, as I said I think I agree with about 95% of it. > > > > One negation needs to be reversed: "DTLS fingerprint and setup role > MUST NOT change unless underlying transport did change as well." > > > > This is not I do not write drafts -- I can be dyslexic at times. > > > > In what draft would this go? Which section? I'm sorry but after > re-reading the whole thread I still can't find this. > > > > > > I think this particular discussion started because of > draft-ietf-mmusic-sctp-sdp. The best alternative would be to have a > separate new draft in MMUSIC which will define common offer/answer rules > for DTLS. This draft can update RFC 5763 and it can be referenced by > draft-ietf-mmusic-sctp-sdp and RFC 4583 bis. Another alternative would > be to update DTLS-SRTP (update RFC 5763) and include this language in > draft-ietf-mmusic-sctp-sdp. > > _____________ > Roman Shpount > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Feb 24 10:40:27 2015 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 B7E571A8775 for ; Tue, 24 Feb 2015 10:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 S1QTZ6fz_lwL for ; Tue, 24 Feb 2015 10:40:25 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8F81A1BF8 for ; Tue, 24 Feb 2015 10:40:24 -0800 (PST) Received: by wesw62 with SMTP id w62so26972649wes.12 for ; Tue, 24 Feb 2015 10:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=aDUEdV6XRSOZtJj7CZ1xcGliJASfPWAyIrsRmwRmbgw=; b=NsDnDdpSEVzT6P4UgJJTtHopbzB/UZ/o8ObOZyW5eXQsdS8frYh1izqnEOEkRgZMzI a3KnGXl9vehXhHBnY8DlRoy1afovXcIDs1PJLvXR3hCAN7bhydn3GtyQjggNLgO2A1f8 sYmHGufhX73J4tY+Uf7PstmneJiZPg/RQYiSxpl+SAYpfLNQF83mG+2z9b9E1en09TxJ 6RJqYDWL2RX0th0iFK+xVJHH8gwlj4LddtNQxyKMMmRNswCi3favb+2Y4cX+2oTxXJcV ZSMcC+ahXtYX5nsooGU9Iz5cl2dC3FpxqDR63ybFJ3Nk8ydV9N/Bepn91jtb9zse4Lii fmRw== X-Received: by 10.194.236.200 with SMTP id uw8mr34389875wjc.10.1424803223339; Tue, 24 Feb 2015 10:40:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.129.196 with HTTP; Tue, 24 Feb 2015 10:40:02 -0800 (PST) From: Bernard Aboba Date: Tue, 24 Feb 2015 10:40:02 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01493f60008be7050fd9da63 Archived-At: Subject: [rtcweb] JSEP: Question relating to ICE candidate pool 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 Feb 2015 18:40:26 -0000 --089e01493f60008be7050fd9da63 Content-Type: text/plain; charset=UTF-8 A question has arisen with respect to draft-ietf-rtcweb-jsep-08 Sections 3.4.4 and 4.1.2. Exerpts from these sections are enclosed below. While Section 3.4.4 refers to "pre-gathering" of ICE candidates prior to calling of setLocalDescription(), Section 4.1.2 states that createOffer() does not result in candidate gathering. One way to interpret this is that while createOffer() does not result in firing of the onicecandidate callback (which needs to wait until setLocalDescription() is called), it is ok (or even encouraged) for the implementation to begin "pre-gathering" ICE candidates into the ICE candidate pool once createOffer() is called. Is this a reasonable interpretation or is there another way this could/should be read? Section 4.1.2 createOffer: Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause media to start or stop flowing. Section 3.4.4 ICE candidate pool: 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, and thereby ICE components, for which to gather candidates. However, to accelerate cases where the application knows the number of ICE components to use ahead of time, it may ask the browser to gather a pool of potential ICE candidates to help ensure rapid media setup. When setLocalDescription is eventually called, and the browser goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the application immediately via the ICE candidate callback. If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual. One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to minimize the time it takes to establish connectivity, to avoid clipping of initial media. By pre-gathering candidates into the pool, it can exchange and start sending connectivity checks from these candidates almost immediately upon receipt of a call. Note though that by holding on to these pre-gathered candidates, which will be kept alive as long as they may be needed, the application will consume resources on the STUN/TURN servers it is using. --089e01493f60008be7050fd9da63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A question has arisen with respect to draft-ietf-rtcweb-js= ep-08 Sections 3.4.4 and 4.1.2.=C2=A0 Exerpts from these sections are enclo= sed below.=C2=A0

While Section 3.4.4 refers to "pre= -gathering" of ICE candidates prior to calling of setLocalDescription(= ), Section 4.1.2 states that createOffer() does not result in candidate gat= hering.=C2=A0

One way to interpret this is that wh= ile createOffer() does not result in firing of the onicecandidate callback = (which needs to wait until setLocalDescription() is called), it is ok (or e= ven encouraged) for the implementation to begin "pre-gathering" I= CE candidates into the ICE candidate pool once createOffer() is called.=C2= =A0

Is this a reasonable interpretation or is ther= e another way this could/should be read? =C2=A0


=
Section 4.1.2 createOffer:=C2=A0

   Calling this method may do things such as generate new ICE
   credentials, but does not result in candidate gathering, or cause
   media to start or stop flowing.

Section 3.4.4 ICE candidate pool:=C2=A0

   JSEP applications typically inform the browser to begin ICE gather=
ing
   via the information supplied to setLocalDescription, as this is where
   the app specifies the number of media streams, and thereby ICE
   components, for which to gather candidates.  However, to accelerate
   cases where the application knows the number of ICE components to use
   ahead of time, it may ask the browser to gather a pool of potential
   ICE candidates to help ensure rapid media setup.

   When setLocalDescription is eventually called, and the browser goes
   to gather the needed ICE candidates, it SHOULD start by checking if
   any candidates are available in the pool.  If there are candidates in
   the pool, they SHOULD be handed to the application immediately via
   the ICE candidate callback.  If the pool becomes depleted, either
   because a larger-than-expected number of ICE components is used, or
   because the pool has not had enough time to gather candidates, the
   remaining candidates are gathered as usual.

   One example of where this concept is useful is an application that
   expects an incoming call at some point in the future, and wants to
   minimize the time it takes to establish connectivity, to avoid
   clipping of initial media.  By pre-gathering candidates into the
   pool, it can exchange and start sending connectivity checks from
   these candidates almost immediately upon receipt of a call.  Note
   though that by holding on to these pre-gathered candidates, which
   will be kept alive as long as they may be needed, the application
   will consume resources on the STUN/TURN servers it is using.
=


--089e01493f60008be7050fd9da63-- From nobody Tue Feb 24 12:45:01 2015 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 67EE91A8772 for ; Tue, 24 Feb 2015 12:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_iHXqsxI_7S for ; Tue, 24 Feb 2015 12:44:57 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168261A88E6 for ; Tue, 24 Feb 2015 12:44:56 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id u20so21609478oif.11 for ; Tue, 24 Feb 2015 12:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ugyNGqxBXz+/oaElT7sYQPhPBY1uGCmoA9/PS+245mA=; b=Ju9Y/RIgeqV8YDOnTXE6+/BMyoQ4U9o4GyIU08xmcQJveOV38duOEWt1V3K5qxRjUt ts780bLebtI2ZFH0LtjACb1pYUVPqWWIwpDVW2UgWdIhMaKUrWU3jR2iEGDIZFviATHL qSEyoqNDDt21RJ00QFxhK/cZCpGMW1JoFin1UugL8wGeEV+v2b/mM1qoGzstSXdTabRu YbgOL3ptV7lgXsBP2xUiK0/Kpg4hrePgByzV/sWyjkfu9JSg7CoKPRsa4a6Sspa8eA9q enzjudVo2pJ5Yp+vXEvTta5fe4Ikll4xZjksQFS8fwKvTGw1YgUEJtTErAhfLoHF8HSw QWAA== MIME-Version: 1.0 X-Received: by 10.182.60.197 with SMTP id j5mr12469093obr.85.1424810695315; Tue, 24 Feb 2015 12:44:55 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 24 Feb 2015 12:44:55 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 24 Feb 2015 12:44:55 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Feb 2015 09:44:55 +1300 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e013a2b2c5dd8d5050fdb97cb Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Question relating to ICE candidate pool 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 Feb 2015 20:44:59 -0000 --089e013a2b2c5dd8d5050fdb97cb Content-Type: text/plain; charset=UTF-8 I recall that the gathering could start at any point. At one point, Firefox was gathering immediately after construction. I think that the intent was to have pre-gathering start when the setting was applied. On Feb 25, 2015 7:40 AM, "Bernard Aboba" wrote: > A question has arisen with respect to draft-ietf-rtcweb-jsep-08 Sections > 3.4.4 and 4.1.2. Exerpts from these sections are enclosed below. > > While Section 3.4.4 refers to "pre-gathering" of ICE candidates prior to > calling of setLocalDescription(), Section 4.1.2 states that createOffer() > does not result in candidate gathering. > > One way to interpret this is that while createOffer() does not result in > firing of the onicecandidate callback (which needs to wait until > setLocalDescription() is called), it is ok (or even encouraged) for the > implementation to begin "pre-gathering" ICE candidates into the ICE > candidate pool once createOffer() is called. > > Is this a reasonable interpretation or is there another way this > could/should be read? > > > Section 4.1.2 createOffer: > > Calling this method may do things such as generate new ICE > credentials, but does not result in candidate gathering, or cause > media to start or stop flowing. > > > Section 3.4.4 ICE candidate pool: > > > 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, and thereby ICE > components, for which to gather candidates. However, to accelerate > cases where the application knows the number of ICE components to use > ahead of time, it may ask the browser to gather a pool of potential > ICE candidates to help ensure rapid media setup. > > When setLocalDescription is eventually called, and the browser goes > to gather the needed ICE candidates, it SHOULD start by checking if > any candidates are available in the pool. If there are candidates in > the pool, they SHOULD be handed to the application immediately via > the ICE candidate callback. If the pool becomes depleted, either > because a larger-than-expected number of ICE components is used, or > because the pool has not had enough time to gather candidates, the > remaining candidates are gathered as usual. > > One example of where this concept is useful is an application that > expects an incoming call at some point in the future, and wants to > minimize the time it takes to establish connectivity, to avoid > clipping of initial media. By pre-gathering candidates into the > pool, it can exchange and start sending connectivity checks from > these candidates almost immediately upon receipt of a call. Note > though that by holding on to these pre-gathered candidates, which > will be kept alive as long as they may be needed, the application > will consume resources on the STUN/TURN servers it is using. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e013a2b2c5dd8d5050fdb97cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I recall that the gathering could start at any point. At one= point, Firefox was gathering immediately after construction. I think that = the intent was to have pre-gathering start when the setting was applied.

On Feb 25, 2015 7:40 AM, "Bernard Aboba&quo= t; <bernard.aboba@gmail.com> wrote:
A question has arisen with respect to draft-ietf-rtcweb-jsep-08 = Sections 3.4.4 and 4.1.2.=C2=A0 Exerpts from these sections are enclosed be= low.=C2=A0

While Section 3.4.4 refers to "pre-gathe= ring" of ICE candidates prior to calling of setLocalDescription(), Sec= tion 4.1.2 states that createOffer() does not result in candidate gathering= .=C2=A0

One way to interpret this is that while cr= eateOffer() does not result in firing of the onicecandidate callback (which= needs to wait until setLocalDescription() is called), it is ok (or even en= couraged) for the implementation to begin "pre-gathering" ICE can= didates into the ICE candidate pool once createOffer() is called.=C2=A0

Is this a reasonable interpretation or is there anoth= er way this could/should be read? =C2=A0


<= div>Section 4.1.2 createOffer:=C2=A0

   Calling this=
 method may do things such as generate new ICE
   credentials, but does not result in candidate gathering, or cause
   media to start or stop flowing.

Section 3.4.4 ICE candidate pool:=C2=A0

   JSEP applications typically inform the browse=
r to begin ICE gathering
   via the information supplied to setLocalDescription, as this is where
   the app specifies the number of media streams, and thereby ICE
   components, for which to gather candidates.  However, to accelerate
   cases where the application knows the number of ICE components to use
   ahead of time, it may ask the browser to gather a pool of potential
   ICE candidates to help ensure rapid media setup.

   When setLocalDescription is eventually called, and the browser goes
   to gather the needed ICE candidates, it SHOULD start by checking if
   any candidates are available in the pool.  If there are candidates in
   the pool, they SHOULD be handed to the application immediately via
   the ICE candidate callback.  If the pool becomes depleted, either
   because a larger-than-expected number of ICE components is used, or
   because the pool has not had enough time to gather candidates, the
   remaining candidates are gathered as usual.

   One example of where this concept is useful is an application that
   expects an incoming call at some point in the future, and wants to
   minimize the time it takes to establish connectivity, to avoid
   clipping of initial media.  By pre-gathering candidates into the
   pool, it can exchange and start sending connectivity checks from
   these candidates almost immediately upon receipt of a call.  Note
   though that by holding on to these pre-gathered candidates, which
   will be kept alive as long as they may be needed, the application
   will consume resources on the STUN/TURN servers it is using.
= 

=

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

--089e013a2b2c5dd8d5050fdb97cb-- From nobody Tue Feb 24 14:41:00 2015 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 8609D1A0063 for ; Tue, 24 Feb 2015 14:40:59 -0800 (PST) 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 9F7KRoxS5mza for ; Tue, 24 Feb 2015 14:40:57 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11C91A0039 for ; Tue, 24 Feb 2015 14:40:56 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ex7so8679828wid.4 for ; Tue, 24 Feb 2015 14:40:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7Tkxjp1vk4P7EwFmNgGOlkIXWacVxNVshZzdhplq0OQ=; b=RWWDVoDipnpeQztNUdyH3Ll5TKxHNCAoDYF3Lotslu8wxL8a2N90vDz0C5NDQ2mfO0 Q1dD8dHSDV3TpSTlsnwvViKcWyhZl/px8GqgUFHAwims+N3RMc7CsGLD7bkL4NZon9US WDF64OijP2hR9zzK93p0LARe10Xu7yZBqApgkA531nTtcDB0Bdl+w165YzhkmsVlwKYf Dsg4TXNdBlI1ksRY+CWVy/J12dgRoX+vrfzfWfsNdli0o4atthvYC3A8hBpc6st9plKW vY28RJd0qey37XfzKLaU3U8Ji2rPm3d49DamiF7F9peDy0K+DL8hEGRfJ46umeOVePRa fbXQ== X-Gm-Message-State: ALoCoQnwzJ5vzp9x5cxPL7t0RrBn+WIFI1T1oXaNuKap2LrPZLIeGNaJYobtxVbzEJ2hOnPVJpmV X-Received: by 10.180.104.3 with SMTP id ga3mr850857wib.66.1424817655586; Tue, 24 Feb 2015 14:40:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.214.203 with HTTP; Tue, 24 Feb 2015 14:40:15 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 24 Feb 2015 14:40:15 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d043c059e3b3685050fdd36ea Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Question relating to ICE candidate pool 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 Feb 2015 22:40:59 -0000 --f46d043c059e3b3685050fdd36ea Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 10:40 AM, Bernard Aboba wrote: > A question has arisen with respect to draft-ietf-rtcweb-jsep-08 Sections > 3.4.4 and 4.1.2. Exerpts from these sections are enclosed below. > > While Section 3.4.4 refers to "pre-gathering" of ICE candidates prior to > calling of setLocalDescription(), Section 4.1.2 states that createOffer() > does not result in candidate gathering. > > One way to interpret this is that while createOffer() does not result in > firing of the onicecandidate callback (which needs to wait until > setLocalDescription() is called), it is ok (or even encouraged) for the > implementation to begin "pre-gathering" ICE candidates into the ICE > candidate pool once createOffer() is called. > The way I understood this was that you would start pre-gathering as soon as the pool size was increased to > 0. I.e., potentially before CreateOffer -Ekr > Is this a reasonable interpretation or is there another way this > could/should be read? > > > Section 4.1.2 createOffer: > > Calling this method may do things such as generate new ICE > credentials, but does not result in candidate gathering, or cause > media to start or stop flowing. > > > Section 3.4.4 ICE candidate pool: > > > 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, and thereby ICE > components, for which to gather candidates. However, to accelerate > cases where the application knows the number of ICE components to use > ahead of time, it may ask the browser to gather a pool of potential > ICE candidates to help ensure rapid media setup. > > When setLocalDescription is eventually called, and the browser goes > to gather the needed ICE candidates, it SHOULD start by checking if > any candidates are available in the pool. If there are candidates in > the pool, they SHOULD be handed to the application immediately via > the ICE candidate callback. If the pool becomes depleted, either > because a larger-than-expected number of ICE components is used, or > because the pool has not had enough time to gather candidates, the > remaining candidates are gathered as usual. > > One example of where this concept is useful is an application that > expects an incoming call at some point in the future, and wants to > minimize the time it takes to establish connectivity, to avoid > clipping of initial media. By pre-gathering candidates into the > pool, it can exchange and start sending connectivity checks from > these candidates almost immediately upon receipt of a call. Note > though that by holding on to these pre-gathered candidates, which > will be kept alive as long as they may be needed, the application > will consume resources on the STUN/TURN servers it is using. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043c059e3b3685050fdd36ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 24, 2015 at 10:40 AM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:
A question has arisen with respect to draft-ietf-rtcweb-jsep-08 Se= ctions 3.4.4 and 4.1.2.=C2=A0 Exerpts from these sections are enclosed belo= w.=C2=A0

While Section 3.4.4 refers to "pre-gatheri= ng" of ICE candidates prior to calling of setLocalDescription(), Secti= on 4.1.2 states that createOffer() does not result in candidate gathering.= =C2=A0

One way to interpret this is that while cre= ateOffer() does not result in firing of the onicecandidate callback (which = needs to wait until setLocalDescription() is called), it is ok (or even enc= ouraged) for the implementation to begin "pre-gathering" ICE cand= idates into the ICE candidate pool once createOffer() is called.=C2=A0

The way I understood this was that = you would start pre-gathering as soon as the pool
size was increa= sed to > 0. I.e., potentially before CreateOffer

-Ekr
=C2=A0
Is this a reasonable interpretation or is there another way this cou= ld/should be read? =C2=A0


Section 4.1= .2 createOffer:=C2=A0

   Calling this method may do =
things such as generate new ICE
   credentials, but does not result in candidate gathering, or cause
   media to start or stop flowing.

Section 3.4.4 ICE candidate pool:=C2=A0

   JSEP applications typically inform the browse=
r to begin ICE gathering
   via the information supplied to setLocalDescription, as this is where
   the app specifies the number of media streams, and thereby ICE
   components, for which to gather candidates.  However, to accelerate
   cases where the application knows the number of ICE components to use
   ahead of time, it may ask the browser to gather a pool of potential
   ICE candidates to help ensure rapid media setup.

   When setLocalDescription is eventually called, and the browser goes
   to gather the needed ICE candidates, it SHOULD start by checking if
   any candidates are available in the pool.  If there are candidates in
   the pool, they SHOULD be handed to the application immediately via
   the ICE candidate callback.  If the pool becomes depleted, either
   because a larger-than-expected number of ICE components is used, or
   because the pool has not had enough time to gather candidates, the
   remaining candidates are gathered as usual.

   One example of where this concept is useful is an application that
   expects an incoming call at some point in the future, and wants to
   minimize the time it takes to establish connectivity, to avoid
   clipping of initial media.  By pre-gathering candidates into the
   pool, it can exchange and start sending connectivity checks from
   these candidates almost immediately upon receipt of a call.  Note
   though that by holding on to these pre-gathered candidates, which
   will be kept alive as long as they may be needed, the application
   will consume resources on the STUN/TURN servers it is using.
= 

=

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


--f46d043c059e3b3685050fdd36ea-- From nobody Tue Feb 24 18:45:41 2015 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 7E17B1A033A for ; Tue, 24 Feb 2015 18:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F7hcqsFanvO for ; Tue, 24 Feb 2015 18:45:37 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825571A00DC for ; Tue, 24 Feb 2015 18:45:37 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id h15so2449972igd.3 for ; Tue, 24 Feb 2015 18:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZxSl3NEcaK89Yt0w9HkXWqVVwzHbUbKn95dSDXpNp8I=; b=niQyfG28PfOmmwNbxrQGpd6E4DNiUy1Aw1pm1VIqGWCOB4vgt/FF2y/CCvY/ylY1YE rHhDoRjLoPpAMfPp5Yz0zLwy+XL48wQiZlzDMHNbgG0aG8UQNjQmt5FolTwOujMmdB0e b6g77k6ZKRxShBsnnk5QzXtX+lUQnZNflO+cvvfEyF5xZbNtiF7fCusZzIeQF2X6EsGk oLCTQw+vNhj6dSmw9jdTruXnVZA6rj/CyEv/uZaQgB8u9xMBlFr64AbB9MOB0WDmSspx fI19qUcRc9hLnlcs6Kd2dhiOo2ZPKpXPwvWvx/uWAld0oZQIACRkLN9/g/eUemyK0Hlo rGeA== 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=ZxSl3NEcaK89Yt0w9HkXWqVVwzHbUbKn95dSDXpNp8I=; b=OZs1tACP5kEPrrV0+CRG4C6J7yLNE+G5xYmrVLFgrryvnZU1OHyOaaVtOU7QQJHFNL bl7lqyqgRgb8r3kthasksig9/Rl9FCfEQlmOsWuIcix4RSjX/dTsSTSf+p31sIZp/aWT qQxqVOx+HhtptCuy3bTN4s+pBMgeHPq3qwL1BHRFXbv9ISRikoNp02JuPgkIZtkeNdqx j8nSbVbw6ksMfcBSFYPuvs3CBR4ktgA2Wr693n3QoJQAUQJ+q0hZArWEWsLnnY9N5oDk d03ZLz+HrPNhKkT+BIJ6GFw9yScj5NgAOAFjaVANX0PpeQ0VlKduP+qURUnuL8tpxfaj pN/w== X-Gm-Message-State: ALoCoQl3YoxDqBvFay0+NOgXX2ww5nU6TwSdfNogb2JwJoyNGAAVt4CSLzVbWRY9Zm8aglh6V1i9 X-Received: by 10.42.223.194 with SMTP id il2mr1488881icb.94.1424832336681; Tue, 24 Feb 2015 18:45:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Tue, 24 Feb 2015 18:45:16 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Tue, 24 Feb 2015 18:45:16 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1132fb6e4af98e050fe0a16d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Question relating to ICE candidate pool 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, 25 Feb 2015 02:45:39 -0000 --001a1132fb6e4af98e050fe0a16d Content-Type: text/plain; charset=UTF-8 Exactly what Eric said. createOffer is probably too late to be useful in many cases. On Tue, Feb 24, 2015 at 2:40 PM, Eric Rescorla wrote: > > > On Tue, Feb 24, 2015 at 10:40 AM, Bernard Aboba > wrote: > >> A question has arisen with respect to draft-ietf-rtcweb-jsep-08 Sections >> 3.4.4 and 4.1.2. Exerpts from these sections are enclosed below. >> >> While Section 3.4.4 refers to "pre-gathering" of ICE candidates prior to >> calling of setLocalDescription(), Section 4.1.2 states that createOffer() >> does not result in candidate gathering. >> >> One way to interpret this is that while createOffer() does not result in >> firing of the onicecandidate callback (which needs to wait until >> setLocalDescription() is called), it is ok (or even encouraged) for the >> implementation to begin "pre-gathering" ICE candidates into the ICE >> candidate pool once createOffer() is called. >> > > The way I understood this was that you would start pre-gathering as soon > as the pool > size was increased to > 0. I.e., potentially before CreateOffer > > -Ekr > > >> Is this a reasonable interpretation or is there another way this >> could/should be read? >> >> >> Section 4.1.2 createOffer: >> >> Calling this method may do things such as generate new ICE >> credentials, but does not result in candidate gathering, or cause >> media to start or stop flowing. >> >> >> Section 3.4.4 ICE candidate pool: >> >> >> 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, and thereby ICE >> components, for which to gather candidates. However, to accelerate >> cases where the application knows the number of ICE components to use >> ahead of time, it may ask the browser to gather a pool of potential >> ICE candidates to help ensure rapid media setup. >> >> When setLocalDescription is eventually called, and the browser goes >> to gather the needed ICE candidates, it SHOULD start by checking if >> any candidates are available in the pool. If there are candidates in >> the pool, they SHOULD be handed to the application immediately via >> the ICE candidate callback. If the pool becomes depleted, either >> because a larger-than-expected number of ICE components is used, or >> because the pool has not had enough time to gather candidates, the >> remaining candidates are gathered as usual. >> >> One example of where this concept is useful is an application that >> expects an incoming call at some point in the future, and wants to >> minimize the time it takes to establish connectivity, to avoid >> clipping of initial media. By pre-gathering candidates into the >> pool, it can exchange and start sending connectivity checks from >> these candidates almost immediately upon receipt of a call. Note >> though that by holding on to these pre-gathered candidates, which >> will be kept alive as long as they may be needed, the application >> will consume resources on the STUN/TURN servers it is using. >> >> >> >> >> _______________________________________________ >> 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 > > --001a1132fb6e4af98e050fe0a16d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exactly what Eric said. createOffer is probably too late t= o be useful in many cases.

On Tue, Feb 24, 2015 at 2:40 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= br>

On Tue, Feb 24, 2015 at 10:40 AM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:
A question has arisen with respect to draft-ietf-rtcweb-jsep-08 Secti= ons 3.4.4 and 4.1.2.=C2=A0 Exerpts from these sections are enclosed below.= =C2=A0

While Section 3.4.4 refers to "pre-gathering= " of ICE candidates prior to calling of setLocalDescription(), Section= 4.1.2 states that createOffer() does not result in candidate gathering.=C2= =A0

One way to interpret this is that while create= Offer() does not result in firing of the onicecandidate callback (which nee= ds to wait until setLocalDescription() is called), it is ok (or even encour= aged) for the implementation to begin "pre-gathering" ICE candida= tes into the ICE candidate pool once createOffer() is called.=C2=A0

The way I understood this was t= hat you would start pre-gathering as soon as the pool
size was in= creased to > 0. I.e., potentially before CreateOffer

-Ekr
=C2=A0
Is this a reasonable interpretation or is= there another way this could/should be read? =C2=A0


Section 4.1.2 createOffer:=C2=A0

   =
Calling this method may do things such as generate new ICE
   credentials, but does not result in candidate gathering, or cause
   media to start or stop flowing.

Section 3.4.4 ICE candidate pool:=C2=A0

   JSEP applications typically inform the browse=
r to begin ICE gathering
   via the information supplied to setLocalDescription, as this is where
   the app specifies the number of media streams, and thereby ICE
   components, for which to gather candidates.  However, to accelerate
   cases where the application knows the number of ICE components to use
   ahead of time, it may ask the browser to gather a pool of potential
   ICE candidates to help ensure rapid media setup.

   When setLocalDescription is eventually called, and the browser goes
   to gather the needed ICE candidates, it SHOULD start by checking if
   any candidates are available in the pool.  If there are candidates in
   the pool, they SHOULD be handed to the application immediately via
   the ICE candidate callback.  If the pool becomes depleted, either
   because a larger-than-expected number of ICE components is used, or
   because the pool has not had enough time to gather candidates, the
   remaining candidates are gathered as usual.

   One example of where this concept is useful is an application that
   expects an incoming call at some point in the future, and wants to
   minimize the time it takes to establish connectivity, to avoid
   clipping of initial media.  By pre-gathering candidates into the
   pool, it can exchange and start sending connectivity checks from
   these candidates almost immediately upon receipt of a call.  Note
   though that by holding on to these pre-gathered candidates, which
   will be kept alive as long as they may be needed, the application
   will consume resources on the STUN/TURN servers it is using.
= 

=

__________________________________________= _____
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


--001a1132fb6e4af98e050fe0a16d-- From nobody Wed Feb 25 11:48:19 2015 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 B9D0F1A1BCC; Wed, 25 Feb 2015 11:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzg_muJ-DY5q; Wed, 25 Feb 2015 11:48:12 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A401A870C; Wed, 25 Feb 2015 11:48:11 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTP id 8E972F23A1; Wed, 25 Feb 2015 11:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.corp.phx1.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVQcihBm4HCg; Wed, 25 Feb 2015 11:48:10 -0800 (PST) Received: from [10.252.26.110] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 64110F2181; Wed, 25 Feb 2015 11:48:10 -0800 (PST) Message-ID: <54EE26FA.4060009@mozilla.com> Date: Wed, 25 Feb 2015 11:48:10 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" , "rmcat@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------000702040600000706080702" Archived-At: Subject: [rtcweb] Fwd: [video-codec] Come hack on Daala @ IETF 92 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, 25 Feb 2015 19:48:16 -0000 This is a multi-part message in MIME format. --------------000702040600000706080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Distributing more broadly on Charles's suggestion. -------- Forwarded Message -------- Subject: [video-codec] Come hack on Daala @ IETF 92 Date: Wed, 25 Feb 2015 12:38:00 -0700 From: Jack Moffitt To: video-codec@ietf.org , daala@xiph.org Charles Eckel has organized an IETF hackathon the weekend before IETF. Daala is one of the groups participating and we'd love to have some others come hack with us on video codecs. There are Daala projects appropriate for many skills levels, and several of the Daala team will be there to mentor people who need some. Be sure to register early as there are only so many spots available. Here are the details from Charles: The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. It takes place just before IETF 92, and it¹s free and open to everyone. All you need is a knowledge of networking technologies, and you¹ll be guaranteed to learn something new and have fun! Event details: https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html --------------000702040600000706080702 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec --------------000702040600000706080702-- From nobody Thu Feb 26 07:49:23 2015 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 256B21A86E8; Thu, 26 Feb 2015 07:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqEyh8EpZuZq; Thu, 26 Feb 2015 07:49:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7931A1B7B; Thu, 26 Feb 2015 07:49:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226154919.32108.48250.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 07:49:19 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-08.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: Thu, 26 Feb 2015 15:49:21 -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 : Security Considerations for WebRTC Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-08.txt Pages : 24 Date : 2015-02-26 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC". The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 26 13:22:59 2015 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 BC1201ACCED for ; Thu, 26 Feb 2015 13:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s0P035pvVhF for ; Thu, 26 Feb 2015 13:22:48 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A301AC44D for ; Thu, 26 Feb 2015 13:22:37 -0800 (PST) Received: by iecat20 with SMTP id at20so21377064iec.12 for ; Thu, 26 Feb 2015 13:22:36 -0800 (PST) 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=mQXb11g/5870P7121u/pF7mhBCLRAkU5Uh+mMlnUTNI=; b=wpWkhOPIqZz8LrNdKgaLyvfc8jaIf4kJ8luhBIBCO0jWRjrEP6XZjie+woCPWbCb/t grKfzRVqwbLfrm2gVhRz3EZ+hLqjdi9HA1Jrh8IXVZlWdxL/B6kve8bLpIN0zTC8t1sp IxzHLz7c13I5MVNJs/5Y68Rl9IH49p5N4etSb1pxFUl1WeofZjQfQcubPWKGRIvRWS83 S0wtC56AU/1kMFffcjMbALdYlL4lBcheQfHoq8lZ17HwP/1tKf0MSX8UplfnjCaSl8xy 5NpEJPNj5wEs9Lp7nRCP4XuY+c+qMhk88c2ET5q5WpkhHGgn3/vdL0EhpMi6Cs6WGz1K Sjcw== MIME-Version: 1.0 X-Received: by 10.107.167.145 with SMTP id q139mr14729870ioe.16.1424985756905; Thu, 26 Feb 2015 13:22:36 -0800 (PST) Received: by 10.42.35.80 with HTTP; Thu, 26 Feb 2015 13:22:36 -0800 (PST) Date: Thu, 26 Feb 2015 13:22:36 -0800 Message-ID: From: Ted Hardie To: btdingle@gmail.com, "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" , "rfc-design@rfc-editor.org" Content-Type: multipart/alternative; boundary=001a11429990d9b7a905100459bd Archived-At: Subject: [rtcweb] Consistent description of WebRTC in abstracts 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, 26 Feb 2015 21:22:53 -0000 --001a11429990d9b7a905100459bd Content-Type: text/plain; charset=UTF-8 Howdy, Barry recently raised a question about the Abstracts of WebRTC-related RFCs: should there be a consistent single sentence in the Abstract of all related RFCs? The opinion of the chairs is that any Abstract text approved by the working group represents its consensus, and that there is no particular need to require uniformity. Authors and editors are, of course, welcome to re-use the existing text. Folks who prefer the existing text may also, of course, suggest edits for the Abstract as for other parts of the document. regards, Ted, Sean, and Cullen --001a11429990d9b7a905100459bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Barry recently rai= sed a question about the Abstracts of WebRTC-related RFCs:=C2=A0 should the= re be a consistent single sentence in the Abstract of all related RFCs?=C2= =A0 The opinion of the chairs is that any Abstract text approved by the wor= king group represents its consensus, and that there is no particular need t= o require uniformity.=C2=A0 Authors and editors are, of course, welcome to = re-use the existing text.=C2=A0 Folks who prefer the existing text may also= , of course, suggest edits for the Abstract as for other parts of the docum= ent.=C2=A0

regards,

Ted, Sea= n, and Cullen
--001a11429990d9b7a905100459bd-- From nobody Thu Feb 26 13:28:40 2015 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 5513E1ACCE5 for ; Thu, 26 Feb 2015 13:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8XSY1S2soLO for ; Thu, 26 Feb 2015 13:28:38 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BE31AC443 for ; Thu, 26 Feb 2015 13:28:38 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id x69so12214104oia.5 for ; Thu, 26 Feb 2015 13:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TxUSG2a/jC2luMQSjL8slbg8VxhDL2URS4fUeDljfXc=; b=bOVpJaNdbB69oRsGplZoVP6Hn/DeRGXOhqYk2ybv5erFJPh1ZrCFkFPAnBaZT4xZXs zogKy8IZrzqGGPChfs5f0HkPflngpTxBhR+hIEbCEeQbKaDs08X1vUGyGMMLhEIIpVJe nKYQgYRwn05yL4z4qGhg8pJM39wjOnrA4jzdhYx9kNhsD/FLX58xKVTlzC+q8oC2BJCq TTbUlYJY6lrvxjBeiL8uyua9lGkblaT0G0eSJGUsIF3n1ZYkEYzcvj0bq8YvcgPdoPgM xkSY7ridQdr8T2XGilcjh3YgvxU/Uy5HAXnBk68U96grmALDmUjYodO/jKWNl9tAIlYG z3gg== MIME-Version: 1.0 X-Received: by 10.202.7.1 with SMTP id 1mr7187366oih.16.1424986117288; Thu, 26 Feb 2015 13:28:37 -0800 (PST) Received: by 10.202.225.135 with HTTP; Thu, 26 Feb 2015 13:28:37 -0800 (PST) In-Reply-To: References: Date: Fri, 27 Feb 2015 10:28:37 +1300 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rfc-design@rfc-editor.org" , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Consistent description of WebRTC in abstracts 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, 26 Feb 2015 21:28:39 -0000 On 27 February 2015 at 10:22, Ted Hardie wrote: > Barry recently raised a question about the Abstracts of WebRTC-related RFCs: > should there be a consistent single sentence in the Abstract of all related > RFCs? What would that sentence say? From nobody Thu Feb 26 13:35:35 2015 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 000841A8032 for ; Thu, 26 Feb 2015 13:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds5yCXLjzEjT for ; Thu, 26 Feb 2015 13:35:33 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7062F1A1A91 for ; Thu, 26 Feb 2015 13:35:33 -0800 (PST) Received: by iecrl12 with SMTP id rl12so21599389iec.2 for ; Thu, 26 Feb 2015 13:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BpCNEKSV1QhitHNAjft3rDpZwcPwpxo/kI9iyBrAL0k=; b=auuL+AH7TsOtVPQ7dgwBBRRuCV50NLcNfbKQ1lbA1qXh9xWuXR76FVF/V2+On28eE7 3cjxr4MI3m13UKTsoFYUr226HHksHy80sXIp4kT0CY30f2pOSIaBtsviEUbrR1ls8Z1k i6zS5eT18ZN02zcNLDpMQqdPWpUD+9Skai2paqvWyGCbsgBW2nkn4IyTSQY1nThEfpzR QeO0jWTXsnbuwk0w0MMhj9w7obMPWcsRrV79L3CfELSSNlu5VntrdvGh96PI8UmEAPUC bb/M4WzFfSbzi6dE4C/MaZ/MLTtMA3EaD9i21bg1dSfWvY4cLI1mPRujVYIV5+T1ZCiP F8Qg== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr178266igl.6.1424986532746; Thu, 26 Feb 2015 13:35:32 -0800 (PST) Received: by 10.42.35.80 with HTTP; Thu, 26 Feb 2015 13:35:32 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Feb 2015 13:35:32 -0800 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: multipart/alternative; boundary=089e011825c0181c90051004888e Archived-At: Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Consistent description of WebRTC in abstracts 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, 26 Feb 2015 21:35:35 -0000 --089e011825c0181c90051004888e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2015 at 1:28 PM, Martin Thomson wrote: > On 27 February 2015 at 10:22, Ted Hardie wrote: > > Barry recently raised a question about the Abstracts of WebRTC-related > RFCs: > > should there be a consistent single sentence in the Abstract of all > related > > RFCs? > > > What would that sentence say? > =E2=80=8BBarry raised the point because the Data Channel drafts used this p= hrasing: The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. where other drafts use other phrases. The Security architecture draft, for example, says: The Real-Time Communications on the Web (RTCWEB) working group is tasked wi= th standardizing protocols for real-time communications between Web browsers, generally called "WebRTC". =E2=80=8B and overview says: 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". =E2=80=8BTed=E2=80=8B --089e011825c0181c90051004888e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 26, 2015 at 1:28 PM= , Martin Thomson <martin.thomson@gmail.com> wrote:
On 27 February 2015 at 10:22, Ted Hardie <ted.ietf@gmail.com> wrote:
> Barry recently raised a question about the Abstracts of WebRTC-related= RFCs:
> should there be a consistent single sentence in the Abstract of all re= lated
> RFCs?


What would that sentence say?


=E2=80=8BBarry raised the point becaus= e the Data Channel drafts used this phrasing:

The WebRTC framew=
ork specifies protocol support for direct interactive rich communication us=
ing audio, 
video, and data between two peers' web-browsers.

=

where other drafts use other phrases. The Security architecture =
draft, for example, says:
=C2=A0
The Real-Time Communications on the =
Web (RTCWEB) working group is tasked with 
standardizing protocols for r=
eal-time communications between Web browsers, generally 
called "We=
bRTC".
=E2=80=8B
and overview says:
This document gives an overview and context of a protocol suite intended = for use with real-time applications that can be deployed in browsers - &quo= t;real time communication on the Web".


=E2= =80=8BTed=E2=80=8B

--089e011825c0181c90051004888e-- From nobody Thu Feb 26 13:37:03 2015 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 C914F1A885C for ; Thu, 26 Feb 2015 13:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-77Fu3gM6p9 for ; Thu, 26 Feb 2015 13:37:01 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C81C1A8874 for ; Thu, 26 Feb 2015 13:37:01 -0800 (PST) Received: by iecat20 with SMTP id at20so21569048iec.12 for ; Thu, 26 Feb 2015 13:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OTdCec1ge1Lk4PeH5hPYGmiRIDuGkEJVSyCN2em8GEs=; b=EckZLklv34TfU35BybqhGxwIx58cwaDm/mJyfshbQQ0HlHjHoc5J3VfOzDyPQYyMru YsPvN02KcxRLrzLfrbhJhs3hzJOhSlzPa3X8jFE0cSMP5tRT2gPjInLey7DZ4VqgeMqz NYAhyeaFLJTFZgcM3vpCv6VMZW4wCFsKHYTR8jCYdYwVw0PJGbY4joyAuAkshX5n9OBY COiXST6DyiL37YDkkaFpFLwa1CnqtNUL1P3/7GFCQ2ZtcgFaGGghYkf796s2h4YlUusV Lpm/4eM5vsnq202r7ACHgYfybfSVoYXyVRxqBfFfj8uLdUmtvi91zR+rnr+U5EuDHs7c hQRg== MIME-Version: 1.0 X-Received: by 10.107.170.8 with SMTP id t8mr14316277ioe.7.1424986620639; Thu, 26 Feb 2015 13:37:00 -0800 (PST) Received: by 10.42.35.80 with HTTP; Thu, 26 Feb 2015 13:37:00 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Feb 2015 13:37:00 -0800 Message-ID: From: Ted Hardie To: Barry Dingle , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11427bbc5544f50510048d8c Archived-At: Subject: Re: [rtcweb] Consistent description of WebRTC in abstracts 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, 26 Feb 2015 21:37:02 -0000 --001a11427bbc5544f50510048d8c Content-Type: text/plain; charset=UTF-8 My original message was cc'ed to rfc-design because I didn't catch an auto-complete error; please follow up without them cc'ed. thanks, Ted On Thu, Feb 26, 2015 at 1:22 PM, Ted Hardie wrote: > Howdy, > > Barry recently raised a question about the Abstracts of WebRTC-related > RFCs: should there be a consistent single sentence in the Abstract of all > related RFCs? The opinion of the chairs is that any Abstract text approved > by the working group represents its consensus, and that there is no > particular need to require uniformity. Authors and editors are, of course, > welcome to re-use the existing text. Folks who prefer the existing text > may also, of course, suggest edits for the Abstract as for other parts of > the document. > > regards, > > Ted, Sean, and Cullen > --001a11427bbc5544f50510048d8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My original message was cc'ed to rfc-design = because I didn't catch an auto-complete error; please follow up without= them cc'ed.

thanks,

Ted<= br>

On= Thu, Feb 26, 2015 at 1:22 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
How= dy,

Barry recently raised a question about the Abstr= acts of WebRTC-related RFCs:=C2=A0 should there be a consistent single sent= ence in the Abstract of all related RFCs?=C2=A0 The opinion of the chairs i= s that any Abstract text approved by the working group represents its conse= nsus, and that there is no particular need to require uniformity.=C2=A0 Aut= hors and editors are, of course, welcome to re-use the existing text.=C2=A0= Folks who prefer the existing text may also, of course, suggest edits for = the Abstract as for other parts of the document.=C2=A0

regards,

Ted, Sean, and Cullen

--001a11427bbc5544f50510048d8c-- From nobody Thu Feb 26 14:25:34 2015 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 164A21A88DC; Thu, 26 Feb 2015 14:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq0gWYhKGLcg; Thu, 26 Feb 2015 14:22:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C128F1A88BF; Thu, 26 Feb 2015 14:22:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Hardie" To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226222244.20387.747.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 14:22:44 -0800 Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 14:25:31 -0800 Cc: ted.hardie@nominum.com, rtcweb-chairs@tools.ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, iesg-secretary@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org, draft-ietf-rtcweb-stun-consent-freshness@ietf.org Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-stun-consent-freshness-11 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: Thu, 26 Feb 2015 22:22:47 -0000 Ted Hardie has requested publication of draft-ietf-rtcweb-stun-consent-freshness-11 as Proposed Standard on behalf of the RTCWEB working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ From nobody Thu Feb 26 15:37:23 2015 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 154111A89E0 for ; Thu, 26 Feb 2015 15:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 tI55HApq7k10 for ; Thu, 26 Feb 2015 15:37:21 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.10.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385261A8953 for ; Thu, 26 Feb 2015 15:37:19 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 731B6CDB50F7; Thu, 26 Feb 2015 17:37:18 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 616BFCDB5074 for ; Thu, 26 Feb 2015 17:37:18 -0600 (CST) Received: from [96.231.226.227] (port=65442 helo=[192.168.1.8]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YR7zZ-0000Gt-A0 for rtcweb@ietf.org; Thu, 26 Feb 2015 17:37:17 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <51BBF650-F831-4E00-86BE-18F14060473C@ieca.com> Date: Thu, 26 Feb 2015 18:37:17 -0500 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.227 X-Exim-ID: 1YR7zZ-0000Gt-A0 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.8]) [96.231.226.227]:65442 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [rtcweb] WGLC for draft-ietf-rtcweb-video-04 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, 26 Feb 2015 23:37:22 -0000 Dear WG, This message initiates a WGLC (Working Group Last Call) for the "WebRTC = Video Processing and Codec Requirements=94 draft: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ Please review the draft in detail. This WGLC will end on 13 March, = 2015. spt= From nobody Fri Feb 27 06:26:43 2015 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 6EEE61A8902; Fri, 27 Feb 2015 06:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wfIZOc7qGEA; Fri, 27 Feb 2015 06:26:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6032A1A87E2; Fri, 27 Feb 2015 06:26:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150227142640.27339.71835.idtracker@ietfa.amsl.com> Date: Fri, 27 Feb 2015 06:26:40 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-08.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: Fri, 27 Feb 2015 14:26:41 -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 WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-08.txt Pages : 14 Date : 2015-02-27 Abstract: This document describes the data transport protocols used by WebRTC, 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 27 06:31:35 2015 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 106A91A88F3 for ; Fri, 27 Feb 2015 06:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iLNkq-rgwWU for ; Fri, 27 Feb 2015 06:31:31 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3714C1A88B6 for ; Fri, 27 Feb 2015 06:31:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4F54C7C42B0 for ; Fri, 27 Feb 2015 15:31:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpLlL8oscfUy for ; Fri, 27 Feb 2015 15:31:26 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:19f3:8d27:2648:7280] (unknown [IPv6:2001:470:de0a:27:19f3:8d27:2648:7280]) by mork.alvestrand.no (Postfix) with ESMTPSA id F3BF07C42A3 for ; Fri, 27 Feb 2015 15:31:25 +0100 (CET) Message-ID: <54F07FBD.8050403@alvestrand.no> Date: Fri, 27 Feb 2015 15:31:25 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] New version of -transport 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 Feb 2015 14:31:34 -0000 I've shipped a new version of -transport, since I'll be away for most of the time between now and the I-D deadline. There's only one significant change, which resulted from reading the JSEP draft and discussing the matter with the JSEP editors about the meaning of the "balanced" mode. OLD: it may therefore make sense for a sending application to choose any of the configurations: o Each media stream carried on its own 5-tuple o Media streams grouped by media type into 5-tuples (such as carrying all audio on one 5-tuple) o All media sent over a single 5-tuple, with or without differentiation into 6-tuples based on DSCP code points In each of the configurations mentioned, data channels may be carried in its own 5-tuple, or multiplexed together with one of the media flows. More complex configurations, such as sending a high priority video stream on one 5-tuple and sending all other video streams multiplexed together over another 5-tuple, can also be envisioned. More information on mapping media flows to 5-tuples can be found in [I-D.ietf-rtcweb-rtp-usage]. A sending WebRTC endpoint MUST be able to support the following configurations: o multiplex all media and data on a single 5-tuple (fully bundled) o send each media stream on its own 5-tuple and data on its own 5-tuple (fully unbundled) o bundle each media type (audio, video or data) into its own 5-tuple (bundling by media type) It MAY choose to support other configurations. NEW: it may therefore make sense for a sending application to choose any of the configurations: o Each media stream carried on its own 5-tuple o Media streams grouped by media type into 5-tuples (such as carrying all audio on one 5-tuple) o All media sent over a single 5-tuple, with or without differentiation into 6-tuples based on DSCP code points In each of the configurations mentioned, data channels may be carried in its own 5-tuple, or multiplexed together with one of the media flows. More complex configurations, such as sending a high priority video stream on one 5-tuple and sending all other video streams multiplexed together over another 5-tuple, can also be envisioned. More information on mapping media flows to 5-tuples can be found in [I-D.ietf-rtcweb-rtp-usage]. A sending implementation MUST be able to support the following configurations: o multiplex all media and data on a single 5-tuple (fully bundled) o send each media stream on its own 5-tuple and data on its own 5-tuple (fully unbundled) It MAY choose to support other configurations, such as bundling each media type (audio, video or data) into its own 5-tuple (bundling by media type). Note that the draft is now on github: https://github.com/rtcweb-wg/rtcweb-transport If you wish to make sure I don't forget issues, filing an issue there is a Good Ideal; if you feel that you can improve the text, don't hesitate to post pull requests! Harald From nobody Fri Feb 27 08:26:47 2015 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 E68E21A6FF1 for ; Fri, 27 Feb 2015 08:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6khi-qsXqkT for ; Fri, 27 Feb 2015 08:26:44 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734FE1A1B86 for ; Fri, 27 Feb 2015 08:26:44 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-11v.sys.comcast.net with comcast id xULd1p00A29Cfhx01USj1f; Fri, 27 Feb 2015 16:26:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-03v.sys.comcast.net with comcast id xUSj1p0083Ge9ey01USjes; Fri, 27 Feb 2015 16:26:43 +0000 Message-ID: <54F09AC2.6090008@alum.mit.edu> Date: Fri, 27 Feb 2015 11:26:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54F07FBD.8050403@alvestrand.no> In-Reply-To: <54F07FBD.8050403@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425054403; bh=ahBADTce4Btf+FL5Vl+vSrkh/7KmOKwJERJqouNHdM4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=O9n2OKoiaxcbj5msos5CV18LnYz45y8SPP7E+7HLiGaZxiweK0UaHbf2XOhvu9N9A y61us/zPrxORmQY0TkY5EGbNdI5xkIUJCFqijsUNDBgwLZvPi/tS97YflKWv+LySQ1 C27RTaoTi4HExzROSxwDIJbf7K+C6toFn5zZ0xVXjvKfdFGU0kxwIACqVQkFSEMNVC ozrA1xcC1Y9ws4ukKtAFbo7F8SR3jsyhlz6IQSCT0sgn5XnFqs/0tHEJNr0a01U8av e+jxGyPKoOdPAXfNx/PcXkzHfUiGnLDh8NF1Z9iLyIKXh5VBtlKikEaQOmybeyUXKj i1XqZvfEXo7RA== Archived-At: Subject: Re: [rtcweb] New version of -transport 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 Feb 2015 16:26:46 -0000 Harald, In the below (both old and new) you identify an alternative that bundles all audio on one 5-tuple and all video on another 5-tuple. AFAIK there is no way to tell JSEP to do that. (I once thought there was, but eventually learned it wasn't.) If not, does it make sense to list it as an alternative here? Or is that the reason you make that configuration optional for senders? Thanks, Paul On 2/27/15 9:31 AM, Harald Alvestrand wrote: > I've shipped a new version of -transport, since I'll be away for most of > the time between now and the I-D deadline. > > There's only one significant change, which resulted from reading the > JSEP draft and discussing the matter with the JSEP editors about the > meaning of the "balanced" mode. > > > OLD: > > it may therefore make sense for a sending application to > choose any of the configurations: > > o Each media stream carried on its own 5-tuple > > o Media streams grouped by media type into 5-tuples (such as > carrying all audio on one 5-tuple) > > o All media sent over a single 5-tuple, with or without > differentiation into 6-tuples based on DSCP code points > > In each of the configurations mentioned, data channels may be carried > in its own 5-tuple, or multiplexed together with one of the media > flows. > > More complex configurations, such as sending a high priority video > stream on one 5-tuple and sending all other video streams multiplexed > together over another 5-tuple, can also be envisioned. More > information on mapping media flows to 5-tuples can be found in > [I-D.ietf-rtcweb-rtp-usage]. > > A sending WebRTC endpoint MUST be able to support the following > configurations: > > o multiplex all media and data on a single 5-tuple (fully bundled) > > o send each media stream on its own 5-tuple and data on its own > 5-tuple (fully unbundled) > > o bundle each media type (audio, video or data) into its own 5-tuple > (bundling by media type) > > It MAY choose to support other configurations. > > > NEW: > > > it may therefore make sense for a sending application to > choose any of the configurations: > > o Each media stream carried on its own 5-tuple > > o Media streams grouped by media type into 5-tuples (such as > carrying all audio on one 5-tuple) > > o All media sent over a single 5-tuple, with or without > differentiation into 6-tuples based on DSCP code points > > In each of the configurations mentioned, data channels may be carried > in its own 5-tuple, or multiplexed together with one of the media > flows. > > More complex configurations, such as sending a high priority video > stream on one 5-tuple and sending all other video streams multiplexed > together over another 5-tuple, can also be envisioned. More > information on mapping media flows to 5-tuples can be found in > [I-D.ietf-rtcweb-rtp-usage]. > > A sending implementation MUST be able to support the following > configurations: > > o multiplex all media and data on a single 5-tuple (fully bundled) > > o send each media stream on its own 5-tuple and data on its own > 5-tuple (fully unbundled) > > It MAY choose to support other configurations, such as bundling each > media type (audio, video or data) into its own 5-tuple (bundling by > media type). > > Note that the draft is now on github: > > https://github.com/rtcweb-wg/rtcweb-transport > > If you wish to make sure I don't forget issues, filing an issue there is > a Good Ideal; if you feel that you can improve the text, don't hesitate > to post pull requests! > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Feb 27 13:33:11 2015 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 C99771A0211 for ; Fri, 27 Feb 2015 13:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSOT65hypnz3 for ; Fri, 27 Feb 2015 13:33:06 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id E78A21A00FE for ; Fri, 27 Feb 2015 13:33:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3179E7C3E49 for ; Fri, 27 Feb 2015 22:33:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U0Y1_je9YPH for ; Fri, 27 Feb 2015 22:33:02 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:19f3:8d27:2648:7280] (unknown [IPv6:2001:470:de0a:27:19f3:8d27:2648:7280]) by mork.alvestrand.no (Postfix) with ESMTPSA id AEA3D7C394E for ; Fri, 27 Feb 2015 22:33:02 +0100 (CET) Message-ID: <54F0E28E.4050602@alvestrand.no> Date: Fri, 27 Feb 2015 22:33:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54F07FBD.8050403@alvestrand.no> <54F09AC2.6090008@alum.mit.edu> In-Reply-To: <54F09AC2.6090008@alum.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] New version of -transport 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 Feb 2015 21:33:09 -0000 Den 27. feb. 2015 17:26, skrev Paul Kyzivat: > Harald, > > In the below (both old and new) you identify an alternative that bundles > all audio on one 5-tuple and all video on another 5-tuple. > > AFAIK there is no way to tell JSEP to do that. (I once thought there > was, but eventually learned it wasn't.) If not, does it make sense to > list it as an alternative here? Or is that the reason you make that > configuration optional for senders? That is the reason I make that configuration optional for senders. There's no sense in mandating it when there is consensus to not have a control surface to choose it, but there's no sense in forbidding it either - there will always be endpoints with extensions, and if this particular extension makes sense, someone will eventually make it. > > Thanks, > Paul > > On 2/27/15 9:31 AM, Harald Alvestrand wrote: >> I've shipped a new version of -transport, since I'll be away for most of >> the time between now and the I-D deadline. >> >> There's only one significant change, which resulted from reading the >> JSEP draft and discussing the matter with the JSEP editors about the >> meaning of the "balanced" mode. >> >> >> OLD: >> >> it may therefore make sense for a sending application to >> choose any of the configurations: >> >> o Each media stream carried on its own 5-tuple >> >> o Media streams grouped by media type into 5-tuples (such as >> carrying all audio on one 5-tuple) >> >> o All media sent over a single 5-tuple, with or without >> differentiation into 6-tuples based on DSCP code points >> >> In each of the configurations mentioned, data channels may be carried >> in its own 5-tuple, or multiplexed together with one of the media >> flows. >> >> More complex configurations, such as sending a high priority video >> stream on one 5-tuple and sending all other video streams multiplexed >> together over another 5-tuple, can also be envisioned. More >> information on mapping media flows to 5-tuples can be found in >> [I-D.ietf-rtcweb-rtp-usage]. >> >> A sending WebRTC endpoint MUST be able to support the following >> configurations: >> >> o multiplex all media and data on a single 5-tuple (fully bundled) >> >> o send each media stream on its own 5-tuple and data on its own >> 5-tuple (fully unbundled) >> >> o bundle each media type (audio, video or data) into its own 5-tuple >> (bundling by media type) >> >> It MAY choose to support other configurations. >> >> >> NEW: >> >> >> it may therefore make sense for a sending application to >> choose any of the configurations: >> >> o Each media stream carried on its own 5-tuple >> >> o Media streams grouped by media type into 5-tuples (such as >> carrying all audio on one 5-tuple) >> >> o All media sent over a single 5-tuple, with or without >> differentiation into 6-tuples based on DSCP code points >> >> In each of the configurations mentioned, data channels may be carried >> in its own 5-tuple, or multiplexed together with one of the media >> flows. >> >> More complex configurations, such as sending a high priority video >> stream on one 5-tuple and sending all other video streams multiplexed >> together over another 5-tuple, can also be envisioned. More >> information on mapping media flows to 5-tuples can be found in >> [I-D.ietf-rtcweb-rtp-usage]. >> >> A sending implementation MUST be able to support the following >> configurations: >> >> o multiplex all media and data on a single 5-tuple (fully bundled) >> >> o send each media stream on its own 5-tuple and data on its own >> 5-tuple (fully unbundled) >> >> It MAY choose to support other configurations, such as bundling each >> media type (audio, video or data) into its own 5-tuple (bundling by >> media type). >> >> Note that the draft is now on github: >> >> https://github.com/rtcweb-wg/rtcweb-transport >> >> If you wish to make sure I don't forget issues, filing an issue there is >> a Good Ideal; if you feel that you can improve the text, don't hesitate >> to post pull requests! >> >> Harald >> >> _______________________________________________ >> 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 Sat Feb 28 15:22:03 2015 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 859E91A00CC; Sat, 28 Feb 2015 15:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M-3nuIfMRTs; Sat, 28 Feb 2015 15:21:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 690381A008F; Sat, 28 Feb 2015 15:21:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150228232159.15083.45367.idtracker@ietfa.amsl.com> Date: Sat, 28 Feb 2015 15:21:59 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-01.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: Sat, 28 Feb 2015 23:22:00 -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 : Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) Author : Martin Thomson Filename : draft-ietf-rtcweb-alpn-01.txt Pages : 7 Date : 2015-02-28 Abstract: Application Layer Protocol Negotiation (ALPN) labels are defined for use in identifying Web Real-Time Communications (WebRTC) usages of Datagram Transport Layer Security (DTLS). Labels are provided for identifying a session that uses a combination of WebRTC compatible media and data, and for identifying a session requiring confidentiality protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-alpn-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-alpn-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 28 15:24:36 2015 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 896A01A0097 for ; Sat, 28 Feb 2015 15:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R13iFhK-hCS8 for ; Sat, 28 Feb 2015 15:24:34 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1A61A008F for ; Sat, 28 Feb 2015 15:24:34 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id gq1so25057277obb.2 for ; Sat, 28 Feb 2015 15:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BazEtZY7+Drj13v7UilR6V+RFTSFhbunDh6HLYFyd9A=; b=fMHYHZtKzxQz/K6wdJXAr9PfUBUkZOau0qqpP6pOivA2xRs4RYkY88ppdYw2oUrxP9 K+d6L4R8Ew5jXiF+Q3DAW5ym+ZIcxBo0ocHYiTZSLUgmJ2MjJAGgorarUK+hVLcsy4gn dWOZW1SywPEKAxzWKhnLQ7xK/FD8h09lMsxdoy603sELl4qUCjnf4yztOuLQb67oyOwR 9xHKx1MQWxPfz+a7HJPsAIPqFtoRt8WUZvRd3PLDAXI8OsKwhQTbmClyFODfGEvSGycN RQYyXYS3IPZ5MzXYf+9LjZxP9wwXVRCQfKCHmkvGzWTOBvyWJYkYn4+9VeZcMrrgDoBc CjTQ== MIME-Version: 1.0 X-Received: by 10.182.60.197 with SMTP id j5mr14610941obr.85.1425165873391; Sat, 28 Feb 2015 15:24:33 -0800 (PST) Received: by 10.202.225.135 with HTTP; Sat, 28 Feb 2015 15:24:33 -0800 (PST) In-Reply-To: <20150228232159.15083.45367.idtracker@ietfa.amsl.com> References: <20150228232159.15083.45367.idtracker@ietfa.amsl.com> Date: Sat, 28 Feb 2015 15:24:33 -0800 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-01.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 Feb 2015 23:24:35 -0000 On 28 February 2015 at 15:21, wrote: > Filename : draft-ietf-rtcweb-alpn-01.txt Nothing new, I just changed the year to 2015.