From nobody Sat Mar 1 08:47:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95591A0214 for ; Sat, 1 Mar 2014 08:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 EirWpUm_fnQW for ; Sat, 1 Mar 2014 08:47:14 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 823C01A00A6 for ; Sat, 1 Mar 2014 08:47:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id AB06D7C4E75; Sat, 1 Mar 2014 17:47:11 +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 LvKJXpsRa7-J; Sat, 1 Mar 2014 17:47:10 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id E63A87C4E2C; Sat, 1 Mar 2014 17:47:10 +0100 (CET) Message-ID: <53120F0E.4020703@alvestrand.no> Date: Sat, 01 Mar 2014 17:47:10 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Magnus Westerlund , rtcweb@ietf.org References: <530320F7.4090300@ericsson.com> <5303E578.3000207@alvestrand.no> <53046842.2010108@ericsson.com> <5304F3E0.1020206@alvestrand.no> <530C6F3C.1090709@ericsson.com> In-Reply-To: <530C6F3C.1090709@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/I3O9-fonilpkpr-hXKITiD9Up2E Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 16:47:17 -0000 On 02/25/2014 11:23 AM, Magnus Westerlund wrote: > On 2014-02-19 19:11, Harald Alvestrand wrote: >> On 02/19/2014 09:16 AM, Magnus Westerlund wrote: >>> On 2014-02-18 23:58, Harald Alvestrand wrote: >>>> I may be a little simple-minded, but if we have a recommendation that >>>> receivers MUST be able to receive all packetizations of G.711 and OPUS >>>> up to 200 ms per packet, and that receivers should signal this by >>>> sending "a=maxptime:200" in their SDP, what situations exist where >>>> interoperability is not going to be achieved? >>> Interoperability is going to be achieve in the direction towards this >>> endpoint. The question is if we achieve interoperability in the >>> direction from that endpoint. >> So, given that there is nothing in the G.711 specification about which >> sample sizes a G.711 receiver has to support - the right approach seems >> to be to amend the G.711 MIME registration with this information. > Yes, it would for the future. But considering the wide-spread deployment > of this payload format I don't see that having any short term effect on > the interoperability. > > Also, the recommendations are actually context dependent. Thus, it is > not obvious that a single recommendation is suitable. > >> This is not a WebRTC issue; it is an absence of specification for the >> non-WebRTC devices that use G.711. The RTCWEB specifications can >> reasonably be expected to point to existing information about this >> issue; it is not reasonable (in my mind) that the RTCWEB WG decide what >> these values should be. >> > I would argue for this consideration based on that this is done in the > WebRTC context, not any other context. For which value of "this" is that true? All other contexts that use G.711 send packets with a certain ptime (which determines the number of samples per packet). It seems that all other contexts have managed to survive without a specification of which ptime it makes sense to send, except for an upper bound (maxptime). When this situation occurs, usually one of two things is happening: - There's an agreement not captured in the standard, which all participants follow. - The choice doesn't matter for interoperability. If the second is the case, I think the RTCWEB specification needs to say nothing. If the first is the case, the agreement not captured in the standard needs to be captured in a standard. But this is not an RTCWEB standard. Harald From nobody Sun Mar 2 01:38:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A751A0C13 for ; Sun, 2 Mar 2014 01:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 OGzs7oEVbZkQ for ; Sun, 2 Mar 2014 01:38:26 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABFC1A0C1C for ; Sun, 2 Mar 2014 01:38:26 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1513 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WK2ql-000E4p-E3 for rtcweb@ietf.org; Sun, 02 Mar 2014 03:38:23 -0600 Message-ID: <5312FBBC.5080006@jesup.org> Date: Sun, 02 Mar 2014 04:37:00 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> In-Reply-To: <530D9CC5.5080508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2_wNYQcgq7Bei7I7hfo7fd2CJiY Subject: Re: [rtcweb] Open data channel issues 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, 02 Mar 2014 09:38:30 -0000 On 2/26/2014 2:50 AM, Magnus Westerlund wrote: > Thanks Michael, > > WG, please consider these open issues and try to form your own position > on them. They are intended to be discussed at the meeting. If you have > proposals on how to resolve them or other input you are very welcome to > provide that on the list. One more big issue. I realize this is very late for pre-meeting discussion; I'd hoped to hash this out earlier but for various reasons (including power outages and my own workload) this didn't happen. We discussed a way to deal with the issues surrounding maximum message sizes at the last IETF. Right now we have a proposal in the MMUSIC draft for limiting the maximum message size via the SDP. There is a problem with this: it's at odds with the definition of DataChannels in the W3 and with the "duck-typing" of DataChannels to work largely as a superset of WebSockets (outside of channel creation), and the WebAPI folk at Mozilla I talked to don't like the direction we're taking. I've been having talks with the WebAPI people at Mozilla, in particular Jonas Sicking, our WebAPI lead, and they strongly dislike encouraging applications to try to implement their large-data/blob transfer protocols; browsers have considerably more tools available to them to avoid memory hits and to make use of off-main-thread resources than the JS apps do. "Having Send(blob) fail for any size of blob is crazy and non-sensical" was one comment made when I described the impacts of the current plan. Manual chunking in the application means poorly-implemented congestion control in the app to keep the channel running efficiently (the only feedback available directly is either having the far-end ack at the user level, or trying to estimate sleep times via setTimeout() and bufferedAmount() (which is simply not a great solution), or simply dumping a large amount of smaller transfers into Send() and causing the browser to have to buffer them in memory). Also GC or other pauses in JS execution may cause hiccups in the transfer and mis-estimation of available bandwidth. And of course this is being run over a congestion-controlled channel in the first place. Unless and until the W3 side makes DataChannels (and by extension, PeerConnection) APIs available from JS workers (and this is implemented), there will be compromises with packet-level protocols in JS. One of those will be "it's hard to implement your own congestion control well". Even with worker support, considerable extension of the APIs would be needed to make it work really well there. I'll also note that DataChannels-from-worker support is nowhere near implementation in browsers. Another BIG problem as it's currently defined is that there's no lower bound for this limit, so all DataChannel users will need to implement manual chunking even if they use small fixed messages to guarantee spec compliance. Of course they won't do so... and even if they did, they wouldn't test it (another big problem). You might say "ok, fine, lets set some small lower bound on this value, say 2 or 4 or 16K". That doesn't really help much either. Many will send variable-sized messages (because it's easy), and again won't test what happens when the messages trip over the spec limit (or the actual browser implementation limit!) Those with fixed-size messages larger than the spec lower-bound won't test the against that; they'll test against what Firefox and Chrome implement at the moment. So the net result is they'll ship applications that can break randomly in the field for no obvious reason (say if IE implements and uses 16K when Chrome used 32K and Firefox used 100MB). Why hand the application a footgun? Jonas Sicking suggested if the IETF insists on not supporting arbitrary Send(blob), we'll need to push in the W3 for a W3 protocol run on top of IETF DataChannels that handles fragmentation and reassembly in order to preserve the JS API for Send(). We can do this, but part of the whole partnership between the IETF and W3 on WebRTC was to try to avoid having the W3 define network protocols and keep them in the IETF where they belong. Note: abandoning Send(blob) in W3 doesn't help much, as the comments I made above about arbitrary limits and almost-certain lack of testing of messages violating the negotiated size would still apply. Send(blob) just makes it easier to trip over the problem (and in fact more likely that the application will test very large sizes). Our options are: A) Just accept this complexity and just hope that people write good code or use good libraries. (See above about testing...) Note: we'd need to set *some* lower bound for the value. B) Make the W3 API implementation add a level of protocol on top of the underlying IETF network protocol. This protocol could then deal with fragmenting messages on the sending side and reassembling them on the receiving side. C) Convince IETF WG to support arbitrarily sized messages at a protocol level, at least in the WebRTC context, similar to WebSockets. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Sun Mar 2 13:28:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D999B1A0AEC for ; Sun, 2 Mar 2014 13:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 jgshKHg4jHst for ; Sun, 2 Mar 2014 13:28:04 -0800 (PST) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BB4221A0AB9 for ; Sun, 2 Mar 2014 13:28:03 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id oz11so1953811veb.20 for ; Sun, 02 Mar 2014 13:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oX/k6GaIEqvcxyVacLoT3r92HcT7XYT+hxYpYX4OSf4=; b=V6mT7lj9G8hjg1ywI3NKkzel1MvlGqto1WIIt7QcylNQc5RWF0nlcXmF40UypLQ/4d wrzm201M+Ct7fwVLY9qgpwsLRtjfrTxD5AzCjNYEfu8lve6uqtEGYT9PpmumP5tG5ipd 24cmxapu2gmojCu7FLdCPN7ikAT8X7580xDBc3L2P36qgRLHS4sRVUl4mDlPMFcBNR9X LzSjNtYrY3tO8qYpgBbZtkadKTo6g/PQtAtLZfVgxd6/BZ6orz/2U14gGR/ZipyY6c7l aa4fh0ZubUi5rh6+dGdiMOBLWy7myyOoIPB8vUykl60pF5gfBZviVNE2iZ6wG3L09uJ0 +kXw== 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=oX/k6GaIEqvcxyVacLoT3r92HcT7XYT+hxYpYX4OSf4=; b=dUycEH8sLuANomz+toXyzxrp6oUfNUYajbhrhlZ9+NJgYRMJvy7MQOv1ct9zgiox+D UY4NhfZkslZOh0L2kdDCmreAkNUnlIQptQOpEvBtVyYycYpi4sggFU6zpcfeqiBtm3Bp iz/ziv23rxF3d3HGjHzM1TVsQ4f2wGNi/1z/rfuQld7Dkty2sZayi2E5uh/BtSNehhvm ZQLjSKqUp5FFVJA6DShxfZbve2UKh8DK6n9m7FHTxsvC+7SimOP1Zkk4S8Z/42JIJn/f 7p5P6IYX0q2BoRSeDoq91RAIv+bo+dbsMJsTQkt5xC+Xpb9LoGx7nH0i5vvv7Iow2Szm 55FQ== X-Gm-Message-State: ALoCoQk+V5cdO6CTU7CXZn/h3roMRmRFL8FEcKs99I+UXQwNQpSHe72OZDdg8PM8V4uNA6a+oMWziULVVH8BC7VsprAUKUphebrJQm7YB8o3ZN5+Z05qE5lLbTOrQC+UOK8+bu2Puw0EriFZa9f15mx9AFySol4EZBWbL736N8HUCrWoIrX5C5hjw2dBdXx0PBaqOXf/TkvM X-Received: by 10.58.190.99 with SMTP id gp3mr1079425vec.32.1393795680736; Sun, 02 Mar 2014 13:28:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Sun, 2 Mar 2014 13:27:40 -0800 (PST) In-Reply-To: <5312FBBC.5080006@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> From: Justin Uberti Date: Sun, 2 Mar 2014 13:27:40 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=047d7b675bf070f99404f3a65894 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cJTkaAbgdCTUg4sg97tjCrFVvLo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 02 Mar 2014 21:28:08 -0000 --047d7b675bf070f99404f3a65894 Content-Type: text/plain; charset=UTF-8 I'm not sure I understand the actual problem here. We *are* going to handle arbitrary-sized messages once ndata gets done. The max-msg-size stuff is just a solution until ndata is deployed. (To cite your options, this is A followed by C). That said, Send(blob) seems like a bit of a footgun to me anyway; I think apps are going to typically avoid it, a) to avoid memory bloat, and b) to get progress indications. The only way out of that situation is to provide stream semantics, which seems like a lot to take on given that WebSockets hasn't gone that route. I also agree that we shouldn't try to go the (B) route that you mention. So I still think manual chunking seems like a reasonable thing to support. I don't quite get the congestion control concerns; just because there is a max chunk size doesn't mean the impl can't buffer multiple chunks in bufferedAmount; the app could let that fill up to a degree to avoid having to poll constantly to prevent underrun. On Sun, Mar 2, 2014 at 1:37 AM, Randell Jesup wrote: > On 2/26/2014 2:50 AM, Magnus Westerlund wrote: > >> Thanks Michael, >> >> WG, please consider these open issues and try to form your own position >> on them. They are intended to be discussed at the meeting. If you have >> proposals on how to resolve them or other input you are very welcome to >> provide that on the list. >> > > One more big issue. I realize this is very late for pre-meeting > discussion; I'd hoped to hash this out earlier but for various reasons > (including power outages and my own workload) this didn't happen. > > > We discussed a way to deal with the issues surrounding maximum message > sizes at the last IETF. Right now we have a proposal in the MMUSIC draft > for limiting the maximum message size via the SDP. > > There is a problem with this: it's at odds with the definition of > DataChannels in the W3 and with the "duck-typing" of DataChannels to work > largely as a superset of WebSockets (outside of channel creation), and the > WebAPI folk at Mozilla I talked to don't like the direction we're taking. > > I've been having talks with the WebAPI people at Mozilla, in particular > Jonas Sicking, our WebAPI lead, and they strongly dislike encouraging > applications to try to implement their large-data/blob transfer protocols; > browsers have considerably more tools available to them to avoid memory > hits and to make use of off-main-thread resources than the JS apps do. > "Having Send(blob) fail for any size of blob is crazy and non-sensical" > was one comment made when I described the impacts of the current plan. > > > Manual chunking in the application means poorly-implemented congestion > control in the app to keep the channel running efficiently (the only > feedback available directly is either having the far-end ack at the user > level, or trying to estimate sleep times via setTimeout() and > bufferedAmount() (which is simply not a great solution), or simply dumping > a large amount of smaller transfers into Send() and causing the browser to > have to buffer them in memory). Also GC or other pauses in JS execution > may cause hiccups in the transfer and mis-estimation of available > bandwidth. And of course this is being run over a congestion-controlled > channel in the first place. > > Unless and until the W3 side makes DataChannels (and by extension, > PeerConnection) APIs available from JS workers (and this is implemented), > there will be compromises with packet-level protocols in JS. One of those > will be "it's hard to implement your own congestion control well". Even > with worker support, considerable extension of the APIs would be needed to > make it work really well there. I'll also note that > DataChannels-from-worker support is nowhere near implementation in browsers. > > > Another BIG problem as it's currently defined is that there's no lower > bound for this limit, so all DataChannel users will need to implement > manual chunking even if they use small fixed messages to guarantee spec > compliance. Of course they won't do so... and even if they did, they > wouldn't test it (another big problem). You might say "ok, fine, lets set > some small lower bound on this value, say 2 or 4 or 16K". That doesn't > really help much either. Many will send variable-sized messages (because > it's easy), and again won't test what happens when the messages trip over > the spec limit (or the actual browser implementation limit!) Those with > fixed-size messages larger than the spec lower-bound won't test the against > that; they'll test against what Firefox and Chrome implement at the moment. > So the net result is they'll ship applications that can break randomly in > the field for no obvious reason (say if IE implements and uses 16K when > Chrome used 32K and Firefox used 100MB). > > Why hand the application a footgun? > > > Jonas Sicking suggested if the IETF insists on not supporting arbitrary > Send(blob), we'll need to push in the W3 for a W3 protocol run on top of > IETF DataChannels that handles fragmentation and reassembly in order to > preserve the JS API for Send(). We can do this, but part of the whole > partnership between the IETF and W3 on WebRTC was to try to avoid having > the W3 define network protocols and keep them in the IETF where they belong. > > Note: abandoning Send(blob) in W3 doesn't help much, as the comments I > made above about arbitrary limits and almost-certain lack of testing of > messages violating the negotiated size would still apply. Send(blob) just > makes it easier to trip over the problem (and in fact more likely that the > application will test very large sizes). > > > Our options are: > > A) Just accept this complexity and just hope that people write good code > or use good libraries. (See above about testing...) > Note: we'd need to set *some* lower bound for the value. > > B) Make the W3 API implementation add a level of protocol on top of the > underlying IETF network protocol. This protocol could then deal with > fragmenting messages on the sending side and reassembling them on the > receiving side. > > C) Convince IETF WG to support arbitrarily sized messages at a protocol > level, at least in the WebRTC context, similar to WebSockets. > > > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b675bf070f99404f3a65894 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure I understand the actual problem here. We = *are* going to handle arbitrary-sized messages once ndata gets done. The ma= x-msg-size stuff is just a solution until ndata is deployed. (To cite your = options, this is A followed by C).

That said, Send(blob) seems like a bit of a footgun to me an= yway; I think apps are going to typically avoid it, a) to avoid memory bloa= t, and b) to get progress indications. The only way out of that situation i= s to provide stream semantics, which seems like a lot to take on given that= WebSockets hasn't gone that route. I also agree that we shouldn't = try to go the (B) route that you mention.

So I still think manual chunking seems like a reasonabl= e thing to support. I don't quite get the congestion control concerns; = just because there is a max chunk size doesn't mean the impl can't = buffer multiple chunks in bufferedAmount; the app could let that fill up to= a degree to avoid having to poll constantly to prevent underrun.


On Sun,= Mar 2, 2014 at 1:37 AM, Randell Jesup <randell-ietf@jesup.org>= ; wrote:
On 2/26/2014 2:50 AM, Magnus= Westerlund wrote:
Thanks Michael,

WG, please consider these open issues and try to form your own position
on them. They are intended to be discussed at the meeting. If you have
proposals on how to resolve them or other input you are very welcome to
provide that on the list.

One more big issue. =C2=A0I realize this is very late for pre-meeting discu= ssion; I'd hoped to hash this out earlier but for various reasons (incl= uding power outages and my own workload) this didn't happen.


We discussed a way to deal with the issues surrounding maximum message size= s at the last IETF. =C2=A0Right now we have a proposal in the MMUSIC draft = for limiting the maximum message size via the SDP.

There is a problem with this: it's at odds with the definition of DataC= hannels in the W3 and with the "duck-typing" of DataChannels to w= ork largely as a superset of WebSockets (outside of channel creation), and = the WebAPI folk at Mozilla I talked to don't like the direction we'= re taking.

I've been having talks with the WebAPI people at Mozilla, in particular= Jonas Sicking, our WebAPI lead, and they strongly dislike encouraging appl= ications to try to implement their large-data/blob transfer protocols; brow= sers have considerably more tools available to them to avoid memory hits an= d to make use of off-main-thread resources than the JS apps do. =C2=A0"= ;Having Send(blob) fail for any size of blob is crazy and non-sensical"= ; was one comment made when I described the impacts of the current plan.

Manual chunking in the application means poorly-implemented congestion cont= rol in the app to keep the channel running efficiently (the only feedback a= vailable directly is either having the far-end ack at the user level, or tr= ying to estimate sleep times via setTimeout() and bufferedAmount() (which i= s simply not a great solution), or simply dumping a large amount of smaller= transfers into Send() and causing the browser to have to buffer them in me= mory). =C2=A0Also GC or other pauses in JS execution may cause hiccups in t= he transfer and mis-estimation of available bandwidth. =C2=A0And of course = this is being run over a congestion-controlled channel in the first place.<= br>
Unless and until the W3 side makes DataChannels (and by extension, PeerConn= ection) APIs available from JS workers (and this is implemented), there wil= l be compromises with packet-level protocols in JS. =C2=A0One of those will= be "it's hard to implement your own congestion control well"= . =C2=A0Even with worker support, considerable extension of the APIs would = be needed to make it work really well there. =C2=A0I'll also note that = DataChannels-from-worker support is nowhere near implementation in browsers= .


Another BIG problem as it's currently defined is that there's no lo= wer bound for this limit, so all DataChannel users will need to implement m= anual chunking even if they use small fixed messages to guarantee spec comp= liance. =C2=A0Of course they won't do so... =C2=A0and even if they did,= they wouldn't test it (another big problem). =C2=A0You might say "= ;ok, fine, lets set some small lower bound on this value, say 2 or 4 or 16K= ". =C2=A0That doesn't really help much either. =C2=A0Many will sen= d variable-sized messages (because it's easy), and again won't test= what happens when the messages trip over the spec limit (or the actual bro= wser implementation limit!) =C2=A0Those with fixed-size messages larger tha= n the spec lower-bound won't test the against that; they'll test ag= ainst what Firefox and Chrome implement at the moment. =C2=A0So the net res= ult is they'll ship applications that can break randomly in the field f= or no obvious reason (say if IE implements and uses 16K when Chrome used 32= K and Firefox used 100MB).

Why hand the application a footgun?


Jonas Sicking suggested if the IETF insists on not supporting arbitrary Sen= d(blob), we'll need to push in the W3 for a W3 protocol run on top of I= ETF DataChannels that handles fragmentation and reassembly in order to pres= erve the JS API for Send(). =C2=A0We can do this, but part of the whole par= tnership between the IETF and W3 on WebRTC was to try to avoid having the W= 3 define network protocols and keep them in the IETF where they belong.

Note: abandoning Send(blob) in W3 doesn't help much, as the comments I = made above about arbitrary limits and almost-certain lack of testing of mes= sages violating the negotiated size would still apply. =C2=A0Send(blob) jus= t makes it easier to trip over the problem (and in fact more likely that th= e application will test very large sizes).


Our options are:

A) Just accept this complexity and just hope that people write good code or= use good libraries. (See above about testing...)
Note: we'd need to set *some* lower bound for the value.

B) Make the W3 API implementation add a level of protocol on top of the und= erlying IETF network protocol. This protocol could then deal with fragmenti= ng messages on the sending side and reassembling them on the receiving side= .

C) Convince IETF WG to support arbitrarily sized messages at a protocol lev= el, at least in the WebRTC context, similar to WebSockets.



--
Randell Jesup -- rjesup a t mozilla d o t com

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

--047d7b675bf070f99404f3a65894-- From nobody Sun Mar 2 13:34:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E971A0B08 for ; Sun, 2 Mar 2014 13:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 brpxpcrcnTNX for ; Sun, 2 Mar 2014 13:34:37 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 01CC01A0B29 for ; Sun, 2 Mar 2014 13:34:25 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id ij19so2804833vcb.6 for ; Sun, 02 Mar 2014 13:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=wVlJrUDuPXjGGQrN7he3r8Dk4eIeLJwAvlHj1A4k84w=; b=Ooaszfkv795LkvYy+RAYG49Lpu89dfSzZEkxHcsw2ra+TGVMnERHKRLc7akgt/gfMj w6X7S8+SecIF0omvDyiZ4f35kP2KjIIC3z5mEm87Jb563SlOxJwd49n3EBEIvfhEQt2R 33MHgLPaPyiVpE2ZgOFqh6d8pgbLubtA+zaXj6eOSNmOzl7Hw/+16tQ3hGrkbRl+fCoO XLDAOMnDIVZaGrwlWDPpri3up83qCsZSmFgB8Denb9ghCUMKkaeyNKPPkrTh7vtASG6S AZqE3g3AOPsW7t0C0Im4WjdEDpbN4aTqTJ6Ynq099P0Nuxz/F/iF1FrX/KR8/bk9+AZL SIFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=wVlJrUDuPXjGGQrN7he3r8Dk4eIeLJwAvlHj1A4k84w=; b=VjY+infhaDfzWseIo2If3PNjOCd71Z/32b9yfl5BBsduSVhyRMUhSWb1y31+Cf2G0q xnfEXZL19vD8EHeWNoEzrY/UgnpcfOpsX1LBdLHFvOSQ53JGspB1B50n3gs4U4WNRydZ zX2Xthxv74T9dt7EWcwqJ7+lpcyMq4RS84Ks56/utGGZd98l/wZ83o1ivwUJwrfvEULg 3aftt+M4miXJJaY4iED8smfPNYBIBTN6fOzBTLXWElAUFPuQC2J8nJlQaLbqVEFjjPq8 jJIiVgo5xDl9X+LzG8mkulPkKyx+5/UxUUV+jaoEl5NNJEUk9y9hFNUWUZRyLGsqXSKY kT8A== X-Gm-Message-State: ALoCoQlYteGpJIDmKbx9UNOwFCBkDrwYPWlKXBd/EIo1RjvjV/m+Qi4XF72oaAwZeIy/gGb4J9UI5CmJel7i3WcXrTJOShb97UJ5W/ufEW/x0/AP7EyiB8q7TmoVxUZKVvX4FW+O15zerFOy+CTDU9uycN9UKeqMw8qiSIivrXb4Vw1CJWSFkk3rf684NuSliMyKYRhonlRi X-Received: by 10.220.147.16 with SMTP id j16mr3878607vcv.28.1393796063025; Sun, 02 Mar 2014 13:34:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Sun, 2 Mar 2014 13:34:02 -0800 (PST) From: Justin Uberti Date: Sun, 2 Mar 2014 13:34:02 -0800 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=047d7b3436d239f47604f3a66fef Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ruFRIocbkSsVaL7GjV_N_y-q9u0 Cc: "rtcweb@ietf.org" Subject: [rtcweb] Proxy browsing (Was: Open data channel issues) 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, 02 Mar 2014 21:34:44 -0000 --047d7b3436d239f47604f3a66fef Content-Type: text/plain; charset=UTF-8 Can you explain more about the specific issue for "U-C 7: Proxy browsing"? (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-3.2) There are existing implementations that do this exact thing, so I don't know if anything needs to be done on our side to support this. On Tue, Feb 25, 2014 at 3:44 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > Dear all, > > Magnus asked me to send a list of open issues regarding data channels > to the list. Here is my current list: > > > * Priority > The W3C hasn't defined it yet. Neither for the (S)RTP media nor for the > data channels. We agreed on using a non strict policy for the data > channels > (some sort of wighted fair queueing). That is all. > > * Protocol > It seems not to be clear what needs to be provided when registering a > (sub)-protocol at IANA. And the name of the registry is unclear... > > * SCTP parameters. > There was discussed the issue how to set SCTP parameters, especially > path.max.retrans > and association.max.retrans. Also HB.Interval might be of interest. > RFC 4060 recommends path.max.retrans=5, association.max.retrans=10, but > has multihoming > in mind. To avoid the dormant state, path.max.retrans = > association.max.retrans should be used. > I would suggest 10 for this value. Should HEARTBEATs be disabled? > > * U-C 7: Proxy browsing > > * Alternate CC for SCTP > Currently there is only the standard CC. However, in some places > negotiation of CC is > mentioned. > > I'm currently going through the backlog of comments regarding the data > channels > ID and I'll try to address the issues. If I find other issues, I send an > update > to the above list. > > Best regards > Michael > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b3436d239f47604f3a66fef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you explain more about the specific issue for "U-= C 7: Proxy browsing"? =C2=A0

There are existing implementations that do this exact t= hing, so I don't know if anything needs to be done on our side to suppo= rt this.

On Tu= e, Feb 25, 2014 at 3:44 PM, Michael Tuexen <Michael.Tuexen@= lurchi.franken.de> wrote:
Dear all,

Magnus asked me to send a list of open issues regarding data channels
to the list. Here is my current list:


* Priority
=C2=A0 The W3C hasn't defined it yet. Neither for the (S)RTP media nor = for the
=C2=A0 data channels. We agreed on using a non strict policy for the data c= hannels
=C2=A0 (some sort of wighted fair queueing). That is all.

* Protocol
=C2=A0 It seems not to be clear what needs to be provided when registering = a
=C2=A0 (sub)-protocol at IANA. And the name of the registry is unclear...
* SCTP parameters.
=C2=A0 There was discussed the issue how to set SCTP parameters, especially= path.max.retrans
=C2=A0 and association.max.retrans. Also HB.Interval might be of interest.<= br> =C2=A0 RFC 4060 recommends path.max.retrans=3D5, association.max.retrans=3D= 10, but has multihoming
=C2=A0 in mind. To avoid the dormant state, path.max.retrans =3D associatio= n.max.retrans should be used.
=C2=A0 I would suggest 10 for this value. Should HEARTBEATs be disabled?
* U-C 7: Proxy browsing

* Alternate CC for SCTP
=C2=A0 Currently there is only the standard CC. However, in some places neg= otiation of CC is
=C2=A0 mentioned.

I'm currently going through the backlog of comments regarding the data = channels
ID and I'll try to address the issues. If I find other issues, I send a= n update
to the above list.

Best regards
Michael


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

--047d7b3436d239f47604f3a66fef-- From nobody Sun Mar 2 13:41:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7771A0B08 for ; Sun, 2 Mar 2014 13:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 4CzfHMBRm7EX for ; Sun, 2 Mar 2014 13:41:35 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8AE1A0A3D for ; Sun, 2 Mar 2014 13:41:35 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id pa12so2949644veb.0 for ; Sun, 02 Mar 2014 13:41:32 -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=HIBUfqWuGxfCAYzF5nb7pUaI84yKY4n5pgWMQR80tCg=; b=L4IFzVk71TnUW7hnkPiojfZynOHIPkjqG7w/0zs5pY9cRM7mFkMXJMUuWUW57crfx8 iNjkhr7p6rV/kAmITdej8EHCfok5lsjcCjWASfst89ZN80wJxyrB2OJ0nanh+dTJsV69 S2HOZ9ZJFBOPJGjlvtipzzrLYrJe/5yQ/QKZbJBDiDeQQ2ZgU4ZNKEf8QR/qNHrtiwUa 9fDybEHGHmpi9zplrp1dORtHy9hK8eYHVJL0Q4sxpP4g2jl8z/NZeigxcSrek1RQdzB5 xgzcVaeXyZTB3yvuRJSfoIq0Xs5xzxsxgncUIawtuMBF6C8FoiMJCARQlZJwuCSC77BS qRkQ== 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=HIBUfqWuGxfCAYzF5nb7pUaI84yKY4n5pgWMQR80tCg=; b=deDlo7FPV5AaLMP0qsxt2KF5AuwJANx+OLblA3dzskM4YmUEN+iRIPdGeaP9uR166/ LYXMQFkmQ3BvH3mPqzMxqBglVRZJjnXhjWeapNL3tP53K3Cz2/u5m9XOM4TDYtSPCsJT OV+/tYNm11aCLXNYPbk1dOPu7NxYfLqIQvgVVMuHkxwkEm/it8PZjvAhE4VsaP/d4Ppq I/BiZMzTX8OKzMYdZi4VvtusZtQKYhwfEfzn91z3QoN0SLiGsSQb7xnTl7VoFiMjRP99 x9if1j/kEQtI4l5zEJ8W5wGCQ2PYiETzpLJdvpleldBw+oAtk/T5NjMOvhxGWowuCOSz N3Jg== X-Gm-Message-State: ALoCoQlP5w8fyF746E6O0HW+nQoiNjeC8iG1Ihm44uKAhL+gAbPVf8QRWgN211uoZvMTkqZBhETJ1339DVdbEqu+6fG6LmvtynTaMS2NFi/KTGzcuTm1RUiAkb9a71W1RLxvASSXsw+GhD+xMIYJonIVdnipbGlIKc2EY6YpjS9ZOVa+FPG8udZY4txjmFrrg6hQnz584zYy X-Received: by 10.220.133.80 with SMTP id e16mr14165819vct.13.1393796492518; Sun, 02 Mar 2014 13:41:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Sun, 2 Mar 2014 13:41:12 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B5588@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5588@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 2 Mar 2014 13:41:12 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11362cd4d392bf04f3a68819 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6nYZlcrBgJhsTXwIu3SNKSJA-Js Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy 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, 02 Mar 2014 21:41:37 -0000 --001a11362cd4d392bf04f3a68819 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 24, 2014 at 9:02 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> Section 4.1.1. defines, for the PeerConnection constructor, the > possibility to specify BUNDLE policy. > >> > >> However, I am missing the possibility to indicate whether, within a > BUNDLE group, the same port number shall be used or not. > >> > >> Section 5.2.1 does say: > >> > >> "o The port value is set to the port of the default ICE > candidate for > >> this m= section; if this m= section is not being bundled into > >> another m= section, the port value MUST be unique." > >> > >> ...but, it doesn't talk about the case when the port IS being bundled > into another m= section. Normally, in the initial Offer, the port value > will be > >> unique also in that case, but if the PeerConnection is created due to > forking, and it is known that the remote peer supports BUNDLE, then > >> identical port values can be used already in the initial offer. > > > > If a m= section is being bundled into another m= section, then the port > number must be the same, as indicated in the BUNDLE WG draft. > > Before it is known whether the remote peer supports BUNDLE, each m= line > must have a unique port number. > Agreed. Setting aside BUNDLE-only for now, the implementation knows in the first offer that BUNDLE may not be supported and will use a unique port number for m= lines in the initial offer. > > > I did not include a policy option to force use of the same port; the > closest thing would be to use a policy of "all", which will mark all lines > except the > > first as bundle-only and achieve basically the same result, although it > would require a second offer to update the bundle-only ports. If this is a > > problem we could consider adding another policy value. > > Not sure I follow. I think the usage of bundle-only is a separate issue. > > The use-case I have in mind is where I want to guarantee interoperability, > so I'd choose the "max-compat" policy. > > However, I do need to be able to indicate whether the m= lines should have > the same port number or not (again, depending on whether the remote peer > has indicated support of BUNDLE or not). > In the typical case, you don't need to set this; the implementation knows to use unique ports in the initial offer and then can do the appropriate thing in future offers (i.e., once BUNDLE support by the remote side is known). In the case where you want to start with shared ports in the initial offer, because you know through some mechanism that the remote side supports this, the bundle-policy constraint could allow you to indicate this, i.e. that you want bundling to start immediately. I agree that a new value is needed to support this. --001a11362cd4d392bf04f3a68819 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 24, 2014 at 9:02 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi,

>> Section 4.1.1. defines, for the PeerConnection constructor, the po= ssibility to specify BUNDLE policy.
>>
>> However, I am missing the possibility to indicate whether, within = a BUNDLE group, the same port number shall be used or not.
>>
>> Section 5.2.1 does say:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "o =C2=A0The port value is set to = the port of the default ICE candidate for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 this m=3D section; if this m=3D section= is not being bundled into
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 another m=3D section, the port value MU= ST be unique."
>>
>> ...but, it doesn't talk about the case when the port IS being = bundled into another m=3D section. Normally, in the initial Offer, the port= value will be
>> unique also in that case, but if the PeerConnection is created due= to forking, and it is known that the remote peer supports BUNDLE, then
>> identical port values can be used already in the initial offer. >
> If a m=3D section is being bundled into another m=3D section, then the= port number must be the same, as indicated in the BUNDLE WG draft.=C2=A0
Before it is known whether the remote peer supports BUNDLE, each m=3D= line must have a unique port number.

A= greed. Setting aside BUNDLE-only for now, the implementation knows in the f= irst offer that BUNDLE may not be supported and will use a unique port numb= er for m=3D lines in the initial offer.

> I did not include a policy option to force use of the same port; the c= losest thing would be to use a policy of "all", which will mark a= ll lines except the
> first as bundle-only and achieve basically the same result, although i= t would require a second offer to update the bundle-only ports. If this is = a
> problem we could consider adding another policy value.

Not sure I follow. I think the usage of bundle-only is a separate iss= ue.

The use-case I have in mind is where I want to guarantee interoperability, = so I'd choose the "max-compat" policy.

However, I do need to be able to indicate whether the m=3D lines should hav= e the same port number or not (again, depending on whether the remote peer = has indicated support of BUNDLE or not).

In the typical case, you don't need to set this; the implementatio= n knows to use unique ports in the initial offer and then can do the approp= riate thing in future offers (i.e., once BUNDLE support by the remote side = is known). In the case where you want to start with shared ports in the ini= tial offer, because you know through some mechanism that the remote side su= pports this, the bundle-policy constraint could allow you to indicate this,= i.e. that you want bundling to start immediately.

I agree that a new value is needed to support this.
--001a11362cd4d392bf04f3a68819-- From nobody Sun Mar 2 13:46:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F381A0B18 for ; Sun, 2 Mar 2014 13:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 7QWwRzg9zAhQ for ; Sun, 2 Mar 2014 13:46:06 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2051A0A3D for ; Sun, 2 Mar 2014 13:46:06 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so2889879vcb.27 for ; Sun, 02 Mar 2014 13:46:03 -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=LgRKvW4J/u2RrlrnE2651lz3xaM1TjwSwkLsv0NRe/o=; b=lKAlW4fcBP5gKyi1g4AqjQReeL2KsUUq1YwBPLUKvJJTVgV7L7ZEsdDtZEa3zNAGvL 7NSbHxANk+B7XNVsMPy3rleGhcKSIW6lQQ94oMdWCdHsHCCLdsjU8a/l2Sttv8V4b16+ UEXbqLJy6jruVu5yLSfdHzxw514YcgKVFiCI+GvMwKu17Jmxc7lpAbKnB+MkhNJFd9n2 FTjy1ZBG6yh21je5hU0W5A1/ehnbWy3rrknbyG+8GfZj3LZDZE6qZ5ib0ByF+Gt+KRo8 XDIToRAqB4dPc1HGq5tZCE+OuL1t2BlC2+pc60Vjr6f3c5SO5O4bETlQjyYgxnYHub5T Um0g== 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=LgRKvW4J/u2RrlrnE2651lz3xaM1TjwSwkLsv0NRe/o=; b=ADX5fskqCpaDLhZapMsV6RK233UB+AlJwwzpxNokmEnwGHNCaVpdy9EzXKgbsWDQUe 9mnsKHgQYx8X3jRlyXzgs9TEH89Tic4pifZj4WBDOX2T0Yrd6el+KI7p2KpHfcmFWZkD Hso9zLfVkpNGqe/PcwmhXD/g3JphX61A5WYZKUeOCDpPkJlFZoOqBd30QKsuBRYV+6hs j7Rjzj6Jfc6qjCURFG8yEsGvYf0H0pSAGbvR6y+MYnXYj0QDn4Gi+zkTXVzvcxUzIfho 3+3quQnYJd5zJ5xJ7P/F16U8P72Qx/bPMg7fPw7Dtec/F4Ga1OFBdeJNvSgADFiAOpgA PCIg== X-Gm-Message-State: ALoCoQlyl5Wbl8m5R4pG8YYY12x/XgmkIica7C9LIJ0OE1yAZHHc3mLvrNK4IUQK/mST40YDh8Y0UhdjORzO9ga0Xb1Gl+bnkDSNqoRs9F9TV6S8txNpZrOgOr8IcK2tt+vk65JhirKzqmFGc3faDyMSABgDrsuzHUKD/STMuOz9PQAJ5q0bB0/dyaDAoRdaCCeTsQ7eJGOb X-Received: by 10.221.37.1 with SMTP id tc1mr1197740vcb.32.1393796763578; Sun, 02 Mar 2014 13:46:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Sun, 2 Mar 2014 13:45:43 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B597C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B597C@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 2 Mar 2014 13:45:43 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11334c38fb909904f3a6988e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F85RBHgjPwVMwrpRxTlqKmBEzEE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy questions 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, 02 Mar 2014 21:46:08 -0000 --001a11334c38fb909904f3a6988e Content-Type: text/plain; charset=UTF-8 On Mon, Feb 24, 2014 at 12:01 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> But, should the application then be able to indicate which media type > (or, even which media source) shall be considered "first"? The browser > probably has no clue? > > > > I think that Justin has proposed a way to identify tracks that should > not be bundled. I recall no objections to this [1]. I'd assume that with > only one track being marked that way, that track could be the one that gets > ports and the others not. > > > > > > [1]... though I can't find anything in the API spec, and we did have the > discussion at an IETF meeting and nowhere else. Maybe the W3C don't know > about it yet. > > JSEP-06 defines different BUNDLE policies, but they are not on per > track/m-line level. We had a discussion in Seattle (IIRC) that the "first" track could be the first one provided to AddTrack, and I think that is simplest. (This of course requires the AddTrack proposal to go through.) --001a11334c38fb909904f3a6988e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 24, 2014 at 12:01 PM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:
Hi,

>> But, should the application then be able to indicate which media t= ype (or, even which media source) shall be considered "first"? Th= e browser probably has no clue?
>
> I think that Justin has proposed a way to identify tracks that should = not be bundled. =C2=A0I recall no objections to this [1]. =C2=A0I'd ass= ume that with only one track being marked that way, that track could be the= one that gets ports and the others not.
>
>
> [1]... though I can't find anything in the API spec, and we did ha= ve the discussion at an IETF meeting and nowhere else. =C2=A0Maybe the W3C = don't know about it yet.

JSEP-06 defines different BUNDLE policies, but they are not on per tr= ack/m-line level.
=C2=A0
We had a discussion in = Seattle (IIRC) that the "first" track could be the first one prov= ided to AddTrack, and I think that is simplest. (This of course requires th= e AddTrack proposal to go through.)
--001a11334c38fb909904f3a6988e-- From nobody Sun Mar 2 13:47:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6484A1A0B28 for ; Sun, 2 Mar 2014 13:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 8SnGtWVzyEeb for ; Sun, 2 Mar 2014 13:47:12 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAD01A0B18 for ; Sun, 2 Mar 2014 13:47:12 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id cz12so2913558veb.16 for ; Sun, 02 Mar 2014 13:47:09 -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=GfCknNtErxdNLodPNxHqfSQsL+D76H5/9u/XZj1Qx2E=; b=fNKt1VPtQLIeJefOajYgNt70muzu2VEyO5Aed7DUhGFpIhV9KxbWwMfJ3IQY6qZqYj GOu10xC3pLeT3ITZ4l/K+m4oD/s/kG5dDkwcmwAcVlErmgLPlDxqVlIiHgYjThuaOjs8 DfPfH/z8iVU9/3z2x1GtJA6/jRN4XqV6kfiCTeijkhEQGliA0ROCzTWi7uMX1W2DdpOw kPFflIsZMnM5EPwKgSR9cNY0/a9Pt3lqRiE11JG5yKPHNL3ZUrwkUdMFL28Tc1BUs7yZ mG1hhWP+prE6t0jyQKZU8JAeSAKehgun3hTV1+F1i9AnG1WOvveQiJe9nuekUK3IbpZ5 7fNQ== 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=GfCknNtErxdNLodPNxHqfSQsL+D76H5/9u/XZj1Qx2E=; b=FlHC/SFygmbgx+MVmih7NqcH5cOqCbm5UUPDeoD6pBPmsdBNLKvot9yjIyjzoeq7+W MCz2LouPePHrUKa5ydvMYbxsd2kLjFDQ+ev2HjGyYbZAWDTmyoB/+eVGyfU0GRBiFuvb dGIFQNzGTM/9hMHa0SD8ifLA47f2lukOxi0XB9OXfybS1dxp27QhqWa2WmSRpybNXvJZ EH/3iRFNZ+P03eLRk/I6JEQEzugcrZdpqqQTkqUhGhuJP2GEtKVAUMcb4fvvEJourkPL ZekdEihrVJDNBQoQKhYhrIHoWvqSoro8cal9YE6jM7ZzwMC4Xoje18Tl26JAtJ3yv3OD tvqA== X-Gm-Message-State: ALoCoQk5C3NI2naAQbr0s9kGVO06u6LBbNW2bKKMikpG2JS12tRubU/3WRSbuBYuWM/rkCKl0kvNgacknoGmVp6d6wRYDCxEu/zDOxVthl5VxdeARhiykMJdwSeIx/fKqCNFNs32Ki8GHrWQFlj3zGttw62x3AC8sVuUHk4QSgTJnZU9iBjUtYjBLAlOs1tnrUdcgaQzOLnz X-Received: by 10.220.11.141 with SMTP id t13mr3993486vct.30.1393796829693; Sun, 02 Mar 2014 13:47:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Sun, 2 Mar 2014 13:46:49 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 2 Mar 2014 13:46:49 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3c970ec69ef04f3a69c95 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WB7juAQWBQbyM1oh0oYkp7FAoxs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy questions 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, 02 Mar 2014 21:47:14 -0000 --001a11c3c970ec69ef04f3a69c95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 24, 2014 at 8:54 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Section 4.1.1 says: > > > > =E2=80=9Co "max-bundle": *The application will BUNDLE all of its media s= treams* > > * on a single transport.* All streams other than the first will be > > marked as bundle-only. This policy aims to minimize candidate > > gathering and maximize multiplexing, at the cost of less > > compatibility with legacy endpoints.=E2=80=9D > > > > *Q1:* > > > > I think it would be good to clarify that the application will BUNDLE all > of its media streams **THAT THE APPLICATION IS ABLE TO DE-MULTIPLEX**. > I don't follow what you are saying here. How would a WebRTC application end up with streams it could not demultiplex? > > > *Q2:* > > > > The text says that all streams other than the first will be marked as > bundle-only. But, will the application have any clue which media type tha= t > first stream will be? Should we e.g. specify that it MUST be audio (if > audio is enabled)? > > > > Regards, > > > > Christer > --001a11c3c970ec69ef04f3a69c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 24, 2014 at 8:54 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Section 4.1.1 says:

=C2=A0

=E2=80=9Co=C2=A0 "max-bund= le": The application will BUNDLE all of its media streams=

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 on a single transport.=C2=A0 All stream= s other than the first will be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = marked as bundle-only.=C2=A0 This policy aims to minimize candidate<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = gathering and maximize multiplexing, at the cost of less

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = compatibility with legacy endpoints.=E2=80=9D

=C2=A0

Q1:

=C2=A0

I think it would be good to cla= rify that the application will BUNDLE all of its media streams *THAT THE= APPLICATION IS ABLE TO DE-MULTIPLEX*.


I don't follow what you are saying here. How would = a WebRTC application end up with streams it could not demultiplex?=C2=A0

=C2=A0

Q2:=

=C2=A0

The text says that all streams = other than the first will be marked as bundle-only. But, will the applicati= on have any clue which media type that first stream will be? Should we e.g.= specify that it MUST be audio (if audio is enabled)?

=C2=A0

Regards,=

=C2=A0

Christer


--001a11c3c970ec69ef04f3a69c95-- From nobody Sun Mar 2 13:49:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4565A1A0A3D for ; Sun, 2 Mar 2014 13:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 kelIiLhF8aAp for ; Sun, 2 Mar 2014 13:49:23 -0800 (PST) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 464211A0B1A for ; Sun, 2 Mar 2014 13:49:23 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jz11so2810187veb.25 for ; Sun, 02 Mar 2014 13:49:20 -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=ZVzqUW4dg22FnwnrD9sai+mRkTI3N4nps2XPBvq/NEU=; b=n0TUODiYOijrdyXk941qiE/j3IskFk9fdPp4bBabOTONwiqzfnGFZeIgW9DsgmmKPD dQ6TgeH0tksX5MzLzfIlbhJ1J1fa69KATKJPBDkWejEN5v22FPnVg9/OksZk9GzGGKl9 5mxKDWcvYMqbbf3qjQoliu7sGImT7NB3DPp6w7hMO8KZFMkYQ8i3JEIBopC6SSwHIE6r Glq0rXyx1aU53zYMirHAY7Bwg3SBaLh/+GA07reMtYHtmnFskH6K9N6SGtClEFn5D8MG QRjeF+l7W3jxN4m5pe+wF9HQwGaHKlWsdKhg0wuoi7Fv6GbQc8kr/Z/opAxAlf8BAu4b snjw== 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=ZVzqUW4dg22FnwnrD9sai+mRkTI3N4nps2XPBvq/NEU=; b=IcSl8qYf7eq80/xJQAXGRCHb6WwS+5cvWBM0Ai9p96yzoATuVejMqqqaXMccKvaBE4 p5XLo/qcHyp+tTsPWtxAcO2hxHB5YHF6dJlXdKiZ3kTLVJhwekG8aDOAk39SaWFknsBv qCuqn5mY6hIWK7MQGc2zi7fCyn8bvM9tzOZ4ZTj70WU7wPuj6aui/5tOhHaPOEpbabGj 88ARD91s7Nn2m14qWN9zzz97eqq4gF0l9Z1mLdckdNuA67nwtuMsjblQ3VIGmqvQ2Ndt qND60yUU+fckZzpVbOUJzG71s1rTkoe2Qu5mZAmAMYErNMIpBjyCGNaPVedyVKJ34lrk repg== X-Gm-Message-State: ALoCoQk96kWFizLzv7qRalgos4rA+gsjQjizncyqSaxy0gVzv91d9avAiXkOLCTSmNIF8SubVfNi0nSiTa01arJpy5Dqc/+2yZVwZGLQz5YmOwvt4KMehWuc7B+kCXlu1ytPl2UNM3NxtN+07VC12C12Pbp5zuhb7tlMTppavC+841TuhevrZM94OC2xmYmIEV1p30qW0+tW X-Received: by 10.220.133.80 with SMTP id e16mr14192645vct.13.1393796960431; Sun, 02 Mar 2014 13:49:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Sun, 2 Mar 2014 13:49:00 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 2 Mar 2014 13:49:00 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11362cd4b7479204f3a6a48a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vdb_7rbuG2BqJFCw9l12VFbaxaQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? 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, 02 Mar 2014 21:49:25 -0000 --001a11362cd4b7479204f3a6a48a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 24, 2014 at 9:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > As specified in BUNDLE, before the remote peer has indicated support of > BUNDLE, all m- lines (including those within to a bundle group) must have > unique port numbers. > > > > Then, when the remote peer has indicated support of BUNDLE, a second offe= r > (called the BAS offer) needs to be sent, in which the same port number is > assigned to all m- lines within a bundle group. > > > > My question is: how do I create the BAS offer? I don=E2=80=99t want to ch= ange > anything =E2=80=93 I just want to get an SDP with the BUNDLE port assigne= d to all > m- lines. Is there a flag in createOffer() for that? > > > The implementation knows that any offers that are created after the BUNDLE answer should have the same port numbers. So, the app could push the createOffer button once it receives the answer if it wanted to ensure this happened immediately. Otherwise, there will be an onnegotiationneeded event once ICE completes, and the offer sent at that time will have the updated ports. --001a11362cd4b7479204f3a6a48a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 24, 2014 at 9:07 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

As specified in BUNDLE, before = the remote peer has indicated support of BUNDLE, all m- lines (including th= ose within to a bundle group) must have unique port numbers.<= /span>

=C2=A0

Then, when the remote peer has = indicated support of BUNDLE, a second offer (called the BAS offer) needs to= be sent, in which the same port number is assigned to all m- lines within = a bundle group.

=C2=A0

My question is: how do I create= the BAS offer? I don=E2=80=99t want to change anything =E2=80=93 I just wa= nt to get an SDP with the BUNDLE port assigned to all m- lines. Is there a = flag in createOffer() for that?

=C2=A0

<= /div>
The implementation knows that any offers that are cr= eated after the BUNDLE answer should have the same port numbers. So, the ap= p could push the createOffer button once it receives the answer if it wante= d to ensure this happened immediately. Otherwise, there will be an onnegoti= ationneeded event once ICE completes, and the offer sent at that time will = have the updated ports.
--001a11362cd4b7479204f3a6a48a-- From nobody Sun Mar 2 13:59:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFAC1A0B34 for ; Sun, 2 Mar 2014 13:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Btr0ml8TgGHH for ; Sun, 2 Mar 2014 13:59:02 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C67701A0B48 for ; Sun, 2 Mar 2014 13:59:00 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id Ylhm1n0021ei1Bg51lyykC; Sun, 02 Mar 2014 21:58:58 +0000 Received: from dhcp-hotel-wifi-157-6c.meeting.ietf.org ([130.129.157.108]) by omta24.westchester.pa.mail.comcast.net with comcast id Ylwj1n00W2LcPnE3klwlwd; Sun, 02 Mar 2014 21:56:56 +0000 Message-ID: <5313A91C.2030407@alum.mit.edu> Date: Sun, 02 Mar 2014 21:56:44 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <530E4E34.4010707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> <5310B14E.4000809@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393797538; bh=mDLs93P4I8OW62UI7nMzZhDhtW0DubkRJG0wN3OwNl0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E9SbaYp8Ff8sgtM8RnhXqYkzae0cHZ9WbXqVKpJxcOn9Xdi4gUbvSKvk6wNZfYWz9 uwkgOel15YJcyZ6Y+JceKOdcLaj0hpOxJlKKfGfzrQpCGhpkbge6gKbxTG8Eu2qkLn 2h1QNaHZ+H2K0k0X4smvlJPwcBQJ9yDHBZFc/XyZe22rfE52s3tjQrAfI+bTViMfpj PaVitgd3BFNB8lQzyz9wZ/GKTZgtXxTWBw2CVz3/ghZJrZolLrEGVS+8KvcWzZP7p1 vwAR+n+fKRehsdj12HDbd/XwOfYEZxDawtJUm3DqSEIHc1mwWaCBEggVyo3/EAPBmq 3n1qvefuL+mBA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MlVLEMi80wIUYFwgPFBMYjqKHYQ Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel 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, 02 Mar 2014 21:59:04 -0000 I suspect we are not understanding one another. On 2/28/14 4:46 PM, Makaraju, Maridi Raju (Raju) wrote: > Hi Paul, > > >>>> Isn't it enough to, in the data channel protocol spec, say that the >> odd/even >>>> rule applies unless the stream id is explicitly negotiated using some >> other >>>> mechanism? >>>> >>> [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data- >> channel-sdpneg should still need to say that "when both external and DCP are >> used, even for DCP created streams the stream ids have to be specified and >> managed by the application (else DCP stack will default to odd/even rule per >> DTLS role which may conflict with SDP offer/answer rule)". >> >> Can we assume there must be a mechanism for using DCEP and still >> controlling which channels are used? > > [Raju] Yes, we can assume that and it is already supported by : > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.5 > and > http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannel-id > I believe it is safe to assume non-browser implementations of > data channel stack gives an option for application to select > stream ids independent of DCEP or external negotiation. > > >> >> It might help if the O/A negotiation also followed the even/odd rule. > [Raju] May be I am missing something here. Richard's draft already has > a specific even/odd rule for O/A. But the issue is TLS based rule may > conflict with the O/A rule as TLS roles may change depending on a=setup. > >> But there are difficulties in knowing who is even and who is odd for the >> first O/A. > > [Raju] Not related to first or subsequent O/A, but rather a conflict > between TLS roles vs. O/A. OK. I didn't state what I meant clearly, and I forgot Richard had an even/odd rule. For O/A there really isn't a need for one, since the only cases this will be a problem result in O/A glare, and that is then resolved via backoff. What I meant was it might help if the O/A proposal and DCEP followed the *same* rule. I think that is what Richard wanted. But he showed why O/A can't use the existing DCEP rule, so *that* would be required to change. >> If the offerer always creates the channel before sending the offer, then >> that will prevent the two mechanisms from stepping on one another's >> stream ids. > [Raju] > In some cases, initial offer may not have a data channel stream created. > I don't know how this can prevent stepping on each other?! > May be I am missing something here?! In most cases TLS role is > determined after O/A is completed, but offerer creates a data > channel before answer, then how does it know even/odd rule? > So, trying to use TLS role for external negotiation is problematic. For channels negotiated at the same time the SCTP association is negotiated the offerer can use *any* ids, since there can yet be no conflict. Then, once the association is established, the channels declared in the SDP need to be "opened" (activated?), independently by both sides. They will then be reserved. After that, if the application follows the DCEP even/odd rule, and creates the channel at its end before sending an offer, then that cannot conflict with channels dynamically allocated by DCEP. And both sides then understand who is even and who is odd, so there will be no conflicts by the two sides choosing the same channel. Thanks, Paul From nobody Sun Mar 2 14:14:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170591A0B4E for ; Sun, 2 Mar 2014 14:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lguGkdsjPUh6 for ; Sun, 2 Mar 2014 14:14:22 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE991A0B3B for ; Sun, 2 Mar 2014 14:14:21 -0800 (PST) Received: from [IPv6:2001:67c:1232:12:c899:bf68:34b0:468] (unknown [IPv6:2001:67c:1232:12:c899:bf68:34b0:468]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3CED71C1042F6; Sun, 2 Mar 2014 23:14:17 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Sun, 2 Mar 2014 22:14:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <19F59005-128A-426D-B169-7928C5096EAE@lurchi.franken.de> References: To: Justin Uberti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/das1sgLs2ulF4_A_Lz32lA6wZnk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proxy browsing (Was: Open data channel issues) 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, 02 Mar 2014 22:14:25 -0000 On 02 Mar 2014, at 21:34, Justin Uberti wrote: > Can you explain more about the specific issue for "U-C 7: Proxy = browsing"? =20 > = (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-3.2)= Magnus said referring to U-C 7: >>> Yes, this may be something that is possible, but to express it as a = use >>> cases intended to be supported might not be the best. We are after = all >>> likely talking about circumventing local security policies. So keep U-C 7 and describe the consequences in the security section or = remove it. I responded yo his e-mail and voted for keeping the U-C. Best regards Michael >=20 > There are existing implementations that do this exact thing, so I = don't know if anything needs to be done on our side to support this. >=20 > On Tue, Feb 25, 2014 at 3:44 PM, Michael Tuexen = wrote: > Dear all, >=20 > Magnus asked me to send a list of open issues regarding data channels > to the list. Here is my current list: >=20 >=20 > * Priority > The W3C hasn't defined it yet. Neither for the (S)RTP media nor for = the > data channels. We agreed on using a non strict policy for the data = channels > (some sort of wighted fair queueing). That is all. >=20 > * Protocol > It seems not to be clear what needs to be provided when registering = a > (sub)-protocol at IANA. And the name of the registry is unclear... >=20 > * SCTP parameters. > There was discussed the issue how to set SCTP parameters, especially = path.max.retrans > and association.max.retrans. Also HB.Interval might be of interest. > RFC 4060 recommends path.max.retrans=3D5, = association.max.retrans=3D10, but has multihoming > in mind. To avoid the dormant state, path.max.retrans =3D = association.max.retrans should be used. > I would suggest 10 for this value. Should HEARTBEATs be disabled? >=20 > * U-C 7: Proxy browsing >=20 > * Alternate CC for SCTP > Currently there is only the standard CC. However, in some places = negotiation of CC is > mentioned. >=20 > I'm currently going through the backlog of comments regarding the data = channels > ID and I'll try to address the issues. If I find other issues, I send = an update > to the above list. >=20 > Best regards > Michael >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sun Mar 2 18:43:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3A1A0C33 for ; Sun, 2 Mar 2014 18:43:52 -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 oiNXh-cBYAxM for ; Sun, 2 Mar 2014 18:43:49 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 472481A0C2E for ; Sun, 2 Mar 2014 18:43:48 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:3109 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKIr3-0008KI-Dr; Sun, 02 Mar 2014 20:43:45 -0600 Message-ID: <5313EC0D.9030808@jesup.org> Date: Sun, 02 Mar 2014 21:42:21 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040601000007030806030207" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/crAE3vzTTbv61wW6WySJtwZMbWY Cc: Michael Tuexen Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 02:43:53 -0000 This is a multi-part message in MIME format. --------------040601000007030806030207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/2/2014 4:27 PM, Justin Uberti wrote: > I'm not sure I understand the actual problem here. We *are* going to > handle arbitrary-sized messages once ndata gets done. The max-msg-size > stuff is just a solution until ndata is deployed. (To cite your > options, this is A followed by C). So, here's where I think there may be a disconnect (and if I'm wrong, great): ndata solves the monopolization issue between streams, allowing packets for different streams to be interleaved on the wire. It does not (so far as I know) relax the usrsctp library's returning EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now). Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it. So ndata will allow us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size). It does not allow us to expand the size to any useful Blob size. > > That said, Send(blob) seems like a bit of a footgun to me anyway; I > think apps are going to typically avoid it, a) to avoid memory bloat, > and b) to get progress indications. The only way out of that situation > is to provide stream semantics, which seems like a lot to take on > given that WebSockets hasn't gone that route. I also agree that we > shouldn't try to go the (B) route that you mention. Well, Streams would be a good thing once they're done. Progress indication could be added at the W3 level without much problem. The memory issue should be resolvable in a number of ways, per my discussion with Sicking. Note that application chunking has a serious memory issue today in that the File Writer API hasn't been agreed to; I think there's progress towards eventually adopting a version of the Filesystem API (with changes), but that will be a while. Again, Stream should help - and note that the semantics for Blob reception allow it to be written to disk as it's received and not held entirely in memory when it's handed to the application, which is NOT possible today for application chunking. > > So I still think manual chunking seems like a reasonable thing to > support. I don't quite get the congestion control concerns; just > because there is a max chunk size doesn't mean the impl can't buffer > multiple chunks in bufferedAmount; the app could let that fill up to a > degree to avoid having to poll constantly to prevent underrun. On a slow link this will work if the browser isn't janky. On a fast link GC pauses and other things may cause the buffer to drain out and go idle for significant periods. Randell > > > On Sun, Mar 2, 2014 at 1:37 AM, Randell Jesup > wrote: > > On 2/26/2014 2:50 AM, Magnus Westerlund wrote: > > Thanks Michael, > > WG, please consider these open issues and try to form your own > position > on them. They are intended to be discussed at the meeting. If > you have > proposals on how to resolve them or other input you are very > welcome to > provide that on the list. > > > One more big issue. I realize this is very late for pre-meeting > discussion; I'd hoped to hash this out earlier but for various > reasons (including power outages and my own workload) this didn't > happen. > > > We discussed a way to deal with the issues surrounding maximum > message sizes at the last IETF. Right now we have a proposal in > the MMUSIC draft for limiting the maximum message size via the SDP. > > There is a problem with this: it's at odds with the definition of > DataChannels in the W3 and with the "duck-typing" of DataChannels > to work largely as a superset of WebSockets (outside of channel > creation), and the WebAPI folk at Mozilla I talked to don't like > the direction we're taking. > > I've been having talks with the WebAPI people at Mozilla, in > particular Jonas Sicking, our WebAPI lead, and they strongly > dislike encouraging applications to try to implement their > large-data/blob transfer protocols; browsers have considerably > more tools available to them to avoid memory hits and to make use > of off-main-thread resources than the JS apps do. "Having > Send(blob) fail for any size of blob is crazy and non-sensical" > was one comment made when I described the impacts of the current plan. > > > Manual chunking in the application means poorly-implemented > congestion control in the app to keep the channel running > efficiently (the only feedback available directly is either having > the far-end ack at the user level, or trying to estimate sleep > times via setTimeout() and bufferedAmount() (which is simply not a > great solution), or simply dumping a large amount of smaller > transfers into Send() and causing the browser to have to buffer > them in memory). Also GC or other pauses in JS execution may > cause hiccups in the transfer and mis-estimation of available > bandwidth. And of course this is being run over a > congestion-controlled channel in the first place. > > Unless and until the W3 side makes DataChannels (and by extension, > PeerConnection) APIs available from JS workers (and this is > implemented), there will be compromises with packet-level > protocols in JS. One of those will be "it's hard to implement > your own congestion control well". Even with worker support, > considerable extension of the APIs would be needed to make it work > really well there. I'll also note that DataChannels-from-worker > support is nowhere near implementation in browsers. > > > Another BIG problem as it's currently defined is that there's no > lower bound for this limit, so all DataChannel users will need to > implement manual chunking even if they use small fixed messages to > guarantee spec compliance. Of course they won't do so... and > even if they did, they wouldn't test it (another big problem). > You might say "ok, fine, lets set some small lower bound on this > value, say 2 or 4 or 16K". That doesn't really help much either. > Many will send variable-sized messages (because it's easy), and > again won't test what happens when the messages trip over the spec > limit (or the actual browser implementation limit!) Those with > fixed-size messages larger than the spec lower-bound won't test > the against that; they'll test against what Firefox and Chrome > implement at the moment. So the net result is they'll ship > applications that can break randomly in the field for no obvious > reason (say if IE implements and uses 16K when Chrome used 32K and > Firefox used 100MB). > > Why hand the application a footgun? > > > Jonas Sicking suggested if the IETF insists on not supporting > arbitrary Send(blob), we'll need to push in the W3 for a W3 > protocol run on top of IETF DataChannels that handles > fragmentation and reassembly in order to preserve the JS API for > Send(). We can do this, but part of the whole partnership between > the IETF and W3 on WebRTC was to try to avoid having the W3 define > network protocols and keep them in the IETF where they belong. > > Note: abandoning Send(blob) in W3 doesn't help much, as the > comments I made above about arbitrary limits and almost-certain > lack of testing of messages violating the negotiated size would > still apply. Send(blob) just makes it easier to trip over the > problem (and in fact more likely that the application will test > very large sizes). > > > Our options are: > > A) Just accept this complexity and just hope that people write > good code or use good libraries. (See above about testing...) > Note: we'd need to set *some* lower bound for the value. > > B) Make the W3 API implementation add a level of protocol on top > of the underlying IETF network protocol. This protocol could then > deal with fragmenting messages on the sending side and > reassembling them on the receiving side. > > C) Convince IETF WG to support arbitrarily sized messages at a > protocol level, at least in the WebRTC context, similar to > WebSockets. > > > > -- > Randell Jesup -- rjesup a t mozilla d o t 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 -- Randell Jesup -- rjesup a t mozilla d o t com --------------040601000007030806030207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/2/2014 4:27 PM, Justin Uberti wrote:
I'm not sure I understand the actual problem here. We *are* going to handle arbitrary-sized messages once ndata gets done. The max-msg-size stuff is just a solution until ndata is deployed. (To cite your options, this is A followed by C).

So, here's where I think there may be a disconnect (and if I'm wrong, great):

ndata solves the monopolization issue between streams, allowing packets for different streams to be interleaved on the wire.  It does not (so far as I know) relax the usrsctp library's returning EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now).

Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it.  So ndata will allow us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size).  It does not allow us to expand the size to any useful Blob size.


That said, Send(blob) seems like a bit of a footgun to me anyway; I think apps are going to typically avoid it, a) to avoid memory bloat, and b) to get progress indications. The only way out of that situation is to provide stream semantics, which seems like a lot to take on given that WebSockets hasn't gone that route. I also agree that we shouldn't try to go the (B) route that you mention.

Well, Streams would be a good thing once they're done. Progress indication could be added at the W3 level without much problem.  The memory issue should be resolvable in a number of ways, per my discussion with Sicking.  Note that application chunking has a serious memory issue today in that the File Writer API hasn't been agreed to; I think there's progress towards eventually adopting a version of the Filesystem API (with changes), but that will be a while.  Again, Stream should help - and note that the semantics for Blob reception allow it to be written to disk as it's received and not held entirely in memory when it's handed to the application, which is NOT possible today for application chunking.


So I still think manual chunking seems like a reasonable thing to support. I don't quite get the congestion control concerns; just because there is a max chunk size doesn't mean the impl can't buffer multiple chunks in bufferedAmount; the app could let that fill up to a degree to avoid having to poll constantly to prevent underrun.

On a slow link this will work if the browser isn't janky.  On a fast link GC pauses and other things may cause the buffer to drain out and go idle for significant periods.

  Randell



On Sun, Mar 2, 2014 at 1:37 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 2/26/2014 2:50 AM, Magnus Westerlund wrote:
Thanks Michael,

WG, please consider these open issues and try to form your own position
on them. They are intended to be discussed at the meeting. If you have
proposals on how to resolve them or other input you are very welcome to
provide that on the list.

One more big issue.  I realize this is very late for pre-meeting discussion; I'd hoped to hash this out earlier but for various reasons (including power outages and my own workload) this didn't happen.


We discussed a way to deal with the issues surrounding maximum message sizes at the last IETF.  Right now we have a proposal in the MMUSIC draft for limiting the maximum message size via the SDP.

There is a problem with this: it's at odds with the definition of DataChannels in the W3 and with the "duck-typing" of DataChannels to work largely as a superset of WebSockets (outside of channel creation), and the WebAPI folk at Mozilla I talked to don't like the direction we're taking.

I've been having talks with the WebAPI people at Mozilla, in particular Jonas Sicking, our WebAPI lead, and they strongly dislike encouraging applications to try to implement their large-data/blob transfer protocols; browsers have considerably more tools available to them to avoid memory hits and to make use of off-main-thread resources than the JS apps do.  "Having Send(blob) fail for any size of blob is crazy and non-sensical" was one comment made when I described the impacts of the current plan.


Manual chunking in the application means poorly-implemented congestion control in the app to keep the channel running efficiently (the only feedback available directly is either having the far-end ack at the user level, or trying to estimate sleep times via setTimeout() and bufferedAmount() (which is simply not a great solution), or simply dumping a large amount of smaller transfers into Send() and causing the browser to have to buffer them in memory).  Also GC or other pauses in JS execution may cause hiccups in the transfer and mis-estimation of available bandwidth.  And of course this is being run over a congestion-controlled channel in the first place.

Unless and until the W3 side makes DataChannels (and by extension, PeerConnection) APIs available from JS workers (and this is implemented), there will be compromises with packet-level protocols in JS.  One of those will be "it's hard to implement your own congestion control well".  Even with worker support, considerable extension of the APIs would be needed to make it work really well there.  I'll also note that DataChannels-from-worker support is nowhere near implementation in browsers.


Another BIG problem as it's currently defined is that there's no lower bound for this limit, so all DataChannel users will need to implement manual chunking even if they use small fixed messages to guarantee spec compliance.  Of course they won't do so...  and even if they did, they wouldn't test it (another big problem).  You might say "ok, fine, lets set some small lower bound on this value, say 2 or 4 or 16K".  That doesn't really help much either.  Many will send variable-sized messages (because it's easy), and again won't test what happens when the messages trip over the spec limit (or the actual browser implementation limit!)  Those with fixed-size messages larger than the spec lower-bound won't test the against that; they'll test against what Firefox and Chrome implement at the moment.  So the net result is they'll ship applications that can break randomly in the field for no obvious reason (say if IE implements and uses 16K when Chrome used 32K and Firefox used 100MB).

Why hand the application a footgun?


Jonas Sicking suggested if the IETF insists on not supporting arbitrary Send(blob), we'll need to push in the W3 for a W3 protocol run on top of IETF DataChannels that handles fragmentation and reassembly in order to preserve the JS API for Send().  We can do this, but part of the whole partnership between the IETF and W3 on WebRTC was to try to avoid having the W3 define network protocols and keep them in the IETF where they belong.

Note: abandoning Send(blob) in W3 doesn't help much, as the comments I made above about arbitrary limits and almost-certain lack of testing of messages violating the negotiated size would still apply.  Send(blob) just makes it easier to trip over the problem (and in fact more likely that the application will test very large sizes).


Our options are:

A) Just accept this complexity and just hope that people write good code or use good libraries. (See above about testing...)
Note: we'd need to set *some* lower bound for the value.

B) Make the W3 API implementation add a level of protocol on top of the underlying IETF network protocol. This protocol could then deal with fragmenting messages on the sending side and reassembling them on the receiving side.

C) Convince IETF WG to support arbitrarily sized messages at a protocol level, at least in the WebRTC context, similar to WebSockets.



--
Randell Jesup -- rjesup a t mozilla d o t 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



-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------040601000007030806030207-- From nobody Sun Mar 2 22:51:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6081A0CA3 for ; Sun, 2 Mar 2014 22:51: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 vEi1DC3f31Zl for ; Sun, 2 Mar 2014 22:51:38 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF6C1A0C3D for ; Sun, 2 Mar 2014 22:51:38 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q59so2688453wes.34 for ; Sun, 02 Mar 2014 22:51:35 -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=uIWyF8GKpVQQr+MrEwVh6Py9fuy55XuQBIS8GqIPpSA=; b=C/nEhuzRhB82/z1uZpbzPd1ovayWYMovDHNSFnTRbZgTBwFYb36GumHnHb2HAu2nje ui3FOIqmZB1Nly4fuOTAJnU1om6XS2/YC49Z8HLAalIAUBNSzvLWbk1WrUHGPs536jiM 9TdWsOzMdXyxi3RQ1l4eAxR0mi6Cff/3YVC7sjL9lOTDEYa5WO+qvX3vqWUJBnGyJ2ew 7jWpkL7Qt2ItI+AecHZ+v+L0zLhVBoaJ9LlzpWiQJ8hPl1e1cdL9U5nppftPuBgT8meL qCDF3m7z6N99fe4A/deCyY4BeWaaa76CMUz4wAxx3eSyRky5lc+5VyN9VAO3YEDioGjT 7MIQ== MIME-Version: 1.0 X-Received: by 10.194.161.136 with SMTP id xs8mr4265613wjb.56.1393829495122; Sun, 02 Mar 2014 22:51:35 -0800 (PST) Received: by 10.227.10.196 with HTTP; Sun, 2 Mar 2014 22:51:35 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B597C@ESESSMB209.ericsson.se> Date: Sun, 2 Mar 2014 22:51:35 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CA_lYruGx8ckE5PuB0wRPg07c1o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy questions 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, 03 Mar 2014 06:51:40 -0000 On 2 March 2014 13:45, Justin Uberti wrote: > We had a discussion in Seattle (IIRC) that the "first" track could be the > first one provided to AddTrack, and I think that is simplest. (This of > course requires the AddTrack proposal to go through.) That's true. But then you have to decide which is first :) We could assume that the order follows what is in every example ever, but that's still an assumption. From nobody Sun Mar 2 22:57:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CCD1A0D41 for ; Sun, 2 Mar 2014 22:56:59 -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 VGysArmjlkkY for ; Sun, 2 Mar 2014 22:56:58 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B1E671A0D2F for ; Sun, 2 Mar 2014 22:56:57 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id p61so1515942wes.13 for ; Sun, 02 Mar 2014 22:56: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:date:message-id:subject:from:to :cc:content-type; bh=KmZj/5rjIyOrgyVOZvFhtZ++qC4xLoghGimVqkZagus=; b=AatjuaPdfXh9Hmdlf5eqNiFhgH7vUCEBiRD6ct1JmtzEz9bz+Q44a+8Lzr59bz515f MaolHg0LIQaMTwnCTc4bg8n45JqDEwAQxVDQ1UZrHP6zshRFo5YyjA0yGN4hiY3zUbzv r30jWJlXVBVn6cAq6iaAtVhdUFq8Q/TNx/cilyvZrb2nD2FtR/ZrO33owQ73NjSPxReE jHT4kP8EuKjl+F9r/Pv/HaEsDLYHGAlBLEKdHKtN7b5t4IDr3kjXuYNq95mz1m5tbQr1 wH4X54A7MGVazWW7j68p3cO2xwHhSoHLRydJp1MXdEgOvkXwfFXond7UsRNPe0vfoN7r dKrA== MIME-Version: 1.0 X-Received: by 10.194.170.167 with SMTP id an7mr14720281wjc.39.1393829814492; Sun, 02 Mar 2014 22:56:54 -0800 (PST) Received: by 10.227.10.196 with HTTP; Sun, 2 Mar 2014 22:56:54 -0800 (PST) In-Reply-To: <5313EC0D.9030808@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> Date: Sun, 2 Mar 2014 22:56:54 -0800 Message-ID: From: Martin Thomson To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RiHVq5oX82OXyTGWod1kT8kWaIg Cc: Michael Tuexen , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 06:56:59 -0000 On 2 March 2014 18:42, Randell Jesup wrote: > ndata solves the monopolization issue between streams, allowing packets for > different streams to be interleaved on the wire. It does not (so far as I > know) relax the usrsctp library's returning EMSGSIZE if the sendto() is > larger than available buffer space, and the alternative (EOR mode) doesn't > allow for interleaving of messages when sending at all (and I'm not sure it > allows interleaving on reception either, but I didn't check right now). > > Now, this is an implementation/API issue which could be fixed with some > work, but so far as I know no work has been done on it. So ndata will allow > us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, > other-sides-max-receive-size). It does not allow us to expand the size to > any useful Blob size. Sounds like the complaint would be best addressed by fixing the SCTP implementations. I would hope that ndata would allow for transmission of messages far in excess of what the implementation is willing to buffer, that seems arbitrarily restrictive. (A streaming API wounds like a good idea too.) From nobody Sun Mar 2 23:42:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CA31A0CA3 for ; Sun, 2 Mar 2014 22:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 BK0fyMa-bOZx for ; Sun, 2 Mar 2014 22:54:04 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 718B31A0BB8 for ; Sun, 2 Mar 2014 22:54:04 -0800 (PST) Received: from [130.129.15.249] (unknown [130.129.15.249]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DDEB71C103E6D; Mon, 3 Mar 2014 07:54:00 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5313EC0D.9030808@jesup.org> Date: Mon, 3 Mar 2014 06:53:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6C3E8CBC-9EC4-4222-8073-7D7903FEC38A@fh-muenster.de> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lgb7CgolLbG9WkLHhMbYVKAsHZQ X-Mailman-Approved-At: Sun, 02 Mar 2014 23:42:07 -0800 Cc: rtcweb@ietf.org, Randall Stewart Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 06:54:07 -0000 On 03 Mar 2014, at 02:42, Randell Jesup wrote: > On 3/2/2014 4:27 PM, Justin Uberti wrote: >> I'm not sure I understand the actual problem here. We *are* going to = handle arbitrary-sized messages once ndata gets done. The max-msg-size = stuff is just a solution until ndata is deployed. (To cite your options, = this is A followed by C). >=20 > So, here's where I think there may be a disconnect (and if I'm wrong, = great): >=20 > ndata solves the monopolization issue between streams, allowing = packets for different streams to be interleaved on the wire. It does = not (so far as I know) relax the usrsctp library's returning=20 Correct. > EMSGSIZE if the sendto() is larger than available buffer space, and = the alternative (EOR mode) doesn't allow for interleaving of messages = when sending at all (and I'm not sure it allows interleaving on = reception either, but I didn't check right now). If you want to send messages larger than the socket send buffer, you = must use the explicit EOR more. This is independent from using NDATA or not. If you use NDATA, you can have on each outgoing stream a single message = (order or unordered) being sent using explicit EOR mode and the calls can be interleaved. I = don't think I have tested this up to know, but this is how it should work. rrs@: Just to double check: Am I right? Please note that RTCWeb doesn't = use ordered and unordered on the same stream, and you don't need to send more than = one message with explicit EOR on the same stream at the same time. Therefore the = above simplification... >=20 > Now, this is an implementation/API issue which could be fixed with = some work, but so far as I know no work has been done on it. So ndata = will allow us to expand the max-sending size to=20 This API work is part of getting NDATA implemented. Randall has = implemented it, we do have code, but it needs some testing and cleaning up in the API which = supports the scheduling... > min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size). It does not = allow us to expand the size to any useful Blob size. Please note that you never have a limitation of the receive buffer send = size, since SCTP would use partial delivery. So other-sides-max-receive-size is only = relevant if there are buffering limits on top of SCTP. Best regards Michael >=20 >>=20 >> That said, Send(blob) seems like a bit of a footgun to me anyway; I = think apps are going to typically avoid it, a) to avoid memory bloat, = and b) to get progress indications. The only way out of that situation = is to provide stream semantics, which seems like a lot to take on given = that WebSockets hasn't gone that route. I also agree that we shouldn't = try to go the (B) route that you mention. >=20 > Well, Streams would be a good thing once they're done. Progress = indication could be added at the W3 level without much problem. The = memory issue should be resolvable in a number of ways, per my discussion = with Sicking. Note that application chunking has a serious memory issue = today in that the File Writer API hasn't been agreed to; I think there's = progress towards eventually adopting a version of the Filesystem API = (with changes), but that will be a while. Again, Stream should help - = and note that the semantics for Blob reception allow it to be written to = disk as it's received and not held entirely in memory when it's handed = to the application, which is NOT possible today for application = chunking. >=20 >>=20 >> So I still think manual chunking seems like a reasonable thing to = support. I don't quite get the congestion control concerns; just because = there is a max chunk size doesn't mean the impl can't buffer multiple = chunks in bufferedAmount; the app could let that fill up to a degree to = avoid having to poll constantly to prevent underrun. >=20 > On a slow link this will work if the browser isn't janky. On a fast = link GC pauses and other things may cause the buffer to drain out and go = idle for significant periods. >=20 > Randell >=20 >>=20 >>=20 >> On Sun, Mar 2, 2014 at 1:37 AM, Randell Jesup = wrote: >> On 2/26/2014 2:50 AM, Magnus Westerlund wrote: >> Thanks Michael, >>=20 >> WG, please consider these open issues and try to form your own = position >> on them. They are intended to be discussed at the meeting. If you = have >> proposals on how to resolve them or other input you are very welcome = to >> provide that on the list. >>=20 >> One more big issue. I realize this is very late for pre-meeting = discussion; I'd hoped to hash this out earlier but for various reasons = (including power outages and my own workload) this didn't happen. >>=20 >>=20 >> We discussed a way to deal with the issues surrounding maximum = message sizes at the last IETF. Right now we have a proposal in the = MMUSIC draft for limiting the maximum message size via the SDP. >>=20 >> There is a problem with this: it's at odds with the definition of = DataChannels in the W3 and with the "duck-typing" of DataChannels to = work largely as a superset of WebSockets (outside of channel creation), = and the WebAPI folk at Mozilla I talked to don't like the direction = we're taking. >>=20 >> I've been having talks with the WebAPI people at Mozilla, in = particular Jonas Sicking, our WebAPI lead, and they strongly dislike = encouraging applications to try to implement their large-data/blob = transfer protocols; browsers have considerably more tools available to = them to avoid memory hits and to make use of off-main-thread resources = than the JS apps do. "Having Send(blob) fail for any size of blob is = crazy and non-sensical" was one comment made when I described the = impacts of the current plan. >>=20 >>=20 >> Manual chunking in the application means poorly-implemented = congestion control in the app to keep the channel running efficiently = (the only feedback available directly is either having the far-end ack = at the user level, or trying to estimate sleep times via setTimeout() = and bufferedAmount() (which is simply not a great solution), or simply = dumping a large amount of smaller transfers into Send() and causing the = browser to have to buffer them in memory). Also GC or other pauses in = JS execution may cause hiccups in the transfer and mis-estimation of = available bandwidth. And of course this is being run over a = congestion-controlled channel in the first place. >>=20 >> Unless and until the W3 side makes DataChannels (and by extension, = PeerConnection) APIs available from JS workers (and this is = implemented), there will be compromises with packet-level protocols in = JS. One of those will be "it's hard to implement your own congestion = control well". Even with worker support, considerable extension of the = APIs would be needed to make it work really well there. I'll also note = that DataChannels-from-worker support is nowhere near implementation in = browsers. >>=20 >>=20 >> Another BIG problem as it's currently defined is that there's no = lower bound for this limit, so all DataChannel users will need to = implement manual chunking even if they use small fixed messages to = guarantee spec compliance. Of course they won't do so... and even if = they did, they wouldn't test it (another big problem). You might say = "ok, fine, lets set some small lower bound on this value, say 2 or 4 or = 16K". That doesn't really help much either. Many will send = variable-sized messages (because it's easy), and again won't test what = happens when the messages trip over the spec limit (or the actual = browser implementation limit!) Those with fixed-size messages larger = than the spec lower-bound won't test the against that; they'll test = against what Firefox and Chrome implement at the moment. So the net = result is they'll ship applications that can break randomly in the field = for no obvious reason (say if IE implements and uses 16K when Chrome = used 32K and Firefox used 100MB). >>=20 >> Why hand the application a footgun? >>=20 >>=20 >> Jonas Sicking suggested if the IETF insists on not supporting = arbitrary Send(blob), we'll need to push in the W3 for a W3 protocol run = on top of IETF DataChannels that handles fragmentation and reassembly in = order to preserve the JS API for Send(). We can do this, but part of = the whole partnership between the IETF and W3 on WebRTC was to try to = avoid having the W3 define network protocols and keep them in the IETF = where they belong. >>=20 >> Note: abandoning Send(blob) in W3 doesn't help much, as the comments = I made above about arbitrary limits and almost-certain lack of testing = of messages violating the negotiated size would still apply. Send(blob) = just makes it easier to trip over the problem (and in fact more likely = that the application will test very large sizes). >>=20 >>=20 >> Our options are: >>=20 >> A) Just accept this complexity and just hope that people write good = code or use good libraries. (See above about testing...) >> Note: we'd need to set *some* lower bound for the value. >>=20 >> B) Make the W3 API implementation add a level of protocol on top of = the underlying IETF network protocol. This protocol could then deal with = fragmenting messages on the sending side and reassembling them on the = receiving side. >>=20 >> C) Convince IETF WG to support arbitrarily sized messages at a = protocol level, at least in the WebRTC context, similar to WebSockets. >>=20 >>=20 >>=20 >> --=20 >> Randell Jesup -- rjesup a t mozilla d o t com >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >>=20 >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Mar 2 23:42:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFF91A0D41 for ; Sun, 2 Mar 2014 23:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 3Kdjlpaev2CG for ; Sun, 2 Mar 2014 23:01:34 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 955661A0D42 for ; Sun, 2 Mar 2014 23:01:33 -0800 (PST) Received: from [130.129.15.249] (unknown [130.129.15.249]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4C9A01C103E6D; Mon, 3 Mar 2014 08:01:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Mon, 3 Mar 2014 07:01:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <24066065-DD25-4037-B476-5FA7C9809DDE@fh-muenster.de> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9FE923z-lUAjvTgBKfVZHiTz6o4 X-Mailman-Approved-At: Sun, 02 Mar 2014 23:42:08 -0800 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 07:01:38 -0000 On 03 Mar 2014, at 06:56, Martin Thomson = wrote: > On 2 March 2014 18:42, Randell Jesup wrote: >> ndata solves the monopolization issue between streams, allowing = packets for >> different streams to be interleaved on the wire. It does not (so far = as I >> know) relax the usrsctp library's returning EMSGSIZE if the sendto() = is >> larger than available buffer space, and the alternative (EOR mode) = doesn't >> allow for interleaving of messages when sending at all (and I'm not = sure it >> allows interleaving on reception either, but I didn't check right = now). >>=20 >> Now, this is an implementation/API issue which could be fixed with = some >> work, but so far as I know no work has been done on it. So ndata = will allow >> us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, >> other-sides-max-receive-size). It does not allow us to expand the = size to >> any useful Blob size. >=20 > Sounds like the complaint would be best addressed by fixing the SCTP > implementations. I would hope that ndata would allow for transmission > of messages far in excess of what the implementation is willing to > buffer, that seems arbitrarily restrictive. As said in my previous mail: Using NDATA will allow to have on each stream a single ordered or unordered message being sent in explicit EOR mode. The send calls can be interleaved. Best regards Michael >=20 > (A streaming API wounds like a good idea too.) >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Mar 3 01:22:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE971A0AF2; Mon, 3 Mar 2014 01:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBHI8NKOotbY; Mon, 3 Mar 2014 01:22:31 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4581F1A0940; Mon, 3 Mar 2014 01:22:23 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403031022175094; Mon, 03 Mar 2014 10:22:17 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'IESG IESG'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Date: Mon, 3 Mar 2014 10:22:12 +0100 Message-ID: <000501cf36c2$0fac5020$2f04f060$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgACxezCAB08LAA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_Zo8d0IIJcrhvKSeOM6vaE7Sbn8 Cc: tram@ietf.org, 'Spencer Dawkins' , rtcweb@ietf.org Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 03 Mar 2014 09:22:34 -0000 Hi Cullen, Memory may be an illusion, still I cannot understand how there can be an ever growing archive in the IETF /Karl Allt v=E4l Hi Cullen, Not to cause more lost in the threads (I am also) I am addressing both = your emails in one, and copy separately to the other guys in the first email. = Further Inline --> >From http://www.ietf.org/mail-archive/web/tram/current/msg00275.html=20 Let me also point out draft-deng-tram-isp-turn-00=20 http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European carrier and = the cable operators in general - CableLabs) have expressed similar concerns = to me *=93This is exactly something we want to work on as the current way = will cause severe problem on traffic when rtcweb applications get popular=94* = is a direct quote from one of those. So, in answer to Simon Perreault [simon.perreault at viagenie.ca]=92s = question in another thread the 13th: a) Is this a real problem that is worth fixing? I think we can be confident that the answer is *YES*. Only these three ISP/NSP referred to, may represent 50%(?) of the universe=92s IP = accesses! And the other will follow these most forward looking carriers.=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 01:49 Till: Karl Stahl Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; = David Singer; Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; Henning Schulzrinne =C4mne: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > Karl,=20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to > be the point of debate, = and what your view is on what we should do. I think that would help make progress.=20 > Thank you,=20 > Cullen I just did something like that in: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html=20 Hoping this thread subject amplifies what this SHOULD be about. (An how = it will lead to the summary, after all diversion.) Actually, the outcome of "Interfacing to QoS" will be=20 I challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem = IX78 that implements such CLEAR INTERFACE and the actual QoS methods, for = both the Congestion, Default gateway, Surf Pipe=20 Manipulating the RTP extension header etc etc on 6 USD CPU and also = include the ADSL part where that quality handling is based on heavy 57 bytes chopping up at this exact=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 02:06 Till: Karl Stahl; IESG IESG Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo = Camarillo; rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins =C4mne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers. > =20 Reading the charter, the above is *not* at all a clear objective of the = WG (note I am not the chair of this WG or the responsible AD).=20 That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP for routing updates over TURN it would be within the scope of this charter.=20 My advice to the responsible AD is recharter this WG before IETF 90 or = close it. I would be glad to help write a charter that is not an infinite = blank cheque.=20 From nobody Mon Mar 3 02:31:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA70A1A0E73 for ; Mon, 3 Mar 2014 02:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 HzysHfXvtkDX for ; Mon, 3 Mar 2014 02:31:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1A02B1A0E72 for ; Mon, 3 Mar 2014 02:31:03 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-2e-531459e4c910 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FD.15.23809.4E954135; Mon, 3 Mar 2014 11:31:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 11:30:59 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: JSEP-06: How to create the second offer where only the port numbers are changed? Thread-Index: Ac8xgmHR3mZq1KQqQbqrDgGDhayzRAE1nSgAABypJXA= Date: Mon, 3 Mar 2014 10:30:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C5BDE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1C5BDEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje6TSJFgg4+rdS22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBl/Hl0lqXgmF3FogtTWRoYn9h0MXJySAiYSNw/ +oUZwhaTuHBvPVsXIxeHkMAhRok3h3ezQDiLGSU6T/0Dcjg42AQsJLr/aYM0iAioSTyctYsV xGYWUJe4s/gcO4gtLBAv8fXmQyaImgSJdZ+ms0DYVhJTNl0Fq2ERUJF4c6gfbDGvgK/E2l13 mCB2TWGU2DJrOlgRp0CgxPLrz8BsRqDrvp9awwSxTFzi1pP5TBBXC0gs2XMe6gNRiZeP/7FC 2EoSi25/hqrPl2i6+YwRYpmgxMmZT1gmMIrOQjJqFpKyWUjKZgG9zCygKbF+lz5EiaLElO6H 7BC2hkTrnLnsyOILGNlXMbLnJmbmpJcbbWIExtPBLb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwzRFqUH64oTW5UeLhiq+9f7913PLvz4hWLbv6vUd76 qnx18L39tfoCPhOW+t2J45UKCGdSM31iqfv3As/DfU4r5h3Ja0u74nldqc3NUSjl41dbZ1ax Bxu8Yk6aFchdabsbIabylEfL2XKaFp9JcaVK/ikGbb+W+UdOKX6K42+yMV+au32isRJLcUai oRZzUXEiAGZMj2d1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1bxRMLqq-sRPBNt8yp5MlwG8fkM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? 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, 03 Mar 2014 10:31:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1C5BDEESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpBcyBzcGVjaWZpZWQgaW4gQlVORExFLCBiZWZvcmUgdGhlIHJlbW90ZSBwZWVyIGhhcyBp bmRpY2F0ZWQgc3VwcG9ydCBvZiBCVU5ETEUsIGFsbCBtLSBsaW5lcyAoaW5jbHVkaW5nIHRob3Nl IHdpdGhpbiB0byBhIGJ1bmRsZSBncm91cCkgbXVzdCBoYXZlIHVuaXF1ZSBwb3J0IG51bWJlcnMu DQpUaGVuLCB3aGVuIHRoZSByZW1vdGUgcGVlciBoYXMgaW5kaWNhdGVkIHN1cHBvcnQgb2YgQlVO RExFLCBhIHNlY29uZCBvZmZlciAoY2FsbGVkIHRoZSBCQVMgb2ZmZXIpIG5lZWRzIHRvIGJlIHNl bnQsIGluIHdoaWNoIHRoZSBzYW1lIHBvcnQgbnVtYmVyIGlzIGFzc2lnbmVkIHRvIGFsbCBtLSBs aW5lcyB3aXRoaW4gYSBidW5kbGUgZ3JvdXAuDQpNeSBxdWVzdGlvbiBpczogaG93IGRvIEkgY3Jl YXRlIHRoZSBCQVMgb2ZmZXI/IEkgZG9u4oCZdCB3YW50IHRvIGNoYW5nZSBhbnl0aGluZyDigJMg SSBqdXN0IHdhbnQgdG8gZ2V0IGFuIFNEUCB3aXRoIHRoZSBCVU5ETEUgcG9ydCBhc3NpZ25lZCB0 byBhbGwgbS0gbGluZXMuIElzIHRoZXJlIGEgZmxhZyBpbiBjcmVhdGVPZmZlcigpIGZvciB0aGF0 Pw0KVGhlIGltcGxlbWVudGF0aW9uIGtub3dzIHRoYXQgYW55IG9mZmVycyB0aGF0IGFyZSBjcmVh dGVkIGFmdGVyIHRoZSBCVU5ETEUgYW5zd2VyIHNob3VsZCBoYXZlIHRoZSBzYW1lIHBvcnQgbnVt YmVycy4gU28sIHRoZSBhcHAgY291bGQgcHVzaCB0aGUgY3JlYXRlT2ZmZXIgYnV0dG9uIG9uY2Ug aXQgcmVjZWl2ZXMgdGhlIGFuc3dlciBpZiBpdCB3YW50ZWQgdG8gZW5zdXJlIHRoaXMgaGFwcGVu ZWQgaW1tZWRpYXRlbHkuIE90aGVyd2lzZSwgdGhlcmUgd2lsbCBiZSBhbiBvbm5lZ290aWF0aW9u bmVlZGVkIGV2ZW50IG9uY2UgSUNFIGNvbXBsZXRlcywgYW5kIHRoZSBvZmZlciBzZW50IGF0IHRo YXQgdGltZSB3aWxsIGhhdmUgdGhlIHVwZGF0ZWQgcG9ydHMuDQoNCldoZW4gSSBjYWxsIGNyZWF0 ZU9mZmVyKCksIGNhbiBJIGJlIGVuc3VyZSB0aGF0IG9ubHkgdGhlIHBvcnQgdmFsdWVzIHdpbGwg Y2hhbmdlPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K --_000_7594FB04B1934943A5C02806D1A2204B1D1C5BDEESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5BcyBzcGVjaWZpZWQgaW4gQlVORExFLCBiZWZvcmUgdGhlIHJlbW90ZSBwZWVyIGhhcyBpbmRp Y2F0ZWQgc3VwcG9ydCBvZiBCVU5ETEUsIGFsbCBtLSBsaW5lcyAoaW5jbHVkaW5nIHRob3NlIHdp dGhpbiB0byBhIGJ1bmRsZSBncm91cCkgbXVzdCBoYXZlIHVuaXF1ZSBwb3J0DQogbnVtYmVycy4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZW4sIHdo ZW4gdGhlIHJlbW90ZSBwZWVyIGhhcyBpbmRpY2F0ZWQgc3VwcG9ydCBvZiBCVU5ETEUsIGEgc2Vj b25kIG9mZmVyIChjYWxsZWQgdGhlIEJBUyBvZmZlcikgbmVlZHMgdG8gYmUgc2VudCwgaW4gd2hp Y2ggdGhlIHNhbWUgcG9ydCBudW1iZXIgaXMgYXNzaWduZWQNCiB0byBhbGwgbS0gbGluZXMgd2l0 aGluIGEgYnVuZGxlIGdyb3VwLjwvc3Bhbj48c3BhbiBsYW5nPSJGSSIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPk15IHF1ZXN0aW9uIGlzOiBob3cgZG8gSSBjcmVhdGUgdGhlIEJBUyBv ZmZlcj8gSSBkb27igJl0IHdhbnQgdG8gY2hhbmdlIGFueXRoaW5nIOKAkyBJIGp1c3Qgd2FudCB0 byBnZXQgYW4gU0RQIHdpdGggdGhlIEJVTkRMRSBwb3J0IGFzc2lnbmVkIHRvIGFsbCBtLSBsaW5l cy4gSXMgdGhlcmUNCiBhIGZsYWcgaW4gY3JlYXRlT2ZmZXIoKSBmb3IgdGhhdD88L3NwYW4+PHNw YW4gbGFuZz0iRkkiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBpbXBsZW1lbnRhdGlvbiBrbm93cyB0aGF0IGFueSBvZmZlcnMgdGhhdCBhcmUgY3Jl YXRlZCBhZnRlciB0aGUgQlVORExFIGFuc3dlciBzaG91bGQgaGF2ZSB0aGUgc2FtZSBwb3J0IG51 bWJlcnMuIFNvLCB0aGUgYXBwIGNvdWxkIHB1c2ggdGhlIGNyZWF0ZU9mZmVyIGJ1dHRvbiBvbmNl IGl0IHJlY2VpdmVzIHRoZSBhbnN3ZXIgaWYgaXQgd2FudGVkIHRvIGVuc3VyZSB0aGlzIGhhcHBl bmVkIGltbWVkaWF0ZWx5Lg0KIE90aGVyd2lzZSwgdGhlcmUgd2lsbCBiZSBhbiBvbm5lZ290aWF0 aW9ubmVlZGVkIGV2ZW50IG9uY2UgSUNFIGNvbXBsZXRlcywgYW5kIHRoZSBvZmZlciBzZW50IGF0 IHRoYXQgdGltZSB3aWxsIGhhdmUgdGhlIHVwZGF0ZWQgcG9ydHMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4gSSBjYWxsIGNy ZWF0ZU9mZmVyKCksIGNhbiBJIGJlIGVuc3VyZSB0aGF0DQo8Yj5vbmx5PC9iPiB0aGUgcG9ydCB2 YWx1ZXMgd2lsbCBjaGFuZ2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D1C5BDEESESSMB209erics_-- From nobody Mon Mar 3 02:34:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04C61A0E72 for ; Mon, 3 Mar 2014 02:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 osLJjI8Cpz4Q for ; Mon, 3 Mar 2014 02:34:31 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F41C51A0E92 for ; Mon, 3 Mar 2014 02:34:28 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-b0-53145ab1ac79 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.17.04249.1BA54135; Mon, 3 Mar 2014 11:34:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 11:34:25 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: JSEP-06: max-bundle policy questions Thread-Index: Ac8xgReyx0/WK3m4RUOln8j3WJLYRQE13CuAABzQDnA= Date: Mon, 3 Mar 2014 10:34:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C5C0A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B552E@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1C5C0AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje7GKJFgg3PntC22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlXH5xi72gw6Vi3oVmpgbGKU5djJwcEgImEo3L ZjFC2GISF+6tZ+ti5OIQEjjCKNF/aTWUs5hRYv7E18xdjBwcbAIWEt3/tEEaRATUJB7O2sUK YjMLqEvcWXyOHcQWFjCUWDplKRNEjZFEz6rZbBC2lUTnl5csIDaLgIrEun/bwGp4BXwlmhr/ MULsmsIose9jD9hQToFAiQc/t4HZjEDXfT+1hglimbjErSfzmSCuFpBYsuc8M4QtKvHy8T9W CFtJYtHtz1D1+RJHNh6FWiYocXLmE5YJjKKzkIyahaRsFpKyWUAvMwtoSqzfpQ9Roigxpfsh O4StIdE6Zy47svgCRvZVjBzFqcVJuelGBpsYgRF1cMtvix2Ml//aHGKU5mBREuf9+NY5SEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVANjwFN/C7G+sP5FW34+f5TP5dNvn2/CurLyCmNu8EG1 9aqRU7WrN9vwJUXendY4i98i38jX6uWmtZEbam1Fj1pHmZuvS3JlDN6QcifjwqE/aXWnbQTP Ci/busfmeIbC4l0t03bf0pxwdxnvvep7vF7r7K1n8gnPytx+6pRvz5nGU69UDmr7FOsqsRRn JBpqMRcVJwIAprI66nYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kJ3-vqO37cdh2E6IOQG-db3O79c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: max-bundle policy questions 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, 03 Mar 2014 10:34:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1C5C0AESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpTZWN0aW9uIDQuMS4xIHNheXM6DQrigJxvICAibWF4LWJ1bmRsZSI6IFRoZSBhcHBsaWNh dGlvbiB3aWxsIEJVTkRMRSBhbGwgb2YgaXRzIG1lZGlhIHN0cmVhbXMNCiAgICAgIG9uIGEgc2lu Z2xlIHRyYW5zcG9ydC4gIEFsbCBzdHJlYW1zIG90aGVyIHRoYW4gdGhlIGZpcnN0IHdpbGwgYmUN CiAgICAgIG1hcmtlZCBhcyBidW5kbGUtb25seS4gIFRoaXMgcG9saWN5IGFpbXMgdG8gbWluaW1p emUgY2FuZGlkYXRlDQogICAgICBnYXRoZXJpbmcgYW5kIG1heGltaXplIG11bHRpcGxleGluZywg YXQgdGhlIGNvc3Qgb2YgbGVzcw0KICAgICAgY29tcGF0aWJpbGl0eSB3aXRoIGxlZ2FjeSBlbmRw b2ludHMu4oCdDQpRMToNCkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZ5IHRoYXQg dGhlIGFwcGxpY2F0aW9uIHdpbGwgQlVORExFIGFsbCBvZiBpdHMgbWVkaWEgc3RyZWFtcyAqVEhB VCBUSEUgQVBQTElDQVRJT04gSVMgQUJMRSBUTyBERS1NVUxUSVBMRVgqLg0KDQpJIGRvbid0IGZv bGxvdyB3aGF0IHlvdSBhcmUgc2F5aW5nIGhlcmUuIEhvdyB3b3VsZCBhIFdlYlJUQyBhcHBsaWNh dGlvbiBlbmQgdXAgd2l0aCBzdHJlYW1zIGl0IGNvdWxkIG5vdCBkZW11bHRpcGxleD8NCg0KTWF5 YmUgc29tZW9uZSBpcyBpbXBsZW1lbnRpbmcgc29tZSBuZXcgbWVkaWEgdHlwZSwgZm9yIHdoaWNo IHRoZSBidW5kbGluZyBoYXNu4oCZdCBiZWVuIHNwZWNpZmllZC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D1C5C0AESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VjdGlvbiA0LjEuMSBz YXlzOiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPuKAnG8mbmJzcDsgJnF1b3Q7bWF4LWJ1bmRsZSZxdW90OzoNCjxiPlRoZSBhcHBsaWNh dGlvbiB3aWxsIEJVTkRMRSBhbGwgb2YgaXRzIG1lZGlhIHN0cmVhbXM8L2I+PC9zcGFuPjxzcGFu IGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb24g YSBzaW5nbGUgdHJhbnNwb3J0Ljwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBB bGwgc3RyZWFtcyBvdGhlciB0aGFuIHRoZSBmaXJzdCB3aWxsIGJlPC9zcGFuPjxzcGFuIGxhbmc9 IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFya2VkIGFzIGJ1 bmRsZS1vbmx5LiZuYnNwOyBUaGlzIHBvbGljeSBhaW1zIHRvIG1pbmltaXplIGNhbmRpZGF0ZTwv c3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGdhdGhlcmluZyBhbmQgbWF4aW1pemUgbXVsdGlwbGV4aW5nLCBhdCB0aGUgY29zdCBvZiBs ZXNzPC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+Y29tcGF0aWJpbGl0eSB3aXRoIGxlZ2Fj eSBlbmRwb2ludHMu4oCdPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkZJ Ij5RMTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+SSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGNsYXJpZnkgdGhhdCB0aGUgYXBwbGlj YXRpb24gd2lsbCBCVU5ETEUgYWxsIG9mIGl0cyBtZWRpYSBzdHJlYW1zICo8Yj5USEFUIFRIRSBB UFBMSUNBVElPTiBJUyBBQkxFIFRPIERFLU1VTFRJUExFWDwvYj4qLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRvbid0IGZvbGxvdyB3aGF0IHlvdSBhcmUgc2F5aW5nIGhlcmUuIEhvdyB3 b3VsZCBhIFdlYlJUQyBhcHBsaWNhdGlvbiBlbmQgdXAgd2l0aCBzdHJlYW1zIGl0IGNvdWxkIG5v dCBkZW11bHRpcGxleD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5YmUgc29tZW9uZSBpcyBpbXBsZW1lbnRpbmcgc29t ZSBuZXcgbWVkaWEgdHlwZSwgZm9yIHdoaWNoIHRoZSBidW5kbGluZyBoYXNu4oCZdCBiZWVuIHNw ZWNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D1C5C0AESESSMB209erics_-- From nobody Mon Mar 3 02:39:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15631A0DC2 for ; Mon, 3 Mar 2014 02:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y2v-jRmsJk6 for ; Mon, 3 Mar 2014 02:39:13 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6261A0EAF for ; Mon, 3 Mar 2014 02:39:04 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so2929327wgh.0 for ; Mon, 03 Mar 2014 02:39:01 -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=E/THlZ99Obe1LQEYbcZcoDGv/gTewGHZQqOTjUWSTMs=; b=hmpRn6tAyxoiT9EUauFi4ClpNqoejGjVenHInUSqgI0nOw7/l0iNG/Gt8uTSY6z/mO RRrp6Rg+CRZ0jk+wgQr8V2Q2/ZcQJo2iTtjc205IXycTB0oqNBgU8+3ngCHc1mK2AEwl ZlnwIGdUvzp14G3FDy0sUWGWipwy8r26ildxU3tfkrh0RB6FTDf3QCKQVolRVQeHqNrd UiTxPH/AuGPfcirM4KpeGSQcJExnO1xmUqr9Ojo0MJtTQKS5+yotb0MHYKKcaTX6eMZq W2EyAyJRFTjSOxcB5REBqPjUzvOXiQJOelBvx/eXceVMMLRm2Icobr3CMvb1L+07WVrt Pc9Q== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr1219210wjc.56.1393843141069; Mon, 03 Mar 2014 02:39:01 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 02:39:01 -0800 (PST) In-Reply-To: <24066065-DD25-4037-B476-5FA7C9809DDE@fh-muenster.de> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <24066065-DD25-4037-B476-5FA7C9809DDE@fh-muenster.de> Date: Mon, 3 Mar 2014 02:39:01 -0800 Message-ID: From: Martin Thomson To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mCKPHwchtNLjwnRkbC8tU6v2wZw Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 10:39:15 -0000 On 2 March 2014 23:01, Michael Tuexen wrote: > As said in my previous mail: Using NDATA will allow to have on each > stream a single ordered or unordered message being sent in explicit > EOR mode. The send calls can be interleaved. That's great. So the protocol can and is being fixed. I think that part of Randell's concern comes from the implementations thereof. Those would seem to be even easier to fix. From nobody Mon Mar 3 02:44:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6A1A0DBB for ; Mon, 3 Mar 2014 02:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 vPrWf3jqyUim for ; Mon, 3 Mar 2014 02:44:36 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF351A0CB7 for ; Mon, 3 Mar 2014 02:44:35 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-60-53145d0f4646 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 56.2F.10875.F0D54135; Mon, 3 Mar 2014 11:44:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 11:44:31 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy Thread-Index: Ac8pjtnjzyDELOBDTjiX88M43xAyxwDrMPeAARFru7ABNZy1AAAdWm5Q Date: Mon, 3 Mar 2014 10:44:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C5C73@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B5588@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1C5C73ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja5ArEiwwTQzi61ThSzW/mtnd2Dy WLCp1GPJkp9MAUxRXDYpqTmZZalF+nYJXBnz+k6zFpwwrfjy7DNTA2OLSRcjJ4eEgInE/vYP jBC2mMSFe+vZuhi5OIQEDjFK7J3fxAzhLGaUuDLrE5DDwcEmYCHR/U8bpEFEQE3i4axdrCA2 s4C6xJ3F59hBbGGBBIk199cwQtQkSrz+3cEGYbtJ/D76BKyeRUBFYvmm3SwgNq+Ar8S9k1NY IHbNZ5LY9WIKWAOnQKDEw3tTwQYxAl33/dQaJohl4hK3nsxngrhaQGLJnvPMELaoxMvH/1gh bCWJRbc/Q9XnS9w6v4ENYpmgxMmZT1gmMIrOQjJqFpKyWUjKZgG9zCygKbF+lz5EiaLElO6H 7BC2hkTrnLnsyOILGNlXMbLnJmbmpJcbbmIERtPBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxilyZdd2eVO9P4PTLyqyOLU+BLTq+LTNJvpu7d277u y7tpjEsZvHxCvt5Yn71U/W/bJK1z4TF//lXOn2sS2dfW0pja3Rb5MYGxeZOilKHovT9xGZwL mHh+aB9ev+z9aY65+94cLnwZFbzIKGjJ/xQfsToNTV1Z4Vidd69/v1sovm6zV5PXRx0lluKM REMt5qLiRAB3ykJRdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jOZ01HwJfBP9yzTTCl6Ej7EBQXY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy 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, 03 Mar 2014 10:44:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1C5C73ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JbiB0aGUgdHlwaWNhbCBjYXNlLCB5b3UgZG9uJ3QgbmVlZCB0byBzZXQgdGhpczsg dGhlIGltcGxlbWVudGF0aW9uIGtub3dzIHRvIHVzZSB1bmlxdWUgcG9ydHMgPmluIHRoZSBpbml0 aWFsIG9mZmVyIGFuZCB0aGVuIGNhbiBkbyB0aGUgYXBwcm9wcmlhdGUgdGhpbmcgaW4gZnV0dXJl IG9mZmVycyAoaS5lLiwgb25jZSBCVU5ETEUgPnN1cHBvcnQgYnkgdGhlIHJlbW90ZSBzaWRlIGlz IGtub3duKS4gSW4gdGhlIGNhc2Ugd2hlcmUgeW91IHdhbnQgdG8gc3RhcnQgd2l0aCBzaGFyZWQg cG9ydHMgaW4gPnRoZSBpbml0aWFsIG9mZmVyLCBiZWNhdXNlIHlvdSBrbm93IHRocm91Z2ggc29t ZSBtZWNoYW5pc20gdGhhdCB0aGUgcmVtb3RlIHNpZGUgc3VwcG9ydHMgPnRoaXMsIHRoZSBidW5k bGUtcG9saWN5IGNvbnN0cmFpbnQgY291bGQgYWxsb3cgeW91IHRvIGluZGljYXRlIHRoaXMsIGku ZS4gdGhhdCB5b3Ugd2FudCBidW5kbGluZyA+dG8gc3RhcnQgaW1tZWRpYXRlbHkuDQo+DQo+SSBh Z3JlZSB0aGF0IGEgbmV3IHZhbHVlIGlzIG5lZWRlZCB0byBzdXBwb3J0IHRoaXMuDQoNCkdvb2Qg 4pi6DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D1C5C73ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPkluIHRoZSB0eXBpY2FsIGNhc2UsIHlvdSBkb24ndCBuZWVkIHRvIHNl dCB0aGlzOyB0aGUgaW1wbGVtZW50YXRpb24ga25vd3MgdG8gdXNlIHVuaXF1ZSBwb3J0cw0KPHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+aW4gdGhlIGluaXRpYWwgb2ZmZXIg YW5kIHRoZW4gY2FuIGRvIHRoZSBhcHByb3ByaWF0ZSB0aGluZyBpbiBmdXR1cmUgb2ZmZXJzIChp LmUuLCBvbmNlIEJVTkRMRQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+ c3VwcG9ydCBieSB0aGUgcmVtb3RlIHNpZGUgaXMga25vd24pLiBJbiB0aGUgY2FzZSB3aGVyZSB5 b3Ugd2FudCB0byBzdGFydCB3aXRoIHNoYXJlZCBwb3J0cyBpbg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZndDs8L3NwYW4+dGhlIGluaXRpYWwgb2ZmZXIsIGJlY2F1c2UgeW91IGtub3cg dGhyb3VnaCBzb21lIG1lY2hhbmlzbSB0aGF0IHRoZSByZW1vdGUgc2lkZSBzdXBwb3J0cw0KPHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+dGhpcywgdGhlIGJ1bmRsZS1wb2xp Y3kgY29uc3RyYWludCBjb3VsZCBhbGxvdyB5b3UgdG8gaW5kaWNhdGUgdGhpcywgaS5lLiB0aGF0 IHlvdSB3YW50IGJ1bmRsaW5nDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bh bj50byBzdGFydCBpbW1lZGlhdGVseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFu PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+SSBhZ3JlZSB0aGF0IGEg bmV3IHZhbHVlIGlzIG5lZWRlZCB0byBzdXBwb3J0IHRoaXMuPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+R29vZA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D1C5C73ESESSMB209erics_-- From nobody Mon Mar 3 02:45:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E81A0E54 for ; Mon, 3 Mar 2014 02:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 76kDmhuUn_Om for ; Mon, 3 Mar 2014 02:45:51 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC11A0E63 for ; Mon, 3 Mar 2014 02:45:51 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-84-53145d5be73a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F6.28.23809.B5D54135; Mon, 3 Mar 2014 11:45:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 11:45:47 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Martin Thomson , Randell Jesup Thread-Topic: [rtcweb] Open data channel issues Thread-Index: AQHPMoOZqdy9P53uXkqR5LB8VVCpoQ== Date: Mon, 3 Mar 2014 10:45:46 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF747B1@ESESSMB209.ericsson.se> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvjW50rEiwwdkvmhbXzvxjtDi7Lcti 7b92dosJSx+xOrB49Ew5zeqxc9Zddo8lS34yeXxYvo4tgCWKyyYlNSezLLVI3y6BK+PJs0ms BTOYK06t7mJvYHzM1MXIwSEhYCLx6b1cFyMnkCkmceHeerYuRi4OIYFDjBKzbzSwQziLGSUm PW9mB6liEwiU2LpvARuILSIQLrFl5mZmkEHMQPHf3yRAwsICehIfW7azQ5ToS2y8sIwZwtaT 2PPjG1icRUBFYunD00wgNq+Ar8ShC4dZIXZtYJJYdWcDWAMj0EXfT60BK2IWEJe49WQ+E8Sl AhJL9pxnhrBFJV4+/scKYStKXJ2+HKpeT+LG1ClsELa2xLKFr5khlglKnJz5hGUCo+gsJGNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLjTYxAiPm4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGrZvn//DIynrOpzOr2aXN0ZZ7fe657MjnV+XtDj1gYpZ7 rvGqIPLUi78zFTYWJUvxnmxiYNq3TMFj56SL/16s0+t/rbkgKeGSWkrrm3AN71Nda9N1F+5J mv1z0n4V7vpOU+3iZqMS7wmHwnWu8woEivTMvRv1lCVhk9NlyVfyzsZF+zIDxBiVWIozEg21 mIuKEwH3femIZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8LODypLJovMk2qLwN04GnApBwI0 Cc: Michael Tuexen , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 10:45:53 -0000 On 2014-03-03 07:57, Martin Thomson wrote:=0A= =0A= > (A streaming API wounds like a good idea too.)=0A= =0A= There is some ongoing work: =0A= http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0218.html=0A= =0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From nobody Mon Mar 3 02:57:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4BD1A0EE3 for ; Mon, 3 Mar 2014 02:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WK5ZScxkGLJ for ; Mon, 3 Mar 2014 02:57:44 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0419C1A0D87 for ; Mon, 3 Mar 2014 02:57:43 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id l18so2957059wgh.21 for ; Mon, 03 Mar 2014 02:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wN0QrIMAFdgQ1lgayJ0NN8ycOSKMnSiyRrrfOqLkDsc=; b=HmxvVlcbFW4YbRbiRrjCSHYhbTRKlmkUOWPUypnNepFmfmZGlR6El69J4x8vYEKahz XkmgNHbNWhYDmNZ2pQDYXw58MnsZhWGBwbb5hgCguA9/KAArXxs4Ct1AnSJ9Q6fbdDLu 6DTa7l9s18w6xh/3dQjTjbiDVjy8+G3lh+7+kaOxkZ2N8oX+/RzkrdZW2l5QZ23FbMbP waIBMIZf1WhvUTRoiJMrK4vXsvUCRGTO7GR4YQkSne/KBx6z9onGAOW2fY4CIjMyeWxL usgpruLvRG2HG1bk/OWDvd8rThcFOJrBwxcxdpUCntiAJfBhBltkKwXSM9TsGSh79RuL nXdA== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr16675264wjb.28.1393844247079; Mon, 03 Mar 2014 02:57:27 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 02:57:26 -0800 (PST) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF747B1@ESESSMB209.ericsson.se> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <1447FA0C20ED5147A1AA0EF02890A64B1CF747B1@ESESSMB209.ericsson.se> Date: Mon, 3 Mar 2014 02:57:26 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MUxCY2tFhSm38XEr49RdSlf8M0o Cc: Randell Jesup , Michael Tuexen , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 10:57:45 -0000 On 3 March 2014 02:45, Stefan H=C3=A5kansson LK wrote: > There is some ongoing work: > http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0218.html I was thinking more specific work applying that to thewebsocketapi. From nobody Mon Mar 3 03:19:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094E91A0F3C for ; Mon, 3 Mar 2014 03:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 4sYLBl3wAcX8 for ; Mon, 3 Mar 2014 03:19:05 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A5B861A0EEF for ; Mon, 3 Mar 2014 03:19:05 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id jw12so727660veb.37 for ; Mon, 03 Mar 2014 03:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EbKuYjNXPrsQzP56xzHnR+lq76sECR71Tfu82fR0N+s=; b=dxHDaWUTthOV6tTm/DqTNVhj+CKkE5wus/dGrG7yDKitX5LiUvXqFuoFj8pj4vMhfS AKsS7gmWUq95XBB1LvIz2rjyGlstNW+1IVGxa/aJQvqWVga54oKtc21VJ5ci/4Ipc4nl EwUPvDa4Ozel4cuauWReIlfbyoidQm6m1AgVLZWPpc/rF7AHlPCdnIivPecxww0H5YEV M/gmG8acrmAq7jZ7YL2Rb1+5ai61XjghPIlpd6AfRXtbWgZMK5Bypyf7NwrwGQjXp8+8 Ftys1wd9Z19A6FqDvyb8C9IUrxYhgFTbLh1tTjBGC6P80looPgeYvpZxcxiFH/r7dPdB z0pw== 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=EbKuYjNXPrsQzP56xzHnR+lq76sECR71Tfu82fR0N+s=; b=E314OgKm196Qz3d697quzqqGvuwpS+dgjXyAHylW3tZtv34NBG1XnXBRniOO28wBW4 u7PiROFeWTlI1N+SHCTcEbFqPwWcdcf7g6ytblF6vr0JtLBoG06e4YfOOslWfo2jMYfH GMDEvTV7D3R/+AGr8UC0RKuF6Ojj5U+wDij2dcShyI75fBf7nKeCrkkS0CnABgCK6K/8 dovfPBqhrIyfTvJzFWCiLwMUdVL0xlb/x5K8SUVA9/NYv/8mFwBYtd8vuy0TcFeiGfDe R8E1qCVJxLS6mZKc5ISL3hqFGiRakbtR3ybzEoPdg9cSU9zMuYAOn4+sQErsDmWIkYUQ nZUQ== X-Gm-Message-State: ALoCoQmUwdpjgJNqm/B0hxJdZmxaCQKRdRF4hnxZ0g5bqbv2SxvKd2bzcdxZYaIQikBIEAiFT2JxRID+qszTWf7xZOzpTbxnEi+AUdrJqwBoGS+K+8EGAHV8mrWAAvZ6JysLsX/ce/Xau2rG+cBXi7RJrr4ecWmhK5Yhw8iQ2M39GROlk3BAqngdYQ73vI439I1MFXMJaoIY X-Received: by 10.52.171.39 with SMTP id ar7mr25197655vdc.5.1393845542539; Mon, 03 Mar 2014 03:19:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 03:18:42 -0800 (PST) In-Reply-To: <5313EC0D.9030808@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> From: Justin Uberti Date: Mon, 3 Mar 2014 03:18:42 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=047d7bacb7386f6ee804f3b1f407 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RCm1DmetkmkhjJPeNJ45JmqBXAk Cc: Michael Tuexen , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 11:19:10 -0000 --047d7bacb7386f6ee804f3b1f407 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup wrote: > On 3/2/2014 4:27 PM, Justin Uberti wrote: > > I'm not sure I understand the actual problem here. We *are* going to > handle arbitrary-sized messages once ndata gets done. The max-msg-size > stuff is just a solution until ndata is deployed. (To cite your options, > this is A followed by C). > > > So, here's where I think there may be a disconnect (and if I'm wrong, > great): > > ndata solves the monopolization issue between streams, allowing packets > for different streams to be interleaved on the wire. It does not (so far > as I know) relax the usrsctp library's returning EMSGSIZE if the sendto() > is larger than available buffer space, and the alternative (EOR mode) > doesn't allow for interleaving of messages when sending at all (and I'm not > sure it allows interleaving on reception either, but I didn't check right > now). > > Now, this is an implementation/API issue which could be fixed with some > work, but so far as I know no work has been done on it. So ndata will > allow us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, > other-sides-max-receive-size). It does not allow us to expand the size to > any useful Blob size. > Based on the discussion of ndata/eor in followup messages, I think this problem will be addressed in the near future. > > > > That said, Send(blob) seems like a bit of a footgun to me anyway; I > think apps are going to typically avoid it, a) to avoid memory bloat, and > b) to get progress indications. The only way out of that situation is to > provide stream semantics, which seems like a lot to take on given that > WebSockets hasn't gone that route. I also agree that we shouldn't try to go > the (B) route that you mention. > > > Well, Streams would be a good thing once they're done. Progress indication > could be added at the W3 level without much problem. The memory issue > should be resolvable in a number of ways, per my discussion with Sicking. > Note that application chunking has a serious memory issue today in that the > File Writer API hasn't been agreed to; I think there's progress towards > eventually adopting a version of the Filesystem API (with changes), but > that will be a while. Again, Stream should help - and note that the > semantics for Blob reception allow it to be written to disk as it's > received and not held entirely in memory when it's handed to the > application, which is NOT possible today for application chunking. > Agree Streams will be useful when done, but that's probably post-1.0 (as Martin says, we should first let it be applied to WebSockets). However I don't think app chunking will have any memory problems - the chunks will be small enough that they can be easily spooled to disk as they come in. > > > So I still think manual chunking seems like a reasonable thing to > support. I don't quite get the congestion control concerns; just because > there is a max chunk size doesn't mean the impl can't buffer multiple > chunks in bufferedAmount; the app could let that fill up to a degree to > avoid having to poll constantly to prevent underrun. > > > On a slow link this will work if the browser isn't janky. On a fast link > GC pauses and other things may cause the buffer to drain out and go idle > for significant periods. > Since the amount buffered is up to the app, the app can just increase the buffer size to provide enough data to cover the next second or so of transfer. Note that app chunking will clearly be needed in some of the more interesting cases we want to support, such as where the transfer is not 1:1. For swarm-style downloading, we need to make sure app chunking works well (and I think it does). > > > Randell > > > > > On Sun, Mar 2, 2014 at 1:37 AM, Randell Jesup wrote: > >> On 2/26/2014 2:50 AM, Magnus Westerlund wrote: >> >>> Thanks Michael, >>> >>> WG, please consider these open issues and try to form your own position >>> on them. They are intended to be discussed at the meeting. If you have >>> proposals on how to resolve them or other input you are very welcome to >>> provide that on the list. >>> >> >> One more big issue. I realize this is very late for pre-meeting >> discussion; I'd hoped to hash this out earlier but for various reasons >> (including power outages and my own workload) this didn't happen. >> >> >> We discussed a way to deal with the issues surrounding maximum message >> sizes at the last IETF. Right now we have a proposal in the MMUSIC draft >> for limiting the maximum message size via the SDP. >> >> There is a problem with this: it's at odds with the definition of >> DataChannels in the W3 and with the "duck-typing" of DataChannels to work >> largely as a superset of WebSockets (outside of channel creation), and the >> WebAPI folk at Mozilla I talked to don't like the direction we're taking. >> >> I've been having talks with the WebAPI people at Mozilla, in particular >> Jonas Sicking, our WebAPI lead, and they strongly dislike encouraging >> applications to try to implement their large-data/blob transfer protocols; >> browsers have considerably more tools available to them to avoid memory >> hits and to make use of off-main-thread resources than the JS apps do. >> "Having Send(blob) fail for any size of blob is crazy and non-sensical" >> was one comment made when I described the impacts of the current plan. >> >> >> Manual chunking in the application means poorly-implemented congestion >> control in the app to keep the channel running efficiently (the only >> feedback available directly is either having the far-end ack at the user >> level, or trying to estimate sleep times via setTimeout() and >> bufferedAmount() (which is simply not a great solution), or simply dumping >> a large amount of smaller transfers into Send() and causing the browser to >> have to buffer them in memory). Also GC or other pauses in JS execution >> may cause hiccups in the transfer and mis-estimation of available >> bandwidth. And of course this is being run over a congestion-controlled >> channel in the first place. >> >> Unless and until the W3 side makes DataChannels (and by extension, >> PeerConnection) APIs available from JS workers (and this is implemented), >> there will be compromises with packet-level protocols in JS. One of those >> will be "it's hard to implement your own congestion control well". Even >> with worker support, considerable extension of the APIs would be needed to >> make it work really well there. I'll also note that >> DataChannels-from-worker support is nowhere near implementation in browsers. >> >> >> Another BIG problem as it's currently defined is that there's no lower >> bound for this limit, so all DataChannel users will need to implement >> manual chunking even if they use small fixed messages to guarantee spec >> compliance. Of course they won't do so... and even if they did, they >> wouldn't test it (another big problem). You might say "ok, fine, lets set >> some small lower bound on this value, say 2 or 4 or 16K". That doesn't >> really help much either. Many will send variable-sized messages (because >> it's easy), and again won't test what happens when the messages trip over >> the spec limit (or the actual browser implementation limit!) Those with >> fixed-size messages larger than the spec lower-bound won't test the against >> that; they'll test against what Firefox and Chrome implement at the moment. >> So the net result is they'll ship applications that can break randomly in >> the field for no obvious reason (say if IE implements and uses 16K when >> Chrome used 32K and Firefox used 100MB). >> >> Why hand the application a footgun? >> >> >> Jonas Sicking suggested if the IETF insists on not supporting arbitrary >> Send(blob), we'll need to push in the W3 for a W3 protocol run on top of >> IETF DataChannels that handles fragmentation and reassembly in order to >> preserve the JS API for Send(). We can do this, but part of the whole >> partnership between the IETF and W3 on WebRTC was to try to avoid having >> the W3 define network protocols and keep them in the IETF where they belong. >> >> Note: abandoning Send(blob) in W3 doesn't help much, as the comments I >> made above about arbitrary limits and almost-certain lack of testing of >> messages violating the negotiated size would still apply. Send(blob) just >> makes it easier to trip over the problem (and in fact more likely that the >> application will test very large sizes). >> >> >> Our options are: >> >> A) Just accept this complexity and just hope that people write good code >> or use good libraries. (See above about testing...) >> Note: we'd need to set *some* lower bound for the value. >> >> B) Make the W3 API implementation add a level of protocol on top of the >> underlying IETF network protocol. This protocol could then deal with >> fragmenting messages on the sending side and reassembling them on the >> receiving side. >> >> C) Convince IETF WG to support arbitrarily sized messages at a protocol >> level, at least in the WebRTC context, similar to WebSockets. >> >> >> >> -- >> Randell Jesup -- rjesup a t mozilla d o t com >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bacb7386f6ee804f3b1f407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup <randell-ietf@jesup= .org> wrote:
=20 =20 =20
On 3/2/2014 4:27 PM, Justin Uberti wrote:
I'm not sure I understand the actual problem her= e. We *are* going to handle arbitrary-sized messages once ndata gets done. The max-msg-size stuff is just a solution until ndata is deployed. (To cite your options, this is A followed by C).

So, here's where I think there may be a disconnect (and if I'm wrong, great):

ndata solves the monopolization issue between streams, allowing packets for different streams to be interleaved on the wire.=C2=A0 It does not (so far as I know) relax the usrsctp library's returning EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now).
Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it.=C2=A0 So ndata will allow us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size).=C2=A0 It does not allow us to expand the size to any useful Blob size.

Based on the discussion of ndata/eor in followup me= ssages, I think this problem will be addressed in the near future.
=C2=A0=C2=A0



That said, Send(blob) seems like a bit of a footgun to me anyway; I think apps are going to typically avoid it, a) to avoid memory bloat, and b) to get progress indications. The only way out of that situation is to provide stream semantics, which seems like a lot to take on given that WebSockets hasn'= t gone that route. I also agree that we shouldn't try to go the (B) route that you mention.

Well, Streams would be a good thing once they're done. Progress indication could be added at the W3 level without much problem.=C2=A0 T= he memory issue should be resolvable in a number of ways, per my discussion with Sicking.=C2=A0 Note that application chunking has a serious memory issue today in that the File Writer API hasn't been agreed to; I think there's progress towards eventually adopting a version of the Filesystem API (with changes), but that will be a while.=C2=A0 Again, Stream should help - and note that the semantics fo= r Blob reception allow it to be written to disk as it's received and not held entirely in memory when it's handed to the application, which is NOT possible today for application chunking.

Agree Streams will be useful when done, but that's= probably post-1.0 (as Martin says, we should first let it be applied to We= bSockets). However I don't think app chunking will have any memory prob= lems - the chunks will be small enough that they can be easily spooled to d= isk as they come in.=C2=A0


So I still think manual chunking seems like a reasonable thing to support. I don't quite get the congestion control concerns; just because there is a max chunk size doesn't mean the impl can't buffer multiple chunks in bufferedAmount; the app could let that fill up to a degree to avoid having to poll constantly to prevent underrun.

On a slow link this will work if the browser isn't janky.=C2=A0 On = a fast link GC pauses and other things may cause the buffer to drain out and go idle for significant periods.

<= div>Since the amount buffered is up to the app, the app can just increase t= he buffer size to provide enough data to cover the next second or so of tra= nsfer.=C2=A0

Note that app chunking will clearly be needed in s= ome of the more interesting cases we want to support, such as where the tra= nsfer is not 1:1. For swarm-style downloading, we need to make sure app chu= nking works well (and I think it does).


=C2=A0 Randell




On Sun, Mar 2, 2014 at 1:37 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 2/26/2014 2:50 AM, Magnus Westerlund wrote:
Thanks Michael,

WG, please consider these open issues and try to form your own position
on them. They are intended to be discussed at the meeting. If you have
proposals on how to resolve them or other input you are very welcome to
provide that on the list.

One more big issue. =C2=A0I realize this is very late for pre-meeting discussion; I'd hoped to hash this out earlier but for various reasons (including power outages and my own workload) this didn't happen.


We discussed a way to deal with the issues surrounding maximum message sizes at the last IETF. =C2=A0Right now we have= a proposal in the MMUSIC draft for limiting the maximum message size via the SDP.

There is a problem with this: it's at odds with the definition of DataChannels in the W3 and with the "duck-typing" of DataChannels to work largely as a su= perset of WebSockets (outside of channel creation), and the WebAPI folk at Mozilla I talked to don't like the direction we'= ;re taking.

I've been having talks with the WebAPI people at Mozilla, i= n particular Jonas Sicking, our WebAPI lead, and they strongly dislike encouraging applications to try to implement their large-data/blob transfer protocols; browsers have considerably more tools available to them to avoid memory hits and to make use of off-main-thread resources than the JS apps do. =C2=A0"Having Send(blob) fail for any size of = blob is crazy and non-sensical" was one comment made when I described the impacts of the current plan.


Manual chunking in the application means poorly-implemented congestion control in the app to keep the channel running efficiently (the only feedback available directly is either having the far-end ack at the user level, or trying to estimate sleep times via setTimeout() and bufferedAmount() (which is simply not a great solution), or simply dumping a large amount of smaller transfers into Send() and causing the browser to have to buffer them in memory). =C2=A0Also GC or other pauses in JS execution may cause hiccups in the transfer and mis-estimation of available bandwidth. =C2=A0And o= f course this is being run over a congestion-controlled channel in the first place.

Unless and until the W3 side makes DataChannels (and by extension, PeerConnection) APIs available from JS workers (and this is implemented), there will be compromises with packet-level protocols in JS. =C2=A0One of those will be "= it's hard to implement your own congestion control well". =C2= =A0Even with worker support, considerable extension of the APIs would be needed to make it work really well there. =C2=A0I'= ll also note that DataChannels-from-worker support is nowhere near implementation in browsers.


Another BIG problem as it's currently defined is that there's no lower bound for this limit, so all DataChannel users will need to implement manual chunking even if they use small fixed messages to guarantee spec compliance. =C2=A0Of course they won't do so... =C2=A0and even if they did, they wouldn't test it (another big problem). =C2=A0You might say= "ok, fine, lets set some small lower bound on this value, say 2 or 4 or 16K". =C2=A0That doesn't really help much eith= er. =C2=A0Many will send variable-sized messages (because it's easy), and again won't test what happens when the messages trip over the spec limit (or the actual browser implementation limit!) =C2=A0Those with fixed-size messages larger than the spec lower-bound won't test the against that; they'll test against what Firefox and Chrome implement at the moment. =C2=A0= So the net result is they'll ship applications that can break randomly in the field for no obvious reason (say if IE implements and uses 16K when Chrome used 32K and Firefox used 100MB).

Why hand the application a footgun?


Jonas Sicking suggested if the IETF insists on not supporting arbitrary Send(blob), we'll need to push in the W3 for a W3 protocol run on top of IETF DataChannels that handles fragmentation and reassembly in order to preserve the JS API for Send(). =C2=A0We can do this, but part of the whole partnership between the IETF and W3 on WebRTC was to try to avoid having the W3 define network protocols and keep them in the IETF where they belong.

Note: abandoning Send(blob) in W3 doesn't help much, as the comments I made above about arbitrary limits and almost-certain lack of testing of messages violating the negotiated size would still apply. =C2=A0Send(blob) just makes = it easier to trip over the problem (and in fact more likely that the application will test very large sizes).


Our options are:

A) Just accept this complexity and just hope that people write good code or use good libraries. (See above about testing...)
Note: we'd need to set *some* lower bound for the value.
B) Make the W3 API implementation add a level of protocol on top of the underlying IETF network protocol. This protocol could then deal with fragmenting messages on the sending side and reassembling them on the receiving side.

C) Convince IETF WG to support arbitrarily sized messages at a protocol level, at least in the WebRTC context, similar to WebSockets.



--
Randell Jesup -- rjesup a t mozilla d o t 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



--=20
Randell Jesup -- rjesup a t mozilla d o t com

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


--047d7bacb7386f6ee804f3b1f407-- From nobody Mon Mar 3 03:26:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A021A0F47 for ; Mon, 3 Mar 2014 03:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 tpGDoCVeyNb4 for ; Mon, 3 Mar 2014 03:26:55 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E736C1A0F45 for ; Mon, 3 Mar 2014 03:26:54 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1582 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKR17-0006Ss-AC; Mon, 03 Mar 2014 05:26:41 -0600 Message-ID: <5314669C.3090301@jesup.org> Date: Mon, 03 Mar 2014 06:25:16 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <6C3E8CBC-9EC4-4222-8073-7D7903FEC38A@fh-muenster.de> In-Reply-To: <6C3E8CBC-9EC4-4222-8073-7D7903FEC38A@fh-muenster.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dlaK9u0btp9YP-SzVWMFDfwZHTE Cc: Michael Tuexen , Randall Stewart Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 11:26:56 -0000 On 3/3/2014 1:53 AM, Michael Tuexen wrote: > On 03 Mar 2014, at 02:42, Randell Jesup wrote: > > >> EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now). > If you want to send messages larger than the socket send buffer, you must use the explicit > EOR more. This is independent from using NDATA or not. right. > If you use NDATA, you can have on each outgoing stream a single message (order or unordered) > being sent using explicit EOR mode and the calls can be interleaved. I don't think I have > tested this up to know, but this is how it should work. > > rrs@: Just to double check: Am I right? Please note that RTCWeb doesn't use ordered and > unordered on the same stream, and you don't need to send more than one message with > explicit EOR on the same stream at the same time. Therefore the above simplification... If this is the case, this should deal with the issue I believe, with one caveat for the W3 layer: If we can only send one at a time, we get an issue where we call channel.send(blob1); channel.send(blob2); the JS interface to send() is synchronous and can't block. This implies that if send(blob1) hasn't completed, the send(blob2) can't start, and all following send()s must also be buffered in memory. For a blob, since a blob reference is read-only, this is likely ok (need to verify what happens if we haven't read the blob into memory - if this isn't the case, we have a problem). For sending an ArrayBuffer (or string), we'll have to snapshot the buffer at send() time if it's queued since the referenced data may change. However, this really isn't anything that new, since if the SCTP buffers are full you have to do something similar anyways, even without any messages using fragmentation. I presume from your comment (since it wasn't entirely clear) that if I have channel.send(blob1); channel.send("foo") that "foo" can't be sent until blob1 has been fully transmitted (has hit EOR at the send side), even though "foo" doesn't require fragmentation, and so all send()s for a channel during a fragmented send() must be copied and queued. >> Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it. So ndata will allow us to expand the max-sending size to > This API work is part of getting NDATA implemented. Randall has implemented it, we do have > code, but it needs some testing and cleaning up in the API which supports the scheduling... So the last issue would be backwards compatibility. If today an app must be written to query (via an unspecified W3 property) the max size you can reliably send() to the other side, then it must buy into (and test!) that functionality now and until it's pretty certain that all non-compliant implementations are gone. This can take a while, even if you assume people update promptly, due to things like Firefox "ESR" releases (Extended Support for businesses, schools, etc). Thes are valid for most of a year, and if we land ndata support right after one is created it could be closer to 1-1.5 years before if even starts to reach clients - and it may take even more time for all ESR users to approve/test it and update. The arguments about having all the apps be required to implement their own fragmentation, etc for a considerable period adds lots of complexity to the apps. Implementing the PPID chunking as the stopgap (and retiring it once ndata is universal) means the API to the application remains stable and simple. Since all DataChannel implementations must implement queuing of JS send()s (since the SCTP bufferspace may be full), it's easy to support PPID fragmentation if you don't worry about memory-use optimization). ndata not being available yet highlights this issue. >> min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size). It does not allow us to expand the size to any useful Blob size. > Please note that you never have a limitation of the receive buffer send size, since SCTP > would use partial delivery. So other-sides-max-receive-size is only relevant if there are > buffering limits on top of SCTP. I was referring to the SDP value for "minimum value I guarantee receiving". We would need to specify that if ndata is agreed to (I presume we know that) that the application would be told an "infinite" value for max-I-can-receive (since we can't use the value from the SDP, as that predates the two sides creating the association and negotiating ndata). I don't want to renegotiate just to remove the max SCTP receive size. Randell -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Mon Mar 3 03:46:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96371A001A for ; Mon, 3 Mar 2014 03:46:16 -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 TI6ud44PYFMN for ; Mon, 3 Mar 2014 03:46:12 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAF61A0010 for ; Mon, 3 Mar 2014 03:46:12 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1605 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKRJx-000EvW-Et for rtcweb@ietf.org; Mon, 03 Mar 2014 05:46:09 -0600 Message-ID: <53146B2C.8080008@jesup.org> Date: Mon, 03 Mar 2014 06:44:44 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060303070001080209080008" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WKJhfxnmhX03uTEIIQcz-OEbXAA Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 11:46:17 -0000 This is a multi-part message in MIME format. --------------060303070001080209080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/3/2014 6:18 AM, Justin Uberti wrote: > > > On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup > wrote: > > On 3/2/2014 4:27 PM, Justin Uberti wrote: >> I'm not sure I understand the actual problem here. We *are* going >> to handle arbitrary-sized messages once ndata gets done. The >> max-msg-size stuff is just a solution until ndata is deployed. >> (To cite your options, this is A followed by C). > > So, here's where I think there may be a disconnect (and if I'm > wrong, great): > > ndata solves the monopolization issue between streams, allowing > packets for different streams to be interleaved on the wire. It > does not (so far as I know) relax the usrsctp library's returning > EMSGSIZE if the sendto() is larger than available buffer space, > and the alternative (EOR mode) doesn't allow for interleaving of > messages when sending at all (and I'm not sure it allows > interleaving on reception either, but I didn't check right now). > > Now, this is an implementation/API issue which could be fixed with > some work, but so far as I know no work has been done on it. So > ndata will allow us to expand the max-sending size to > min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size). It does > not allow us to expand the size to any useful Blob size. > > > Based on the discussion of ndata/eor in followup messages, I think > this problem will be addressed in the near future. Hopefully so, though I hate forcing apps to include a bunch of code for backwards compat for a year or two (and many won't, or won't test it, etc). That hurts the feature. And today no one has ndata. > >> That said, Send(blob) seems like a bit of a footgun to me anyway; >> I think apps are going to typically avoid it, a) to avoid memory >> bloat, and b) to get progress indications. The only way out of >> that situation is to provide stream semantics, which seems like a >> lot to take on given that WebSockets hasn't gone that route. I >> also agree that we shouldn't try to go the (B) route that you >> mention. > > Well, Streams would be a good thing once they're done. Progress > indication could be added at the W3 level without much problem. > The memory issue should be resolvable in a number of ways, per my > discussion with Sicking. Note that application chunking has a > serious memory issue today in that the File Writer API hasn't been > agreed to; I think there's progress towards eventually adopting a > version of the Filesystem API (with changes), but that will be a > while. Again, Stream should help - and note that the semantics > for Blob reception allow it to be written to disk as it's received > and not held entirely in memory when it's handed to the > application, which is NOT possible today for application chunking. > > > Agree Streams will be useful when done, but that's probably post-1.0 > (as Martin says, we should first let it be applied to WebSockets). > However I don't think app chunking will have any memory problems - the > chunks will be small enough that they can be easily spooled to disk as > they come in. Agree on Streams (post 1.0). Chunking does have memory problems unless you have a File Writer API (we don't) or a Filesystem API (we don't, though my understanding is that we believe that with some changes this can be adoptable in the future). You have two choices today for app chunking (and I assume using blob slices for sending chunks): 1) create a blob from each received chunk then then create a new blob from the concatenation of all the sub-blobs. This requires a large memory hit, though I suppose in theory maybe it could be done without a hit (painfully). Even if the memory hit is avoided there will be a large disk IO hit to merge all those files and write a new file from them. 2) hold all the parts in memory, then write the entire thing as a blob after the last part is received. Large memory and disk IO hit on reception of final part. > >> >> So I still think manual chunking seems like a reasonable thing to >> support. I don't quite get the congestion control concerns; just >> because there is a max chunk size doesn't mean the impl can't >> buffer multiple chunks in bufferedAmount; the app could let that >> fill up to a degree to avoid having to poll constantly to prevent >> underrun. > > On a slow link this will work if the browser isn't janky. On a > fast link GC pauses and other things may cause the buffer to drain > out and go idle for significant periods. > > > Since the amount buffered is up to the app, the app can just increase > the buffer size to provide enough data to cover the next second or so > of transfer. How does the app increase the size of the internal SCTP buffers? (And that buffer is shared by all channels, of course). > Note that app chunking will clearly be needed in some of the more > interesting cases we want to support, such as where the transfer is > not 1:1. For swarm-style downloading, we need to make sure app > chunking works well (and I think it does). Agreed, we need good solutions for application chunking (and thus my interest in resolving the Filesystem API issues in the W3). My problem is that we don't have those today for the reception side - but this (for apps that *need* chunking) is largely a W3 issue. -- Randell Jesup -- rjesup a t mozilla d o t com --------------060303070001080209080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/3/2014 6:18 AM, Justin Uberti wrote:


On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 3/2/2014 4:27 PM, Justin Uberti wrote:
I'm not sure I understand the actual problem here. We *are* going to handle arbitrary-sized messages once ndata gets done. The max-msg-size stuff is just a solution until ndata is deployed. (To cite your options, this is A followed by C).

So, here's where I think there may be a disconnect (and if I'm wrong, great):

ndata solves the monopolization issue between streams, allowing packets for different streams to be interleaved on the wire.  It does not (so far as I know) relax the usrsctp library's returning EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now).

Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it.  So ndata will allow us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size).  It does not allow us to expand the size to any useful Blob size.

Based on the discussion of ndata/eor in followup messages, I think this problem will be addressed in the near future.

Hopefully so, though I hate forcing apps to include a bunch of code for backwards compat for a year or two (and many won't, or won't test it, etc).  That hurts the feature.  And today no one has ndata.

  

That said, Send(blob) seems like a bit of a footgun to me anyway; I think apps are going to typically avoid it, a) to avoid memory bloat, and b) to get progress indications. The only way out of that situation is to provide stream semantics, which seems like a lot to take on given that WebSockets hasn't gone that route. I also agree that we shouldn't try to go the (B) route that you mention.

Well, Streams would be a good thing once they're done. Progress indication could be added at the W3 level without much problem.  The memory issue should be resolvable in a number of ways, per my discussion with Sicking.  Note that application chunking has a serious memory issue today in that the File Writer API hasn't been agreed to; I think there's progress towards eventually adopting a version of the Filesystem API (with changes), but that will be a while.  Again, Stream should help - and note that the semantics for Blob reception allow it to be written to disk as it's received and not held entirely in memory when it's handed to the application, which is NOT possible today for application chunking.

Agree Streams will be useful when done, but that's probably post-1.0 (as Martin says, we should first let it be applied to WebSockets). However I don't think app chunking will have any memory problems - the chunks will be small enough that they can be easily spooled to disk as they come in.

Agree on Streams (post 1.0).  Chunking does have memory problems unless you have a File Writer API (we don't) or a Filesystem API (we don't, though my understanding is that we believe that with some changes this can be adoptable in the future).  You have two choices today for app chunking (and I assume using blob slices for sending chunks):

1) create a blob from each received chunk then then create a new blob from the concatenation of all the sub-blobs.  This requires a large memory hit, though I suppose in theory maybe it could be done without a hit (painfully).  Even if the memory hit is avoided there will be a large disk IO hit to merge all those files and write a new file from them.

2) hold all the parts in memory, then write the entire thing as a blob after the last part is received.  Large memory and disk IO hit on reception of final part.



So I still think manual chunking seems like a reasonable thing to support. I don't quite get the congestion control concerns; just because there is a max chunk size doesn't mean the impl can't buffer multiple chunks in bufferedAmount; the app could let that fill up to a degree to avoid having to poll constantly to prevent underrun.

On a slow link this will work if the browser isn't janky.  On a fast link GC pauses and other things may cause the buffer to drain out and go idle for significant periods.

Since the amount buffered is up to the app, the app can just increase the buffer size to provide enough data to cover the next second or so of transfer.

How does the app increase the size of the internal SCTP buffers?  (And that buffer is shared by all channels, of course).

Note that app chunking will clearly be needed in some of the more interesting cases we want to support, such as where the transfer is not 1:1. For swarm-style downloading, we need to make sure app chunking works well (and I think it does).

Agreed, we need good solutions for application chunking (and thus my interest in resolving the Filesystem API issues in the W3).  My problem is that we don't have those today for the reception side - but this (for apps that *need* chunking) is largely a W3 issue.


-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------060303070001080209080008-- From nobody Mon Mar 3 04:10:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7D81A0079 for ; Mon, 3 Mar 2014 04:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpkd0_cWPS_W for ; Mon, 3 Mar 2014 04:10:43 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D7D751A0069 for ; Mon, 3 Mar 2014 04:10:42 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EB2731C0E97AE; Mon, 3 Mar 2014 13:10:38 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5314669C.3090301@jesup.org> Date: Mon, 3 Mar 2014 12:10:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <6C3E8CBC-9EC4-4222-8073-7D7903FEC38A@fh-muenster.de> <5314669C.3090301@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VajrGMRrJU_s2GasO0YDnBPnJhQ Cc: rtcweb@ietf.org, Randall Stewart Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 12:10:46 -0000 On 03 Mar 2014, at 11:25, Randell Jesup wrote: > On 3/3/2014 1:53 AM, Michael Tuexen wrote: >> On 03 Mar 2014, at 02:42, Randell Jesup = wrote: >>=20 >>=20 >>> EMSGSIZE if the sendto() is larger than available buffer space, and = the alternative (EOR mode) doesn't allow for interleaving of messages = when sending at all (and I'm not sure it allows interleaving on = reception either, but I didn't check right now). >> If you want to send messages larger than the socket send buffer, you = must use the explicit >> EOR more. This is independent from using NDATA or not. >=20 > right. >=20 >> If you use NDATA, you can have on each outgoing stream a single = message (order or unordered) >> being sent using explicit EOR mode and the calls can be interleaved. = I don't think I have >> tested this up to know, but this is how it should work. >>=20 >> rrs@: Just to double check: Am I right? Please note that RTCWeb = doesn't use ordered and >> unordered on the same stream, and you don't need to send more = than one message with >> explicit EOR on the same stream at the same time. Therefore the = above simplification... >=20 > If this is the case, this should deal with the issue I believe, with = one caveat for the W3 layer: >=20 > If we can only send one at a time, we get an issue where we call = channel.send(blob1); channel.send(blob2); >=20 > the JS interface to send() is synchronous and can't block. This = implies that if send(blob1) hasn't completed, the send(blob2) can't = start, and all following send()s must also be buffered in memory. For a = blob, since a blob reference is read-only, this is likely ok (need to = verify what happens if we haven't read the blob into memory - if this = isn't the case, we have a problem). For sending an ArrayBuffer (or = string), we'll have to snapshot the buffer at send() time if it's queued = since the referenced data may change. However, this really isn't = anything that new, since if the SCTP buffers are full you have to do = something similar anyways, even without any messages using = fragmentation. >=20 > I presume from your comment (since it wasn't entirely clear) that if I = have channel.send(blob1); channel.send("foo") that "foo" can't be sent = until blob1 has been fully transmitted (has hit EOR at the send side), = even though "foo" doesn't require fragmentation, and so all send()s for = a channel during a fragmented send() must be copied and queued. Correct. And if you are on an ordered channel, there is no alternative, = right? On an unordered, you can't interleave messages on a single stream... >=20 >>> Now, this is an implementation/API issue which could be fixed with = some work, but so far as I know no work has been done on it. So ndata = will allow us to expand the max-sending size to >> This API work is part of getting NDATA implemented. Randall has = implemented it, we do have >> code, but it needs some testing and cleaning up in the API which = supports the scheduling... >=20 > So the last issue would be backwards compatibility. If today an app = must be written to query (via an unspecified W3 property) the max size = you can reliably send() to the other side, then it must buy into (and = test!) that functionality now and until it's pretty certain that all = non-compliant implementations are gone. This can take a while, even if = you assume people update promptly, due to things like Firefox "ESR" = releases (Extended Support for businesses, schools, etc). Thes are = valid for most of a year, and if we land ndata support right after one = is created it could be closer to 1-1.5 years before if even starts to = reach clients - and it may take even more time for all ESR users to = approve/test it and update. >=20 > The arguments about having all the apps be required to implement their = own fragmentation, etc for a considerable period adds lots of complexity = to the apps. Implementing the PPID chunking as the stopgap (and = retiring it once ndata is universal) means the API to the application = remains stable and simple. Since all DataChannel implementations must = implement queuing of JS send()s (since the SCTP bufferspace may be = full), it's easy to support PPID fragmentation if you don't worry about = memory-use optimization). ndata not being available yet highlights this = issue. >=20 >>> min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size). It does = not allow us to expand the size to any useful Blob size. >> Please note that you never have a limitation of the receive buffer = send size, since SCTP >> would use partial delivery. So other-sides-max-receive-size is only = relevant if there are >> buffering limits on top of SCTP. >=20 > I was referring to the SDP value for "minimum value I guarantee = receiving". Understood. My point was the following: If NDATA is not yet supported, the sender can choose a message limit to = avoid monopolisation. It is a sender side thing. So any limit the receiver is enforcing and communicating via SDP is for = different reasons. So if we agree on support for arbitrary size messages when we = have NDATA, then there is ne need to negotiate a message size limit. The = sender just enforces whatever he things is appropriate to mitigate monopolisation. >=20 > We would need to specify that if ndata is agreed to (I presume we know = that) that the application would be told an "infinite" value for = max-I-can-receive (since we can't use the value from the SDP, as that = predates the two sides creating the association and negotiating ndata). = I don't want to renegotiate just to remove the max SCTP receive size. Correct. See my above statement. Why negotiate at all if we agree on the = receiver being able to handle arbitrary size messages? Best regards Michael >=20 > Randell >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 >=20 From nobody Mon Mar 3 04:22:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E1F1A00AB for ; Mon, 3 Mar 2014 04:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EmyyftPZNWL for ; Mon, 3 Mar 2014 04:22:44 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCC01A00A8 for ; Mon, 3 Mar 2014 04:22:44 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1D3D21C0E97AE; Mon, 3 Mar 2014 13:22:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Mon, 3 Mar 2014 12:22:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3D616A97-C717-4EED-B7C7-9DBBE7D0B908@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D16D2BA@ESESSMB209.ericsson.se> <52FAF2A9.9070507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16E5F0@ESESSMB209.ericsson.se> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Cnlz4JmzzEu1yOCSA3zfhKJOQ6Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Comment on section 6 title 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, 03 Mar 2014 12:22:46 -0000 On 12 Feb 2014, at 18:56, Makaraju, Maridi Raju (Raju) = wrote: >> Hi, >>=20 >>> I suggest that this just be called "Data Channel", not "WebRTC Data >> Channel". (Or pick some other neutral name - perhaps SCTP Data = Channel.) >>=20 >> Agree. A more generic name would be useful. >>=20 >> "Simple Data Channel" >> "Simple SCTP Data Channel" >> Etc... >=20 > [Raju] How about "Application Data Channel"? What about: "The Usage of SCTP for Data Channels" Best regards Michael >=20 >> (But it would still make sense for the JS API to have a = WebRTC-specific name.) > +1 >=20 > -raju >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Mar 3 04:43:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961CE1A00AA for ; Mon, 3 Mar 2014 04:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy-nHox1Hg1i for ; Mon, 3 Mar 2014 04:43:20 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id ED7EC1A00A9 for ; Mon, 3 Mar 2014 04:43:19 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 70ADB1C103E61; Mon, 3 Mar 2014 13:43:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53093EB6.5080500@alum.mit.edu> Date: Mon, 3 Mar 2014 12:43:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1E36BE76-1A27-47F1-B020-8E67483C181D@lurchi.franken.de> References: <53093EB6.5080500@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RtxE2Aezn776qZj2T6mT3kECElE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07 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, 03 Mar 2014 12:43:22 -0000 On 23 Feb 2014, at 00:20, Paul Kyzivat wrote: > (Catching up before the meeting) > Here are some comments on the latest version. There don't necessarily = relate to recent changes. Rather they come from my perspective trying to = use this for CLUE, whether using a webrtc endpoint or not. >=20 > * Section 5: >=20 > This section says: >=20 > Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed to SCTP by its upper layer and sent > to its peer. This value can be used to multiplex multiple protocols > over a single SCTP association. The sender provides for each > protocol a specific PPID and the receiver can demultiplex the > messages based on the received PPID. The PPID is used to = distinguish > UTF-8 encoded user data and binary encoded userdata. The Data > Channel Establishment Protocol defined in > [I-D.ietf-rtcweb-data-protocol] uses also a specific PPID to be > distinguished from user data. >=20 > The language has proved extremely confusing to several people who = haven't followed the development and discussion of this from the = beginning. It is because of the extreme ambiguity in the use of = "protocol". While I guess we can't rename PPID, the other language could = be clarified. >=20 > The problem is that we have SCTP protocol, "WebRTC Data Channel = Establishment Protocol", and within the DATA_CHANNEL_OPEN message of the = WebRTC Data Channel Establishment Protocol we have a "Protocol" field. >=20 > We also have layering of protocols and implementations. So it isn't = clear above who "sender" and "receiver" above apply to. (Could be code = that is calling the SCTP stack, or code that is calling the "data = channel stack", or the browser, or a javascript application on top of = browser. >=20 > IIUC, javascript users don't have any visibility to the PPID. But = others implementing data channels may. >=20 > How about: >=20 > Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed to SCTP by the data channel layer > and sent to its peer. This value is used to multiplex WebRTC Data > Channel Establishment Protocol messages (defined in = [I-D.ietf-rtcweb- > data-protocol]) with messages containing user data on a data > channel. The PPID is also used to distinguish UTF-8 encoded user > data and binary encoded user data. The above text has changed in the meantime due to comments. It currently = reads: Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side. The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association. In the WebRTP context, the PPID is used to distinguish between UTF-8 encoded user data, binary encoded userdata and the Data Channel Establishment Protocol defined in . Please note that the PPID is not accessible via the Javascript API. Does this address your issues? >=20 > Also in this section is Figure 2 that shows layering. I'm unclear if = "WEBRTC DATA" in intended to include rtcweb-data-protocol or not. That = is defined in a separate draft, is mandatory to support but optional to = use. So it could go either way. Might be good to clarify: >=20 >=20 > +---------+ > |CHANNEL | > |PROTOCOL | > +---------+ > |DATA | > |CHANNEL | > +---------+ > | SCTP | > +-----------------------+ > | STUN | SRTP | DTLS | > +-----------------------+ > | ICE | > +-----------------------+ > | UDP1 | UDP2 | ... | > +-----------------------+ Hmm. What about using +------+------+------+ | DCEP | UTF-8|Binary| | | data | data | +------+------+------+ | SCTP | +----------------------------------+ | STUN | SRTP | DTLS | +----------------------------------+ | ICE | +----------------------------------+ | UDP1 | UDP2 | ... | +----------------------------------+ which also makes clear how the PPID is used to multiplex/demultiplex the = different upper layers? >=20 > * Section 6.5 >=20 > This section contains: >=20 > Data channels can be opened by using internal or external > negotiation. The details are out of scope of this document. >=20 > A simple protocol for internal negotiation is specified in > [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >=20 > But internal and external negotiation are not defined in this = document. >=20 > I *thought* that internal negotiation was by definition negotiation by = use of rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 = thinks so too, but calls it "in-band negotiation".) We can use in-band and out-of-band negotiation >=20 > There should be a good definition of these terms, or reference to one. = And more discussion if there can be other kinds of internal negotiation. = (If so, how would one be chosen?) Up to now, there is no other way.... Would you prefer that? >=20 > * Section 6.6: >=20 > Say: >=20 > All data sent on a Channel in both directions MUST be sent over the > underlying stream using the reliability defined when the Channel was > opened unless the options are changed, or per-message options are > specified by a higher level. >=20 > Is the recipient to consider it an error if messages are received with = options different from those defined for the channel? Please note that the receiver could double the the ordering. The = receiver could also detect that messages have been abandoned on ordered streams, but not on = unordered. For successfully delivered messages, the receiver can not detect if the = message was sent reliably or not. There is no explicit way for the receiver to = verify the PR SCTP policy or the corresponding value. So I would vote for ignoring... >=20 > Also, is it an error if messages are received with a PPID that isn't = specified in Section 8? (And what about PPID 50?) >=20 > How are such channel errors to be treated? Reset the channel? Do we want to specify that? >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Mar 3 04:46:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8BD1A009E for ; Mon, 3 Mar 2014 04:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_b7NzNKIL5H for ; Mon, 3 Mar 2014 04:46:38 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 393C21A0090 for ; Mon, 3 Mar 2014 04:46:38 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CD6561C1042F2; Mon, 3 Mar 2014 13:46:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B89F8@ESESSMB209.ericsson.se> Date: Mon, 3 Mar 2014 12:46:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5B3CAD36-6C87-4FA6-B9A3-FFB0A181AE9F@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D16D2A3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1B89F8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ri_pq6_Q8vZwLEZib4F7wcF24Ik Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5 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, 03 Mar 2014 12:46:40 -0000 On 25 Feb 2014, at 10:48, Christer Holmberg = wrote: > Hi, >=20 >>> Q1: >>>=20 >>> Section 5 says: >>>=20 >>> "SCTP as specified in [RFC4960] MUST be used in >>> combination with the extension defined in [RFC3758] and provides = the >>> following interesting features for transporting non-media data >>> between browsers:" >>>=20 >>> I suggest to say: >>>=20 >>> "The SCTP extension defined in [RFC3758] MUST be supported, and >>> provides the following features: >>>=20 >> But this implies that the listed features are provided by the = extension defined in RFC 3758, which is not true. The features are = provided by the combination of RFC 4960 and RFC 3758. >=20 > Correct. My mistake. >=20 > So, my suggestion would then be to remove "as specified in" and = "interesting". >=20 > "SCTP [RFC4960] MUST be used in combination with the extension = defined in [RFC3758] and=20 > provides the following features for transporting non-media data = between browsers:" >=20 > The reference implicitly means "as specified in", in my opinon :) Removed the 'interesting'. The document use a 'as specified in' or similar text in several places. = For consistency it should be removed in all places. So I kept it for now to be = consistent. Best regards Michael >=20 > ---------- >=20 >>> Q3: >>>=20 >>> Section 5 says: >>>=20 >>> "This value can be used to multiplex multiple protocols >>> over a single SCTP association. The sender provides for each >>> protocol a specific PPID and the receiver can demultiplex the >>> messages based on the received PPID." >>>=20 >>> I think we discussed this earlier. The PPID value CAN NOT (at least = not as used by WebRTC) be used to multiplex multiple protocols=20 >>> over a single SCTP association. If you create multiple channels, for = multiple protocols, the same PPID values may be used for each protocol. >>>=20 >>> The PPID CAN, however, be used within a data channel, e.g. to = demultiplex the DCP from channel data. >>=20 >> I guess the problem is that I consider 'protocol' as something = running on top of SCTP like DCEP, Binary of String data, you consider = 'protocol'=20 >> as something running on top of Binary of String data and the = 'protocol' being identified in the JS protocol string. >>=20 >> What about using: >>=20 >> Each SCTP user message contains a Payload Protocol Identifier = (PPID) that is passed to SCTP by its upper layer on the sending side and = provided to its upper layer on the receiving side. >> The PPID can be used to multiplex/demultiplex multiple upper layers = over a single SCTP association. >> In the WebRTP context, the PPID is used to distinguish between >> UTF-8 encoded user data, binary encoded userdata and the Data Channel = Establishment Protocol defined in . >> Please note that the PPID is not accessable via the Javascript = API. >>=20 >> Does this address your issue? >=20 > Instead of talking about SCTP associations, could we talk about data = channels? I.e. the PPID can be used to multiplex/demultiplex multiple = upper layers within a single data channel? >=20 > Because, if you have multiple data channels on a single SCTP = association, you will use the stream IDs - not the PPIDs - to = multiplex/demultiplex between the channels. >=20 > ---------- >=20 >>> Q5: >>>=20 >>> Sometimes you say "SCTP" and sometimes "SCTP as defined in = [RFC4960]". >>>=20 >>> I suggest to e.g. use the reference on the first occurrence, and = then only use "SCTP". >>=20 >> I double checked: >> SCTP as defined in [RFC4960] is used in >> * In the Introduction (first occurrence) talking about SCTP / UDP >> * In the Introduction to make sure which specifications are used: RFC = 4960 and RFC 3758 >=20 > In the 2nd paragraph of the Introduction, the text says: >=20 > "SCTP as specified in [RFC4960] with the partial reliability = extension defined in [RFC3758]" >=20 > Could you remove "as specified in", and say? >=20 > "SCTP [RFC4960] with the partial reliability extension defined = in [RFC3758]" >=20 >=20 >> * In section 5 when used with RFC 2119 language. >=20 > I still think you could remove "as specified in", and say: >=20 > "SCTP [RFC4960] MUST be used in combination with the extension = defined..." >=20 >> * In section 6 to make clear what relates to RFC 4960 and what to the = NDATA extension. >>=20 >> All of these are intentional. Which one do you think is not = necessary? >=20 > In section 6.6, I think you could remove "specified in", and say: >=20 > "The SCTP base protocol [RFC4960]..." >=20 >=20 > I am not religious about these things, but again: in my opinion adding = the reference means "as specified in", and makes the text easier to read = :) >=20 > Regards, >=20 > Christer >=20 >=20 From nobody Mon Mar 3 05:25:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80271A0103; Mon, 3 Mar 2014 05:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoaAw75X0hs7; Mon, 3 Mar 2014 05:25:32 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A70581A00FB; Mon, 3 Mar 2014 05:25:30 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403031425262808; Mon, 03 Mar 2014 14:25:26 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'IESG IESG'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Date: Mon, 3 Mar 2014 14:25:22 +0100 Message-ID: <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgACxezCAB08LAIAAQ40g Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8T21VNRONb3a4BiMKE_biaP-H8U Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 03 Mar 2014 13:25:36 -0000 Cullen, Illution I am checking the IETF archive for links - Memory you know... I feel I also have an email from Harald to answer You will not see the below /Kalle Allt v=E4l -----Ursprungligt meddelande----- Fr=E5n: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Skickat: den 3 mars 2014 10:22 Till: 'Cullen Jennings (fluffy)'; 'IESG IESG' Kopia: 'Magnus Westerlund'; 'Simon Perreault'; 'Ted Hardie'; 'Gonzalo Camarillo'; 'rtcweb@ietf.org'; 'tram@ietf.org'; 'Spencer Dawkins' =C4mne: SV: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Hi Cullen, Memory may be an illusion, still I cannot understand how there can be an ever growing archive in the IETF /Karl Allt v=E4l Hi Cullen, Not to cause more lost in the threads (I am also) I am addressing both = your emails in one, and copy separately to the other guys in the first email. = Further Inline --> >From http://www.ietf.org/mail-archive/web/tram/current/msg00275.html Let me also point out draft-deng-tram-isp-turn-00 http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European carrier and = the cable operators in general - CableLabs) have expressed similar concerns = to me *=93This is exactly something we want to work on as the current way = will cause severe problem on traffic when rtcweb applications get popular=94* = is a direct quote from one of those. So, in answer to Simon Perreault [simon.perreault at viagenie.ca]=92s = question in another thread the 13th: a) Is this a real problem that is worth fixing? I think we can be confident that the answer is *YES*. Only these three ISP/NSP referred to, may represent 50%(?) of the universe=92s IP = accesses! And the other will follow these most forward looking carriers.=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] Skickat: den 26 februari 2014 01:49 Till: Karl Stahl Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; = David Singer; Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; Henning Schulzrinne =C4mne: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > Karl,=20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to > be the point of debate, = and what your view is on what we should do. I think that would help make progress.=20 > Thank you,=20 > Cullen I just did something like that in: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html=20 Hoping this thread subject amplifies what this SHOULD be about. (An how = it will lead to the summary, after all diversion.) Actually, the outcome of "Interfacing to QoS" will be=20 I challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem = IX78 that implements such CLEAR INTERFACE and the actual QoS methods, for = both the Congestion, Default gateway, Surf Pipe=20 Manipulating the RTP extension header etc etc on 6 USD CPU and also = include the ADSL part where that quality handling is based on heavy 57 bytes chopping up at this exact=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 02:06 Till: Karl Stahl; IESG IESG Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo = Camarillo; rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins =C4mne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers. > =20 Reading the charter, the above is *not* at all a clear objective of the = WG (note I am not the chair of this WG or the responsible AD).=20 That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP for routing updates over TURN it would be within the scope of this charter.=20 My advice to the responsible AD is recharter this WG before IETF 90 or = close it. I would be glad to help write a charter that is not an infinite = blank cheque.=20 From nobody Mon Mar 3 05:29:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D96D1A0132 for ; Mon, 3 Mar 2014 05:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 HF2ctRTPg245 for ; Mon, 3 Mar 2014 05:29:17 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1451A0123 for ; Mon, 3 Mar 2014 05:29:17 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so3556457vcb.31 for ; Mon, 03 Mar 2014 05:29:14 -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=52gZCBKmwyCNRAcejFGBTzQpxMxp39S77uIuQWdo6TA=; b=RPhcZ+b1qQeeNd0bJpUU0GlmFeJQWLCGUm8hCS5du34fwIkYmqC/0vAMk3zQKaF/Ff YrxH45FtZeOIuZOOsY7/5hBtVlL4+dp3oGs/ejl0Pb06dpjilUQsHrYs+hJwUAuAbR0m j8feS4vQABW0m3BS4h2iMXKz08aTol565z1lHO/mKJd/OedeOudMmQCke/B4b3O2gGDy K5rUYG778k74eIPJnrHCXLnLOeBjiOQN3gzgemWqtEfTnE2B4Q88yN0hVT+D+krT7U+x zzOpFf7p7CeTs5JifccITSk/yIWJ1kJ3kiPvAOEc3NME7eFeTCdkHdKSa0w3oN9iLlN5 Uf1w== 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=52gZCBKmwyCNRAcejFGBTzQpxMxp39S77uIuQWdo6TA=; b=ltKuVoDRmYW1z2/FLMv31FC79CpkX1ZJmd6zBdC9Br+oDXsjCg8iweGpH3JqoxQCk4 P6bUJkI8WFdT4v38dBRoRaPNJQoUKHU6DDsmpMJtoGk6UWi0Ztd7n3gAI9KpPvs5MwH2 o83WOzpghR2hP97xD/Crgasu+ZxchaYq2j92/21ngksudj9wwrsdwPdwgmj37GT/z8Ag Ja0Lv8kQvuK70r/i7YxClME9ngdaGi9cb9RPKJDrfqlpgsERgGYVpMXbikjvJIUtiQSG 4TPb71RlRHDEN8Fe8jhzy75jVjtPRS20jkwCkeLtppFphUUu/CVhEwcKbuPtn1OPtHiO xsPg== X-Gm-Message-State: ALoCoQkGnWUxKxyFlzUgynW2Y2Ytrnx2lkZ6TvDcnFoc+QqJTJwBV6kSxaaZHrLH3mRzXcG1kYaXa0qJHhEsgl9Uu8n8YvKCmNcUegOhns7YlYxwHYqH08xmLSiZVUdsSTZNubJdf2+XIabio/9t+T4kpD0Cu6Nwkt0d/d8iNjw8fqc0ZFLPYojgx4YRF71mAhLxGHBfTxVF X-Received: by 10.58.37.67 with SMTP id w3mr17228619vej.22.1393853354138; Mon, 03 Mar 2014 05:29:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 05:28:54 -0800 (PST) In-Reply-To: <53146B2C.8080008@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> From: Justin Uberti Date: Mon, 3 Mar 2014 05:28:54 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=089e013a0d420af76e04f3b3c611 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Iy0gIwn18KAsnYVB36kHgGxCC0U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 13:29:20 -0000 --089e013a0d420af76e04f3b3c611 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup wrote: > On 3/3/2014 6:18 AM, Justin Uberti wrote: > > > > On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup wrote: > >> On 3/2/2014 4:27 PM, Justin Uberti wrote: >> >> I'm not sure I understand the actual problem here. We *are* going to >> handle arbitrary-sized messages once ndata gets done. The max-msg-size >> stuff is just a solution until ndata is deployed. (To cite your options, >> this is A followed by C). >> >> >> So, here's where I think there may be a disconnect (and if I'm wrong, >> great): >> >> ndata solves the monopolization issue between streams, allowing packets >> for different streams to be interleaved on the wire. It does not (so far >> as I know) relax the usrsctp library's returning EMSGSIZE if the sendto() >> is larger than available buffer space, and the alternative (EOR mode) >> doesn't allow for interleaving of messages when sending at all (and I'm not >> sure it allows interleaving on reception either, but I didn't check right >> now). >> >> Now, this is an implementation/API issue which could be fixed with some >> work, but so far as I know no work has been done on it. So ndata will >> allow us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, >> other-sides-max-receive-size). It does not allow us to expand the size to >> any useful Blob size. >> > > Based on the discussion of ndata/eor in followup messages, I think this > problem will be addressed in the near future. > > > Hopefully so, though I hate forcing apps to include a bunch of code for > backwards compat for a year or two (and many won't, or won't test it, > etc). That hurts the feature. And today no one has ndata. > > > > >> >> That said, Send(blob) seems like a bit of a footgun to me anyway; I >> think apps are going to typically avoid it, a) to avoid memory bloat, and >> b) to get progress indications. The only way out of that situation is to >> provide stream semantics, which seems like a lot to take on given that >> WebSockets hasn't gone that route. I also agree that we shouldn't try to go >> the (B) route that you mention. >> >> >> Well, Streams would be a good thing once they're done. Progress >> indication could be added at the W3 level without much problem. The memory >> issue should be resolvable in a number of ways, per my discussion with >> Sicking. Note that application chunking has a serious memory issue today >> in that the File Writer API hasn't been agreed to; I think there's progress >> towards eventually adopting a version of the Filesystem API (with changes), >> but that will be a while. Again, Stream should help - and note that the >> semantics for Blob reception allow it to be written to disk as it's >> received and not held entirely in memory when it's handed to the >> application, which is NOT possible today for application chunking. >> > > Agree Streams will be useful when done, but that's probably post-1.0 (as > Martin says, we should first let it be applied to WebSockets). However I > don't think app chunking will have any memory problems - the chunks will be > small enough that they can be easily spooled to disk as they come in. > > > Agree on Streams (post 1.0). Chunking does have memory problems unless > you have a File Writer API (we don't) or a Filesystem API (we don't, though > my understanding is that we believe that with some changes this can be > adoptable in the future). You have two choices today for app chunking (and > I assume using blob slices for sending chunks): > > 1) create a blob from each received chunk then then create a new blob from > the concatenation of all the sub-blobs. This requires a large memory hit, > though I suppose in theory maybe it could be done without a hit > (painfully). Even if the memory hit is avoided there will be a large disk > IO hit to merge all those files and write a new file from them. > > 2) hold all the parts in memory, then write the entire thing as a blob > after the last part is received. Large memory and disk IO hit on reception > of final part. > > > >> >> So I still think manual chunking seems like a reasonable thing to >> support. I don't quite get the congestion control concerns; just because >> there is a max chunk size doesn't mean the impl can't buffer multiple >> chunks in bufferedAmount; the app could let that fill up to a degree to >> avoid having to poll constantly to prevent underrun. >> >> >> On a slow link this will work if the browser isn't janky. On a fast >> link GC pauses and other things may cause the buffer to drain out and go >> idle for significant periods. >> > > Since the amount buffered is up to the app, the app can just increase > the buffer size to provide enough data to cover the next second or so of > transfer. > > > How does the app increase the size of the internal SCTP buffers? (And > that buffer is shared by all channels, of course). > What I meant is the app can make multiple calls to send() at a time, each with a chunk, which will be buffered in the api layer and increase bufferedAmount. > > > Note that app chunking will clearly be needed in some of the more > interesting cases we want to support, such as where the transfer is not > 1:1. For swarm-style downloading, we need to make sure app chunking works > well (and I think it does). > > > Agreed, we need good solutions for application chunking (and thus my > interest in resolving the Filesystem API issues in the W3). My problem is > that we don't have those today for the reception side - but this (for apps > that *need* chunking) is largely a W3 issue. > > > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e013a0d420af76e04f3b3c611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup <= ;randell-ietf@j= esup.org> wrote:
=20 =20 =20
On 3/3/2014 6:18 AM, Justin Uberti wrote:


On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 3/2/2014 4:27 PM, Justin Uberti wrote:
I'm not sure I understand the actu= al problem here. We *are* going to handle arbitrary-sized messages once ndata gets done. The max-msg-size stuff is just a solution until ndata is deployed. (To cite your options, this is A followed by C).

So, here's where I think there may be a disconnect (and if I'm wrong, great):

ndata solves the monopolization issue between streams, allowing packets for different streams to be interleaved on the wire.=C2=A0 It does not (so far as I know) relax the usrsctp library's returning EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now).

Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it.=C2=A0 So ndata will allow us to expand the max-sending size to min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size).=C2=A0 It does not allow us t= o expand the size to any useful Blob size.

Based on the discussion of ndata/eor in followup messages, I think this problem will be addressed in the near future.

Hopefully so, though I hate forcing apps to include a bunch of code for backwards compat for a year or two (and many won't, or won'= t test it, etc).=C2=A0 That hurts the feature.=C2=A0 And today no one has= ndata.


=C2=A0=C2=A0

That said, Send(blob) seems like a bit of a footgun to me anyway; I think apps are going to typically avoid it, a) to avoid memory bloat, and b) to get progress indications. The only way out of that situation is to provide stream semantics, which seems like a lot to take on given that WebSockets hasn't gone that route. I also agree that we shouldn't try to go the (B) route that you mention.

Well, Streams would be a good thing once they're done. Progress indication could be added at the W3 level without much problem.=C2=A0 The memory issue should be resolvable in a number of ways, per my discussion with Sicking.=C2=A0 Note that application chunking has a serious memory issue today in that the File Writer API hasn't been agreed to; I think there's progress towards eventually adopting a version of the Filesystem API (with changes), but that will be a while.=C2=A0 Again, Stre= am should help - and note that the semantics for Blob reception allow it to be written to disk as it's received and not held entirely in memory when it's handed to the application, which is NOT possible today for application chunking.

Agree Streams will be useful when done, but that's probably post-1.0 (as Martin says, we should first let it be applied to WebSockets). However I don't think app chunking will have any memory problems - the chunks will be small enough that they can be easily spooled to disk as they come in.

Agree on Streams (post 1.0).=C2=A0 Chunking does have memory problems unless you have a File Writer API (we don't) or a Filesystem API (w= e don't, though my understanding is that we believe that with some changes this can be adoptable in the future).=C2=A0 You have two choice= s today for app chunking (and I assume using blob slices for sending chunks):

1) create a blob from each received chunk then then create a new blob from the concatenation of all the sub-blobs.=C2=A0 This requires a large memory hit, though I suppose in theory maybe it could be done without a hit (painfully).=C2=A0 Even if the memory hit is avoided ther= e will be a large disk IO hit to merge all those files and write a new file from them.

2) hold all the parts in memory, then write the entire thing as a blob after the last part is received.=C2=A0 Large memory and disk IO hi= t on reception of final part.




So I still think manual chunking seems like a reasonable thing to support. I don't quite get the congestion control concerns; just because there is a max chunk size doesn't mean the impl can't buffer multiple chunks in bufferedAmount; the app could let that fill up to a degree to avoid having to poll constantly to prevent underrun.

On a slow link this will work if the browser isn't janky.=C2=A0 On a fast link GC pauses and other things may cause the buffer to drain out and go idle for significant periods.

Since the amount buffered is up to the app, the app can just increase the buffer size to provide enough data to cover the next second or so of transfer.

How does the app increase the size of the internal SCTP buffers?=C2=A0 (And that buffer is shared by all channels, of course).

What I meant is the app can make multiple calls to s= end() at a time, each with a chunk, which will be buffered in the api layer= and increase bufferedAmount.


Note that app chunking will clearly be needed in some of the more interesting cases we want to support, such as where the transfer is not 1:1. For swarm-style downloading, we need to make sure app chunking works well (and I think it does).

Agreed, we need good solutions for application chunking (and thus my interest in resolving the Filesystem API issues in the W3).=C2=A0 My problem is that we don't have those today for the reception side - but this (for apps that *need* chunking) is largely a W3 issue.



--=20
Randell Jesup -- rjesup a t mozilla d o t com

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


--089e013a0d420af76e04f3b3c611-- From nobody Mon Mar 3 05:31:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEA31A0145 for ; Mon, 3 Mar 2014 05:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 qUJF8ncb5GZ6 for ; Mon, 3 Mar 2014 05:31:27 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF0F1A0139 for ; Mon, 3 Mar 2014 05:31:26 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id lg15so3500739vcb.26 for ; Mon, 03 Mar 2014 05:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WoqBwtsjKd0j5upjJDmzJP7PI2If2hu+2fU/e5rOAWE=; b=XXmAZnEDAUWcdOxFwKSUw18veQcmWhZaYUHv7qa1y7JUU+dEjuSHTouMAo+LOVHMX6 mN12jc9u42SKjMIw0V5moEd59/MHZwSsx4NrvJJIPRoZrX3/NCzdP87s+5CT383OVqrg mKSoiZPfbL76tMbEAglK5fVnZRoEMqRYViwMm3OifoyRmMtAIMsvz5rGYcYWwMaC9DRg PNDkwfQzbswSGtZ2cJwXLzDW+PU/kmHicuniy7vfREJ/+bHXro3bCZYwVRzRWxDkIJUg TpmDsJZWlBqfmuchL59mJkjqzQeO0gXy2yOEEfdiAG+oXQHveii3HukUfuY8V8BH49mK J7NQ== 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=WoqBwtsjKd0j5upjJDmzJP7PI2If2hu+2fU/e5rOAWE=; b=HUE8GBbJK1B08BR1bNQWyPLBAVM7VW8mttakbQaggY+xbp1g4SrGRxRP6+ljcZbPbx R+sIl1J2RG3AvOKww6b5tUIx8c4/dCbeySIJbC9BD44ida3aCqnt9USIQ8rilMMfOQTz /25pm6VFpeBQBtOsCi8uNqsIN8DCEsl1elrPgJ+apcScWADwpM1r7hr6a8BpVQHkpJjf CxLGApGRemEl9dA07/YOm9tAIumVbfpv4b+19cnSS3vPdAW4KxV81jShWWgkzxwnPZ72 YUFrQukBZsaRg5sXPxD1ASV6ulBaODGtiwBSI4c5cKJ1XZsim66u7MbC75Y8TND7bvBf yRPg== X-Gm-Message-State: ALoCoQmiM4ktu2FuvOSJaqPtiVJFv32W+ETV0LyvPG4eGAOrTJ7egvTGuSnmDCzPb9csldvkdgD7qowBzLE11RxFfgeVOk4L+hQ9CkR29GFzXNCdvMOaKCstzsGKgRgPt70NGCpEzQrj02DrlUQfqVb+QjCo8d0JR8HQGmuwZ1QPn1959LIAKoT+oJ/GxvYtzxds6rS/vYZs X-Received: by 10.220.11.141 with SMTP id t13mr7217639vct.30.1393853483881; Mon, 03 Mar 2014 05:31:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 05:31:03 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1C5BDE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C5BDE@ESESSMB209.ericsson.se> From: Justin Uberti Date: Mon, 3 Mar 2014 05:31:03 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3c970c6bb2904f3b3cdb3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hvgw6ET7r2_UhfzxY5jCaGgb7r8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? 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, 03 Mar 2014 13:31:32 -0000 --001a11c3c970c6bb2904f3b3cdb3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 3, 2014 at 2:30 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > As specified in BUNDLE, before the remote peer has indicated support of > BUNDLE, all m- lines (including those within to a bundle group) must have > unique port numbers. > > Then, when the remote peer has indicated support of BUNDLE, a second offe= r > (called the BAS offer) needs to be sent, in which the same port number is > assigned to all m- lines within a bundle group. > > My question is: how do I create the BAS offer? I don=E2=80=99t want to ch= ange > anything =E2=80=93 I just want to get an SDP with the BUNDLE port assigne= d to all > m- lines. Is there a flag in createOffer() for that? > > The implementation knows that any offers that are created after the > BUNDLE answer should have the same port numbers. So, the app could push t= he > createOffer button once it receives the answer if it wanted to ensure thi= s > happened immediately. Otherwise, there will be an onnegotiationneeded eve= nt > once ICE completes, and the offer sent at that time will have the updated > ports. > > > > When I call createOffer(), can I be ensure that *only* the port values > will change? > > > No. Why would this be necessary? --001a11c3c970c6bb2904f3b3cdb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 3, 2014 at 2:30 AM, Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:

Hi,<= /p>

As specified in BUNDLE, before = the remote peer has indicated support of BUNDLE, all m- lines (including th= ose within to a bundle group) must have unique port numbers.=C2=A0

Then, when the remote peer has = indicated support of BUNDLE, a second offer (called the BAS offer) needs to= be sent, in which the same port number is assigned to all m- lines within a bundle group.

My question is: how do I create= the BAS offer? I don=E2=80=99t want to change anything =E2=80=93 I just wa= nt to get an SDP with the BUNDLE port assigned to all m- lines. Is there a flag in createOffer() for that?

The implementation knows that any offers that are cr= eated after the BUNDLE answer should have the same port numbers. So, the ap= p could push the createOffer button once it receives the answer if it wante= d to ensure this happened immediately. Otherwise, there will be an onnegotiationneeded event once ICE completes, = and the offer sent at that time will have the updated ports.<= /p>

=C2=A0

When I call c= reateOffer(), can I be ensure that only the port values will change?

=C2=A0

<= /div>

No. Why= would this be necessary?=C2=A0
--001a11c3c970c6bb2904f3b3cdb3-- From nobody Mon Mar 3 05:32:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EB01A013F; Mon, 3 Mar 2014 05:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 lAUkKuoY9II8; Mon, 3 Mar 2014 05:32:17 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5766C1A0139; Mon, 3 Mar 2014 05:32:16 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-8b-5314845b648b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C7.87.10875.B5484135; Mon, 3 Mar 2014 14:32:11 +0100 (CET) Received: from [131.160.126.237] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.347.0; Mon, 3 Mar 2014 14:32:10 +0100 Message-ID: <5314845A.2060100@ericsson.com> Date: Mon, 3 Mar 2014 13:32:10 +0000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl , "'Cullen Jennings (fluffy)'" , 'IESG IESG' References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se> In-Reply-To: <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW50i0iwwfdTphYdk9ksZvyZyGzx rmctm8Xaf+3sFt1L/7NYNM61s/iw9gKbA7vHlN8bWT12zrrL7rFkyU8mj09b57N4rPtgHsAa xWWTkpqTWZZapG+XwJXx5vg0loK1+hWfVjxmaWC8rNrFyMkhIWAi0bHzNhOELSZx4d56ti5G Lg4hgUOMEo8m9DJCOGsYJRomLmcDqeIV0JbYuXEuUAcHB4uAisSk5mqQMJuAhcSWW/dZQGxR gSiJn1cWsEOUC0qcnPkELC4iUC7x78oBVhCbWWALo8S2z0EgtjDI/K5zyhC7nrFI9O7eCNbA KeAgsfjmMnaQXRIC4hI9jUEQvXoSU662MELY8hLNW2czg9hCQKctf9bCMoFRaBaS1bOQtMxC 0rKAkXkVI3tuYmZOernhJkZg0B/c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwJh381PMqz3L1++LunGj8vXedYyTjzmtOij8ceYqg0V89ie/tPrEXpj7 Q7nliqG8fo936pozR6SWa/Oc+nb03NolAtPKCsXmyHg9T30R4/uUQV4sTtKyN+/G5crwVb/z mddU1fX1s9Vf/TXJ/uxKt9u95zIXbX10tlTNIILblO2FgmfQIbP1pZpKLMUZiYZazEXFiQAm 5f4ASAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mKOc5mMB66OSEsncSpXJYtyY4rs Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 03 Mar 2014 13:32:20 -0000 Karl, speaking as RAI AD and TRAM WG chair: note that our policy is to avoid cross-posting to several mailing lists. The reason is that doing so may make it more difficult for people who are subscribed to several lists to follow the discussions. Also, messages with too many requirements are moderated and need to be manually approved by the admins of each list. Therefore, from now on, please choose only *one* mailing list; preferably one where the discussions you intend to have are within its scope. Thanks, Gonzalo On 03/03/2014 1:25 PM, Karl Stahl wrote: > Cullen, > > Illution > I am checking the IETF archive for links - Memory you know... > I feel I also have an email from Harald to answer > > > > > You will not see the below > /Kalle > Allt väl > -----Ursprungligt meddelande----- > Från: Karl Stahl [mailto:karl.stahl@intertex.se] > Skickat: den 3 mars 2014 10:22 > Till: 'Cullen Jennings (fluffy)'; 'IESG IESG' > Kopia: 'Magnus Westerlund'; 'Simon Perreault'; 'Ted Hardie'; 'Gonzalo > Camarillo'; 'rtcweb@ietf.org'; 'tram@ietf.org'; 'Spencer Dawkins' > Ämne: SV: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter > Clarification regardig Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs > > Hi Cullen, > > Memory may be an illusion, still I cannot understand how there can be an > ever growing archive in the IETF > > /Karl > > Allt väl > Hi Cullen, > > Not to cause more lost in the threads (I am also) I am addressing both your > emails in one, and copy separately to the other guys in the first email. > > Further Inline --> > >>From http://www.ietf.org/mail-archive/web/tram/current/msg00275.html > Let me also point out draft-deng-tram-isp-turn-00 > http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from China > Mobile that appeared on this mailing list yesterday. It points out the need > and willingness from the ISP/NSP side to do something about QoS for WebRTC > traffic, that they expect to be large and have to bring to their customers > with best QoE. In fact they and some more (a huge European carrier and the > cable operators in general - CableLabs) have expressed similar concerns to > me *"This is exactly something we want to work on as the current way will > cause severe problem on traffic when rtcweb applications get popular"* is a > direct quote from one of those. > > So, in answer to Simon Perreault [simon.perreault at viagenie.ca]'s question > in another thread the 13th: > a) Is this a real problem that is worth fixing? > I think we can be confident that the answer is *YES*. Only these three > ISP/NSP referred to, may represent 50%(?) of the universe's IP accesses! And > the other will follow these most forward looking carriers. > > > -----Ursprungligt meddelande----- > Från: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Skickat: den 26 februari 2014 01:49 > Till: Karl Stahl > Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; David > Singer; Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; > Henning Schulzrinne > Ämne: Re: [rtcweb] [tram] I-D Action: > draft-thomson-tram-turn-bandwidth-00.txt > > >> Karl, > >> I am totally lost on this thread. Could you start a new tmead that > summarize what the issues is, what seems to > be the point of debate, and > what your view is on what we should do. I think that would help make > progress. > >> Thank you, > >> Cullen > > I just did something like that in: > [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 > IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff > http://www.ietf.org/mail-archive/web/tram/current/msg00331.html > Hoping this thread subject amplifies what this SHOULD be about. (An how it > will lead to the summary, after all diversion.) > > Actually, the outcome of "Interfacing to QoS" will be > > > I challenge anyone that this will be outcome, and will start "Interfacing to > QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem IX78 > that implements such CLEAR INTERFACE and the actual QoS methods, for both > the Congestion, Default gateway, Surf Pipe > Manipulating the RTP extension header etc etc on 6 USD CPU and also include > the ADSL part where that quality handling is based on heavy 57 bytes > chopping up > at this exact > > > > > -----Ursprungligt meddelande----- > Från: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Skickat: den 26 februari 2014 02:06 > Till: Karl Stahl; IESG IESG > Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo; > rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins > Ämne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter > Clarification regardig Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs > > > > On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > >> To the TRAM WG and RTCWEB WG and ADs: >> >> It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed and > encouraged to route quality demanding WebRTC media into their IP pipes that > are capable of transporting real-time traffic without quality issues, using > TURN servers. >> > > Reading the charter, the above is *not* at all a clear objective of the WG > (note I am not the chair of this WG or the responsible AD). > > That said, I think you have pointed out this charter is abysmally vague - it > does not say what the WG is not going to do. If I decided to do BGP for > routing updates over TURN it would be within the scope of this charter. > > My advice to the responsible AD is recharter this WG before IETF 90 or close > it. I would be glad to help write a charter that is not an infinite blank > cheque. > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Mon Mar 3 05:48:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4781A0197 for ; Mon, 3 Mar 2014 05:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 R5fwujUmWQ2V for ; Mon, 3 Mar 2014 05:48:35 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E00E71A0171 for ; Mon, 3 Mar 2014 05:48:32 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-53-5314882cf974 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 16.C9.10875.C2884135; Mon, 3 Mar 2014 14:48:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 14:48:27 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: JSEP-06: How to create the second offer where only the port numbers are changed? Thread-Index: Ac8xgmHR3mZq1KQqQbqrDgGDhayzRAE1nSgAABypJXAABD1xgAACqajg Date: Mon, 3 Mar 2014 13:48:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C63D2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C5BDE@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_7594FB04B1934943A5C02806D1A2204B1D1C63D2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja5uh0iwwRJhi61ThSzW/mtnd2Dy WLCp1GPJkp9MAUxRXDYpqTmZZalF+nYJXBlT13awFPzwqDg8awtTA+MXty5GTg4JAROJy69e MEPYYhIX7q1nA7GFBA4xSkxaWtLFyAVkL2aUODC9m7WLkYODTcBCovufNkiNiICaxMNZu1hB bGYBdYk7i8+xg9jCAvESX28+ZIKoSZBY92k6C4TtJrHo5Xyw+SwCKhIv236wgIzkFfCV6N3G ArFqPpPEittzwGZyCgRKNBzsBOtlBLrt+6k1TBC7xCVuPZnPBHGzgMSSPeeh7heVePn4HyuE rSTRuOQJ2MnMAvkS35q5QMK8AoISJ2c+YZnAKDoLyaRZCFWzkFRBhDUl1u/Sh6hWlJjS/ZAd wtaQaJ0zlx1ZfAEj+ypG9tzEzJz0csNNjMAoOrjlt+4OxlPnRA4xSnOwKInzfnjrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBcQrzAibXPxMSdokmLix68OjVnJe9e3oil7ns3F7wy3Cv c4DqxQ1rmWVbnRVPM+54/LPy4Iu+5TX3F6Yuf7THu3fiTuX4Bo8/r0sq4qK0YnetPCU55/1W Edcntu/CFhw/sGPJH+lgh7Pnnl00fSMp3sJxfYvmzyd/H+6oF/13bF35mXcFNz99SpimxFKc kWioxVxUnAgAbd5YjXACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pcMfE8Xb1F4r8MTI0uIGEJihsQA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? 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, 03 Mar 2014 13:48:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1C63D2ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpBcyBzcGVjaWZpZWQgaW4gQlVORExFLCBiZWZvcmUgdGhlIHJlbW90ZSBwZWVyIGhhcyBp bmRpY2F0ZWQgc3VwcG9ydCBvZiBCVU5ETEUsIGFsbCBtLSBsaW5lcyAoaW5jbHVkaW5nIHRob3Nl IHdpdGhpbiB0byBhIGJ1bmRsZSBncm91cCkgbXVzdCBoYXZlIHVuaXF1ZSBwb3J0IG51bWJlcnMu DQpUaGVuLCB3aGVuIHRoZSByZW1vdGUgcGVlciBoYXMgaW5kaWNhdGVkIHN1cHBvcnQgb2YgQlVO RExFLCBhIHNlY29uZCBvZmZlciAoY2FsbGVkIHRoZSBCQVMgb2ZmZXIpIG5lZWRzIHRvIGJlIHNl bnQsIGluIHdoaWNoIHRoZSBzYW1lIHBvcnQgbnVtYmVyIGlzIGFzc2lnbmVkIHRvIGFsbCBtLSBs aW5lcyB3aXRoaW4gYSBidW5kbGUgZ3JvdXAuDQpNeSBxdWVzdGlvbiBpczogaG93IGRvIEkgY3Jl YXRlIHRoZSBCQVMgb2ZmZXI/IEkgZG9u4oCZdCB3YW50IHRvIGNoYW5nZSBhbnl0aGluZyDigJMg SSBqdXN0IHdhbnQgdG8gZ2V0IGFuIFNEUCB3aXRoIHRoZSBCVU5ETEUgcG9ydCBhc3NpZ25lZCB0 byBhbGwgbS0gbGluZXMuIElzIHRoZXJlIGEgZmxhZyBpbiBjcmVhdGVPZmZlcigpIGZvciB0aGF0 Pw0KVGhlIGltcGxlbWVudGF0aW9uIGtub3dzIHRoYXQgYW55IG9mZmVycyB0aGF0IGFyZSBjcmVh dGVkIGFmdGVyIHRoZSBCVU5ETEUgYW5zd2VyIHNob3VsZCBoYXZlIHRoZSBzYW1lIHBvcnQgbnVt YmVycy4gU28sIHRoZSBhcHAgY291bGQgcHVzaCB0aGUgY3JlYXRlT2ZmZXIgYnV0dG9uIG9uY2Ug aXQgcmVjZWl2ZXMgdGhlIGFuc3dlciBpZiBpdCB3YW50ZWQgdG8gZW5zdXJlIHRoaXMgaGFwcGVu ZWQgaW1tZWRpYXRlbHkuIE90aGVyd2lzZSwgdGhlcmUgd2lsbCBiZSBhbiBvbm5lZ290aWF0aW9u bmVlZGVkIGV2ZW50IG9uY2UgSUNFIGNvbXBsZXRlcywgYW5kIHRoZSBvZmZlciBzZW50IGF0IHRo YXQgdGltZSB3aWxsIGhhdmUgdGhlIHVwZGF0ZWQgcG9ydHMuDQpXaGVuIEkgY2FsbCBjcmVhdGVP ZmZlcigpLCBjYW4gSSBiZSBlbnN1cmUgdGhhdCBvbmx5IHRoZSBwb3J0IHZhbHVlcyB3aWxsIGNo YW5nZT8NCg0KTm8uIFdoeSB3b3VsZCB0aGlzIGJlIG5lY2Vzc2FyeT8NCg0KQmVjYXVzZSB0aGUg b25seSB0aGluZyBJIHdhbnQgdG8gZG8gaXMgdG8gc2VuZCBhIG5ldyBvZmZlciwgd2l0aCB0aGUg c2FtZSBwb3J0IG51bWJlciBpbiBlYWNoIG0tIGxpbmUuIEkgZG9u4oCZdCB3YW50IGFueXRoaW5n IGVsc2UgdG8gY2hhbmdlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K --_000_7594FB04B1934943A5C02806D1A2204B1D1C63D2ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpyZWQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHNwZWNpZmllZCBpbiBC VU5ETEUsIGJlZm9yZSB0aGUgcmVtb3RlIHBlZXIgaGFzIGluZGljYXRlZCBzdXBwb3J0IG9mIEJV TkRMRSwgYWxsIG0tIGxpbmVzIChpbmNsdWRpbmcgdGhvc2Ugd2l0aGluIHRvIGEgYnVuZGxlIGdy b3VwKSBtdXN0IGhhdmUgdW5pcXVlIHBvcnQNCiBudW1iZXJzLiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZW4s IHdoZW4gdGhlIHJlbW90ZSBwZWVyIGhhcyBpbmRpY2F0ZWQgc3VwcG9ydCBvZiBCVU5ETEUsIGEg c2Vjb25kIG9mZmVyIChjYWxsZWQgdGhlIEJBUyBvZmZlcikgbmVlZHMgdG8gYmUgc2VudCwgaW4g d2hpY2ggdGhlIHNhbWUgcG9ydCBudW1iZXIgaXMgYXNzaWduZWQNCiB0byBhbGwgbS0gbGluZXMg d2l0aGluIGEgYnVuZGxlIGdyb3VwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk15IHF1ZXN0aW9uIGlzOiBob3cgZG8gSSBj cmVhdGUgdGhlIEJBUyBvZmZlcj8gSSBkb27igJl0IHdhbnQgdG8gY2hhbmdlIGFueXRoaW5nIOKA kyBJIGp1c3Qgd2FudCB0byBnZXQgYW4gU0RQIHdpdGggdGhlIEJVTkRMRSBwb3J0IGFzc2lnbmVk IHRvIGFsbCBtLSBsaW5lcy4gSXMgdGhlcmUNCiBhIGZsYWcgaW4gY3JlYXRlT2ZmZXIoKSBmb3Ig dGhhdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIGltcGxlbWVudGF0aW9uIGtub3dzIHRoYXQgYW55IG9mZmVycyB0aGF0IGFyZSBj cmVhdGVkIGFmdGVyIHRoZSBCVU5ETEUgYW5zd2VyIHNob3VsZCBoYXZlIHRoZSBzYW1lIHBvcnQg bnVtYmVycy4gU28sIHRoZSBhcHAgY291bGQgcHVzaCB0aGUgY3JlYXRlT2ZmZXIgYnV0dG9uIG9u Y2UgaXQgcmVjZWl2ZXMNCiB0aGUgYW5zd2VyIGlmIGl0IHdhbnRlZCB0byBlbnN1cmUgdGhpcyBo YXBwZW5lZCBpbW1lZGlhdGVseS4gT3RoZXJ3aXNlLCB0aGVyZSB3aWxsIGJlIGFuIG9ubmVnb3Rp YXRpb25uZWVkZWQgZXZlbnQgb25jZSBJQ0UgY29tcGxldGVzLCBhbmQgdGhlIG9mZmVyIHNlbnQg YXQgdGhhdCB0aW1lIHdpbGwgaGF2ZSB0aGUgdXBkYXRlZCBwb3J0cy48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPldoZW4gSSBjYWxsIGNyZWF0ZU9mZmVyKCksIGNhbiBJIGJlIGVuc3VyZSB0aGF0DQo8Yj5v bmx5PC9iPiB0aGUgcG9ydCB2YWx1ZXMgd2lsbCBjaGFuZ2U/PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Oby4gV2h5IHdvdWxkIHRoaXMgYmUgbmVjZXNzYXJ5PyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPkJl Y2F1c2UgdGhlIG9ubHkgdGhpbmcgSSB3YW50IHRvIGRvIGlzIHRvIHNlbmQgYSBuZXcgb2ZmZXIs IHdpdGggdGhlIHNhbWUgcG9ydCBudW1iZXIgaW4gZWFjaCBtLSBsaW5lLiBJIGRvbuKAmXQgd2Fu dCBhbnl0aGluZyBlbHNlIHRvIGNoYW5nZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D1C63D2ESESSMB209erics_-- From nobody Mon Mar 3 05:53:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42B51A0194 for ; Mon, 3 Mar 2014 05:53:13 -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 xfiA_x18hIZN for ; Mon, 3 Mar 2014 05:53:12 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 443411A0175 for ; Mon, 3 Mar 2014 05:53:12 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1788 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKTIr-0001rt-8H for rtcweb@ietf.org; Mon, 03 Mar 2014 07:53:09 -0600 Message-ID: <531488F0.7090300@jesup.org> Date: Mon, 03 Mar 2014 08:51:44 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020203070104000208010204" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZzgjXHxKINxi12ClxysQ1majCR4 Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 13:53:14 -0000 This is a multi-part message in MIME format. --------------020203070104000208010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/3/2014 8:28 AM, Justin Uberti wrote: > On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup > wrote: > > On 3/3/2014 6:18 AM, Justin Uberti wrote: >> On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup >> > wrote: >>> >>> So I still think manual chunking seems like a reasonable thing >>> to support. I don't quite get the congestion control concerns; >>> just because there is a max chunk size doesn't mean the impl >>> can't buffer multiple chunks in bufferedAmount; the app could >>> let that fill up to a degree to avoid having to poll constantly >>> to prevent underrun. >> >> On a slow link this will work if the browser isn't janky. On >> a fast link GC pauses and other things may cause the buffer >> to drain out and go idle for significant periods. >> >> >> Since the amount buffered is up to the app, the app can just >> increase the buffer size to provide enough data to cover the next >> second or so of transfer. > > How does the app increase the size of the internal SCTP buffers? > (And that buffer is shared by all channels, of course). > > > What I meant is the app can make multiple calls to send() at a time, > each with a chunk, which will be buffered in the api layer and > increase bufferedAmount. Aha - that explains "increase the buffer size". Yes, that will work, modulo that the app will have to track the actual bandwidth by either monitoring how fast the bufferedAmount drains, or via a JS API to report bandwidth ala the bug I opened on JS interaction with congestion control. I still feel this pushes some level of congestion control into the JS app (and done like trying to thread needles with oven mitts on - ok, mild exaggeration) or the app will simply ignore this issue (likely) and get sub-optimal performance, perhaps significantly. So I think more thought would be useful here, especially at the W3/JS level. If we have the bandwidth reporting, having the app choose a reasonable amount of buffering would be much easier/simpler. -- Randell Jesup -- rjesup a t mozilla d o t com --------------020203070104000208010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/3/2014 8:28 AM, Justin Uberti wrote:
On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 3/3/2014 6:18 AM, Justin Uberti wrote:
On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup <randell-ietf@jesup.org> wrote:

So I still think manual chunking seems like a reasonable thing to support. I don't quite get the congestion control concerns; just because there is a max chunk size doesn't mean the impl can't buffer multiple chunks in bufferedAmount; the app could let that fill up to a degree to avoid having to poll constantly to prevent underrun.

On a slow link this will work if the browser isn't janky.  On a fast link GC pauses and other things may cause the buffer to drain out and go idle for significant periods.

Since the amount buffered is up to the app, the app can just increase the buffer size to provide enough data to cover the next second or so of transfer.

How does the app increase the size of the internal SCTP buffers?  (And that buffer is shared by all channels, of course).

What I meant is the app can make multiple calls to send() at a time, each with a chunk, which will be buffered in the api layer and increase bufferedAmount.

Aha - that explains "increase the buffer size".  Yes, that will work, modulo that the app will have to track the actual bandwidth by either monitoring how fast the bufferedAmount drains, or via a JS API to report bandwidth ala the bug I opened on JS interaction with congestion control.  I still feel this pushes some level of congestion control into the JS app (and done like trying to thread needles with oven mitts on - ok, mild exaggeration) or the app will simply ignore this issue (likely) and get sub-optimal performance, perhaps significantly.  So I think more thought would be useful here, especially at the W3/JS level.

If we have the bandwidth reporting, having the app choose a reasonable amount of buffering would be much easier/simpler.
-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------020203070104000208010204-- From nobody Mon Mar 3 05:54:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693491A0185 for ; Mon, 3 Mar 2014 05:54:02 -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 PQ4pA5sQcX_K for ; Mon, 3 Mar 2014 05:54:01 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 174471A0175 for ; Mon, 3 Mar 2014 05:54:00 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id w62so1417362wes.0 for ; Mon, 03 Mar 2014 05:53:57 -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=/0NX/u/UFdlWKT8QfopBMsmYEKWLSUuy92N97xiqrJk=; b=K7DZRnnnko3nNqjWkNjcuEqcfiB5WFaIJkAyjTcI2yNwpuzO5KW1vzkZfzw2B94Xiz qzUpCYCck3AQuH9LTENT33ed2zC9F3Fho4NjHQ2IaDTAxKyUJBV4Tt9qY7ZBKXPs+8zt lYLbEuG4P9NmfWAlOSY7w64v61Ea1s+Qdrh+wo61OeTT12id5RZANwlmU+cwbidHAwqw quhJEsX51aaNrcSxU1oimAXPlCL0KQLCqYxihYxZWvasKsQLhRXOBdjd29D2LRRNQJCM L47UJqN4l5xEYcl0BiuzPvV7Rpvk91EloZ6xj0BIZspquyk3f2b+IKNw32IVeOC9EyAl 2n+w== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr2878655wjc.56.1393854837613; Mon, 03 Mar 2014 05:53:57 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 05:53:57 -0800 (PST) In-Reply-To: <53146B2C.8080008@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> Date: Mon, 3 Mar 2014 05:53:57 -0800 Message-ID: From: Martin Thomson To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Lb6vS39DaT5K_fHiFQ3ZRD-paMk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 13:54:02 -0000 On 3 March 2014 03:44, Randell Jesup wrote: > Hopefully so, though I hate forcing apps to include a bunch of code for > backwards compat for a year or two (and many won't, or won't test it, etc). > That hurts the feature. And today no one has ndata. Since WebRTC is behind a flag, I don't find this particularly convincing. We can implement ndata. I think that we could even remove our temporary length restriction. From nobody Mon Mar 3 06:13:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447721A012A for ; Mon, 3 Mar 2014 06:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 04OB4OHe8G6g for ; Mon, 3 Mar 2014 06:13:06 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 59C981A0116 for ; Mon, 3 Mar 2014 06:13:06 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hu8so3692146vcb.1 for ; Mon, 03 Mar 2014 06:13:03 -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=FKTif9Ta+/Y4RiZWNeIz0Mxvu0ifKvnZx1LqYvxjCE4=; b=ErhRO+hdWRFf71Dh9V1HyYXDjXl6rQ6I+Js9jjlC2BT2oVhaUkUyq3o/MRHpjJN/dI 5bz1lN71mSV+bj5Mt89D8Wz4udE0/urP0YSYBd1hW2o9R/40vUrZvW9xKdkJX1eR0rZw yU0xbvdGj5tizWlUoIpI4ZePiBcpIF1mYGQf33WGQFsvwOu1L6mQbaMtf6ki2OJU9lqm VPAaYgNzdMKvjlLh1mjqDGI6qXKGTjQzkmrrB2Dz9JKzmj7FGByXhWWthLrAeKDbR8Yg EowhNqpWl1f3o1B0pFXsjJ33D4DxolEgVvY9UigEOXYofBKhjfMNH/bRtlnqlyOu0ZqZ 0Mig== 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=FKTif9Ta+/Y4RiZWNeIz0Mxvu0ifKvnZx1LqYvxjCE4=; b=SqIug3OytaJyKtx+AU9XIX7NJ8ScGinH7dX3veTT0iz6XajfF8duKCNcyp4Eb2NaRe sTMlxER+1SZZ6iiKVvB9o7aJYx+ggVImTBSDVXB5KFvi/XWCLkFOhHbCJfOTYos3JPQX OgyIBBQoE2OW09myhYb44XKwLMs1t94glgoyR3W6wXFVKSYqsNo4iNTU3BqVTG3KbM46 quhBXQsnN3RMq2eOJG7tVhRtDdVPz/QWPhpjy8HXO0bhlUQ2/KBF32eY6ee3gth4cVpt 1A9auIe/j0NYNqu+Rfngo3atJxfamHYTjZzLtkN5N6ZetGDVonSjtHb604rU5ShEl/fi N4VA== X-Gm-Message-State: ALoCoQm/zBLWi3TB1Yyoi8MHr3DHhhKzG8aDoRsMXbAvFO6u8WlK6n2pITZHPQZ28JIZnMkMlRG01sCh0ZmT1uPYObi3AMYp+bh5wBMSS6wzbRcANI7zbGuvDl72KHi2ps3d1LTjs+eYFjMEQo26PR2oPd9UwOjMwjuejTannN6BsC4AVGWfb08IDOHfQPhkipg95cKIxOXs X-Received: by 10.52.83.229 with SMTP id t5mr115743vdy.91.1393855983178; Mon, 03 Mar 2014 06:13:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 06:12:43 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1C63D2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C5BDE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C63D2@ESESSMB209.ericsson.se> From: Justin Uberti Date: Mon, 3 Mar 2014 06:12:43 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1136b114beee7e04f3b46297 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1oJ2kmUEZ1o8ogP8w4iqr17wgF8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? 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, 03 Mar 2014 14:13:08 -0000 --001a1136b114beee7e04f3b46297 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But why is it a problem if other things change (e.g. a=3Dremote-candidates = is set)? On Mon, Mar 3, 2014 at 5:48 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > As specified in BUNDLE, before the remote peer has indicated support > of BUNDLE, all m- lines (including those within to a bundle group) must > have unique port numbers. > > Then, when the remote peer has indicated support of BUNDLE, a second offe= r > (called the BAS offer) needs to be sent, in which the same port number is > assigned to all m- lines within a bundle group. > > My question is: how do I create the BAS offer? I don=E2=80=99t want to ch= ange > anything =E2=80=93 I just want to get an SDP with the BUNDLE port assigne= d to all > m- lines. Is there a flag in createOffer() for that? > > The implementation knows that any offers that are created after the > BUNDLE answer should have the same port numbers. So, the app could push t= he > createOffer button once it receives the answer if it wanted to ensure thi= s > happened immediately. Otherwise, there will be an onnegotiationneeded eve= nt > once ICE completes, and the offer sent at that time will have the updated > ports. > > When I call createOffer(), can I be ensure that *only* the port values > will change? > > > > No. Why would this be necessary? > > > > Because the only thing I want to do is to send a new offer, with the same > port number in each m- line. I don=E2=80=99t want anything else to change= . > > > > Regards, > > > > Christer > --001a1136b114beee7e04f3b46297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But why is it a problem if other things change (e.g. a=3Dr= emote-candidates is set)?


On Mon, Mar 3, 2014 at 5:48 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

As specified in BUNDLE, before = the remote peer has indicated support of BUNDLE, all m- lines (including th= ose within to a bundle group) must have unique port numbers.=C2=A0

Then, when the remote peer has = indicated support of BUNDLE, a second offer (called the BAS offer) needs to= be sent, in which the same port number is assigned to all m- lines within a bundle group.

My question is: how do I create= the BAS offer? I don=E2=80=99t want to change anything =E2=80=93 I just wa= nt to get an SDP with the BUNDLE port assigned to all m- lines. Is there a flag in createOffer() for that?

The implementation knows that any offers that are cr= eated after the BUNDLE answer should have the same port numbers. So, the ap= p could push the createOffer button once it receives the answer if it wanted to ensure this happened immediately. Otherwise, th= ere will be an onnegotiationneeded event once ICE completes, and the offer = sent at that time will have the updated ports.

When I call createOffer()= , can I be ensure that only the port values will change?

=C2=A0

No. Why would this be necessary?=C2=A0=

=C2=A0

Because the only = thing I want to do is to send a new offer, with the same port number in eac= h m- line. I don=E2=80=99t want anything else to change.

=C2=A0

Regards,

=C2=A0

Christer=


--001a1136b114beee7e04f3b46297-- From nobody Mon Mar 3 06:35:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6361A004A for ; Mon, 3 Mar 2014 06:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 fG659_piRyri for ; Mon, 3 Mar 2014 06:35:38 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7472E1A002B for ; Mon, 3 Mar 2014 06:35:37 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-6f-53149335f259 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6F.29.23809.53394135; Mon, 3 Mar 2014 15:35:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 15:35:32 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: JSEP-06: How to create the second offer where only the port numbers are changed? Thread-Index: Ac8xgmHR3mZq1KQqQbqrDgGDhayzRAE1nSgAABypJXAABD1xgAACqajg///2VoD//+mmcA== Date: Mon, 3 Mar 2014 14:35:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C6595@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C5BDE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C63D2@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_7594FB04B1934943A5C02806D1A2204B1D1C6595ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvja7ZZJFggxvTWC22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlPLhxhbHgxBTGikkbZzM1MJ6ZwNjFyMEhIWAi 0d5Q0MXICWSKSVy4t56ti5GLQ0jgEKPExU0HWSCcxYwSRyfPZAdpYBOwkOj+pw3SICKgJvFw 1i5WEJtZQF3izuJz7CC2sEC8xNebD5kgahIk1n2azgJhh0ls/7SBDcRmEVCRuLr1IZjNK+Ar sf/hY0aIXauYJRrvb2QGSXAKBEqsv3eZEcRmBLru+6k1TBDLxCVuPZnPBHG1gMSSPeeZIWxR iZeP/7FC2EoSjUueQB2XL7GpB+JQXgFBiZMzn7BMYBSdhWTULCRls5CUzQJ6mVlAU2L9Ln2I EkWJKd0P2SFsDYnWOXPZkcUXMLKvYmTPTczMSS832sQIjKiDW36r7mC8c07kEKM0B4uSOO+H t85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgLl/2fcKj5ZNr/O40Pql3Ov1ItWe7wen7j 7Mi9rst2KXXM23Fou05b0swl6Rwcl38apqQHfdtlVloqfG3e9b88QZ98nzDt+ql+heUtt6h+ ZPOW6782+UkZNC/JCdH0rLhuqxtzx8nS8UvhwQsH/C8nVXC3zSiSP8YS/HpZv/jpiVLfvu/S XrxMiaU4I9FQi7moOBEAW6PvAXYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FWIW36uwvzVWAc9xP2cWSnNJ25w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? 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, 03 Mar 2014 14:35:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1C6595ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2gsIG1heWJlIHNvbWUgdGhpbmdzIGNhbiBjaGFuZ2UuIEFuZCwgQlVORExFIGRv ZXMgbm90IGZvcmJpZCBjaGFuZ2luZyB2YWx1ZXMsIGJ1dCBpdCBkb2VzIHNheSB0aGF0IHRoZSBv ZmZlcmVyIHNob3VsZCBiZSBjYXJlZnVsIHdoZW4gZG9pbmcgc28uDQoNClNlY3Rpb24gNi40LjM6 DQoNCuKAnFRoZSBPZmZlcmVyIE1BWSBtb2RpZnkgYW55IFNEUCBwYXJhbWV0ZXIgaW4gYSBCQVMg T2ZmZXIuDQoNCiAgIE5PVEU6IEl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBCQVMgT2ZmZXIgZ2V0 cyBhY2NlcHRlZCBieSB0aGUNCiAgIEFuc3dlcmVyLCBzbyB0aGUgT2ZmZXJlciBuZWVkcyB0byBj b25zaWRlciB0aGUgbmVjZXNzaXR5IHRvIG1vZGlmeQ0KICAgU0RQIHBhcmFtZXRlcnMgdGhhdCBj b3VsZCBnZXQgdGhlIEFuc3dlcmVyIHRvIHJlamVjdCB0aGUgQkFTIE9mZmVyLg0KICAgUmVtb3Zp bmcgIm09IiBsaW5lcywgb3IgcmVkdWNpbmcgdGhlIG51bWJlciBvZiBjb2RlY3MsIGluIHRoZSBC QVMNCiAgIE9mZmVyIHVzZWQgZm9yIHRoZSBpcyBjb25zaWRlcmVkIHRvIGhhdmUgYSBsb3cgcmlz ayBvZiBiZWluZw0KICAgcmVqZWN0ZWQu4oCdDQoNClNvLCBJIGd1ZXNzIHdoYXQgc2hvdWxkIGJl IGF2b2lkZWQgaXMgYWRkaW5nIG9mIG5ldyBtLSBsaW5lcywgbmV3IGNvZGVjcywgb3IgYW55dGhp bmcgd2hpY2ggbWF5IHRyaWdnZXIgdGhlIGFuc3dlciB0byByZWplY3QgdGhlIG9mZmVyLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0 aUBnb29nbGUuY29tXQ0KU2VudDogMDMgTWFyY2ggMjAxNCAxNjoxMw0KVG86IENocmlzdGVyIEhv bG1iZXJnDQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogSlNFUC0wNjogSG93IHRv IGNyZWF0ZSB0aGUgc2Vjb25kIG9mZmVyIHdoZXJlIG9ubHkgdGhlIHBvcnQgbnVtYmVycyBhcmUg Y2hhbmdlZD8NCg0KQnV0IHdoeSBpcyBpdCBhIHByb2JsZW0gaWYgb3RoZXIgdGhpbmdzIGNoYW5n ZSAoZS5nLiBhPXJlbW90ZS1jYW5kaWRhdGVzIGlzIHNldCk/DQoNCk9uIE1vbiwgTWFyIDMsIDIw MTQgYXQgNTo0OCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aSwNCkFzIHNwZWNpZmllZCBpbiBCVU5ETEUsIGJlZm9yZSB0aGUgcmVtb3RlIHBlZXIgaGFzIGlu ZGljYXRlZCBzdXBwb3J0IG9mIEJVTkRMRSwgYWxsIG0tIGxpbmVzIChpbmNsdWRpbmcgdGhvc2Ug d2l0aGluIHRvIGEgYnVuZGxlIGdyb3VwKSBtdXN0IGhhdmUgdW5pcXVlIHBvcnQgbnVtYmVycy4N ClRoZW4sIHdoZW4gdGhlIHJlbW90ZSBwZWVyIGhhcyBpbmRpY2F0ZWQgc3VwcG9ydCBvZiBCVU5E TEUsIGEgc2Vjb25kIG9mZmVyIChjYWxsZWQgdGhlIEJBUyBvZmZlcikgbmVlZHMgdG8gYmUgc2Vu dCwgaW4gd2hpY2ggdGhlIHNhbWUgcG9ydCBudW1iZXIgaXMgYXNzaWduZWQgdG8gYWxsIG0tIGxp bmVzIHdpdGhpbiBhIGJ1bmRsZSBncm91cC4NCk15IHF1ZXN0aW9uIGlzOiBob3cgZG8gSSBjcmVh dGUgdGhlIEJBUyBvZmZlcj8gSSBkb27igJl0IHdhbnQgdG8gY2hhbmdlIGFueXRoaW5nIOKAkyBJ IGp1c3Qgd2FudCB0byBnZXQgYW4gU0RQIHdpdGggdGhlIEJVTkRMRSBwb3J0IGFzc2lnbmVkIHRv IGFsbCBtLSBsaW5lcy4gSXMgdGhlcmUgYSBmbGFnIGluIGNyZWF0ZU9mZmVyKCkgZm9yIHRoYXQ/ DQpUaGUgaW1wbGVtZW50YXRpb24ga25vd3MgdGhhdCBhbnkgb2ZmZXJzIHRoYXQgYXJlIGNyZWF0 ZWQgYWZ0ZXIgdGhlIEJVTkRMRSBhbnN3ZXIgc2hvdWxkIGhhdmUgdGhlIHNhbWUgcG9ydCBudW1i ZXJzLiBTbywgdGhlIGFwcCBjb3VsZCBwdXNoIHRoZSBjcmVhdGVPZmZlciBidXR0b24gb25jZSBp dCByZWNlaXZlcyB0aGUgYW5zd2VyIGlmIGl0IHdhbnRlZCB0byBlbnN1cmUgdGhpcyBoYXBwZW5l ZCBpbW1lZGlhdGVseS4gT3RoZXJ3aXNlLCB0aGVyZSB3aWxsIGJlIGFuIG9ubmVnb3RpYXRpb25u ZWVkZWQgZXZlbnQgb25jZSBJQ0UgY29tcGxldGVzLCBhbmQgdGhlIG9mZmVyIHNlbnQgYXQgdGhh dCB0aW1lIHdpbGwgaGF2ZSB0aGUgdXBkYXRlZCBwb3J0cy4NCldoZW4gSSBjYWxsIGNyZWF0ZU9m ZmVyKCksIGNhbiBJIGJlIGVuc3VyZSB0aGF0IG9ubHkgdGhlIHBvcnQgdmFsdWVzIHdpbGwgY2hh bmdlPw0KDQpOby4gV2h5IHdvdWxkIHRoaXMgYmUgbmVjZXNzYXJ5Pw0KDQpCZWNhdXNlIHRoZSBv bmx5IHRoaW5nIEkgd2FudCB0byBkbyBpcyB0byBzZW5kIGEgbmV3IG9mZmVyLCB3aXRoIHRoZSBz YW1lIHBvcnQgbnVtYmVyIGluIGVhY2ggbS0gbGluZS4gSSBkb27igJl0IHdhbnQgYW55dGhpbmcg ZWxzZSB0byBjaGFuZ2UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D1C6595ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUt bmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RmFp ciBlbm91Z2gsIG1heWJlIHNvbWUgdGhpbmdzIGNhbiBjaGFuZ2UuIEFuZCwgQlVORExFIGRvZXMg bm90IGZvcmJpZCBjaGFuZ2luZyB2YWx1ZXMsIGJ1dCBpdCBkb2VzIHNheSB0aGF0IHRoZSBvZmZl cmVyIHNob3VsZCBiZQ0KIGNhcmVmdWwgd2hlbiBkb2luZyBzby48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlY3Rpb24gNi40 LjM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij7igJxUaGUgT2ZmZXJlciBNQVkgbW9kaWZ5IGFueSBTRFAgcGFyYW1ldGVyIGluIGEg QkFTIE9mZmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE5PVEU6IEl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBC QVMgT2ZmZXIgZ2V0cyBhY2NlcHRlZCBieSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFuc3dlcmVyLCBzbyB0aGUg T2ZmZXJlciBuZWVkcyB0byBjb25zaWRlciB0aGUgbmVjZXNzaXR5IHRvIG1vZGlmeTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgU0RQIHBhcmFtZXRlcnMgdGhhdCBjb3VsZCBnZXQgdGhlIEFuc3dlcmVyIHRvIHJlamVjdCB0 aGUgQkFTIE9mZmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUmVtb3ZpbmcgJnF1b3Q7bT0mcXVvdDsgbGluZXMsIG9y IHJlZHVjaW5nIHRoZSBudW1iZXIgb2YgY29kZWNzLCBpbiB0aGUgQkFTPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBPZmZl ciB1c2VkIGZvciB0aGUgaXMgY29uc2lkZXJlZCB0byBoYXZlIGEgbG93IHJpc2sgb2YgYmVpbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IHJlamVjdGVkLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28sIEkgZ3Vlc3Mgd2hhdCBzaG91bGQgYmUg YXZvaWRlZCBpcyBhZGRpbmcgb2YgbmV3IG0tIGxpbmVzLCBuZXcgY29kZWNzLCBvciBhbnl0aGlu ZyB3aGljaCBtYXkgdHJpZ2dlciB0aGUgYW5zd2VyIHRvIHJlamVjdCB0aGUNCiBvZmZlci4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRp IFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDAzIE1hcmNo IDIwMTQgMTY6MTM8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6 PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEpTRVAtMDY6IEhv dyB0byBjcmVhdGUgdGhlIHNlY29uZCBvZmZlciB3aGVyZSBvbmx5IHRoZSBwb3J0IG51bWJlcnMg YXJlIGNoYW5nZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHdo eSBpcyBpdCBhIHByb2JsZW0gaWYgb3RoZXIgdGhpbmdzIGNoYW5nZSAoZS5nLiBhPXJlbW90ZS1j YW5kaWRhdGVzIGlzIHNldCk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWFyIDMsIDIwMTQg YXQgNTo0OCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOnJlZCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+QXMgc3BlY2lmaWVkIGluIEJVTkRMRSwgYmVmb3JlIHRoZSByZW1vdGUgcGVlciBoYXMgaW5k aWNhdGVkIHN1cHBvcnQgb2YgQlVORExFLCBhbGwgbS0gbGluZXMgKGluY2x1ZGluZyB0aG9zZSB3 aXRoaW4gdG8gYSBidW5kbGUgZ3JvdXApIG11c3QgaGF2ZSB1bmlxdWUgcG9ydA0KIG51bWJlcnMu Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlbiwgd2hlbiB0aGUgcmVtb3RlIHBlZXIgaGFzIGluZGljYXRlZCBz dXBwb3J0IG9mIEJVTkRMRSwgYSBzZWNvbmQgb2ZmZXIgKGNhbGxlZCB0aGUgQkFTIG9mZmVyKSBu ZWVkcyB0byBiZSBzZW50LCBpbiB3aGljaCB0aGUgc2FtZSBwb3J0IG51bWJlciBpcyBhc3NpZ25l ZA0KIHRvIGFsbCBtLSBsaW5lcyB3aXRoaW4gYSBidW5kbGUgZ3JvdXAuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgcXVl c3Rpb24gaXM6IGhvdyBkbyBJIGNyZWF0ZSB0aGUgQkFTIG9mZmVyPyBJIGRvbuKAmXQgd2FudCB0 byBjaGFuZ2UgYW55dGhpbmcg4oCTIEkganVzdCB3YW50IHRvIGdldCBhbiBTRFAgd2l0aCB0aGUg QlVORExFIHBvcnQgYXNzaWduZWQgdG8gYWxsIG0tIGxpbmVzLiBJcyB0aGVyZQ0KIGEgZmxhZyBp biBjcmVhdGVPZmZlcigpIGZvciB0aGF0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgaW1wbGVtZW50YXRpb24ga25vd3MgdGhhdCBh bnkgb2ZmZXJzIHRoYXQgYXJlIGNyZWF0ZWQgYWZ0ZXIgdGhlIEJVTkRMRSBhbnN3ZXIgc2hvdWxk IGhhdmUgdGhlIHNhbWUgcG9ydCBudW1iZXJzLiBTbywgdGhlIGFwcCBjb3VsZCBwdXNoIHRoZSBj cmVhdGVPZmZlciBidXR0b24gb25jZSBpdCByZWNlaXZlcw0KIHRoZSBhbnN3ZXIgaWYgaXQgd2Fu dGVkIHRvIGVuc3VyZSB0aGlzIGhhcHBlbmVkIGltbWVkaWF0ZWx5LiBPdGhlcndpc2UsIHRoZXJl IHdpbGwgYmUgYW4gb25uZWdvdGlhdGlvbm5lZWRlZCBldmVudCBvbmNlIElDRSBjb21wbGV0ZXMs IGFuZCB0aGUgb2ZmZXIgc2VudCBhdCB0aGF0IHRpbWUgd2lsbCBoYXZlIHRoZSB1cGRhdGVkIHBv cnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4gSSBjYWxs IGNyZWF0ZU9mZmVyKCksIGNhbiBJIGJlIGVuc3VyZSB0aGF0DQo8Yj5vbmx5PC9iPiB0aGUgcG9y dCB2YWx1ZXMgd2lsbCBjaGFuZ2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk5vLiBXaHkgd291bGQgdGhpcyBiZSBuZWNlc3Nhcnk/Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVk Ij5CZWNhdXNlIHRoZSBvbmx5IHRoaW5nIEkgd2FudCB0byBkbyBpcyB0byBzZW5kIGEgbmV3IG9m ZmVyLCB3aXRoIHRoZSBzYW1lIHBvcnQgbnVtYmVyIGluIGVhY2ggbS0gbGluZS4NCiBJIGRvbuKA mXQgd2FudCBhbnl0aGluZyBlbHNlIHRvIGNoYW5nZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpy ZWQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5DaHJpc3Rlcjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D1C6595ESESSMB209erics_-- From nobody Mon Mar 3 06:37:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3250F1A01E1 for ; Mon, 3 Mar 2014 06:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 65HAA4Cf2qtu for ; Mon, 3 Mar 2014 06:37:38 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CF1A01DD for ; Mon, 3 Mar 2014 06:37:36 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ik5so3689161vcb.9 for ; Mon, 03 Mar 2014 06:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MPs0x7JqZqSBsRcIjIcXSTwgRreanCax2HSDxqPt2jI=; b=WrUm/UgRQwVzG4AgNDwM0ebfvHOPQ5+NlxRbqpO59qoq4ds8x1DBYR7oGUygOIDKol A1sNFwYQKQYDHLqP1xOFO4ORIDGDKRUYAG/sNAJ2XS2vqdqc768qGhdSfj+JptoLZ0FJ j2VdUnuEYIF+/Y2CNb6Yq0TGWlamq4mtKjPClgmaIhVKe6/a33p4UXIJBcrDKUFsDFzR B03PqfGhfmmJPen7INjzORP2l6hig6v5yamfH2a82GPo74t/n5VJYiird3uM3Mee6CkQ ibq15aa7Uh4lkWW2L8YjOc7fL7F6UFOi7JSJFDizPBDSaK8gaKZzUXbB6Wn3Bq4o3O2H Wepg== 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=MPs0x7JqZqSBsRcIjIcXSTwgRreanCax2HSDxqPt2jI=; b=Xc0gOWZY2YXW9pzeq789QreEhalPVVVQwSbtug17iDNz2RB+2cKQoUQuqS/8j8zu75 36L4voKl5rwEpRcMSx77eAVNZ2a/2sYh3kK2WsJs4P/PqN2k+unQ8CAqfICeRfsmb7zj J8KqRz+0pomXky5+7pJF/nipFwz7/R5oVHGAVTLYlzOUYWSqz4uzeKFEFcgb023iro8s dnCvLyyaFtBEegtEpHnGD0cjx7H249gGlPZPKUzOgmgtyHrkJtwachwS1JCA6LAP5vyr 4OpNT2k44FbKLz3eJq7oYG5K2KGdTgQkabJLS7MTlHdaU+Wu94H77a/DgwlZ9FFsg5Oq ePSg== X-Gm-Message-State: ALoCoQmfwdMlA3m4cMLzSjKlu35w86gVwADoLhyx28OcB1eAQZ2fNepGu5g3CkrlzdHhn5Tbt9Vz2PCQh0YwEQ0v4NH9wlPU+oge363Eq9VMVhbeKr2SflTbw4OPdUm/5C25zzjjwK5//oXDuOgmUlszD9tzehJG/x+NGOOLP63pHeYPzutBz1SsJwDg51Oq0XbQUhjTxmXt X-Received: by 10.52.29.209 with SMTP id m17mr120132vdh.72.1393857453734; Mon, 03 Mar 2014 06:37:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 06:37:13 -0800 (PST) In-Reply-To: <531488F0.7090300@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <531488F0.7090300@jesup.org> From: Justin Uberti Date: Mon, 3 Mar 2014 06:37:13 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=20cf307d054065d50604f3b4ba56 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/olF2JWfekk4BqRFZ_36ageVxGSo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 14:37:44 -0000 --20cf307d054065d50604f3b4ba56 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 3, 2014 at 5:51 AM, Randell Jesup wrote: > On 3/3/2014 8:28 AM, Justin Uberti wrote: > > On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup wrote: > >> On 3/3/2014 6:18 AM, Justin Uberti wrote: >> >> On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup wrote: >> >> >> So I still think manual chunking seems like a reasonable thing to >> support. I don't quite get the congestion control concerns; just because >> there is a max chunk size doesn't mean the impl can't buffer multiple >> chunks in bufferedAmount; the app could let that fill up to a degree to >> avoid having to poll constantly to prevent underrun. >> >> >> On a slow link this will work if the browser isn't janky. On a >>> fast link GC pauses and other things may cause the buffer to drain out and >>> go idle for significant periods. >>> >> >> Since the amount buffered is up to the app, the app can just increase >> the buffer size to provide enough data to cover the next second or so of >> transfer. >> >> >> How does the app increase the size of the internal SCTP buffers? (And >> that buffer is shared by all channels, of course). >> > > What I meant is the app can make multiple calls to send() at a time, > each with a chunk, which will be buffered in the api layer and increase > bufferedAmount. > > > Aha - that explains "increase the buffer size". Yes, that will work, > modulo that the app will have to track the actual bandwidth by either > monitoring how fast the bufferedAmount drains, or via a JS API to report > bandwidth ala the bug I opened on JS interaction with congestion control. > I still feel this pushes some level of congestion control into the JS app > (and done like trying to thread needles with oven mitts on - ok, mild > exaggeration) or the app will simply ignore this issue (likely) and get > sub-optimal performance, perhaps significantly. So I think more thought > would be useful here, especially at the W3/JS level. > > If we have the bandwidth reporting, having the app choose a reasonable > amount of buffering would be much easier/simpler. > In the simplest case, you could just have a medium-sized buffer of size (max expected transfer rate * worst-case poll interval); 10 MB would be plenty for almost all cases. If you wanted to be smarter, you could start with 1MB buffer, poll every 100 ms, and then adjust the buffer size to be at least ((data sent since last poll / time since last poll) * worst-case poll interval), where worst-case poll interval, accounting for GC, is somewhere around 1 second. I don't think this pushes CC onto apps, it just pushes spooling onto them, which is the consequence of not having streams yet. > -- > Randell Jesup -- rjesup a t mozilla d o t com > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf307d054065d50604f3b4ba56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 3, 2014 at 5:51 AM, Randell Jesup <= ;randell-ietf@j= esup.org> wrote:
=20 =20 =20
On 3/3/2014 8:28 AM, Justin Uberti wrote:
On Mon, Mar 3, 2014 at 3:44 AM, Rand= ell Jesup <randell-ietf@jesup.org> wrote:
On 3/3/2014 6:18 AM, Justin Uberti wrote:
On Sun, Ma= r 2, 2014 at 6:42 PM, Randell Jesup <randell-ietf@jesup.or= g> wrote:

So I still think manual chunking seems like a reasonable thing to support. I don't quite get the congestion control concerns; just because there is a max chunk size doesn't mean the impl can't buffer multiple chunks in bufferedAmount; the app could let that fill up to a degree to avoid having to poll constantly to prevent underrun.

On a slow link this will work if the browser isn't janky.=C2=A0 On a fast link GC paus= es and other things may cause the buffer to drain out and go idle for significant periods.

Since the amount buffered is up to the app, the app can just increase the buffer size to provide enough data to cover the next second or so of transfer.

How does the app increase the size of the internal SCTP buffers?=C2=A0 (And that buffer is shared by all channels, = of course).

What I meant is the app can make multiple calls to send() at a time, each with a chunk, which will be buffered in the api layer and increase bufferedAmount.

Aha - that explains "increase the buffer size".=C2=A0 Yes, th= at will work, modulo that the app will have to track the actual bandwidth by either monitoring how fast the bufferedAmount drains, or via a JS API to report bandwidth ala the bug I opened on JS interaction with congestion control.=C2=A0 I still feel this pushes some level of congestion control into the JS app (and done like trying to thread needles with oven mitts on - ok, mild exaggeration) or the app will simply ignore this issue (likely) and get sub-optimal performance, perhaps significantly.=C2=A0 So I think more thought would be useful here, especially at the W3/JS level.

If we have the bandwidth reporting, having the app choose a reasonable amount of buffering would be much easier/simpler.

In the simplest case, you could just have a med= ium-sized buffer of size (max expected transfer rate * worst-case poll inte= rval); 10 MB would be plenty for almost all cases.

If you wanted to be smarter, you could start with 1MB b= uffer, poll every 100 ms, and then adjust the buffer size to be at least ((= data sent since last poll / time since last poll) * worst-case poll interva= l), where worst-case poll interval, accounting for GC, is somewhere around = 1 second.=C2=A0

I don't think this pushes CC onto apps, it just pus= hes spooling onto them, which is the consequence of not having streams yet.= 


--=20
Randell Jesup -- rjesup a t mozilla d o t com

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


--20cf307d054065d50604f3b4ba56-- From nobody Mon Mar 3 06:39:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BA11A01B3 for ; Mon, 3 Mar 2014 06:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 JPqNmM78GIVM for ; Mon, 3 Mar 2014 06:39:26 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B25821A01E8 for ; Mon, 3 Mar 2014 06:39:25 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so3618423vcb.41 for ; Mon, 03 Mar 2014 06:39:22 -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=AFgDNnaNTEsFfThlUNKL20PGrEnGpgDZ87zecmF0UIU=; b=JCZkvgwdcwSSqfXIYw9C5nTmmYtCbwlFz1i6/jZvXSZkhC+AfqTncvAnQ+FAudw2yj BLrZHSsTePBXf5kN0VgOdCHA0Z4Caa1A3FL/zhbR8As1Uh3jVwjJU7UDsMPOlvVBUNnA T6sbWAWSqt1JmddiPlhDVm4viF7ACSdrevz8CSzF54aQVJOQ1/ryOx02mfjGFmLPW2mQ tu1UaW/5ZGISeOt7mwcOt3hB67bu90oc/L071LDpvS02KA5Sa8HT7Ycn+BUxsy1b+usN fgz4RDOtCBloLV/YNMZ0G7MpqHzLHK24XgTQ6LXehSZn/nBqhTVSN8et4rCzuR4lszX4 z5kg== 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=AFgDNnaNTEsFfThlUNKL20PGrEnGpgDZ87zecmF0UIU=; b=LdYtVAI/v3xvHiHya6fn7VHPjNaLlB1jDHQCHiJCyy88fiQ1uMIWdVIrBwzOIhc3dg sGXo7Zvn55t1UVuTipdKHb2zK7MuP75slmyCf84n+3drSZQsJcKPb8HeGFbhSfKqd53u JaPQc6aRUr/Mf9FC7pfPc1CZL9UAtM6KN+Cc3MucEIZsp4dymVVKDHIZZjiX5ZjinWXC XCpucvRsuJXeFp0+PneoSekBDFOTgzRPiPGPzMLC8UKbJkZluhOvzPKew52LBYqvoGB6 N7o36qJK5S1CYIwf4QFKI4GVTxeMSUEsSIcV8W5aBXr/QhbqdIor/clyd7RMuFPV9eyp mj7g== X-Gm-Message-State: ALoCoQnQE7sh5c+3rauHj4rHBNc7w6U8rJ0V3PDu8SoQQ+TcAGeyEuvQhNiQBuuO3HX7xaIe4pUHVM7GO4RnATgM1RqZz6v5D59b+kQBLok9ggemGgMIsZfiJ5jtUISA5Fn4KzWaU+It2qL5Lz42iNRQuPwUTmjxp6ujQLSr2AT2SMmppKov1rbszgXKtapjKZ4NrMEW3ZfQ X-Received: by 10.52.81.66 with SMTP id y2mr83391vdx.23.1393857562660; Mon, 03 Mar 2014 06:39:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 06:39:02 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1C6595@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1B55BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C5BDE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C63D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C6595@ESESSMB209.ericsson.se> From: Justin Uberti Date: Mon, 3 Mar 2014 06:39:02 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1136776ae3eb5d04f3b4c02b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y3dZFvdtYdPXQ4JqFAWTavMJlWg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-06: How to create the second offer where only the port numbers are changed? 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, 03 Mar 2014 14:39:28 -0000 --001a1136776ae3eb5d04f3b4c02b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. On Mon, Mar 3, 2014 at 6:35 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Fair enough, maybe some things can change. And, BUNDLE does not forbid > changing values, but it does say that the offerer should be careful when > doing so. > > > > Section 6.4.3: > > > > =E2=80=9CThe Offerer MAY modify any SDP parameter in a BAS Offer. > > > > NOTE: It is important that the BAS Offer gets accepted by the > > Answerer, so the Offerer needs to consider the necessity to modify > > SDP parameters that could get the Answerer to reject the BAS Offer. > > Removing "m=3D" lines, or reducing the number of codecs, in the BAS > > Offer used for the is considered to have a low risk of being > > rejected.=E2=80=9D > > > > So, I guess what should be avoided is adding of new m- lines, new codecs, > or anything which may trigger the answer to reject the offer. > > > > Regards, > > > > Christer > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* 03 March 2014 16:13 > *To:* Christer Holmberg > *Cc:* rtcweb@ietf.org > *Subject:* Re: JSEP-06: How to create the second offer where only the > port numbers are changed? > > > > But why is it a problem if other things change (e.g. a=3Dremote-candidate= s > is set)? > > > > On Mon, Mar 3, 2014 at 5:48 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > As specified in BUNDLE, before the remote peer has indicated support > of BUNDLE, all m- lines (including those within to a bundle group) must > have unique port numbers. > > Then, when the remote peer has indicated support of BUNDLE, a second offe= r > (called the BAS offer) needs to be sent, in which the same port number is > assigned to all m- lines within a bundle group. > > My question is: how do I create the BAS offer? I don=E2=80=99t want to ch= ange > anything =E2=80=93 I just want to get an SDP with the BUNDLE port assigne= d to all > m- lines. Is there a flag in createOffer() for that? > > The implementation knows that any offers that are created after the > BUNDLE answer should have the same port numbers. So, the app could push t= he > createOffer button once it receives the answer if it wanted to ensure thi= s > happened immediately. Otherwise, there will be an onnegotiationneeded eve= nt > once ICE completes, and the offer sent at that time will have the updated > ports. > > When I call createOffer(), can I be ensure that *only* the port values > will change? > > > > No. Why would this be necessary? > > > > Because the only thing I want to do is to send a new offer, with the same > port number in each m- line. I don=E2=80=99t want anything else to change= . > > > > Regards, > > > > Christer > > > --001a1136776ae3eb5d04f3b4c02b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed.


On Mon, Mar 3, 2014 at 6:35 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Fair enough, maybe some t= hings can change. And, BUNDLE does not forbid changing values, but it does = say that the offerer should be careful when doing so.

=C2=A0

Section 6.4.3:<= /u>

=C2=A0

=E2=80=9CThe Offerer MAY modify any SDP parameter in a BAS= Offer.

=C2=A0

=C2=A0=C2=A0 NOTE: It is important that the BAS Offer gets= accepted by the

=C2=A0=C2=A0 Answerer, so the Offerer needs to consider th= e necessity to modify

=C2=A0=C2=A0 SDP parameters that could get the Answerer to= reject the BAS Offer.

=C2=A0=C2=A0 Removing "m=3D" lines, or reducing = the number of codecs, in the BAS

=C2=A0=C2=A0 Offer used for the is considered to have a lo= w risk of being

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

=C2=A0

So, I guess what should b= e avoided is adding of new m- lines, new codecs, or anything which may trig= ger the answer to reject the offer.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: Justin Uberti [mailto:juberti@google.com]
Sent: 03 March 2014 16:13
To: Christer Holmberg
Cc: rtcweb@ietf= .org
Subject: Re: JSEP-06: How to create the second offer where only the = port numbers are changed?

=C2=A0

But why is it a problem if other things change (e.g.= a=3Dremote-candidates is set)?

=C2=A0<= /p>

On Mon, Mar 3, 2014 at 5:48 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

As specified in BUNDLE, before = the remote peer has indicated support of BUNDLE, all m- lines (including th= ose within to a bundle group) must have unique port numbers.=C2=A0

Then, when the remote peer has = indicated support of BUNDLE, a second offer (called the BAS offer) needs to= be sent, in which the same port number is assigned to all m- lines within a bundle group.

My question is: how do I create= the BAS offer? I don=E2=80=99t want to change anything =E2=80=93 I just wa= nt to get an SDP with the BUNDLE port assigned to all m- lines. Is there a flag in createOffer() for that?

The implementation knows that any offers that are cr= eated after the BUNDLE answer should have the same port numbers. So, the ap= p could push the createOffer button once it receives the answer if it wanted to ensure this happened immediately. Otherwise, th= ere will be an onnegotiationneeded event once ICE completes, and the offer = sent at that time will have the updated ports.

When I call createOffer()= , can I be ensure that only the port values will change?

=C2=A0

No. Why would this be necessary?=C2=A0=

=C2=A0

Because the only thing I want= to do is to send a new offer, with the same port number in each m- line. I don=E2=80=99t want anything else to change.

=C2=A0

Regards,=

=C2=A0

Christer

=C2=A0


--001a1136776ae3eb5d04f3b4c02b-- From nobody Mon Mar 3 06:41:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E8F1A0140 for ; Mon, 3 Mar 2014 06:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaEAX3XuaLQ9 for ; Mon, 3 Mar 2014 06:41:12 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D12041A0155 for ; Mon, 3 Mar 2014 06:41:11 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so3281032wgh.31 for ; Mon, 03 Mar 2014 06:41:08 -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=mCxyLFhBkMk6JUxvWfKB/HAVfUiMExgVxzEfZ47rjXo=; b=GD0sapVsVPFV1dDIjIjgnY8nAtnYwgJ+eDSwy2gBPWJ1lq08Sn+e3GVIH8CVHwSUQQ ZvCVXT9wbvEGP6apQXmi7zp+0s3zCvekk1uvGr/flm3DOrnbp7tm474wwxlhTZj+hwrP MwocRcBXynwlEFruyHRjVqq646zR6Vb0vjuLiOLKLSFTjWDy2z8N84E0x5lDinljZBAQ lOHis6M9Ew859ndMUhSqaaBNwjsAba5eCnqB7ipX2KgnMx16S3mPVTMfxYaYupJcPVXb mOME0IXwxBgeHIVJho+48/zLht2NwtdDk/JNMOCAQOSMVWtezkuSzIhdrlyQd6f/RfEZ dfPQ== MIME-Version: 1.0 X-Received: by 10.194.174.197 with SMTP id bu5mr6424538wjc.71.1393857668570; Mon, 03 Mar 2014 06:41:08 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 06:41:08 -0800 (PST) In-Reply-To: References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> Date: Mon, 3 Mar 2014 06:41:08 -0800 Message-ID: From: Martin Thomson To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SmRGT9GS7LPcR3GFX7pzU-JJifo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 14:41:14 -0000 I should have said prefix. On 3 March 2014 05:53, Martin Thomson wrote: > On 3 March 2014 03:44, Randell Jesup wrote: >> Hopefully so, though I hate forcing apps to include a bunch of code for >> backwards compat for a year or two (and many won't, or won't test it, etc). >> That hurts the feature. And today no one has ndata. > > Since WebRTC is behind a flag, I don't find this particularly > convincing. We can implement ndata. > > I think that we could even remove our temporary length restriction. From nobody Mon Mar 3 06:41:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B991A015C for ; Mon, 3 Mar 2014 06:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SgkdbIq1RYk for ; Mon, 3 Mar 2014 06:41:52 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71C1A005E for ; Mon, 3 Mar 2014 06:41:52 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A7ECA1C1042F5; Mon, 3 Mar 2014 15:41:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se> Date: Mon, 3 Mar 2014 14:41:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <26814FB1-993E-4F5C-8224-BFB93E4AC44D@lurchi.franken.de> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu> <530E564B.9070103@jesup.org> <530E6580.4080804@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gOvRUWAe3zATfUtTDDDPAZuNpdE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 14:41:54 -0000 On 26 Feb 2014, at 22:21, Christer Holmberg = wrote: > Hi, >=20 >>>> * Section 6.5 >>>>=20 >>>> This section contains: >>>=20 >>> Data channels can be opened by using internal or external >>> negotiation. The details are out of scope of this document. >>>=20 >>> A simple protocol for internal negotiation is specified in >>> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >>>=20 >>>> But internal and external negotiation are not defined in this = document. >>>>=20 >>>=20 >>>> I *thought* that internal negotiation was by definition negotiation=20= >>> by use of > rtcweb-data-protocol.=20 >>> (draft-ejzak-mmusic-data-channel-sdpneg-00 >>> thinks so too, >>>> but calls it "in-band negotiation".) There should be a good=20 >>> definition of these > terms, or reference to one. And more = discussion=20 >>> if there can be other kinds of > internal negotiation. (If so, how=20= >>> would one be chosen?) >>>=20 >>> Well, the text above says that ietf-rtcweb-data-protocol specifies = an=20 >>> internal negotiation protocol, so it's not that far off. The split=20= >>> does allow someone to use an alternative negotiation protocol=20 >>> (internal or external). >>>=20 >>> How about: >>>=20 >>> Data channels can be opened by using negotiation within the SCTP=20= >>> association or external >>> negotiation. External negotiation is defined as any method which=20= >>> results in an agreement >>> as to the parameters of a channel and the creation thereof. >>> The details are out of scope of this document. >>>=20 >>> A simple protocol for negotiation within the SCTP association is=20= >>> specified in >>> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >>>=20 >>> Perhaps someone can wordsmith "external negotiation" better. >>=20 >> ISTM the issue is that Internal vs. External isn't the key = distinction.=20 >> What is key is that there is one method that MUST be *supported* but = need not be the only one >used. Other mechanisms may be used. It doesn't = really matter whether they are conducted >internally (over the SCTP = association) or externally (anything else). >=20 > I think the MUST-be-supported-method is a separate question. >=20 >> E.g., I could use DCEP to establish one channel, and then use my own = private protocol over that to >negotiate other channels. Would that be = internal or external negotiation? Does it matter? >=20 > I guess they would both be in-band methods. Maybe using in-band and = out-of-band terminology would be more clear - and more aligned with = existing terminology. OK, changed to in-band and out-of-band. Best regards Michael >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Mar 3 07:06:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4061A0141 for ; Mon, 3 Mar 2014 07:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDVLng3CekHL for ; Mon, 3 Mar 2014 07:06:31 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id B005D1A0127 for ; Mon, 3 Mar 2014 07:06:30 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403031606260796 for ; Mon, 03 Mar 2014 16:06:26 +0100 From: "Karl Stahl" To: References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <531488F0.7090300@jesup.org> In-Reply-To: Date: Mon, 3 Mar 2014 16:06:22 +0100 Message-ID: <000101cf36f2$23da7a60$6b8f6f20$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01CF36FA.859EE260" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac827igaTGTVlXvJRqSyhoh73r3fLAAA/I8Q Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9oXNnibFHEiZ1DLqiayqykDnXbQ Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 15:06:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01CF36FA.859EE260 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Justin = Uberti Skickat: den 3 mars 2014 15:37 Till: Randell Jesup Kopia: rtcweb@ietf.org =C3=84mne: Re: [rtcweb] Open data channel issues =20 =20 =20 On Mon, Mar 3, 2014 at 5:51 AM, Randell Jesup = wrote: On 3/3/2014 8:28 AM, Justin Uberti wrote: On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup = wrote: On 3/3/2014 6:18 AM, Justin Uberti wrote: On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup = wrote: =20 So I still think manual chunking seems like a reasonable thing to = support. I don't quite get the congestion control concerns; just because = there is a max chunk size doesn't mean the impl can't buffer multiple = chunks in bufferedAmount; the app could let that fill up to a degree to = avoid having to poll constantly to prevent underrun. =20 On a slow link this will work if the browser isn't janky. On a fast = link GC pauses and other things may cause the buffer to drain out and go = idle for significant periods. =20 Since the amount buffered is up to the app, the app can just increase = the buffer size to provide enough data to cover the next second or so of = transfer.=20 =20 How does the app increase the size of the internal SCTP buffers? (And = that buffer is shared by all channels, of course). =20 What I meant is the app can make multiple calls to send() at a time, = each with a chunk, which will be buffered in the api layer and increase = bufferedAmount. Aha - that explains "increase the buffer size". Yes, that will work, = modulo that the app will have to track the actual bandwidth by either = monitoring how fast the bufferedAmount drains, or via a JS API to report = bandwidth ala the bug I opened on JS interaction with congestion = control. I still feel this pushes some level of congestion control into = the JS app (and done like trying to thread needles with oven mitts on - = ok, mild exaggeration) or the app will simply ignore this issue (likely) = and get sub-optimal performance, perhaps significantly. So I think more = thought would be useful here, especially at the W3/JS level. If we have the bandwidth reporting, having the app choose a reasonable = amount of buffering would be much easier/simpler. =20 In the simplest case, you could just have a medium-sized buffer of size = (max expected transfer rate * worst-case poll interval); 10 MB would be = plenty for almost all cases. =20 If you wanted to be smarter, you could start with 1MB buffer, poll every = 100 ms, and then adjust the buffer size to be at least ((data sent since = last poll / time since last poll) * worst-case poll interval), where = worst-case poll interval, accounting for GC, is somewhere around 1 = second.=20 =20 I don't think this pushes CC onto apps, it just pushes spooling onto = them, which is the consequence of not having streams yet. =20 --=20 Randell Jesup -- rjesup a t mozilla d o t com _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_0002_01CF36FA.859EE260 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

Fr=C3=A5n: rtcweb = [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Justin = Uberti
Skickat: den 3 mars 2014 15:37
Till: Randell = Jesup
Kopia: rtcweb@ietf.org
=C3=84mne: Re: [rtcweb] = Open data channel issues

 

 

 

On Mon, Mar 3, 2014 at 5:51 AM, Randell Jesup <randell-ietf@jesup.org> = wrote:

On 3/3/2014 = 8:28 AM, Justin Uberti wrote:

On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup <randell-ietf@jesup.org> = wrote:

On 3/3/2014 6:18 AM, Justin Uberti = wrote:

On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup <randell-ietf@jesup.org> = wrote:

 

So I still think manual chunking seems like a = reasonable thing to support. I don't quite get the congestion control = concerns; just because there is a max chunk size doesn't mean the impl = can't buffer multiple chunks in bufferedAmount; the app could let that = fill up to a degree to avoid having to poll constantly to prevent = underrun.

 

On a slow link this will work if the browser isn't = janky.  On a fast link GC pauses and other things may cause the = buffer to drain out and go idle for significant = periods.

 

Since the amount buffered is up to the app, the app = can just increase the buffer size to provide enough data to cover the = next second or so of transfer. =

 

How = does the app increase the size of the internal SCTP buffers?  (And = that buffer is shared by all channels, of = course).

 

What I meant is the app can make multiple calls to = send() at a time, each with a chunk, which will be buffered in the api = layer and increase = bufferedAmount.

=


Aha - that explains "increase the buffer = size".  Yes, that will work, modulo that the app will have to = track the actual bandwidth by either monitoring how fast the = bufferedAmount drains, or via a JS API to report bandwidth ala the bug I = opened on JS interaction with congestion control.  I still feel = this pushes some level of congestion control into the JS app (and done = like trying to thread needles with oven mitts on - ok, mild = exaggeration) or the app will simply ignore this issue (likely) and get = sub-optimal performance, perhaps significantly.  So I think more = thought would be useful here, especially at the W3/JS level.

If = we have the bandwidth reporting, having the app choose a reasonable = amount of buffering would be much = easier/simpler.

 

In the simplest case, you could just have a = medium-sized buffer of size (max expected transfer rate * worst-case = poll interval); 10 MB would be plenty for almost all = cases.

 

If you wanted to be smarter, you could start with 1MB = buffer, poll every 100 ms, and then adjust the buffer size to be at = least ((data sent since last poll / time since last poll) * worst-case = poll interval), where worst-case poll interval, accounting for GC, is = somewhere around 1 second. 

 

I = don't think this pushes CC onto apps, it just pushes spooling onto them, = which is the consequence of not having streams = yet.

 



-- =

Randell Jesup -- rjesup a t mozilla d o t =
com


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

 

------=_NextPart_000_0002_01CF36FA.859EE260-- From nobody Mon Mar 3 07:25:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD921A0145 for ; Mon, 3 Mar 2014 07:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWvyUc4yZDqd for ; Mon, 3 Mar 2014 07:24:56 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 075871A00CB for ; Mon, 3 Mar 2014 07:24:56 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 29E981C1042F6; Mon, 3 Mar 2014 16:24:52 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <530CD7C2.7050106@alum.mit.edu> Date: Mon, 3 Mar 2014 15:24:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530965D5.9090105@alum.mit.edu> <1B3F1D52-0F89-4F87-AB70-C1FAA73EC8EC@lurchi.franken.de> <530CD7C2.7050106@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qr5EzNxWTDmHgB7A-sNdvgn0OR8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03 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, 03 Mar 2014 15:25:00 -0000 On 25 Feb 2014, at 17:49, Paul Kyzivat wrote: > Inline >=20 > On 2/24/14 5:12 AM, Michael Tuexen wrote: >> On Feb 23, 2014, at 4:07 AM, Paul Kyzivat = wrote: >>=20 >>> A few comments on this draft: >>>=20 >>> * Section 5.1: >>>=20 >>> DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel = provides >>> a partial reliable in-order bi-directional Communication >>> channel. User messages might not be transmitted or >>> retransmitted after a specified life-time given in milli- >>> seconds in the Reliability Parameter. This life-time starts >>> when providing the user message to the Javascript engine. >>>=20 >>> The last sentence above is troubling. This protocol won't always be = used via Javascript. Can we please have a definition that >> OK. What about replacing the last sentence with >>=20 >> This life-time starts when providing the user >> message to the protocol stack. >=20 > *which* protocol stack? >=20 > This is part of the problem. As the documents are currently = structured, there is a "data channel establishment protocol", but there = is no "data channel protocol". >=20 > But in reality there *is* a (thin) data channel protocol. It just = isn't described explicitly. In a browser it is perhaps just the code = behind the data channel API. But in other environments it may need to be = more explicit. It has some obligations. Presumably enforcing this = "lifetime" parameter is one of them. Enforcing the use of sequenced = messages between a DCEP open and receipt of ACK is another. >=20 >>> doesn't depend on that? Is the timing being done by SCTP, or are you = assuming that a data channel layer on top of SCTP is doing this? Is it = specific to SCEP, or is it still applicable when the channel has been = established via external negotiation? >> It is actually the time when the message is provided to the SCTP = stack, but I think >> there might be some code running between the SCTP code and the user = code (let it be >> JS or anything else). I'm assuming that there is no substantial = buffering happening >> there. >>>=20 >>> Does use of this option imply that retransmission continues until = this time limit is reached? Or might it stop after some implementation = defined number of retransmissions? >> The only way the retransmissions don't happen until the time limit is = reached, is that >> SCTP decides that the association is broken because of excessive = retransmissions. >>>=20 >>> The description of the reliability parameter says: >>>=20 >>> This field is ignored if a reliable channel is used. >>>=20 >>> IMO folk wisdom says that some specific value (e.g., 0) should be = prescribed to be used in such cases. That makes things more = deterministic and provides more flexibility in extending the protocol in = the future. >> What about: >>=20 >> For reliable channels this field MUST be set to 0 on the sending side >> and MUST be ignored no the receiving side. >=20 > WFM >=20 >>> The name "Protocol" (and "Protocol Length") here is troublesome, = because it is ambiguous with other sorts of uses. (See my comment about = this point earlier today wrt draft-ietf-rtcweb-data-channel-07.) Others = (including draft-ejzak-mmusic-data-channel-sdpneg-00 and websockets) = call this "subprotocol". Using that would make it a little less = confusing. >> In the W3C specification it is also called protocol, but the text = talks about sub-protocol. Maybe we should do >> the same here. >=20 > I'm not following the W3C part. >=20 > I'm just interested in getting consistency, and avoiding confusion. > Right now there is a lot of confusion around the use of "protocol". >=20 >>> Also, ISTM that all of these things are applicable to externally = negotiated channels, and so ought to be defined by = draft-ietf-rtcweb-data-channel. (But of course their use in the = DATA_CHANNEL_OPEN message belongs here.) >> Reliability is discussed there, but I agree, we need to discuss label = and protocol there, too. >=20 > Good! >=20 >>> * Section 8.4: >>>=20 >>> ISTM there ought to be a template of the minimum information that = the specification for a registered (sub)protocol MUST (SHOULD?) include. = E.g., >>>=20 >>> - what Channel Type(s) are valid for this (sub)protocol >> I assumed all... >=20 > ISTM that in *most* cases a if a (sub)protocol is designed for use = with a reliable channel it won't work correctly with an unreliable = channel. >=20 > And while things designed to work with an unreliable channel will = probably continue to work with a reliable channel, they might not have = the intended properties. >=20 > That's why its good to have some guidelines about what the = specification must contain. It prevents people providing something = sloppy and incomplete that isn't sufficient to use the (sub)protocol. >=20 >>> - A contact for more information about this protocol >> You need to provide a reference for the protocol. Isn't that enough? >=20 > Depends on the form of the reference. Is the reference required to be = publicly available? Stable? >=20 > Note the definition of FCFS policy in 5226: >=20 > First Come First Served - Assignments are made to anyone on a > first come, first served basis. There is no substantive > review of the request, other than to ensure that it is > well-formed and doesn't duplicate an existing assignment. > However, requests must include a minimal amount of clerical > information, such as a point of contact (including an email > address) and a brief description of how the value will be > used. Additional information specific to the type of value > requested may also need to be provided, as defined by the > namespace. For numbers, the exact value is generally > assigned by IANA; with names, specific text strings can > usually be requested. >=20 > Having a sufficient definition of what must be in the registry, and = what must be in a reference from the registry is *more* important for = FCFS than it is for some of the more restrictive policies. The policies = that get careful review can perhaps depend on the reviewers stopping = something that is incomplete. >=20 > IMO the registry ought to provide, directly or indirectly, enough = information to implement/use the (sub)protocol. I'll bring this up in the RTCWeb meeting. Best regards Michael >=20 > Thanks, > Paul >=20 >> Best regards >> Michael >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >>=20 >=20 >=20 From nobody Mon Mar 3 07:27:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911471A014A for ; Mon, 3 Mar 2014 07:27:39 -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, 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 qKywpMNxGomk for ; Mon, 3 Mar 2014 07:27:32 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 270561A004A for ; Mon, 3 Mar 2014 07:27:32 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1914 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKUm9-000A4a-4F for rtcweb@ietf.org; Mon, 03 Mar 2014 09:27:29 -0600 Message-ID: <53149F0C.6070001@jesup.org> Date: Mon, 03 Mar 2014 10:26:04 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L740VVatFr9xd8agIP4hf5ylhuA Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 15:27:39 -0000 On 3/3/2014 8:53 AM, Martin Thomson wrote: > On 3 March 2014 03:44, Randell Jesup wrote: >> Hopefully so, though I hate forcing apps to include a bunch of code for >> backwards compat for a year or two (and many won't, or won't test it, etc). >> That hurts the feature. And today no one has ndata. > Since WebRTC is behind a flag, I don't find this particularly > convincing. We can implement ndata. I don't understand the "behind a flag" comment; an app using DataChannels for anything variable-length (unless with low bounds) must care until all old implementations are gone. Since we already have DataChannel impls in ESR releases, there's no avoiding this if we rely on that (even worse, since this undefined property doesn't exist yet (let alone in ESR), the app has to handle that case as well). Or add browser and version sniffing to all the apps... > I think that we could even remove our temporary length restriction. Sure, we can. This will reduce or eliminate source changes for apps that don't care about interleaving, which is a plus. It will cause total stall of all other DataChannels during transmission of one large message, which some applications would be ok with, and others would not, and so those that would not would have to somehow deal with it. So, applications that are ok with blocking other channels with large sends could be allowed to send arbitrary-sized messages, and receivers would be required to receive them (without chunking). Applications that do care about other channels would need to restrict their sending size when ndata isn't available at both ends. We really only need to know if ndata is available and expose that fact to the application, not a receive size from the receiver. So this plan would be: 1) We expose ndata being agreed to (currently == false); 2) We turn off the PPID chunking in Firefox (and live with ESR24 and current revs of Firefox not being compatible; see 2a) 2a) we make sure the app can detect if the local client has the ndata property at all (supports this solution). 3) We make sure Chrome and Firefox both implement both EOR sending and EOR reception and unlimited (or virtually) send/receive sizes. For bonus points, on EOR reception of a blob, spool it to disk in the browser (if over some limit perhaps), and on EOR send of a blob, optimize it to avoid send-side memory hits and performance issues. This will break large send/receive between Chrome and current/older Firefox - but those are broken today by Chrome not implement PPID chunking and Firefox doing so. Firefox can still fall back on PPID chunking if it knows it's talking to another Firefox until we decide that this no longer matters. I could be wrong, but I think Chrome doesn't support EOR sending currently; I know Firefox doesn't since we were using PPID chunking, so we'd need to add that. Once ndata is supported, all will work well, and applications that didn't care about interleaving don't have to change, and those that do will trigger on ndata and switch (and they can test ndata==true mode reasonably well by forcing it in the app, since send(large) will work). -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Mon Mar 3 07:39:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A21E1A01DF for ; Mon, 3 Mar 2014 07:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sFT5FkngJHO for ; Mon, 3 Mar 2014 07:38:56 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 316181A01E8 for ; Mon, 3 Mar 2014 07:38:56 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 19DD01C1042F6; Mon, 3 Mar 2014 16:38:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <530E564B.9070103@jesup.org> Date: Mon, 3 Mar 2014 15:38:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2D233459-7359-499F-AF01-95EBF950E31E@lurchi.franken.de> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu> <530E564B.9070103@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/99uiZ-CkLyzW-VygtWqfG1Clres Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 15:38:59 -0000 On 26 Feb 2014, at 21:02, Randell Jesup wrote: > On 2/26/2014 2:50 PM, Paul Kyzivat wrote: >> Michael, >>=20 >> There have been no replies to my comments: >>=20 >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11518.html >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11519.html >>=20 >> The first of those is about channels, the 2nd about DCEP. One of my = issues is that the partitioning between those two drafts is awkward. At = the least some things from DCEP should be moved to the channel draft. It = might be better to just merge those two drafts, or do a serious = refactoring. >=20 > There seem to have been a number of responses to your second posting = at least. >=20 >> How about: >=20 > Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed to SCTP by the data channel layer > and sent to its peer. This value is used to multiplex WebRTC Data > Channel Establishment Protocol messages (defined in = [I-D.ietf-rtcweb- > data-protocol]) with messages containing user data on a data > channel. The PPID is also used to distinguish UTF-8 encoded user > data and binary encoded user data. >=20 > That seems reasonable and clearer. >=20 >=20 >> * Section 6.5 >>=20 >> This section contains: >=20 > Data channels can be opened by using internal or external > negotiation. The details are out of scope of this document. >=20 > A simple protocol for internal negotiation is specified in > [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >=20 >> But internal and external negotiation are not defined in this = document. >>=20 >=20 > > I *thought* that internal negotiation was by definition negotiation = by use of > > rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 = thinks so too, > > but calls it "in-band negotiation".) There should be a good = definition of these > > terms, or reference to one. And more discussion if there can be = other kinds of > > internal negotiation. (If so, how would one be chosen?) >=20 > Well, the text above says that ietf-rtcweb-data-protocol specifies an = internal negotiation protocol, > so it's not that far off. The split does allow someone to use an = alternative negotiation protocol > (internal or external). >=20 > How about: >=20 > Data channels can be opened by using negotiation within the SCTP = association or external > negotiation. External negotiation is defined as any method which = results in an agreement > as to the parameters of a channel and the creation thereof. > The details are out of scope of this document. >=20 > A simple protocol for negotiation within the SCTP association is = specified in > [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >=20 >=20 > Perhaps someone can wordsmith "external negotiation" better. Taken, but with in-band and out-of-band... >=20 >=20 >> * Section 6.6: >>=20 >> Say: >=20 > All data sent on a Channel in both directions MUST be sent over the > underlying stream using the reliability defined when the Channel was > opened unless the options are changed, or per-message options are > specified by a higher level. >=20 > > Is the recipient to consider it an error if messages are received = with options different from those > > defined for the channel? Also, is it an error if messages are = received with a PPID that isn't specified > > in Section 8? (And what about PPID 50?) >=20 >> How are such channel errors to be treated? >=20 >=20 > I'd propose that if messages are received with options that don't = match the initial definition, that fact should be ignored and the = message processed. > If messages with an unknown PID are received, those messages should be = ignored. I'll bring that up at the WebRTC session. Best regards Michael >=20 > In both cases, logging of such an event to the application (or onerror = calls in WebRTC W3 JS layers) is allowed but not required. Note that the = onerror callback is currently under-defined, so this might change. >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Mar 3 09:26:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66051A02D9 for ; Mon, 3 Mar 2014 09:26:55 -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 g_ZQZMa4AcXD for ; Mon, 3 Mar 2014 09:26:54 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 027201A02E0 for ; Mon, 3 Mar 2014 09:26:53 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id a1so3617158wgh.10 for ; Mon, 03 Mar 2014 09:26:50 -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=qPMKjjTdINDq0NEVwDbfdAl13laGqabJ9XsqqZWCPMg=; b=TRmhR+6ha5vKdHWoAo6cmJ/iOBHf7SjFyM946VlOldR5pwjtSlkhFaPwSYXh+HJH0k S4g213InwkvZFuY2OWE1eC4NfYjQ7xWS/38PYRqiUUy1znj/pLxIMAyh6+faTIhXNDb9 3Mfb0tmmA3yySli4KaZvlA/Imf7g0vlG29hRDIRupHkIrHxZ6I6iVYr+URmIwhxseqVt Qmkxb9QEfoRmwij6o2M6+PoCXt+sS0cFr22WIv6a/DoH7LenADNZVwp+FTyQjJAwtmux 78K2qx9EEfVKsiGSRAwTE/v2QQ2XmXR7jMjoLuU2oNF1tLtUpy5/Tz+89M4LyCGcAHo4 kFVg== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr4686333wjc.56.1393867610689; Mon, 03 Mar 2014 09:26:50 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 09:26:50 -0800 (PST) In-Reply-To: <53149F0C.6070001@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> Date: Mon, 3 Mar 2014 09:26:50 -0800 Message-ID: From: Martin Thomson To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZnTiKOmI1Y5b5Hdf6LpLp0BIl38 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 17:26:55 -0000 On 3 March 2014 07:26, Randell Jesup wrote: > I don't understand the "behind a flag" comment; an app using DataChannels > for anything variable-length (unless with low bounds) must care until all > old implementations are gone. My point was that these people who you want to protect have already renounced rights to protection by using the prefixed API. Don't use that as a basis for argument. We should concentrate on building the functionality we want to have. From nobody Mon Mar 3 09:54:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63091A00E4 for ; Mon, 3 Mar 2014 09:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 SuSSlV3HXj3K for ; Mon, 3 Mar 2014 09:54:54 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3211A02FC for ; Mon, 3 Mar 2014 09:54:52 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id sa20so3972549veb.36 for ; Mon, 03 Mar 2014 09:54:49 -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=6dDHQjLjw+QvuFcye9axXTg+UZIRHMQa98WKtai2uVk=; b=nEjsWStUuzqKA9mV2d/icU+78YFmefKfSl5de3fe+Q6WFJDVgGvPFlD8LG8JVRktRk +1oEJOVRAKAskOgtXjdnsjXStbARVUnVnxEL3T390cr3vN8FaNO9Yj++maH9dUutWco9 xKF2iITjiIQgNTHcpy4pZIVQsqaZfjbtz7w8KIfm8CD9ay7EKpj7Pf7yfIVDVaGEhNVO TMm2P7aatc6qjwuBNG2oGnJ7cJ1m07FFIwnMN6hbq2ETdnGPrUwc1HCOlguzNQtIVQkN jvr4poYyoCE0ky7N7nv833HdrUqDv9zXprvaPJnNXKOwrWUHupPWRmtsah/xLyE28cKV FcVA== 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=6dDHQjLjw+QvuFcye9axXTg+UZIRHMQa98WKtai2uVk=; b=dbQs8C7tZtlVfR65wXtcWliDNseKNtFYQo3fuzXSjJ75ejuQkpbUy15nQ03redoVGg FckfepoRdjmqEYy2e1+NlklBIJKtQsuFkBzYnpUZWQMIefg9I8VUtcnJqi1TV94vgL5c 36JP75d3irI3u1wW6fmiy8zXCcFKcAjJTkOjP1j9bXdr19fMRoY930bbi986XS8KlBwr aFV5BNqkdC1Qlot7v9yBCg//BZxBFbOJXouCo0A34ZSMPdrZ1+de5OlV7/dm/vORWG9Q dUrkmF4ngJm4pmwC1MGRrWXNMQhei4l5FZcL5Vpjn2vu6Qe11/IS09Kg9gxOfmmau55V 9YBA== X-Gm-Message-State: ALoCoQlMQs4L0mDS+gH+a9FEXgAfKDeLbDUtaVivhRwCGBx6/qcprw9NcGrZWaJst8pCg40UYCNNI+5lDMks+aQh6yXID0m4gGMLv9x88teGSpVuVK+nQQLxvbk3NLN1OZYl0G9/LEFD+xgVaOLj2hnqEhHXtbMeFlkPBlN1tgmHu9aPwYup/qF9aI9wXS5o2KUM0wTnnQXC X-Received: by 10.52.30.230 with SMTP id v6mr591251vdh.6.1393869289132; Mon, 03 Mar 2014 09:54:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 09:54:28 -0800 (PST) In-Reply-To: <53149F0C.6070001@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> From: Justin Uberti Date: Mon, 3 Mar 2014 09:54:28 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec51d2eb8d7aa7704f3b77ba6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xRXXiE8Fr-9tZJr174zUmjAeImg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 17:54:58 -0000 --bcaec51d2eb8d7aa7704f3b77ba6 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup wrote: > On 3/3/2014 8:53 AM, Martin Thomson wrote: > >> On 3 March 2014 03:44, Randell Jesup wrote: >> >>> Hopefully so, though I hate forcing apps to include a bunch of code for >>> backwards compat for a year or two (and many won't, or won't test it, >>> etc). >>> That hurts the feature. And today no one has ndata. >>> >> Since WebRTC is behind a flag, I don't find this particularly >> convincing. We can implement ndata. >> > > I don't understand the "behind a flag" comment; an app using DataChannels > for anything variable-length (unless with low bounds) must care until all > old implementations are gone. Since we already have DataChannel impls in > ESR releases, there's no avoiding this if we rely on that (even worse, > since this undefined property doesn't exist yet (let alone in ESR), the app > has to handle that case as well). Or add browser and version sniffing to > all the apps... > > > I think that we could even remove our temporary length restriction. >> > > Sure, we can. This will reduce or eliminate source changes for apps that > don't care about interleaving, which is a plus. It will cause total stall > of all other DataChannels during transmission of one large message, which > some applications would be ok with, and others would not, and so those that > would not would have to somehow deal with it. > > So, applications that are ok with blocking other channels with large sends > could be allowed to send arbitrary-sized messages, and receivers would be > required to receive them (without chunking). Applications that do care > about other channels would need to restrict their sending size when ndata > isn't available at both ends. We really only need to know if ndata is > available and expose that fact to the application, not a receive size from > the receiver. > > So this plan would be: > 1) We expose ndata being agreed to (currently == false); > 2) We turn off the PPID chunking in Firefox (and live with ESR24 and > current revs of Firefox not being compatible; see 2a) > 2a) we make sure the app can detect if the local client has the ndata > property at all (supports this solution). > 3) We make sure Chrome and Firefox both implement both EOR sending and EOR > reception and unlimited (or virtually) send/receive sizes. > > For bonus points, on EOR reception of a blob, spool it to disk in the > browser (if over some limit perhaps), and on EOR send of a blob, optimize > it to avoid send-side memory hits and performance issues. > > This will break large send/receive between Chrome and current/older > Firefox - but those are broken today by Chrome not implement PPID chunking > and Firefox doing so. Firefox can still fall back on PPID chunking if it > knows it's talking to another Firefox until we decide that this no longer > matters. I could be wrong, but I think Chrome doesn't support EOR sending > currently; I know Firefox doesn't since we were using PPID chunking, so > we'd need to add that. > > Once ndata is supported, all will work well, and applications that didn't > care about interleaving don't have to change, and those that do will > trigger on ndata and switch (and they can test ndata==true mode reasonably > well by forcing it in the app, since send(large) will work). While I agree with the final outcome of #3, I don't think going down the 1/2/2a path makes sense, since it leads to an additional intermediate state over the current situation. i.e. we end up with 3 states: a) today: max safe send is 16 KB b) soon: ndata exists, but large sends lock out other sends c) final: ndata exists, and large sends work OK I would rather maintain a) or similar for now (using the max-message-size param) and jump to c) when we have the right stuff in SCTP. > > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec51d2eb8d7aa7704f3b77ba6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup <= ;randell-ietf@j= esup.org> wrote:
On 3/3/2014 8:53 AM, Martin Thomson wro= te:
On 3 March 2014 03:44, Randell Jesup <randell-ietf@jesup.org> wrote:
Hopefully so, though I hate forcing apps to include a bunch of code for
backwards compat for a year or two (and many won't, or won't test i= t, etc).
That hurts the feature. =C2=A0And today no one has ndata.
Since WebRTC is behind a flag, I don't find this particularly
convincing. =C2=A0We can implement ndata.

I don't understand the "behind a flag" comment; an app using = DataChannels for anything variable-length (unless with low bounds) must car= e until all old implementations are gone. =C2=A0Since we already have DataC= hannel impls in =C2=A0ESR releases, there's no avoiding this if we rely= on that (even worse, since this undefined property doesn't exist yet (= let alone in ESR), the app has to handle that case as well). =C2=A0Or add b= rowser and version sniffing to all the apps...


I think that we could even remove our temporary length restriction.

Sure, we can. =C2=A0This will reduce or eliminate source changes for apps t= hat don't care about interleaving, which is a plus. =C2=A0It will cause= total stall of all other DataChannels during =C2=A0transmission of one lar= ge message, which some applications would be ok with, and others would not,= and so those that would not would have to somehow deal with it.

So, applications that are ok with blocking other channels with large sends = could be allowed to send arbitrary-sized messages, and receivers would be r= equired to receive them (without chunking). Applications that do care about= other channels would need to restrict their sending size when ndata isn= 9;t available at both ends. =C2=A0We really only need to know if ndata is a= vailable and expose that fact to the application, not a receive size from t= he receiver.

So this plan would be:
1) We expose ndata being agreed to (currently =3D=3D false);
2) We turn off the PPID chunking in Firefox (and live with ESR24 and curren= t revs of Firefox not being compatible; see 2a)
2a) we make sure the app can detect if the local client has the ndata prope= rty at all (supports this solution).
3) We make sure Chrome and Firefox both implement both EOR sending and EOR = reception and unlimited (or virtually) send/receive sizes.

For bonus points, on EOR reception of a blob, spool it to disk in the brows= er (if over some limit perhaps), and on EOR send of a blob, optimize it to = avoid send-side memory hits and performance issues.

This will break large send/receive between Chrome and current/older Firefox= - but those are broken today by Chrome not implement PPID chunking and Fir= efox doing so. =C2=A0Firefox can still fall back on PPID chunking if it kno= ws it's talking to another Firefox until we decide that this no longer = matters. =C2=A0I could be wrong, but I think Chrome doesn't support EOR= sending currently; I know Firefox doesn't since we were using PPID chu= nking, so we'd need to add that.

Once ndata is supported, all will work well, and applications that didn'= ;t care about interleaving don't have to change, and those that do will= trigger on ndata and switch (and they can test ndata=3D=3Dtrue mode reason= ably well by forcing it in the app, since send(large) will work).

While I agree with the final outcome of #3, I don't= think going down the 1/2/2a path makes sense, since it leads to an additio= nal intermediate state over the current situation. i.e. we end up with 3 st= ates:
a) today: max safe send is 16 KB
b) soon: ndata exists, but = large sends lock out other sends
c) final: ndata exists, and larg= e sends work OK

I would rather maintain a) or simi= lar for now (using the max-message-size param) and jump to c) when we have = the right stuff in SCTP.


--
Randell Jesup -- rjesup a t mozilla d o t com

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

--bcaec51d2eb8d7aa7704f3b77ba6-- From nobody Mon Mar 3 14:19:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91EB1A00C9 for ; Mon, 3 Mar 2014 14:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE3QmNISMaoM for ; Mon, 3 Mar 2014 14:19:29 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 657AC1A006A for ; Mon, 3 Mar 2014 14:19:28 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s23MJNRN027031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Mar 2014 16:19:24 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s23MJNpi023244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 17:19:23 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 3 Mar 2014 17:19:23 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Justin Uberti , Randell Jesup Thread-Topic: [rtcweb] Open data channel issues Thread-Index: AQHPNvTjdPPAuXGnm0CBoOmgEn8ul5rP+SYA///UOvA= Date: Mon, 3 Mar 2014 22:19:23 +0000 Message-ID: References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> 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_E1FE4C082A89A246A11D7F32A95A17826E006069US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1kxWX9K31cSRktYUFBh-wyQQsHs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 22:19:34 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826E006069US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgdG8ganVtcCBpbiBmcm9tIG1pZGRsZSBvZiBub3doZXJlIGluIHRoaXMgaW50ZXJlc3Rp bmcgY29udmVyc2F0aW9uLiBJIGNvdWxkbuKAmXQgcmVzaXN0IHByb3ZpZGluZyB0aGlzIGZlZWRi YWNrIGFuZCBJIGhvcGUgaXQgaXMgdXNlZnVsLg0KDQpGaXJzdCwgb24g4oCcRU9SIHNvbHZpbmcg bW9ub3BvbGl6YXRpb24gaXNzdWXigJ06DQpJIGNvdWxkIGJlIHdyb25nLCBidXQgSSBhbSBub3Qg c3VyZSBob3cgRU9SIGJhc2VkIGFwcHJvYWNoIGF2b2lkcyBTQ1RQIGxpbmsgbW9ub3BvbGl6YXRp b24/ISBQZXIgbXkgdW5kZXJzdGFuZGluZyBFT1IgaXMgYSBsb2NhbCBzZW5kICgpIHV0aWxpdHkg cmF0aGVyIHRoYW4gcmVjZWl2ZSBzaWRlIHV0aWxpdHkgYW5kIGl0IGlzIGltcGxlbWVudGVkIG9u IHRvcCBvZiBiYXNlIFNDVFAgUkZDIChzbyBubyBpbmRpY2F0aW9uIG9mIHNwZWNpYWwgRU9SIGlu IFNDVFAgaGVhZGVycyBvdGhlciB0aGFuIGJhc2UgU0NUUCBSRkMgQi9FIGZyYWdtZW50IGluZGlj YXRpb24gYml0cykuIE9uY2UgYSBzZW5kICgpIHdpdGggRU9SIHNldCB0byBmYWxzZSBpcyBjYWxs ZWQsIG9uIGEgc3RyZWFtIGlkLCB0aGUgU0NUUCBsaW5rIGlzIG1vbm9wb2xpemVkIHVudGlsIHNl bmQgKCkgb24gc2FtZSBzdHJlYW0gaWQgd2l0aCBFT1Igc2V0IHRvIHRydWUgaXMgY2FsbGVkOyBz byBzYW1lIGxpbWl0YXRpb24gZXhpc3QuICBFT1IgYWxsb3dzIHNlbmRpbmcgc2lkZSB0byBzdGFy dCBzZW5kaW5nIGNodW5rcyB3aXRob3V0IHdhaXRpbmcgZm9yIGNvbXBsZXRlIGRhdGEuIEVPUiBo YXMgbm8gaW1wYWN0IG9uIHJlY2VpdmluZyBzaWRlLCB0aGUgU0NUUCBzdGFjayB3YWl0cyBmb3Ig bGFzdCBjaHVuayAod2hpY2ggaXMgdGhlIHJlc3VsdCBvZiBzZW5kaW5nIHNpZGUgc2V0dGluZyBF T1I9dHJ1ZSkgYW5kIGRlbGl2ZXJzIGVudGlyZSBtZXNzYWdlIHRvIGFwcC4NCg0KTmV3IFBDIGFw cHJvYWNoOg0KSWYgYW4gYXBwbGljYXRpb24gaXMgc2Vuc2l0aXZlIHRvIFNDVFAgbGluayBtb25v cG9saXNhdGlvbiB0aGVuIHRoZXJlIGlzIGFub3RoZXIgb3B0aW9uIGl0IGNhbiBjb25zaWRlciDi gJMgdXNlIG9mIHNlcGFyYXRlIG5ldyBQZWVyQ29ubmVjdGlvbiAoUEMpIGZvciB0aGUgZGF0YSBj aGFubmVsKHMpIHdoaWNoIG1heSBtb25vcG9saXplIHRoZSBsaW5rLg0KRGVwZW5kaW5nIG9uIGhv dyBhbiBhcHBsaWNhdGlvbiBpcyBkZXNpZ25lZCwgdXNpbmcgYSBuZXcgUEMgY291bGQgYmUgc2lt cGxlciB0aGFuIGhhdmluZyBhbiBhcHBsaWNhdGlvbiBsZXZlbCBjaHVua2luZyBwcm90b2NvbCAo ZnJhZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSkuICBJZiBhcHAgbmVlZHMgc3VjaCDigJxoZWF2 eeKAnSBkYXRhIGNoYW5uZWwgaW5mcmVxdWVudGx5IHRoZW4gaXQgY2FuIGNyZWF0ZSBuZXcgUEMg YXMgbmVlZGVkOyBpZiBpdCBpcyBuZWVkZWQgZnJlcXVlbnRseSB0aGVuIGEgZGVkaWNhdGVkIFBD IGNhbiBiZSBhbGxvY2F0ZWQgYW5kIGtlZXAgaXQgb3BlbiBhbGwgdGhlIHRpbWUuDQoNCk9uZSBk aXNhZHZhbnRhZ2Ugd2l0aCBhcHBsaWNhdGlvbiBsZXZlbCBjaHVua2luZyBwcm90b2NvbCBpcyBi b3RoIHRoZSBwZWVycyBuZWVkIHRvIHVzZSBpdDsgc28gaXQgbWF5IG5vdCB3b3JrIGJldHdlZW4g Y2xpZW50cyBvZiBkaWZmZXJlbnQgdHlwZXMgb3Igc2FtZSBjbGllbnRzIHdpdGggZGlmZmVyZW50 IHZlcnNpb25zLiBOZXcgUEMgYmFzZWQgYXBwcm9hY2ggb2J2aW91c2x5IGRvZXMgbm90IGhhdmUg dGhpcyBpc3N1ZSBhcyBubyBjaHVua2luZyBpcyBpbnZvbHZlZC4NCg0KQXQgZmlyc3QsIG5ldyBQ QyBhcHByb2FjaCBtYXkgYXBwZWFyIGhlYXZ5IHdlaWdodCB3cnQgIyBvZiBQQ3MgaW4gdXNlICh3 aGljaCBJIGRvbuKAmXQgdGhpbmsgYW4gaXNzdWUgb24gYnJvd3NlcnMpLCBJQ0Ugb3ZlcmhlYWQg Zm9yIG5ldyBQQyBldGMuIEJ1dCBpbiBjb21wYXJpc2lvbiB0byBhcHBsaWNhdGlvbiBsZXZlbCBj aHVua2luZyBuZXcgUEMgYXBwcm9hY2ggbWF5IG5vdCBiZSB0aGF0IGJhZC4NCg0KUGxlYXNlIHNl ZSBhZGRpdGlvbmFsIGNvbW1lbnRzIGlubGluZS4NCg0KLVJhanUNCg0KRnJvbTogcnRjd2ViIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRp DQpTZW50OiBNb25kYXksIE1hcmNoIDAzLCAyMDE0IDExOjU0IEFNDQpUbzogUmFuZGVsbCBKZXN1 cA0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIE9wZW4gZGF0YSBj aGFubmVsIGlzc3Vlcw0KDQoNCg0KT24gTW9uLCBNYXIgMywgMjAxNCBhdCA3OjI2IEFNLCBSYW5k ZWxsIEplc3VwIDxyYW5kZWxsLWlldGZAamVzdXAub3JnPG1haWx0bzpyYW5kZWxsLWlldGZAamVz dXAub3JnPj4gd3JvdGU6DQpPbiAzLzMvMjAxNCA4OjUzIEFNLCBNYXJ0aW4gVGhvbXNvbiB3cm90 ZToNCk9uIDMgTWFyY2ggMjAxNCAwMzo0NCwgUmFuZGVsbCBKZXN1cCA8cmFuZGVsbC1pZXRmQGpl c3VwLm9yZzxtYWlsdG86cmFuZGVsbC1pZXRmQGplc3VwLm9yZz4+IHdyb3RlOg0KSG9wZWZ1bGx5 IHNvLCB0aG91Z2ggSSBoYXRlIGZvcmNpbmcgYXBwcyB0byBpbmNsdWRlIGEgYnVuY2ggb2YgY29k ZSBmb3INCmJhY2t3YXJkcyBjb21wYXQgZm9yIGEgeWVhciBvciB0d28gKGFuZCBtYW55IHdvbid0 LCBvciB3b24ndCB0ZXN0IGl0LCBldGMpLg0KVGhhdCBodXJ0cyB0aGUgZmVhdHVyZS4gIEFuZCB0 b2RheSBubyBvbmUgaGFzIG5kYXRhLg0KU2luY2UgV2ViUlRDIGlzIGJlaGluZCBhIGZsYWcsIEkg ZG9uJ3QgZmluZCB0aGlzIHBhcnRpY3VsYXJseQ0KY29udmluY2luZy4gIFdlIGNhbiBpbXBsZW1l bnQgbmRhdGEuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgImJlaGluZCBhIGZsYWciIGNvbW1l bnQ7IGFuIGFwcCB1c2luZyBEYXRhQ2hhbm5lbHMgZm9yIGFueXRoaW5nIHZhcmlhYmxlLWxlbmd0 aCAodW5sZXNzIHdpdGggbG93IGJvdW5kcykgbXVzdCBjYXJlIHVudGlsIGFsbCBvbGQgaW1wbGVt ZW50YXRpb25zIGFyZSBnb25lLiAgU2luY2Ugd2UgYWxyZWFkeSBoYXZlIERhdGFDaGFubmVsIGlt cGxzIGluICBFU1IgcmVsZWFzZXMsIHRoZXJlJ3Mgbm8gYXZvaWRpbmcgdGhpcyBpZiB3ZSByZWx5 IG9uIHRoYXQgKGV2ZW4gd29yc2UsIHNpbmNlIHRoaXMgdW5kZWZpbmVkIHByb3BlcnR5IGRvZXNu J3QgZXhpc3QgeWV0IChsZXQgYWxvbmUgaW4gRVNSKSwgdGhlIGFwcCBoYXMgdG8gaGFuZGxlIHRo YXQgY2FzZSBhcyB3ZWxsKS4gIE9yIGFkZCBicm93c2VyIGFuZCB2ZXJzaW9uIHNuaWZmaW5nIHRv IGFsbCB0aGUgYXBwcy4uLg0KDQpJIHRoaW5rIHRoYXQgd2UgY291bGQgZXZlbiByZW1vdmUgb3Vy IHRlbXBvcmFyeSBsZW5ndGggcmVzdHJpY3Rpb24uDQoNClN1cmUsIHdlIGNhbi4gIFRoaXMgd2ls bCByZWR1Y2Ugb3IgZWxpbWluYXRlIHNvdXJjZSBjaGFuZ2VzIGZvciBhcHBzIHRoYXQgZG9uJ3Qg Y2FyZSBhYm91dCBpbnRlcmxlYXZpbmcsIHdoaWNoIGlzIGEgcGx1cy4gIEl0IHdpbGwgY2F1c2Ug dG90YWwgc3RhbGwgb2YgYWxsIG90aGVyIERhdGFDaGFubmVscyBkdXJpbmcgIHRyYW5zbWlzc2lv biBvZiBvbmUgbGFyZ2UgbWVzc2FnZSwgd2hpY2ggc29tZSBhcHBsaWNhdGlvbnMgd291bGQgYmUg b2sgd2l0aCwgYW5kIG90aGVycyB3b3VsZCBub3QsIGFuZCBzbyB0aG9zZSB0aGF0IHdvdWxkIG5v dCB3b3VsZCBoYXZlIHRvIHNvbWVob3cgZGVhbCB3aXRoIGl0Lg0KDQpTbywgYXBwbGljYXRpb25z IHRoYXQgYXJlIG9rIHdpdGggYmxvY2tpbmcgb3RoZXIgY2hhbm5lbHMgd2l0aCBsYXJnZSBzZW5k cyBjb3VsZCBiZSBhbGxvd2VkIHRvIHNlbmQgYXJiaXRyYXJ5LXNpemVkIG1lc3NhZ2VzLCBhbmQg cmVjZWl2ZXJzIHdvdWxkIGJlIHJlcXVpcmVkIHRvIHJlY2VpdmUgdGhlbSAod2l0aG91dCBjaHVu a2luZykuIEFwcGxpY2F0aW9ucyB0aGF0IGRvIGNhcmUgYWJvdXQgb3RoZXIgY2hhbm5lbHMgd291 bGQgbmVlZCB0byByZXN0cmljdCB0aGVpciBzZW5kaW5nIHNpemUgd2hlbiBuZGF0YSBpc24ndCBh dmFpbGFibGUgYXQgYm90aCBlbmRzLiAgV2UgcmVhbGx5IG9ubHkgbmVlZCB0byBrbm93IGlmIG5k YXRhIGlzIGF2YWlsYWJsZSBhbmQgZXhwb3NlIHRoYXQgZmFjdCB0byB0aGUgYXBwbGljYXRpb24s IG5vdCBhIHJlY2VpdmUgc2l6ZSBmcm9tIHRoZSByZWNlaXZlci4NCg0KU28gdGhpcyBwbGFuIHdv dWxkIGJlOg0KMSkgV2UgZXhwb3NlIG5kYXRhIGJlaW5nIGFncmVlZCB0byAoY3VycmVudGx5ID09 IGZhbHNlKTsNCjIpIFdlIHR1cm4gb2ZmIHRoZSBQUElEIGNodW5raW5nIGluIEZpcmVmb3ggKGFu ZCBsaXZlIHdpdGggRVNSMjQgYW5kIGN1cnJlbnQgcmV2cyBvZiBGaXJlZm94IG5vdCBiZWluZyBj b21wYXRpYmxlOyBzZWUgMmEpDQoyYSkgd2UgbWFrZSBzdXJlIHRoZSBhcHAgY2FuIGRldGVjdCBp ZiB0aGUgbG9jYWwgY2xpZW50IGhhcyB0aGUgbmRhdGEgcHJvcGVydHkgYXQgYWxsIChzdXBwb3J0 cyB0aGlzIHNvbHV0aW9uKS4NCjMpIFdlIG1ha2Ugc3VyZSBDaHJvbWUgYW5kIEZpcmVmb3ggYm90 aCBpbXBsZW1lbnQgYm90aCBFT1Igc2VuZGluZyBhbmQgRU9SIHJlY2VwdGlvbiBhbmQgdW5saW1p dGVkIChvciB2aXJ0dWFsbHkpIHNlbmQvcmVjZWl2ZSBzaXplcy4NCltSYWp1XSBUaGlzIHJlcXVp cmVzIFBlZXJDb25uZWN0aW9uIEFQSSB0byBpbmRpY2F0ZSBFT1IgZHVyaW5nIHNlbmQoKS4gUmln aHQ/IFdoaWNoIG1heSBiZSB1c2VmdWwgaW4gc29tZSBjYXNlcyB3aGVyZSBhcHAgd2FudHMgdG8g c2VuZCBwYXJ0aWFsIGRhdGEgYXMgaXQgaXMgYXZhaWxhYmxlL3JlYWR5LiBCdXQgYXMgZXhwbGFp bmVkIGFib3ZlLCBpbiBteSBvcGluaW9uIEVPUiB3b27igJl0IHNvbHZlIFNDVFAgbGluayBtb25v cG9saXphdGlvbiBhbmQgdW5uY2Vzc2FyaWx5IGludHJvZHVjZXMgb3ZlcmhlYWQgYXQgYXBwbGlj YXRpb24uDQoNCkZvciBib251cyBwb2ludHMsIG9uIEVPUiByZWNlcHRpb24gb2YgYSBibG9iLCBz cG9vbCBpdCB0byBkaXNrIGluIHRoZSBicm93c2VyIChpZiBvdmVyIHNvbWUgbGltaXQgcGVyaGFw cyksIGFuZCBvbiBFT1Igc2VuZCBvZiBhIGJsb2IsIG9wdGltaXplIGl0IHRvIGF2b2lkIHNlbmQt c2lkZSBtZW1vcnkgaGl0cyBhbmQgcGVyZm9ybWFuY2UgaXNzdWVzLg0KDQpUaGlzIHdpbGwgYnJl YWsgbGFyZ2Ugc2VuZC9yZWNlaXZlIGJldHdlZW4gQ2hyb21lIGFuZCBjdXJyZW50L29sZGVyIEZp cmVmb3ggLSBidXQgdGhvc2UgYXJlIGJyb2tlbiB0b2RheSBieSBDaHJvbWUgbm90IGltcGxlbWVu dCBQUElEIGNodW5raW5nIGFuZCBGaXJlZm94IGRvaW5nIHNvLiAgRmlyZWZveCBjYW4gc3RpbGwg ZmFsbCBiYWNrIG9uIFBQSUQgY2h1bmtpbmcgaWYgaXQga25vd3MgaXQncyB0YWxraW5nIHRvIGFu b3RoZXIgRmlyZWZveCB1bnRpbCB3ZSBkZWNpZGUgdGhhdCB0aGlzIG5vIGxvbmdlciBtYXR0ZXJz LiAgSSBjb3VsZCBiZSB3cm9uZywgYnV0IEkgdGhpbmsgQ2hyb21lIGRvZXNuJ3Qgc3VwcG9ydCBF T1Igc2VuZGluZyBjdXJyZW50bHk7IEkga25vdyBGaXJlZm94IGRvZXNuJ3Qgc2luY2Ugd2Ugd2Vy ZSB1c2luZyBQUElEIGNodW5raW5nLCBzbyB3ZSdkIG5lZWQgdG8gYWRkIHRoYXQuDQoNCk9uY2Ug bmRhdGEgaXMgc3VwcG9ydGVkLCBhbGwgd2lsbCB3b3JrIHdlbGwsIGFuZCBhcHBsaWNhdGlvbnMg dGhhdCBkaWRuJ3QgY2FyZSBhYm91dCBpbnRlcmxlYXZpbmcgZG9uJ3QgaGF2ZSB0byBjaGFuZ2Us IGFuZCB0aG9zZSB0aGF0IGRvIHdpbGwgdHJpZ2dlciBvbiBuZGF0YSBhbmQgc3dpdGNoIChhbmQg dGhleSBjYW4gdGVzdCBuZGF0YT09dHJ1ZSBtb2RlIHJlYXNvbmFibHkgd2VsbCBieSBmb3JjaW5n IGl0IGluIHRoZSBhcHAsIHNpbmNlIHNlbmQobGFyZ2UpIHdpbGwgd29yaykuDQoNCldoaWxlIEkg YWdyZWUgd2l0aCB0aGUgZmluYWwgb3V0Y29tZSBvZiAjMywgSSBkb24ndCB0aGluayBnb2luZyBk b3duIHRoZSAxLzIvMmEgcGF0aCBtYWtlcw0Kc2Vuc2UsIHNpbmNlIGl0IGxlYWRzIHRvIGFuIGFk ZGl0aW9uYWwgaW50ZXJtZWRpYXRlIHN0YXRlIG92ZXIgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLiBp LmUuIHdlIGVuZCB1cCB3aXRoIDMgc3RhdGVzOg0KYSkgdG9kYXk6IG1heCBzYWZlIHNlbmQgaXMg MTYgS0INCmIpIHNvb246IG5kYXRhIGV4aXN0cywgYnV0IGxhcmdlIHNlbmRzIGxvY2sgb3V0IG90 aGVyIHNlbmRzDQpjKSBmaW5hbDogbmRhdGEgZXhpc3RzLCBhbmQgbGFyZ2Ugc2VuZHMgd29yayBP Sw0KDQpJIHdvdWxkIHJhdGhlciBtYWludGFpbiBhKSBvciBzaW1pbGFyIGZvciBub3cgKHVzaW5n IHRoZSBtYXgtbWVzc2FnZS1zaXplIHBhcmFtKSBhbmQganVtcCB0byBjKSB3aGVuIHdlIGhhdmUg dGhlIHJpZ2h0IHN0dWZmIGluIFNDVFAuDQpbUmFqdV0gV2l0aCAxNktCIHNhZmUgc2l6ZSB3b27i gJl0IGFwcGxpY2F0aW9ucyBoYXZlIHRvIGhhdmUgdGhlaXIgb3duIGNodW5raW5nIHByb3RvY29s PyBhcyBwZXIgbXkgdW5kZXJzdGFuZGluZyBFT1Igd29u4oCZdCBzb2x2ZSB0aGUgbW9ub3BvbGl6 YXRpb24gaXNzdWUsIHNvIGl0IGFkZHMgbm8gdmFsdWUuDQoNClRvIGF2b2lkIGFwcGxpY2F0aW9u cyBjb21pbmcgdXAgd2l0aCB0aGVpciBvd24gY2h1bmtpbmcgcHJvdG9jb2wsIGFuIGF0dHJhY3Rp dmUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gdXNlIHRoZSBQUElEIGNodW5raW5nIHRoYXTigJlz IGFscmVhZHkgbWVudGlvbmVkIGFib3ZyIGFuZCBpbXBsZW1lbnRlZCBieSBGaXJlZm94LiBUaGVu IHRoZSBpc3N1ZSBvZiBpbnRlcndvcmtpbmcgcHVzaGVkIGRvd24gdG8gYnJvd3NlciBmcm9tIGFw cGxpY2F0aW9uIGFyZWEuIEJ1dCB0aGlzIG9idmlvdXNseSByZXF1aXJlcyBicm93c2VycyBvbiBi b3RoIHRoZSBlbmRzIHRvIHN1cHBvcnQgdGhpcyBQUElEIGJhc2VkIGNodW5raW5nLg0KDQotUmFq dQ0KDQoNCg0KLS0NClJhbmRlbGwgSmVzdXAgLS0gcmplc3VwIGEgdCBtb3ppbGxhIGQgbyB0IGNv bQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dl YiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_E1FE4C082A89A246A11D7F32A95A17826E006069US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxMTMwNjI4ODIxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo5MzY5NTIwODggLTI0MDIzNTQ5MiA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5Tb3JyeSB0byBqdW1wIGluIGZy b20gbWlkZGxlIG9mIG5vd2hlcmUgaW4gdGhpcyBpbnRlcmVzdGluZyBjb252ZXJzYXRpb24uIEkg Y291bGRu4oCZdCByZXNpc3QgcHJvdmlkaW5nIHRoaXMgZmVlZGJhY2sgYW5kIEkgaG9wZSBpdCBp cyB1c2VmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDBCMDUwIj5GaXJzdCwgb24g4oCcRU9SIHNvbHZpbmcgbW9ub3BvbGl6YXRp b24gaXNzdWXigJ06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgY291bGQgYmUgd3Jv bmcsIGJ1dCBJIGFtIG5vdCBzdXJlIGhvdyBFT1IgYmFzZWQgYXBwcm9hY2ggYXZvaWRzIFNDVFAg bGluayBtb25vcG9saXphdGlvbj8hIFBlciBteSB1bmRlcnN0YW5kaW5nIEVPUiBpcyBhIGxvY2Fs IHNlbmQgKCkgdXRpbGl0eSByYXRoZXIgdGhhbg0KIHJlY2VpdmUgc2lkZSB1dGlsaXR5IGFuZCBp dCBpcyBpbXBsZW1lbnRlZCBvbiB0b3Agb2YgYmFzZSBTQ1RQIFJGQyAoc28gbm8gaW5kaWNhdGlv biBvZiBzcGVjaWFsIEVPUiBpbiBTQ1RQIGhlYWRlcnMgb3RoZXIgdGhhbiBiYXNlIFNDVFAgUkZD IEIvRSBmcmFnbWVudCBpbmRpY2F0aW9uIGJpdHMpLiBPbmNlIGEgc2VuZCAoKSB3aXRoIEVPUiBz ZXQgdG8gZmFsc2UgaXMgY2FsbGVkLCBvbiBhIHN0cmVhbSBpZCwgdGhlIFNDVFAgbGluayBpcyBt b25vcG9saXplZA0KIHVudGlsIHNlbmQgKCkgb24gc2FtZSBzdHJlYW0gaWQgd2l0aCBFT1Igc2V0 IHRvIHRydWUgaXMgY2FsbGVkOyBzbyBzYW1lIGxpbWl0YXRpb24gZXhpc3QuICZuYnNwO0VPUiBh bGxvd3Mgc2VuZGluZyBzaWRlIHRvIHN0YXJ0IHNlbmRpbmcgY2h1bmtzIHdpdGhvdXQgd2FpdGlu ZyBmb3IgY29tcGxldGUgZGF0YS4gRU9SIGhhcyBubyBpbXBhY3Qgb24gcmVjZWl2aW5nIHNpZGUs IHRoZSBTQ1RQIHN0YWNrIHdhaXRzIGZvciBsYXN0IGNodW5rICh3aGljaCBpcw0KIHRoZSByZXN1 bHQgb2Ygc2VuZGluZyBzaWRlIHNldHRpbmcgRU9SPXRydWUpIGFuZCBkZWxpdmVycyBlbnRpcmUg bWVzc2FnZSB0byBhcHAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpyZWQiPk5ldyBQQyBhcHByb2FjaDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+SWYgYW4gYXBwbGljYXRpb24gaXMgc2Vuc2l0aXZlIHRvIFNDVFAgbGluayBt b25vcG9saXNhdGlvbiB0aGVuIHRoZXJlIGlzIGFub3RoZXIgb3B0aW9uIGl0IGNhbiBjb25zaWRl ciDigJMNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj51c2Ug b2Ygc2VwYXJhdGUgbmV3IFBlZXJDb25uZWN0aW9uIChQQykgZm9yIHRoZSBkYXRhIGNoYW5uZWwo cykgd2hpY2ggbWF5IG1vbm9wb2xpemUgdGhlIGxpbmsuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MEIwNTAiPkRlcGVuZGluZyBvbiBob3cgYW4gYXBwbGljYXRpb24gaXMgZGVzaWduZWQsIHVzaW5n IGEgbmV3IFBDIGNvdWxkIGJlIHNpbXBsZXIgdGhhbiBoYXZpbmcgYW4gYXBwbGljYXRpb24gbGV2 ZWwgY2h1bmtpbmcgcHJvdG9jb2wgKGZyYWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkpLg0KICZu YnNwO0lmIGFwcCBuZWVkcyBzdWNoIOKAnGhlYXZ54oCdIGRhdGEgY2hhbm5lbCBpbmZyZXF1ZW50 bHkgdGhlbiBpdCBjYW4gY3JlYXRlIG5ldyBQQyBhcyBuZWVkZWQ7IGlmIGl0IGlzIG5lZWRlZCBm cmVxdWVudGx5IHRoZW4gYSBkZWRpY2F0ZWQgUEMgY2FuIGJlIGFsbG9jYXRlZCBhbmQga2VlcCBp dCBvcGVuIGFsbCB0aGUgdGltZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPk9uZSBkaXNhZHZhbnRhZ2Ugd2l0aCBhcHBs aWNhdGlvbiBsZXZlbCBjaHVua2luZyBwcm90b2NvbCBpcyBib3RoIHRoZSBwZWVycyBuZWVkIHRv IHVzZSBpdDsgc28gaXQgbWF5IG5vdCB3b3JrIGJldHdlZW4gY2xpZW50cyBvZiBkaWZmZXJlbnQg dHlwZXMgb3Igc2FtZSBjbGllbnRzDQogd2l0aCBkaWZmZXJlbnQgdmVyc2lvbnMuIE5ldyBQQyBi YXNlZCBhcHByb2FjaCBvYnZpb3VzbHkgZG9lcyBub3QgaGF2ZSB0aGlzIGlzc3VlIGFzIG5vIGNo dW5raW5nIGlzIGludm9sdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+QXQgZmlyc3QsIG5ldyBQQyBhcHByb2FjaCBt YXkgYXBwZWFyIGhlYXZ5IHdlaWdodCB3cnQgIyBvZiBQQ3MgaW4gdXNlICh3aGljaCBJIGRvbuKA mXQgdGhpbmsgYW4gaXNzdWUgb24gYnJvd3NlcnMpLCBJQ0Ugb3ZlcmhlYWQgZm9yIG5ldyBQQyBl dGMuIEJ1dCBpbiBjb21wYXJpc2lvbg0KIHRvIGFwcGxpY2F0aW9uIGxldmVsIGNodW5raW5nIG5l dyBQQyBhcHByb2FjaCBtYXkgbm90IGJlIHRoYXQgYmFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+UGxlYXNlIHNlZSBh ZGRpdGlvbmFsIGNvbW1lbnRzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPi1SYWp1PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMDMsIDIwMTQgMTE6NTQgQU08YnI+DQo8Yj5Ubzo8L2I+ IFJhbmRlbGwgSmVzdXA8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gT3BlbiBkYXRhIGNoYW5uZWwgaXNzdWVzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTW9uLCBNYXIgMywgMjAxNCBhdCA3OjI2IEFNLCBSYW5kZWxsIEplc3VwICZsdDs8 YSBocmVmPSJtYWlsdG86cmFuZGVsbC1pZXRmQGplc3VwLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJh bmRlbGwtaWV0ZkBqZXN1cC5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzLzMvMjAxNCA4OjUzIEFNLCBNYXJ0aW4gVGhvbXNv biB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMgTWFyY2gg MjAxNCAwMzo0NCwgUmFuZGVsbCBKZXN1cCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmRlbGwtaWV0 ZkBqZXN1cC5vcmciIHRhcmdldD0iX2JsYW5rIj5yYW5kZWxsLWlldGZAamVzdXAub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3BlZnVsbHkg c28sIHRob3VnaCBJIGhhdGUgZm9yY2luZyBhcHBzIHRvIGluY2x1ZGUgYSBidW5jaCBvZiBjb2Rl IGZvcjxicj4NCmJhY2t3YXJkcyBjb21wYXQgZm9yIGEgeWVhciBvciB0d28gKGFuZCBtYW55IHdv bid0LCBvciB3b24ndCB0ZXN0IGl0LCBldGMpLjxicj4NClRoYXQgaHVydHMgdGhlIGZlYXR1cmUu ICZuYnNwO0FuZCB0b2RheSBubyBvbmUgaGFzIG5kYXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U2luY2UgV2ViUlRDIGlzIGJlaGluZCBhIGZsYWcsIEkgZG9uJ3QgZmlu ZCB0aGlzIHBhcnRpY3VsYXJseTxicj4NCmNvbnZpbmNpbmcuICZuYnNwO1dlIGNhbiBpbXBsZW1l bnQgbmRhdGEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB1bmRlcnN0 YW5kIHRoZSAmcXVvdDtiZWhpbmQgYSBmbGFnJnF1b3Q7IGNvbW1lbnQ7IGFuIGFwcCB1c2luZyBE YXRhQ2hhbm5lbHMgZm9yIGFueXRoaW5nIHZhcmlhYmxlLWxlbmd0aCAodW5sZXNzIHdpdGggbG93 IGJvdW5kcykgbXVzdCBjYXJlIHVudGlsIGFsbCBvbGQgaW1wbGVtZW50YXRpb25zIGFyZSBnb25l LiAmbmJzcDtTaW5jZSB3ZSBhbHJlYWR5IGhhdmUgRGF0YUNoYW5uZWwgaW1wbHMgaW4gJm5ic3A7 RVNSIHJlbGVhc2VzLA0KIHRoZXJlJ3Mgbm8gYXZvaWRpbmcgdGhpcyBpZiB3ZSByZWx5IG9uIHRo YXQgKGV2ZW4gd29yc2UsIHNpbmNlIHRoaXMgdW5kZWZpbmVkIHByb3BlcnR5IGRvZXNuJ3QgZXhp c3QgeWV0IChsZXQgYWxvbmUgaW4gRVNSKSwgdGhlIGFwcCBoYXMgdG8gaGFuZGxlIHRoYXQgY2Fz ZSBhcyB3ZWxsKS4gJm5ic3A7T3IgYWRkIGJyb3dzZXIgYW5kIHZlcnNpb24gc25pZmZpbmcgdG8g YWxsIHRoZSBhcHBzLi4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgd2UgY291bGQgZXZl biByZW1vdmUgb3VyIHRlbXBvcmFyeSBsZW5ndGggcmVzdHJpY3Rpb24uPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZSwgd2UgY2FuLiAmbmJzcDtUaGlz IHdpbGwgcmVkdWNlIG9yIGVsaW1pbmF0ZSBzb3VyY2UgY2hhbmdlcyBmb3IgYXBwcyB0aGF0IGRv bid0IGNhcmUgYWJvdXQgaW50ZXJsZWF2aW5nLCB3aGljaCBpcyBhIHBsdXMuICZuYnNwO0l0IHdp bGwgY2F1c2UgdG90YWwgc3RhbGwgb2YgYWxsIG90aGVyIERhdGFDaGFubmVscyBkdXJpbmcgJm5i c3A7dHJhbnNtaXNzaW9uIG9mIG9uZSBsYXJnZSBtZXNzYWdlLCB3aGljaCBzb21lIGFwcGxpY2F0 aW9ucw0KIHdvdWxkIGJlIG9rIHdpdGgsIGFuZCBvdGhlcnMgd291bGQgbm90LCBhbmQgc28gdGhv c2UgdGhhdCB3b3VsZCBub3Qgd291bGQgaGF2ZSB0byBzb21laG93IGRlYWwgd2l0aCBpdC48YnI+ DQo8YnI+DQpTbywgYXBwbGljYXRpb25zIHRoYXQgYXJlIG9rIHdpdGggYmxvY2tpbmcgb3RoZXIg Y2hhbm5lbHMgd2l0aCBsYXJnZSBzZW5kcyBjb3VsZCBiZSBhbGxvd2VkIHRvIHNlbmQgYXJiaXRy YXJ5LXNpemVkIG1lc3NhZ2VzLCBhbmQgcmVjZWl2ZXJzIHdvdWxkIGJlIHJlcXVpcmVkIHRvIHJl Y2VpdmUgdGhlbSAod2l0aG91dCBjaHVua2luZykuIEFwcGxpY2F0aW9ucyB0aGF0IGRvIGNhcmUg YWJvdXQgb3RoZXIgY2hhbm5lbHMgd291bGQgbmVlZCB0byByZXN0cmljdA0KIHRoZWlyIHNlbmRp bmcgc2l6ZSB3aGVuIG5kYXRhIGlzbid0IGF2YWlsYWJsZSBhdCBib3RoIGVuZHMuICZuYnNwO1dl IHJlYWxseSBvbmx5IG5lZWQgdG8ga25vdyBpZiBuZGF0YSBpcyBhdmFpbGFibGUgYW5kIGV4cG9z ZSB0aGF0IGZhY3QgdG8gdGhlIGFwcGxpY2F0aW9uLCBub3QgYSByZWNlaXZlIHNpemUgZnJvbSB0 aGUgcmVjZWl2ZXIuPGJyPg0KPGJyPg0KU28gdGhpcyBwbGFuIHdvdWxkIGJlOjxicj4NCjEpIFdl IGV4cG9zZSBuZGF0YSBiZWluZyBhZ3JlZWQgdG8gKGN1cnJlbnRseSA9PSBmYWxzZSk7PGJyPg0K MikgV2UgdHVybiBvZmYgdGhlIFBQSUQgY2h1bmtpbmcgaW4gRmlyZWZveCAoYW5kIGxpdmUgd2l0 aCBFU1IyNCBhbmQgY3VycmVudCByZXZzIG9mIEZpcmVmb3ggbm90IGJlaW5nIGNvbXBhdGlibGU7 IHNlZSAyYSk8YnI+DQoyYSkgd2UgbWFrZSBzdXJlIHRoZSBhcHAgY2FuIGRldGVjdCBpZiB0aGUg bG9jYWwgY2xpZW50IGhhcyB0aGUgbmRhdGEgcHJvcGVydHkgYXQgYWxsIChzdXBwb3J0cyB0aGlz IHNvbHV0aW9uKS48YnI+DQozKSBXZSBtYWtlIHN1cmUgQ2hyb21lIGFuZCBGaXJlZm94IGJvdGgg aW1wbGVtZW50IGJvdGggRU9SIHNlbmRpbmcgYW5kIEVPUiByZWNlcHRpb24gYW5kIHVubGltaXRl ZCAob3IgdmlydHVhbGx5KSBzZW5kL3JlY2VpdmUgc2l6ZXMuPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5bUmFqdV0gVGhpcyBy ZXF1aXJlcyBQZWVyQ29ubmVjdGlvbiBBUEkgdG8gaW5kaWNhdGUgRU9SIGR1cmluZyBzZW5kKCku IFJpZ2h0PyBXaGljaCBtYXkgYmUgdXNlZnVsIGluIHNvbWUgY2FzZXMgd2hlcmUgYXBwIHdhbnRz IHRvIHNlbmQgcGFydGlhbCBkYXRhIGFzDQogaXQgaXMgYXZhaWxhYmxlL3JlYWR5LiBCdXQgYXMg ZXhwbGFpbmVkIGFib3ZlLCBpbiBteSBvcGluaW9uIEVPUiB3b27igJl0IHNvbHZlIFNDVFAgbGlu ayBtb25vcG9saXphdGlvbiBhbmQgdW5uY2Vzc2FyaWx5IGludHJvZHVjZXMgb3ZlcmhlYWQgYXQg YXBwbGljYXRpb24uPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMEIwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCkZvciBib251cyBwb2ludHMsIG9uIEVPUiByZWNlcHRpb24gb2YgYSBibG9iLCBzcG9v bCBpdCB0byBkaXNrIGluIHRoZSBicm93c2VyIChpZiBvdmVyIHNvbWUgbGltaXQgcGVyaGFwcyks IGFuZCBvbiBFT1Igc2VuZCBvZiBhIGJsb2IsIG9wdGltaXplIGl0IHRvIGF2b2lkIHNlbmQtc2lk ZSBtZW1vcnkgaGl0cyBhbmQgcGVyZm9ybWFuY2UgaXNzdWVzLjxicj4NCjxicj4NClRoaXMgd2ls bCBicmVhayBsYXJnZSBzZW5kL3JlY2VpdmUgYmV0d2VlbiBDaHJvbWUgYW5kIGN1cnJlbnQvb2xk ZXIgRmlyZWZveCAtIGJ1dCB0aG9zZSBhcmUgYnJva2VuIHRvZGF5IGJ5IENocm9tZSBub3QgaW1w bGVtZW50IFBQSUQgY2h1bmtpbmcgYW5kIEZpcmVmb3ggZG9pbmcgc28uICZuYnNwO0ZpcmVmb3gg Y2FuIHN0aWxsIGZhbGwgYmFjayBvbiBQUElEIGNodW5raW5nIGlmIGl0IGtub3dzIGl0J3MgdGFs a2luZyB0byBhbm90aGVyIEZpcmVmb3ggdW50aWwNCiB3ZSBkZWNpZGUgdGhhdCB0aGlzIG5vIGxv bmdlciBtYXR0ZXJzLiAmbmJzcDtJIGNvdWxkIGJlIHdyb25nLCBidXQgSSB0aGluayBDaHJvbWUg ZG9lc24ndCBzdXBwb3J0IEVPUiBzZW5kaW5nIGN1cnJlbnRseTsgSSBrbm93IEZpcmVmb3ggZG9l c24ndCBzaW5jZSB3ZSB3ZXJlIHVzaW5nIFBQSUQgY2h1bmtpbmcsIHNvIHdlJ2QgbmVlZCB0byBh ZGQgdGhhdC48YnI+DQo8YnI+DQpPbmNlIG5kYXRhIGlzIHN1cHBvcnRlZCwgYWxsIHdpbGwgd29y ayB3ZWxsLCBhbmQgYXBwbGljYXRpb25zIHRoYXQgZGlkbid0IGNhcmUgYWJvdXQgaW50ZXJsZWF2 aW5nIGRvbid0IGhhdmUgdG8gY2hhbmdlLCBhbmQgdGhvc2UgdGhhdCBkbyB3aWxsIHRyaWdnZXIg b24gbmRhdGEgYW5kIHN3aXRjaCAoYW5kIHRoZXkgY2FuIHRlc3QgbmRhdGE9PXRydWUgbW9kZSBy ZWFzb25hYmx5IHdlbGwgYnkgZm9yY2luZyBpdCBpbiB0aGUgYXBwLCBzaW5jZSBzZW5kKGxhcmdl KQ0KIHdpbGwgd29yaykuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XaGlsZSBJIGFncmVlIHdpdGggdGhlIGZpbmFsIG91dGNvbWUgb2YgIzMsIEkgZG9uJ3Qg dGhpbmsgZ29pbmcgZG93biB0aGUgMS8yLzJhIHBhdGggbWFrZXMNCjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5z ZW5zZSwgc2luY2UgaXQgbGVhZHMgdG8gYW4gYWRkaXRpb25hbCBpbnRlcm1lZGlhdGUgc3RhdGUg b3ZlciB0aGUgY3VycmVudCBzaXR1YXRpb24uIGkuZS4gd2UgZW5kIHVwIHdpdGggMyBzdGF0ZXM6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hKSB0 b2RheTogbWF4IHNhZmUgc2VuZCBpcyAxNiBLQjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Yikgc29vbjogbmRhdGEgZXhpc3RzLCBidXQgbGFyZ2Ug c2VuZHMgbG9jayBvdXQgb3RoZXIgc2VuZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmMpIGZpbmFsOiBuZGF0YSBleGlzdHMsIGFuZCBsYXJnZSBz ZW5kcyB3b3JrIE9LPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgd291bGQgcmF0aGVyIG1haW50YWluIGEpIG9yIHNpbWlsYXIgZm9yIG5vdyAo dXNpbmcgdGhlIG1heC1tZXNzYWdlLXNpemUgcGFyYW0pIGFuZCBqdW1wIHRvIGMpIHdoZW4gd2Ug aGF2ZSB0aGUgcmlnaHQgc3R1ZmYgaW4gU0NUUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUw Ij5bUmFqdV0gV2l0aCAxNktCIHNhZmUgc2l6ZSB3b27igJl0IGFwcGxpY2F0aW9ucyBoYXZlIHRv IGhhdmUgdGhlaXIgb3duIGNodW5raW5nIHByb3RvY29sPyBhcyBwZXIgbXkgdW5kZXJzdGFuZGlu ZyBFT1Igd29u4oCZdCBzb2x2ZSB0aGUgbW9ub3BvbGl6YXRpb24gaXNzdWUsDQogc28gaXQgYWRk cyBubyB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5UbyBhdm9p ZCBhcHBsaWNhdGlvbnMgY29taW5nIHVwIHdpdGggdGhlaXIgb3duIGNodW5raW5nIHByb3RvY29s LCBhbiBhdHRyYWN0aXZlIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIHVzZSB0aGUgUFBJRCBjaHVu a2luZyB0aGF04oCZcyBhbHJlYWR5IG1lbnRpb25lZA0KIGFib3ZyIGFuZCBpbXBsZW1lbnRlZCBi eSBGaXJlZm94LiBUaGVuIHRoZSBpc3N1ZSBvZiBpbnRlcndvcmtpbmcgcHVzaGVkIGRvd24gdG8g YnJvd3NlciBmcm9tIGFwcGxpY2F0aW9uIGFyZWEuIEJ1dCB0aGlzIG9idmlvdXNseSByZXF1aXJl cyBicm93c2VycyBvbiBib3RoIHRoZSBlbmRzIHRvIHN1cHBvcnQgdGhpcyBQUElEIGJhc2VkIGNo dW5raW5nLg0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+LVJhanU8bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQotLSA8YnI+DQpSYW5kZWxs IEplc3VwIC0tIHJqZXN1cCBhIHQgbW96aWxsYSBkIG8gdCBjb208bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17826E006069US70UWXCHMBA02z_-- From nobody Mon Mar 3 14:45:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8281A01E8 for ; Mon, 3 Mar 2014 14:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvZ6hQOOAqL6 for ; Mon, 3 Mar 2014 14:45:43 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A81A00DD for ; Mon, 3 Mar 2014 14:45:42 -0800 (PST) Received: from [130.129.15.249] (unknown [130.129.15.249]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A61571C103E6D; Mon, 3 Mar 2014 23:45:38 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Mon, 3 Mar 2014 22:45:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7387F0E6-2DE0-4372-8559-B9DE9B9F365F@lurchi.franken.de> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g0ELk6ERtYL9RWof1PQAI8FLgMQ Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 03 Mar 2014 22:45:47 -0000 On 03 Mar 2014, at 22:19, Makaraju, Maridi Raju (Raju) = wrote: > Sorry to jump in from middle of nowhere in this interesting = conversation. I couldn=92t resist providing this feedback and I hope it = is useful. > =20 > First, on =93EOR solving monopolization issue=94: > I could be wrong, but I am not sure how EOR based approach avoids SCTP = link monopolization?! Per my understanding EOR is a local send () = utility rather than receive side utility and it is implemented on top of = base SCTP RFC (so no indication of special EOR in SCTP headers other = than base SCTP RFC B/E fragment indication bits). Once a send () with = EOR set to false is called, on a stream id, the SCTP link is monopolized = until send () on same stream id with EOR set to true is called; so same = limitation exist. EOR allows sending side to start sending chunks = without waiting for complete data. EOR has no impact on receiving side, = the SCTP stack waits for last chunk (which is the result of sending side = setting EOR=3Dtrue) and delivers entire message to app. You are right, if you consider RFC 4960. But using http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 overcomes this limitation. You can have on each stream a message being = sent in explicit EOR mode. Using an interleaving scheduler, they get interleaved on the wire. So = you need the NDATA extension... > =20 > New PC approach: > If an application is sensitive to SCTP link monopolisation then there = is another option it can consider =96 use of separate new PeerConnection = (PC) for the data channel(s) which may monopolize the link. > Depending on how an application is designed, using a new PC could be = simpler than having an application level chunking protocol = (fragmentation and reassembly). If app needs such =93heavy=94 data = channel infrequently then it can create new PC as needed; if it is = needed frequently then a dedicated PC can be allocated and keep it open = all the time. > =20 > One disadvantage with application level chunking protocol is both the = peers need to use it; so it may not work between clients of different = types or same clients with different versions. New PC based approach = obviously does not have this issue as no chunking is involved. > =20 > At first, new PC approach may appear heavy weight wrt # of PCs in use = (which I don=92t think an issue on browsers), ICE overhead for new PC = etc. But in comparision to application level chunking new PC approach = may not be that bad. I think the large message support with NDATA is sufficient to do = whatever RTCWeb wants... > =20 > Please see additional comments inline. > =20 > -Raju > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin = Uberti > Sent: Monday, March 03, 2014 11:54 AM > To: Randell Jesup > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Open data channel issues > =20 > =20 > =20 >=20 > On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup = wrote: > On 3/3/2014 8:53 AM, Martin Thomson wrote: > On 3 March 2014 03:44, Randell Jesup wrote: > Hopefully so, though I hate forcing apps to include a bunch of code = for > backwards compat for a year or two (and many won't, or won't test it, = etc). > That hurts the feature. And today no one has ndata. > Since WebRTC is behind a flag, I don't find this particularly > convincing. We can implement ndata. > =20 > I don't understand the "behind a flag" comment; an app using = DataChannels for anything variable-length (unless with low bounds) must = care until all old implementations are gone. Since we already have = DataChannel impls in ESR releases, there's no avoiding this if we rely = on that (even worse, since this undefined property doesn't exist yet = (let alone in ESR), the app has to handle that case as well). Or add = browser and version sniffing to all the apps... > =20 >=20 > I think that we could even remove our temporary length restriction. > =20 > Sure, we can. This will reduce or eliminate source changes for apps = that don't care about interleaving, which is a plus. It will cause = total stall of all other DataChannels during transmission of one large = message, which some applications would be ok with, and others would not, = and so those that would not would have to somehow deal with it. >=20 > So, applications that are ok with blocking other channels with large = sends could be allowed to send arbitrary-sized messages, and receivers = would be required to receive them (without chunking). Applications that = do care about other channels would need to restrict their sending size = when ndata isn't available at both ends. We really only need to know if = ndata is available and expose that fact to the application, not a = receive size from the receiver. >=20 > So this plan would be: > 1) We expose ndata being agreed to (currently =3D=3D false); > 2) We turn off the PPID chunking in Firefox (and live with ESR24 and = current revs of Firefox not being compatible; see 2a) > 2a) we make sure the app can detect if the local client has the ndata = property at all (supports this solution). > 3) We make sure Chrome and Firefox both implement both EOR sending and = EOR reception and unlimited (or virtually) send/receive sizes. > [Raju] This requires PeerConnection API to indicate EOR during send(). = Right? Which may be useful in some cases where app wants to send partial = data as it is available/ready. But as explained above, in my opinion EOR = won=92t solve SCTP link monopolization and unncessarily introduces = overhead at application. At the API to the SCTP stack you need EOR support. But this API is not = exposed to the JS user. The JS user can just call send(bigmessage) and it works... >=20 > For bonus points, on EOR reception of a blob, spool it to disk in the = browser (if over some limit perhaps), and on EOR send of a blob, = optimize it to avoid send-side memory hits and performance issues. >=20 > This will break large send/receive between Chrome and current/older = Firefox - but those are broken today by Chrome not implement PPID = chunking and Firefox doing so. Firefox can still fall back on PPID = chunking if it knows it's talking to another Firefox until we decide = that this no longer matters. I could be wrong, but I think Chrome = doesn't support EOR sending currently; I know Firefox doesn't since we = were using PPID chunking, so we'd need to add that. >=20 > Once ndata is supported, all will work well, and applications that = didn't care about interleaving don't have to change, and those that do = will trigger on ndata and switch (and they can test ndata=3D=3Dtrue mode = reasonably well by forcing it in the app, since send(large) will work). > =20 > While I agree with the final outcome of #3, I don't think going down = the 1/2/2a path makes > sense, since it leads to an additional intermediate state over the = current situation. i.e. we end up with 3 states: > a) today: max safe send is 16 KB > b) soon: ndata exists, but large sends lock out other sends > c) final: ndata exists, and large sends work OK > =20 > I would rather maintain a) or similar for now (using the = max-message-size param) and jump to c) when we have the right stuff in = SCTP. > [Raju] With 16KB safe size won=92t applications have to have their own = chunking protocol? as per my understanding EOR won=92t solve the = monopolization issue, so it adds no value. > =20 > To avoid applications coming up with their own chunking protocol, an = attractive alternative would be to use the PPID chunking that=92s = already mentioned abovr and implemented by Firefox. Then the issue of = interworking pushed down to browser from application area. But this = obviously requires browsers on both the ends to support this PPID based = chunking. ... correct. And at the last RTCWeb session it was decided to avoid this = intermediate step and just use NDATA... Best regards Michael > =20 > -Raju > =20 >=20 >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 3 19:39:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106231A031B for ; Mon, 3 Mar 2014 19:39:53 -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 yy4kwODwVEDY for ; Mon, 3 Mar 2014 19:39:47 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EDCDD1A031A for ; Mon, 3 Mar 2014 19:39:45 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:3206 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKgCk-0002a9-Ar for rtcweb@ietf.org; Mon, 03 Mar 2014 21:39:42 -0600 Message-ID: <53154AA8.4000202@jesup.org> Date: Mon, 03 Mar 2014 22:38:16 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050703090904060301060305" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qh9IBdvRbkCBfzoso4Use8Gd-eY Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 03:39:53 -0000 This is a multi-part message in MIME format. --------------050703090904060301060305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/3/2014 12:54 PM, Justin Uberti wrote: > > > > On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup > wrote: > > On 3/3/2014 8:53 AM, Martin Thomson wrote: > > On 3 March 2014 03:44, Randell Jesup > wrote: > > Hopefully so, though I hate forcing apps to include a > bunch of code for > backwards compat for a year or two (and many won't, or > won't test it, etc). > That hurts the feature. And today no one has ndata. > > Since WebRTC is behind a flag, I don't find this particularly > convincing. We can implement ndata. > > > I don't understand the "behind a flag" comment; an app using > DataChannels for anything variable-length (unless with low bounds) > must care until all old implementations are gone. Since we > already have DataChannel impls in ESR releases, there's no > avoiding this if we rely on that (even worse, since this undefined > property doesn't exist yet (let alone in ESR), the app has to > handle that case as well). Or add browser and version sniffing to > all the apps... > > > I think that we could even remove our temporary length > restriction. > > > Sure, we can. This will reduce or eliminate source changes for > apps that don't care about interleaving, which is a plus. It will > cause total stall of all other DataChannels during transmission > of one large message, which some applications would be ok with, > and others would not, and so those that would not would have to > somehow deal with it. > > So, applications that are ok with blocking other channels with > large sends could be allowed to send arbitrary-sized messages, and > receivers would be required to receive them (without chunking). > Applications that do care about other channels would need to > restrict their sending size when ndata isn't available at both > ends. We really only need to know if ndata is available and > expose that fact to the application, not a receive size from the > receiver. > > So this plan would be: > 1) We expose ndata being agreed to (currently == false); > 2) We turn off the PPID chunking in Firefox (and live with ESR24 > and current revs of Firefox not being compatible; see 2a) > 2a) we make sure the app can detect if the local client has the > ndata property at all (supports this solution). > 3) We make sure Chrome and Firefox both implement both EOR sending > and EOR reception and unlimited (or virtually) send/receive sizes. > > For bonus points, on EOR reception of a blob, spool it to disk in > the browser (if over some limit perhaps), and on EOR send of a > blob, optimize it to avoid send-side memory hits and performance > issues. > > This will break large send/receive between Chrome and > current/older Firefox - but those are broken today by Chrome not > implement PPID chunking and Firefox doing so. Firefox can still > fall back on PPID chunking if it knows it's talking to another > Firefox until we decide that this no longer matters. I could be > wrong, but I think Chrome doesn't support EOR sending currently; I > know Firefox doesn't since we were using PPID chunking, so we'd > need to add that. > > Once ndata is supported, all will work well, and applications that > didn't care about interleaving don't have to change, and those > that do will trigger on ndata and switch (and they can test > ndata==true mode reasonably well by forcing it in the app, since > send(large) will work). > > > While I agree with the final outcome of #3, I don't think going down > the 1/2/2a path makes sense, since it leads to an additional > intermediate state over the current situation. i.e. we end up with 3 > states: > a) today: max safe send is 16 KB > b) soon: ndata exists, but large sends lock out other sends > c) final: ndata exists, and large sends work OK > > I would rather maintain a) or similar for now (using the > max-message-size param) and jump to c) when we have the right stuff in > SCTP. So, is there any significant advantage to using a max-message-size param (with >16K) as an interim step? You get 3 similar steps (though perhaps with a smaller lockout). To take your suggestion: a) applications assume 16KB if ndata wasn't negotiated (per the current suggestion) b) implement ndata and EOR support in the browsers, and drop the 16KB limit when ndata is negotiated. All this needs is "is ndata supported by this association" exposed to the app; no sdp changes needed. (One less dependency!) -- Randell Jesup -- rjesup a t mozilla d o t com --------------050703090904060301060305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/3/2014 12:54 PM, Justin Uberti wrote:



On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 3/3/2014 8:53 AM, Martin Thomson wrote:
On 3 March 2014 03:44, Randell Jesup <randell-ietf@jesup.org> wrote:
Hopefully so, though I hate forcing apps to include a bunch of code for
backwards compat for a year or two (and many won't, or won't test it, etc).
That hurts the feature.  And today no one has ndata.
Since WebRTC is behind a flag, I don't find this particularly
convincing.  We can implement ndata.

I don't understand the "behind a flag" comment; an app using DataChannels for anything variable-length (unless with low bounds) must care until all old implementations are gone.  Since we already have DataChannel impls in  ESR releases, there's no avoiding this if we rely on that (even worse, since this undefined property doesn't exist yet (let alone in ESR), the app has to handle that case as well).  Or add browser and version sniffing to all the apps...


I think that we could even remove our temporary length restriction.

Sure, we can.  This will reduce or eliminate source changes for apps that don't care about interleaving, which is a plus.  It will cause total stall of all other DataChannels during  transmission of one large message, which some applications would be ok with, and others would not, and so those that would not would have to somehow deal with it.

So, applications that are ok with blocking other channels with large sends could be allowed to send arbitrary-sized messages, and receivers would be required to receive them (without chunking). Applications that do care about other channels would need to restrict their sending size when ndata isn't available at both ends.  We really only need to know if ndata is available and expose that fact to the application, not a receive size from the receiver.

So this plan would be:
1) We expose ndata being agreed to (currently == false);
2) We turn off the PPID chunking in Firefox (and live with ESR24 and current revs of Firefox not being compatible; see 2a)
2a) we make sure the app can detect if the local client has the ndata property at all (supports this solution).
3) We make sure Chrome and Firefox both implement both EOR sending and EOR reception and unlimited (or virtually) send/receive sizes.

For bonus points, on EOR reception of a blob, spool it to disk in the browser (if over some limit perhaps), and on EOR send of a blob, optimize it to avoid send-side memory hits and performance issues.

This will break large send/receive between Chrome and current/older Firefox - but those are broken today by Chrome not implement PPID chunking and Firefox doing so.  Firefox can still fall back on PPID chunking if it knows it's talking to another Firefox until we decide that this no longer matters.  I could be wrong, but I think Chrome doesn't support EOR sending currently; I know Firefox doesn't since we were using PPID chunking, so we'd need to add that.

Once ndata is supported, all will work well, and applications that didn't care about interleaving don't have to change, and those that do will trigger on ndata and switch (and they can test ndata==true mode reasonably well by forcing it in the app, since send(large) will work).

While I agree with the final outcome of #3, I don't think going down the 1/2/2a path makes sense, since it leads to an additional intermediate state over the current situation. i.e. we end up with 3 states:
a) today: max safe send is 16 KB
b) soon: ndata exists, but large sends lock out other sends
c) final: ndata exists, and large sends work OK

I would rather maintain a) or similar for now (using the max-message-size param) and jump to c) when we have the right stuff in SCTP.

So, is there any significant advantage to using a max-message-size param (with >16K) as an interim step?  You get 3 similar steps (though perhaps with a smaller lockout).

To take your suggestion:
a) applications assume 16KB if ndata wasn't negotiated (per the current suggestion)
b) implement ndata and EOR support in the browsers, and drop the 16KB limit when ndata is negotiated.
All this needs is "is ndata supported by this association" exposed to the app; no sdp changes needed.  (One less dependency!)

-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------050703090904060301060305-- From nobody Mon Mar 3 23:00:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5C1A01AE for ; Mon, 3 Mar 2014 23:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUst73QQgnQA for ; Mon, 3 Mar 2014 23:00:26 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C4F661A03B5 for ; Mon, 3 Mar 2014 23:00:21 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id t61so1905459wes.16 for ; Mon, 03 Mar 2014 23:00:18 -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=tLotNifnH/y8FxMTXDjhEz0TX15shUVep9mA/6sh4vE=; b=G5fXlFyBsA0wEJCbQO2Wma3DCrmQkFd6oNJNP3e1oJ59vqHFssrvkaojXMn0fquvX3 NVkkiVrcSbPo0g3Pf48NWtFRVPiG4O7WSJSqfrRh5j0oXK8iuovu38o7gz58RU3NjgWA JeiOfPE8QWrOLHhZzZfZ6hmd8mu7Yh8pQZ+sLDLjEdorYcteslkLitkgoMWs7s9pAXZE bqHdpiqbglWg8mS42bK2N8ISi/oE2CmxIJcC3sm7axufZJFP7JVzUGUSYpYefJsoYw4J qL8j+i7q8yJyqnyx6juadYS2COhWzwRbHaaRNezWR9VEXzpEI3c9Z3UgHYMd4f4txrC3 LBDw== MIME-Version: 1.0 X-Received: by 10.194.2.194 with SMTP id 2mr12924874wjw.73.1393916418219; Mon, 03 Mar 2014 23:00:18 -0800 (PST) Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 23:00:18 -0800 (PST) In-Reply-To: <53154AA8.4000202@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> <53154AA8.4000202@jesup.org> Date: Tue, 4 Mar 2014 07:00:18 +0000 Message-ID: From: Martin Thomson To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kYJmPXbaWUREbR6ocPZ-d4-l3XU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 07:00:28 -0000 On 4 March 2014 03:38, Randell Jesup wrote: > To take your suggestion: > a) applications assume 16KB if ndata wasn't negotiated (per the current > suggestion) > b) implement ndata and EOR support in the browsers, and drop the 16KB limit > when ndata is negotiated. > All this needs is "is ndata supported by this association" exposed to the > app; no sdp changes needed. (One less dependency!) Or, to avoid vestigal crap in the API in the end state, when you install the 16K limitation, add an indicator that applications can check. Once you remove the cap, remove the indicator. if (dataChannel.isNotVeryGood) { chunkMessage(message); } else { dataChannel.send(message); } From nobody Mon Mar 3 23:31:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6641A03C8 for ; Mon, 3 Mar 2014 23:31:43 -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, 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 FeGSi6PZksF2 for ; Mon, 3 Mar 2014 23:31:41 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9747C1A03C3 for ; Mon, 3 Mar 2014 23:31:41 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4066 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKjpC-0002HX-4q for rtcweb@ietf.org; Tue, 04 Mar 2014 01:31:38 -0600 Message-ID: <53158103.4000809@jesup.org> Date: Tue, 04 Mar 2014 02:30:11 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> <53154AA8.4000202@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M5juK2miXJA_69FHiExo1zmPqxw Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 07:31:43 -0000 On 3/4/2014 2:00 AM, Martin Thomson wrote: > On 4 March 2014 03:38, Randell Jesup wrote: >> To take your suggestion: >> a) applications assume 16KB if ndata wasn't negotiated (per the current >> suggestion) >> b) implement ndata and EOR support in the browsers, and drop the 16KB limit >> when ndata is negotiated. >> All this needs is "is ndata supported by this association" exposed to the >> app; no sdp changes needed. (One less dependency!) > > Or, to avoid vestigal crap in the API in the end state, when you > install the 16K limitation, add an indicator that applications can > check. Once you remove the cap, remove the indicator. > > if (dataChannel.isNotVeryGood) { > chunkMessage(message); > } else { > dataChannel.send(message); > } Yup, that works for me. dataChannel.requiresFragmentation would be the wordy version or mustFragmentAt16K for self-documentation. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Mon Mar 3 23:55:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A501A03E5 for ; Mon, 3 Mar 2014 23:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4wpo_8moisC for ; Mon, 3 Mar 2014 23:55:30 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2451A03B5 for ; Mon, 3 Mar 2014 23:55:30 -0800 (PST) Received: from [130.129.15.249] (unknown [130.129.15.249]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5C50A1C104304; Tue, 4 Mar 2014 08:55:26 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53158103.4000809@jesup.org> Date: Tue, 4 Mar 2014 07:55:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> <53154AA8.4000202@jesup.org> <53158103.4000809@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LcWErxOjK2PWhzzJVrz4g1jwtSA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 07:55:33 -0000 On 04 Mar 2014, at 07:30, Randell Jesup wrote: > On 3/4/2014 2:00 AM, Martin Thomson wrote: >> On 4 March 2014 03:38, Randell Jesup wrote: >>> To take your suggestion: >>> a) applications assume 16KB if ndata wasn't negotiated (per the = current >>> suggestion) >>> b) implement ndata and EOR support in the browsers, and drop the = 16KB limit >>> when ndata is negotiated. >>> All this needs is "is ndata supported by this association" exposed = to the >>> app; no sdp changes needed. (One less dependency!) >>=20 >> Or, to avoid vestigal crap in the API in the end state, when you >> install the 16K limitation, add an indicator that applications can >> check. Once you remove the cap, remove the indicator. >>=20 >> if (dataChannel.isNotVeryGood) { >> chunkMessage(message); >> } else { >> dataChannel.send(message); >> } >=20 > Yup, that works for me. dataChannel.requiresFragmentation would be = the wordy version or mustFragmentAt16K for self-documentation. Or you return a number which gives you the limit if you don't want to = specify the 16K limit... Best regards Michael >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Mar 4 01:02:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A9A1A0427 for ; Tue, 4 Mar 2014 01:02:10 -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, 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 A3_KG92X0hmo for ; Tue, 4 Mar 2014 01:02:09 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 037BF1A0429 for ; Tue, 4 Mar 2014 01:02:08 -0800 (PST) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4679 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKlEj-0003dj-7J for rtcweb@ietf.org; Tue, 04 Mar 2014 03:02:05 -0600 Message-ID: <53159637.8050909@jesup.org> Date: Tue, 04 Mar 2014 04:00:39 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> <53154AA8.4000202@jesup.org> <53158103.4000809@jesup.org> <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de> In-Reply-To: <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZqGsJmiAqFvhYqynVQVsrIBne3g Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 09:02:10 -0000 On 3/4/2014 2:55 AM, Michael Tuexen wrote: > On 04 Mar 2014, at 07:30, Randell Jesup wrote: > >> On 3/4/2014 2:00 AM, Martin Thomson wrote: >>> On 4 March 2014 03:38, Randell Jesup wrote: >>>> To take your suggestion: >>>> a) applications assume 16KB if ndata wasn't negotiated (per the current >>>> suggestion) >>>> b) implement ndata and EOR support in the browsers, and drop the 16KB limit >>>> when ndata is negotiated. >>>> All this needs is "is ndata supported by this association" exposed to the >>>> app; no sdp changes needed. (One less dependency!) >>> Or, to avoid vestigal crap in the API in the end state, when you >>> install the 16K limitation, add an indicator that applications can >>> check. Once you remove the cap, remove the indicator. >>> >>> if (dataChannel.isNotVeryGood) { >>> chunkMessage(message); >>> } else { >>> dataChannel.send(message); >>> } Wait, the reason why we had it be 16K as a default was that current impls don't have the property. So datachannel.isntFixed (ok, better names can be found - but that's W3 anyways. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Mar 4 01:09:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292201A0418 for ; Tue, 4 Mar 2014 01:09:48 -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 VK8OYlP6iobJ for ; Tue, 4 Mar 2014 01:09:46 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEF61A03CD for ; Tue, 4 Mar 2014 01:09:46 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id m15so4574583wgh.4 for ; Tue, 04 Mar 2014 01:09:42 -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=1WimX6cNz7/xK2S412+p3HvVU/5zApOydiPSB7u1o+c=; b=oFoxhDAPaZ21d9If1iM3kDWX6onv6lkawU/xpUgGaeWT7huLCwaIJX8/IZ6NSTweww yzXL3qHB/QdqEHQFhKvPCVkOcD8Yhb2CzS8GjZZg/2tZX5MgC+kGxCJxs7B/hzxViyxO dNgJZGISFCOwtXlyX+vOW/HZDCaYNbbZr7OI/wRmRli6DlEkcNW30xnTJ+iITnYEcROK hdoE8CkcPmRzy7NZpZihTIUuz2b84Zt8wP10mJPILARQGihvfLp3OqLc4/sidN8GgY6H /jPa6St8jAgqUd9+BW7FME+N9F9XYeDhEDrEkDlIZGTKqSmDLuYxrGkzVb+MJ8IbPySw V2ZQ== MIME-Version: 1.0 X-Received: by 10.194.192.233 with SMTP id hj9mr13811565wjc.78.1393924176158; Tue, 04 Mar 2014 01:09:36 -0800 (PST) Received: by 10.227.10.196 with HTTP; Tue, 4 Mar 2014 01:09:36 -0800 (PST) In-Reply-To: <53159637.8050909@jesup.org> References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> <53154AA8.4000202@jesup.org> <53158103.4000809@jesup.org> <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de> <53159637.8050909@jesup.org> Date: Tue, 4 Mar 2014 09:09:36 +0000 Message-ID: From: Martin Thomson To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zbaCw05-xUJonAPAPdIV5MSIUZ8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 09:09:48 -0000 On 4 March 2014 09:00, Randell Jesup wrote: > Wait, the reason why we had it be 16K as a default was that current impls > don't have the property. So datachannel.isntFixed (ok, better names can be > found - but that's W3 anyways. Some current implementations don't have a limit either. We could spend lots of our precious cycles on fixing shit that's both broken and unchangeable. Or, we could try to design the thing that we actually want. From nobody Tue Mar 4 03:05:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C71A06CD for ; Tue, 4 Mar 2014 03:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665, SUBJ_ALL_CAPS=1.506] 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 Su7PWuuN1FQ7 for ; Tue, 4 Mar 2014 03:05:18 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 427771A069C for ; Tue, 4 Mar 2014 03:05:18 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id ZP311n00716LCl05EP5F6w; Tue, 04 Mar 2014 11:05:15 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta06.westchester.pa.mail.comcast.net with comcast id ZP341n00D2904qf3SP36gb; Tue, 04 Mar 2014 11:03:13 +0000 Message-ID: <5315B2E8.7010703@alum.mit.edu> Date: Tue, 04 Mar 2014 11:03:04 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393931115; bh=8/NacAX9ZKGlxXZ+15311kIVGGPP8u1fNArtz1qL0iY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XKk+5MDoj1+OKMevJooWVj9EVnd1FdHAV13hyESizK1cyWNls3MM8W2uU6PvP0TR4 RboMVUNQbE3d8biNoQATOvW8zJl3N+akeaLlnezFVieCgadyblQy803bIrtgS4zA92 fGxcAMo4MjkFokQKeJHBAQzdoyYFN8zbqXsJCgZsMYrG00lgAErR/AHOUtKNL2KzFp JlYDkC7lmK9NollGeByocHyIREZjl3RrzgAZJ+drvLXN66Ux+N7kZu//RGMUbgQ7On lVrN5r18jbIHUaTIF8hL/AuJE2KejfGADWJmvgpzkBqgKvL1+N41dwcU928v0fJ34c /pycVdM04t7+w== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XdNMB98J6oGns1zFNyXATSkVLuw Cc: "rtcweb@ietf.org" Subject: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 11:05:19 -0000 Ted, (I think this was open issue #8) You closed discussion on this, saying that this should be specified in some rtcweb "system" document. IIUC, then I disagree. This is important to others besides rtcweb. We want to use this mechanism, both with and without components that are implementing rtcweb. Certainly for non-browsers. This ultimately comes down to what I can expect after having negotiated (in SDP) the establishment of an SCTP association. When doing so, I use a=sctpmap to negotiate the how the association will be used. If I intend to use data channels and DCEP then I want an assurance that the other end does too. (That is the purpose of the SDP negotiation.) AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or 'a=sctp-datachannel' depending on where I look), that means the other side supports data channels *and* guarantees support for DCEP. There is no means to indicate support for data channels *without* DCEP. I don't see any urgent need to have data channels without DCEP, as long as *use* of DCEP is optional. IMO things would be less confusing if the two documents were merged into one, that defines the *Data Channel Protocol* (that runs over SCTP). This protocol runs over pairs of SCTP streams, has a small number of messages (open, ack, string-payload, binary-payload, close), and encodes them in SCTP using SCTP messages with particular payloads and SCTP stream reset. The open and ack messages would be optional. Thanks, Paul From nobody Tue Mar 4 03:08:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC891A06CD for ; Tue, 4 Mar 2014 03:08:40 -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 zwadCp95kFNJ for ; Tue, 4 Mar 2014 03:08:39 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6190F1A069C for ; Tue, 4 Mar 2014 03:08:39 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w61so4718502wes.32 for ; Tue, 04 Mar 2014 03:08:35 -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=n2kldoKqBPz1EYPlt6Mvu/6o40wCytFn9dAekODa0Gs=; b=zEEIRDgGw0dxU1lvn/c361Fc4wjZ00GiD35+PADWuAEy90ux7Q1Ka2XeMdXyyWcKW8 RWnbx+5IDlxNaTOXKtJTzjdHvg2+xft5pACltrghigOP5w3lYkcGNERN38mGKE1EYcxj 7hxh2yCrJShh268pUKZzYqFiFscYjyYK1uOGgBnxMPVm9xNtqHnISUVcOC0jks2uok5q //oduV82Wa1R61WUARoA4bJnAYAb8u/jUkASRd0QsGUPDZWPy5phk2sVahcG7HNUuTIe XnHn/OF49zGNuaRD2uKM9UniylLhBJjOjCB3Mjm5Y0//Cm78QpmpoNBaMM4cRqpTty2y MFlg== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr11269456wjc.56.1393931308702; Tue, 04 Mar 2014 03:08:28 -0800 (PST) Received: by 10.227.10.196 with HTTP; Tue, 4 Mar 2014 03:08:28 -0800 (PST) In-Reply-To: <5315B2E8.7010703@alum.mit.edu> References: <5315B2E8.7010703@alum.mit.edu> Date: Tue, 4 Mar 2014 11:08:28 +0000 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iOp1F3erb6nINpWNhE_bwksc9VA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 11:08:41 -0000 On 4 March 2014 11:03, Paul Kyzivat wrote: > > This is important to others besides rtcweb. We want to use this mechanism, > both with and without components that are implementing rtcweb. Certainly for > non-browsers. if (need(DCEP)) { addStatementToMyDoc("MUST", DCEP) } From nobody Tue Mar 4 03:17:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD401A02CE for ; Tue, 4 Mar 2014 03:17:17 -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_17=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 8RIt11i0ncOn for ; Tue, 4 Mar 2014 03:17:15 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2981A0056 for ; Tue, 4 Mar 2014 03:17:15 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id as1so6984813iec.3 for ; Tue, 04 Mar 2014 03:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u/JtYGCVbUkyn3CDKXofDZ6HQy3sgjKscHjFOHwvNZ0=; b=LibW7dWwjIJQwL/PbgnhI1xf7fYCRCtfGxn2CtHQ1H35e1r7AHE5pcwvUh48l4q6Eg nr/c83WvdHEWFnDnfpn8xIHHWqIO4+mMdIjOwUEARCOUlSKNZ3nY3HSSxxsq2C2dvZw4 Ng33sb4f2maK02dmvWM35UDm6qZ9TkVgZ5Av/r+Do8/PS8/S0KSrKC122+r1GSXhMO1C hTa6174uJKySUJnKVAuEqoEk4zf3h+mpyd5++Ng16rQnKpjx7D5jlCmu9wZfHqL97Wex nnys4iJ9aAaT0EfreE7cnyrRL104qvrazXEL/r9Dz/nC48jp0QnSjKqCNDeuzGLlDcqw lm5w== MIME-Version: 1.0 X-Received: by 10.50.137.71 with SMTP id qg7mr28005990igb.30.1393931832409; Tue, 04 Mar 2014 03:17:12 -0800 (PST) Received: by 10.42.237.206 with HTTP; Tue, 4 Mar 2014 03:17:12 -0800 (PST) In-Reply-To: <5315B2E8.7010703@alum.mit.edu> References: <5315B2E8.7010703@alum.mit.edu> Date: Tue, 4 Mar 2014 11:17:12 +0000 Message-ID: From: Ted Hardie To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c3c196b643ec04f3c60b4c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kGI1Wut3rItj_0eoxJqBdFCy6cw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 11:17:17 -0000 --001a11c3c196b643ec04f3c60b4c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat wrote: > Ted, > > (I think this was open issue #8) > > You closed discussion on this, saying that this should be specified in > some rtcweb "system" document. IIUC, then I disagree. > > This is important to others besides rtcweb. We want to use this mechanism, > both with and without components that are implementing rtcweb. Certainly > for non-browsers. > > Help me understand why it wouldn't then be in their systems documents? Ted > This ultimately comes down to what I can expect after having negotiated > (in SDP) the establishment of an SCTP association. When doing so, I use > a=sctpmap to negotiate the how the association will be used. If I intend to > use data channels and DCEP then I want an assurance that the other end does > too. (That is the purpose of the SDP negotiation.) > > AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or > 'a=sctp-datachannel' depending on where I look), that means the other side > supports data channels *and* guarantees support for DCEP. There is no means > to indicate support for data channels *without* DCEP. > > I don't see any urgent need to have data channels without DCEP, as long as > *use* of DCEP is optional. > > IMO things would be less confusing if the two documents were merged into > one, that defines the *Data Channel Protocol* (that runs over SCTP). This > protocol runs over pairs of SCTP streams, has a small number of messages > (open, ack, string-payload, binary-payload, close), and encodes them in > SCTP using SCTP messages with particular payloads and SCTP stream reset. > The open and ack messages would be optional. > > Thanks, > Paul > --001a11c3c196b643ec04f3c60b4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 4, 2014 at 11:03 AM= , Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Ted,

(I think this was open issue #8)

You closed discussion on this, saying that this should be specified in some= rtcweb "system" document. IIUC, then I disagree.

This is important to others besides rtcweb. We want to use this mechanism, = both with and without components that are implementing rtcweb. Certainly fo= r non-browsers.


Help me understand why it wouldn't then be in their sys= tems documents?

Ted


=A0
This ultimately comes down to what I can expect after having negotiated (in= SDP) the establishment of an SCTP association. When doing so, I use a=3Dsc= tpmap to negotiate the how the association will be used. If I intend to use= data channels and DCEP then I want an assurance that the other end does to= o. (That is the purpose of the SDP negotiation.)

AFAIK, current when I specify 'a=3Dsctpmap:webrtc-datachannel' (or = 'a=3Dsctp-datachannel' depending on where I look), that means the o= ther side supports data channels *and* guarantees support for DCEP. There i= s no means to indicate support for data channels *without* DCEP.

I don't see any urgent need to have data channels without DCEP, as long= as *use* of DCEP is optional.

IMO things would be less confusing if the two documents were merged into on= e, that defines the *Data Channel Protocol* (that runs over SCTP). This pro= tocol runs over pairs of SCTP streams, has a small number of messages (open= , ack, string-payload, binary-payload, close), and encodes them in SCTP usi= ng SCTP messages with particular payloads and SCTP stream reset. The open a= nd ack messages would be optional.

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

--001a11c3c196b643ec04f3c60b4c-- From nobody Tue Mar 4 03:18:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D640D1A0056 for ; Tue, 4 Mar 2014 03:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEhQ9WLmGbRM for ; Tue, 4 Mar 2014 03:17:58 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D96751A0431 for ; Tue, 4 Mar 2014 03:17:57 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s24BHrsf010201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 05:17:53 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s24BG6ss027834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 06:17:52 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 06:17:19 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Michael Tuexen Thread-Topic: [rtcweb] Open data channel issues Thread-Index: AQHPNvTjdPPAuXGnm0CBoOmgEn8ul5rP+SYA///UOvCAAH0dAIAAd/Dw Date: Tue, 4 Mar 2014 11:17:19 +0000 Message-ID: References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> <7387F0E6-2DE0-4372-8559-B9DE9B9F365F@lurchi.franken.de> In-Reply-To: <7387F0E6-2DE0-4372-8559-B9DE9B9F365F@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BR1qe0LM8CCJrqScOTVh70Fjhe4 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 11:18:01 -0000 Please see inline comments. > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Monday, March 03, 2014 4:46 PM > To: Makaraju, Maridi Raju (Raju) > Cc: Justin Uberti; Randell Jesup; rtcweb@ietf.org > Subject: Re: [rtcweb] Open data channel issues >=20 > On 03 Mar 2014, at 22:19, Makaraju, Maridi Raju (Raju) > wrote: >=20 > > Sorry to jump in from middle of nowhere in this interesting conversatio= n. > I couldn't resist providing this feedback and I hope it is useful. > > > > First, on "EOR solving monopolization issue": > > I could be wrong, but I am not sure how EOR based approach avoids SCTP > link monopolization?! Per my understanding EOR is a local send () utility > rather than receive side utility and it is implemented on top of base SCT= P > RFC (so no indication of special EOR in SCTP headers other than base SCTP > RFC B/E fragment indication bits). Once a send () with EOR set to false i= s > called, on a stream id, the SCTP link is monopolized until send () on sam= e > stream id with EOR set to true is called; so same limitation exist. EOR > allows sending side to start sending chunks without waiting for complete > data. EOR has no impact on receiving side, the SCTP stack waits for last > chunk (which is the result of sending side setting EOR=3Dtrue) and delive= rs > entire message to app. > You are right, if you consider RFC 4960. But using > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 > overcomes this limitation. You can have on each stream a message being se= nt > in explicit EOR mode. > Using an interleaving scheduler, they get interleaved on the wire. So you > need the NDATA extension... [Raju]=20 Thanks for clarifying. Earlier it wasn't clear to me as EOR was referred to= be EOR+NDATA. I was reading EOR as just EOR support without NDATA. Yes, NDATA support is a must to avoid monopolization. [/Raju] > > > > New PC approach: > > If an application is sensitive to SCTP link monopolisation then there i= s > another option it can consider - use of separate new PeerConnection (PC) = for > the data channel(s) which may monopolize the link. > > Depending on how an application is designed, using a new PC could be > simpler than having an application level chunking protocol (fragmentation > and reassembly). If app needs such "heavy" data channel infrequently the= n > it can create new PC as needed; if it is needed frequently then a dedicat= ed > PC can be allocated and keep it open all the time. > > > > One disadvantage with application level chunking protocol is both the > peers need to use it; so it may not work between clients of different typ= es > or same clients with different versions. New PC based approach obviously > does not have this issue as no chunking is involved. > > > > At first, new PC approach may appear heavy weight wrt # of PCs in use > (which I don't think an issue on browsers), ICE overhead for new PC etc. = But > in comparision to application level chunking new PC approach may not be t= hat > bad. > I think the large message support with NDATA is sufficient to do whatever > RTCWeb wants... [Raju]=20 Yes, I agree that NDATA is the final solution. But in the interim, applicat= ion chunking per 16K size requires some chunking protocol at app. Do we know the timeframe for NDATA support from browsers? Until NDATA is available, to avoid monopolization one can use new PC as an = alternative to application level chunking (which also require some kind of = flow/congestion control). Appreictae any comments on this approach. [/Raju] Best Regards Raju From nobody Tue Mar 4 03:31:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8C21A063D for ; Tue, 4 Mar 2014 03:31:54 -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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6Gg_dIKI3CY for ; Tue, 4 Mar 2014 03:31:53 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 683791A0431 for ; Tue, 4 Mar 2014 03:31:53 -0800 (PST) Received: from dhcp-a508.meeting.ietf.org (unknown [31.133.165.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C434522E1F4 for ; Tue, 4 Mar 2014 06:31:49 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 4 Mar 2014 11:32:50 +0000 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cryWO14PD1P4aZEQWRMQPKOfyIc Subject: [rtcweb] Notes from Data discussion today 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, 04 Mar 2014 11:31:55 -0000 Data Presentation Issue #1=20 - Will say MUST use NDATA and ignore intermediate states till we have = that - Will keep the signaling of receiver seize limits Issue #2 - add general statement on congestion control and specific for TCP = windows based congestion control=20 Issue #3 - say nothing about this in our specification and leave it to the SCTP = specifications - will propose the path max retrain =3D association max retrans in TSVWG - no text involving this in rtcweb specs=20 Issue #4=20 - will remove negation and discussion of this. It is a point for the WG = developing SCTP. - Ted to send text on how to craft such a statement=20 Issue #5=20 - part of the issue here is there is a protocol on top of SCTP=20 - change to text say =93reset channel=94 Issue #6 - will use the the "IANA registry for WebSocket Subprotocol names " Issue #7=20 - skipped due to time=20 Issue #8 - The transports documents should make the DCEP be MTI=20 - The data channel draft will not require implementation of DCEP Issue #9=20 - this is an example of something you can do with tool set we provide = and may or may not be a bad idea=20 - do nothing for now and be sad later=20 From nobody Tue Mar 4 03:40:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78D61A0431 for ; Tue, 4 Mar 2014 03:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlylqIbK5MAW for ; Tue, 4 Mar 2014 03:39:58 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DAAB61A02CE for ; Tue, 4 Mar 2014 03:39:57 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s24BdsIA010357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 05:39:54 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s24BdrQR031418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 06:39:53 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 06:39:53 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Open data channel issues Thread-Index: AQHPN1stdPPAuXGnm0CBoOmgEn8ul5rQ0+gAgAAIWoCAAAcMgIAAEjqA///SoEA= Date: Tue, 4 Mar 2014 11:39:53 +0000 Message-ID: References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <5313EC0D.9030808@jesup.org> <53146B2C.8080008@jesup.org> <53149F0C.6070001@jesup.org> <53154AA8.4000202@jesup.org> <53158103.4000809@jesup.org> <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de> <53159637.8050909@jesup.org> In-Reply-To: <53159637.8050909@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p28-QWmU2QH39qpnCqjdHCyQfrM Subject: Re: [rtcweb] Open data channel issues 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, 04 Mar 2014 11:39:59 -0000 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup > Sent: Tuesday, March 04, 2014 3:01 AM > On 3/4/2014 2:55 AM, Michael Tuexen wrote: > > On 04 Mar 2014, at 07:30, Randell Jesup wrote: > > > >> On 3/4/2014 2:00 AM, Martin Thomson wrote: > >>> On 4 March 2014 03:38, Randell Jesup wrote: > >>>> To take your suggestion: > >>>> a) applications assume 16KB if ndata wasn't negotiated (per the curr= ent > >>>> suggestion) > >>>> b) implement ndata and EOR support in the browsers, and drop the 16K= B > limit > >>>> when ndata is negotiated. > >>>> All this needs is "is ndata supported by this association" exposed t= o > the > >>>> app; no sdp changes needed. (One less dependency!) > >>> Or, to avoid vestigal crap in the API in the end state, when you > >>> install the 16K limitation, add an indicator that applications can > >>> check. Once you remove the cap, remove the indicator. > >>> > >>> if (dataChannel.isNotVeryGood) { > >>> chunkMessage(message); > >>> } else { > >>> dataChannel.send(message); > >>> } >=20 >=20 > Wait, the reason why we had it be 16K as a default was that current > impls don't have the property. So datachannel.isntFixed (ok, better > names can be found - but that's W3 anyways. [Raju]=20 NDATA requires support from both the ends. Is browser going to update datac= hannel.isntFixed/ndata after SCTP is up? Per my reading of PeerConnection o= nopen() won't be called before SCTP is up (however may be called before DCE= P, if used, is done). So, app knows NDATA support before sending first mess= age. Thanks Raju From nobody Tue Mar 4 04:08:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5A21A0644 for ; Tue, 4 Mar 2014 04:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ihSSXwxHhyV for ; Tue, 4 Mar 2014 04:08:24 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 379031A0758 for ; Tue, 4 Mar 2014 04:08:24 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s24C8Ijj019416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 06:08:19 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s24C8GO9031321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 07:08:18 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 07:08:18 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Ted Hardie , Paul Kyzivat Thread-Topic: [rtcweb] *MUST* DCEP? Thread-Index: AQHPN5mmFhBjN/7IlE2x2iXE8FJgd5rRGzIA//+4iTA= Date: Tue, 4 Mar 2014 12:08:18 +0000 Message-ID: References: <5315B2E8.7010703@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826E0069CBUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qXa6C_UIIeYLbF6KyiZI9vLuQfc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 12:08:27 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826E0069CBUS70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While a=3Dsctpmap assumes use of DCEP, indication of external negotiation (= instead of DCEP) also requires subprotocol and it's parameters to be convey= ed. This has to be done per data channel stream. Are you looking at more than what is documented in [I-D.ejzak-mmusic-data-c= hannel-sdpneg]? Or are you looking for an indication of this (for all streams) directly in = a=3Dsctpmap? How about item 3 of the following proposal? http://www.ietf.org/mail-archive/web/mmusic/current/msg13155.html -Raju From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, March 04, 2014 5:17 AM To: Paul Kyzivat Cc: rtcweb@ietf.org Subject: Re: [rtcweb] *MUST* DCEP? On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat > wrote: Ted, (I think this was open issue #8) You closed discussion on this, saying that this should be specified in some= rtcweb "system" document. IIUC, then I disagree. This is important to others besides rtcweb. We want to use this mechanism, = both with and without components that are implementing rtcweb. Certainly fo= r non-browsers. Help me understand why it wouldn't then be in their systems documents? Ted This ultimately comes down to what I can expect after having negotiated (in= SDP) the establishment of an SCTP association. When doing so, I use a=3Dsc= tpmap to negotiate the how the association will be used. If I intend to use= data channels and DCEP then I want an assurance that the other end does to= o. (That is the purpose of the SDP negotiation.) AFAIK, current when I specify 'a=3Dsctpmap:webrtc-datachannel' (or 'a=3Dsct= p-datachannel' depending on where I look), that means the other side suppor= ts data channels *and* guarantees support for DCEP. There is no means to in= dicate support for data channels *without* DCEP. I don't see any urgent need to have data channels without DCEP, as long as = *use* of DCEP is optional. IMO things would be less confusing if the two documents were merged into on= e, that defines the *Data Channel Protocol* (that runs over SCTP). This pro= tocol runs over pairs of SCTP streams, has a small number of messages (open= , ack, string-payload, binary-payload, close), and encodes them in SCTP usi= ng SCTP messages with particular payloads and SCTP stream reset. The open a= nd ack messages would be optional. Thanks, Paul --_000_E1FE4C082A89A246A11D7F32A95A17826E0069CBUS70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While a=3Dsctpmap assumes= use of DCEP, indication of external negotiation (instead of DCEP) also req= uires subprotocol and it’s parameters to be conveyed. This has to be done per data channel stream.

Are you looking at more t= han what is documented in [I-D.ejzak-mmusic-data-channel-sdpneg]?

Or are you looking for an= indication of this (for all streams) directly in a=3Dsctpmap?

 <= /p>

How about item 3 of the f= ollowing proposal?

http://www.ietf.org/ma= il-archive/web/mmusic/current/msg13155.html

 <= /p>

-Raju

 <= /p>

 <= /p>

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, March 04, 2014 5:17 AM
To: Paul Kyzivat
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] *MUST* DCEP?

 

On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

Ted,

(I think this was open issue #8)

You closed discussion on this, saying that this should be specified in some= rtcweb "system" document. IIUC, then I disagree.

This is important to others besides rtcweb. We want to use this mechanism, = both with and without components that are implementing rtcweb. Certainly fo= r non-browsers.

 

Help me understand why it wouldn't then be in their systems d= ocuments?

Ted



 

This ultimately comes down to what I can expect afte= r having negotiated (in SDP) the establishment of an SCTP association. When= doing so, I use a=3Dsctpmap to negotiate the how the association will be u= sed. If I intend to use data channels and DCEP then I want an assurance that the other end does too. (That is th= e purpose of the SDP negotiation.)

AFAIK, current when I specify 'a=3Dsctpmap:webrtc-datachannel' (or 'a=3Dsct= p-datachannel' depending on where I look), that means the other side suppor= ts data channels *and* guarantees support for DCEP. There is no means to in= dicate support for data channels *without* DCEP.

I don't see any urgent need to have data channels without DCEP, as long as = *use* of DCEP is optional.

IMO things would be less confusing if the two documents were merged into on= e, that defines the *Data Channel Protocol* (that runs over SCTP). This pro= tocol runs over pairs of SCTP streams, has a small number of messages (open= , ack, string-payload, binary-payload, close), and encodes them in SCTP using SCTP messages with particular paylo= ads and SCTP stream reset. The open and ack messages would be optional.

        Thanks,
        Paul

 

--_000_E1FE4C082A89A246A11D7F32A95A17826E0069CBUS70UWXCHMBA02z_-- From nobody Tue Mar 4 06:53:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C9C1A0167 for ; Tue, 4 Mar 2014 06:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9zfCaqZf-2B for ; Tue, 4 Mar 2014 06:53:10 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 595241A00B9 for ; Tue, 4 Mar 2014 06:53:10 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id ZQ6X1n0031ap0As5ASt7oe; Tue, 04 Mar 2014 14:53:07 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta22.westchester.pa.mail.comcast.net with comcast id ZSqv1n01P2904qf3iSqye8; Tue, 04 Mar 2014 14:51:05 +0000 Message-ID: <5315E850.5070700@alum.mit.edu> Date: Tue, 04 Mar 2014 14:50:56 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ted Hardie References: <5315B2E8.7010703@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393944787; bh=qUWSdVc9y0M3JqteLQqX4I6Fi7GPx1PO/jNufBK7GA8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pEx6HoK5eNzXvX+D7bDsnuk0q+ogmNcNJTL0dwp7ddq29VIr6rarGAishPWt20Xrn 6tj4Tmn9e86voqmLSEo3KifikAcS+4FWdT7WohKKd3yws2bMP6jjkdihzIWkYevPcJ fIm55mh9sNU/Zedfj2hnk48QkbP0A7exVKaHkgVUf9vu3ZSt2v/tJg66lMrljyeGge m6ZVuznmoQiabZVZ+ORi/gSwDxFRaj2R2nHwMAvazUxvSQKr1XgHh0uji1phHbXtGh Zi8ZZlz7X/I2XYv7I2BUMCU2J8M3+2jqJw6UadEpUBvUFxTX0KiuUvlNxR970rCoUH Q8iOJZ1yYG+oQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vs1Rz9b3SwxTsawLD1UAGCg4Ajw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 14:53:11 -0000 IIUC rtcweb is predicated on the assumption that there is a single entity orchestrating the "system" including both of the endpoints of the sctp association. You therefore assume that you can a priori assume that both ends conform to your "systems document". A sip endpoint doesn't have that. A major purpose of the signaling and the O/A exchange is to find out what we agree to. We won't know in advance if the other endpoint follows the CLUE "systems document". ISTM that you are defining things so that we must use some mechanism to negotiate an application-specific agreement between the two ends about use of data channels *before* using any data channels. With the ejzak draft we can use the O/A to negotiate a specific clue subprotocol, and then have a reasonable expectation that we can follow our own documentation of that protocol to go on. Using DCEP would be more straightforward, especially for browser based endpoints. But if we can't even depend on support of DCEP when we have a data channel SCTP association, then DCEP is less useful. Thanks, Paul On 3/4/14 11:17 AM, Ted Hardie wrote: > On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat > wrote: > > Ted, > > (I think this was open issue #8) > > You closed discussion on this, saying that this should be specified > in some rtcweb "system" document. IIUC, then I disagree. > > This is important to others besides rtcweb. We want to use this > mechanism, both with and without components that are implementing > rtcweb. Certainly for non-browsers. > > > Help me understand why it wouldn't then be in their systems documents? > > Ted > > > This ultimately comes down to what I can expect after having > negotiated (in SDP) the establishment of an SCTP association. When > doing so, I use a=sctpmap to negotiate the how the association will > be used. If I intend to use data channels and DCEP then I want an > assurance that the other end does too. (That is the purpose of the > SDP negotiation.) > > AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or > 'a=sctp-datachannel' depending on where I look), that means the > other side supports data channels *and* guarantees support for DCEP. > There is no means to indicate support for data channels *without* DCEP. > > I don't see any urgent need to have data channels without DCEP, as > long as *use* of DCEP is optional. > > IMO things would be less confusing if the two documents were merged > into one, that defines the *Data Channel Protocol* (that runs over > SCTP). This protocol runs over pairs of SCTP streams, has a small > number of messages (open, ack, string-payload, binary-payload, > close), and encodes them in SCTP using SCTP messages with particular > payloads and SCTP stream reset. The open and ack messages would be > optional. > > Thanks, > Paul > > From nobody Tue Mar 4 07:00:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145771A017B for ; Tue, 4 Mar 2014 07:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6jyA_YjZyy4 for ; Tue, 4 Mar 2014 07:00:49 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5551A00F1 for ; Tue, 4 Mar 2014 07:00:49 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id ZRVr1n00427AodY5CT0m0t; Tue, 04 Mar 2014 15:00:46 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta19.westchester.pa.mail.comcast.net with comcast id ZSyZ1n00A2904qf3fSybQH; Tue, 04 Mar 2014 14:58:44 +0000 Message-ID: <5315EA19.90401@alum.mit.edu> Date: Tue, 04 Mar 2014 14:58:33 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Ted Hardie References: <5315B2E8.7010703@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393945246; bh=A0QlVw6glIfMvbHbNtU2YkIie7DChjJbxrG8sWWPv2o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NYbhazXg78lpMvEChEafbvV+nc0N0jOY3ZwnvuLivCHqmPgGCpPfjbBgUo1zW9as5 B0CvsLfc9SYMf23/gycQ3NbD2omGI6GZvDOOhlo4k8yIxGpsJQuMRRkeUbcFzAA950 qIL4WKPldNaOB1fvobyf0oS+nFuRINV8X/f5w7U1QwSQq/Ta9bM+Pehhr+hDWpKfma KyQDkew9emX8dnLn5tdBNW3OpTWkUp8ix+h+NNeq/wDh66EljsBJISmHl6vp6pvade 16iD0JnZJ7FyVFoWmM0YuM8kTu5J1oMwlujwlGwjGbwf+d3A6Kl3Ts0IILqzakO9zp +0WJTkELt2SYw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rqBtxjHV51JcPn-c__L35is-gpQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 15:00:51 -0000 On 3/4/14 12:08 PM, Makaraju, Maridi Raju (Raju) wrote: > While a=sctpmap assumes use of DCEP, indication of external negotiation > (instead of DCEP) also requires subprotocol and it’s parameters to be > conveyed. This has to be done per data channel stream. > > Are you looking at more than what is documented in > [I-D.ejzak-mmusic-data-channel-sdpneg]? > > Or are you looking for an indication of this (for all streams) directly > in a=sctpmap? I'm ok as things currently stand, though the documents are confusing. The 'a=sctpmap:nnn websocket-datachannel' means that DCEP is supported. My concern was a proposal I think I heard that would make support for DCEP to be optional. In that case, IMO it is important that the O/A exchange establish whether DCEP is supported or not. Thanks, Paul > How about item 3 of the following proposal? > > http://www.ietf.org/mail-archive/web/mmusic/current/msg13155.html > > -Raju > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* Tuesday, March 04, 2014 5:17 AM > *To:* Paul Kyzivat > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] *MUST* DCEP? > > On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat > wrote: > > Ted, > > (I think this was open issue #8) > > You closed discussion on this, saying that this should be specified > in some rtcweb "system" document. IIUC, then I disagree. > > This is important to others besides rtcweb. We want to use this > mechanism, both with and without components that are implementing > rtcweb. Certainly for non-browsers. > > Help me understand why it wouldn't then be in their systems documents? > > Ted > > > > This ultimately comes down to what I can expect after having > negotiated (in SDP) the establishment of an SCTP association. When > doing so, I use a=sctpmap to negotiate the how the association will > be used. If I intend to use data channels and DCEP then I want an > assurance that the other end does too. (That is the purpose of the > SDP negotiation.) > > AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or > 'a=sctp-datachannel' depending on where I look), that means the > other side supports data channels *and* guarantees support for DCEP. > There is no means to indicate support for data channels *without* DCEP. > > I don't see any urgent need to have data channels without DCEP, as > long as *use* of DCEP is optional. > > IMO things would be less confusing if the two documents were merged > into one, that defines the *Data Channel Protocol* (that runs over > SCTP). This protocol runs over pairs of SCTP streams, has a small > number of messages (open, ack, string-payload, binary-payload, > close), and encodes them in SCTP using SCTP messages with particular > payloads and SCTP stream reset. The open and ack messages would be > optional. > > Thanks, > Paul > From nobody Tue Mar 4 07:40:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E81A01F9 for ; Tue, 4 Mar 2014 07:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPsxqL_zZOmu for ; Tue, 4 Mar 2014 07:40:24 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B46F91A005E for ; Tue, 4 Mar 2014 07:40:24 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s24FeHbU005736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 09:40:17 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s24FeEIw027433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 10:40:16 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 10:39:54 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , Ted Hardie Thread-Topic: [rtcweb] *MUST* DCEP? Thread-Index: AQHPN5mmFhBjN/7IlE2x2iXE8FJgd5rRGzIA//+4iTCAAIVPgP//tvcg Date: Tue, 4 Mar 2014 15:39:54 +0000 Message-ID: References: <5315B2E8.7010703@alum.mit.edu> <5315EA19.90401@alum.mit.edu> In-Reply-To: <5315EA19.90401@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XBQlCLYRdHw2dTM_xx_4Ft0mSw4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 15:40:27 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, March 04, 2014 8:59 AM > On 3/4/14 12:08 PM, Makaraju, Maridi Raju (Raju) wrote: > > While a=3Dsctpmap assumes use of DCEP, indication of external negotiati= on > > (instead of DCEP) also requires subprotocol and it's parameters to be > > conveyed. This has to be done per data channel stream. > > > > Are you looking at more than what is documented in > > [I-D.ejzak-mmusic-data-channel-sdpneg]? > > > > Or are you looking for an indication of this (for all streams) directly > > in a=3Dsctpmap? >=20 > I'm ok as things currently stand, though the documents are confusing. > The 'a=3Dsctpmap:nnn websocket-datachannel' means that DCEP is supported. >=20 > My concern was a proposal I think I heard that would make support for > DCEP to be optional. In that case, IMO it is important that the O/A > exchange establish whether DCEP is supported or not. [Raju] That's the reason why I proposed to add 'protocol' parameter to a=3Ddcmap. Having this parameter at a=3Dsctmap level may not make that much sense due = to: sctpmap is for entire association and protocol defaults to DCEP. To make us= e of external negotiation, which is per data channel stream, one would need= additional a=3D line(s) (e.g. ejzak's draft) to convey subprotocol info. I= MO adding data channel protocol option to a=3Ddcamp, which is per subprotoc= ol, makes sense. [/Raju]=20 Best Regards Raju From nobody Tue Mar 4 07:47:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7156D1A00F5 for ; Tue, 4 Mar 2014 07:47:12 -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 YxZpCwQFNeSd for ; Tue, 4 Mar 2014 07:47:11 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 554131A0179 for ; Tue, 4 Mar 2014 07:47:11 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id ZSsk1n0071ei1Bg53Tn80Y; Tue, 04 Mar 2014 15:47:08 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta24.westchester.pa.mail.comcast.net with comcast id ZTkz1n0192904qf3kTl2kH; Tue, 04 Mar 2014 15:45:06 +0000 Message-ID: <5315F4FB.4000908@alum.mit.edu> Date: Tue, 04 Mar 2014 15:44:59 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393948028; bh=LjgvuYZGas6qtbz3Z1T/snVMu8uS3XyqM3KadG84a24=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R2Z4f6iGTC9SdYH3MLwZmDiwobYNXQ7ZcbHujVaIv32XxgBF1J+wemWm1bX0MbhCX 8Dx+t6SSC7zfcHawNFoPGbSPc+5UxCzgWdYTWUxyORUKJI8krxNSs1tL4SXtm/uuTe PpKHb3+Y9NNZpCv4juei4sOn9hcsUDeOiPkSofFgEr6pHyPSEfIIR8+6iSyMbeXhxF tREwjGpxtxQXt2WiKNQxGo8PaeDQnJwbojviX4P8JGcfYFdHk0rFbVYEuNqoouzZBp yjc+G7G43Li1+SfxLshLJPopR7WMtI9/pgObNfIBlc/tLyAZbHsKG2gpbtg8KpnQwg ogPSZYWFIGBHw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wYpfs_tXeyRta3oVJDVc0F60FSg Subject: Re: [rtcweb] Notes from Data discussion today - reset channel? 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, 04 Mar 2014 15:47:12 -0000 On 3/4/14 11:32 AM, Cullen Jennings wrote: > Issue #5 > - part of the issue here is there is a protocol on top of SCTP > - change to text say “reset channel” I understand what an SCTP stream reset is. I can guess what "reset channel" means, but AFAIK it isn't defined anywhere. I guess it may mean sending an Outgoing SSN Reset Request, or an Incoming SSN Reset Request, or both. (If there was a notion of a Data Channel Protocol, then it could have a channel reset request, that mapped to the appropriate corresponding SCTP actions.) Thanks, Paul From nobody Tue Mar 4 07:50:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A8A1A0117 for ; Tue, 4 Mar 2014 07:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_e0oxuqfrj0 for ; Tue, 4 Mar 2014 07:50:27 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 3191A1A00F5 for ; Tue, 4 Mar 2014 07:50:27 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 284A41C0E97FE; Tue, 4 Mar 2014 16:50:23 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5315F4FB.4000908@alum.mit.edu> Date: Tue, 4 Mar 2014 15:50:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5315F4FB.4000908@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RFLi1DXCSx9Uxn4MBdbpDUsmNts Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Notes from Data discussion today - reset channel? 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, 04 Mar 2014 15:50:29 -0000 On 04 Mar 2014, at 15:44, Paul Kyzivat wrote: > On 3/4/14 11:32 AM, Cullen Jennings wrote: >=20 >> Issue #5 >> - part of the issue here is there is a protocol on top of SCTP >> - change to text say =93reset channel=94 >=20 > I understand what an SCTP stream reset is. >=20 > I can guess what "reset channel" means, but AFAIK it isn't defined = anywhere. More precise language: Close the channel. This is described in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.7 Best regards Michael >=20 > I guess it may mean sending an Outgoing SSN Reset Request, or an = Incoming SSN Reset Request, or both. >=20 > (If there was a notion of a Data Channel Protocol, then it could have = a channel reset request, that mapped to the appropriate corresponding = SCTP actions.) >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Mar 4 07:58:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAA51A0117 for ; Tue, 4 Mar 2014 07:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgXMqEDN3wJj for ; Tue, 4 Mar 2014 07:58:17 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 506911A0141 for ; Tue, 4 Mar 2014 07:58:17 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id ZQ4h1n0020mv7h055TyEkc; Tue, 04 Mar 2014 15:58:14 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta11.westchester.pa.mail.comcast.net with comcast id ZTw51n00s2904qf3XTw8Cb; Tue, 04 Mar 2014 15:56:12 +0000 Message-ID: <5315F795.7090304@alum.mit.edu> Date: Tue, 04 Mar 2014 15:56:05 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: 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=q20121106; t=1393948694; bh=8KLyW7oHHNiiCBFysysRxQ9pKqtOhvfhNjDL3pXKMKA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=smkSykVXV8ZByjNT/eGFSl5pjmev+M+d0fOmbSXYN1d5BkBXYGOwvYwYgredC7iY7 niigbZHtrQmDXiHnVfZv+Tb1FT13hzUJZ9wugLHil8t06CPHMV8IS+7ZE5YQPtne6D GMYanFtUv2z25PJ/9VDr8DRY/ERx7C5aqKsar7C3X1+GBfq03M8VtQTKv+cR2oTzm5 E+WXuaJYQngoL2cS8Ne4oD8nSnKSCYJAXnC82Cru4OtHH8mUEHmu26a/DVtvkqPMGt oaWNWNhK1f98iyQ1yh0ZEUfb1UGxBtPpLPBKdry8v0xH1WtpYrzXtNMRCcgXeLzas4 B8yD9JeeFX0NA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9Jep3wE3N7l_7yvF2PuThBxbtkU Subject: Re: [rtcweb] Notes from Data discussion today - DCEP MTI? 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, 04 Mar 2014 15:58:18 -0000 On 3/4/14 11:32 AM, Cullen Jennings wrote: > Issue #8 > - The transports documents should make the DCEP be MTI > - The data channel draft will not require implementation of DCEP It isn't hugely important to me which document the MTI is in. (I do care for clarity, but not as far as substance.) What *is* important to me is what the definition of "webrtc-datachannel" is, in the registry defined by draft-ietf-mmusic-sctp-sdp-06. (I can't find anything that does the definition.) If it says DCEP is MTI then I'm ok. If it doesn't then I think there is a problem. Thanks, Paul From nobody Tue Mar 4 08:19:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2F71A023E for ; Tue, 4 Mar 2014 08:19:54 -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 f-06yNTW75i7 for ; Tue, 4 Mar 2014 08:19:53 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 493D21A024E for ; Tue, 4 Mar 2014 08:19:53 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ZTGK1n0030cZkys5BUKqa3; Tue, 04 Mar 2014 16:19:50 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta10.westchester.pa.mail.comcast.net with comcast id ZUHf1n00V2904qf3WUHhDh; Tue, 04 Mar 2014 16:17:48 +0000 Message-ID: <5315FCA2.8010802@alum.mit.edu> Date: Tue, 04 Mar 2014 16:17:38 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Tuexen References: <5315F4FB.4000908@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393949990; bh=Kmrj+LRPPR1QO7F0G70LNtPPVgiqCuUNcqHrlqHw2Ik=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=q6rp9JVmJd199z/KwdWWvUexULMyrw3FPhLXDXLNmTFj0bQBoONVHs/NXrraH68sd DIcNpfNUWwYSxF2lGXM2A9GBuPu71Tp6qaHf2LFnEAkRxeHmdHgihspll7Lob2x+0h 6piQGjgKod2smoWrdMAvxClc/njCG5yHmaOyMye7loHI1WIb3wJ2Q9RiChGIaksK+6 oyVXfb27MG8cYeHwXJ5oIoG1UEEZcf1yIMFOj0FzuJlAa9lfKSm73afOKMyS3NIFay Rr1sIbcEFA+v8bCkIs+qGRMJKU6sICRKFki7Aot379kkbzhbLdRuABL6zI2oOGAlLR QzBtMD0N3ZEAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z68mNiXvcr229mbBdOddzXVOpLM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Notes from Data discussion today - reset channel? 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, 04 Mar 2014 16:19:55 -0000 On 3/4/14 3:50 PM, Michael Tuexen wrote: > On 04 Mar 2014, at 15:44, Paul Kyzivat wrote: > >> On 3/4/14 11:32 AM, Cullen Jennings wrote: >> >>> Issue #5 >>> - part of the issue here is there is a protocol on top of SCTP >>> - change to text say “reset channel” >> >> I understand what an SCTP stream reset is. >> >> I can guess what "reset channel" means, but AFAIK it isn't defined anywhere. > More precise language: Close the channel. This is described in > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.7 > > Best regards > Michael OK. Close enough I guess. (Close - Reset) Sorry, Paul From nobody Tue Mar 4 08:38:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7436D1A017D for ; Tue, 4 Mar 2014 08:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9vvLCFG8img for ; Tue, 4 Mar 2014 08:38:51 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 57E601A0154 for ; Tue, 4 Mar 2014 08:38:51 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id ZQvq1n0040Fqzac5DUeoWE; Tue, 04 Mar 2014 16:38:48 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta08.westchester.pa.mail.comcast.net with comcast id ZUcb1n00A2904qf3UUcdJi; Tue, 04 Mar 2014 16:36:46 +0000 Message-ID: <53160112.3080702@alum.mit.edu> Date: Tue, 04 Mar 2014 16:36:34 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Ted Hardie References: <5315B2E8.7010703@alum.mit.edu> <5315EA19.90401@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393951128; bh=hMRCjkht14bDQ+By1jKdxToayKc33I6B+Uh6vgQt9mM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ci0PC6ru2D/ImJOAgy44JUq2D9ocdyhnUC21qGEVNumSGKxcOdMegmunyMIiMIeiy XqC+7x6RlfdPG2R/MltDz9hHAPeMCkVD/ePYA3EOE0BPlot7BTu0Ivg61vvieQqIbm 4sq4k19mbsAGm+LKDzejeiu6jE5RniFLWzdLdxnAfbn064ehlOysLJdOTjUpLH2uKX AIpJdM5NhKQLeVCZgzvSaHsyW8zyYY/NpT9gxtk3gSxuth96UkviBy5cqg+WY9dwNT j1FSDu2zEjwdiwAKKDZEzoaFFexg30MymLut/nXrl07XAOSNd5rgYpgVqV5geQqJtG WMuwHy0obCXLA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VyjmFsDzJf4xEr0qAPWzzZ193HY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 16:38:52 -0000 On 3/4/14 3:39 PM, Makaraju, Maridi Raju (Raju) wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, March 04, 2014 8:59 AM >> On 3/4/14 12:08 PM, Makaraju, Maridi Raju (Raju) wrote: >>> While a=sctpmap assumes use of DCEP, indication of external negotiation >>> (instead of DCEP) also requires subprotocol and it's parameters to be >>> conveyed. This has to be done per data channel stream. >>> >>> Are you looking at more than what is documented in >>> [I-D.ejzak-mmusic-data-channel-sdpneg]? >>> >>> Or are you looking for an indication of this (for all streams) directly >>> in a=sctpmap? >> >> I'm ok as things currently stand, though the documents are confusing. >> The 'a=sctpmap:nnn websocket-datachannel' means that DCEP is supported. >> >> My concern was a proposal I think I heard that would make support for >> DCEP to be optional. In that case, IMO it is important that the O/A >> exchange establish whether DCEP is supported or not. > > [Raju] > That's the reason why I proposed to add 'protocol' parameter to a=dcmap. > Having this parameter at a=sctmap level may not make that much sense due to: > sctpmap is for entire association and protocol defaults to DCEP. To make use of external negotiation, which is per data channel stream, one would need additional a= line(s) (e.g. ejzak's draft) to convey subprotocol info. IMO adding data channel protocol option to a=dcamp, which is per subprotocol, makes sense. > [/Raju] I have no problem with a=dcmap. It is the 'app' parameter of the sctpmap attribute that I am talking about. If I want to use DCEP, the dcmap attribute is irrelevant to me. What is it that tells me that DCEP is supported. The only datum available that could imply that is the 'app' parameter of sctpmap. Right now, if app is webrtc-datachannel, that implies DCEP is MTI. That serves the purpose. But as of today there was a suggestion that you could have cases where there is an SCTP association that supports Data Channels, but not DCEP. I don't know how the two would be distinguishable. Possibly by a different 'app' value. A related question is what is the applicability of a=dcmap. Surely it doesn't apply for all uses of SCTP - those that don't use data channels at all. Do you propose to couple this to particular 'app' values? Or is support for this negotiated independently of a=sctpmap? Thanks, Paul From nobody Tue Mar 4 09:39:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6315D1A01D9 for ; Tue, 4 Mar 2014 09:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 LNVtiN8mTYa0 for ; Tue, 4 Mar 2014 09:39:15 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE0E1A021C for ; Tue, 4 Mar 2014 09:39:13 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-a3-53160fbda38d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 20.3D.04853.DBF06135; Tue, 4 Mar 2014 18:39:09 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.347.0; Tue, 4 Mar 2014 18:39:08 +0100 Message-ID: <53160FBB.4070401@ericsson.com> Date: Tue, 4 Mar 2014 17:39:07 +0000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Tuexen References: <530B740E.4090707@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvje5efrFgg84GeYvVh/eyWVxsWsJo sfZfO7sDs8eSJT+ZPDa07GDy+HL5M1sAcxSXTUpqTmZZapG+XQJXxtHjG1kKnntUnH/o0MD4 07KLkYNDQsBEov+0RhcjJ5ApJnHh3nq2LkYuDiGBE4wSb3a1sUI4yxglDnb9ZAGp4hXQlvj4 pZ8JxGYRUJG4Nr+RGcRmE7CQuPmjkQ3EFhUIlth54DcjRL2gxMmZT8B6RQRMJQ4unwdmMwtE S3TcvAnWKyzgLbFsRStYr5BAisT0aZfAejkFXCVabzSyQxwqLtHTGATRqicx5WoLI4QtL9G8 dTYzRKu2RENTB+sERqFZSDbPQtIyC0nLAkbmVYySxanFxbnpRgZ6uem5JXqpRZnJxcX5eXrF qZsYgeF9cMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx ypYnS/2N5kXOXTIzZE/l//UG5gUMyQoen69MfsSy9bVlYfYjAdYJ7Ar6S67LTOTefKs1Quf8 nln/NrvPtlM+2R/FLNG1ep+IsW8W+5ws39hzk1nulzIo22uyO876qMV+oez3Q4cbqhPe98eI udj6LHkgfo45M1kksPb24bnGwhd9rrtvX6eqxFKckWioxVxUnAgADnjhoz0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9BQ1yz0dq1DyigRYyriVN5Nz72g Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 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, 04 Mar 2014 17:39:17 -0000 On 2014-02-25 17:07, Michael Tuexen wrote: > > On Feb 24, 2014, at 5:32 PM, Magnus Westerlund wrote: > >> Hi, >> (as individual) > Hi Magnus, > > thank you very much for the detailed review. Please see my comments in-line. > > Best regards > Michael >> >> I have reviewed the WebRTC Data Channel Establishment protocol >> (draft-ietf-rtcweb-data-protocol-03) and have some comments: >> >> 1. Section 4: >> Shouldn't this section discuss the priority field? > I added in the list of consistent properties: > > the priority of the data Channel. > > and in the text below that enumeration: > > ?????? Yes, text for this needs to be figured out. >> >> 2. Section 4: >> >> The method >> used to determine which side uses odd or even is based on the >> underlying DTLS connection role when used in WebRTC, with the side >> acting as the DTLS client using even stream identifiers. >> >> Isn't this unnecessary using the vague word of WebRTC instead of simply >> pointing to the DTLS roles of the established data channel? > The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore > you can refer to the DTLS role. However, you could use DCEP/SCTP/IP > or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. > In that case DTLS is not used and you can not refer to the DTLS role. > That is why the restriction is used. Ok, if that concern then you still should be able to write a normative specification under the condition that it is SCTP over DTLS. If not how do you determine that? Are suggesting just to hand way or point to a higher signaling layer. >> >> 3. Section 5.1: >> DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides >> a partial reliable in-order bi-directional Communication >> channel. User messages might not be transmitted or >> retransmitted after a specified life-time given in milli- >> seconds in the Reliability Parameter. This life-time starts >> when providing the user message to the Javascript engine. >> >> I think the use of "Javascript engine" in the last sentence is unclear. >> Can we provide a implementation neutral definition, like "This life-time >> starts when requesting transmission of the user message."? > This comment was already made on the list and I changed the text to > > This life-time starts when providing the user message to the protocol stack. > > OK? Yes. >> >> 4. Section 5.1: >> Label: Variable Length (sequence of characters) >> The name of the channel. This may be an empty string. >> >> Protocol: Variable Length (sequence of characters) >> The protocol for the channel. If this is an empty string the >> protocol us unspecified. If it is an non-empty string, it >> specifies an IANA-registered protocol (see Section 8.4). >> >> Both of these fields are strings, shouldn't a particular encoding be >> specified here? Like UTF-8. Secondly, what values are allowed, the full >> set of Unicode? > You are right. Any need for restrictions? We only need to be able to > transform it to a DomString. > So I changed it to: > > > > The name of the channel as a UTF-8 encoded string. > This may be an empty string. > > > > The protocol for the channel as a UTF-8 encoded string. > If this is an empty string the protocol us unspecified. > If it is an non-empty string, it specifies an IANA-registered protocol > (see ). I guess this is slightly overtaken by event. It have to be aligned with what the websocket sub-protocol identifier. >> >> 5. Section 6: >> All Data Channel Establishment Protocol messages MUST be sent >> requesting ordered delivery and using reliable transmission. >> >> I wonder of the use of requesting ordered delivery and using reliable >> transmission, from an SCTP stream perspective, wouldn't using in both >> places be appropriate? Or is how object which has been requested to be >> transmitted unordered interact in SCTP with the ordered ones? > I'm sorry, I don't understand what you are asking... Sorry, it really is a language issue. The above sentence first states "sent 'requesting' ordered" and later "and 'using' reliable". This inconsistency is what I reacted to. > >> 6. Section 7: >> >> I think this section can be beefed up a bit. First make clear that the >> Data Channel's required usage of DTLS ensures that the message integrity >> and possible source authentication as well as confidentiality. Then >> going over any security risks with a malicous peer using this protocol. >> Can a malicous side screw up the peer using this protocol? What are the >> implications? > Just to double check: Aren't the referenced documents the ones which > discuss all security stuff in one place? The security document do discuss system level important aspects. But, from my perspective, details that are very specific to this protocol should be discussed in this document. I think this is highly relevant in this document as there are others that are interested in using it. >> >> 7. Section 8.2: >> >> This registry reserves 0xff without any motivation, please add one. > I added: > > The value 0xff has been reserved for future extensibility. > Ok >> >> 8. Section 8.3: >> If I define a channel behavior that allows mixed ordered and unordered, >> how would I register this? > You can't. For SCTP properties like ordered/unordered delivery are > on a per message base. In RTCWeb it was decided to make per channel > base. So you can't have a data channel supporting a mixtures of > ordered and unordered messages. Ok, fine. >> >> 9. Section 8.4: >> >> I have a suggestion for this registries name, instead of "Protocol >> Registry" I propose "DCEP Protocol Identification Registry" > The problem I have with this definition is the following: > Your name suggests that the use of this entity is restricted to > DCEP. But isn't the protocol a property of a data channel, no matter > whether negotiated by used DCEP or not? As we now are going to point at the websocket one this is a mote point. >> >> 10. Section 8.4: >> >> There is missing any specification of what type of strings I may >> register. Also, no length limitation, although the protocol allows at >> maximum of 255 octets of encoded characters. > I don't understand the limitation to 255 octets. The length field > is 16 bit, so you can have up to 65535 octets. Therefore I changed: > A name for the protocol; > to > A name for the protocol which length is smaller than 65536 when using > an UTF-8 encoding; Overtaken by events, limitations will be the ones of the Websocket registry. >> >> 11. This comments concerns the relation to the Data Channel >> specification. So my interpretation is that the WebRTC Data channel >> draft has become both the base for this specification as well as the one >> that specifies that the DCEP shall be implemented and supported. For >> WebRTC I don't think this matters much, but if someone likes to re-use >> the basic Data Channel specification, this structure makes it more >> difficult and have no need for the bi-directional negotiated parameter >> settings that the DCEP provides. In that case one have to sub-set the > I think the data channel draft discusses the data channels independent > how they are opened. This covers data parameters, user data transmission > and closing of data channels. The data channel protocol draft discusses > an in-band protocol for setting up data channels. I think this was discussed today. And make it clear that DCEP requirement shouldn't be from the Data Channel spec. >> data channel specification. I wonder if it would be better to move some >> normative statements around, so that the chain of implementation >> requirement goes draft-ietf-rtcweb-transports -> >> draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel thus >> providing a cleaner and more modular build up of the protocols. > I think you can implement draft-ietf-rtcweb-data-channel without > draft-ietf-rtcweb-data-protocol, but not vice versa. > > So you don't like the statement: > > A simple protocol for internal negotiation is specified in > [I-D.ietf-rtcweb-data-protocol] and MUST be supported. > > from draft-ietf-rtcweb-data-channel. What would you suggest? I think the high level requirement on DCEP might be in -rtcweb-transports. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Mar 4 09:41:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA21A0289 for ; Tue, 4 Mar 2014 09:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 449RwomG7PG3 for ; Tue, 4 Mar 2014 09:41:43 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 351AF1A0284 for ; Tue, 4 Mar 2014 09:41:42 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-d4-53161052523e Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 68.D8.23809.25016135; Tue, 4 Mar 2014 18:41:38 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.220]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Tue, 4 Mar 2014 18:41:37 +0100 From: John Mattsson To: "rtcweb@ietf.org" Thread-Topic: comments on draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHPN9D9VQxOZ2H5PkqUHhzonfyQng== Date: Tue, 4 Mar 2014 17:41:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW6QgFiwwaEF0hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr482jycwF/4QrVn26xdLAuEe4i5GTQ0LARGL9/w52CFtM4sK9 9WxdjFwcQgKHGCUOTD8HlhASWMwocX2mNIjNJmAgMXdPAxuILSKgLnH54QWwGmEBB4kpn/ay QMRdJaZt3gpl60n0XL3DCGKzCKhI9Hx/DVbPK2AmcevyN7A4I9Di76fWMIHYzALiEreezGeC OEhAYsme88wQtqjEy8f/WEFsUaCZ9x7NZYGIK0ksuv0ZqJ4DqFdTYv0ufYgx1hKrzu5khLAV JaZ0P4RaKyhxcuYTlgmMorOQbJuF0D0LSfcsJN2zkHQvYGRdxciem5iZk15utIkRGAsHt/xW 3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBqJcT3me6r5pmx qevKkhaLj4KyIeGTP/7gOy267snz9XNvHbc+WbPTIqf/xZUPk6vO2/6+wcy4pJe7nLWfi7Xt 0FvF/PhyLq2Lol9cLiTOyp3p+O7z/HUW9xSXa1Zv57C03r2+eJUGR9vX1szV+VUxH49H/rY1 NJDb37XO+PLxk902v9LfiWYosRRnJBpqMRcVJwIAqacwAVMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5MD-ha4NNJwl-SDeRiw-Fs3V164 Subject: [rtcweb] comments on draft-ietf-rtcweb-stun-consent-freshness-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: Tue, 04 Mar 2014 17:41:47 -0000 SSByZWFkIHRocm91Z2ggZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0w MC4gSSBtb3N0bHkgaGF2ZQ0KZWRpdG9yaWFsIGNvbW1lbnRzLg0KDQpDaGVlcnMNCkpvaG4NCg0K DQot4oCcQSBjb25zZW50IHRpbWVyLCBUYywgd2hvc2UgdmFsdWUgaXMgZGV0ZXJtaW5lZCBieSB0 aGUgYnJvd3Nlci4gVGhpcw0KdmFsdWUgTVVTVCBiZSAxNSBzZWNvbmRzLuKAnQ0KDQpJIHdvdWxk IGRlbGV0ZSDigJx3aG9zZSB2YWx1ZSBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBicm93c2Vy4oCdIGFz IGl04oCZcw0KZGV0ZXJtaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KLUkgdGhpbmsgdGhl IHNlc3Npb24gbGl2ZW5lc3MgbWVjaGFuaXNtIG5lZWRzIG1vcmUgZGV0YWlsczoNCkRvZXMgInN0 YXJ0IGxpdmVuZXNzIHRlc3QiIG1lYW4gdGhhdCBpdCBzdGF5cyBvbiB1bnRpbCBKYXZhU2NyaXB0 IHNheXMNCiJzdG9wIGxpdmVuZXNzIHRlc3TigJ0sIGRvZXMgaXMgc3RvcCBhZnRlciBUciwgb3Ig ZG9lcyBpdCBzdG9wIGFmdGVyDQpub3RpZmljYXRpb24/DQpJZiBsaXZlbmVzcyB0ZXN0IHN0YXlz IG9uIGFmdGVyIG5vdGlmaWNhdGlvbiwgc2hvdWxkbid0IHRoZSBqYXZhc2NyaXB0IGJlDQppbmZv cm1lZCBvZiByZW5ld2VkIGNvbm5lY3Rpdml0eT8NCklmIGxpdmVuZXNzIHRlc3Qgc3RheXMgb24g YWZ0ZXIgbm90aWZpY2F0aW9uLCBJcyB0aGUgdGltZXIgcmVzZXQsIG9yIGRvZXMNCnRoZSBicm93 c2VyIGtlZXAgY2hlY2tpbmcgKGUuZy4gZXZlcnkgNTAwIG1zKQ0KDQoNCkVkaXRvcmlhbCBjb21t ZW50czoNCg0KLSAiVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBuZXcgU1RVTiB1c2FnZSB3aXRo IGEgcmVxdWVzdCBhbmQgcmVzcG9uc2UNCndoaWNoIHZlcmlmaWVzIHRoZSByZW1vdGUgcGVlciBj b25zZW50cyB0byByZWNlaXZlIHRyYWZmaWMsIGFuZCBkZXRlY3RzDQpsb3NzIG9mIGxpdmVuZXNz LiINCiAgIA0KU2hvdWxkIGJlIHJlcGhyYXNlZCBtYWtlIGl0IGNsZWFyZWVyIHRoYXQgIlNUVU4g dXNhZ2UiIGRvZXMgbm90IGRldGVjdA0KbG9zcyBvZiBsaXZlbmVzcy4NCg0KLSJUcmFuc3BvcnQg QWRkcmVzcyINCk5vdCB1c2VkLCBkZWxldGUgZGVmaW5pdGlvbg0KDQotUHV0IHNwYWNlIGJldHdl ZW4gbnVtYmVyIGFuZCB1bml0LCBpLmUuIOKAnDUwMG1z4oCdIC0+IOKAnDUwMCBtc+KAnSAocHJl ZmVyYWJseQ0Kbm9uLWJyZWFraW5nKQ0KDQoidXNlcyB0aHJlZSB2YWx1ZXMiDQpTZWVtIHRvIHVz ZSBmb3VyIHZhbHVlcyBhcyA1MDAgbXMgaXMgdXNlZCBhcyB3ZWxsLiBTaG91bGQgbWF5YmUgY29u c2lkZXINCnRyYXRpbmcgIlRjIiBhbmQgIjUwMCBtcyIgaW4gdGhlIHNhbWUgd2F5LiBJLmUuIGVp dGhlciB3cml0aW5nIG91dCAxNQ0Kc2Vjb25kcyBvciBpbnRyb2R1Y2luZyBUeCBmb3IgIjUwMCBt cyIuDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSk9ITiBNQVRUU1NPTg0KTVNjIEVuZ2luZWVy aW5nIFBoeXNpY3MsIE1TYyBCdXNpbmVzcyBBZG1pbmlzdHJhdGlvbiBhbmQgRWNvbm9taWNzDQpF cmljc3NvbiBJRVRGIFNlY3VyaXR5IENvb3JkaW5hdG9yDQpTZW5pb3IgUmVzZWFyY2hlciwgU2Vj dXJpdHkNCg0KRXJpY3Nzb24gQUINClNlY3VyaXR5IFJlc2VhcmNoDQpGw6Ryw7ZnYXRhbiA2DQpT RS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4NClBob25lICs0NiAxMCA3MSA0MyA1MDENClNNUy9N TVMgKzQ2IDc2IDExIDUzIDUwMQ0Kam9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20NCnd3dy5lcmlj c3Nvbi5jb20gPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tLz4NCg0KDQoNCg== From nobody Tue Mar 4 09:50:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571431A017B for ; Tue, 4 Mar 2014 09:50:56 -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 151j280A-6vw for ; Tue, 4 Mar 2014 09:50:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7C31A024E for ; Tue, 4 Mar 2014 09:50:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140304175047.1031.60291.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 09:50:47 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Oh_dSJOxveu_fF8SwGQitcEUGHI Subject: [rtcweb] Milestones changed for rtcweb WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:50:56 -0000 Changed milestone "Send Use Cases document (draft-ietf-rtcweb-use-cases-and- requirements) to IESG for publication as Informational", resolved as "Done". URL: http://datatracker.ietf.org/wg/rtcweb/charter/ From nobody Tue Mar 4 09:56:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEF61A0295 for ; Tue, 4 Mar 2014 09:56:47 -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 cBOwbz5dAPyS for ; Tue, 4 Mar 2014 09:56:46 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 66EBF1A028C for ; Tue, 4 Mar 2014 09:56:46 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta07.westchester.pa.mail.comcast.net with comcast id ZS3t1n0071vXlb857Vwjjh; Tue, 04 Mar 2014 17:56:43 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta17.westchester.pa.mail.comcast.net with comcast id ZVua1n0112904qf3dVudK7; Tue, 04 Mar 2014 17:54:41 +0000 Message-ID: <5316135A.1010405@alum.mit.edu> Date: Tue, 04 Mar 2014 17:54:34 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <530B740E.4090707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393955803; bh=kzAvfpek24srRphR+/JFpZh3H7ouWGtAAauuU/FXRIo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RjfNCUGeA+PNkhdg9C5q2GzB0JYjI6+jDvE30HpxZ3/90aw2FjgehKWrlrijGOunY QRljyOXxTjBuh4k2yy83VTGEfZVBe9ri2hYKgHwE/NxD241yIxenp6sCrMiSZabwcq 5WksABXkKsoBnv7n8CE84n8BY75cJTqoALN5Buu2MJExjm03FcLszt7E/5gzgQsau6 w06aHYweVUBzIbj2sSiQsTNzD1Nx81EfX8jpR7Nui5+Llq5SBY5LhdYh/+JBrEHU4B QPqzGKzHapDTUyEgykuZ2csByIh0B/JeBCyfDoUyjMcFkEf6+FQXX41K1TpnmTDQdr GjL+px3AzTZGA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lEFdsYrrxAe0nYlLYk2btZCfbw8 Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 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, 04 Mar 2014 17:56:49 -0000 On 2/25/14 5:07 PM, Michael Tuexen wrote: >> 2. Section 4: >> >> The method >> used to determine which side uses odd or even is based on the >> underlying DTLS connection role when used in WebRTC, with the side >> acting as the DTLS client using even stream identifiers. >> >> Isn't this unnecessary using the vague word of WebRTC instead of simply >> pointing to the DTLS roles of the established data channel? > The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore > you can refer to the DTLS role. However, you could use DCEP/SCTP/IP > or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. > In that case DTLS is not used and you can not refer to the DTLS role. > That is why the restriction is used. So data channels could work over SCTP/IP or SCTP/UDP/IP, but in fact can't solely because the choice of even/odd role is dependent on DTLS connection role? Couldn't you find a way to choose the even/odd role based solely on the SCTP layer and the SDP? Then data channels could be used over those other stacks. Thanks, Paul From nobody Tue Mar 4 10:28:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7C1A02DD for ; Tue, 4 Mar 2014 10:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqZNMlnjIfbw for ; Tue, 4 Mar 2014 10:28:27 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 86DE41A01F1 for ; Tue, 4 Mar 2014 10:28:27 -0800 (PST) Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6EB241C1042E0; Tue, 4 Mar 2014 19:28:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5316135A.1010405@alum.mit.edu> Date: Tue, 4 Mar 2014 18:28:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530B740E.4090707@ericsson.com> <5316135A.1010405@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bP-wGdA5R9qk1wVA4f9hYgJ0HHY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 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, 04 Mar 2014 18:28:32 -0000 On 04 Mar 2014, at 17:54, Paul Kyzivat wrote: > On 2/25/14 5:07 PM, Michael Tuexen wrote: >=20 >>> 2. Section 4: >>>=20 >>> The method >>> used to determine which side uses odd or even is based on the >>> underlying DTLS connection role when used in WebRTC, with the side >>> acting as the DTLS client using even stream identifiers. >>>=20 >>> Isn't this unnecessary using the vague word of WebRTC instead of = simply >>> pointing to the DTLS roles of the established data channel? >> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and = therefore >> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP >> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. >> In that case DTLS is not used and you can not refer to the DTLS role. >> That is why the restriction is used. >=20 > So data channels could work over SCTP/IP or SCTP/UDP/IP, but in fact = can't solely because the choice of even/odd role is dependent on DTLS = connection role? When not running over DTLS, you have not the security features provided = by DTLS, of course. >=20 > Couldn't you find a way to choose the even/odd role based solely on = the SCTP layer and the SDP? Then data channels could be used over those = other stacks. When running over UDP or IP you could define a client and server role = and use a similar rule. Best regards Michael >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Mar 4 10:28:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DDC1A01F1 for ; Tue, 4 Mar 2014 10:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 JWh7BLWcV47t for ; Tue, 4 Mar 2014 10:28:30 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE4AD1A02CE for ; Tue, 4 Mar 2014 10:28:29 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-ac-53161b498e34 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.E1.10875.94B16135; Tue, 4 Mar 2014 19:28:25 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.347.0; Tue, 4 Mar 2014 19:28:24 +0100 Message-ID: <53161B47.2090608@ericsson.com> Date: Tue, 4 Mar 2014 18:28:23 +0000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Harald Alvestrand , References: <530320F7.4090300@ericsson.com> <5303E578.3000207@alvestrand.no> <53046842.2010108@ericsson.com> <5304F3E0.1020206@alvestrand.no> <530C6F3C.1090709@ericsson.com> <53120F0E.4020703@alvestrand.no> In-Reply-To: <53120F0E.4020703@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RtdTWizYYMoVM4tjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBkXLixjL9gsWXHw8zmWBsbjIl2MnBwSAiYS lz4sY4awxSQu3FvP1sXIxSEkcIhRYt/amywQzjJGiTlL54JV8QpoSxx9eJQVxGYRUJFY1DAb zGYTsJC4+aORDcQWFQiW2HngNyNEvaDEyZlPWEBsEQF7iYtzXoLZwgKFEkd29YD1CgmcY5S4 fsWoi5GDg1NAV+LHFWMQU0JAXKKnMQikgllAT2LK1RZGCFteonnrbGaITm2JhqYO1gmMgrOQ LJuFpGUWkpYFjMyrGNlzEzNz0ssNNzECA/Lglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBkZNrr1+8v+68mUdMtOOy/qbSVxl9Zohd5aTXy9YhnnT874v OjmyhjL9RnkXdYVPn3N4JJ54zH+6/RrvWyUCCVUPLJ/ZBDcsa1q/2eFBb8PtlSw7j+dsK5l7 e6Hm2SY5pZoVJ7jW+/0Pf+jD5fXf2q/goKiksd6andXKyqEz1t/0q94aXSVTrsRSnJFoqMVc VJwIAGqwU9kWAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t5B5g_jhvvH-TKgASvx1BK5VmMI Subject: Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:28:35 -0000 On 2014-03-01 16:47, Harald Alvestrand wrote: > On 02/25/2014 11:23 AM, Magnus Westerlund wrote: >> On 2014-02-19 19:11, Harald Alvestrand wrote: >>> On 02/19/2014 09:16 AM, Magnus Westerlund wrote: >>>> On 2014-02-18 23:58, Harald Alvestrand wrote: >>>>> I may be a little simple-minded, but if we have a recommendation that >>>>> receivers MUST be able to receive all packetizations of G.711 and OPUS >>>>> up to 200 ms per packet, and that receivers should signal this by >>>>> sending "a=maxptime:200" in their SDP, what situations exist where >>>>> interoperability is not going to be achieved? >>>> Interoperability is going to be achieve in the direction towards this >>>> endpoint. The question is if we achieve interoperability in the >>>> direction from that endpoint. >>> So, given that there is nothing in the G.711 specification about which >>> sample sizes a G.711 receiver has to support - the right approach seems >>> to be to amend the G.711 MIME registration with this information. >> Yes, it would for the future. But considering the wide-spread deployment >> of this payload format I don't see that having any short term effect on >> the interoperability. >> >> Also, the recommendations are actually context dependent. Thus, it is >> not obvious that a single recommendation is suitable. >> >>> This is not a WebRTC issue; it is an absence of specification for the >>> non-WebRTC devices that use G.711. The RTCWEB specifications can >>> reasonably be expected to point to existing information about this >>> issue; it is not reasonable (in my mind) that the RTCWEB WG decide what >>> these values should be. >>> >> I would argue for this consideration based on that this is done in the >> WebRTC context, not any other context. > > For which value of "this" is that true? > > All other contexts that use G.711 send packets with a certain ptime > (which determines the number of samples per packet). > > It seems that all other contexts have managed to survive without a > specification of which ptime it makes sense to send, except for an upper > bound (maxptime). > > When this situation occurs, usually one of two things is happening: > > - There's an agreement not captured in the standard, which all > participants follow. > - The choice doesn't matter for interoperability. > > If the second is the case, I think the RTCWEB specification needs to say > nothing. > If the first is the case, the agreement not captured in the standard > needs to be captured in a standard. But this is not an RTCWEB standard. > I appear to be in the rough on this. I don't expect any real issues with this as long as implementations do sane things. (I was tempted to write "the right thing (TM)". Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Mar 4 11:24:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB801A028E for ; Tue, 4 Mar 2014 11:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YjFTK2jI-rI for ; Tue, 4 Mar 2014 11:24:35 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1D41A0279 for ; Tue, 4 Mar 2014 11:24:34 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s24JOU87023568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 13:24:30 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s24JOMOF002261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 14:24:29 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 14:24:22 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 Thread-Index: AQHPN9LNEmpWvfnszUmbtZnjPYHLHJrRS1Vw Date: Tue, 4 Mar 2014 19:24:22 +0000 Message-ID: References: <530B740E.4090707@ericsson.com> <5316135A.1010405@alum.mit.edu> In-Reply-To: <5316135A.1010405@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/de-NhPGIAq2zMfnnR15hs39axkg Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 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, 04 Mar 2014 19:24:37 -0000 > >> 2. Section 4: > >> > >> The method > >> used to determine which side uses odd or even is based on the > >> underlying DTLS connection role when used in WebRTC, with the side > >> acting as the DTLS client using even stream identifiers. > >> > >> Isn't this unnecessary using the vague word of WebRTC instead of simpl= y > >> pointing to the DTLS roles of the established data channel? > > The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefor= e > > you can refer to the DTLS role. However, you could use DCEP/SCTP/IP > > or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. > > In that case DTLS is not used and you can not refer to the DTLS role. > > That is why the restriction is used. >=20 > So data channels could work over SCTP/IP or SCTP/UDP/IP, but in fact > can't solely because the choice of even/odd role is dependent on DTLS > connection role? >=20 > Couldn't you find a way to choose the even/odd role based solely on the > SCTP layer and the SDP? Then data channels could be used over those > other stacks. [Raju]=20 +1 a=3Dsetup could be used to determine this, but the final determination is d= one only at SDP answer (which is same for DTLS). For DTLS/SCTP case since both DTLS and SCTP layers use the same a=3Dsetup, = both DTLS and SCTP client/servers roles match. So, DCEP changing text to indicate role determination be done per SCTP clie= nt/server role instead of DTLS role may just work and is compatible with ex= isting text. [/Raju] Best Regards Raju From nobody Tue Mar 4 11:43:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AAF1A02B5 for ; Tue, 4 Mar 2014 11:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boueNzhG6W_e for ; Tue, 4 Mar 2014 11:43:36 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD601A02B0 for ; Tue, 4 Mar 2014 11:43:35 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s24JhUxi022557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 13:43:30 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s24JhTEl023538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 14:43:29 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 14:43:29 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , Ted Hardie Thread-Topic: [rtcweb] *MUST* DCEP? Thread-Index: AQHPN5mmFhBjN/7IlE2x2iXE8FJgd5rRGzIA//+4iTCAAIVPgP//tvcggABkbAD//8FwkA== Date: Tue, 4 Mar 2014 19:43:28 +0000 Message-ID: References: <5315B2E8.7010703@alum.mit.edu> <5315EA19.90401@alum.mit.edu> <53160112.3080702@alum.mit.edu> In-Reply-To: <53160112.3080702@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {41EA916C-3AF1-41EC-AC3D-536E0F9832B6} x-cr-hashedpuzzle: BNOx HI/w Ikl3 JjeH MOZr NzD4 OBBX OZPy QCVD RL9c Syfz T5iO VMkC W5cj YrHA YztF; 3; cABrAHkAegBpAHYAYQB0AEAAYQBsAHUAbQAuAG0AaQB0AC4AZQBkAHUAOwByAHQAYwB3AGUAYgBAAGkAZQB0AGYALgBvAHIAZwA7AHQAZQBkAC4AaQBlAHQAZgBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {41EA916C-3AF1-41EC-AC3D-536E0F9832B6}; cgBhAGoAdQAuAG0AYQBrAGEAcgBhAGoAdQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtAA==; Tue, 04 Mar 2014 19:43:23 GMT;UgBFADoAIABbAHIAdABjAHcAZQBiAF0AIAAqAE0AVQBTAFQAKgAgAEQAQwBFAFAAPwA= x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/070u9sDkChSOxnvmCvcUb6klEec Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] *MUST* DCEP? 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, 04 Mar 2014 19:43:38 -0000 > >>> Are you looking at more than what is documented in > >>> [I-D.ejzak-mmusic-data-channel-sdpneg]? > >>> > >>> Or are you looking for an indication of this (for all streams) direct= ly > >>> in a=3Dsctpmap? > >> > >> I'm ok as things currently stand, though the documents are confusing. > >> The 'a=3Dsctpmap:nnn websocket-datachannel' means that DCEP is support= ed. > >> > >> My concern was a proposal I think I heard that would make support for > >> DCEP to be optional. In that case, IMO it is important that the O/A > >> exchange establish whether DCEP is supported or not. > > > > [Raju] > > That's the reason why I proposed to add 'protocol' parameter to a=3Ddcm= ap. > > Having this parameter at a=3Dsctmap level may not make that much sense = due > to: > > sctpmap is for entire association and protocol defaults to DCEP. To mak= e > use of external negotiation, which is per data channel stream, one would > need additional a=3D line(s) (e.g. ejzak's draft) to convey subprotocol i= nfo. > IMO adding data channel protocol option to a=3Ddcamp, which is per > subprotocol, makes sense. > > [/Raju] >=20 > I have no problem with a=3Ddcmap. >=20 > It is the 'app' parameter of the sctpmap attribute that I am talking abou= t. >=20 > If I want to use DCEP, the dcmap attribute is irrelevant to me. What is > it that tells me that DCEP is supported. The only datum available that > could imply that is the 'app' parameter of sctpmap. >=20 > Right now, if app is webrtc-datachannel, that implies DCEP is MTI. That > serves the purpose. >=20 > But as of today there was a suggestion that you could have cases where > there is an SCTP association that supports Data Channels, but not DCEP. > I don't know how the two would be distinguishable. Possibly by a > different 'app' value. [Raju]=20 Yes, one option is to define a new 'app'.=20 Another option is to use 'webrtc-datachannel', but then convey your own external data channel protocol via SDP and use it for all the streams. When you say "not DCEP", you mean it is "external" or "a different flavor of internal DCEP"?=20 [/Raju] >=20 > A related question is what is the applicability of a=3Ddcmap. Surely it > doesn't apply for all uses of SCTP - those that don't use data channels > at all. Do you propose to couple this to particular 'app' values? Or is > support for this negotiated independently of a=3Dsctpmap? [Raju]=20 Correct. dcmap applies to SCTP data channels only. dcmap's 'protocol' param= eter allows you to override webrtc default DCEP per data channel stream. When you are using dcmap it allows per data channel "interal(DCEP)" or=20 "external(SDP based)" determination using 'protocol' parameter. If there is a need we can allow the 'protocol' value to be extended (per IA= NA, may be?! ): "internal-DCEP" "external-SDP-based" (ejzak's draft) "new-enhanced-internal-DCEP" "pre-defined-stream-id-use-arrangement" [/Raju] Best Regards Raju From nobody Wed Mar 5 01:28:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE61A0199 for ; Wed, 5 Mar 2014 01:28:01 -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 C_wEzxTL47Ol for ; Wed, 5 Mar 2014 01:27:59 -0800 (PST) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 666EB1A00F2 for ; Wed, 5 Mar 2014 01:27:59 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q58so845455wes.6 for ; Wed, 05 Mar 2014 01:27: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:from:date:message-id:subject:to :content-type; bh=DJ4LZf35WEtRNNmfzNiZ8dq6EcurxbdTxJaTKNw2Eiw=; b=jaqKhYCfxVW+Y+SzTSc7B1DIDumMlqgjy+/LEOilwuPmJLk8vHwDgt2OoCKfqZHQRg uqhPQp5nZTqUtFieL+vfUeP8sDiDwdIYy4wewA4RmTISfNQpBA3gqZjATaILYujOkkZg YJwVaeAGPhaQLNnSTI0do4+jIRrFzsF3+2vuOxbecgknu7xeF1aOoUgMXTH09H46qDOA 7T36d9hFFuAwK7tJe2LOSTnEgfwU6SqO2ZwmT/GxrixmAuRPASSqNKkEkZdEvV0j3jVF YRLsyP3+GZb94kDTerOXBiLb0S368Z0e/wEJGPyAHFCA1tVD0+Qa0lQ8g482tq/Edmq0 eYDA== X-Gm-Message-State: ALoCoQkLGncVxBnPkBBRQHRf3sx8may6r6ymOgQ6o6jWB0HQaDOairly/YfEr9+Uda8m1IzScwBe X-Received: by 10.194.94.162 with SMTP id dd2mr6798148wjb.66.1394011675503; Wed, 05 Mar 2014 01:27:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 5 Mar 2014 01:27:15 -0800 (PST) X-Originating-IP: [2001:67c:370:176:3116:9dc8:d768:86ed] From: Eric Rescorla Date: Wed, 5 Mar 2014 09:27:15 +0000 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb04dc0bb468e04f3d8a262 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1QcxiujLFXK0IGaFUgtsh-VzUBs Subject: [rtcweb] Issue with new Trickle ICE text 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, 05 Mar 2014 09:28:01 -0000 --047d7bb04dc0bb468e04f3d8a262 Content-Type: text/plain; charset=ISO-8859-1 S 3.4.2 of JSEP now reads: JSEP applications typically inform the browser to begin ICE gathering via the information supplied to setLocalDescription, as this is where the app specifies the number of media streams to gather candidates for. However, to accelerate cases where the browser knows the number of media streams to use ahead of time, the application 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 can start by checking if any candidates are available in the pool. The issue here is that this basically mandates trickle ICE. If the pool is smaller than the number of independent ICE streams needed, then there is no way for you to "start gathering" (since this text says it happens with sLD) and therefore you cannot supply all of the candidates in the offer. If that's not the intention to require (and I don't believe we agreed to this semantic), then this needs to be rewritten. -Ekr --047d7bb04dc0bb468e04f3d8a262 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
S 3.4.2 of JSEP now reads:

=A0 =A0= JSEP applications typically inform the browser to begin ICE gathering
=A0 =A0 via the in= formation supplied to setLocalDescription, as this is where
=A0 =A0 the app specifies the number of media streams to gather candid= ates
=A0 =A0 f= or. =A0However, to accelerate cases where the browser knows the number
=A0 =A0 of media streams to use ahead of time, the application MAY ask= the
=A0 =A0 b= rowser to gather a pool of potential ICE candidates to help ensure
=A0 =A0 rapid media setup. =A0When setLocalDescription is eventually c= alled,
=A0 =A0= and the browser goes to gather the needed ICE candidates, it can
=A0 =A0 start by checking if any candidates are available in the pool.=

The issue here is that this basically mandates tr= ickle ICE. If the
pool is smaller than the number of independent = ICE streams needed,
then there is no way for you to "start gathering" (since thi= s text
says it happens with sLD) and therefore you cannot supply = all of the
candidates in the offer.

If that's not the intention to require (and I don't believe we agre= ed
to this semantic), then this needs to be rewritten.

-Ekr

--047d7bb04dc0bb468e04f3d8a262-- From nobody Wed Mar 5 02:04:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2021A000D for ; Wed, 5 Mar 2014 02:04:37 -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 iuS5UHNaotN9 for ; Wed, 5 Mar 2014 02:04:36 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DEB891A03AF for ; Wed, 5 Mar 2014 02:04:35 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so892340wes.29 for ; Wed, 05 Mar 2014 02:04:32 -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=0qfoDNCqdLTwBu6FY5b/8X+HnjfqGvZAjHWlBIeYfPM=; b=bHRRVLBWh2PtpxGjFNn0Lv7wRE2+QtEnaqnti+61mH9TFvwUXlHpks7p+Ydn2cKukw HQ8qGwo9OyQvoasoCWQW2zoxf4T/kbcIwtDd/Ilyw3u2V6ZHZYDzJvOmONCh+ipbN49G lW3HIcNuSkjBXhOZMdDX8KnoAuWi5DJjrTnB1U5AINV6iLyfA2oC7QNdEDbQ7R8LMLgh H1TA6mLFe8b4UCaSt2QcoBuCVi3d20QTipuZuS92dHT7UQdjtD1iPUdn+LUAVKzLdFLL nMjpED1dsKuQREssasrKLHZNc9u05hA6Ict6IV7NhSntr5CBHMudVgDn3avndupPLgNA 8JjQ== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr6944396wjc.31.1394013872009; Wed, 05 Mar 2014 02:04:32 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 02:04:31 -0800 (PST) Date: Wed, 5 Mar 2014 10:04:31 +0000 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eRJXCwVpY_6M-_H2I0Y75EWXFH4 Subject: [rtcweb] CNAMEs and multiple peer connections 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, 05 Mar 2014 10:04:37 -0000 I haven't thought about this in detail yet, but I wanted to ensure that this issue is tracked. I think that our chairs might be able to create an issue in some tracker. Can I request that they do that for this issue? From nobody Wed Mar 5 02:47:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2767B1A0416 for ; Wed, 5 Mar 2014 02:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXTxs6mOiZxe for ; Wed, 5 Mar 2014 02:47:40 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 926D91A0415 for ; Wed, 5 Mar 2014 02:47:40 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id Zmlf1n0040xGWP856mndpb; Wed, 05 Mar 2014 10:47:37 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta12.westchester.pa.mail.comcast.net with comcast id ZmlS1n00E2904qf3YmlUrm; Wed, 05 Mar 2014 10:45:35 +0000 Message-ID: <53170047.8070000@alum.mit.edu> Date: Wed, 05 Mar 2014 10:45:27 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Tuexen References: <530B740E.4090707@ericsson.com> <5316135A.1010405@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394016457; bh=E52iwHS0bt0NSHh1f6IR8ZNhKzNehUfWcG4OkAkfmmk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VuhMvPehr71JGuQZHYjaaySsflDTNcquoHjk+xes+ziD40bSzw3YtqlzuBQBuD1Ed 1ewbBjF+/t8TKyF7cR07SWXtoxfZ62PJe/t5W+wvmIlRaNYyrgfjRxu1ygfntohg6d PfikOzeu5OpCY9U6xZbiN7WkkdE7ViySzTzN32uP6zPX5kkqsGr4n64+4ABOTmlYVS 3q0uAq0SI7oClzBAoq+sNX6A/H2EhIKBcT8taTaTg4xJhFZ7upJP8BPSITYLt+VZk+ Qmd/rpJQRtMthxqd2R2uZlR98cH3EgCCbSIQ8jXcSkB/CPhh4LWQ3gG5r6oDKMFw07 WFf0v1xf00PEA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6gqby4Bd_GVnLpTLZ8IrLmeSbxo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 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, 05 Mar 2014 10:47:42 -0000 On 3/4/14 6:28 PM, Michael Tuexen wrote: > On 04 Mar 2014, at 17:54, Paul Kyzivat wrote: > >> On 2/25/14 5:07 PM, Michael Tuexen wrote: >> >>>> 2. Section 4: >>>> >>>> The method >>>> used to determine which side uses odd or even is based on the >>>> underlying DTLS connection role when used in WebRTC, with the side >>>> acting as the DTLS client using even stream identifiers. >>>> >>>> Isn't this unnecessary using the vague word of WebRTC instead of simply >>>> pointing to the DTLS roles of the established data channel? >>> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore >>> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP >>> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. >>> In that case DTLS is not used and you can not refer to the DTLS role. >>> That is why the restriction is used. >> >> So data channels could work over SCTP/IP or SCTP/UDP/IP, but in fact can't solely because the choice of even/odd role is dependent on DTLS connection role? > When not running over DTLS, you have not the security features provided by DTLS, of course. Of course. One might argue that in the new world we shouldn't even define proto stacks that don't include security. But for the moment we are defining those protos. I see no reason why data channels should work over sctp, regardless of what is below that. >> Couldn't you find a way to choose the even/odd role based solely on the SCTP layer and the SDP? Then data channels could be used over those other stacks. > When running over UDP or IP you could define a client and server role and use a similar rule. Defining the rule differently for each proto stack is *possible* but unpleasant. IMO it would be far better to have a rule that works without regard for what is under sctp. Thanks, Paul > Best regards > Michael >> >> Thanks, >> Paul >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > From nobody Wed Mar 5 04:32:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62D91A0489 for ; Wed, 5 Mar 2014 04:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 L_njRJopSAfw for ; Wed, 5 Mar 2014 04:32:49 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id BE3F11A0424 for ; Wed, 5 Mar 2014 04:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1194; q=dns/txt; s=iport; t=1394022761; x=1395232361; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8CY5jp6faeYRz9GGg2EgY0FN1Z8rO809mKSwJhkUP+g=; b=QLw4rDdGJKGnPDTbl9Gmb1wSa7q0eR5NJIx0zfY3XYtvDYRNbdOmJYN4 YocUR2a9jUOWE+BfpGdOyhkddliOxiAHjandg/Jb/PfTTfmRkZQABxWc8 n+kLvVNCEt1bP1ypsij45Iqnp3qk8wM0GcJEpBZZoTHEDG3NDdprDUdJz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0KAEkYF1OtJXG//2dsb2JhbAA5IYMGgRLCJBZ0giw6UQE+QicEiAyeBq9sF5F8gRQEmD2SK4Mtgio X-IronPort-AV: E=Sophos;i="4.97,592,1389744000"; d="scan'208";a="25075710" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-5.cisco.com with ESMTP; 05 Mar 2014 12:32:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s25CWeok006577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 12:32:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.113]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 06:32:40 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8Sfg== Date: Wed, 5 Mar 2014 12:32:39 +0000 Message-ID: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.238] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MmGLRmDLuYzNWkeln38wMl492FQ Subject: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 12:32:54 -0000 I am opposed to mandating that Client-to-Mixer Audio Level RTP header is RE= QUIRED to be encrypted. It means that we can not really build conferencing = system where the mixers do not have access to decrypt the media. I would like to propose that the JS application can control if the header = is encrypted or not. =20 I am aware of the paper that suggests these audio levels can reveal the con= tents of the conversation. There is some element of truth to this. There is= also some element of truth to the point that if this was true, speech reco= gnition system would work better than they do. Encrypting this or not is a = risk that the application using the header extension needs to evaluate, and= WebRTC system needs to provide the applications with a control surfaces th= at allows them to use this in the way the applications desires. I will note that an normal application that used this header could decide i= f it was encrypted or not, what is different in RTCWeb is that we are build= ing a platform and my view is that this platform should allow the applicati= ons build on the platform to decide the tradeoffs of risk for encrypting th= is or not.=20 From nobody Wed Mar 5 04:44:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A096B1A03A6 for ; Wed, 5 Mar 2014 04:44:24 -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, 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 Y5435pLl6btG for ; Wed, 5 Mar 2014 04:44:23 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 38F691A0400 for ; Wed, 5 Mar 2014 04:44:21 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-fe-53171c21637e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0B.D1.04249.12C17135; Wed, 5 Mar 2014 13:44:17 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.347.0; Wed, 5 Mar 2014 13:44:16 +0100 Message-ID: <53171C20.3020001@ericsson.com> Date: Wed, 5 Mar 2014 12:44:16 +0000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson , "rtcweb@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RldRRjzY4MItPotrZ/4xWqz9187u wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGXsP3eGteCMYMXd99/YGxjb+LoYOTkkBEwk bmxpZ4KwxSQu3FvP1sXIxSEkcIRRYt7UfiYIZxmjxJv5sxlBqngFtCV6W1+yg9gsAioSx89d YAGx2QQsJG7+aGQDsUUFgiV2HvgNVS8ocXLmE7AaEYEQiSNt01lBbGEBK4knhw+AxYUEAiS6 vm8H6uXg4BQIlLh6wAPElBAQl+hpDAKpYBbQk5hytYURwpaXaN46mxmiU1uioamDdQKj4Cwk y2YhaZmFpGUBI/MqRo7i1OKk3HQjg02MwJA8uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoFxedjXre/WfpivscH8ROQCWy7lx6m2Bc8LTWebxj+Xk1r4 3ntCjq0f25S7rewP2o8IZM/NCFppUnz7o1zgvPcKWdMKpp30f6ty/yLbMa3O7pKJm6dzVE/u EjBf2ZkyOeRZysnD/Np1KipPK6df+rLEzC6Ya8fmQH6Nhy0PzTIe3FRVlPmt4DlRiaU4I9FQ i7moOBEA3fIVUhcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_A5mHp0MWDvjVvd3cmJ28Sv1LXU Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 05 Mar 2014 12:44:25 -0000 On 2014-03-05 10:04, Martin Thomson wrote: > I haven't thought about this in detail yet, but I wanted to ensure > that this issue is tracked. I think that our chairs might be able to > create an issue in some tracker. Can I request that they do that for > this issue? > I will currently not stuff anything into our tracker. However, I will give a bit of context from what the rtp-usage says about this. On the receiver side, we have a clear requirement on handling multiple CNAMEs in Section 11. A WebRTC endpoint MUST support receiving multiple MediaStreamTracks, where each of different MediaStreamTracks (and their sets of associated packet streams) uses different CNAMEs. However, MediaStreamTracks that are received with different CNAMEs have no defined synchronisation. On the sending side the text says the following: The same MediaStreamTrack can also be included in multiple MediaStreams, thus multiple sets of MediaStreams can implicitly need to use the same synchronisation base. To ensure that this works in all cases, and don't forces a endpoint to change synchronisation base and CNAME in the middle of a ongoing delivery of any packet streams, which would cause media disruption; all MediaStreamTracks and their associated SSRCs originating from the same endpoint MUST be sent using the same CNAME within one RTCPeerConnection as well as across all RTCPeerConnections part of the same communication session context, which for a browser are a single origin. Martin, you talked about linking in this context. I wonder if there really are an issue with linking as this is all in the same communication context. Can you please make clear your concerns? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 5 05:37:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544A31A0041 for ; Wed, 5 Mar 2014 05:37:45 -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 N21twXn4gAft for ; Wed, 5 Mar 2014 05:37:44 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id DCA151A002A for ; Wed, 5 Mar 2014 05:37:43 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so1230026wgh.19 for ; Wed, 05 Mar 2014 05:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n2cFY4fg8bTmTF0YBQZrZdgBMuslco49nbiYi6ThZYI=; b=xjquu8Jrp4Ujijjt1AZNEVGiQO7o1n48s2S45K2KI48uhSgFYdH25GBRZg5QGpGThD ftyITaPkdwn91yV67OnFkSLAGVAoaBVEFslK/tiUZNq7igdFxG3fT9oZOXScuR3kF/tb JXHOAujQCAEh3ndpquO8vBZ+3aM88Ao0JMlYGJmXGsPuUkn0KarKHBG1mKtK7ZNJz14V ZABxeLuAizpAyuaz4IPr1ZUSOIxtAUyeaN5ATfeubXsGS9Ey/JJFDsOWpr7nPcsSCMfi ULddodpKXzu8ONsDa85rJWpIVcMW04chL19wp7l6FD853X4S9CWkbAfoKSc0cKikwuP2 WePQ== MIME-Version: 1.0 X-Received: by 10.194.206.102 with SMTP id ln6mr873253wjc.43.1394026659893; Wed, 05 Mar 2014 05:37:39 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 05:37:39 -0800 (PST) In-Reply-To: <53171C20.3020001@ericsson.com> References: <53171C20.3020001@ericsson.com> Date: Wed, 5 Mar 2014 13:37:39 +0000 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aQmc-eaobtJ84TW1wPzOvXCP8Hc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 05 Mar 2014 13:37:45 -0000 On 5 March 2014 12:44, Magnus Westerlund wrote: > Martin, you talked about linking in this context. I wonder if there > really are an issue with linking as this is all in the same > communication context. Can you please make clear your concerns? I'm mostly concerned about being able to communicate with multiple people from the same page without revealing a linkage between sessions based on cert or CNAME. It may be that we need API hooks to control this. As I said, I haven't thought it through fully. From nobody Wed Mar 5 05:59:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153231A00A8 for ; Wed, 5 Mar 2014 05:59:14 -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 dEjpeqBpA39f for ; Wed, 5 Mar 2014 05:59:12 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 71F471A0080 for ; Wed, 5 Mar 2014 05:59:11 -0800 (PST) Received: (qmail 39714 invoked from network); 5 Mar 2014 13:59:06 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 8759 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Mar 2014 13:59:06 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6920F18A0534; Wed, 5 Mar 2014 13:59:06 +0000 (GMT) Received: from dhcp-a471.meeting.ietf.org (dhcp-a471.meeting.ietf.org [31.133.164.113]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 43BDE18A03A0; Wed, 5 Mar 2014 13:59:06 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: tim panton In-Reply-To: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> Date: Wed, 5 Mar 2014 13:59:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rxcnXnf4vV6By_Y9pnMgrP3SA3w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 13:59:14 -0000 On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) = wrote: >=20 > I am opposed to mandating that Client-to-Mixer Audio Level RTP header = is REQUIRED to be encrypted. It means that we can not really build = conferencing system where the mixers do not have access to decrypt the = media. I have to ask: Does that matter enough to weaken user security for everyone else?=20 >=20 > I would like to propose that the JS application can control if the = header is encrypted or not. =20 I am deeply uncomfortable about that. I am not a good enough = cryptographer to know, but my instinct is that exposing the fact that (for example) most of the top bits of the = ulaw data are zeros in this packet must be a risk. I=92m pretty confident that one could detect the pitch of the speaker = and probably fingerprint that down to individuals or languages with enough data. >=20 > I am aware of the paper that suggests these audio levels can reveal = the contents of the conversation. There is some element of truth to = this. There is also some element of truth to the point that if this was = true, speech recognition system would work better than they do. = Encrypting this or not is a risk that the application using the header = extension needs to evaluate, and WebRTC system needs to provide the = applications with a control surfaces that allows them to use this in the = way the applications desires. I am also uncomfortable about the number of little ad-hoc control = surfaces that we seem to be mandating without an overall design. My take is that we should push this out to 2.0 when hopefully we will = have a designed control surface in place. >=20 > I will note that an normal application that used this header could = decide if it was encrypted or not, what is different in RTCWeb is that = we are building a platform and my view is that this platform should = allow the applications build on the platform to decide the tradeoffs of = risk for encrypting this or not.=20 That isn=92t the line we have taken in any other encryption discussion. Tim. From nobody Wed Mar 5 06:06:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B28A1A01FC for ; Wed, 5 Mar 2014 06:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 mY5L5ppNcNLT for ; Wed, 5 Mar 2014 06:06:03 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65C1A016B for ; Wed, 5 Mar 2014 06:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2886; q=dns/txt; s=iport; t=1394028360; x=1395237960; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=G+51u9L1QLf09fUi1csCMHDV2UMBUEe150naq59b5fo=; b=k81l7rPyj7uTSgIQ6ZQ1pT8r4Zjp8G1ildJ2+Fk/Z1xLnbxVObSregLh xyk/CejJg+BVo1hhaGtQGz2NsrLwD5Xle+IZ901af7OvSLpC7qv+9DdXl xVSWpgisw7zNnq7Etx9e+LJ+evP4LDvODgRdGd0TSNeiZK37kurboDALz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFEuF1OtJXG//2dsb2JhbABagwaBEsELgRYWdIIlAQEBAwF5EAIBCBguMiUCBA4Fh3EIzgoXjh4zB4MkgRQBA5g9kiuDLYIq X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="308168594" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 05 Mar 2014 14:05:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s25E5sRA020791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 14:05:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.113]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 08:05:54 -0600 From: "Cullen Jennings (fluffy)" To: tim panton Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8SfprS6duAgAACN4A= Date: Wed, 5 Mar 2014 14:05:53 +0000 Message-ID: <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.132] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3E90FC92E77D9C4C925CCDFE0B9A7A03@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rC_Kjs0wjkZ_gSeLrOtv1htMHcc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:06:05 -0000 Well if people don=92t want to allow the application to choose to encrypt t= his header or not, I will be arguing for MUST NOT encrypt the RTP headers -= all of them.=20 A recurring theme at IETF is that people trying to protect E2E privacy, do = things that result in the real world having the only way they can build app= lications is to build middle boxes that pretend to to be an end to the thin= gs on both sides. This means that the middle boxes end up with 100% ability= to change everything and we loose all the protection we hoped to get with = E2E security.=20 On Mar 5, 2014, at 1:59 PM, tim panton wrote: >=20 > On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) wrot= e: >=20 >>=20 >> I am opposed to mandating that Client-to-Mixer Audio Level RTP header is= REQUIRED to be encrypted. It means that we can not really build conferenci= ng system where the mixers do not have access to decrypt the media. >=20 > I have to ask: > Does that matter enough to weaken user security for everyone else?=20 >=20 >=20 >>=20 >> I would like to propose that the JS application can control if the head= er is encrypted or not. =20 >=20 > I am deeply uncomfortable about that. I am not a good enough cryptographe= r to know, but my instinct > is that exposing the fact that (for example) most of the top bits of the = ulaw data are zeros in this packet > must be a risk. >=20 > I=92m pretty confident that one could detect the pitch of the speaker and= probably fingerprint that down > to individuals or languages with enough data. >=20 >>=20 >> I am aware of the paper that suggests these audio levels can reveal the = contents of the conversation. There is some element of truth to this. There= is also some element of truth to the point that if this was true, speech r= ecognition system would work better than they do. Encrypting this or not is= a risk that the application using the header extension needs to evaluate, = and WebRTC system needs to provide the applications with a control surfaces= that allows them to use this in the way the applications desires. >=20 > I am also uncomfortable about the number of little ad-hoc control surface= s that we seem to be mandating > without an overall design. >=20 > My take is that we should push this out to 2.0 when hopefully we will hav= e a designed control surface in place. >=20 >>=20 >> I will note that an normal application that used this header could decid= e if it was encrypted or not, what is different in RTCWeb is that we are bu= ilding a platform and my view is that this platform should allow the applic= ations build on the platform to decide the tradeoffs of risk for encrypting= this or not.=20 >=20 > That isn=92t the line we have taken in any other encryption discussion. >=20 > Tim. >=20 From nobody Wed Mar 5 06:26:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E01A0505 for ; Wed, 5 Mar 2014 06:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 1Gj45SXzpHMy for ; Wed, 5 Mar 2014 06:26:10 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C01B41A0537 for ; Wed, 5 Mar 2014 06:26:06 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id va2so1050838obc.14 for ; Wed, 05 Mar 2014 06:26:03 -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=u7JF0CPe+VH8de1q3u1Tq//sBgUeR9DJMpeMWCB0Wec=; b=QHNEccdfGHgyfQEsi4V9s6WP/YgprwC/5je4zn+YD3H3x69Ez9SGgA5HJ8ZGLuYJvA /SrxqxeomxM6tXIfa56ZNgUQn4XnfOK0FoTj9OpFPR+AafdFutVcMBNliy0pVF9CLz6n aHN9FC5NDToQ751SJ1yN2SRMC4LGJ3UeAIfwQfKjsusucuELIUn4FxiZ6292pYX9Pmhy mdpfsvms8SJSism/uk6O8CK6QgGv59AFO2WFKgjcSxPDHfxq/J9o+Fx90pFzLypAyRs5 4rEO175QoFDkCaTEiC7WElL04nl2NaHk3UrQpefhu0IPyuRYKV7eNPd6S2332qcKwh7d umxQ== 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=u7JF0CPe+VH8de1q3u1Tq//sBgUeR9DJMpeMWCB0Wec=; b=BeEfzwE8Q9AJ3xwlugjMzbIt5ufRTAJI2z6vy+2fkQWFyw41JmNbgIut2eKFc2o5k8 Yziu52T1PWjqBu12mN0jY14qvXLf1ULx+qJIq2DG3nDs0tNK8z2mGY3FqI5S1fkfxbMl 6mawvZfHGspzE8o4/qWVMud0lXXxTc0s5xZytpNiVlqmQaZZqyFw46BDjJZ1X6jwOb7y QF4GDa8MXpvvR+8Er77Mb3ywTJiG+WqId7hHMRyXsvFjsxM53s3Az7FhFfOMKvlyMeJ+ rSESi48xzVwvY4dlhe3RMUWoLfC49aKcNb7ANMlPtVC7ukXJtYxKPr6G/oPvpgYjzzF2 scGA== X-Gm-Message-State: ALoCoQnlPuB6yHvgzLUcNaDlB70yqw+t5zhsMb61hWQMhl2nQEI3EejZ+L48e17D44jeSMhIUVjYQoIjM/dH+u9Qep6u8c6PEZ1wg84Wzyzj/z66e1jSvFMcnXS2npch48A3hyAMLZfVJkGth6J69Z26XM08K6h+WAf+fWKKCUOVqPV02j+5Rb5Ho0870+Cle9M5nvS1eiFh X-Received: by 10.60.119.73 with SMTP id ks9mr568955oeb.75.1394029563014; Wed, 05 Mar 2014 06:26:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 06:25:42 -0800 (PST) In-Reply-To: <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> From: Justin Uberti Date: Wed, 5 Mar 2014 14:25:42 +0000 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b33cddce9149404f3dccc44 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/soGJf0bIx08sK88cPxn5vik4VFc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:26:13 -0000 --047d7b33cddce9149404f3dccc44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So there are three things here: 1) MUST the implementation offer encrypted header extensions? (i.e. mandatory-to-implement) 2) MUST the implementation use encrypted header extensions? (i.e. mandatory-to-use) 3) MUST the implementation expose an API to control this? (i.e. no SDP munging needed) I think we want yes for #1, no for #2, and #3 is potentially interesting but out of scope for 1.0. That gives encrypted headers for audio on by default, but remote parties can negotiate this off using RFC 6904 mechanisms. On Wed, Mar 5, 2014 at 2:05 PM, Cullen Jennings (fluffy) wrote: > > Well if people don=E2=80=99t want to allow the application to choose to e= ncrypt > this header or not, I will be arguing for MUST NOT encrypt the RTP header= s > - all of them. > > A recurring theme at IETF is that people trying to protect E2E privacy, d= o > things that result in the real world having the only way they can build > applications is to build middle boxes that pretend to to be an end to the > things on both sides. This means that the middle boxes end up with 100% > ability to change everything and we loose all the protection we hoped to > get with E2E security. > > > On Mar 5, 2014, at 1:59 PM, tim panton wrote: > > > > > On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) > wrote: > > > >> > >> I am opposed to mandating that Client-to-Mixer Audio Level RTP header > is REQUIRED to be encrypted. It means that we can not really build > conferencing system where the mixers do not have access to decrypt the > media. > > > > I have to ask: > > Does that matter enough to weaken user security for everyone else? > > > > > >> > >> I would like to propose that the JS application can control if the > header is encrypted or not. > > > > I am deeply uncomfortable about that. I am not a good enough > cryptographer to know, but my instinct > > is that exposing the fact that (for example) most of the top bits of th= e > ulaw data are zeros in this packet > > must be a risk. > > > > I=E2=80=99m pretty confident that one could detect the pitch of the spe= aker and > probably fingerprint that down > > to individuals or languages with enough data. > > > >> > >> I am aware of the paper that suggests these audio levels can reveal th= e > contents of the conversation. There is some element of truth to this. The= re > is also some element of truth to the point that if this was true, speech > recognition system would work better than they do. Encrypting this or not > is a risk that the application using the header extension needs to > evaluate, and WebRTC system needs to provide the applications with a > control surfaces that allows them to use this in the way the applications > desires. > > > > I am also uncomfortable about the number of little ad-hoc control > surfaces that we seem to be mandating > > without an overall design. > > > > My take is that we should push this out to 2.0 when hopefully we will > have a designed control surface in place. > > > >> > >> I will note that an normal application that used this header could > decide if it was encrypted or not, what is different in RTCWeb is that we > are building a platform and my view is that this platform should allow th= e > applications build on the platform to decide the tradeoffs of risk for > encrypting this or not. > > > > That isn=E2=80=99t the line we have taken in any other encryption discu= ssion. > > > > Tim. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b33cddce9149404f3dccc44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So there are three things here:
1) MUST the implementa= tion offer encrypted header extensions? (i.e. mandatory-to-implement)
=
2) MUST the implementation use encrypted header extensions? (i.e. mand= atory-to-use)
3) MUST the implementation expose an API to control this? (i.e. no SDP= munging needed)

I think we want yes for #1, n= o for #2, and #3 is potentially interesting but out of scope for 1.0.
That gives encrypted headers for audio on by default, but remote parti= es can negotiate this off using RFC 6904 mechanisms.



On Wed, M= ar 5, 2014 at 2:05 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

Well if people don=E2=80=99t want to allow the application to choose to enc= rypt this header or not, I will be arguing for MUST NOT encrypt the RTP hea= ders - all of them.

A recurring theme at IETF is that people trying to protect E2E privacy, do = things that result in the real world having the only way they can build app= lications is to build middle boxes that pretend to to be an end to the thin= gs on both sides. This means that the middle boxes end up with 100% ability= to change everything and we loose all the protection we hoped to get with = E2E security.


On Mar 5, 2014, at 1:59 PM, tim panton <tim@phonefromhere.com> wrote:

>
> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
>>
>> I am opposed to mandating that Client-to-Mixer Audio Level RTP hea= der is REQUIRED to be encrypted. It means that we can not really build conf= erencing system where the mixers do not have access to decrypt the media. >
> I have to ask:
> Does that matter enough to weaken user security for everyone else?
>
>
>>
>> I would like to propose that the JS application can control =C2=A0= if the header is encrypted or not.
>
> I am deeply uncomfortable about that. I am not a good enough cryptogra= pher to know, but my instinct
> is that exposing the fact that (for example) most of the top bits of t= he ulaw data are zeros in this packet
> must be a risk.
>
> I=E2=80=99m pretty confident that one could detect the pitch of the sp= eaker and probably fingerprint that down
> to individuals or languages with enough data.
>
>>
>> I am aware of the paper that suggests these audio levels can revea= l the contents of the conversation. There is some element of truth to this.= There is also some element of truth to the point that if this was true, sp= eech recognition system would work better than they do. Encrypting this or = not is a risk that the application using the header extension needs to eval= uate, and WebRTC system needs to provide the applications with a control su= rfaces that allows them to use this in the way the applications desires. >
> I am also uncomfortable about the number of little ad-hoc control surf= aces that we seem to be mandating
> without an overall design.
>
> My take is that we should push this out to 2.0 when hopefully we will = have a designed control surface in place.
>
>>
>> I will note that an normal application that used this header could= decide if it was encrypted or not, what is different in RTCWeb is that we = are building a platform and my view is that this platform should allow the = applications build on the platform to decide the tradeoffs of risk for encr= ypting this or not.
>
> That isn=E2=80=99t the line we have taken in any other encryption disc= ussion.
>
> Tim.
>

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

--047d7b33cddce9149404f3dccc44-- From nobody Wed Mar 5 06:28:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039651A0245 for ; Wed, 5 Mar 2014 06:28:29 -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 wKGBWlgbQ-5t for ; Wed, 5 Mar 2014 06:28:26 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 971211A0203 for ; Wed, 5 Mar 2014 06:28:25 -0800 (PST) Received: (qmail 76984 invoked from network); 5 Mar 2014 14:28:20 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 9418 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Mar 2014 14:28:20 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id D37DE18A07F3; Wed, 5 Mar 2014 14:28:20 +0000 (GMT) Received: from dhcp-a471.meeting.ietf.org (dhcp-a471.meeting.ietf.org [31.133.164.113]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A253B18A05E7; Wed, 5 Mar 2014 14:28:20 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: tim panton In-Reply-To: <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> Date: Wed, 5 Mar 2014 14:28:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <11A86E86-F87A-43C0-AC9D-D202FD038C83@phonefromhere.com> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7hwF5_x-CuFwb7Z0Vk_OMKlc81k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:28:29 -0000 On 5 Mar 2014, at 14:05, Cullen Jennings (fluffy) = wrote: >=20 > Well if people don=92t want to allow the application to choose to = encrypt this header or not, I will be arguing for MUST NOT encrypt the = RTP headers - all of them.=20 >=20 > A recurring theme at IETF is that people trying to protect E2E = privacy, do things that result in the real world having the only way = they can build applications is to build middle boxes that pretend to to = be an end to the things on both sides. This means that the middle boxes = end up with 100% ability to change everything and we loose all the = protection we hoped to get with E2E security.=20 To me this smacks of special pleading, it would be very useful (for = support reasons) if the javascript (optionally) got access to the names and characteristics of the input devices. We = decided as a group that a) the risks of fingerprinting out weighed the = benefits b) that we didn=92t need a control surface to expose an option = for this. I feel this is an equivalent case, but we seem to be looking at making a = different decision. I=92m confident that the desired result could be achieved securely with = a combination of webAudio sending appropriate volume data down a data = channel set up to the middle box for this purpose. I realise that would require some extensive rework in the middle box, = but thats what happens when you connect a middle box to an ostensibly = peer-to-peer system. Tim. >=20 >=20 > On Mar 5, 2014, at 1:59 PM, tim panton wrote: >=20 >>=20 >> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) = wrote: >>=20 >>>=20 >>> I am opposed to mandating that Client-to-Mixer Audio Level RTP = header is REQUIRED to be encrypted. It means that we can not really = build conferencing system where the mixers do not have access to decrypt = the media. >>=20 >> I have to ask: >> Does that matter enough to weaken user security for everyone else?=20 >>=20 >>=20 >>>=20 >>> I would like to propose that the JS application can control if the = header is encrypted or not. =20 >>=20 >> I am deeply uncomfortable about that. I am not a good enough = cryptographer to know, but my instinct >> is that exposing the fact that (for example) most of the top bits of = the ulaw data are zeros in this packet >> must be a risk. >>=20 >> I=92m pretty confident that one could detect the pitch of the speaker = and probably fingerprint that down >> to individuals or languages with enough data. >>=20 >>>=20 >>> I am aware of the paper that suggests these audio levels can reveal = the contents of the conversation. There is some element of truth to = this. There is also some element of truth to the point that if this was = true, speech recognition system would work better than they do. = Encrypting this or not is a risk that the application using the header = extension needs to evaluate, and WebRTC system needs to provide the = applications with a control surfaces that allows them to use this in the = way the applications desires. >>=20 >> I am also uncomfortable about the number of little ad-hoc control = surfaces that we seem to be mandating >> without an overall design. >>=20 >> My take is that we should push this out to 2.0 when hopefully we will = have a designed control surface in place. >>=20 >>>=20 >>> I will note that an normal application that used this header could = decide if it was encrypted or not, what is different in RTCWeb is that = we are building a platform and my view is that this platform should = allow the applications build on the platform to decide the tradeoffs of = risk for encrypting this or not.=20 >>=20 >> That isn=92t the line we have taken in any other encryption = discussion. >>=20 >> Tim. >>=20 >=20 From nobody Wed Mar 5 06:31:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3481A022A for ; Wed, 5 Mar 2014 06:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 z_6AYda072gs for ; Wed, 5 Mar 2014 06:31:06 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3B54F1A014C for ; Wed, 5 Mar 2014 06:31:06 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id uz6so1056268obc.15 for ; Wed, 05 Mar 2014 06:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c3Uh+m6niWkcOlg78jXaVUr7d8pHLC3Oh79RGzzLDT4=; b=NDJrpbWwwzxHNMERFuO5afOt6MP/L8Nrm4AaKjpm/1hwU3HMyYEnX3b9fkblynffpv tnFkCYBvo5qUK1jq7Sv7oZHp2BOkUP+Xul5vZiuEAcCqcpZzX8cFxPQapaWtuAGjJ99C bkcRhJVKT3Jj7RKL6kp1GrcA95npQ2wRD46M/2nYMBqInm5ib3k8Ql4/RRU64LJvwZQq UeDdmh4OWtyx6pE75i/C+tshb6EEh/OhvD9WDbppuROVagcxJnMjVmmTVxM3V5HXDn66 ypJmW0r8Aiiz1oroaIaMoObHQ4bjuhG1fmHzX17BFDFdpaiqKNu3ru6vsC7vR663Z2rA ygew== 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=c3Uh+m6niWkcOlg78jXaVUr7d8pHLC3Oh79RGzzLDT4=; b=AUyFtasMxhnckAkL/8nvlOv0ymIoMd1dYE2qGHeRvrz9JSg4rBOb9Q1GtrkR9lPCv4 j5jpLH8kxANiCqbrCJxy9WpXesAuu5PcyM2CuGue3+ue2QQUYRoG5rdd7dlDklRFfLzI DV8z+OrDr72/CJlmTdIz/luS5GKQly/UrWbbS+Qqv97lEUfRqe3waapvwKtnhKg7HiN/ tWCF28t5HJA7rkRQvY1q/Vmn9G8ruoRDnOCvkBy3FdUDfRz5+obV1MBTgTSrOmw0eehE qz/1thaR/6icrKvqxKjXLbZXZFkiPoui7r9ROAZ/p1q/iRYQO+UKFJP2cz4WRChkNqs7 qQcA== X-Gm-Message-State: ALoCoQmWe3XIukRn5PeYIDYQlZHfrLguosrfZ095raor0Yc0WcT+TR7NhgV/qYsAbr3V+hrQoFW2w3Yz4+8CWNks91WqlyXRE/bXt0wo5PUdKgKtrabPa+GsAAlmYD2Hat77WtYP31LMnZbor219vLK4RKeGTU8dPDGh5AcFQ808eeMLnfmrfZ+4xKzYgvN03OmZdbdDBwtK X-Received: by 10.60.155.72 with SMTP id vu8mr705649oeb.60.1394029862527; Wed, 05 Mar 2014 06:31:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 06:30:42 -0800 (PST) In-Reply-To: References: <53171C20.3020001@ericsson.com> From: Justin Uberti Date: Wed, 5 Mar 2014 14:30:42 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bd6ab54c34f2c04f3dcde1c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iRY49B8y-NZe-pSFiLptyrqmdSA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 05 Mar 2014 14:31:08 -0000 --047d7bd6ab54c34f2c04f3dcde1c Content-Type: text/plain; charset=UTF-8 I think the key thing is that it's not clear when creating a new PeerConnection whether it should make new CNAMEs or use existing ones. Compare the two scenarios below: #1: audio and video over 2 PCs to the same destination pc1 = new RTCPeerConnection(); pc2 = new RTCPeerConnection(); pc1.addStream(audioStream); pc2.addStream(videoStream); doCall(pc1); doCall(pc2); // cnames in pc1 and pc2 should be the same #2: audio call over PC1 to destination 1, followed by audio call over PC2 to destination 2 pc1 = new RTCPeerConnection(); pc1.addStream(audioStream); doCall(pc1); pc2 = new RTCPeerConnection(); pc2.addStream(audioStream); doCall(pc2); // cnames in pc1 and pc2 should be different I am inclined to make CNAMEs per-PeerConnection (i.e. enforce scenario #2 behavior) for 1.0, as it has a smaller downside. On Wed, Mar 5, 2014 at 1:37 PM, Martin Thomson wrote: > On 5 March 2014 12:44, Magnus Westerlund > wrote: > > Martin, you talked about linking in this context. I wonder if there > > really are an issue with linking as this is all in the same > > communication context. Can you please make clear your concerns? > > I'm mostly concerned about being able to communicate with multiple > people from the same page without revealing a linkage between sessions > based on cert or CNAME. It may be that we need API hooks to control > this. > > As I said, I haven't thought it through fully. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd6ab54c34f2c04f3dcde1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the key thing is that it's not clear when crea= ting a new PeerConnection whether it should make new CNAMEs or use existing= ones.

Compare the two scenarios below:

#1: audio and video over 2 PCs to the same destination
pc1 = =3D new RTCPeerConnection();
pc2 =3D new RTCPeerConnection();
pc1.addStream(audioStream);
pc2.addStream(videoStream);
doCall(pc1);
doCall(pc2);
// cnames in pc1 and pc2= should be the same

#2: audio call over PC1 to des= tination 1, followed by audio call over PC2 to destination 2
pc1 =3D new RTCPeerConnection();
pc1.addStream(audioStream);
doCall(pc1);
pc2 =3D new RTCPeerConnection();
pc2.addStream(audioStream);
doCall(pc2);
// cna= mes in pc1 and pc2 should be different

I am inclined to make CNAMEs per-PeerConnection (i.e. e= nforce scenario #2 behavior) for 1.0, as it has a smaller downside.



On Wed, Mar 5, 2014 at 1:37 PM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
On 5 March 2014 12:44, Magnus Westerlund <magnus.westerlund@ericsson.com> = wrote:
> Martin, you talked about linking in this context. I wonder if there > really are an issue with linking as this is all in the same
> communication context. Can you please make clear your concerns?

I'm mostly concerned about being able to communicate with multipl= e
people from the same page without revealing a linkage between sessions
based on cert or CNAME. =C2=A0It may be that we need API hooks to control this.

As I said, I haven't thought it through fully.

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

--047d7bd6ab54c34f2c04f3dcde1c-- From nobody Wed Mar 5 06:33:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF71A065A for ; Wed, 5 Mar 2014 06:33:34 -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 tqOMm_sKxJpW for ; Wed, 5 Mar 2014 06:33:33 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB51A063F for ; Wed, 5 Mar 2014 06:33:29 -0800 (PST) Received: (qmail 84903 invoked from network); 5 Mar 2014 14:33:25 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 9517 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Mar 2014 14:33:25 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id A9CAA18A0116; Wed, 5 Mar 2014 14:33:25 +0000 (GMT) Received: from dhcp-a471.meeting.ietf.org (dhcp-a471.meeting.ietf.org [31.133.164.113]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 46E4B18A0A60; Wed, 5 Mar 2014 14:33:25 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: tim panton In-Reply-To: Date: Wed, 5 Mar 2014 14:33:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <32D95060-6273-4804-A398-712311481E73@phonefromhere.com> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> To: Justin Uberti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6vVIFCb9XDeRH6HGyOwWlVrUzm0 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:33:34 -0000 On 5 Mar 2014, at 14:25, Justin Uberti wrote: > So there are three things here: > 1) MUST the implementation offer encrypted header extensions? (i.e. = mandatory-to-implement) > 2) MUST the implementation use encrypted header extensions? (i.e. = mandatory-to-use) > 3) MUST the implementation expose an API to control this? (i.e. no SDP = munging needed) >=20 > I think we want yes for #1, no for #2, and #3 is potentially = interesting but out of scope for 1.0. > That gives encrypted headers for audio on by default, but remote = parties can negotiate this off using RFC 6904 mechanisms. >=20 In order to agree with that I=92d need to be persuaded that there isn=92t = a known-plaintext attack risk there (e.g. detecting a muted mic therefore knowing the ulaw content of a = packet), since any weakening in DTLS also impacts the data channel and video channels = - assuming bundle. Like I say, I=92m not enough of a cryptographer to know. T. From nobody Wed Mar 5 06:36:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE461A0223 for ; Wed, 5 Mar 2014 06:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 L1RfGHQDPSPC for ; Wed, 5 Mar 2014 06:35:57 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CABC21A065A for ; Wed, 5 Mar 2014 06:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1218; q=dns/txt; s=iport; t=1394030147; x=1395239747; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SwUpwBfoNUaD4m/S14Npb/Ax5sLTngwsbwBUvJsZby4=; b=bDsPJUoxw6B19D0SGtnnxPMOvXcysJKCuEUWvUezFMVa6SkOPRtDCR1m tZ6uf1yDMplFmHD8pRl6/Eh4SoO+l+ehBR3Oy8hnbPEmBafLqSMsF/rvU XnJ7oUCoxh8rxjrHOmsZzBZ6QoiChegae/wMSbhIQQN8lCjD+u/LnPhe4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFc1F1OtJV2d/2dsb2JhbABagwaBEsELgRcWdIIlAQEBAwF5EAIBCBguMiUCBA4Fh3EIzhQXjh4zB4MkgRQBA5RSg2uSK4Mtgio X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="308293694" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 05 Mar 2014 14:35:42 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s25EZg4A008903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 14:35:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.113]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 08:35:42 -0600 From: "Cullen Jennings (fluffy)" To: tim panton Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8SfprS6duAgAACN4CAAAU4AIAAAicAgAAA8wA= Date: Wed, 5 Mar 2014 14:35:41 +0000 Message-ID: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> <32D95060-6273-4804-A398-712311481E73@phonefromhere.com> In-Reply-To: <32D95060-6273-4804-A398-712311481E73@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.132] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t9tdbdWP7TAiTsjbyJL-3bVvFwo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:36:00 -0000 On Mar 5, 2014, at 2:33 PM, tim panton wrote: >=20 > On 5 Mar 2014, at 14:25, Justin Uberti wrote: >=20 >> So there are three things here: >> 1) MUST the implementation offer encrypted header extensions? (i.e. mand= atory-to-implement) >> 2) MUST the implementation use encrypted header extensions? (i.e. mandat= ory-to-use) >> 3) MUST the implementation expose an API to control this? (i.e. no SDP m= unging needed) >>=20 >> I think we want yes for #1, no for #2, and #3 is potentially interesting= but out of scope for 1.0. >> That gives encrypted headers for audio on by default, but remote parties= can negotiate this off using RFC 6904 mechanisms. >>=20 >=20 > In order to agree with that I=92d need to be persuaded that there isn=92t= a known-plaintext attack risk there > (e.g. detecting a muted mic therefore knowing the ulaw content of a packe= t), since > any weakening in DTLS also impacts the data channel and video channels -= assuming bundle. >=20 > Like I say, I=92m not enough of a cryptographer to know. No - it does not weaken DTLS to know the plaintext (and if it did, DTLS wou= ld have series security problems )= From nobody Wed Mar 5 06:40:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABE01A021D for ; Wed, 5 Mar 2014 06:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 4Xv26ArRIUYE for ; Wed, 5 Mar 2014 06:40:25 -0800 (PST) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 479FA1A0505 for ; Wed, 5 Mar 2014 06:40:25 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id g12so1075734oah.22 for ; Wed, 05 Mar 2014 06:40:21 -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=YzFMGWcVX+wX20+Khf1j6hfpLbxphl0OJLhi1qUoA64=; b=GMWbB43hM8lN/v7XdNUMtnwK7v5rI3swrNlxQYXk34r9PY60zSx7WYQulPEZoCNviC gXe/fOUsqrFGj5UIhISKaliC7Pcwgze15HVbHsWDEhgPiRihAyBp2cGXBS9N1RzB3Hc6 m1BdFnNZfpbXhlBqcwCe7zyTn0uCzEp+7bW6ZL5FdcTosoV9hspzIBI4SDwvSXiqZFGc o+S706e4bTjeSSowmwn2s5zzeut+bi1DACVVHYpIIMprHCTOXEg0A4lnvHD3Q77uo7aQ VRl3eAWuRNq5wlr4v9VoQyzPqbzf82MDJrmqNUxHTMD92aWB2zr5N6+q2dk0nbzCdn0I XpfQ== 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=YzFMGWcVX+wX20+Khf1j6hfpLbxphl0OJLhi1qUoA64=; b=MMKTpg5OaMLLyKcl+2ZzYp6Ym4ZLVL20VFPkF6iNxJQ4xmw/BnMTi8snhMrW5ZYxHk Wz5UiD9FsHqzpkEUodObWFftnM/7H/dUNwxXPuaRCnX9JqbonPo3M7WPSHnkpk7m9R5j mD2IU8N/4mh1sDKyaPbgHZNLwQjH71jZkt3JB2N11qMOhKPLcTmUaM5Wbbzun3bERHAz eUpgYucJ11pXjNrhatBwJqV1CF2DoRowhZ668kyAuf2WTD/ecVEXi/OjJl6ooBkrhGIY uH6d++MCpTHv0Dr8ayMoeLpvtL0BIqcvxSw0VDi8StnLGbC3CCkMY5FzR5GPUuUV6gmN Arsg== X-Gm-Message-State: ALoCoQmxLATNOlTcfDLc6r0fH79g85EHzlRNFUTo1QAXE0bDfNnRl1Q6BI+tKpNqgDPC1N1lwPNwpsT2juylJZAifduhCeCrOMmJCYdE7n0EpfBYUhVIasOD0fecu3TMZUwo/GJT3KEFTi72EAlv+5Kq5jNnV0CXams5BRX0VpohHd7nEZ+CMdY/2GMnGzrHc+ygJhBgJBld X-Received: by 10.60.102.37 with SMTP id fl5mr643330oeb.65.1394030421499; Wed, 05 Mar 2014 06:40:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 06:40:01 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> <32D95060-6273-4804-A398-712311481E73@phonefromhere.com> From: Justin Uberti Date: Wed, 5 Mar 2014 14:40:01 +0000 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=089e0111bce0147fc204f3dd009a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sPK3yBXV-460MF9LSSS5JFASTto Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:40:27 -0000 --089e0111bce0147fc204f3dd009a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree with Cullen (and FWIW the SRTP encryption uses keys vended from the DTLS master secret, so I think even if you are able to crack the SRTP crypto it would not be trivial to go backwards up to the DTLS key material) On Wed, Mar 5, 2014 at 2:35 PM, Cullen Jennings (fluffy) wrote: > > On Mar 5, 2014, at 2:33 PM, tim panton wrote: > > > > > On 5 Mar 2014, at 14:25, Justin Uberti wrote: > > > >> So there are three things here: > >> 1) MUST the implementation offer encrypted header extensions? (i.e. > mandatory-to-implement) > >> 2) MUST the implementation use encrypted header extensions? (i.e. > mandatory-to-use) > >> 3) MUST the implementation expose an API to control this? (i.e. no SDP > munging needed) > >> > >> I think we want yes for #1, no for #2, and #3 is potentially > interesting but out of scope for 1.0. > >> That gives encrypted headers for audio on by default, but remote > parties can negotiate this off using RFC 6904 mechanisms. > >> > > > > In order to agree with that I=E2=80=99d need to be persuaded that there= isn=E2=80=99t a > known-plaintext attack risk there > > (e.g. detecting a muted mic therefore knowing the ulaw content of a > packet), since > > any weakening in DTLS also impacts the data channel and video channels > - assuming bundle. > > > > Like I say, I=E2=80=99m not enough of a cryptographer to know. > > No - it does not weaken DTLS to know the plaintext (and if it did, DTLS > would have series security problems ) --089e0111bce0147fc204f3dd009a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with Cullen (and FWIW the SRTP encryption uses keys = vended from the DTLS master secret, so I think even if you are able to crac= k the SRTP crypto it would not be trivial to go backwards up to the DTLS ke= y material)


On Wed, Mar 5= , 2014 at 2:35 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

On Mar 5, 2014, at 2:33 PM, tim panton <tim@phonefromhere.com> wrote:

>
> On 5 Mar 2014, at 14:25, Justin Uberti <juberti@google.com> wrote:
>
>> So there are three things here:
>> 1) MUST the implementation offer encrypted header extensions? (i.e= . mandatory-to-implement)
>> 2) MUST the implementation use encrypted header extensions? (i.e. = mandatory-to-use)
>> 3) MUST the implementation expose an API to control this? (i.e. no= SDP munging needed)
>>
>> I think we want yes for #1, no for #2, and #3 is potentially inter= esting but out of scope for 1.0.
>> That gives encrypted headers for audio on by default, but remote p= arties can negotiate this off using RFC 6904 mechanisms.
>>
>
> In order to agree with that I=E2=80=99d need to be persuaded that ther= e isn=E2=80=99t a known-plaintext attack risk there
> (e.g. detecting a muted mic therefore knowing the ulaw content of a pa= cket), since
> any weakening =C2=A0in DTLS also impacts the data channel and video ch= annels - assuming bundle.
>
> Like I say, I=E2=80=99m not enough of a cryptographer to know.

No - it does not weaken DTLS to know the plaintext (and if it d= id, DTLS would have series security problems )

--089e0111bce0147fc204f3dd009a-- From nobody Wed Mar 5 06:42:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABBD1A0691 for ; Wed, 5 Mar 2014 06:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 BPTMSpRedRcQ for ; Wed, 5 Mar 2014 06:41:58 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2733F1A068A for ; Wed, 5 Mar 2014 06:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=962; q=dns/txt; s=iport; t=1394030514; x=1395240114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3XwglVs3VZy7lsV9Q8YEuUJj+KeFBb/YxFmQ3FmOhNY=; b=RHNNUQUiVGVuwRaY7rp/4CglZte1eAgIK2ux0lPbaJm6nOZHTPJ8BSyY LJr+Akyj1XfTfML3oqdas9TP9OqYATHSzZtdrzHQFaGv8tCOUmFNIDxic dqY/yvdjXrRAWwHLP2QBFjKm8HDuf83eoC/Q9hWi/hcTt2VIKLKLbNWnF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMA2F1OtJXG//2dsb2JhbABagwaBEsELgRcWdIIlAQEBAwF5BQsCAQgOODIlAgQOBYdxCM4XF44eMweDJIEUAQOYPZIrgy2CKg X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="25105304" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-4.cisco.com with ESMTP; 05 Mar 2014 14:41:54 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s25EfsCQ027517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 14:41:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.113]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 08:41:54 -0600 From: "Cullen Jennings (fluffy)" To: Justin Uberti Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8SfprS6duAgAACN4CAAAU4AIAABNeA Date: Wed, 5 Mar 2014 14:41:53 +0000 Message-ID: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.132] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5YYftHTxIXf4DQTauaDrHDj1Zxk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:41:59 -0000 On Mar 5, 2014, at 2:25 PM, Justin Uberti wrote: > So there are three things here: > 1) MUST the implementation offer encrypted header extensions? (i.e. manda= tory-to-implement) I=92m fine with yes > 2) MUST the implementation use encrypted header extensions? (i.e. mandato= ry-to-use) I think this needs to be No. Never mind my current use case - if the far en= d does not negotiate RFC 6094 with the browser, the media and headers shoul= d not fail.=20 > 3) MUST the implementation expose an API to control this? (i.e. no SDP mu= nging needed) I prefer control surfaces to SDP munging but as you say, I could live with = SDP munging in 1.0=20 >=20 > I think we want yes for #1, no for #2, and #3 is potentially interesting = but out of scope for 1.0. > That gives encrypted headers for audio on by default, but remote parties = can negotiate this off using RFC 6904 mechanisms. >=20 seems workable=20 From nobody Wed Mar 5 06:52:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F011A0245 for ; Wed, 5 Mar 2014 06:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwLUPMY8xpeu for ; Wed, 5 Mar 2014 06:52:19 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 8907A1A025A for ; Wed, 5 Mar 2014 06:52:18 -0800 (PST) Received: (qmail 7463 invoked from network); 5 Mar 2014 14:52:14 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10002 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Mar 2014 14:52:14 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 33B5B18A0A60; Wed, 5 Mar 2014 14:52:14 +0000 (GMT) Received: from dhcp-a471.meeting.ietf.org (dhcp-a471.meeting.ietf.org [31.133.164.113]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id F3BCB18A03A0; Wed, 5 Mar 2014 14:52:13 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: tim panton In-Reply-To: Date: Wed, 5 Mar 2014 14:52:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> <32D95060-6273-4804-A398-712311481E73@phonefromhere.com> To: Justin Uberti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kzn4YpdXZE96Sy4_HzEnmRF6ES0 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:52:29 -0000 On 5 Mar 2014, at 14:40, Justin Uberti wrote: > Agree with Cullen (and FWIW the SRTP encryption uses keys vended from = the DTLS master secret, so I think even if you are able to crack the = SRTP crypto it would not be trivial to go backwards up to the DTLS key = material) >=20 >=20 Yep, agreed, my mistake. T. From nobody Wed Mar 5 06:57:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7175D1A06FE for ; Wed, 5 Mar 2014 06:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 iyv1zsdmfg5E for ; Wed, 5 Mar 2014 06:57:13 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id AD90C1A025A for ; Wed, 5 Mar 2014 06:57:13 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wp18so1119453obc.9 for ; Wed, 05 Mar 2014 06:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=J9dfvgQUZnIA08VgZVka9E/4fRDl3BK0NQ6EC+GmFCM=; b=YffJvBoMH71eibdGrArPY7rx0vD81QfGPSCSJc6oTQWWT56Gbvuzz5K0/GOMiGR7jI 3gSYLGjlTRhIK1K9wc1FRzDZ8ZgneRQlxMpsb51zmHXm5bh6Kd48PiFqkwOrFmc9ERmo vXY1k5F2TEhqrCd1J4232NAy98F6lJ4j68UKqIQbstm3WVJ9e7QS1rOHgXmoygXbbpgR 7pNNd+5ETueX7SSo8BCjw/GztY4ocMBvnh3FD5Y0otmt42tt9f2h0dcmYVGWTUAAUTqM 4tYiJfLzYfCIXh1BQhoIJyEyHojY/h8y4EQyQ7wS6+GuTVxGJ9PuFy/nuuKzdghOGxxD CldQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=J9dfvgQUZnIA08VgZVka9E/4fRDl3BK0NQ6EC+GmFCM=; b=VxQCZE9I4V1WlKPmddQRFWx+gBr3pCq53X+wCND7Hb7NhUm5fZt6Oup+orBDgpWQ2t PnrtsfnLoO0rpi/HDG18qKdmIZsUWeg8PtcGnXIHwDEyChrkSc7TFN8SUcKWZxD1KgTQ mh2VbacVXrZMA5Pj8ZzFif0+dhqL8g+6AbIlw3uPJAr0/dqlJeSqBzko8Kwf2bhZhQUy JXOGibPEf9jWb3KXbU3RKoEsyjX07FLqvQjsBsAJB4e1xWNr6WPT6LczHhIhCxZU4hI/ +wxByUD+q0/bE7fbKVs2x85dr8NwuAeSHMuleVxijuO79UHTUY9KQ4Snp1jPYRBFwTHy Spcw== X-Gm-Message-State: ALoCoQn6hemHyNhRuafu8Yp6WStsPwusqlVWtO2TXarWQTq15MnG5gF+cZyS1gdQ3dey8Gys2hxz16pH4dW+YjMOQp6cra0GtulmkTNnHhiS4doc7AzzjXgb/fd1ppIAztLpHd/cN5NrDfW7UidksZLvVV/gZHsOM6LlICXanNRqLBYLz3HqtUQVPd61HwCI7aeMQBzaqUOr X-Received: by 10.182.107.232 with SMTP id hf8mr765478obb.75.1394031429831; Wed, 05 Mar 2014 06:57:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 06:56:49 -0800 (PST) From: Justin Uberti Date: Wed, 5 Mar 2014 14:56:49 +0000 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6f9c2f5c3804f3dd3cff Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EmVQxzJ2aXVSkMd0G5K2gX-CP2A Subject: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 14:57:15 -0000 --089e013c6f9c2f5c3804f3dd3cff Content-Type: text/plain; charset=UTF-8 >From the transports draft, S 3.4: In order to deal with situations where one party is on an IPv4 network and the other party is on an IPv6 network, TURN extensions for IPv6 [RFC6156 ] MUST be supported. I think this needs clarification. Does this mean that we should allocate v6 candidates from all v4 interfaces (for compat with v6-only endpoints), as well as allocate v4 candidates from all v6 interfaces (for compat with v4-only endpoints), and if so, which path (v6-to-TURN or v6-from-TURN) should be prioritized? Note also that these v4->v6 or v6->v4 allocations will be dependent on the SSODA work being discussed in TRAM, since this is the only way to allocate v4 and v6 TURN from a single host candidate. Also worth noting: With the current default settings, a single STUN and TURN server, and assuming a dual-stack host with two network interfaces, a PeerConnection with audio, video, and data will generate 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * 2 (IP protocols) = 80 candidates --089e013c6f9c2f5c3804f3dd3cff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
From the transports draft, S 3.4:


   In order to deal with situations where one part=
y is on an IPv4
   network and the other party is on an IPv6 network, TURN extensions
   for IPv6 [RFC6156<=
/a>] MUST be supported.


I thin=
k this needs clarification. Does this mean that we should allocate v6 candi=
dates from all v4 interfaces (for compat with v6-only endpoints), as well a=
s allocate v4 candidates from all v6 interfaces (for compat with v4-only en=
dpoints), and if so, which path (v6-to-TURN or v6-from-TURN) should be prio=
ritized?


Note also that these v4->v6 =
or v6->v4 allocations will be dependent on the SSODA work being discusse=
d in TRAM, since this is the only way to allocate v4 and v6 TURN from a sin=
gle host candidate.





Also worth noting:
=

With the current=
 default settings, a single STUN and TURN server, and assuming a dual-stack=
 host with two network interfaces, a PeerConnection with audio, video, and =
data will generate



5 (components) *=
 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * 2 (IP protocols) =3D =
80 candidates
--089e013c6f9c2f5c3804f3dd3cff-- From nobody Wed Mar 5 06:58:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F611A025A for ; Wed, 5 Mar 2014 06:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 fx3SsSIwkvtD for ; Wed, 5 Mar 2014 06:58:51 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id F410F1A0527 for ; Wed, 5 Mar 2014 06:58:50 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id m1so1115782oag.7 for ; Wed, 05 Mar 2014 06:58:47 -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=rwyr+6FUcAVBXR1TnJYHjQVcykj3AmF8rD2M2bf7M74=; b=O1Su0z3+9Ic6QkyvVaAcJH6ap6WF+cveyK7Gjj9NrTfA7gqxHWYsUNHz7qTOicMx6b AODk21zTRXtFN1UD4ga5aNcsBpLZsjEeAaS3L2LjBOvZWHzYimoHI4ZznuXLl/j2AWTE 780Pn2szyQ4otGOkf8aTzE9WohUl4Gi/TpkZvbgwtTayzU3h1nLnR4N2PL64A56yJ1EE iallKqKuJVBzfsXoUBIxfHBZ2iFiFDuiXSNgYC0C+e44qv1w0+OnT5YWkRPNJzVqeff5 nRkktcJ8OkqeSG6SyDUySEjxOp7glWjvV0t4QrlFz0G64gQgAUeawJer/xhBTihqO/QJ Clng== 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=rwyr+6FUcAVBXR1TnJYHjQVcykj3AmF8rD2M2bf7M74=; b=O0pRc4ZGWm1TIuxKQ56OlMH7MWLP4WkRICYw1i02+DyyLUbVCFkAImZD618kZatOq9 DsG//v7kCm0CvPdiclHqGF4us6NBKv0T24DSVMdIA1wwSwnB0Zm6ohcQrUqqXsDIeUCk I3c1C32c0GxQDUpO8KOMD6w58yAh57BXu0M0lVD0IgT3mKP0g6XI8YqTnpZljxebc0Op VoTNRce8w1+lT6NSh4YZHHS9/CAROKkC5w/boB6KaRwepH2k1nhu0Pon5cx4ZecfSnAh p9gJSZmAC+VvF4nPn93w1IxtgEKzW/2jR3J8gW61BnbSF0zW3QNOKnhAWrMfS/ktQwmh rnWg== X-Gm-Message-State: ALoCoQmP24+76R3KQM1Twbr2WPP79jQ/ee9p7n6htWwU21+Gtm0zjHM5XcLlZPd37XfowZYspyERnq9FRrNlqyH3WGOzpraFFGPmfE2zR2S61bShXLMpajdeX7YcQyvjvRCb/d6FNaAnMQ+doh7z/LOWtXrTXbZOYMd3aVsKrpD18o2IVPBgONHN0NrRrwe9rtfgzHbi6fOg X-Received: by 10.60.116.166 with SMTP id jx6mr863481oeb.22.1394031527078; Wed, 05 Mar 2014 06:58:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 06:58:27 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> From: Justin Uberti Date: Wed, 5 Mar 2014 14:58:27 +0000 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=089e0129534efa4cfb04f3dd4110 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NASbG88qvwNWFahYhWi5l_LLDwY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 14:58:57 -0000 --089e0129534efa4cfb04f3dd4110 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 5, 2014 at 2:41 PM, Cullen Jennings (fluffy) wrote: > > > On Mar 5, 2014, at 2:25 PM, Justin Uberti wrote: > > > So there are three things here: > > 1) MUST the implementation offer encrypted header extensions? (i.e. > mandatory-to-implement) > I=E2=80=99m fine with yes > > > 2) MUST the implementation use encrypted header extensions? (i.e. > mandatory-to-use) > I think this needs to be No. Never mind my current use case - if the far > end does not negotiate RFC 6094 with the browser, the media and headers > should not fail. > > > 3) MUST the implementation expose an API to control this? (i.e. no SDP > munging needed) > I prefer control surfaces to SDP munging but as you say, I could live wit= h > SDP munging in 1.0 > > > > > I think we want yes for #1, no for #2, and #3 is potentially interestin= g > but out of scope for 1.0. > > That gives encrypted headers for audio on by default, but remote partie= s > can negotiate this off using RFC 6904 mechanisms. > > > > > seems workable > Where should this be codified (in which I-D?) --089e0129534efa4cfb04f3dd4110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 5, 2014 at 2:41 PM, Cullen Jennings (fluffy) <fluffy@c= isco.com> wrote:


On Mar 5, 2014, at 2:25 PM, Justin Uberti <juberti@google.com> wrote:

> So there are three things here:
> 1) MUST the implementation offer encrypted header extensions? (i.e. ma= ndatory-to-implement)
I=E2=80=99m fine with yes

> 2) MUST the implementation use encrypted header extensions? (i.e. mand= atory-to-use)
I think this needs to be No. Never mind my current use case - if the = far end does not negotiate RFC 6094 with the browser, the media and headers= should not fail.

> 3) MUST the implementation expose an API to control this? (i.e. no SDP= munging needed)
I prefer control surfaces to SDP munging but as you say, I could live= with SDP munging in 1.0

>
> I think we want yes for #1, no for #2, and #3 is potentially interesti= ng but out of scope for 1.0.
> That gives encrypted headers for audio on by default, but remote parti= es can negotiate this off using RFC 6904 mechanisms.
>


seems workable

Where should this = be codified (in which I-D?)=C2=A0

--089e0129534efa4cfb04f3dd4110-- From nobody Wed Mar 5 07:00:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4F21A0039 for ; Wed, 5 Mar 2014 07:00:37 -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 6Q4BjJH5vqUd for ; Wed, 5 Mar 2014 07:00:36 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1981A0171 for ; Wed, 5 Mar 2014 07:00:35 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id my13so471179bkb.36 for ; Wed, 05 Mar 2014 07:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bNFjy7yoatSZUuwwHSVTi/DxqDYE3xxE3MeBz10Zu3I=; b=BGx14Cuod5UFWjowAZvgOiD8wr0vfs0Lc6Msf0M9LOmnp63uTWohMcJZvb25VciGLX oGAIrERjZEtOwqFPedjyyiqB/U5rFdHLOYSwJKRSvHSbtx4eGw1riJnc3Lxbeu4u60Bk xYJvqFKGpYXhO4ojm7fzky8Hq4cGMOrr55gD8RjalJ5WtEDSmNboss08cZOKat2BDgCq wQf6QvhF6tL43wuF3IK8uTU4Vd2d1BKIErs+alpnUsesSh94EFrmOoRPiR1czPaUOV9V WExLIofzrCER36HtbakEla27o/YA58EKaGPGeunrb+RP6w8lEG3af1Yv/ASwzQ+qxx/N 7usA== X-Received: by 10.204.76.7 with SMTP id a7mr2117008bkk.17.1394031632098; Wed, 05 Mar 2014 07:00:32 -0800 (PST) Received: from [192.168.1.35] (105.Red-81-33-134.dynamicIP.rima-tde.net. [81.33.134.105]) by mx.google.com with ESMTPSA id dj6sm5245054bkc.5.2014.03.05.07.00.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 07:00:30 -0800 (PST) Message-ID: <53173C11.8060504@gmail.com> Date: Wed, 05 Mar 2014 16:00:33 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> In-Reply-To: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Zr_2C24HgMt7blHVIi9xbDB9MVk Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 15:00:37 -0000 El 05/03/2014 13:32, Cullen Jennings (fluffy) escribió: > I am opposed to mandating that Client-to-Mixer Audio Level RTP header is REQUIRED to be encrypted. It means that we can not really build conferencing system where the mixers do not have access to decrypt the media. > > Hi Cullen, I am not sure I am following you. AFAIK DTLS is only possible to be setup between two peers, so in a multiconference solution the mixer will anyway have to establish a DTLS/SRTP session which each peer and decrypt/encrypt before sending to any of participants in the conference. In case of a full meshed conference, there is no need of a mixer at all, and the logic could be directly implemented on each of the endpoints. Am I missing something? Please correct me if I am wrong. Best regards Sergio From nobody Wed Mar 5 07:02:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776F41A01B3 for ; Wed, 5 Mar 2014 07:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 hlsDs12jue2s for ; Wed, 5 Mar 2014 07:02:52 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id D0A741A0072 for ; Wed, 5 Mar 2014 07:02:52 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so1137892oag.28 for ; Wed, 05 Mar 2014 07:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=40NwcZZt0LtUBiZyFhqqbNEwg1KD5ki0xsNpYYRGBTQ=; b=FsUluCKoU5yHg0yremFKZTS/YN8I6XuzKQ5+LC7JFn+aq63wBB0uqan++H+hVNltyM zlIzF4oWG96dWEg5EZ872ohH4XqQU9T0Js7jGLt1pF4Ctz8jBtQBFe3+s9z3yaii1jFK CJhZo9eAfTNir8dIUdiLIx9ViyTVWVArw1DBOcNpoBX5+rvharoeu/7oH0bKAPfTWczr peZgDbHserOftO4TuyKYbzZ21X3pEWzusW1k3c65WfQNjZVlA92RyBkmXbIlkfRThI/n D7j2kGtzlvXqBXV3oGogoy9A3LWbvki/MdYZuUA5hok6oiIPUVsPXriUCyFVvDyaTmXZ 1EBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=40NwcZZt0LtUBiZyFhqqbNEwg1KD5ki0xsNpYYRGBTQ=; b=bx8GVWAByRIrzlwUK8S44uF2p8CToMWtSml87rB5uYKHaCCYqaaULEkEzeoPf/7Dcj WzE4YuMhZuGE9fv936bY05LB0ppvlIbHKi5dnBeDvOKygD4KOKxTzWFxqWG4qmkyoKY5 4wf+N28FgTiupByQQNMe7ZwkuXqoE7A05y9cBUgNJgelTGcgC8qsXIo1acmvPAJ+7lhq bqF2BOUrjdaEEcNf+tu3by++CaAbNaFIEIjKYtXGxclQ5DFrpa7WbfJjXkj5eCIhnZJU RFo0esVCO4bKxAUWAe7bg1G9IXsifOyDZdwe2TQhbFpIIDFaIUzeP2bWAkWzpBk+EXJD V8ww== X-Gm-Message-State: ALoCoQn0WrXup7NlXpZbg2ciFxqEGFVA7d6Rel0THqaBwZ+vmFiyMWN3mV25g3og+5cl4hXHZktbXu+BqIYKlOsqE3MWy5CSZERr75pkNy7n6ALjoEoCAP/5kOpKW22bieZsRKTwUdseOZEF7tjxTJoBb0PiYtKWoZHll/W5KeeQZoZUI9Y8kAlak9cS/BddVsjRKOfXMK4w X-Received: by 10.60.102.37 with SMTP id fl5mr736057oeb.65.1394031769157; Wed, 05 Mar 2014 07:02:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 07:02:29 -0800 (PST) From: Justin Uberti Date: Wed, 5 Mar 2014 15:02:29 +0000 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0111bce0681e4e04f3dd50fd Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ExJp9cCK-684JLgKTesgoShncUc Subject: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 15:02:54 -0000 --089e0111bce0681e4e04f3dd50fd Content-Type: text/plain; charset=UTF-8 >From the transports draft, Section 3.4: TURN TCP candidates [RFC6062 ] SHOULD be supported; this allows applications to achieve peer-to-peer communication when both parties are behind UDP-blocking firewalls using a single TURN server. (In this case, one can also achieve communication using two TURN servers that use TCP between the server and the client, and UDP between the TURN servers.) I don't think we want to do this. The optimization of having a single vs two TURN servers in the .09% case is not worth the implementation or runtime cost of allocating TURN TCP candidates. It requires a TCP connection to the TURN server, which we would otherwise not do except in fallback cases. --089e0111bce0681e4e04f3dd50fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the transports draft, Section 3.4:

   TURN TCP candidates [RFC6062] SHOULD be supported; this allow=
s
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

I don't think we want to do this. The=
 optimization of having a single vs two TURN servers in the .09% case is no=
t worth the implementation or runtime cost of allocating TURN TCP candidate=
s. It requires a TCP connection to the TURN server, which we would otherwis=
e not do except in fallback cases.
--089e0111bce0681e4e04f3dd50fd-- From nobody Wed Mar 5 07:04:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05871A05C3 for ; Wed, 5 Mar 2014 07:04:54 -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 yTMJrP13f7jE for ; Wed, 5 Mar 2014 07:04:53 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9551A063E for ; Wed, 5 Mar 2014 07:04:50 -0800 (PST) Received: (qmail 20816 invoked from network); 5 Mar 2014 15:04:46 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10286 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Mar 2014 15:04:46 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 3B7AE18A0A60; Wed, 5 Mar 2014 15:04:46 +0000 (GMT) Received: from dhcp-a471.meeting.ietf.org (dhcp-a471.meeting.ietf.org [31.133.164.113]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 101FE18A05C1; Wed, 5 Mar 2014 15:04:46 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: tim panton In-Reply-To: Date: Wed, 5 Mar 2014 15:04:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7A408D4F-80C0-4C17-835E-C740036B6B76@phonefromhere.com> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gsntHQwL-L5-zeIqvj55fCYotvo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 15:04:54 -0000 On 5 Mar 2014, at 14:41, Cullen Jennings (fluffy) = wrote: >=20 >=20 > On Mar 5, 2014, at 2:25 PM, Justin Uberti wrote: >=20 >> So there are three things here: >> 1) MUST the implementation offer encrypted header extensions? (i.e. = mandatory-to-implement) > I=92m fine with yes >=20 >> 2) MUST the implementation use encrypted header extensions? (i.e. = mandatory-to-use) > I think this needs to be No. Never mind my current use case - if the = far end does not negotiate RFC 6094 with the browser, the media and = headers should not fail.=20 >=20 >> 3) MUST the implementation expose an API to control this? (i.e. no = SDP munging needed) > I prefer control surfaces to SDP munging but as you say, I could live = with SDP munging in 1.0=20 >=20 >>=20 >> I think we want yes for #1, no for #2, and #3 is potentially = interesting but out of scope for 1.0. >> That gives encrypted headers for audio on by default, but remote = parties can negotiate this off using RFC 6904 mechanisms. >>=20 >=20 >=20 > seems workable=20 For the record, I still don=92t like the idea that the far end can = bid-down encryption on this header, but I suppose if my app cares it = will have to not offer to do that header extension at all. (Hopefully it = is a malleable SDP field). Tim.= From nobody Wed Mar 5 07:21:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCD1A022E for ; Wed, 5 Mar 2014 07:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 JV9U-UmA2jFJ for ; Wed, 5 Mar 2014 07:21:06 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 589201A01E1 for ; Wed, 5 Mar 2014 07:21:06 -0800 (PST) Received: from porto.nomis80.org (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 777114040A for ; Wed, 5 Mar 2014 10:21:02 -0500 (EST) Message-ID: <531740DD.5030700@viagenie.ca> Date: Wed, 05 Mar 2014 15:21:01 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bSUbnfh43hM2Q4hF6bxwA41vj8A Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 15:21:09 -0000 Le 2014-03-05 14:56, Justin Uberti a écrit : > I think this needs clarification. Does this mean that we should allocate v6 candidates from all v4 interfaces (for compat with v6-only endpoints), as well as allocate v4 candidates from all v6 interfaces (for compat with v4-only endpoints), and if so, which path (v6-to-TURN or v6-from-TURN) should be prioritized? You must always allocate both v4 and v6 relayed candidates, irrespective of what other candidates you have. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 5 07:21:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B691A0270 for ; Wed, 5 Mar 2014 07:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 0NJlF4CN9OhD for ; Wed, 5 Mar 2014 07:21:14 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 08A981A014F for ; Wed, 5 Mar 2014 07:21:13 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-8a-531740e58efc Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F7.58.23809.5E047135; Wed, 5 Mar 2014 16:21:09 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.220]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 16:21:08 +0100 From: John Mattsson To: "Cullen Jennings (fluffy)" , tim panton Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8SfprSdIKAgAAB5oCAABTlAA== Date: Wed, 5 Mar 2014 15:21:07 +0000 Message-ID: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> In-Reply-To: <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <7C09A8FC97FB634DB2B5FF0198AD03F4@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje5TB/Fgg+8vTSw6JrNZrP3Xzm5x cfstRgdmjym/N7J6LFnyk8ljyaRGtgDmKC6blNSczLLUIn27BK6M7Zu3Mhb8UqnYsCKkgbFB pYuRk0NCwERi77+TTBC2mMSFe+vZQGwhgUOMErdX5HQxcgHZixkl5i9cCVbEJmAgMXdPA1iR iEC4xMd9f5lBbGYBdYk7i8+xg9jCAkESU9omAMU5gGqCJdqaRCDKnSSW729jBLFZBFQkVj56 BVbOK2AmcWbNIRaIvasYJSZvNASxOQVsJW7P7gQbzwh02/dTa5ggVolL3HoyH+pmAYkle84z Q9iiEi8f/2MFsUUF9CTuPZrLAhFXklh7eDsLyDnMApoS63fpQ4yxlpi+/BoLhK0oMaX7IdQ5 ghInZz5hmcAoMQvJtlkI3bOQdM9C0j0LSfcCRtZVjOy5iZk56eVGmxiBUXdwy2/VHYx3zokc YpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OM0gpzZungeb1O05fs3zbJ 6TrbFYEv73iPmiYfuFSdOXF60MaNt5d3Ovk2XyyTW//im3PnzhObw5W/2vkeirJdbx20/+Ry I8t9Gf5zbrcnCMSyB09UdXfJr9RfvfYzp3/cwc7PaWu4U4xbbz80/nTE9bwF64tFJr7PzXWr Tp/REv9avXHvsZ1KLMUZiYZazEXFiQDxwVoGiAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MKtUgR8UZG1OWvhOyM0ycTkHjas Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 15:21:17 -0000 DQoNCk9uIDA1LzAzLzE0IDE0OjA1LCAiQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIiA8Zmx1ZmZ5 QGNpc2NvLmNvbT4gd3JvdGU6DQoNCj4NCj5XZWxsIGlmIHBlb3BsZSBkb27igJl0IHdhbnQgdG8g YWxsb3cgdGhlIGFwcGxpY2F0aW9uIHRvIGNob29zZSB0byBlbmNyeXB0DQo+dGhpcyBoZWFkZXIg b3Igbm90LCBJIHdpbGwgYmUgYXJndWluZyBmb3IgTVVTVCBOT1QgZW5jcnlwdCB0aGUgUlRQDQo+ aGVhZGVycyAtIGFsbCBvZiB0aGVtLg0KPg0KPkEgcmVjdXJyaW5nIHRoZW1lIGF0IElFVEYgaXMg dGhhdCBwZW9wbGUgdHJ5aW5nIHRvIHByb3RlY3QgRTJFIHByaXZhY3ksDQo+ZG8gdGhpbmdzIHRo YXQgcmVzdWx0IGluIHRoZSByZWFsIHdvcmxkIGhhdmluZyB0aGUgb25seSB3YXkgdGhleSBjYW4N Cj5idWlsZCBhcHBsaWNhdGlvbnMgaXMgdG8gYnVpbGQgbWlkZGxlIGJveGVzIHRoYXQgcHJldGVu ZCB0byB0byBiZSBhbiBlbmQNCj50byB0aGUgdGhpbmdzIG9uIGJvdGggc2lkZXMuIFRoaXMgbWVh bnMgdGhhdCB0aGUgbWlkZGxlIGJveGVzIGVuZCB1cCB3aXRoDQo+MTAwJSBhYmlsaXR5IHRvIGNo YW5nZSBldmVyeXRoaW5nIGFuZCB3ZSBsb29zZSBhbGwgdGhlIHByb3RlY3Rpb24gd2UNCj5ob3Bl ZCB0byBnZXQgd2l0aCBFMkUgc2VjdXJpdHkuDQoNClllcywgYW5kIEkgdGhpbmsgdGhpcyBhbGwt b3Itbm90aGluZyBwcm9ibGVtIGlzIGdvaW5nIHRvIHBvcCB1cCBhIGxvdCBtb3JlDQppbiB0aGUg ZnV0dXJlLiBJIHRoaW5rIEN1bGxlbuKAmXMgY29uZmVyZW5jaW5nIHVzZSBjYXNlIGlzIGEgZ29v ZCBleGFtcGxlDQp3aGVyZSBpdCB3b3VsZCBoYXZlIGJlZW4gZ29vZCB0byBiZSBhYmxlIHRvIGVu Y3J5cHQgbWVkaWEgY2xpZW50LXRvLWNsaWVudA0KYnV0IGNlcnRhaW4gcnRwIGhlYWRlcnMgY2xp ZW50LXRvLW1peGVyIChvcHRpbWFsbHkgd2l0aCBpbnRlZ3JpdHkgc3RpbGwNCmJlaW5nIGNsaWVu dC10by1jbGllbnQpLg0KDQpKb2huDQoNCj4gDQo+DQo+DQo+T24gTWFyIDUsIDIwMTQsIGF0IDE6 NTkgUE0sIHRpbSBwYW50b24gPHRpbUBwaG9uZWZyb21oZXJlLmNvbT4gd3JvdGU6DQo+DQo+PiAN Cj4+IE9uIDUgTWFyIDIwMTQsIGF0IDEyOjMyLCBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSkgPGZs dWZmeUBjaXNjby5jb20+DQo+Pndyb3RlOg0KPj4gDQo+Pj4gDQo+Pj4gSSBhbSBvcHBvc2VkIHRv IG1hbmRhdGluZyB0aGF0IENsaWVudC10by1NaXhlciBBdWRpbyBMZXZlbCBSVFAgaGVhZGVyDQo+ Pj5pcyBSRVFVSVJFRCB0byBiZSBlbmNyeXB0ZWQuIEl0IG1lYW5zIHRoYXQgd2UgY2FuIG5vdCBy ZWFsbHkgYnVpbGQNCj4+PmNvbmZlcmVuY2luZyBzeXN0ZW0gd2hlcmUgdGhlIG1peGVycyBkbyBu b3QgaGF2ZSBhY2Nlc3MgdG8gZGVjcnlwdCB0aGUNCj4+Pm1lZGlhLg0KPj4gDQo+PiBJIGhhdmUg dG8gYXNrOg0KPj4gRG9lcyB0aGF0IG1hdHRlciBlbm91Z2ggdG8gd2Vha2VuIHVzZXIgc2VjdXJp dHkgZm9yIGV2ZXJ5b25lIGVsc2U/DQo+PiANCj4+IA0KPj4+IA0KPj4+IEkgd291bGQgbGlrZSB0 byBwcm9wb3NlIHRoYXQgdGhlIEpTIGFwcGxpY2F0aW9uIGNhbiBjb250cm9sICBpZiB0aGUNCj4+ PmhlYWRlciBpcyBlbmNyeXB0ZWQgb3Igbm90Lg0KPj4gDQo+PiBJIGFtIGRlZXBseSB1bmNvbWZv cnRhYmxlIGFib3V0IHRoYXQuIEkgYW0gbm90IGEgZ29vZCBlbm91Z2gNCj4+Y3J5cHRvZ3JhcGhl ciB0byBrbm93LCBidXQgbXkgaW5zdGluY3QNCj4+IGlzIHRoYXQgZXhwb3NpbmcgdGhlIGZhY3Qg dGhhdCAoZm9yIGV4YW1wbGUpIG1vc3Qgb2YgdGhlIHRvcCBiaXRzIG9mDQo+PnRoZSB1bGF3IGRh dGEgYXJlIHplcm9zIGluIHRoaXMgcGFja2V0DQo+PiBtdXN0IGJlIGEgcmlzay4NCj4+IA0KPj4g SeKAmW0gcHJldHR5IGNvbmZpZGVudCB0aGF0IG9uZSBjb3VsZCBkZXRlY3QgdGhlIHBpdGNoIG9m IHRoZSBzcGVha2VyIGFuZA0KPj5wcm9iYWJseSBmaW5nZXJwcmludCB0aGF0IGRvd24NCj4+IHRv IGluZGl2aWR1YWxzIG9yIGxhbmd1YWdlcyB3aXRoIGVub3VnaCBkYXRhLg0KPj4gDQo+Pj4gDQo+ Pj4gSSBhbSBhd2FyZSBvZiB0aGUgcGFwZXIgdGhhdCBzdWdnZXN0cyB0aGVzZSBhdWRpbyBsZXZl bHMgY2FuIHJldmVhbA0KPj4+dGhlIGNvbnRlbnRzIG9mIHRoZSBjb252ZXJzYXRpb24uIFRoZXJl IGlzIHNvbWUgZWxlbWVudCBvZiB0cnV0aCB0bw0KPj4+dGhpcy4gVGhlcmUgaXMgYWxzbyBzb21l IGVsZW1lbnQgb2YgdHJ1dGggdG8gdGhlIHBvaW50IHRoYXQgaWYgdGhpcyB3YXMNCj4+PnRydWUs IHNwZWVjaCByZWNvZ25pdGlvbiBzeXN0ZW0gd291bGQgd29yayBiZXR0ZXIgdGhhbiB0aGV5IGRv Lg0KPj4+RW5jcnlwdGluZyB0aGlzIG9yIG5vdCBpcyBhIHJpc2sgdGhhdCB0aGUgYXBwbGljYXRp b24gdXNpbmcgdGhlIGhlYWRlcg0KPj4+ZXh0ZW5zaW9uIG5lZWRzIHRvIGV2YWx1YXRlLCBhbmQg V2ViUlRDIHN5c3RlbSBuZWVkcyB0byBwcm92aWRlIHRoZQ0KPj4+YXBwbGljYXRpb25zIHdpdGgg YSBjb250cm9sIHN1cmZhY2VzIHRoYXQgYWxsb3dzIHRoZW0gdG8gdXNlIHRoaXMgaW4NCj4+PnRo ZSB3YXkgdGhlIGFwcGxpY2F0aW9ucyBkZXNpcmVzLg0KPj4gDQo+PiBJIGFtIGFsc28gdW5jb21m b3J0YWJsZSBhYm91dCB0aGUgbnVtYmVyIG9mIGxpdHRsZSBhZC1ob2MgY29udHJvbA0KPj5zdXJm YWNlcyB0aGF0IHdlIHNlZW0gdG8gYmUgbWFuZGF0aW5nDQo+PiB3aXRob3V0IGFuIG92ZXJhbGwg ZGVzaWduLg0KPj4gDQo+PiBNeSB0YWtlIGlzIHRoYXQgd2Ugc2hvdWxkIHB1c2ggdGhpcyBvdXQg dG8gMi4wIHdoZW4gaG9wZWZ1bGx5IHdlIHdpbGwNCj4+aGF2ZSBhIGRlc2lnbmVkIGNvbnRyb2wg c3VyZmFjZSBpbiBwbGFjZS4NCj4+IA0KPj4+IA0KPj4+IEkgd2lsbCBub3RlIHRoYXQgYW4gbm9y bWFsIGFwcGxpY2F0aW9uIHRoYXQgdXNlZCB0aGlzIGhlYWRlciBjb3VsZA0KPj4+ZGVjaWRlIGlm IGl0IHdhcyBlbmNyeXB0ZWQgb3Igbm90LCB3aGF0IGlzIGRpZmZlcmVudCBpbiBSVENXZWIgaXMg dGhhdA0KPj4+d2UgYXJlIGJ1aWxkaW5nIGEgcGxhdGZvcm0gYW5kIG15IHZpZXcgaXMgdGhhdCB0 aGlzIHBsYXRmb3JtIHNob3VsZA0KPj4+YWxsb3cgdGhlIGFwcGxpY2F0aW9ucyBidWlsZCBvbiB0 aGUgcGxhdGZvcm0gdG8gZGVjaWRlIHRoZSB0cmFkZW9mZnMgb2YNCj4+PnJpc2sgZm9yIGVuY3J5 cHRpbmcgdGhpcyBvciBub3QuDQo+PiANCj4+IFRoYXQgaXNu4oCZdCB0aGUgbGluZSB3ZSBoYXZl IHRha2VuIGluIGFueSBvdGhlciBlbmNyeXB0aW9uIGRpc2N1c3Npb24uDQo+PiANCj4+IFRpbS4N Cj4+IA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+cnRjd2ViIG1haWxpbmcgbGlzdA0KPnJ0Y3dlYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== From nobody Wed Mar 5 07:26:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCD91A01CA for ; Wed, 5 Mar 2014 07:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjUwOTv44t5b for ; Wed, 5 Mar 2014 07:26:23 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id ED8E11A01E5 for ; Wed, 5 Mar 2014 07:26:22 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id m5so1104342qaj.7 for ; Wed, 05 Mar 2014 07:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dVdqtelS0zMN5nMWUnfhcsTVyYuLuDzXmp8SpIRh4gU=; b=hmr8TcyThf1jxnzhULRJoAT6/uO+AHaopK0y62AyshnW/8fGQbFrP0RuLb5UGl/Ahr Yve/825O73yB1WmDsmlxbKA6SgbhUA4nDaotxL+oMRrRQWFkZSsOgeL++UQxeqA2AUnv qsYwlar8LTSM1pOyQNI6tzzHvIDak/zmS7wgSbIRf1BCvpwvLrAOA7QGvp7krmF2b0PA C2XDHMeq2Gu/PssQAVXHvX0u4Gt5V6NFP5RRyZ7pDmFVPEss/RPV7OqK9wOf6k+PCudt m8/AAz4Y5m1gR2pOMD9Yt43ihCzLqE2HTJeGWLDv9ldHzruq/MGFb/0z0/SM+oixfMR3 pQ4w== MIME-Version: 1.0 X-Received: by 10.224.161.140 with SMTP id r12mr7599130qax.24.1394033179170; Wed, 05 Mar 2014 07:26:19 -0800 (PST) Received: by 10.224.28.200 with HTTP; Wed, 5 Mar 2014 07:26:19 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Mar 2014 10:26:19 -0500 Message-ID: From: Gil Zino To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0153742e735b8104f3dda419 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/o5WsAH8u6QQS1XmdbQ0i_iZEct0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 15:26:25 -0000 --089e0153742e735b8104f3dda419 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agree on the cost concern. Not sure I fully understand the context though. Is ~.09% the estimated percentage of times that TCP will be the only way to get through UDP-blocking firewalls, or am I mis-understanding the use case? If it does refer to the UDP-blocking, what data is it based on? I do know large enterprise firewalls skew significantly higher on UDP blocking, but I suspect SMB and residential perhaps are more UDP-permissive by default (but have never seen extensive data that is not biased by the sampling). On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti wrote: > From the transports draft, Section 3.4: > > TURN TCP candidates [RFC6062 ] SHO= ULD be supported; this allows > applications to achieve peer-to-peer communication when both parties > are behind UDP-blocking firewalls using a single TURN server. (In > this case, one can also achieve communication using two TURN servers > that use TCP between the server and the client, and UDP between the > TURN servers.) > > > I don't think we want to do this. The optimization of having a single vs = two TURN servers in the .09% case is not worth the implementation or runtim= e cost of allocating TURN TCP candidates. It requires a TCP connection to t= he TURN server, which we would otherwise not do except in fallback cases. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0153742e735b8104f3dda419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree on the cost concern. =A0Not sure I fully understand = the context though. =A0Is ~.09% the estimated percentage of times that TCP = will be the only way to get through UDP-blocking firewalls, or am I mis-und= erstanding the use case? =A0

If it does refer to the UDP-blocking, what data is it based = on? =A0I do know large enterprise firewalls skew significantly higher on UD= P blocking, but I suspect SMB and residential perhaps are more UDP-permissi= ve by default (but have never seen extensive data that is not biased by the= sampling).




On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti <ju= berti@google.com> wrote:
From the transports draft, = Section 3.4:

   TURN TCP candidates [RFC6062] SHOULD be supported; this all=
ows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

I don't think we wan=
t to do this. The optimization of having a single vs two TURN servers in th=
e .09% case is not worth the implementation or runtime cost of allocating T=
URN TCP candidates. It requires a TCP connection to the TURN server, which =
we would otherwise not do except in fallback cases.

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


--089e0153742e735b8104f3dda419-- From nobody Wed Mar 5 07:27:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1937C1A01CA for ; Wed, 5 Mar 2014 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 7YJAOBlwPptq for ; Wed, 5 Mar 2014 07:27:05 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id EECD91A00C2 for ; Wed, 5 Mar 2014 07:27:04 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id lg15so1156822vcb.26 for ; Wed, 05 Mar 2014 07:27:01 -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=6qM9jBdl0or+ZieDwALz5NQfqjkb3autVrGm+UNPtN0=; b=DqoNzb/Zq6ZEP+Sff7xoMkSzxAWGWA2enf1MQ/zjK8IQhXpoUgGqaOvcf+tL9EOO29 GPb0pzdWRG72rXrSUBafvNg8CZY91WjUxQJvye1UWo0m3dLIgbv6WomCTUDKgP3oOycM 5/TXX4NC4ZLWUso1dXNi8owyjoKie8W9i1hy2LFYzjpB+2qxwDEwR1pYfYnD59GLhgl8 Um3jmhDLTdvl+zxHJHZNRSklpzTB58WrZAZRwThJG0U1Q52/Wq7EcmspObrHWsxM/4Cb q+02PwibiemZyp31xFEfwoSOPm7TAdnkHr8aZp0KuY0ZKsti7oA114Uhm/FhWCN29FbJ w7Iw== 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=6qM9jBdl0or+ZieDwALz5NQfqjkb3autVrGm+UNPtN0=; b=ZLMJ5hxk5OVDti1y2wIc10WySJvTPCbnary9KhVijnGRiP/2MUg5Kz/TKUhYydjord +7zsJPrHQ51uUtlRwobEt2LTixnkhjIT/MKKagLGRDsGY/1fM+Nsf+HwZjbIB0X3nsGj iNFyJMCco4Iudu2dROu8rs5W2D7/cdSXRVF+XDqzc11iWFL45mc38Lcp8Mbo4ysgoRlF x2k2TK9Q7iuGTK1z1MMWvCyA6YUcKC0f6WnsXqnISkXLOHSXxpzlyvO8nTjDl3GGbPhY LXqGfTELECDQZ3bf2zjyjW9iJubElhuDamH3TTl7ofDa0BeUMtDlPwMJu6s+aMjF8sAZ hhYw== X-Gm-Message-State: ALoCoQmEeNnv6ZATkJ0kogXH/UvvS56p2FHyWsngx9rVQ7AjiCFHuZrL265lN4qz+RAZ1Fk4cv2GuqJEX/TtfKzb7FA/Jy/zoAuEECVazvzSyJD6Q70/gBJPeYJbt+x9Ed2CT3rY/clzuHQTqV635bsHpMiHz+P9BjA7GKhwmmz4uYW6gORW4CuDamV8o0Fa8PCSOTiSR4Hv X-Received: by 10.58.123.70 with SMTP id ly6mr728031veb.26.1394033221185; Wed, 05 Mar 2014 07:27:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 5 Mar 2014 07:26:41 -0800 (PST) In-Reply-To: <531740DD.5030700@viagenie.ca> References: <531740DD.5030700@viagenie.ca> From: Justin Uberti Date: Wed, 5 Mar 2014 15:26:41 +0000 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=089e0118490ef448ea04f3dda6ae Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6Lt2I-TKp0pO3LVLn5VBCijW008 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 15:27:08 -0000 --089e0118490ef448ea04f3dda6ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 5, 2014 at 3:21 PM, Simon Perreault wrote: > Le 2014-03-05 14:56, Justin Uberti a =C3=A9crit : > > I think this needs clarification. Does this mean that we should allocat= e > v6 candidates from all v4 interfaces (for compat with v6-only endpoints), > as well as allocate v4 candidates from all v6 interfaces (for compat with > v4-only endpoints), and if so, which path (v6-to-TURN or v6-from-TURN) > should be prioritized? > > You must always allocate both v4 and v6 relayed candidates, irrespective > of what other candidates you have. > I am fine with that - this needs to be added to the transports document though. Any thoughts on the prioritization question? --089e0118490ef448ea04f3dda6ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 5, 2014 at 3:21 PM, Simon Perreault &= lt;simon.p= erreault@viagenie.ca> wrote:
Le 2014-03-05 14:56, Justin Uberti a =C3=A9c= rit :
> I think this needs clarification. Does this mean that = we should allocate v6 candidates from all v4 interfaces (for compat with v6= -only endpoints), as well as allocate v4 candidates from all v6 interfaces = (for compat with v4-only endpoints), and if so, which path (v6-to-TURN or v= 6-from-TURN) should be prioritized?

You must always allocate both v4 and v6 relayed candidates, irrespect= ive
of what other candidates you have.

I am= fine with that - this needs to be added to the transports document though.=

Any thoughts on the prioritization question?=C2= =A0
--089e0118490ef448ea04f3dda6ae-- From nobody Wed Mar 5 07:32:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079841A0119 for ; Wed, 5 Mar 2014 07:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 oQNGnhINv_MP for ; Wed, 5 Mar 2014 07:31:54 -0800 (PST) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6773C1A0310 for ; Wed, 5 Mar 2014 07:31:54 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hq11so1212227vcb.0 for ; Wed, 05 Mar 2014 07:31:50 -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=ZHbHa4p9jUdje0tN9GPgrvx9FdtP2S2vaiOD2R6izN8=; b=GSgKkiKByp2APtTwMxdAvPxniJ4tyRtjFOn7X2Pi4QuNu7sL2Gsb6bcrna7ymEY5JN UucqfIdxylVbfioLxq9k5p65ljandfaiyyoRJ3zrQ6h/uY+qpI37twmNt86iGDxHSjY8 gbxG+xjBHGeCnxBKLuUx9y0z5bcTmn+UljXoUQ6NjFOdx6UTPJJeSlm8+rZN6IWbzt5Z 0FePeH25adJGd3AOTeELvmCeEY4ptxfO7hZxDginFlHoxzKiRDi3A6CqatmqnQlwqCbH aXrPmPyrQ+eK1bQCeEeHR04a/yAI5LnbdkGyXL02xNGqlDnew4rUo9gMts1PP/WS1oYt 9Y9w== 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=ZHbHa4p9jUdje0tN9GPgrvx9FdtP2S2vaiOD2R6izN8=; b=Rljzmt9J7byB37DKghTHdhA6ZqZePI3ryNAr336T2iFYzqPv938seVso7IqANRk08h 1afMHfuTJMuWufiVWFlsQc98qX1s5IeNyDrS58Ta4SnOHdkVB+4/wdvMsFPg2C9kLReo hCUtX3Sd7baOPMdF1vo5cUYj1Dex7u9qzJn6RJYloHNw9lBw6sQW9Fs/Sfx+1VeJOy7i TDh9A0hqQEBdl6PwBFQ06QFxlu5Mcvdyv4lGzBG0ddhb4OAs9qFuS5ZWV2qEeJYEsMAP E19tK6p8pAQGPDJvEebJWLrdgQw1yNH5EMYgMfMHrUEWJp5HLWSrkHyrJx9we5xRl+cB +L9Q== X-Gm-Message-State: ALoCoQmrs921LEh0lLEsqmTpTps6OZ5mZnj0BbYCq/jHIck/WocboYlzOfuzBizwCLKRtJT0GWdc1zSr7H4KbJJwaknGL71Fq8Miy9rTWL9x8GaKFC+uJcok/9zNwDadDwjyAK35LUwPGvs4VOIrJTfnXg98uaHMQZVppUbu8reu32m7nuIaaEwwfB8o7WiWAOzkmT7yY3tI X-Received: by 10.221.74.65 with SMTP id yv1mr458683vcb.31.1394033510626; Wed, 05 Mar 2014 07:31:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 5 Mar 2014 07:31:30 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Wed, 5 Mar 2014 15:31:30 +0000 Message-ID: To: Gil Zino Content-Type: multipart/alternative; boundary=001a1136563834ce1504f3ddb8d9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_jJyLX6Pj0h6x5bZZ_gB1qYHBuc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 15:32:00 -0000 --001a1136563834ce1504f3ddb8d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am assuming 3% as the case where TCP is needed to get through UDP-blocking firewalls, based on empirical data from QUIC testing in Chrome over a very large population. Since TURN TCP candidates (not to be confused with TURN/TCP to connect to the TURN server) are only useful in the case where BOTH sides are behind such firewalls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN TCP candidates are useful. As an optimization, I don't think this is worth worrying about. On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino wrote: > Agree on the cost concern. Not sure I fully understand the context > though. Is ~.09% the estimated percentage of times that TCP will be the > only way to get through UDP-blocking firewalls, or am I mis-understanding > the use case? > > If it does refer to the UDP-blocking, what data is it based on? I do kno= w > large enterprise firewalls skew significantly higher on UDP blocking, but= I > suspect SMB and residential perhaps are more UDP-permissive by default (b= ut > have never seen extensive data that is not biased by the sampling). > > > > > On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti wrote= : > >> From the transports draft, Section 3.4: >> >> >> TURN TCP candidates [RFC6062 ] SH= OULD be supported; this allows >> applications to achieve peer-to-peer communication when both parties >> are behind UDP-blocking firewalls using a single TURN server. (In >> this case, one can also achieve communication using two TURN servers >> that use TCP between the server and the client, and UDP between the >> TURN servers.) >> >> >> I don't think we want to do this. The optimization of having a single vs= two TURN servers in the .09% case is not worth the implementation or runti= me cost of allocating TURN TCP candidates. It requires a TCP connection to = the TURN server, which we would otherwise not do except in fallback cases. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a1136563834ce1504f3ddb8d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am assuming 3% as the case where TCP is needed to get th= rough UDP-blocking firewalls, based on empirical data from QUIC testing in = Chrome over a very large population.

Since TURN TCP cand= idates (not to be confused with TURN/TCP to connect to the TURN server) are= only useful in the case where BOTH sides are behind such firewalls, 3% * 3= % =3D=3D .09% is the fraction of calls where TURN TCP candidates are useful= . As an optimization, I don't think this is worth worrying about.


On Wed,= Mar 5, 2014 at 3:26 PM, Gil Zino <gilzino@gmail.com> wrote:=
Agree on the cost concern. =C2=A0Not sure I fully understa= nd the context though. =C2=A0Is ~.09% the estimated percentage of times tha= t TCP will be the only way to get through UDP-blocking firewalls, or am I m= is-understanding the use case? =C2=A0

If it does refer to the UDP-blocking, what data is it based = on? =C2=A0I do know large enterprise firewalls skew significantly higher on= UDP blocking, but I suspect SMB and residential perhaps are more UDP-permi= ssive by default (but have never seen extensive data that is not biased by = the sampling).




On Wed, Mar 5, 2014 at 10:02 = AM, Justin Uberti <juberti@google.com> wrote:
From the transports draft, Section 3.4:


   TURN TCP candidates [RFC6062] SHOULD be supported; this all=
ows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

I don't think we wan=
t to do this. The optimization of having a single vs two TURN servers in th=
e .09% case is not worth the implementation or runtime cost of allocating T=
URN TCP candidates. It requires a TCP connection to the TURN server, which =
we would otherwise not do except in fallback cases.

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



--001a1136563834ce1504f3ddb8d9-- From nobody Wed Mar 5 07:46:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E021A0739 for ; Wed, 5 Mar 2014 07:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 G9j42UDHN5kS for ; Wed, 5 Mar 2014 07:46:00 -0800 (PST) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB71A00DA for ; Wed, 5 Mar 2014 07:45:59 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/5/2014 10:45:55 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-500/SG:5 3/5/2014 10:45:07 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.862181 p=-0.98233 Source White X-Signature-Violations: 0-0-0-21141-c X-Note-419: 31.2006 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 3/5/2014 10:45:41 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 77492778; Wed, 05 Mar 2014 10:45:54 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 5 Mar 2014 09:45:54 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOIXa97MYXf3mNUS0a1X98yqSFprTB4SA Date: Wed, 5 Mar 2014 15:45:54 +0000 Message-ID: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.226] Content-Type: multipart/alternative; boundary="_000_E7C174FBB1374E6D81AC06C8C2B30FE1vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZTE7Mvt-AiiZEhVYh-AD6ufcpcI Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 15:46:03 -0000 --_000_E7C174FBB1374E6D81AC06C8C2B30FE1vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 5, 2014, at 2:25 PM, Justin Uberti > wrote: So there are three things here: 1) MUST the implementation offer encrypted header extensions? (i.e. mandato= ry-to-implement) 2) MUST the implementation use encrypted header extensions? (i.e. mandatory= -to-use) 3) MUST the implementation expose an API to control this? (i.e. no SDP mung= ing needed) I think we want yes for #1, no for #2, and #3 is potentially interesting bu= t out of scope for 1.0. That gives encrypted headers for audio on by default, but remote parties ca= n negotiate this off using RFC 6904 mechanisms. Note that in 6904=92s procedures, an offerer has to explicitly offer both e= ncrypted and unencrypted versions of a header extension if it wants to allo= w the answerer to choose between them. To support this use case, in RTCWeb terms, this would mean that a browser w= ould a) have to offer both the encrypted and unencrypted versions of the he= ader extension, and b) answer an offer that offered only the unencrypted he= ader by agreeing to use it. That said, I=92m not sure I believe in Cullen=92s use case =97 there=92s to= o much other information that this unauthorized conference mixer wouldn=92t= be able to do. (e.g., request I-frames, or detect them, for switching; or= generate proper RTCP reports for sometimes-on streams). On Wed, Mar 5, 2014 at 2:05 PM, Cullen Jennings (fluffy) > wrote: Well if people don=92t want to allow the application to choose to encrypt t= his header or not, I will be arguing for MUST NOT encrypt the RTP headers -= all of them. A recurring theme at IETF is that people trying to protect E2E privacy, do = things that result in the real world having the only way they can build app= lications is to build middle boxes that pretend to to be an end to the thin= gs on both sides. This means that the middle boxes end up with 100% ability= to change everything and we loose all the protection we hoped to get with = E2E security. On Mar 5, 2014, at 1:59 PM, tim panton > wrote: > > On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) > wrote: > >> >> I am opposed to mandating that Client-to-Mixer Audio Level RTP header is= REQUIRED to be encrypted. It means that we can not really build conferenci= ng system where the mixers do not have access to decrypt the media. > > I have to ask: > Does that matter enough to weaken user security for everyone else? > > >> >> I would like to propose that the JS application can control if the head= er is encrypted or not. > > I am deeply uncomfortable about that. I am not a good enough cryptographe= r to know, but my instinct > is that exposing the fact that (for example) most of the top bits of the = ulaw data are zeros in this packet > must be a risk. > > I=92m pretty confident that one could detect the pitch of the speaker and= probably fingerprint that down > to individuals or languages with enough data. > >> >> I am aware of the paper that suggests these audio levels can reveal the = contents of the conversation. There is some element of truth to this. There= is also some element of truth to the point that if this was true, speech r= ecognition system would work better than they do. Encrypting this or not is= a risk that the application using the header extension needs to evaluate, = and WebRTC system needs to provide the applications with a control surfaces= that allows them to use this in the way the applications desires. > > I am also uncomfortable about the number of little ad-hoc control surface= s that we seem to be mandating > without an overall design. > > My take is that we should push this out to 2.0 when hopefully we will hav= e a designed control surface in place. > >> >> I will note that an normal application that used this header could decid= e if it was encrypted or not, what is different in RTCWeb is that we are bu= ilding a platform and my view is that this platform should allow the applic= ations build on the platform to decide the tradeoffs of risk for encrypting= this or not. > > That isn=92t the line we have taken in any other encryption discussion. > > Tim. > _______________________________________________ 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 --_000_E7C174FBB1374E6D81AC06C8C2B30FE1vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7D8D83A3C70C1C42A6177F98AE131C5C@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Mar 5, 2014, at 2:25 PM, Justin Uberti <juberti@google.com> wrote:

So there are three things here:
1) MUST the implementation offer encrypted header extensions? (i.e. ma= ndatory-to-implement)
2) MUST the implementation use encrypted header extensions? (i.e. mand= atory-to-use)
3) MUST the implementation expose an API to control this? (i.e. no SDP= munging needed)

I think we want yes for #1, no for #2, and #3 is potentially interesti= ng but out of scope for 1.0.
That gives encrypted headers for audio on by default, but remote parti= es can negotiate this off using RFC 6904 mechanisms.

Note that in 6904=92s procedures, an offerer has to explicitly offer b= oth encrypted and unencrypted versions of a header extension if it wants to= allow the answerer to choose between them.

To support this use case, in RTCWeb terms, this would mean that a brow= ser would a) have to offer both the encrypted and unencrypted versions of t= he header extension, and b) answer an offer that offered only the unencrypt= ed header by agreeing to use it.

That said, I=92m not sure I believe in Cullen=92s use case =97 there= =92s too much other information that this unauthorized conference mixer wou= ldn=92t be able to do.  (e.g., request I-frames, or detect them, for s= witching; or generate proper RTCP reports for sometimes-on streams). 

On Wed, Mar 5, 2014 at 2:05 PM, Cullen Jennings = (fluffy) <fluffy@cisco.com> wrote:

Well if people don=92t want to allow the application to choose to encrypt t= his header or not, I will be arguing for MUST NOT encrypt the RTP headers -= all of them.

A recurring theme at IETF is that people trying to protect E2E privacy, do = things that result in the real world having the only way they can build app= lications is to build middle boxes that pretend to to be an end to the thin= gs on both sides. This means that the middle boxes end up with 100% ability to change everything and we loos= e all the protection we hoped to get with E2E security.


On Mar 5, 2014, at 1:59 PM, tim panton <tim@phonefromhere.com> wrote:

>
> On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
>>
>> I am opposed to mandating that Client-to-Mixer Audio Level RTP hea= der is REQUIRED to be encrypted. It means that we can not really build conf= erencing system where the mixers do not have access to decrypt the media. >
> I have to ask:
> Does that matter enough to weaken user security for everyone else?
>
>
>>
>> I would like to propose that the JS application can control  = if the header is encrypted or not.
>
> I am deeply uncomfortable about that. I am not a good enough cryptogra= pher to know, but my instinct
> is that exposing the fact that (for example) most of the top bits of t= he ulaw data are zeros in this packet
> must be a risk.
>
> I=92m pretty confident that one could detect the pitch of the speaker = and probably fingerprint that down
> to individuals or languages with enough data.
>
>>
>> I am aware of the paper that suggests these audio levels can revea= l the contents of the conversation. There is some element of truth to this.= There is also some element of truth to the point that if this was true, sp= eech recognition system would work better than they do. Encrypting this or not is a risk that the application using = the header extension needs to evaluate, and WebRTC system needs to provide = the applications with a control surfaces that allows them to use this in th= e way the applications desires.
>
> I am also uncomfortable about the number of little ad-hoc control surf= aces that we seem to be mandating
> without an overall design.
>
> My take is that we should push this out to 2.0 when hopefully we will = have a designed control surface in place.
>
>>
>> I will note that an normal application that used this header could= decide if it was encrypted or not, what is different in RTCWeb is that we = are building a platform and my view is that this platform should allow the = applications build on the platform to decide the tradeoffs of risk for encrypting this or not.
>
> That isn=92t the line we have taken in any other encryption discussion= .
>
> Tim.
>

_______________________________________________
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

--_000_E7C174FBB1374E6D81AC06C8C2B30FE1vidyocom_-- From nobody Wed Mar 5 07:56:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858361A023D for ; Wed, 5 Mar 2014 07:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 Xv7T8osEFkt5 for ; Wed, 5 Mar 2014 07:56:03 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 971031A022E for ; Wed, 5 Mar 2014 07:56:03 -0800 (PST) Received: from porto.nomis80.org (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B2BFF4040A for ; Wed, 5 Mar 2014 10:55:59 -0500 (EST) Message-ID: <5317490E.3090701@viagenie.ca> Date: Wed, 05 Mar 2014 15:55:58 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3TfG1LvRduLIFUBPOwsF6OAbxF4 Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 15:56:07 -0000 Since you asked for more... Le 2014-03-05 14:56, Justin Uberti a écrit : > which path (v6-to-TURN or v6-from-TURN) should be prioritized? I'm sorry, I don't understand this question. > Note also that these v4->v6 or v6->v4 allocations will be dependent on the SSODA work being discussed in TRAM, since this is the only way to allocate v4 and v6 TURN from a single host candidate. I don't understand what you mean. > Also worth noting: > > With the current default settings, a single STUN and TURN server, and assuming a dual-stack host with two network interfaces, a PeerConnection with audio, video, and data will generate > > 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * 2 (IP protocols) = 80 candidates It's....... it's beautiful! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 5 07:56:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6081A0750 for ; Wed, 5 Mar 2014 07:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mMEBLGbfgO3 for ; Wed, 5 Mar 2014 07:56:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9FE1A0236 for ; Wed, 5 Mar 2014 07:56:04 -0800 (PST) Received: from BLUPR03MB437.namprd03.prod.outlook.com (10.141.78.147) by BLUPR03MB376.namprd03.prod.outlook.com (10.141.75.150) with Microsoft SMTP Server (TLS) id 15.0.883.10; Wed, 5 Mar 2014 15:55:59 +0000 Received: from BLUPR03CA035.namprd03.prod.outlook.com (10.141.30.28) by BLUPR03MB437.namprd03.prod.outlook.com (10.141.78.147) with Microsoft SMTP Server (TLS) id 15.0.888.9; Wed, 5 Mar 2014 15:55:57 +0000 Received: from BN1AFFO11FD025.protection.gbl (2a01:111:f400:7c10::114) by BLUPR03CA035.outlook.office365.com (2a01:111:e400:879::28) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 15:55:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD025.mail.protection.outlook.com (10.58.52.85) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 15:55:57 +0000 Received: from TK5EX14MBXC296.redmond.corp.microsoft.com ([169.254.2.186]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Wed, 5 Mar 2014 15:55:23 +0000 From: "Matthew Kaufman (SKYPE)" To: Justin Uberti Thread-Topic: [rtcweb] Transports: RFC 6062 support Thread-Index: AQHPOIP9MQysxUHuaES93/Eve9xs+5rSnXuAgAABcwCAAAaraQ== Date: Wed, 5 Mar 2014 15:55:22 +0000 Message-ID: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> References: , 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_4A409D06511D424D8285E38B3E08292Dskypenet_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(438001)(199002)(189002)(24454002)(377454003)(93516002)(4396001)(83072002)(74366001)(56816005)(90146001)(33656001)(85852003)(31966008)(81542001)(74502001)(47446002)(92566001)(77096001)(36756003)(79102001)(20776003)(63696002)(15202345003)(65816001)(30436002)(80022001)(512954002)(94316002)(94946001)(92726001)(47736001)(93136001)(50986001)(47976001)(86362001)(19580405001)(83322001)(49866001)(76786001)(19580395003)(6806004)(81816001)(15975445006)(95416001)(81686001)(82746002)(95666003)(87266001)(76482001)(51856001)(87936001)(53806001)(83716003)(59766001)(77982001)(74706001)(80976001)(81342001)(69226001)(76796001)(44976005)(16236675002)(85306002)(46102001)(54316002)(2656002)(54356001)(74876001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB437; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:BCB2C137.AA3E6FC3.23EB7373.84E1D2FA.2037F; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01415BB535 Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mQnAq_1_YJWnneQs9qciSZHZp88 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 15:56:12 -0000 --_000_4A409D06511D424D8285E38B3E08292Dskypenet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 given that it still works for those 0.9%, it just hits two TURN servers.= .. And with luck, that actually is better because if they each select TURN = servers well you get TCP on the short legs and UDP on the long leg. Matthew Kaufman Sent from my iPad On Mar 5, 2014, at 7:32 AM, "Justin Uberti" > wrote: I am assuming 3% as the case where TCP is needed to get through UDP-blockin= g firewalls, based on empirical data from QUIC testing in Chrome over a ver= y large population. Since TURN TCP candidates (not to be confused with TURN/TCP to connect to t= he TURN server) are only useful in the case where BOTH sides are behind suc= h firewalls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN TCP ca= ndidates are useful. As an optimization, I don't think this is worth worryi= ng about. On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino > wrote: Agree on the cost concern. Not sure I fully understand the context though.= Is ~.09% the estimated percentage of times that TCP will be the only way = to get through UDP-blocking firewalls, or am I mis-understanding the use ca= se? If it does refer to the UDP-blocking, what data is it based on? I do know = large enterprise firewalls skew significantly higher on UDP blocking, but I= suspect SMB and residential perhaps are more UDP-permissive by default (bu= t have never seen extensive data that is not biased by the sampling). On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti > wrote: >From the transports draft, Section 3.4: TURN TCP candidates [RFC6062] SHOULD= be supported; this allows applications to achieve peer-to-peer communication when both parties are behind UDP-blocking firewalls using a single TURN server. (In this case, one can also achieve communication using two TURN servers that use TCP between the server and the client, and UDP between the TURN servers.) I don't think we want to do this. The optimization of having a single vs tw= o TURN servers in the .09% case is not worth the implementation or runtime = cost of allocating TURN TCP candidates. It requires a TCP connection to the= TURN server, which we would otherwise not do except in fallback cases. _______________________________________________ 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 --_000_4A409D06511D424D8285E38B3E08292Dskypenet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1 given that it still works for those 0.9%, it just hits two TURN= servers... And with luck, that actually is better because if they each sel= ect TURN servers well you get TCP on the short legs and UDP on the long leg= .

Matthew Kaufman

Sent from my iPad

On Mar 5, 2014, at 7:32 AM, "Justin Uberti" <juberti@google.com> wrote:

I am assuming 3% as the case where TCP is needed to get th= rough UDP-blocking firewalls, based on empirical data from QUIC testing in = Chrome over a very large population.

Since TURN TCP candidates (not to be confused with TURN/TCP to connect= to the TURN server) are only useful in the case where BOTH sides are behin= d such firewalls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN T= CP candidates are useful. As an optimization, I don't think this is worth worrying about.


On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino <gilzino@gmail.co= m> wrote:
Agree on the cost concern.  Not sure I fully understa= nd the context though.  Is ~.09% the estimated percentage of times tha= t TCP will be the only way to get through UDP-blocking firewalls, or am I m= is-understanding the use case?  

If it does refer to the UDP-blocking, what data is it based on?  = I do know large enterprise firewalls skew significantly higher on UDP block= ing, but I suspect SMB and residential perhaps are more UDP-permissive by d= efault (but have never seen extensive data that is not biased by the sampling).




On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti <jubert= i@google.com> wrote:
From the transports draft, Section 3.4: 

   TURN TCP candidates [RFC6062] SHOULD be supported; this all=
ows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

I don't think we want to do this. The optimi=
zation of having a single vs two TURN servers in the .09% case is not worth=
 the implementation or runtime cost of allocating TURN TCP candidates. It r=
equires a TCP connection to the TURN server, which we would otherwise not d=
o except in fallback cases.

_______________________________________________
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
--_000_4A409D06511D424D8285E38B3E08292Dskypenet_-- From nobody Wed Mar 5 08:07:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6C01A0545 for ; Wed, 5 Mar 2014 08:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k5cQGKD0H1n for ; Wed, 5 Mar 2014 08:07:22 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 710211A0128 for ; Wed, 5 Mar 2014 08:07:22 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id x13so1502613wgg.21 for ; Wed, 05 Mar 2014 08:07:18 -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=GEjt5dxysFEip2oUobdeAveYjM1S4sNzzFTJryKrJ4s=; b=MYA0jc+FGahLWaTMZxQV3toKo8y6Zx5WW9T0BZj2xIbNT2Z6ITwq/Kl9+PF6Rz8gw1 xfV6L3oSJwKneFCmH2aW+Hb93ZkIWLe8EOqNppJ1Wi8frypYJQ85e+PCgfU4Jtv+y52O pSgbbvnTFdJqIyKwPvuGt7GDFAXozvCK32WZA5G7ZqLt5uqqB4AE5J7VSGE1PfEulH4u wrK1lEK6p5jmsfjQ4Y9geg3mfaynjypCBorA5+A2Hf/XtYd0bl6tJGdPYXWEAlwmTeF7 yWn2uRj6nXLP9j0eHsZ9kAAxxip/xvjRRw1+XXJPuv/BtG+gipF19A9ZxS6dJRoP4KJQ aAPw== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr2380899wjb.28.1394035638454; Wed, 05 Mar 2014 08:07:18 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 08:07:18 -0800 (PST) In-Reply-To: References: <53171C20.3020001@ericsson.com> Date: Wed, 5 Mar 2014 16:07:18 +0000 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aGiXYqGNwJd-nxxa2XVDe-an7HI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 05 Mar 2014 16:07:27 -0000 On 5 March 2014 14:30, Justin Uberti wrote: > I am inclined to make CNAMEs per-PeerConnection (i.e. enforce scenario #2 > behavior) for 1.0, as it has a smaller downside. I think that I am OK with this. It might still be possible to synchronize in the first scenario, but it would require that the playback protect itself against drift, because CNAME wouldn't be providing a positive indication that synchronization is safe. From nobody Wed Mar 5 08:10:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9021A0642 for ; Wed, 5 Mar 2014 08:10:03 -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 u8m4zvxrwIKu for ; Wed, 5 Mar 2014 08:10:01 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB51A0234 for ; Wed, 5 Mar 2014 08:10:01 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so1471274wes.40 for ; Wed, 05 Mar 2014 08:09:57 -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=Ez1r4MQq2Tjfn0Ys1nBH6RF4YoNIUMDglxMYHPBgmxw=; b=c7SHK2fhWSqtN4Aw+zvxc526mQv9yGfnJtDdjdKwBcY1TUmvUBXUiRpb1L9p8Oy3Nr uRlpy2bJg+7aDGAcjLuo4lGopkznTOIiYXRT2BSTyknes0cIcblHWPW4vin0b0CRK7NX tw4+jCXZxuiIDFFWRwfYFOP27e8AJaNxXUQhTWQYyX1Yrur7NhMleeDKrfIL24m/Ao2T JhwvJ3klv9S5uLRigHoXRy6+ysJzPXNlzhhRvbveTS7VOWBkH8ye2rtRiLMK5nlml5L4 xwOTSnopGlh8ogHd0YkaRJauGwElnhWXWR44I62f9XS4tB33DNZecCIjf8handU/XMg7 dUPg== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr2405858wjb.28.1394035797342; Wed, 05 Mar 2014 08:09:57 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 08:09:57 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> <32D95060-6273-4804-A398-712311481E73@phonefromhere.com> Date: Wed, 5 Mar 2014 16:09:57 +0000 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9Invv1fxqT5lLo22HI2dDbhHwD8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 16:10:04 -0000 On 5 March 2014 14:40, Justin Uberti wrote: > Agree with Cullen (and FWIW the SRTP encryption uses keys vended from the > DTLS master secret, so I think even if you are able to crack the SRTP crypto > it would not be trivial to go backwards up to the DTLS key material) Yes. DTLS-SRTP extracts keys, so working backwards to the master secret would mean that not only have you cracked SRTP, but that you can also produce a HMAC preimage at will. From nobody Wed Mar 5 08:12:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD2B1A06A3 for ; Wed, 5 Mar 2014 08:12:12 -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 oWYN9n8l2GyK for ; Wed, 5 Mar 2014 08:12:07 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7458D1A06A4 for ; Wed, 5 Mar 2014 08:11:36 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so1507893wgh.7 for ; Wed, 05 Mar 2014 08:11: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=GEUpF+ldNbI4nYPG2TjN4SZr/13dJpKo+QfHBdfy5/s=; b=XCI/58efZGI2FaMp6mz5t/aB+od5jPG0ZhuZGDQX98Wp3gKFkmRAe62QjpSW1JLbOV oj931mKy1OEKC6HwbDsTetoaGZSC3yFCRJ8hqPLmrsXBMr9WDcA4ohvL1i0IanFQq7Sc 8M0E7d7ePm5dJfx2MK4WgikDGqQgUN6oTobD5DLK84ZzmzR5JDOdIWJUnKbweeVWQ8pl d60vrNvKOFdavP2pI+XeCYwlsy74x6/s+1Ek4HtXbQz0XU2L/a1uW5IeNcsMksf3tEQP 7l5Pzq2scEtd0kpzVNP8+yvkW3RhcjjYc80RXZBiFlFZHg4YYV40hAiy3ZZkB2b3/aeY CF4g== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr2332068wjc.56.1394035889093; Wed, 05 Mar 2014 08:11:29 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 08:11:28 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> Date: Wed, 5 Mar 2014 16:11:28 +0000 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Z8ivuo0X6JP1w7zOZ8aooOKkYuU Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 16:12:13 -0000 On 5 March 2014 14:25, Justin Uberti wrote: > 3) MUST the implementation expose an API to control this? (i.e. no SDP > munging needed) I think perhaps we might split this finer and discuss whether the control is offered for isolated streams or not. From nobody Wed Mar 5 08:23:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2B51A01BF for ; Wed, 5 Mar 2014 08:23:11 -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 XPoST_-YoONW for ; Wed, 5 Mar 2014 08:23:10 -0800 (PST) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id AB4021A0174 for ; Wed, 5 Mar 2014 08:23:09 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a15so1169224eae.9 for ; Wed, 05 Mar 2014 08:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=sKZG1BC9mxDd7BY6+F+AP6BBZk8fFyUvYuSmjnt0RyI=; b=0Fikpezgx4ko5YURatJ+GxEtO8W+p1dZxr7n16Zye1CU8+ObtMZEe/ycO6eR9IKed8 cpdOTW9+cTf2t9lv6iVF6GfV22c+f1FrMGjXsTWDzU9weugwH3iphSQC7gBG/YzWLiTd +K5e1vtlRKsOAk2LllzEBJfOEO29fLhdrN8mZqOuAi/vvMD7+OYqWz2PIZyCuVbpEDIY yE0SWjnepk3wIVeb5IcXaiDs8vqcub3Reoo7SsOyY+oOIif3hln9dcZRTngSqWCMNh9u kUWKsUemNDa+R8rtcBuatgKwdUs5GA8Wu98HTb4q87cH2qFPh8VNiHXjaPwwxPbeBfBZ c0eg== X-Received: by 10.14.225.73 with SMTP id y49mr3136873eep.43.1394036585514; Wed, 05 Mar 2014 08:23:05 -0800 (PST) Received: from [192.168.1.35] (105.Red-81-33-134.dynamicIP.rima-tde.net. [81.33.134.105]) by mx.google.com with ESMTPSA id i47sm10779087eeg.6.2014.03.05.08.23.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 08:23:04 -0800 (PST) Message-ID: <53174F6B.2030706@gmail.com> Date: Wed, 05 Mar 2014 17:23:07 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050100020608060907050107" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qUffWcpgsj3EA3qGWLEJ88ClK8o Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 16:23:12 -0000 This is a multi-part message in MIME format. --------------050100020608060907050107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 05/03/2014 16:45, Jonathan Lennox escribió: > > That said, I'm not sure I believe in Cullen's use case --- there's too > much other information that this unauthorized conference mixer > wouldn't be able to do. (e.g., request I-frames, or detect them, for > switching; or generate proper RTCP reports for sometimes-on streams). I have deeper doubts, I don't really know how a RTP router/mixer would be able to work without acting as DTLS endpoint and decripting/encripting the RTP data. Or is there a way to setup/share a DTLS session between more than two peers so the same DTLS/SRTP packet is decriptable by more than one receiver? Best regards Sergio --------------050100020608060907050107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
El 05/03/2014 16:45, Jonathan Lennox escribió:

That said, I’m not sure I believe in Cullen’s use case — there’s too much other information that this unauthorized conference mixer wouldn’t be able to do.  (e.g., request I-frames, or detect them, for switching; or generate proper RTCP reports for sometimes-on streams). 

I have deeper doubts, I don't really know how a RTP router/mixer would be able to work without acting as DTLS endpoint and decripting/encripting the RTP data.  Or is there a way to setup/share a DTLS session between more than two peers so the same DTLS/SRTP packet is decriptable by more than one receiver?

Best regards
Sergio
--------------050100020608060907050107-- From nobody Wed Mar 5 08:25:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7C71A0733 for ; Wed, 5 Mar 2014 08:25:35 -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 2yDWDO9pbg5H for ; Wed, 5 Mar 2014 08:25:34 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3671A0502 for ; Wed, 5 Mar 2014 08:25:33 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so1344169qcv.5 for ; Wed, 05 Mar 2014 08: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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Rbi78RcXyR2/9acHW0OQnIPQmaMM6I09Z4eYMhgcn8s=; b=lU4b0YwY23zcjFXoVCsa26kHEVSvq+lIhD7jVkXmOdiVHGFmco5YrIHof+bw5AkaEa e0u+jkfY1dOEBTkXq2tVJ6F9hxMVvUhxNJhbOeZpgrcKUPoSbSGQy8JyMBkNijJbVBnl 4j3mBtiDXnxVmYvbKTtHRo66uhDToBMewC+Jaxayv+Iyax24kZ3utEKpEQ0UbmmxQ4hf g9d8WbvxHGmz/dOek4i2Ine1DmW8gjneO9ihe6L3yw30nO+/M+fFWYFmiQMOxgulOYT7 mXJSD4oIp3G9c0tUOV9rNHxLWO9+rcE6ZM7DN/DQV4/w4OCL6WiGRsO4JNFVncRQLjhw PD6g== X-Gm-Message-State: ALoCoQlrdPWlQdQQRjx4GGcxtDdrZfCIfDNaQXhPP6JfxpxJaWczMGWmz9ygrUcyj0G5UV90a9zt X-Received: by 10.224.21.207 with SMTP id k15mr7922648qab.66.1394036730229; Wed, 05 Mar 2014 08:25:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.203.169 with HTTP; Wed, 5 Mar 2014 08:25:10 -0800 (PST) In-Reply-To: <53173C11.8060504@gmail.com> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <53173C11.8060504@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 5 Mar 2014 17:25:10 +0100 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Yx7hUYf19vxsUej3egfs9WyfbrA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 16:25:35 -0000 2014-03-05 16:00 GMT+01:00 Sergio Garcia Murillo : > El 05/03/2014 13:32, Cullen Jennings (fluffy) escribi=C3=B3: > >> I am opposed to mandating that Client-to-Mixer Audio Level RTP header is >> REQUIRED to be encrypted. It means that we can not really build conferen= cing >> system where the mixers do not have access to decrypt the media. >> >> > Hi Cullen, > > I am not sure I am following you. AFAIK DTLS is only possible to be setup > between two peers, so in a multiconference solution the mixer will anyway > have to establish a DTLS/SRTP session which each peer and decrypt/encrypt > before sending to any of participants in the conference. In case of a ful= l > meshed conference, there is no need of a mixer at all, and the logic coul= d > be directly implemented on each of the endpoints. Hi Cullen, could you please clarify this? I agree with Sergio: The mixer (or a media-server before it) has a DTLS and SRTP session with every participant, so it *already* has to decrypt the received SRTP (and hence it can decrypt the encrypted RTP header as well) before processing the media in a mixing fashion (or whichever it does with it). Thanks. --=20 I=C3=B1aki Baz Castillo From nobody Wed Mar 5 08:27:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCDE1A0760 for ; Wed, 5 Mar 2014 08:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.547, 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 sumjaOix0Qru for ; Wed, 5 Mar 2014 08:27:21 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C40A31A01D8 for ; Wed, 5 Mar 2014 08:27:20 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id db12so1264465veb.24 for ; Wed, 05 Mar 2014 08:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=zKIdRqnwCH04JVF3cBzI77J048NhQ8ju8CeXIo91SSY=; b=EKeNIPYW3M1I3rGixIH0xR1dQsFdZ/IRwqZLQNC5t7ekAH8QOC41c7AXxn7+03gTGL ZeWBn/Scx5PYWLBJFdZR2vK4pgDoaa9D/ysXEiYsHw0/SaJ/E0VubtMbVYSh2Bj6Ww2U mnF4h8mHs9tYYf2D4TilWLWrpZzDCO8OEWIw2sr//RbJNmG8zi3XiT5qiobCox7hFbHO +EM1JEJO+XPxbJ82euaIwaAhQrU3UTX0CRSVv694qXAPHrE9PImBeFha7CLIwy9gEulQ A9y2IbkmFubTNDph7HBXVnARGFQV7bMDxLycByaQZyFr7U+mMQ8GVWfkGIywHsI4Eon9 5Skg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=zKIdRqnwCH04JVF3cBzI77J048NhQ8ju8CeXIo91SSY=; b=GwB8EmxApLkTw3tQWrAbBGCzLhQyEwXdtyJu9bAyUfgh78x5w0pxDoJ/L88RcxtBTM 9jKSSZat2ooyf8+7SOM429u8Hc/SZs/5rFxaSp1yx7S+UHLWTGtvu9LxSGM9Nr0JjE6C MClCkdLAIrVId2a/AHjVAAfaQOAwXyqh1OD1dFKYvEXtarnZ5yzdXyuAjhz6OaNlNknb 8WDDFmAOVei8oz7p5kYOwqM/Q2D+gux+trSZnUIfhNdZVA4WRIYQJuBZGYhjhW/5DW7W X7x7HQDZfe6nQojXUS5wa300JYXThPTrKtYFVldBjraL4RBMN4vICxJs+I+d8+qHcofM KUVw== X-Gm-Message-State: ALoCoQlgxWNjr20POCRHOZxXNzvsKI1arlhVoB09zSXyJDFJisdwJJBEymj2+HI//8X6UbfDrtL41BZuI2T6p6u0hHmgiRBmJVnIGbukA8tCAotTwEV4/IpiBXhy/yOAqX6AglJq9kahwr0yBVoCpsVyfaYwO6C7ZeDW3a6dr3KqPaAIh08ERtF/ErxQz3f3xpFEYpOIqYz+ X-Received: by 10.221.40.10 with SMTP id to10mr717002vcb.22.1394036836971; Wed, 05 Mar 2014 08:27:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 5 Mar 2014 08:26:56 -0800 (PST) From: Justin Uberti Date: Wed, 5 Mar 2014 16:26:56 +0000 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1133757678c54c04f3de7e6c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-530QfcgrLwwTFV0v4XBA9ydu08 Subject: [rtcweb] On ptimes and maxptimes 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, 05 Mar 2014 16:27:22 -0000 --001a1133757678c54c04f3de7e6c Content-Type: text/plain; charset=UTF-8 >From the session this morning, I recall this consensus: - We will add recommendations on the frame sizes to use for PCMU/A to the rtcweb audio codec I-D (20, 30, 60 ms frames). - We will consider adding an a=maxptime attribute that represents the "minimum maxptime" of all the offered codecs. That is, if both Opus (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a maxptime=60 SHOULD be included. - Since maxptime spans all codecs, this means that some modes (e.g. Opus 120ms) will be unavailable, unless only Opus is offered. - We will consider adding an a=ptime attribute, set to the receiver's preferred frame size to receive. Again, this value spans all codecs, so the specified value may not be viable for all codecs (e.g. 30 ms works for PCMU but not for Opus) After thinking about this some, I'm not sure the maxptime/ptime values will lead to any different behavior than if they were not specified. Since there is a complexity cost (especially if the values need to change based on which codecs are offered), is there a clear upside here? --001a1133757678c54c04f3de7e6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the session this morning, I recall this consensus:
  • We will add recommendations on the frame sizes to use for PCMU/A = to the rtcweb audio codec I-D (20, 30, 60 ms frames).
  • We will consi= der adding an a=3Dmaxptime attribute that represents the "minimum maxp= time" of all the offered codecs. That is, if both Opus (maxptime of 12= 0ms) and PCMU (maxptime of 60) are offered, a maxptime=3D60 SHOULD be inclu= ded.
    • Since maxptime spans all codecs, this means that some modes (e.g. O= pus 120ms) will be unavailable, unless only Opus is offered.
  • W= e will consider adding an a=3Dptime attribute, set to the receiver's pr= eferred frame size to receive. Again, this value spans all codecs, so the s= pecified value may not be viable for all codecs (e.g. 30 ms works for PCMU = but not for Opus)
After thinking about this some, I'm not sure the maxptime/pti= me values will lead to any different behavior than if they were not specifi= ed. Since there is a complexity cost (especially if the values need to chan= ge based on which codecs are offered), is there a clear upside here?
--001a1133757678c54c04f3de7e6c-- From nobody Wed Mar 5 08:28:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B751A06E5 for ; Wed, 5 Mar 2014 08:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 yH-yMEXyCsVq for ; Wed, 5 Mar 2014 08:28:19 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF01A01BF for ; Wed, 5 Mar 2014 08:28:18 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id oy12so1270641veb.26 for ; Wed, 05 Mar 2014 08:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rvuQEFM7j9tHVvoQ73iFYVi33+o8TDM03bARMTjhYIk=; b=YmVTwMlMKVLIa7U3CebyvfzyPdojmXjHou2lUQefFn3PMTJvcnJm5z5HUVqdJYaYSh 9vqt6v+wb8s6H4wXek7/ehmF5ZIW5omWjb/QDiBuoWw5lHariqRK3rx+xbMxaIoj7RJw vhVnFJRJkZftZYrNkOPgKUTV++aSZ/80wzdzUFa1OR5yhNVPvMJ9vQ0hOfGQ6cMj15rN mlbVvZxhfLOjHMr3eZTQo3W13RdA8DwqwHKl8zLUkmiT82nv12mlgtMljIgy1KzXDZoA 8oZFDYJikZHZ8OrcqjpB+/HztVck2o7vr7w74n4KbGiQdF019HkiQWyV6WREeeawU33u dZ/g== 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=rvuQEFM7j9tHVvoQ73iFYVi33+o8TDM03bARMTjhYIk=; b=IkQwgEBL0+lNsZIO/Jq5aAA3vJOG3o5903g71k8eMSf5omOM5umcKY1pKSFSSIwa5D 5ceaPCxDPgFMV4mAC/D2QBBYHf1oCqaRVr1RqshJev1UbC/vkxrNa+DRBWRlW/ecK8FK ps03BVCWmxADTsaNg9vbtBUjm0v3/jxqYS4JlMNqikssytovgSg8d3xD4rg1+znl1ik2 SQ92iAsQLKoDARN7jFrdUx2lbEslENTPVYumytDJmBRKkcXh1/f4QeAHVF/Yi+xaEWvd WJ257HAnygJEoiBx/66VR1XXmG2rDN88H1YDCXeIFFZ8lb1NqaeJNUxYaqjV+gm/Oesz z/2w== X-Gm-Message-State: ALoCoQk8suaZVp65W2IW+iFFYD4axivSy6qRdcgnHUhTsdmflsyKv8l60mINlahUSlKbEQjNHLt8R2wELccmVVfSHqZVch+8+Xp7Epl8v492o4wVC7pTsZbvkyM8aTi9CFiyUP6vvHlEhz8pFA5aMRsj0ACI0rvFcV1hnU9haxYCCcoyGxyw75Idbd8xB3pZppFVi3MEbs14 X-Received: by 10.52.189.33 with SMTP id gf1mr4323590vdc.26.1394036895188; Wed, 05 Mar 2014 08:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 5 Mar 2014 08:27:55 -0800 (PST) In-Reply-To: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> From: Justin Uberti Date: Wed, 5 Mar 2014 16:27:55 +0000 Message-ID: To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=001a1136b262f1281604f3de8165 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Yg2sl43HWnJIVlXp1hnGgYfGrRY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 16:28:21 -0000 --001a1136b262f1281604f3de8165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good point on isolating TCP to the short legs. On Wed, Mar 5, 2014 at 3:55 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > +1 given that it still works for those 0.9%, it just hits two TURN > servers... And with luck, that actually is better because if they each > select TURN servers well you get TCP on the short legs and UDP on the lon= g > leg. > > Matthew Kaufman > > Sent from my iPad > > On Mar 5, 2014, at 7:32 AM, "Justin Uberti" wrote: > > I am assuming 3% as the case where TCP is needed to get through > UDP-blocking firewalls, based on empirical data from QUIC testing in Chro= me > over a very large population. > > Since TURN TCP candidates (not to be confused with TURN/TCP to connect > to the TURN server) are only useful in the case where BOTH sides are behi= nd > such firewalls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN T= CP > candidates are useful. As an optimization, I don't think this is worth > worrying about. > > > On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino wrote: > >> Agree on the cost concern. Not sure I fully understand the context >> though. Is ~.09% the estimated percentage of times that TCP will be the >> only way to get through UDP-blocking firewalls, or am I mis-understandin= g >> the use case? >> >> If it does refer to the UDP-blocking, what data is it based on? I do >> know large enterprise firewalls skew significantly higher on UDP blockin= g, >> but I suspect SMB and residential perhaps are more UDP-permissive by >> default (but have never seen extensive data that is not biased by the >> sampling). >> >> >> >> >> On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti wrot= e: >> >>> From the transports draft, Section 3.4: >>> >>> TURN TCP candidates [RFC6062 ] = SHOULD be supported; this allows >>> applications to achieve peer-to-peer communication when both parties >>> are behind UDP-blocking firewalls using a single TURN server. (In >>> this case, one can also achieve communication using two TURN servers >>> that use TCP between the server and the client, and UDP between the >>> TURN servers.) >>> >>> >>> I don't think we want to do this. The optimization of having a single v= s two TURN servers in the .09% case is not worth the implementation or runt= ime cost of allocating TURN TCP candidates. It requires a TCP connection to= the TURN server, which we would otherwise not do except in fallback cases. >>> >>> >>> _______________________________________________ >>> 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 > > --001a1136b262f1281604f3de8165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good point on isolating TCP to the short legs.


On Wed, Mar 5, 2014= at 3:55 PM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:
+1 given that it still works for those 0.9%, it just hits two TURN ser= vers... And with luck, that actually is better because if they each select = TURN servers well you get TCP on the short legs and UDP on the long leg.
Matthew Kaufman

Sent from my iPad
I am assuming 3% as the case where TCP is needed to get th= rough UDP-blocking firewalls, based on empirical data from QUIC testing in = Chrome over a very large population.

Since TURN TCP candidates (not to be confused with TURN/TCP to connect= to the TURN server) are only useful in the case where BOTH sides are behin= d such firewalls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN T= CP candidates are useful. As an optimization, I don't think this is worth worrying about.


On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino <gilzino@gmail.co= m> wrote:
Agree on the cost concern. =C2=A0Not sure I fully understa= nd the context though. =C2=A0Is ~.09% the estimated percentage of times tha= t TCP will be the only way to get through UDP-blocking firewalls, or am I m= is-understanding the use case? =C2=A0

If it does refer to the UDP-blocking, what data is it based on? =C2=A0= I do know large enterprise firewalls skew significantly higher on UDP block= ing, but I suspect SMB and residential perhaps are more UDP-permissive by d= efault (but have never seen extensive data that is not biased by the sampling).




On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
From the transports draft, Section 3.4: 

   TURN TCP c=
andidates [RFC6062] SHOULD be supported; this allows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

I don't think we want to do this. The op=
timization of having a single vs two TURN servers in the .09% case is not w=
orth the implementation or runtime cost of allocating TURN TCP candidates. =
It requires a TCP connection to the TURN server, which we would otherwise n=
ot do except in fallback cases.

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



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

--001a1136b262f1281604f3de8165-- From nobody Wed Mar 5 08:28:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4991A0767 for ; Wed, 5 Mar 2014 08:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LnUj5wchnEA2 for ; Wed, 5 Mar 2014 08:28:50 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.18]) by ietfa.amsl.com (Postfix) with ESMTP id D2F5A1A01BF for ; Wed, 5 Mar 2014 08:28:49 -0800 (PST) Received: from userPC (unknown [122.167.230.131]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 4387A6381EC; Wed, 5 Mar 2014 16:28:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1394036925; bh=GO4uqPC7gJyKH1mot3416GcJO5xCbnJylKWNi8FzR9w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ZokHg8XllDmbYZRSBF7NgFUcDDFaEKuSqmXt3UgX4Y/gXoHItBWoHdMqnYbdSr8wr nxN9XEJKazLZvDtwNiDDbXFrjUDX5rHWJXjI8wm2dlHnAxMjEfPOTxBY3Dw7jji3dz VzYb4YKenCnEhnIPHO3OJSBBGFLCI0GFYMNbJxqk= From: "Parthasarathi R" To: "'Justin Uberti'" , "'Simon Perreault'" References: <531740DD.5030700@viagenie.ca> In-Reply-To: Date: Wed, 5 Mar 2014 21:58:33 +0530 Message-ID: <00c901cf388f$f8146a40$e83d3ec0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CF38BE.11CCA640" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac84h2JrncnsPVouSfiltl4zwbL+mQABk5tw Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.531750BD.009F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.134 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d5oHlzy648Z1dxAoA90VCI_ji14 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 16:28:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CA_01CF38BE.11CCA640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable (TURN) relayed candidates MUST NOT be prioritized as it is always = possible to other high priority candidates succeed for the WebRTC = session. Also, TURN candidates is not required to be allocated for all = the session. Hope trickle ICE solve these problems as the allocation = shall happen. =20 IMO, it is very much possible to implement in the WebRTC network = (server/endpoint) without TURN server and with reduced WebRTC session = setup time. =20 Thanks Partha From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, March 05, 2014 8:57 PM To: Simon Perreault Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports questions on IPv6 =20 =20 =20 On Wed, Mar 5, 2014 at 3:21 PM, Simon Perreault = wrote: Le 2014-03-05 14:56, Justin Uberti a =C3=A9crit : > I think this needs clarification. Does this mean that we should = allocate v6 candidates from all v4 interfaces (for compat with v6-only = endpoints), as well as allocate v4 candidates from all v6 interfaces = (for compat with v4-only endpoints), and if so, which path (v6-to-TURN = or v6-from-TURN) should be prioritized? You must always allocate both v4 and v6 relayed candidates, irrespective of what other candidates you have. =20 I am fine with that - this needs to be added to the transports document = though. =20 Any thoughts on the prioritization question?=20 ------=_NextPart_000_00CA_01CF38BE.11CCA640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

(TURN) relayed candidates MUST NOT be prioritized as it = is always possible to other high priority candidates succeed for the WebRTC = session. Also, TURN candidates is not required to be allocated for all the = session. Hope trickle ICE solve these problems as the allocation shall = happen.

 

IMO, it is very much possible to implement in the WebRTC = network (server/endpoint) without TURN server and with reduced WebRTC session = setup time.

 

Thanks

Partha

From:= rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, March 05, 2014 8:57 PM
To: Simon Perreault
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Transports questions on = IPv6

 

 

 

On Wed, Mar 5, 2014 at 3:21 PM, Simon Perreault = <simon.perreault@viagenie.ca> wrote:

Le 2014-03-05 14:56, Justin Uberti a =C3=A9crit = :

> I think this = needs clarification. Does this mean that we should allocate v6 candidates from = all v4 interfaces (for compat with v6-only endpoints), as well as allocate v4 candidates from all v6 interfaces (for compat with v4-only endpoints), = and if so, which path (v6-to-TURN or v6-from-TURN) should be = prioritized?

You must always allocate both v4 and v6 relayed = candidates, irrespective
of what other candidates you have.

 

I am fine with that - this needs to be added to the transports document though.

 

Any thoughts on the prioritization = question? 

------=_NextPart_000_00CA_01CF38BE.11CCA640-- From nobody Wed Mar 5 08:30:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B381A0424 for ; Wed, 5 Mar 2014 08:30:57 -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 KUpXK5nLB7kG for ; Wed, 5 Mar 2014 08:30:55 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id BF8911A01BF for ; Wed, 5 Mar 2014 08:30:54 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id a1so1545985wgh.22 for ; Wed, 05 Mar 2014 08:30:50 -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=ggtw52GOVnCV2/lnPisBZjYOPmcMMY35GqS5F2NKAds=; b=MeshrUP3zVxfJoZKVgZ3yOapgxAHqvDFdULXld8SZZ2bb5ORTuhwuc8Sdj0wsQATRn vvFzxmttZ8mVzFcT1ttfvO69MZ5dRUnDO9E9vfM6AwrenbNZbmX1jhPyMfoG4xSt/pGH TfGqO9IcvgTWDb6aS4PP4wAVOq+m+JsswCQhLH+pMH3R594esYtaEUso8r+HbcLVEJNN Y1hKgbVKEFmAqcoq18CfncnO9RejDn6b5Un8iwOV8j5zWEL04hgkF7if/xySTNHsIyUF zkb+HzeF+Wx2si+Z9UZB8HkvkRevXdh+Mt0C0HtP4lJ0upcHLBaPgzo9wS28dLcE6JM9 cSKg== X-Received: by 10.194.85.168 with SMTP id i8mr2192585wjz.81.1394037039901; Wed, 05 Mar 2014 08:30:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.217.161.66 with HTTP; Wed, 5 Mar 2014 08:30:19 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 5 Mar 2014 16:30:19 +0000 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=089e010d7efc91310904f3de8afa Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y_qMuL4B8sRNLEKquxXkIJoNhIg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 16:30:57 -0000 --089e010d7efc91310904f3de8afa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Justin said: "Since TURN TCP candidates (not to be confused with TURN/TCP to connect to the TURN server) are only useful in the case where BOTH sides are behind such firewalls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN TCP candidates are useful. As an optimization, I don't think this is worth worrying about." [BA] +1. If TURN/TCP isn't sufficient to traverse the firewall then you've typically got a problem that TURN TCP candidates won't solve either. On Wed, Mar 5, 2014 at 3:31 PM, Justin Uberti wrote: > I am assuming 3% as the case where TCP is needed to get through > UDP-blocking firewalls, based on empirical data from QUIC testing in Chro= me > over a very large population. > > Since TURN TCP candidates (not to be confused with TURN/TCP to connect to > the TURN server) are only useful in the case where BOTH sides are behind > such firewalls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN T= CP > candidates are useful. As an optimization, I don't think this is worth > worrying about. > > > On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino wrote: > >> Agree on the cost concern. Not sure I fully understand the context >> though. Is ~.09% the estimated percentage of times that TCP will be the >> only way to get through UDP-blocking firewalls, or am I mis-understandin= g >> the use case? >> >> If it does refer to the UDP-blocking, what data is it based on? I do >> know large enterprise firewalls skew significantly higher on UDP blockin= g, >> but I suspect SMB and residential perhaps are more UDP-permissive by >> default (but have never seen extensive data that is not biased by the >> sampling). >> >> >> >> >> On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti wrote= : >> >>> From the transports draft, Section 3.4: >>> >>> >>> TURN TCP candidates [RFC6062 ] S= HOULD be supported; this allows >>> applications to achieve peer-to-peer communication when both parties >>> are behind UDP-blocking firewalls using a single TURN server. (In >>> this case, one can also achieve communication using two TURN servers >>> that use TCP between the server and the client, and UDP between the >>> TURN servers.) >>> >>> >>> I don't think we want to do this. The optimization of having a single v= s two TURN servers in the .09% case is not worth the implementation or runt= ime cost of allocating TURN TCP candidates. It requires a TCP connection to= the TURN server, which we would otherwise not do except in fallback cases. >>> >>> >>> _______________________________________________ >>> 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 > > --089e010d7efc91310904f3de8afa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Justin said:

"Since TU= RN TCP candidates (not to be confused with TURN/TCP to connect to the TURN = server) are only useful in the case where BOTH sides are behind such firewa= lls, 3% * 3% =3D=3D .09% is the fraction of calls where TURN TCP candidates= are useful. As an optimization, I don't think this is worth worrying a= bout."

[BA] +1.=A0

If TURN/TCP isn= 9;t sufficient to traverse the=A0firewall then you've typically got a p= roblem=A0that TURN TCP candidates won't solve either. =A0


On Wed, Mar 5, 2014 at 3:31 PM, Justin U= berti <juberti@google.com> wrote:
I am assuming 3% as the case where TCP is needed to get th= rough UDP-blocking firewalls, based on empirical data from QUIC testing in = Chrome over a very large population.

Since TURN TCP cand= idates (not to be confused with TURN/TCP to connect to the TURN server) are= only useful in the case where BOTH sides are behind such firewalls, 3% * 3= % =3D=3D .09% is the fraction of calls where TURN TCP candidates are useful= . As an optimization, I don't think this is worth worrying about.

On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino <= span dir=3D"ltr"><gilzino@gmail.com> wrote:
Agree on the cost concern. =A0Not sure I fully understand = the context though. =A0Is ~.09% the estimated percentage of times that TCP = will be the only way to get through UDP-blocking firewalls, or am I mis-und= erstanding the use case? =A0

If it does refer to the UDP-blocking, what data is it based = on? =A0I do know large enterprise firewalls skew significantly higher on UD= P blocking, but I suspect SMB and residential perhaps are more UDP-permissi= ve by default (but have never seen extensive data that is not biased by the= sampling).




On Wed, Mar 5, 2014 at 10:02 AM, Justin Ub= erti <juberti@google.com> wrote:
From the transports= draft, Section 3.4:

   TURN TCP candidates [RFC6062] SHOULD be supported; this all=
ows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

I don't think we wan=
t to do this. The optimization of having a single vs two TURN servers in th=
e .09% case is not worth the implementation or runtime cost of allocating T=
URN TCP candidates. It requires a TCP connection to the TURN server, which =
we would otherwise not do except in fallback cases.

_______________________________________________
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


--089e010d7efc91310904f3de8afa-- From nobody Wed Mar 5 08:35:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CB61A01BF for ; Wed, 5 Mar 2014 08:35:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHDQ8XO_t4f1 for ; Wed, 5 Mar 2014 08:35:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) by ietfa.amsl.com (Postfix) with ESMTP id CE6FE1A00E9 for ; Wed, 5 Mar 2014 08:35:13 -0800 (PST) Received: from BY2PR03CA052.namprd03.prod.outlook.com (10.141.249.25) by BY2PR03MB012.namprd03.prod.outlook.com (10.255.240.38) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 5 Mar 2014 16:35:08 +0000 Received: from BY2FFO11FD063.protection.gbl (2a01:111:f400:7c0c::125) by BY2PR03CA052.outlook.office365.com (2a01:111:e400:2c5d::25) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 16:35:08 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD063.mail.protection.outlook.com (10.1.15.197) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 16:35:08 +0000 Received: from TK5EX14MBXC296.redmond.corp.microsoft.com ([169.254.2.186]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0174.002; Wed, 5 Mar 2014 16:34:32 +0000 From: "Matthew Kaufman (SKYPE)" To: Sergio Garcia Murillo Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOG7/fizbxTQF/UyT77go6S8SfprShUWAgAAB54CAAAWJAIAAFmgAgAAKZoCAAAMxBA== Date: Wed, 5 Mar 2014 16:34:32 +0000 Message-ID: <212442C8-F66F-4D7A-B64D-C37629B1F710@skype.net> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> , <53174F6B.2030706@gmail.com> In-Reply-To: <53174F6B.2030706@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(51704005)(24454002)(189002)(199002)(479174003)(377454003)(52034003)(94946001)(84676001)(74502001)(69226001)(93136001)(31966008)(81816001)(56816005)(85306002)(47446002)(95416001)(82746002)(15975445006)(20776003)(87936001)(81686001)(86362001)(63696002)(83716003)(23746002)(53806001)(93516002)(54356001)(77982001)(59766001)(47776003)(6806004)(81342001)(81542001)(36756003)(74706001)(4396001)(44976005)(92566001)(76786001)(79102001)(76796001)(92726001)(51856001)(46102001)(19580405001)(77096001)(83322001)(50986001)(76482001)(54316002)(80022001)(87266001)(95666003)(33656001)(19580395003)(90146001)(83072002)(85852003)(47736001)(49866001)(47976001)(80976001)(2656002)(94316002)(65816001)(74876001)(74366001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB012; H:mail.microsoft.com; FPR:F4DAF53D.ACD88BDB.3DD8954B.42E3DBC1.20274; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01415BB535 Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tV5FrA8Q-IPZLwQgwq4FPJIZ-K8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 16:35:16 -0000 EKT is one possible answer to this concern. By the way: If and when we specify EKT for RTCWEB, there is a simple rule w= e should establish: A "browser" must not initiate the use of EKT. That way,= browser to browser sessions would be unable to force a known key... That c= ould only happen when talking to non-browser endpoints (likely mixers) Matthew Kaufman Sent from my iPad > On Mar 5, 2014, at 8:23 AM, "Sergio Garcia Murillo" wrote: >=20 > El 05/03/2014 16:45, Jonathan Lennox escribi=F3: >>=20 >> That said, I=92m not sure I believe in Cullen=92s use case =97 there=92s= too much other information that this unauthorized conference mixer wouldn= =92t be able to do. (e.g., request I-frames, or detect them, for switching= ; or generate proper RTCP reports for sometimes-on streams).=20 >=20 > I have deeper doubts, I don't really know how a RTP router/mixer would be= able to work without acting as DTLS endpoint and decripting/encripting the= RTP data. Or is there a way to setup/share a DTLS session between more th= an two peers so the same DTLS/SRTP packet is decriptable by more than one r= eceiver? >=20 > Best regards > Sergio > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Mar 5 08:41:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104B81A012A for ; Wed, 5 Mar 2014 08:41:06 -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 obAUz6Bt8TgI for ; Wed, 5 Mar 2014 08:41:03 -0800 (PST) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5521A00A3 for ; Wed, 5 Mar 2014 08:41:03 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id d49so579566eek.41 for ; Wed, 05 Mar 2014 08:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lTiSg9RfP1ryrMftW8DxGhzK0Kpg4iKR+5wX1bKAlWk=; b=F8tYaZ/04wDkhuroJN1PqfCqRRZRDaiDrwuVxI9A5tITyQFiPeKgqQaxpCcy3Zz5P/ xsQbJen/i2JBCF9jY471GBLhODO8Fgr+bbgv0xvTofikrU2Crss1QxXy5qQsB8Slb3Xg R+Unb38oiQOPVNdKBslWk0AwG+g2WFvYK8g/TN+/9D9T1Em5QVBznGmpGvZbOzZLO0ih w+smNDxe3r5q4wCBWItODn/lK9zHqwXMiQoVDgt7gwyGFGlwZ/vcsUdZgNSU6xAscyUv 4e5OrvYj/u+gmMjRH9IADbJ6/hsJNRJb5Ajr08TxUMtgud335xM2Ni9/dmtQ8qaj9ri5 +XmQ== X-Received: by 10.15.21.2 with SMTP id c2mr6828722eeu.77.1394037659449; Wed, 05 Mar 2014 08:40:59 -0800 (PST) Received: from [192.168.1.35] (105.Red-81-33-134.dynamicIP.rima-tde.net. [81.33.134.105]) by mx.google.com with ESMTPSA id m9sm10939262eeh.3.2014.03.05.08.40.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 08:40:58 -0800 (PST) Message-ID: <5317539C.7020305@gmail.com> Date: Wed, 05 Mar 2014 17:41:00 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Matthew Kaufman (SKYPE)" References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> , <53174F6B.2030706@gmail.com> <212442C8-F66F-4D7A-B64D-C37629B1F710@skype.net> In-Reply-To: <212442C8-F66F-4D7A-B64D-C37629B1F710@skype.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VxvbK-QCvXgbl5AjOmQ1i2uqtHs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 16:41:06 -0000 In that case, we could link the usage of EKT to unencripted rtp header extensions (and not only audio-to-mixer level), moreover as you suggest that it would not be enabled in P2P communications and only when a mixer is involved. Best regards Sergio El 05/03/2014 17:34, Matthew Kaufman (SKYPE) escribió: > EKT is one possible answer to this concern. > > By the way: If and when we specify EKT for RTCWEB, there is a simple rule we should establish: A "browser" must not initiate the use of EKT. That way, browser to browser sessions would be unable to force a known key... That could only happen when talking to non-browser endpoints (likely mixers) > > Matthew Kaufman > > Sent from my iPad > >> On Mar 5, 2014, at 8:23 AM, "Sergio Garcia Murillo" wrote: >> >> El 05/03/2014 16:45, Jonathan Lennox escribió: >>> That said, I’m not sure I believe in Cullen’s use case — there’s too much other information that this unauthorized conference mixer wouldn’t be able to do. (e.g., request I-frames, or detect them, for switching; or generate proper RTCP reports for sometimes-on streams). >> I have deeper doubts, I don't really know how a RTP router/mixer would be able to work without acting as DTLS endpoint and decripting/encripting the RTP data. Or is there a way to setup/share a DTLS session between more than two peers so the same DTLS/SRTP packet is decriptable by more than one receiver? >> >> Best regards >> Sergio >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Mar 5 08:46:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3661A0140 for ; Wed, 5 Mar 2014 08:46:54 -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 u96mW-yYh8WI for ; Wed, 5 Mar 2014 08:46:53 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3411A0652 for ; Wed, 5 Mar 2014 08:46:53 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so1577419wgh.12 for ; Wed, 05 Mar 2014 08:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pyvmGb7t9UlGKSy34tw2A/kWyAG1HfllaQQRSJsi3io=; b=l7AoTNvUgv2AHR4z/NCtWOfc9OIEjuekVQvHt7EDx+IqjEp7WKLxayvy3Jka3NDIBe 8ZqR0PpFolqqnN0OMW7JqQlOVcFeeq1PCDU/ooSB+x6LeoCF1/X/tXdGEL38EWBxSYZX /PokZQu6rqp2bHO09N++z4xBaP7nxcOrr/wb5oOsP4pDpe5IPLcYBgAth2KWsEszmDap DV8NS0VeHeiSm83riyQsapgovi72wJ2VOLsdrBFpvHOV9MpATayUJw1NyZK72UD/HF8K Hk7xR1Jpi/Rdk1iYbrl5Z1xRFpnddrTt+FRtBQcaYb4TGMy//Ff/4XDlAIJ/+UWTt2AD gUfA== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr2602154wjc.56.1394038009512; Wed, 05 Mar 2014 08:46:49 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 08:46:49 -0800 (PST) In-Reply-To: <212442C8-F66F-4D7A-B64D-C37629B1F710@skype.net> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> <53174F6B.2030706@gmail.com> <212442C8-F66F-4D7A-B64D-C37629B1F710@skype.net> Date: Wed, 5 Mar 2014 16:46:49 +0000 Message-ID: From: Martin Thomson To: "Matthew Kaufman (SKYPE)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/S1GbIXBFN0qENyqpUFNtnWLUsEk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 05 Mar 2014 16:46:55 -0000 On 5 March 2014 16:34, Matthew Kaufman (SKYPE) wrote: > By the way: If and when we specify EKT for RTCWEB, there is a simple rule= we should establish: A "browser" must not initiate the use of EKT. That wa= y, browser to browser sessions would be unable to force a known key... That= could only happen when talking to non-browser endpoints (likely mixers) I've talked to several people about this and we all agree on this point. It's important, if browsers ever implement EKT. We might also require that "private" sessions not accept attempts to use EKT too. From nobody Wed Mar 5 09:04:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6151A0448 for ; Wed, 5 Mar 2014 09:04:21 -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 IsRUaZ1jEC1U for ; Wed, 5 Mar 2014 09:04:20 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id F1C6C1A06A4 for ; Wed, 5 Mar 2014 09:04:19 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id p61so1533132wes.41 for ; Wed, 05 Mar 2014 09:04:15 -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=OwUSWq/s8GGx5pwyU02gCTBw2/2HeKYZSOsXin0wIYU=; b=r3zZB1e/aidVPR6BzJ31vG1u38EWYWdkvjvYFpXl6DRgep+iRJ4pWdWe9Rp0D4u1YP h2vKkDpbUYkkpDHkwGs6kpNYZkCchl/uSZ0Egteqlm8+4JPuT6pwvtkrYEtkCUABkpZX ipw15jswmfkecUXQoO37xSwewBFSlRvQSYkS3YcNK53EJ3q1xgf4oBJjDpya6LCiCd8d qk3M97zSQFZkQLd3efMz38aJISHfzHWVC2snsQLs+QyzAdIs4k/HwTj7/WWqhdZScAUs 3kD4Uqk+nSFF09QDKV4ZrcIDHmBi9d9cO19y3zXe3qGP55oXNDUk/KaS0soQaM8wXdCj 5Vwg== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr2823290wjb.28.1394039055775; Wed, 05 Mar 2014 09:04:15 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 09:04:15 -0800 (PST) In-Reply-To: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> Date: Wed, 5 Mar 2014 17:04:15 +0000 Message-ID: From: Martin Thomson To: "Matthew Kaufman (SKYPE)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/f5dqiMDICWQsBwzKYjrR50GueS0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 17:04:21 -0000 On 5 March 2014 15:55, Matthew Kaufman (SKYPE) wrote: > +1 given that it still works for those 0.9%, it just hits two TURN > servers... And with luck, that actually is better because if they each > select TURN servers well you get TCP on the short legs and UDP on the long > leg. Agree. From nobody Wed Mar 5 10:16:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD6A1A00BB for ; Wed, 5 Mar 2014 10:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RP_MATCHES_RCVD=-0.547, 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 pOBKMKyz-z15 for ; Wed, 5 Mar 2014 10:16:25 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0537D1A012A for ; Wed, 5 Mar 2014 10:16:24 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so1400167vcb.19 for ; Wed, 05 Mar 2014 10:16:20 -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=Mmhif3hRSLf32twtDDDQl2QWtUGuO7h5oRD4+ejs0CQ=; b=VhYx24uUG3OLjIFBacPsc24xOVnRKFrijST0BnCX3H7B8jUqpri8x2PQDgUxM49ItF NHbVJDj4kHUPXHkhGTDvHW8KSsWnEvjrslMO8YeddKz0Lnkc5H7fn5kU0TBYW5T4TRMp 30wubv5s5gtIglho8I9XErReE7gZqS00/JcvM4OsN1UarhkwV1YkQIxSKQppXJtcqTgI T376iSFldMJuhZ3MefUzxGFQqHr2he7dkSRlWEfLtLvtH6tn2LPZzaVaaAcrcbfNUehH 3ofsFJjDk2x/9fUdV/7gP4NVDNYn5vM45S6ts2Q6zVnPJ/LBWuCr6J/Nifd3XmBAyMgj A+Eg== 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=Mmhif3hRSLf32twtDDDQl2QWtUGuO7h5oRD4+ejs0CQ=; b=Pb/ySJItt/NNqYZfMUS4syLku6VrbL+d5rkGKFeyBPJrVL77XeI4O66BH97ft/1/13 GytdIwboZR6A4FndAZHR8gZVEv3j+HYX+I9QwsUtVh+VcHPFVCM/5ZrMmMEwLrv/jXRa 6AMnOgM8LGonnoWH3oijOGkXKtZGwBxa8klgUbxgZZqxZODyQYcz1am9zz9KvAoai0SQ gh/QAYigBHBuM4qqfanMzvDx/92Jjzf0LfcIhKYDHjdIzr+3u+ockKaiKcYx+xZMbIHf xa7EH8QNpIGvcEKX1fQ2Qpq9MrfIyEy+qYdbuSuCbgjAqG5Q5bXn1bePNUIXts7mfNv1 i+/A== X-Gm-Message-State: ALoCoQldnXn9Jv+HLWs6er7XBNpCHAdf5ABqzaIcbS2sdd+zSWHy+8ipuy/7hOhsewXxoh8qOQ24HYk+tUb5uuWc/r3r+YN6K1rCTIq22qo0rwGZ5/5GxevCAyk/Hi2vqQNGP2VHpAEWEnwXVwhap6lly8lQCIH3ZlHKRZN2tcIzOOrsD7VcVa1sK4JuZZmd5vbI5BTzfdHA X-Received: by 10.58.228.35 with SMTP id sf3mr1209678vec.7.1394043380667; Wed, 05 Mar 2014 10:16:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 5 Mar 2014 10:16:00 -0800 (PST) In-Reply-To: <5317490E.3090701@viagenie.ca> References: <5317490E.3090701@viagenie.ca> From: Justin Uberti Date: Wed, 5 Mar 2014 18:16:00 +0000 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7bdc969c81b35304f3e0040e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6fFi5UoPlyYHTmW8bRgrv8pWpR4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 18:16:28 -0000 --047d7bdc969c81b35304f3e0040e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 5, 2014 at 3:55 PM, Simon Perreault wrote: > Since you asked for more... > > Le 2014-03-05 14:56, Justin Uberti a =C3=A9crit : > > which path (v6-to-TURN or v6-from-TURN) should be prioritized? > > I'm sorry, I don't understand this question. > Imagine I am a v6-only endpoint. Via IPv6, I allocate 2 ports on the TURN server, v4 and v6. The remote client is v4-only, and via IPv4 it also allocates v4 and v6 on its TURN server. So we need to relay to connect v4 and v6. Which path should be preferred? a) Caller -- TURN/v6 --> TURN Server(Caller, v4 alloc) <-- v4 -- Callee [ Caller candidate is relay, Callee candidate is host ] b) Caller -- v6 --> TURN Server(Callee, v6 alloc) <-- TURN/v4 -- Callee [ Caller candidate is host, Callee candidate is relay ] I worked this through and I think ICE will choose (b), due to the (G>D?1:0) tiebreaker, which seems right to me. So no action needed :) > > Note also that these v4->v6 or v6->v4 allocations will be dependent on > the SSODA work being discussed in TRAM, since this is the only way to > allocate v4 and v6 TURN from a single host candidate. > > I don't understand what you mean. > I was assuming that WebRTC endpoints will need to do cross-family allocations, to handle the case where they are talking to a v4-only or v6-only endpoint and they are not v4- or v6- capable. If so, the transports draft will need to reference the SSODA work once it becomes a WG item, since I don't think WebRTC endpoints should create additional sockets to do cross-family allocations (we have enough sockets already, as shown below). > > Also worth noting: > > > > With the current default settings, a single STUN and TURN server, and > assuming a dual-stack host with two network interfaces, a PeerConnection > with audio, video, and data will generate > > > > 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * 2 > (IP protocols) =3D 80 candidates > > It's....... it's beautiful! > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bdc969c81b35304f3e0040e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 5, 2014 at 3:55 PM, Simon Perreault &= lt;simon.p= erreault@viagenie.ca> wrote:
Since you asked for more...

Le 2014-03-05 14:56, Justin Uberti a =C3=A9crit :
> which path (v6-to-TURN or v6-from-TURN) should be prioritiz= ed?

I'm sorry, I don't understand this question.
=

Imagine I am a v6-only endpoint. Via IPv6, I allocate 2= ports on the TURN server, v4 and v6. The remote client is v4-only, and via= IPv4 it also allocates v4 and v6 on its TURN server. So we need to relay t= o connect v4 and v6. Which path should be preferred?

a) Caller -- TURN/v6 --> TURN Server(Caller, v4 allo= c) <-- v4 -- Callee
[ Caller candidate is relay, Callee candid= ate is host ]
b) Caller -- v6 --> TURN Server(Callee, v6 alloc= ) <-- TURN/v4 -- Callee
[ Caller candidate is host, Callee candidate is relay ]

=
I worked this through and I think ICE will choose (b), due to th= e (G>D?1:0) tiebreaker, which seems right to me. So no action needed :)<= /div>



> Note also that these v4->v6 or v6->v4 allocations will be depend= ent on the SSODA work being discussed in TRAM, since this is the only way t= o allocate v4 and v6 TURN from a single host candidate.

I don't understand what you mean.

=
I was assuming that WebRTC endpoints will need to do cross-family allo= cations, to handle the case where they are talking to a v4-only or v6-only = endpoint and they are not v4- or v6- capable. If so, the transports draft w= ill need to reference the SSODA work once it becomes a WG item, since I don= 't think WebRTC endpoints should create additional sockets to do cross-= family allocations (we have enough sockets already, as shown below).


> Also worth noting:
>
> With the current default settings, a single STUN and TURN server, and = assuming a dual-stack host with two network interfaces, a PeerConnection wi= th audio, video, and data will generate
>
> 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * = 2 (IP protocols) =3D 80 candidates

It's....... it's beautiful!

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=

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

--047d7bdc969c81b35304f3e0040e-- From nobody Wed Mar 5 10:33:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225E51A020B for ; Wed, 5 Mar 2014 10:33:26 -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 Ov5FnKH6zvLA for ; Wed, 5 Mar 2014 10:33:21 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8514B1A01DD for ; Wed, 5 Mar 2014 10:33:16 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id x13so1731236wgg.26 for ; Wed, 05 Mar 2014 10:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Cl3EwBZ/yM83Tle0fjxDxQ7oOoOvt4r7GH1/WUugbQ=; b=q6pIJj7xQFtck8/umt814KTwWW4bOsm/PsHFHp3kxw9MC1AUOueg4DN+7HIw5U0umL 90H26rNbi2OU567K5meqc4teCI3HvCq4nGwYMX5ok/nd7P8KEfG0pJoKSFN6zRsgGqGS KyB0qXk1KO2Xu7N1pAT1mOqodh9YhkgYMkhkixI76RD1GgxQOC93vHuzuP4aktoiyAKu LyQl2OQlYjRo5wE3kVZRrfxWYPhJ7MNB8u+LznqXivKgfLQ6VsuA3XKQ7xN10xu+sjhc hCHgFQdMm/fa8QyzJvQhEmDCH37XCz5HY8TuWlxU1gA+EoZ5IbgoVQA7pdjzhTfSGnpw 6wiA== MIME-Version: 1.0 X-Received: by 10.194.174.197 with SMTP id bu5mr3077645wjc.71.1394044392535; Wed, 05 Mar 2014 10:33:12 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 10:33:12 -0800 (PST) In-Reply-To: References: <5317490E.3090701@viagenie.ca> Date: Wed, 5 Mar 2014 18:33:12 +0000 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/s3h7OYHglsB0k5zmMwamQuHZpN4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 18:33:26 -0000 On 5 March 2014 18:16, Justin Uberti wrote: > I worked this through and I think ICE will choose (b), due to the (G>D?1:0) > tiebreaker, which seems right to me. So no action needed :) Isn't it the case that you can assign different local priorities to these to get the result that you need/want such that the tie breaker is not necessary. I would suggest that ICE would prefer the v6-all-the-way option, but the happy eyeballs stuff might cause the precedence to flip. From nobody Wed Mar 5 10:35:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A891A0270 for ; Wed, 5 Mar 2014 10:35:01 -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 Ui_hh6nO4bNl for ; Wed, 5 Mar 2014 10:34:59 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 74E971A01A8 for ; Wed, 5 Mar 2014 10:34:59 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id x12so1761418wgg.30 for ; Wed, 05 Mar 2014 10:34: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=a2T9LEYRR82EwW15SOJ+kaqZx1TNQ5RgrWEvQdYFgD0=; b=T+GxvNl8wHgv3aoGWBW8km9PRxXpHSeCDMCOSdCQ94z5OyXrnHi2PRV5BLLGSNOhPM F0eHQVch4mWDwhoRKVeaF8DzF7FQzrpkYJ9MzzRWZeHNnFSEVQFK7vRwILThOU/cu+tW 4vaJrzsaZAl9vOdcQFPrpQQIdsl8D2thyD3B6QVS842/NxSRo9SWGtRwsReadMU3g3CB WrtkVqqeTNqs+nwnt9fLPST7uR5QOs4ltR2nEQ/xmWQISJpAOth38QlxiPkIswFw3MDX /fsZrYGqcTTk6L/UwvOo0528Swg84J0aqSd5hldZqrWJOuSS9YvLse8slw4lOIKIzyDM unvw== MIME-Version: 1.0 X-Received: by 10.194.170.167 with SMTP id an7mr3244908wjc.39.1394044495267; Wed, 05 Mar 2014 10:34:55 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 10:34:55 -0800 (PST) In-Reply-To: <5317490E.3090701@viagenie.ca> References: <5317490E.3090701@viagenie.ca> Date: Wed, 5 Mar 2014 18:34:55 +0000 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SkE-XuEp8yT7pxGYH1LctmZDEWI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 18:35:01 -0000 On 5 March 2014 15:55, Simon Perreault wrote: >> 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * 2 (IP protocols) = 80 candidates > > It's....... it's beautiful! Indeed! Now imagine pairing those. From nobody Wed Mar 5 10:54:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720621A024C for ; Wed, 5 Mar 2014 10:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 gTBVfSLFyf4E for ; Wed, 5 Mar 2014 10:53:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D19211A0162 for ; Wed, 5 Mar 2014 10:53:58 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C78384040A; Wed, 5 Mar 2014 13:53:54 -0500 (EST) Message-ID: <531772C2.7040306@viagenie.ca> Date: Wed, 05 Mar 2014 18:53:54 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <5317490E.3090701@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ePs8IGEibHh2ULtytTbMdXXDN50 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 18:54:03 -0000 Le 2014-03-05 18:34, Martin Thomson a écrit : > On 5 March 2014 15:55, Simon Perreault wrote: >>> 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * 2 (IP protocols) = 80 candidates >> >> It's....... it's beautiful! > > Indeed! Now imagine pairing those. 5 * ( 16 * 15 / 2 ) = 600 pairs A marvel of engineering! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 5 11:26:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D01A02AD for ; Wed, 5 Mar 2014 11:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 tskBfyPEs7vg for ; Wed, 5 Mar 2014 11:26:26 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A44221A0275 for ; Wed, 5 Mar 2014 11:26:26 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C78B54040A for ; Wed, 5 Mar 2014 14:26:22 -0500 (EST) Message-ID: <53177A5E.7030704@viagenie.ca> Date: Wed, 05 Mar 2014 19:26:22 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> In-Reply-To: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WVHjKXaBL3Y4z5Jf5gzMff8SNCU Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 19:26:28 -0000 Le 2014-03-05 15:55, Matthew Kaufman (SKYPE) a écrit : > if they each select TURN servers well you get TCP on the short legs and > UDP on the long leg. How would they "select TURN servers well"? We have a milestone for solving that problem in TRAM, and no draft currently adopted for it. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 5 11:30:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7821A0275 for ; Wed, 5 Mar 2014 11:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 GQHsGlQdkw4h for ; Wed, 5 Mar 2014 11:30:31 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6959B1A0418 for ; Wed, 5 Mar 2014 11:30:13 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id pa12so1564634veb.29 for ; Wed, 05 Mar 2014 11:30:09 -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=WDf5TJE4tDXcMZvyyLd4jjts/mmkyQoqng5BYJx0Gjk=; b=ml4otlKoidA2JsI8KqGxY7oorkD54uL8aUgjsHg6EtTN2uV6Y+9ezvwdQPXCY06m7l fGpbezA2QXemeK0FuEJ3fherQSi2EsUvLo+rKIhBZH/msGF3PKlIpW9EcfD4ozh8eWeV bL62BJjJIfGTaFBLhlO6Zk2gktcSNa4yVWNc1W2tiEOPPsqTSehvmY9I4GMfPO/uYMfn ye30hEl7pXe1twgvEvOQ8bhzQAJMjQlPm7Xbe4LQTxTyQWVi6KSt2vlzJt7J9wE01EF7 U8KyZKuzSQ16kMedhlmbwHFUKAbFHO0v4YdlMUkPlu57bDvTQfIG+NCz4oozfyR9GXBo UpYQ== 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=WDf5TJE4tDXcMZvyyLd4jjts/mmkyQoqng5BYJx0Gjk=; b=OaKm0ZG4IvTuL+x3uXPdwmTLiIWwnYTnyNkVhTRYg4p+9sarYH8QhznT91w9WiVkdP JmKveFY1j9wSqYUeLGyKMOHl+M/1ePwQd+FMgk1yJhTLdtFLL0D6K/T5QAFSJIspN9Uj OaivOPVuWkmhq9wf59l85/PihbjEHnZwRoSkDJXCCvIFR7xhZrla1opw6i9uqZ6u9vST ymBbC9FMjJ37hYcn8GxXCjqctuLGXyNFXLY/aQ6DkJoKpWuxrFzxT0QElHBNUZxgHAFJ q9K0aCE6ZLVNtSdMnTfExV7XIE6DkMkF5L9ZK9faJD+uICnsP44JSIKoNA07swkW642v 9bMQ== X-Gm-Message-State: ALoCoQlAkn24ZMuolTG7s6Os0QccMf0xRkXfeo5/yg15yybSe7wk7T5jQEfy81tly6b+lqx1lypUNTvVuPBlhyRe3sUQaqz5e7+Rq7NHYSw0h6wAxNxBMNOLdQ9ncZrYFZMQkgLPn/yrritBWT4ZQRkTIn0mAVwhS2l1+7TwHD2Ao0bYsuuwM4RDunz5oflNVObHjmGccCtv X-Received: by 10.52.122.14 with SMTP id lo14mr1336525vdb.38.1394047809570; Wed, 05 Mar 2014 11:30:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 5 Mar 2014 11:29:49 -0800 (PST) In-Reply-To: <531772C2.7040306@viagenie.ca> References: <5317490E.3090701@viagenie.ca> <531772C2.7040306@viagenie.ca> From: Justin Uberti Date: Wed, 5 Mar 2014 19:29:49 +0000 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=089e013a1b227d64a704f3e10c18 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3p3tiW_QR6WwJjvUvxYMG_MEOTk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports questions on IPv6 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, 05 Mar 2014 19:30:33 -0000 --089e013a1b227d64a704f3e10c18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 5, 2014 at 6:53 PM, Simon Perreault wrote: > Le 2014-03-05 18:34, Martin Thomson a =C3=A9crit : > > On 5 March 2014 15:55, Simon Perreault > wrote: > >>> 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * > 2 (IP protocols) =3D 80 candidates > >> > >> It's....... it's beautiful! > > > > Indeed! Now imagine pairing those. > > 5 * ( 16 * 15 / 2 ) =3D 600 pairs > > A marvel of engineering! > At 20 ms paced checks, this is... 12 seconds. (Fortunately many pairs don't make sense, e.g. v4->v6, udp->tcp, stun->*, and can be omitted) > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013a1b227d64a704f3e10c18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 5, 2014 at 6:53 PM, Simon Perreault &= lt;simon.p= erreault@viagenie.ca> wrote:
Le 2014-03-05 18:34, Martin Thomson a =C3=A9= crit :
> On 5 March 2014 15:55, Simon Perreault <simon.perreault@viagenie.ca> wro= te:
>>> 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interf= aces) * 2 (IP protocols) =3D 80 candidates
>>
>> It's....... it's beautiful!
>
> Indeed! =C2=A0Now imagine pairing those.

5 * ( 16 * 15 / 2 ) =3D 600 pairs

A marvel of engineering!

At 20 ms paced= checks, this is... 12 seconds.

(Fortunately many = pairs don't make sense, e.g. v4->v6, udp->tcp, stun->*, and ca= n be omitted)=C2=A0

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=

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

--089e013a1b227d64a704f3e10c18-- From nobody Wed Mar 5 11:49:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ED11A045B for ; Wed, 5 Mar 2014 11:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KcajqUJuwRQ for ; Wed, 5 Mar 2014 11:49:18 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id B051D1A048F for ; Wed, 5 Mar 2014 11:49:18 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta12.westchester.pa.mail.comcast.net with comcast id ZuGe1n0051uE5Es5CvpFKe; Wed, 05 Mar 2014 19:49:15 +0000 Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta16.westchester.pa.mail.comcast.net with comcast id Zvn41n00S2904qf3cvn6co; Wed, 05 Mar 2014 19:47:13 +0000 Message-ID: <53177F38.6060503@alum.mit.edu> Date: Wed, 05 Mar 2014 19:47:04 +0000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "rtcweb@ietf.org" References: <530B740E.4090707@ericsson.com> <5316135A.1010405@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394048955; bh=9uDgVgXZQ2+0DA2zV8gxs1Fn4ugIVXsSuZwySWHnRws=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M+M/hgVZQUtzWNkbHnqd5fvN6oMLmpk9rwrdBO049RVd2PzRQL0uYkRjS82vFnXP6 0L0E3Eh6S57pU2SRooLlP8phP6x1eUQZWBXSGp4L5m94UOCE+CQuMSl7TlNTlHWvBq WDRNMpgKEN3RZBanrF19XsTEjpFwO0RhwglafwW9SWRs9v/912TQAphXNsxTI299yw oIEqO2ljnMbTuP/t7lDqpAdPW4FrB0FmXV/7lIgb3aPrmk9v2NX8uu9+4YIrMho7jU 8PsVC+09kM4o8prNQozzmjco0+VsWyWPaPmt1+/jB5E8prd4cyZM31bELWpJFdxx0M hYkbZYh1kGl3A== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-W96oOvedXAlJH0HT0V5Jd8U_0I Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 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, 05 Mar 2014 19:49:20 -0000 On 3/4/14 7:24 PM, Makaraju, Maridi Raju (Raju) wrote: >>>> 2. Section 4: >>>> >>>> The method >>>> used to determine which side uses odd or even is based on the >>>> underlying DTLS connection role when used in WebRTC, with the side >>>> acting as the DTLS client using even stream identifiers. >>>> >>>> Isn't this unnecessary using the vague word of WebRTC instead of simply >>>> pointing to the DTLS roles of the established data channel? >>> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore >>> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP >>> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. >>> In that case DTLS is not used and you can not refer to the DTLS role. >>> That is why the restriction is used. >> >> So data channels could work over SCTP/IP or SCTP/UDP/IP, but in fact >> can't solely because the choice of even/odd role is dependent on DTLS >> connection role? >> >> Couldn't you find a way to choose the even/odd role based solely on the >> SCTP layer and the SDP? Then data channels could be used over those >> other stacks. > [Raju] > +1 > a=setup could be used to determine this, but the final determination is done only at SDP answer (which is same for DTLS). > For DTLS/SCTP case since both DTLS and SCTP layers use the same a=setup, both DTLS and SCTP client/servers roles match. > So, DCEP changing text to indicate role determination be done per SCTP client/server role instead of DTLS role may just work and is compatible with existing text. > [/Raju] +1 Thanks, Paul From nobody Wed Mar 5 12:40:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8A51A0685 for ; Wed, 5 Mar 2014 12:40:10 -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 zzWrhMdi_chz for ; Wed, 5 Mar 2014 12:40:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn14138.inbound.protection.outlook.com [207.46.163.138]) by ietfa.amsl.com (Postfix) with ESMTP id A7ADD1A0669 for ; Wed, 5 Mar 2014 12:39:45 -0800 (PST) Received: from DM2PR03CA009.namprd03.prod.outlook.com (10.141.52.157) by BLUPR03MB049.namprd03.prod.outlook.com (10.255.209.149) with Microsoft SMTP Server (TLS) id 15.0.893.10; Wed, 5 Mar 2014 20:39:40 +0000 Received: from BN1BFFO11FD008.protection.gbl (2a01:111:f400:7c10::1:147) by DM2PR03CA009.outlook.office365.com (2a01:111:e400:2414::29) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 20:39:40 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD008.mail.protection.outlook.com (10.58.144.71) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 20:39:39 +0000 Received: from TK5EX14MBXC296.redmond.corp.microsoft.com ([169.254.2.186]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Wed, 5 Mar 2014 20:39:00 +0000 From: "Matthew Kaufman (SKYPE)" To: Simon Perreault , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Transports: RFC 6062 support Thread-Index: AQHPOIP9MQysxUHuaES93/Eve9xs+5rSnXuAgAABcwCAAAaraYAAOvQAgAAUC3A= Date: Wed, 5 Mar 2014 20:39:00 +0000 Message-ID: References: , <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> In-Reply-To: <53177A5E.7030704@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(377424004)(377454003)(51704005)(13464003)(189002)(199002)(6806004)(19580405001)(19580395003)(83322001)(15975445006)(81686001)(69226001)(55846006)(23756003)(16601075003)(46102001)(74876001)(63696002)(4396001)(83072002)(47446002)(74502001)(85852003)(80976001)(79102001)(74706001)(77982001)(93136001)(59766001)(2656002)(87266001)(15202345003)(90146001)(56816005)(47776003)(20776003)(74366001)(87936001)(85306002)(77096001)(31966008)(44976005)(94316002)(76482001)(54316002)(65816001)(66066001)(80022001)(76786001)(76796001)(54356001)(53806001)(51856001)(93516002)(81542001)(86362001)(33656001)(95416001)(94946001)(49866001)(50986001)(81816001)(81342001)(47976001)(95666003)(47736001)(92566001)(92726001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB049; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:6C30C934.AF3297D2.81E13C73.D4DD1371.20212; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01415BB535 Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ey5u7y0cmKw9sbLLIYAmGIf-TqY Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 05 Mar 2014 20:40:10 -0000 TRAM is solving the "without the assistance of the JavaScript" case (findin= g corporate servers or ISP servers)... I'm sure that some of the larger RTC= WEB application providers will be more than capable of figuring out which T= URN servers will be best to assign to their customers. Matthew Kaufman > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Simon > Perreault > Sent: Wednesday, March 5, 2014 7:26 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Transports: RFC 6062 support >=20 > Le 2014-03-05 15:55, Matthew Kaufman (SKYPE) a =E9crit : > > if they each select TURN servers well you get TCP on the short legs > > and UDP on the long leg. >=20 > How would they "select TURN servers well"? >=20 > We have a milestone for solving that problem in TRAM, and no draft > currently adopted for it. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Mar 6 01:11:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC91A018A for ; Thu, 6 Mar 2014 01:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 0wI5ZN2uwjPS for ; Thu, 6 Mar 2014 01:11:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 245231A019D for ; Thu, 6 Mar 2014 01:11:30 -0800 (PST) Received: from porto.nomis80.org (h230.viagenie.ca [206.123.31.230]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8BBD8403E7; Thu, 6 Mar 2014 04:11:25 -0500 (EST) Message-ID: <53183BBB.3040409@viagenie.ca> Date: Thu, 06 Mar 2014 09:11:23 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Matthew Kaufman (SKYPE)" , "rtcweb@ietf.org" References: , <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e6ELjSXJ8F2z6A4mZr_3P_q4yHs Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 06 Mar 2014 09:11:43 -0000 Le 2014-03-05 20:39, Matthew Kaufman (SKYPE) a écrit : > TRAM is solving the "without the assistance of the JavaScript" case (finding corporate servers or ISP servers)... I'm sure that some of the larger RTCWEB application providers will be more than capable of figuring out which TURN servers will be best to assign to their customers. Right. So the "TCP on the short legs, UDP on the long leg" argument currently only holds for large application providers. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 6 01:29:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BD21A0178 for ; Thu, 6 Mar 2014 01:28:58 -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 7BWHZjyz2Cmq for ; Thu, 6 Mar 2014 01:28:56 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E86B01A0170 for ; Thu, 6 Mar 2014 01:28:55 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id x12so2774402wgg.6 for ; Thu, 06 Mar 2014 01:28:51 -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=erFoflZRfZUcwes4yVcDfytjyBxLqWSEVShjuzKanRA=; b=1AGwQquDBcOtXpyO9+rQWY/5J/p7jSbQffyCQXRGP1WlWm09Hn6DRCZNE1dP7450ZT p7/+NO2mvgAQPVCAqKGi6HGc6uZ0Xdcy90opbTeHwnHs4glqHCM3INsTWfwFxxJQbS1/ 1C9KAPq3ipjqnuJ5hU7bpFpZRCxCnfHS/lr9F4aCrR1drLM2vBKT60/0T2U0aHmDNc+F DoB6m1OPgKROsVSXaDSUlJ4Y6ofPYCC71jHEGbwsN92guxtKLjGQvLDFKxg0OmuiZThG 0Vr2ZOj+K6taZybOzA5S5vg5RMQ/P4dyTRAVAfK9Qy0S5UpKg9WUT/NNfF3uC324erL+ owoQ== MIME-Version: 1.0 X-Received: by 10.194.170.167 with SMTP id an7mr8216874wjc.39.1394098131693; Thu, 06 Mar 2014 01:28:51 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 01:28:51 -0800 (PST) Date: Thu, 6 Mar 2014 09:28:51 +0000 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lTZRwUlzcFF0Qshg7KUAoNyL_c4 Subject: [rtcweb] HTTP POST for IdP 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, 06 Mar 2014 09:28:58 -0000 As discussed in the meeting, I've put together a proposal for handling IdP interactions using HTTP POST. This adds a direct translation of the exchanges that are sent over the Message Channel to JSON over HTTP POST. This allows servers or non-browser applications to use the IdP. More details: - the "id" and "origin" parameters are only used for the MessageChannel mapping - for "id", HTTP provides adequate request-response correlation - for "origin", the HTTP Origin header should suffice - there is a new field added to the identity assertion that identifies the supported interaction models: "proxy", "http" or both, included in an array - on this point, we should discuss in the W3C whether we will add this parameter to setIdentityProvider - there are some structural changes required to make this flow properly - I've referenced the new JSON RFC Actual change request: https://github.com/ekr/ietf-drafts/pull/14/files From nobody Thu Mar 6 01:56:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551D81A01D7 for ; Thu, 6 Mar 2014 01:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 U67h5fkPsIJ5 for ; Thu, 6 Mar 2014 01:56:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D838D1A01C8 for ; Thu, 6 Mar 2014 01:56:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBU48498; Thu, 06 Mar 2014 09:56:23 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 09:55:49 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 09:56:22 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 17:56:16 +0800 From: "Huangyihong (Rachel)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTP usage: supporting RTP ECN? Thread-Index: Ac85IlR9g4Ppx7noToe3jIdcqhi3Nw== Date: Thu, 6 Mar 2014 09:56:15 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB861952E2@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.85.206] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB861952E2nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sl2KIMbCCMh95zjpeKik-YkzdrE Subject: [rtcweb] RTP usage: supporting RTP ECN? 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, 06 Mar 2014 09:56:30 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB861952E2nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, draft-ietf-rtcweb-rtp-usage-12 doesn't have any description regarding to RT= P ECN RFC6679. I'm wondering why. But from my point of view, it's worth som= e discussion. The usage of ECN is a trend though it is not universal in cur= rent network. Supporting it in browsers for RTP media transport may be good= for future. BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB861952E2nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

draft-ietf-rtcweb-rtp-usage-12 = doesn’t have any description regarding to RTP ECN RFC6679. I’m = wondering why. But from my point of view, it’s worth some discussion.= The usage of ECN is a trend though it is not universal in current network. Supporting it in browsers for RTP media transport may = be good for future.

 

BR,

Rachel

--_000_51E6A56BD6A85142B9D172C87FC3ABBB861952E2nkgeml501mbschi_-- From nobody Thu Mar 6 05:11:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6BD1A025E for ; Thu, 6 Mar 2014 05:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 vVuSHyIcjIrq for ; Thu, 6 Mar 2014 05:11:46 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9831A02A7 for ; Thu, 6 Mar 2014 05:11:46 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oy12so2587951veb.32 for ; Thu, 06 Mar 2014 05:11: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=sUHq2aUOUkqzLwlaiCJJn4ZKW6aJ5w8hO/lCZdSyRfE=; b=QqZFGezjtR3dVh/2GcOjUtHDjWdNygrzBEGDXoqmHNtYPaPglcewPqkPXViZBivS9h fu/SoUp3+H3FDEG+MItj1cM6eGfM9z4GqrOmKe1WzELmIvj+cBvCYZXUSdWSzmKoxS55 N3ym9I38YqY2MZbF1yO26E9QCxg0rQ4o6+w3eAy53sNQm+1akrJYkYv7TqJuNpSWAcJN WUEUTeD/RMj9jFZdkYEF7Q/MIC1+V5y+p/SB52giFjfu9PgH6FGmPHrJWQ1+X/oWItib OdEUC+2F2WLXB1Urn/gl9YdeP0af/cMk71RlsfRSxrC/zbyeXXEIIK+llLcnnK8ksSzF bA5Q== 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=sUHq2aUOUkqzLwlaiCJJn4ZKW6aJ5w8hO/lCZdSyRfE=; b=gXN2iWxW3imPzqhrK5YQex7nu05NIVdmJY41YnjEXwiS3BPMnQM1Iq5k4Sd8U7KXYK yH+kLD4AhX/+bN1DzG4iVQrJxRr2zDqsYzCZerREz9k2TWraH5KFWO1Mlted2YxUhuSp MvOEMFgoQ3EttfKHzgN528WYr9KpQvou0KHSTaiY+YxzZWOyVxhXtPb4U3tfnnCCNtKe UEzZxnhNqcgH1oQNnprx+MUoarBnkVXwohfwKHl/KZVf574+gJddIQPqSpBHh1iSORjH 1weGbMjYYd8P5C6HEz3iEKjAA1ePKh1opzr4XiiUfEsQfOIMVUCgKcVRDVbkFo1HNCYl cmrA== X-Gm-Message-State: ALoCoQl9Wl1FTG8eKTgNcULGFTe+AJ7TiUBqyzmXMxTC4Bl2Fxuw6ZOhM2P5Vqn0gjobyZnJ/qni8CMAKTID4aThAkWX0xqQyKhzHBE81gZBMhVeB4ESobHy3m+OS64muRB/tgcYPRHBjFSHA/EUuXMaZoKNkyl668oTeJJHUOOEx//RvdY0k9jmDAav2TNSq9grHCh3zNMz X-Received: by 10.52.15.132 with SMTP id x4mr1607043vdc.31.1394111502118; Thu, 06 Mar 2014 05:11:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 6 Mar 2014 05:11:22 -0800 (PST) In-Reply-To: <53183BBB.3040409@viagenie.ca> References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> From: Justin Uberti Date: Thu, 6 Mar 2014 13:11:22 +0000 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf30334741dc851604f3efe02d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WDhMdsdI6iYFhfABi1vd3X6ZVZQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 06 Mar 2014 13:11:51 -0000 --20cf30334741dc851604f3efe02d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would expect that corp or ISP servers would also be located very close to the endpoint. On Thu, Mar 6, 2014 at 9:11 AM, Simon Perreault wrote: > Le 2014-03-05 20:39, Matthew Kaufman (SKYPE) a =C3=A9crit : > > TRAM is solving the "without the assistance of the JavaScript" case > (finding corporate servers or ISP servers)... I'm sure that some of the > larger RTCWEB application providers will be more than capable of figuring > out which TURN servers will be best to assign to their customers. > > Right. So the "TCP on the short legs, UDP on the long leg" argument > currently only holds for large application providers. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30334741dc851604f3efe02d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would expect that corp or ISP servers would also be loca= ted very close to the endpoint.


On Thu, Mar 6, 2014 at 9:11 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-03-05 20:39, Matthew Kaufman (SKYPE)= a =C3=A9crit :
> TRAM is solving the "without the assistance of th= e JavaScript" case (finding corporate servers or ISP servers)... I'= ;m sure that some of the larger RTCWEB application providers will be more t= han capable of figuring out which TURN servers will be best to assign to th= eir customers.

Right. So the "TCP on the short legs, UDP on the long leg" = argument
currently only holds for large application providers.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=

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

--20cf30334741dc851604f3efe02d-- From nobody Thu Mar 6 05:14:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58581A01F2 for ; Thu, 6 Mar 2014 05:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 P7raDR0ho2f0 for ; Thu, 6 Mar 2014 05:14:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 577661A025E for ; Thu, 6 Mar 2014 05:14:17 -0800 (PST) Received: from porto.nomis80.org (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E05AE403E7; Thu, 6 Mar 2014 08:14:12 -0500 (EST) Message-ID: <531874A4.6010908@viagenie.ca> Date: Thu, 06 Mar 2014 13:14:12 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hg2wm8qk4ABlPCzggvuWs6XomGo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 06 Mar 2014 13:14:21 -0000 Le 2014-03-06 13:11, Justin Uberti a écrit : > I would expect that corp or ISP servers would also be located very close > to the endpoint. Right, but my point is that we still don't have a way for those corp- or ISP-provided servers to be discovered by the endpoint. We had a draft presented in TRAM yesterday, but it was not adopted. So I guess we're at a point where we need ideas. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 6 05:22:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765151A02E9 for ; Thu, 6 Mar 2014 05:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 HqmRQ8JqqS8t for ; Thu, 6 Mar 2014 05:22:41 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2021A0228 for ; Thu, 6 Mar 2014 05:22:41 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id if11so2498342vcb.36 for ; Thu, 06 Mar 2014 05:22:37 -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=UCp0KlVBPmOTRnN2YD2QACIDdLqWGOzWoOCAozfszn8=; b=BVdh/Fo86AokaJW03LKY0MAIRCn7qlmoCzgzMZvHJZmrggt/tytUK+a8UdGWcb+tVC vqs8sJ0uRoM947DBf6iVztfyoVkw/xee5OPK5VIaQ58oPiye2g8j9A9vmpzsdIEQ3k3L RxyMpLAZT5XglLEPPji7yggKyvlQzMAQ76SsaR4OXkNCP1ssVGg6RA/5zy+2IFVj7YEF Svkqh2LFzmwshpFgJLFHEWOnzURhmOs2yeC/M8dE8tPrNn4L4Q9ki0mQQlSZ9z6zpDSE +zIWdk18UwN2CEohZNQ5i514cWu4NgwugHtyqbzUigKkzoYrpcCY5iMHmAWLXkdRkfem 8Neg== 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=UCp0KlVBPmOTRnN2YD2QACIDdLqWGOzWoOCAozfszn8=; b=cS7ERYk/D9Wpbi1MIYuuAgrG1Sc8cU4Nc2bUhCTFWJKklnVk/Tou1fWHPNDzg3ZfXo BM5wcV/YnCVdPnX4oba3sPlXwkg2xb+WF9S51Ya12F9XkSLKnXO0eQqZNLkt0fBBLDtB wsMqO5u7atvFH57pjtiKh3pnSAAPrv5q8wuXj2XkNkpEQlF0jKxL3wpRmGFjsu6spM/v fKQrwVpifrDhvDNETQViAYsiIu7aopYTwU7v1nf9yYrYIGsAsM80Aon7CqkcR2JXbE7J TCtD122o8SHpvkCh6zyzsCElf8oc+f+kE35PVnxJeRZsXtaFO/vLtrI6aDVAAGFBS6Uu 7w/g== X-Gm-Message-State: ALoCoQlX+0Hm+e9AcZ7HHCYwaUJ7GIAOuq9OSVEbSer7iseAU0fssK/00AKESdZ/81IGWa2We2gKlhI5iouEj7/Sr8pPBR4k3zAyx/SFwlOsWQtKWUjbDKCGNqnEuMbvCS5fuEhToLwqoHfU3MMB0Hl+MOV6VrHDWF6JpGATa00sx+Ecyaw2QsGkr1am2SNMWkyjcJuhdpYk X-Received: by 10.52.101.135 with SMTP id fg7mr7932708vdb.17.1394112157072; Thu, 06 Mar 2014 05:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 6 Mar 2014 05:22:16 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> From: Justin Uberti Date: Thu, 6 Mar 2014 13:22:16 +0000 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=bcaec5469505e6574604f3f00762 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1jytWX44PSDIOjT5172s3eVLf7I Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 06 Mar 2014 13:22:43 -0000 --bcaec5469505e6574604f3f00762 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 5, 2014 at 3:45 PM, Jonathan Lennox wrote: > > On Mar 5, 2014, at 2:25 PM, Justin Uberti wrote: > > So there are three things here: > 1) MUST the implementation offer encrypted header extensions? (i.e. > mandatory-to-implement) > 2) MUST the implementation use encrypted header extensions? (i.e. > mandatory-to-use) > 3) MUST the implementation expose an API to control this? (i.e. no SDP > munging needed) > > I think we want yes for #1, no for #2, and #3 is potentially interesting > but out of scope for 1.0. > That gives encrypted headers for audio on by default, but remote parties > can negotiate this off using RFC 6904 mechanisms. > > > Note that in 6904=E2=80=99s procedures, an offerer has to explicitly off= er both > encrypted and unencrypted versions of a header extension if it wants to > allow the answerer to choose between them. > > To support this use case, in RTCWeb terms, this would mean that a > browser would a) have to offer both the encrypted and unencrypted version= s > of the header extension, and b) answer an offer that offered only the > unencrypted header by agreeing to use it. > That is a good point, and implies that for any header extension that recommends encryption (e.g. RFC 6464 for audio level), we have the following choices: a) Implementations MUST offer only the encrypted version, and MUST accept only the encrypted version b) Implementations MUST offer both the encrypted and unencrypted versions, and MUST accept both Of these, a) is the less complicated option. --bcaec5469505e6574604f3f00762 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 5, 2014 at 3:45 PM, Jonathan Lennox &= lt;jonathan@vidyo.c= om> wrote:

On Mar 5, 2014, at 2:25 PM, Justin Uberti <juberti@google.com> wrote:

So there are three things here:
1) MUST the implementation offer encrypted header extensions? (i.e. ma= ndatory-to-implement)
2) MUST the implementation use encrypted header extensions? (i.e. mand= atory-to-use)
3) MUST the implementation expose an API to control this? (i.e. no SDP= munging needed)

I think we want yes for #1, no for #2, and #3 is potentially interesti= ng but out of scope for 1.0.
That gives encrypted headers for audio on by default, but remote parti= es can negotiate this off using RFC 6904 mechanisms.

Note that in 6904=E2=80=99s procedures, an offerer has to explic= itly offer both encrypted and unencrypted versions of a header extension if= it wants to allow the answerer to choose between them.

To support this use case, in RTCWeb terms, this would mean that a brow= ser would a) have to offer both the encrypted and unencrypted versions of t= he header extension, and b) answer an offer that offered only the unencrypt= ed header by agreeing to use it.

That is a good point, and impl= ies that for any header extension that recommends encryption (e.g. RFC 6464= for audio level), we have the following choices:
a) Implementati= ons MUST offer only the encrypted version, and MUST accept only the encrypt= ed version
b) Implementations MUST offer both the encrypted and unencrypted versi= ons, and MUST accept both

Of these, a) is the less= complicated option.


--bcaec5469505e6574604f3f00762-- From nobody Thu Mar 6 05:24:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BF01A025D for ; Thu, 6 Mar 2014 05:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 e45N--Maetzd for ; Thu, 6 Mar 2014 05:24:15 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA551A0073 for ; Thu, 6 Mar 2014 05:24:15 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id oz11so2562192veb.5 for ; Thu, 06 Mar 2014 05:24: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:from:date:message-id:subject:to :cc:content-type; bh=5AWaJxptrXYmFt9m6sz7O6WI0uGo6bYH6p3arYihuDQ=; b=Xl7435TjFbt1Hzd77SGsjnaP8kfDNcbUa0v67nZ4pj8JNhKsd9QGU07yL6dhdbxBtX qYwP5KcXGtCGTXRteNR+nwdjBCJMw4MXrPej59vE1y42HecJaIe0I+vRrY36sYlu1Gv7 hbkpog5cVpZ/QDy7qjPS/JiZr6nPG9caJIWbrTYPd97xieWcgpoLR+omgV6+8X46W6a7 iNlt2gZoKWhLS2xsKO5g6p8ZRvRA6EvMF14tidFXKm4BdeVBxH8bfklG/JnhFOWprHIJ SPmFzbqYvjXuqE/4foHPMVH4lFBCh3yecdAH3QPgs/zd+4w+o0+8SnytLE2WwIPRZRfm yyyQ== 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=5AWaJxptrXYmFt9m6sz7O6WI0uGo6bYH6p3arYihuDQ=; b=Ld0/aDRoAqlSTGMnjQ/ZVyOw+JXkeL1/6FqdgMHm2P+5Qljt4ZM6AjTjjEo2EBpQWQ uZHKNNyAkUuNkf/c7E0FRShMoCgfH/cBHnSIcgVaa3crGHeqc6fhZldTZTm1fOlbw18T 6kBEUHXaL08HygZRj09I52Uncz+gkGJihdBBgV69AJWowpFCk0gBu3j26WSbyK26smGE s0lVwblpuiqG1uORYrtg6FJvaLdVqeH5iqQV8np6F9EfG9u7rbyBTQGSDerGT9aEz/RD HtnbmAyyE4zGxGwUr0XIIxY1WeqmLi0nYi1DBc6r5c5L767fDLdlnHLbD/WPraCU65Qk TEpw== X-Gm-Message-State: ALoCoQnRBOfVJ6gTd/baeLPwuQOZA6j90lPVJluymbKmBzNhGVflSG6zGe72BgeTxNMkkCsJEqnd4sln7SviibBH3Y3gCjWmPkQgZydjbuIqHF6PiOmcUtvH7p4L9O3Ijdgya0gBgTnxWu6XHAnjv81Ih/S5pE/QrPtRT/Y2Hz7SoQRnsjbBwJu594rLVmhzvYjZRWhcj1TN X-Received: by 10.220.67.18 with SMTP id p18mr5109104vci.14.1394112251106; Thu, 06 Mar 2014 05:24:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 6 Mar 2014 05:23:50 -0800 (PST) In-Reply-To: <531874A4.6010908@viagenie.ca> References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> From: Justin Uberti Date: Thu, 6 Mar 2014 13:23:50 +0000 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b343f9a812df704f3f00d9e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NWlMz-YENUEHfWP9YL1WSRS2BfE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 06 Mar 2014 13:24:17 -0000 --047d7b343f9a812df704f3f00d9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable True. But in trying to wrap up this thread, can we agree that TURN TCP candidates are a SHOULD NOT? On Thu, Mar 6, 2014 at 1:14 PM, Simon Perreault wrote: > Le 2014-03-06 13:11, Justin Uberti a =C3=A9crit : > > I would expect that corp or ISP servers would also be located very clos= e > > to the endpoint. > > Right, but my point is that we still don't have a way for those corp- or > ISP-provided servers to be discovered by the endpoint. We had a draft > presented in TRAM yesterday, but it was not adopted. So I guess we're at > a point where we need ideas. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --047d7b343f9a812df704f3f00d9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
True. But in trying to wrap up this thread, can we agree t= hat TURN TCP candidates are a SHOULD NOT?
<= br>
On Thu, Mar 6, 2014 at 1:14 PM, Simon Per= reault <simon.perreault@viagenie.ca> wrote:
Le 2014-03-06 13:11, Justin Uberti a =C3=A9c= rit :
> I would expect that corp or ISP servers would also be = located very close
> to the endpoint.

Right, but my point is that we still don't have a way for those c= orp- or
ISP-provided servers to be discovered by the endpoint. We had a draft
presented in TRAM yesterday, but it was not adopted. So I guess we're a= t
a point where we need ideas.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=

--047d7b343f9a812df704f3f00d9e-- From nobody Thu Mar 6 05:31:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D4B1A02CE for ; Thu, 6 Mar 2014 05:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 Lho0u0Id-Hpv for ; Thu, 6 Mar 2014 05:31:44 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 48E921A02F9 for ; Thu, 6 Mar 2014 05:31:35 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so2560738vcb.17 for ; Thu, 06 Mar 2014 05:31:31 -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=BEJfFjjHGg3oGv/0Evi55GnSYxavX2g+D9VcvqfBQZ4=; b=er7k60ttUlisW/RK6qTQmagj8uqk+13/hdiGyvzEA05FRCUnIJSDf0ZuCfEG0QHNqg tXyzXsNpi/UJ93wYlnNgR6anom1fghzSuTapenrHx94/4rlhvsQbgG7FCye6MHKvnJnW n+kLQYh+xnb7mEPVinfIp4jvkkv/8K2OO4zebyVTQwd3ketit82Lx2+Jq6o+X/kI/k0H /W0VdHRNqA+qZAQCigln8ib+PX4eWp0czeKFsvKz7e6S5/M4NYqkZLGeid4OXSAv93w2 JgMRsVQwhuAzreYXLLJy4MpKPRg0wp8b8YKqaiQzg1vKWL2roaUnnUgzonnfcLZ4Tb3I CWNQ== 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=BEJfFjjHGg3oGv/0Evi55GnSYxavX2g+D9VcvqfBQZ4=; b=kqwwApoW3yA53ssKAnZWU8kaEAsJXphMZSW0ow68WDRzct51lLxmcQDAJNPL0fpC44 HcUyXNpPS/ck4UudUKWzvNqOvRmuBzdr+khnkjMoI65lKuS+QCEIExPxPUdRZrdmvd84 arT6u35bNmDiiG3kd0X1jrMe+GwxUcbvoeWQ16S0joH9ckVMChcmbKJTh4lF9ghZnvwF PHnYw8XpUDwe+voSHi6Am8gBBfmGzYVy1WXUBr9UCqV3G+tClsMMp9HDuolW06QB1Yor 8SsBizDH6vIjCr5HZqbuk37R9dqCKu05l8/YmtrRcBj80N/fJZQ5q9zbr8uAvT6g3whI 9+Ug== X-Gm-Message-State: ALoCoQldMUPkHJ9srRE9uORvDVC3RsVoMCBkPxcnWKWFAYBBJJxDa2eLd35kDmu3HvVFpukPCgwrK0poKrvZeZUkMgzGCE6I/o7QRUOu3q1m5KaKV/5St36Sy9QO4d7OdAdJsIQQpfSv66XOiBgPoi0mahP1KJXYCip94MMW6DyYE7ymzlgdud5z9UkdxiW1y33VmWGKAEMz X-Received: by 10.220.98.143 with SMTP id q15mr82651vcn.38.1394112691252; Thu, 06 Mar 2014 05:31:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 6 Mar 2014 05:31:11 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 6 Mar 2014 13:31:11 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c1da06bd45a204f3f027ec Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n52GwIzMhVvFznuKmU5NpzcQ4CQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Issue with new Trickle ICE text 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, 06 Mar 2014 13:31:52 -0000 --001a11c1da06bd45a204f3f027ec Content-Type: text/plain; charset=UTF-8 As discussed in the meeting, this doesn't mandate Trickle ICE for the application (which can just wait until gathering is complete, as indicated in S 3.4.1). Trickle ICE is mandated for the implementation, but I thought we had agreed that long ago so that applications can get consistent behavior. While the text in S 3.4.2 is new, it is consistent with the text in 4.1.2 and 4.1.5, which defines the behavior for createOffer and setLocalDescription 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. setLocalDescription: This API indirectly controls the candidate gathering process. When a local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and begin gathering candidates for them. On Wed, Mar 5, 2014 at 9:27 AM, Eric Rescorla wrote: > S 3.4.2 of JSEP now reads: > > JSEP applications typically inform the browser to begin ICE gathering > via the information supplied to setLocalDescription, as this is where > the app specifies the number of media streams to gather candidates > for. However, to accelerate cases where the browser knows the number > of media streams to use ahead of time, the application 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 can > start by checking if any candidates are available in the pool. > > The issue here is that this basically mandates trickle ICE. If the > pool is smaller than the number of independent ICE streams needed, > then there is no way for you to "start gathering" (since this text > says it happens with sLD) and therefore you cannot supply all of the > candidates in the offer. > > If that's not the intention to require (and I don't believe we agreed > to this semantic), then this needs to be rewritten. > > -Ekr > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c1da06bd45a204f3f027ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As discussed in the meeting, this doesn't mandate Tric= kle ICE for the application (which can just wait until gathering is complet= e, as indicated in S 3.4.1). Trickle ICE is mandated for the implementation= , but I thought we had agreed that long ago so that applications can get co= nsistent behavior.

While the text in S 3.4.2 is new, it is consistent with the = text in 4.1.2 and 4.1.5, which defines the behavior for createOffer and set= LocalDescription

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.

setLocalD= escription:
   This API indirectl=
y controls the candidate gathering process.  When a
   local description is supplied, and the number of transports currently
   in use does not match the number of transports needed by the local
   description, the PeerConnection will create transports as needed and
   begin gathering candidates for them.


On Wed, Mar 5, 2014 at 9:27 AM,= Eric Rescorla <ekr@rtfm.com> wrote:
S 3.4.2 of JSEP now reads:<= div>
=C2=A0 =C2=A0 JSEP applications typically inform th= e browser to begin ICE gathering
=C2=A0 =C2=A0 via the information supplied to setLocalDescription, as = this is where
=C2=A0 =C2=A0 the app specifies the number of media streams to gather = candidates
=C2=A0 = =C2=A0 for. =C2=A0However, to accelerate cases where the browser knows the = number
=C2=A0 =C2=A0 of media streams to use ahead of time, the application M= AY ask the
=C2=A0 = =C2=A0 browser to gather a pool of potential ICE candidates to help ensure<= span style=3D"white-space:pre-wrap">
=C2=A0 =C2=A0 rapid media setup. =C2=A0When setLocalDescription is eve= ntually called,
=C2= =A0 =C2=A0 and the browser goes to gather the needed ICE candidates, it can=
=C2=A0 =C2=A0 start by checking if any candidates are available in the= pool.

The issue here is that this basically manda= tes trickle ICE. If the
pool is smaller than the number of indepe= ndent ICE streams needed,
then there is no way for you to "start gathering" (since thi= s text
says it happens with sLD) and therefore you cannot supply = all of the
candidates in the offer.

If that's not the intention to require (and I don't believe we agre= ed
to this semantic), then this needs to be rewritten.

-Ekr


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


--001a11c1da06bd45a204f3f027ec-- From nobody Thu Mar 6 05:34:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA31A0309 for ; Thu, 6 Mar 2014 05:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 ur6bwpP8db_V for ; Thu, 6 Mar 2014 05:34:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0692E1A0302 for ; Thu, 6 Mar 2014 05:34:30 -0800 (PST) Received: from porto.nomis80.org (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A8A3E403E7; Thu, 6 Mar 2014 08:34:25 -0500 (EST) Message-ID: <53187960.2010709@viagenie.ca> Date: Thu, 06 Mar 2014 13:34:24 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MNuT1fQnd6FVxOSEHNbdfRbmmus Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 06 Mar 2014 13:34:31 -0000 Le 2014-03-06 13:23, Justin Uberti a écrit : > can we agree that TURN TCP candidates are a SHOULD NOT? Not a SHOULD, sure. SHOULD NOT, no. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 6 05:49:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC1C1A0289 for ; Thu, 6 Mar 2014 05:49:37 -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 UozoMG8x6kRT for ; Thu, 6 Mar 2014 05:49:35 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D5B761A01FE for ; Thu, 6 Mar 2014 05:49:34 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w61so3142165wes.18 for ; Thu, 06 Mar 2014 05:49:30 -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=xDkHXro5AFDjsJkYVVuUhfGUDlq9bDTU8aIqyL6Ld5g=; b=avA+vYqZG4eB3WRM1TQwmGgfHnE7r+DgYHZyywRR/Bmdk1FvJERxLqt7S6BDDXueiN pfcrl2GoOEnmg1sTBtnRSyPFhc/pL2Ry4ON1UI6duLBo5nEGm2rk5OXLEKn6BM5szE2a ScsN8LsOuBAOubKkM4NOsOI4t/lc5IyxkJw1Ejee9IRbjT9WrM7GPJJjGvbQfjPv4sjw I7V0Cw8T2JS+d4RpBX9UOw/3/0etNBcP8PIpJjTnCcV2pkjfWxoVIv8ihSEdQLUkKhMt lwfytG2qBEDXxMPw62nHYWhLPGo8SfEEBGj50EtUKd4vFMfixh1pvq5znNqQZ3JFUABQ LVbQ== MIME-Version: 1.0 X-Received: by 10.194.192.233 with SMTP id hj9mr10367465wjc.78.1394113770538; Thu, 06 Mar 2014 05:49:30 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 05:49:30 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> Date: Thu, 6 Mar 2014 13:49:30 +0000 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F2OxE12IEHq7IZMQGUJlfn5vWXU Cc: Cullen Jennings , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 06 Mar 2014 13:49:37 -0000 On 6 March 2014 13:22, Justin Uberti wrote: > a) Implementations MUST offer only the encrypted version, and MUST accept > only the encrypted version > b) Implementations MUST offer both the encrypted and unencrypted versions, > and MUST accept both "either"? > > Of these, a) is the less complicated option. I agree. From nobody Thu Mar 6 05:53:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279E21A01AE for ; Thu, 6 Mar 2014 05:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 0yKMjfW5OqUI for ; Thu, 6 Mar 2014 05:53:06 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C3CE21A0307 for ; Thu, 6 Mar 2014 05:52:52 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so2649561vcb.3 for ; Thu, 06 Mar 2014 05:52:48 -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=Und9VJralvyEnm2FVJmqn4/7f+QJwP02pTCzrDK+Ao4=; b=I7+d+HqSdSNNQPFatyC9bOi9kijFARSVVLyE8glvnTFYZawn8HYCc4NJriDgO8XxrC lDkZfTDv0f7ZaHnNrA1IwzJDtLV2O39LZvWxVaSuctxnFDYlwujXUxO8ZkUVzEHM7wkT Ji6l2Is5rfgRvMMSbK/FsCjeCD27Q4ShrufHeyfqLRiJynJOPBUJ76yxEDayJiZR6ljT hAmrJaAdYj71/mEY6p2KsE22N/Ts9A9TxeNiE6D8C6OPzVY+kc+EslaXZ6/OhfSET4RI opTRAZjkMr1DBlaIts2UngOBZFl2fGKVUg4GMfcm1Y8D6l/zVciGeVW0lXQqsIVgMaGn Fu6w== 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=Und9VJralvyEnm2FVJmqn4/7f+QJwP02pTCzrDK+Ao4=; b=jH9wm667A5k/E9bXsKLFC+2DCszig4qYVON2D2BdHlCRgkzbCakC71qlfw8gy6vbb9 Vfdm9Ie7mhveqAf6iQhbyjlPvrvCNxxdPpRf/zfp88N/sgA5jVfwPXiiOsB/8i3GiMeX xk8NJkY3z16Lf2OTnfOLxW6qpVjivIpqECgJ5gV2YAXQuxXDcp5xA8Sz3FTeItqXbYE9 WnA/JOREZXmSJvMRmc6W/KxYt7lJDuXely3MgT2zofMn62osZp/pUEM4fHVQ1ozyAcY4 3GPAHcblBIMcWf0AGTu+GmfX8q+lbTnkRa4IGX6Ucf+BmJEOL3U7wvZy5G2FdCS/nqkB Tcow== X-Gm-Message-State: ALoCoQlU5x2/Fl4/3a+be2yi0I3tkEd5IS08TykzH52n+39F8W9I9I/K9jQOLQiokMIatfEp6U7oSWN1OGQD7+nLAYLT/t84/nWJt9EuGS+3CEplQJR8A2QnjuQxdkDIFwYbKmBX7IqdsC4sLkeDpGVyv6Tqx15JP8FTUrLweYUpF2Ww7gfWiQYlNMo3XKb4v5BThfreZXr9 X-Received: by 10.52.126.107 with SMTP id mx11mr170315vdb.41.1394113968638; Thu, 06 Mar 2014 05:52:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 6 Mar 2014 05:52:28 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> From: Justin Uberti Date: Thu, 6 Mar 2014 13:52:28 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec520f689e0d2fd04f3f073b6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XrbvR0dGHhHBlEyZOTlvnBqVX_8 Cc: Cullen Jennings , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 06 Mar 2014 13:53:09 -0000 --bcaec520f689e0d2fd04f3f073b6 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 6, 2014 at 1:49 PM, Martin Thomson wrote: > On 6 March 2014 13:22, Justin Uberti wrote: > > a) Implementations MUST offer only the encrypted version, and MUST accept > > only the encrypted version > > b) Implementations MUST offer both the encrypted and unencrypted > versions, > > and MUST accept both > > "either"? > Right, that is what I meant. > > > > > Of these, a) is the less complicated option. > > I agree. > --bcaec520f689e0d2fd04f3f073b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 6, 2014 at 1:49 PM, Martin Thomson &l= t;martin.thom= son@gmail.com> wrote:
On 6 March 2014 13:22, Justi= n Uberti <juberti@google.com&g= t; wrote:
> a) Implementations MUST offer only the encrypted version, and MUST acc= ept
> only the encrypted version
> b) Implementations MUST offer both the encrypted and unencrypted versi= ons,
> and MUST accept both

"either"?

Right, that i= s what I meant.=C2=A0

>
> Of these, a) is the less complicated option.

I agree.

--bcaec520f689e0d2fd04f3f073b6-- From nobody Thu Mar 6 05:54:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9B1A017E for ; Thu, 6 Mar 2014 05:54:30 -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, 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 QhzjB_ATRWbY for ; Thu, 6 Mar 2014 05:54:28 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id E3A081A01AE for ; Thu, 6 Mar 2014 05:54:27 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/6/2014 8:54:23 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-70/SG:2 3/6/2014 8:53:34 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.909613 p=-0.983566 Source White X-Signature-Violations: 0-0-0-3573-c X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 3/6/2014 8:54:20 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 77803751; Thu, 06 Mar 2014 08:54:23 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Thu, 6 Mar 2014 07:54:22 -0600 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level Thread-Index: AQHPOIXa97MYXf3mNUS0a1X98yqSFprTB4SAgAFqNACAAAj3gA== Date: Thu, 6 Mar 2014 13:54:22 +0000 Message-ID: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.226] Content-Type: text/plain; charset="Windows-1252" Content-ID: <37ADE3FB8810534AA5BAAA80E9A9D057@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8G1erBvOgnYQBZbfzMqzFcSTS_Y Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 06 Mar 2014 13:54:30 -0000 On Mar 6, 2014, at 1:22 PM, Justin Uberti wrote: > That is a good point, and implies that for any header extension that reco= mmends encryption (e.g. RFC 6464 for audio level), we have the following ch= oices: > a) Implementations MUST offer only the encrypted version, and MUST accept= only the encrypted version > b) Implementations MUST offer both the encrypted and unencrypted versions= , and MUST accept both >=20 > Of these, a) is the less complicated option. To be precise, 6904 says an answerer MUST NOT accept both encrypted and une= ncrypted versions of the same header (in the same answer). I think option = b) should say that Implementations MUST be prepared to accept either encryp= ted and unencrypted. [I.e., I agree with Martin, whose e-mail came in whil= e I was writing this.] If we go this way, there=92s then a W3C question of whether to provide an A= PI knob to choose between the encrypted and unencrypted version of the head= er extension. From nobody Thu Mar 6 05:56:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF561A017E for ; Thu, 6 Mar 2014 05:55:58 -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 OngMP00fgk5i for ; Thu, 6 Mar 2014 05:55:53 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9341A0156 for ; Thu, 6 Mar 2014 05:55:53 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so3168729wgh.31 for ; Thu, 06 Mar 2014 05:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4RcmiRqYzlAnTXzEb00htEjxWf756cnM4h7juhx3u18=; b=PC5eLzU9N8L2kucFZWZw+rOSgEq30z+gr2UqQ3iaCPMPW4YjNkmCTVfVgzInmqFsdL sPeC/DSs6kUY6VnN+gLiE7bUhGAf7x6t9GJ496rRubBlTn3OYb6r9/lr0a7D9hI8yQdw xPzAS+qE9YtCHZ6sBpagN7I6VkC+ZKcJt4MZ8t5ojBwmFmCF/D271v+W0wyug+Zm9X3d DFgg1lLaSiQHhLP8nBoaGRi2jRPEk6kkO3o0C32a+WgT6VGNM084xYHiLTUheKUq/bPd 1MhZSCXq6TF6/RtbQfpssLSqobSmOZn/1nUD6/6o78U4X8z1EaEZxG6hgaSMb6+B2XD3 Araw== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr10471045wjb.28.1394114148910; Thu, 06 Mar 2014 05:55:48 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 05:55:48 -0800 (PST) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> Date: Thu, 6 Mar 2014 13:55:48 +0000 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RQRHummZuuW3ecnyFmFLSERSq7o Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 06 Mar 2014 13:55:59 -0000 On 6 March 2014 13:54, Jonathan Lennox wrote: > If we go this way, there=E2=80=99s then a W3C question of whether to prov= ide an API knob to choose between the encrypted and unencrypted version of = the header extension. That's a very good reason to go with option a :) I don't want to expose that knob to the Internet. From nobody Thu Mar 6 05:57:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197351A0156 for ; Thu, 6 Mar 2014 05:57:25 -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, 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 7r2PzJPOm-SZ for ; Thu, 6 Mar 2014 05:57:21 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 137EA1A0078 for ; Thu, 6 Mar 2014 05:57:20 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-7c-53187ebc4eed Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 07.9F.04249.CBE78135; Thu, 6 Mar 2014 14:57:16 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.347.0; Thu, 6 Mar 2014 14:57:15 +0100 Message-ID: <53187EB1.4010106@ericsson.com> Date: Thu, 6 Mar 2014 13:57:05 +0000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti , "Cullen Jennings (fluffy)" References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> <0526965B-6AC9-42F4-9E62-CF3BF29872D3@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvje6eOolgg3fTtSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxpvPE9gLVulWvJy5gLWBcbZS FyMnh4SAicTpq3PZIWwxiQv31rN1MXJxCAkcYZRof7mOFSQhJLCMUWLrkmIQm1dAW+Lf5+9g DSwCKhKbrk0Cs9kELCRu/mhkA7FFBYIldh74zQhRLyhxcuYTli5GDg4RgXCJaRtVQMLMAuoS dxafA2sVFgiSmNI2gRli1WtGiStdcSA2p0CgxLTDXYwgrRIC4hI9jUEQrQYSRxbNYYWw5SWa t86GatWWaGjqYJ3AKDQLyeJZSFpmIWlZwMi8ipGjOLU4KTfdyGATIzBsD275bbGD8fJfm0OM 0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgrFm8vcKDqey+hGtYqOa2+X4d hRqfHvQ5PbZi5F7O32thvOKHj+ukJfGvS+M2LdhysOVkj8Jh7wLBqzf+uvnFbda1bG/X3SLN vLh+tpKEuOfuQ2uu2ofOiBblvF/8TMUw9t2buyKvNn9YXrz5cWeHUJ38sRXMzGkeYjOv7nK8 d6yh9lnQ/wO+SizFGYmGWsxFxYkAqRryXSkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qO_YpR68TXhdV-NyTRK6yzac6Zw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 06 Mar 2014 13:57:25 -0000 Hi, I am not okay with changing 1). I think we MUST mandate implementation of Header Extension encryption if you implement the audio level header extensions. When it comes to use level I am fine with reducing this to RECOMMENDED, with a reasonable motivation, like enabling middleboxes that can avoid to be in the security context to read these headers. Thus resulting in a trade-off between what information one leaks, versus the impact of having the middlebox in the security context. It may also need to be made clear that the trade-off for this may further be changed as we learn more about the feasibility of performing the attack of learning the content of the voice communication based on the audio levels. I realize that the above is mostly useful if one actually gets a control knob for this. But, that is a question for the API. >From my perspective, allowing for exceptions to the default encryption on, when so indicated, is the best way forward. Cheers Magnus On 2014-03-05 14:25, Justin Uberti wrote: > So there are three things here: > 1) MUST the implementation offer encrypted header extensions? (i.e. > mandatory-to-implement) > 2) MUST the implementation use encrypted header extensions? (i.e. > mandatory-to-use) > 3) MUST the implementation expose an API to control this? (i.e. no SDP > munging needed) > > I think we want yes for #1, no for #2, and #3 is potentially interesting > but out of scope for 1.0. > That gives encrypted headers for audio on by default, but remote parties > can negotiate this off using RFC 6904 mechanisms. > > > > On Wed, Mar 5, 2014 at 2:05 PM, Cullen Jennings (fluffy) > > wrote: > > > Well if people don’t want to allow the application to choose to > encrypt this header or not, I will be arguing for MUST NOT encrypt > the RTP headers - all of them. > > A recurring theme at IETF is that people trying to protect E2E > privacy, do things that result in the real world having the only way > they can build applications is to build middle boxes that pretend to > to be an end to the things on both sides. This means that the middle > boxes end up with 100% ability to change everything and we loose all > the protection we hoped to get with E2E security. > > > On Mar 5, 2014, at 1:59 PM, tim panton > wrote: > > > > > On 5 Mar 2014, at 12:32, Cullen Jennings (fluffy) > > wrote: > > > >> > >> I am opposed to mandating that Client-to-Mixer Audio Level RTP > header is REQUIRED to be encrypted. It means that we can not really > build conferencing system where the mixers do not have access to > decrypt the media. > > > > I have to ask: > > Does that matter enough to weaken user security for everyone else? > > > > > >> > >> I would like to propose that the JS application can control if > the header is encrypted or not. > > > > I am deeply uncomfortable about that. I am not a good enough > cryptographer to know, but my instinct > > is that exposing the fact that (for example) most of the top bits > of the ulaw data are zeros in this packet > > must be a risk. > > > > I’m pretty confident that one could detect the pitch of the > speaker and probably fingerprint that down > > to individuals or languages with enough data. > > > >> > >> I am aware of the paper that suggests these audio levels can > reveal the contents of the conversation. There is some element of > truth to this. There is also some element of truth to the point that > if this was true, speech recognition system would work better than > they do. Encrypting this or not is a risk that the application using > the header extension needs to evaluate, and WebRTC system needs to > provide the applications with a control surfaces that allows them to > use this in the way the applications desires. > > > > I am also uncomfortable about the number of little ad-hoc control > surfaces that we seem to be mandating > > without an overall design. > > > > My take is that we should push this out to 2.0 when hopefully we > will have a designed control surface in place. > > > >> > >> I will note that an normal application that used this header > could decide if it was encrypted or not, what is different in RTCWeb > is that we are building a platform and my view is that this platform > should allow the applications build on the platform to decide the > tradeoffs of risk for encrypting this or not. > > > > That isn’t the line we have taken in any other encryption discussion. > > > > Tim. > > > > _______________________________________________ > 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 > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 6 06:17:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3EB1A0385 for ; Thu, 6 Mar 2014 06:17:31 -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 CxlorUZDiVkA for ; Thu, 6 Mar 2014 06:17:30 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C4AFC1A0390 for ; Thu, 6 Mar 2014 06:17:26 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id t60so3190254wes.33 for ; Thu, 06 Mar 2014 06:17:22 -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=gldNBQQkhXNQE8iNVxZgniMuNRGC3P8+R8k+3/rD1oY=; b=pORJARJmFykK8Su63HuY5Dgvizi2X+uxFzz2kQyyKMxm/qCU0xiExvbGdrMN72lqIF jPGVWH3QWj7eZ7J3ISKDumRTNuZdslNh4vwPP0/3gvhEiWhVqPugdE18BwKQSwAGFPd/ 6QIBI7yr6QF4W6T3X4q/hFq5Sh6T0bbwIlx41uSDrWkc42zj+ef4HtGcPlVEa4Gi7Rm2 RODp1eh8oZ7ZAMT3Hjmn+MiBZoDhvfQ3RUDSgB2LmuUjbhoR2D6d/x1tQNQKNDCLBLWI MoY7uJL42hj0FlluFqhyXxMJiRroXsto6LM7T68TAc8UCFD8okR4I8VpHhoWIv94XhJD z8Jg== MIME-Version: 1.0 X-Received: by 10.194.78.180 with SMTP id c20mr10216740wjx.57.1394115442414; Thu, 06 Mar 2014 06:17:22 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 06:17:22 -0800 (PST) In-Reply-To: References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> Date: Thu, 6 Mar 2014 14:17:22 +0000 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mOnUdRBGnMF8Rh41jNWGfTFWQZU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 06 Mar 2014 14:17:31 -0000 On 6 March 2014 13:11, Justin Uberti wrote: > I would expect that corp or ISP servers would also be located very close to > the endpoint. Not in my experience. At least not always. At a previous job, I was forced to use an HTTP proxy that was on the other side of the planet. We were unable to get official clearance for a local breakout. From nobody Thu Mar 6 06:22:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDAA1A03BD for ; Thu, 6 Mar 2014 06:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_18=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 1UqNCC3Wk94g for ; Thu, 6 Mar 2014 06:21:59 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2A11A006B for ; Thu, 6 Mar 2014 06:21:59 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q58so3149600wes.6 for ; Thu, 06 Mar 2014 06:21:55 -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=c6qo2Wy9Lrd7bSJgVOvn0xfsNYNps3ottL3a2uQsn5k=; b=q3743LcXtuieGbf9dfHfZDDF37sabrnBAZNHDJC3FIZeHgQlLHPhRrFVLMBSn52Jea XQtceIxvHu6zxGS3LPiCcy/ImSj5jLZrTTmWIWAYzO7vvrOlrmXkSlKj3JQjS4j33Bx6 mRlbimmFe3aQj7Z8VB0SHT7rpWdY6ixH8uiIFoVu8Qh1f0GRw8q+DPcL19R7FkeRqD6B G/cKPE4jNTJS5Su7ncJFcpMhU0D5v+L/fxLMZI2JRseb7OM+21Vu2SMMzIBJL7mnoY+5 bVbS3fepDl1r6/zHEN1UZgRA1SprhpibiBMW9nFvZzDCN9boviTXwc86yY4nozbkD7n/ 7xvw== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr10695122wjb.28.1394115714988; Thu, 06 Mar 2014 06:21:54 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 06:21:54 -0800 (PST) Date: Thu, 6 Mar 2014 14:21:54 +0000 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LXOhP9YpPwbe3Eoriw0lW7SG5VQ Subject: [rtcweb] Preserving stream isolation when traversing the network 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, 06 Mar 2014 14:22:01 -0000 There was a bit of confusion yesterday regarding stream isolation. Mostly the reasons for its existence. This email is an attempt to explain the rationale in more detail, as well as to explore some of the options. # Problem Statement This is the feature that we rely on for creating end-to-end protected and authenticated calls. We rely on the browser preventing applications from accessing these streams so that they can't be modified, recorded, sent to or through servers, rendered to canvas, pushed into web audio, etc... The basic idea of isolation is already an important part of the web security model. Streams that come from sources other than WebRTC already require protections of this sort. For instance,
On Mar 10, 2014 1:36 AM, "Muthu Arul Mozhi = Perumal (mperumal)" <mperumal= @cisco.com> wrote:

|I think that the existing guidance should be sufficient i= n non-multiplexing

|cases (i.e. BUNDLE).

=A0

I don't think so. Even for non-multiplexing cases, a s= ame stream could use different drop precedence for different packets, as de= scribed in draft-dhesikan-tsvwg-rtcweb-qos

=A0

=A0=A0 The combination of priority input and multiple prec= edence levels

=A0=A0 within a data class provides flexibility for an imp= lementation in

=A0=A0 deciding the importance of the stream and packets w= ithin a stream.

=A0=A0 For example, if I frames are more important than th= e P frames then

=A0=A0 the I frames can be marked with a DSCP with the low= er drop

=A0=A0 precedence.

=A0

My take is that STUN connectivity/consent checks SHOULD us= e the lowest drop precedence within a given data type and priority.<= u>

=A0

|For consent checks, I think the same DSCP markings as any= other ICE connectivity

|checks should be used.

=A0

Agree.

=A0

|If multiplexing is being performed, the connectivity chec= ks probably should

|use the highest DSCP value being used by the multiplexed = media.

=A0

For multiplexed media, I guess there is no WG consensus on= how to mark the stream, yet (draft-ietf-mmusic-sdp-mux-attributes lists tw= o possible options). But, I agree with your proposal in general, since these STUN packets are a kind of (media path) signaling = packets and signaling packets are generally given higher priority..<= u>

=A0

Muthu

=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Monday, March 10, 2014 10:46 AM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] DSCP marking for STUN packets

=A0

I think that the existing guidance should be suffici= ent in non-multiplexing cases (i.e. BUNDLE). For consent checks, I think th= e same DSCP markings as any other ICE connectivity checks should be used; f= or ICE-for-SCTP checks, the same DSCP markings as media packets (i.e. the SCTP traffic) should be used.

=A0

If multiplexing is being performed, the connectivity= checks probably should use the highest DSCP value being used by the multip= lexed media.

=A0

On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Per= umal (mperumal) <mperumal@cisco.com> wrote:

ICE says that an endpoint SHOULD apply the same DSCP marki= ng as media packets to connectivity checks. This looks insufficient for RTCWEB, since it doesn't cover (at least) the following:=

- connectivity checks performed for a stream using differe= nt drop pecedences (draft-dhesikan-tsvwg-rtcweb-qos).<= /p>

- connectivity checks performed for non-media/data-channel= traffic.

- DSCP markings for consent checks.

=A0

Comments on where we need to specify them? The last one ca= n probably go into draft-ietf-rtcweb-stun-consent-freshness?<= u>

=A0<= /u>

Muthu


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

=A0


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

--e89a8f642e1e0c5a6004f43cb6f4-- From nobody Mon Mar 10 06:49:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBEE1A0434 for ; Mon, 10 Mar 2014 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 ldTMfIzmRCgt for ; Mon, 10 Mar 2014 06:49:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4611A041E for ; Mon, 10 Mar 2014 06:48:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-dc-531dc2c5d6f9 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5A.89.10875.5C2CD135; Mon, 10 Mar 2014 14:48:53 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 14:48:52 +0100 Message-ID: <531DC2C4.5060503@ericsson.com> Date: Mon, 10 Mar 2014 14:48:52 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <9ad25bb7847180af05212ce1fc81c105.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <9ad25bb7847180af05212ce1fc81c105.squirrel@www.erg.abdn.ac.uk> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <9ad25bb7847180af05212ce1fc81c105.squirrel@www.erg.abdn.ac.uk> Content-Type: multipart/mixed; boundary="------------010105000008060306090105" X-Brightmail-Tracker: H4sIAAAAAAAAA1VSaUhUYRTle7M6IH5Oo3MxQ9JCczAVpQzawD9iBC4QbWhTPtzGQUZzqaBR Myc1lxzFrcwY0QKpEbdJMmdMcwlzIVNzSRAtYqDSSjHH3rxvBPt37j3n3nO/856QI57luQjj lam0SilXuPNF3KrzW7d8+kz7Iv2KH3oFNVvyBKdRiE63QYWhi6LjMbQiPo1W+Z68IorLbmqk kr/6ZZTNrPPU6LUsH9kJAQdCafcCl2BnGJ1/zrdiMTYh+Lt1LR+JGNyI4H5RPmUl7LEMDJVZ rIiLD0KRZZBnxXwcBNPrpO+EI8HQs4mI3hEGq5ZYAwn2hInFUYEV78FRMNa9QRGzUFgrM7Aa O3wGJrUjzKyQOUgKhVkR5LZzMPRZw67k4DBY2G7lklEZqLM1vBLkWL3LrXqXjODDoP1wBxHs Bh3mWg7BmaD/YuT83xcxuAzBbL+eJQA7QN7wO5YQ4xcIymdzbUQgzLfM2wgDgh+rb/mkYMZ1 SyWUteDiNQ78KZ5mzK1P8oCCZrqaTc8dmvSPbAN6JuKKAR5Z6wWVT0dtegdoNnmQtgRMBds2 iT0Ma4kZ4AYEffrfArJoDMH7qSGKFD0IXlosbARi3I/AmOtMiLsIfnXV8UhmobDS9kBAbjoA hZWv2AE+doWOrXqB9QwJ413Q6VvNflw3WH/Ty9+Jdapcy9+JL6ethvMYBTxDgiR5vCI23b8F MX+osXXTpxMNjUhMaK+Q6y61/24OjhDjWHkqnUjTybQqWnVdQaeYECW0c1Gjo7qb32LmZpXR vV3hm44py1dT95eGTFDaY8IL6orJ5dQ6szlDljA12UlFj19yCh9XadqpxACj9Ikq6WdXuSY9 27/X0zXK+8SRqUOSs7W3E1ZW5Q2fdJebPtZ3COcGcpQOMJOhnr9RbvRxMJr5dHvTPYM0U7p+ yi94KG2xZsnDnZsSJ/f35qhS5P8AD3XKZW8DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k9ymvPb_KZtrk--vLn9u35CGrrQ Subject: [rtcweb] Fwd: [tsvwg] WG Adoption Call for draft-dhesikan-tsvwg-rtcweb-qos - 24th March 2014 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, 10 Mar 2014 13:49:02 -0000 --------------010105000008060306090105 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, For your information the TSVWG has stared an adoption call on draft-dhesikan-tsvwg-rtcweb-qos. Please consider to support this adoption call, and indicate your willingness to help working on this document. Else, this WG will be without one piece of the solution regarding DSCP usage that we clearly had interest before in. Cheers Magnus Westerlund WG Chair --------------010105000008060306090105 Content-Type: message/rfc822; name="[tsvwg] WG Adoption Call for draft-dhesikan-tsvwg-rtcweb-qos - 24th March 2014.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="[tsvwg] WG Adoption Call for draft-dhesikan-tsvwg-rtcweb-qos"; filename*1=" - 24th March 2014.eml" X-Mozilla-Keys: Received: from sessmg10.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.37) with Microsoft SMTP Server id 14.2.347.0; Sun, 9 Mar 2014 09:47:17 +0100 X-AuditID: c1b4fb3e-b7faf8e000001605-18-531c2a95e789 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id EA.18.05637.59A2C135; Sun, 9 Mar 2014 09:47:18 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D70DA1A0232; Sun, 9 Mar 2014 00:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1394354841; bh=e51WvNs4hyVVqGcN4s8YKpGvn0STpQLN1U8vYYGyX8Q=; h=Message-ID:Date:From:To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=a9qnufirP7CkHsyOYyQ0jWr8NuTk/6ZhII9uYysbPXkGD2hShRX+1RkLI0r/r03q3 +auXri8nB2lO+5Bplf0eXcHbcNdX9gykz09jvhoA/Nd//orOHK2UP7DTJjnOIlH3y2 SFcGZXZ/JelHCUbtX4jxE2x5hiL7PPgU6gUA+L7Q= X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13E51A0196 for ; Sun, 9 Mar 2014 00:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 Rk6fJqxItGxp for ; Sun, 9 Mar 2014 00:47:17 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 53D601A011D for ; Sun, 9 Mar 2014 00:47:17 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 214782B451C for ; Sun, 9 Mar 2014 08:47:12 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sun, 9 Mar 2014 08:47:12 -0000 Message-ID: <9ad25bb7847180af05212ce1fc81c105.squirrel@www.erg.abdn.ac.uk> Date: Sun, 9 Mar 2014 08:47:12 +0000 From: To: User-Agent: SquirrelMail/1.4.22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/S6C4mHTOizEt8HcxUYz0WI5aKs4 Subject: [tsvwg] WG Adoption Call for draft-dhesikan-tsvwg-rtcweb-qos - 24th March 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Sender: tsvwg X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTYRjG/XaOZ0fx2Oe8vU7LnIam5SUiBpVE9UcXAlMo8o9s5mlb6pSd KYYQC8tyBpnktVADwy5e0rScgdjyUpGgM6WRSVKZy7DUTFO67Oyo2X/P+z3v8/w+Pj6akNyn pDSbpWO1GkWKjHImSf/uTZuLQ/3iIs/lucmH5/oo+b2Pe+TmhhGR/O2vh4S89MZPsbzkwk75 /ONaR3nni0liF71vYXaQikHxzjuS2BR1JquNiD7hrDJ+259uIbPapgpJPXpHGJATDXgrjDSN LGkv6BtpoAzImZbgRwj0zSUiYShCUPqgXcwPJP5OwNwVCzIg2hYJhPw6lk+TWAa3GysoXktw I4KpgXChNQRK7/Qtra+BOlOgcOwBpvw/joJ2hf7xeTsL8C0EXY0/xAJ4AMG1jpdIGDoQWL9O kMLQjaDe+GXJyUVgLJ9AfBmDD8CnlkKxcKcgGDPn2yEUlkJl9ax9xwNLYOj3qP2untgf5juf UkLWDZ6XfSB5TeAwMIz1UoL2h5yW6yuvVFC/YNdOtp5Lg3n2foTjYPJil4jX7vgYLBb1Le37 grWgCgnaB14O9No1xhgqqo2iAhRSvgpdvgpdvgpdhYi7yJNjOS5VGRUZzmrVJzkuTROuYXVN yPZNnjQvRreiodEoE/KhRTJP5lCwX5zENTEt6YxKwakStBkpLGdCvjQp82Yk5GisBCsVOjaZ ZdNZ7bLrR9MyYIwbbUk3Latks06pU3T/bBHtZEJAu8g8mBJ+h+HSFamcWin4L1CA1Jup5Q3M G6oMzUp2+SOb0VqpO4McHBwkLjZuqlr3v/8ZedNI5s5U8S0uao1upf2zDSyygXN6pDxYp/hn SfUo4TSZ0RsecLhmSOmdMzhdU7ZttH98PFmpXpdbk1B/XFxZ+an25tH1ZOl0/NnzTeYI/WXL 9gxrfs54T7ehJLLtWb1lJjFyS3twmDWoNdOX8IywJBc7fDn4euLIW0Oe0/vcZGXL7rTpupmr usw3XtCUnW3dMLB3ODagtyf422TMq3cyklMpokIJLaf4CwmRXvzDAwAA Return-Path: tsvwg-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC006.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 The TSVWG Chairs are considering adoption of the above draft. This draft has been discussed at previous IETF meetings and on the list. At the recent London IETF meeting it received strong support from the people present in the meeting room, and no comments against adopting this draft as a TSVWG work item. The WG chairs now invite any further comments on this adoption. If there are concerns or comments about adoption please send comments to the list or to the Chairs. We plan to make a final decision on this adoption on 24th March 2014. Gorry, James, and David TSVWG Co-Chairs. --------------010105000008060306090105-- From nobody Mon Mar 10 06:59:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914D81A046C for ; Mon, 10 Mar 2014 06:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=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 JhpDikm2_9Lv for ; Mon, 10 Mar 2014 06:59:14 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 34D451A0462 for ; Mon, 10 Mar 2014 06:59:14 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-42-531dc52c8284 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.1C.04249.C25CD135; Mon, 10 Mar 2014 14:59:08 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 14:59:07 +0100 Message-ID: <531DC52B.6020500@ericsson.com> Date: Mon, 10 Mar 2014 14:59:07 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3RlfnqGywwcTTYhYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8aJA02MBdf5Kp5M/sPcwPiQ u4uRk0NCwERiRstCZghbTOLCvfVsXYxcHEICRxgl9i9bwgjhLGeUeLLzJRNIFa+AtsSBzVvZ uxg5OFgEVCX+T0sFCbMJWEjc/NHIBmKLCgRL7DzwmxGiXFDi5MwnLCBzRAQWMkpsv7yZBSQh LGAscejyUmaIBZMYJeb9PwV2BqeAn8S+65NZQBZICIhL9DQGgYSZBQwkjiyawwphy0s0b50N Vi4EdE9DUwfrBEbBWUj2zULSMgtJywJG5lWMHMWpxUm56UYGmxiBYXpwy2+LHYyX/9ocYpTm YFES5/341jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Oa4UaP5karXSfr2XN+Gx5wn3v3 vM5E1+dvnSUNGlKfP/iu+iFRMbXjX4SJNa/TI7k/wa6CF42axe417n8xZ9IKYbPt986b3DF/ M/vIHAnGpbzf8gR/HmznFWK6s77daGpskv3JzRq3HjXP/WvLsXYnr25c/5WEyQaHnzkqXEw6 KnbIvsD5X7YSS3FGoqEWc1FxIgD+XeIoIQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FhnrXz-hrHczZNUpl9FJdegREd4 Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 10 Mar 2014 13:59:15 -0000 On 2014-03-10 09:24, Christer Holmberg wrote: > Hi, > > > > Before I comment on your proposal, let’s take a few steps back (maybe it > can even solve your issue). > > > > BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp > attributes. I remember we had discussions about that, but I don’t > remember the justification at the moment. But, I wonder whether that > text is from before we made a decision that, unless both endpoints > support BUNDLE, no endpoint will use a single address:port. > > > > So, the question is: do we really need the SDP rtcp attribute? I think it is a question of how you want the fallback to work. In the case of bundle only lines, a non bundle supporting peer will reject them, thus no issues with what is written around RTCP-mux and a=rtcp in those m= blocks. However, the first one if you want that to support fallback that makes sense then you will need both a=rtcp-mux and an a=rtcp (with a different port) to handle that with optimal backwards compatibility. Regarding the motivation for a=rtcp-mux and a=rtcp, I think it is reasonably straight forward. We want a=rtcp-mux to minimize port usage, i.e. ports=1. Not supporting a=rtcp-mux with bundle that would mean two ports (RTP and RTCP) for the bundle group. To get the backwards compatibility the usage of a=rtcp would be required. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 07:18:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEB61A044C for ; Mon, 10 Mar 2014 07:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 Mb_2GKkBpIo7 for ; Mon, 10 Mar 2014 07:18:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3931A0447 for ; Mon, 10 Mar 2014 07:18:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-b3-531dc9c7a522 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 15.AD.10875.7C9CD135; Mon, 10 Mar 2014 15:18:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 15:13:31 +0100 From: Christer Holmberg To: Magnus Westerlund , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcA== Date: Mon, 10 Mar 2014 14:13:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> In-Reply-To: <531DC52B.6020500@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje7xk7LBBi8XS1mseH2O3WLrVCGL tf/a2R2YPRZsKvVYsuQnk8fkx23MAcxRXDYpqTmZZalF+nYJXBmPNn9mK2jmq2idtp+pgXE+ dxcjB4eEgInEv9ccXYycQKaYxIV769m6GLk4hAQOMUqsPnULylnCKLHt/2t2kAY2AQuJ7n/a IHERgYWMEi8/HmAB6RYWMJaY0jmZDcQWARo6d+JrFgjbSeLyxfOMIDaLgKrEvO13wWxeAV+J uxvnMEEs2MYosfflY2aQBKeAjsS+2TfBBjECnfT91BomEJtZQFzi1pP5TBCnCkgs2XOeGcIW lXj5+B8rhK0k8WPDJRaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllI WhYwsqxiZM9NzMxJLzfcxAiMjoNbfuvuYDx1TuQQozQHi5I474e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGMWa7Vf7ewqdTJJhbymf/vSR5ilFDlmfazs3xU6fvHMXx4bjoTel7qff dbE8/PWRofWO+LLwC5vSk3bodvYruQtuqp9uaJ48QSzBRFQ7TqDhW4faVq4o0VLpkq+smooz xXP/nl1jWfut49itvqdpIs5FjTGLDv9Y7MbNfuWyNj/nwmfP7lrfVWIpzkg01GIuKk4EANPI 1HNcAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2oWxcM2dxxr5hm_O12J_8N44Pdg Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 10 Mar 2014 14:18:55 -0000 Hi, >> Before I comment on your proposal, let's take a few steps back (maybe=20 >> it can even solve your issue). =20 >>=20 >> BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp=20 >> attributes. I remember we had discussions about that, but I don't=20 >> remember the justification at the moment. But, I wonder whether that=20 >> text is from before we made a decision that, unless both endpoints=20 >> support BUNDLE, no endpoint will use a single address:port. >>=20 >> =20 >>=20 >> So, the question is: do we really need the SDP rtcp attribute? > > I think it is a question of how you want the fallback to work. In the cas= e of bundle only lines, a non bundle supporting peer will reject them, thu= s=20 > no issues with what is written around RTCP-mux and a=3Drtcp in those m=3D= blocks. However, the first one if you want that to support fallback that=20 > makes sense then you will need both a=3Drtcp-mux and an a=3Drtcp (with a = different port) to handle that with optimal backwards compatibility. > > Regarding the motivation for a=3Drtcp-mux and a=3Drtcp, I think it is rea= sonably straight forward. We want a=3Drtcp-mux to minimize port usage,=20 > i.e. ports=3D1. Not supporting a=3Drtcp-mux with bundle that would mean t= wo ports (RTP and RTCP) for the bundle group. To get the backwards=20 > compatibility the usage of a=3Drtcp would be required. Keep in mind that the offerer must always be prepared that the answerer doe= s not support the rtcp-mux attribute (or the rtcp attribute). So, at least my understanding is: no matter whether BUNDLE is used or not, = if the answer does not contain a rtcp-mux (e.g. in case of fallback) attrib= ute, the offerer must use the default "rtp+1" port. Regards, Christer From nobody Mon Mar 10 07:24:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EF41A0489 for ; Mon, 10 Mar 2014 07:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 wFqhnzDZKsd1 for ; Mon, 10 Mar 2014 07:24:46 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABAE1A0488 for ; Mon, 10 Mar 2014 07:24:45 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-2c-531dcb2761e1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 3A.CD.04853.72BCD135; Mon, 10 Mar 2014 15:24:40 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 15:24:39 +0100 Message-ID: <531DCB27.7070509@ericsson.com> Date: Mon, 10 Mar 2014 15:24:39 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" , Justin Uberti References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvja7Gadlgg8en+Cy2ThWyuPNpDqvF 2n/t7A7MHlN+b2T1WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBmn191nL+gSqWi89JClgXGm QBcjJ4eEgInE7aVPmCBsMYkL99azdTFycQgJnGCU6NmyiQnCWc4o8X36DjaQKl4BbYnp0/Yw djFycLAIqEpsPpkDEmYTsJC4+aMRrERUIFhi54HfjBDlghInZz5hAbFFBFIkNs3fARZnFlCX uLP4HDuILSxgLLH0735miF2XGCX6JxwFS3AK+Eo8+HWZDWSXhIC4RE9jEESvnsSUqy1Qc+Ql mrfOZgaxhYBOa2jqYJ3AKDQLyepZSFpmIWlZwMi8ilGyOLW4ODfdyEAvNz23RC+1KDO5uDg/ T684dRMjMLwPbvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTBuLub+pSuh37I/+MXD1Zv91ZTuXw7eZDRths1HrbJtkdv5ytO4J2w71GeQtMtc+EXqhmwj UUW+9i0TrpaJHbnx8l1+bPqOCycd9kz7PV0tgFkrrti/UCdJs3Z+FTcHn46AYNKcKzzTS2N3 6LidW2jisOT6LfkjKlseZZhs5nm1fFXLi3PpOveUWIozEg21mIuKEwGfrlt8PQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/thuFa61YsnakUQbqVpeZsv3w7TA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 10 Mar 2014 14:24:48 -0000 Hi, (as individual) I think we need to start with what the goals are with the STUN packets. In the initial connectivity establishment of ICE the purpose is to find paths that works. To make that determination at all, I would argue to maximize success one should use best effort markings as the network is least likely to do something strange with such packets, including dropping them for violating policy (even if they should just be downgraded). If one like to use STUN to determine the possibility to get DSCP != BE packets through the network from a peer to peer perspective, then I think one should consider specifying something like the STUN ECN check options that are documented in Section 7.2.2 in RFC 6679. To summarize, this sends an additional round of STUN packets after a working path has been found to check ECN compliance in this path. It includes and option indicating the ECT value entered, and the receiver echoes the received value back. Thus enabling a sender to determine that the path is ECT. Something similar could be specified if desired to determine that at least the network doesn't drop packets with DSCP != BE. For consent freshness I don't think we need to do that on a per traffic marking type level. Thus, the important is that it reaches the peer. And the packet reaching the just needs to be statistically high enough probability over a sequence of checks. Thus, I would say that the only important factor here is to not mark it so that it has significant higher drop probability. It also don't need to be minimal delay, thus EF appears overkill and although AFx could be used, that should rather be based on a traffic mix with a lot of AFx traffic. In the end, it might be easier to not use other DSCP marking that BE for the STUN, simple because it gives the most robust behavior and not subject to network issues due to policing or DSCP remarking. I think it will be important to take the considerations for using multiple DSCP on the same 5-tuple that DART will document into account here. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 07:28:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAE61A0447 for ; Mon, 10 Mar 2014 07:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=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 HTUVaWAUuQcf for ; Mon, 10 Mar 2014 07:28:00 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6A1A043E for ; Mon, 10 Mar 2014 07:27:59 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-88-531dcbe999be Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 02.40.04249.9EBCD135; Mon, 10 Mar 2014 15:27:53 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 15:27:53 +0100 Message-ID: <531DCBE9.70701@ericsson.com> Date: Mon, 10 Mar 2014 15:27:53 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rvfladlgg+bZ+hYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8aFrf/ZCuaKVrw6uJKtgfGf QBcjJ4eEgInE8XOfWCFsMYkL99azdTFycQgJHGGUuNV6lx3CWc4o8W3WHLAqXgFNiVkrL7GD 2CwCqhKfbneA2WwCFhI3fzSygdiiAsESOw/8ZoSoF5Q4OfMJC8ggEYGFjBLbL29mAUkICxhL HLq8lBliwxdGiUsnvoJ1cwr4SVzY/BdoKgfQTeISPY1BIGFmAT2JKVdbGCFseYnmrbOZQWwh AW2JhqYO1gmMgrOQ7JuFpGUWkpYFjMyrGDmKU4uTctONDDYxAgP14JbfFjsYL/+1OcQozcGi JM778a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGfWbrmB7nF917o+MW6n+Ibeq8e52t m/7kfg9tOLxt3bHEy5NXxZ04Nm/7/GTvtO3nprem7mNLUlHc9vfZD57CteXGJhM3/7WrWpp/ 2r7opFx2jf2VfC95JoP5DbcVfM5svb17a5/7TafXJR/e2ZxzfuN56HbWrlNJMsdrd/WZPPx9 4szhZ6m/biixFGckGmoxFxUnAgBmngQJIgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6CeR9bM0Ct7r1NEmm32CM8Qh3kM Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 10 Mar 2014 14:28:00 -0000 On 2014-03-10 15:13, Christer Holmberg wrote: > Hi, > >>> Before I comment on your proposal, let's take a few steps back >>> (maybe it can even solve your issue). >>> >>> BUNDLE currently mandates the usage of both the SDP rtcp-mux and >>> rtcp attributes. I remember we had discussions about that, but I >>> don't remember the justification at the moment. But, I wonder >>> whether that text is from before we made a decision that, unless >>> both endpoints support BUNDLE, no endpoint will use a single >>> address:port. >>> >>> >>> >>> So, the question is: do we really need the SDP rtcp attribute? >> >> I think it is a question of how you want the fallback to work. In >> the case of bundle only lines, a non bundle supporting peer will >> reject them, thus no issues with what is written around RTCP-mux >> and a=rtcp in those m= blocks. However, the first one if you want >> that to support fallback that makes sense then you will need both >> a=rtcp-mux and an a=rtcp (with a different port) to handle that >> with optimal backwards compatibility. >> >> Regarding the motivation for a=rtcp-mux and a=rtcp, I think it is >> reasonably straight forward. We want a=rtcp-mux to minimize port >> usage, i.e. ports=1. Not supporting a=rtcp-mux with bundle that >> would mean two ports (RTP and RTCP) for the bundle group. To get >> the backwards compatibility the usage of a=rtcp would be required. > > Keep in mind that the offerer must always be prepared that the > answerer does not support the rtcp-mux attribute (or the rtcp > attribute). Yes, that was what I meant with fallback in the above text. What you do in case the peer doesn't support bundle. > > So, at least my understanding is: no matter whether BUNDLE is used or > not, if the answer does not contain a rtcp-mux (e.g. in case of > fallback) attribute, the offerer must use the default "rtp+1" port. I have a tendency to agree, which means that the first m= block in a bunde-only group will be required to contain a=rtcp and if RTCP mux is desired also that attribute. I think a=rtcp could be skipped for a bound-only m= block due to the requirement on supporting a=rtcp-mux if you do bundle. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 07:38:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722271A0479 for ; Mon, 10 Mar 2014 07:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=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 e-O3swvKohox for ; Mon, 10 Mar 2014 07:38:39 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id CEA781A0446 for ; Mon, 10 Mar 2014 07:38:38 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-da-531dce68e8bc Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 81.DF.04853.86ECD135; Mon, 10 Mar 2014 15:38:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 15:38:32 +0100 From: Christer Holmberg To: Magnus Westerlund , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5A= Date: Mon, 10 Mar 2014 14:38:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> In-Reply-To: <531DCBE9.70701@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvjW7mOdlgg42bmSxWvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErow1R78zFUwVr1i74ShjA+NV oS5GDg4JAROJPVfKuhg5gUwxiQv31rN1MXJxCAmcYJT4+HQ3lLOEUeL8r6lMIA1sAhYS3f+0 QeIiAgsZJV5+PMAC0i0sYCwxpXMyG4gtAjR07sTXLBC2n8SOw3PB4iwCqhLX7n5hArF5BXwl rq3YxQpiCwnMYpJ4/0QdxOYU0JK43nIBrIYR6KLvp9aA2cwC4hK3nsxngrhUQGLJnvPMELao xMvH/1ghbCWJHxsusUDU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELS soCRZRWjZHFqcXFuupGBXm56bolealFmcnFxfp5eceomRmD8HNzy22gH48k99ocYpTlYlMR5 r7PWBAkJpCeWpGanphakFsUXleakFh9iZOLglGpgzJa4/T3KKrjIKpwv4dC0uXPvV3Z/y1nv Xnqc+2lm2+ZGhjm77xeviwta8TmU+R3/SQPTy28vLHp/5XVV0/OSN5UWth+bp7B+DHvmoDb1 8qypVhnPOJtj+hh92afYqQVaqFcGXdL9evnq6Rk907lU+F7t7zuyh9Gg7c15nR3Bne12lV/1 boYrKLEUZyQaajEXFScCABMsI8ttAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uOOgc3_pDCad95IXktJIhBygITw Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 10 Mar 2014 14:38:40 -0000 Hi, >>>> Before I comment on your proposal, let's take a few steps back=20 >>>> (maybe it can even solve your issue). >>>>=20 >>>> BUNDLE currently mandates the usage of both the SDP rtcp-mux and=20 >>>> rtcp attributes. I remember we had discussions about that, but I=20 >>>> don't remember the justification at the moment. But, I wonder=20 >>>> whether that text is from before we made a decision that, unless=20 >>>> both endpoints support BUNDLE, no endpoint will use a single=20 >>>> address:port. >>>>=20 >>>>=20 >>>>=20 >>>> So, the question is: do we really need the SDP rtcp attribute? >>>=20 >>> I think it is a question of how you want the fallback to work. In the=20 >>> case of bundle only lines, a non bundle supporting peer will reject=20 >>> them, thus no issues with what is written around RTCP-mux and a=3Drtcp= =20 >>> in those m=3D blocks. However, the first one if you want that to=20 >>> support fallback that makes sense then you will need both a=3Drtcp-mux= =20 >>> and an a=3Drtcp (with a different port) to handle that with optimal=20 >>> backwards compatibility. >>>=20 >>> Regarding the motivation for a=3Drtcp-mux and a=3Drtcp, I think it is=20 >>> reasonably straight forward. We want a=3Drtcp-mux to minimize port=20 >>> usage, i.e. ports=3D1. Not supporting a=3Drtcp-mux with bundle that wou= ld=20 >>> mean two ports (RTP and RTCP) for the bundle group. To get the=20 >>> backwards compatibility the usage of a=3Drtcp would be required. >>=20 >> Keep in mind that the offerer must always be prepared that the=20 >> answerer does not support the rtcp-mux attribute (or the rtcp=20 >> attribute). > > Yes, that was what I meant with fallback in the above text. What you do i= n case the peer doesn't support bundle. >=20 >> So, at least my understanding is: no matter whether BUNDLE is used or=20 >> not, if the answer does not contain a rtcp-mux (e.g. in case of >> fallback) attribute, the offerer must use the default "rtp+1" port. > > I have a tendency to agree, which means that the first m=3D block in a bu= nde-only group will be required to contain a=3Drtcp and if RTCP mux is desi= red also that attribute. > > I think a=3Drtcp could be skipped for a bound-only m=3D block due to the = requirement on supporting a=3Drtcp-mux if you do bundle. For bundle-only, I actually think BOTH can be skipped, because bundle-only = will by default use whatever address:port is negotiated - both for RTP and = RTCP. But, for non-bundle-only, I still ask whether we really need a=3Drtcp. Isn'= t a=3Drtcp-mux enough? If the answerer supports it, you will use it, otherw= ise you will use rtp+1. Otherwise, assume that the answerer supports BOTH a=3Drtcp and a=3Drtcp-mux= . Which has higher "priority"? How does the answerer knows whether the offe= rer wants to use rtcp-mux, or whether it wants to use whatever port is indi= cated in a=3Drtcp? Regards, Christer From nobody Mon Mar 10 07:42:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24AB1A0437 for ; Mon, 10 Mar 2014 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 Rc8eH-a--pLx for ; Mon, 10 Mar 2014 07:42:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7267C1A0434 for ; Mon, 10 Mar 2014 07:42:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-47-531dcf4d7b69 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 54.11.10875.D4FCD135; Mon, 10 Mar 2014 15:42:21 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 15:42:11 +0100 Message-ID: <531DCF44.1000203@ericsson.com> Date: Mon, 10 Mar 2014 15:42:12 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson , Dan Wing References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja7vedlgg/vbZC0uXnvIZHHtzD9G i7X/2tkdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcyYOp+9YK9QxdW77g2M X/m6GDk4JARMJDovxXUxcgKZYhIX7q1n62Lk4hASOMQo8eViAytIQkhgOaPE1qdCIDavgLZE Y+dxsDiLgKrE308TmEFsNgELiZs/GtlAbFGBYImdB34zQtQLSpyc+YQFxBYR8JT4sGMHmM0s oC5xZ/E5dhBbWMBK4snhAywQi48xSixZ+RdsAadAoMStFxNYIQ4Vl+hpDILo1ZOYcrWFEcKW l2jeOpsZ4k5tiYamDtYJjEKzkKyehaRlFpKWBYzMqxjZcxMzc9LLDTcxAkP34JbfujsYT50T OcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGdf2rhzYu3PRjv9CdN1+P thm2T5jdyeCrYhF/ruTD8vlneu6WHNrRLuw7sWbDdtNTExqqD8gtVVzFOt27ZtlvntJINcs+ q+8Lauwb/Po8t2y6wn+wt0BiWaJOitStbNFXUZJRz+bzX96S2/nY357N98LGD9c0Xxmd/S9d ueb9bRZ/n8KV0yxmKLEUZyQaajEXFScCAFiLdswrAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/szASwva-0S2AwCSo_v0dHHNIzyk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 10 Mar 2014 14:42:30 -0000 On 2014-03-08 07:48, Martin Thomson wrote: > On 7 March 2014 20:14, Dan Wing wrote: >> About half a year ago, AVTCORE published an updated recommendation >> for CNAME as RFC7022. Is its guidance insufficient? > > Necessary, but not sufficient. Unfortunately, the definition of a > "session", while sufficient for the description in 7022, is not > quite precise enough for this use case. The implication there is > that it means "RTP session", which is both not at the right level of > granularity, and not directly actionable. So, within a PeerConnection one have one or more RTP sessions, depending on how one configures it. That RTP session MAY be interconnected with other PeerConnection's RTP sessions by a middlebox. As long as this is different end-points PCs there is little issues. The interesting case here is if one end-point connects multiple PCs to the same middlebox and starts seeing its own traffic due to the middlebox not being built for this usage and the JS programmer thinks this is okay to do. The end-point can always detect this, as it knows all its used CNAMEs, and can note that they are looped back to itself if this check is implemented. If one have the same CNAME is both PC's RTP session instances the RTP stack is more likely to detect this without code changes as a loop. The only reason I can see for having multiple PCs being connected to the same middlebox would be if that makes the setup of QoS simpler, but I think MST individual RTP sessions within the context of one PC is more straight forward to ensure that one have unique 5-tuples per media stream. > > I also note this little gem: > > A longer-term persistent RTCP CNAME is sometimes useful to > facilitate third-party monitoring, consistent with [RFC3550]. Yes, but that is clearly not suitable for WebRTC. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 07:44:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CCC1A0447 for ; Mon, 10 Mar 2014 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-B77bZIbQZj for ; Mon, 10 Mar 2014 07:44:19 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 700F21A0437 for ; Mon, 10 Mar 2014 07:44:19 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so8770259wgg.33 for ; Mon, 10 Mar 2014 07:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=95v1CFzLtJCMvXlTTIV9/LE19VxVZhmzEqPxF+cK9ZY=; b=TxFAfG5MHbv0owY8s7+9TzNd5yvL9VgDuz1AKoMTflEWXicRDy9RfOEReNa+6mPJop nahrcIcI3ODzrzWr3W46HbDFy8BzTOwzk6mnQZUhN8MFJutyK9yHSDBYWBuw1FgswOZY LXrY3Hiv9jcVwmiEJesnAkRHtt2ngIl/avjmhwTW6bKTsHj6xT+8OqR0gKrRXTR0HPIQ L9SfqLIX+SZysieWW/ae+aEptHsTMn0zALZ3g1HC7gTB+uLPD3CGzWdq6GCpy0qcsXKe F6nDdTcJ0XvlfnbD9DJOOJPfS50i79E0GfNWEG1oWqWSI9v2zFF7Bika2/msGw1jnYaZ Blvg== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr8189981wiw.56.1394462653636; Mon, 10 Mar 2014 07:44:13 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 07:44:13 -0700 (PDT) In-Reply-To: <531DCF44.1000203@ericsson.com> References: <531DCF44.1000203@ericsson.com> Date: Mon, 10 Mar 2014 15:44:13 +0100 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1OQvLN8vuvJzymeW4DIzcy1uexo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 10 Mar 2014 14:44:21 -0000 On 10 March 2014 15:42, Magnus Westerlund wrote: >> A longer-term persistent RTCP CNAME is sometimes useful to >> facilitate third-party monitoring, consistent with [RFC3550]. > > Yes, but that is clearly not suitable for WebRTC. I'm sure that's not the only thing it's unsuitable for. From nobody Mon Mar 10 08:04:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8861A0450 for ; Mon, 10 Mar 2014 08:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 uPQHOCiwNjKr for ; Mon, 10 Mar 2014 08:04:07 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id AF41E1A0233 for ; Mon, 10 Mar 2014 08:04:06 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-4e-531dd460f98d Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 9A.A3.04853.064DD135; Mon, 10 Mar 2014 16:04:00 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:04:00 +0100 Message-ID: <531DD460.20200@ericsson.com> Date: Mon, 10 Mar 2014 16:04:00 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <531DCF44.1000203@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvjW7CFdlgg6f9ehYXrz1ksrh25h+j xdp/7ewOzB5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4MiZtvc5aMJOrYmF7E3sD 43qOLkZODgkBE4nfd6cyQthiEhfurWfrYuTiEBI4wSix/PwcVghnOaPE/LdvmECqeAU0JXau uc4OYrMIqEqcPjuTGcRmE7CQuPmjkQ3EFhUIlth54DcjRL2gxMmZT1hAbBEBXYlFZx+A9TIL OEsse9sDVi8sYCXx5PABFohlq5kktkzpBWvmFAiU+HFyGlARB9B54hI9jUEQvZoSrdt/Q82R l2jeOhvsBiEBbYmGpg7WCYxCs5CsnoWkZRaSlgWMzKsYJYtTi4tz040M9HLTc0v0Uosyk4uL 8/P0ilM3MQKD/OCW30Y7GE/usT/EKM3BoiTOe521JkhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY/y62AOzNnVwxBpqylUKtH8VSo/Zt7Ps5IfANVnLTlo5G07963vOUl7yYeEhIf19arP2 nF/q/aVvonlfiW/u46sn+kMirhTPkVmx3n+v8oaJcVWTI5nvFM3lmPNVwzrrVvyu7S8TowsS fZgT3Z57THBMkZp/teaIctu2bW7GSsxbK6tjQ2wzlViKMxINtZiLihMBJk93I0ACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nGN2AS4B9RGSpsBInpDaqpVqVsk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 10 Mar 2014 15:04:08 -0000 On 2014-03-10 15:44, Martin Thomson wrote: > On 10 March 2014 15:42, Magnus Westerlund > wrote: >>> A longer-term persistent RTCP CNAME is sometimes useful to >>> facilitate third-party monitoring, consistent with [RFC3550]. >> >> Yes, but that is clearly not suitable for WebRTC. > > I'm sure that's not the only thing it's unsuitable for. > No, but there are cases where this can be a desired property in someone building an application. For example an astronomy sensory network that deliver sensor data over RTP. In that case you are not talking about human user's endpoints, and you also may have a private network and want to make monitoring at key points simple. Thus having the sensors being provided a persistent name is simple and straight forward. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 08:16:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693C71A0233 for ; Mon, 10 Mar 2014 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=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 nZL0eKnM0VaY for ; Mon, 10 Mar 2014 08:16:52 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2849E1A0492 for ; Mon, 10 Mar 2014 08:16:44 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-ba-531dd756dcbe Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BF.25.04853.657DD135; Mon, 10 Mar 2014 16:16:39 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:16:38 +0100 Message-ID: <531DD756.50900@ericsson.com> Date: Mon, 10 Mar 2014 16:16:38 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvjW74ddlgg6cr+C1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsEroyny9sZC1bKV6xsrmlg7JTs YuTgkBAwkWh6XNHFyAlkiklcuLeerYuRi0NI4ASjxL0/W5lBEkICyxklJkzRBbF5BTQlZl1f xgpiswioSuz+NAfMZhOwkLj5o5ENxBYVCJbYeeA3I0S9oMTJmU9YQIaKCCxklNh+eTMLSEJY wFji0OWlzBDbrjBJfN/1jAkkwSngJ/F08nUmiOvEJXoag0DCzAJ6ElOutjBC2PISzVtnQx2n LdHQ1ME6gVFwFpJ9s5C0zELSsoCReRWjZHFqcXFuupGBXm56bolealFmcnFxfp5eceomRmAQ H9zy22gH48k99ocYpTlYlMR5r7PWBAkJpCeWpGanphakFsUXleakFh9iZOLglGpgnKl91Vfj MOeB3Cqx6S8U3ugsFHsx0/PsNBW9jPqjcjnBa0RCVZfdXvqHe5ffuXWqR7rFqjO8zc8vNm5p FtN4c91bqvzoffG9u6qcpubEd3z9edmJY3vK8ktbfprUboj4KVawhv2ubNnTq7e+fU6/u/mB aUUpz72K/O8q3kebpEWNHi5xf/tLSYmlOCPRUIu5qDgRALxPNRwwAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kpFdQ5_NR3viaFYaYUW4Ao7hYI4 Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 10 Mar 2014 15:16:53 -0000 On 2014-03-10 15:38, Christer Holmberg wrote: > Hi, > >>>>> Before I comment on your proposal, let's take a few steps >>>>> back (maybe it can even solve your issue). >>>>> >>>>> BUNDLE currently mandates the usage of both the SDP rtcp-mux >>>>> and rtcp attributes. I remember we had discussions about >>>>> that, but I don't remember the justification at the moment. >>>>> But, I wonder whether that text is from before we made a >>>>> decision that, unless both endpoints support BUNDLE, no >>>>> endpoint will use a single address:port. >>>>> >>>>> >>>>> >>>>> So, the question is: do we really need the SDP rtcp >>>>> attribute? >>>> >>>> I think it is a question of how you want the fallback to work. >>>> In the case of bundle only lines, a non bundle supporting peer >>>> will reject them, thus no issues with what is written around >>>> RTCP-mux and a=rtcp in those m= blocks. However, the first one >>>> if you want that to support fallback that makes sense then you >>>> will need both a=rtcp-mux and an a=rtcp (with a different port) >>>> to handle that with optimal backwards compatibility. >>>> >>>> Regarding the motivation for a=rtcp-mux and a=rtcp, I think it >>>> is reasonably straight forward. We want a=rtcp-mux to minimize >>>> port usage, i.e. ports=1. Not supporting a=rtcp-mux with bundle >>>> that would mean two ports (RTP and RTCP) for the bundle group. >>>> To get the backwards compatibility the usage of a=rtcp would be >>>> required. >>> >>> Keep in mind that the offerer must always be prepared that the >>> answerer does not support the rtcp-mux attribute (or the rtcp >>> attribute). >> >> Yes, that was what I meant with fallback in the above text. What >> you do in case the peer doesn't support bundle. >> >>> So, at least my understanding is: no matter whether BUNDLE is >>> used or not, if the answer does not contain a rtcp-mux (e.g. in >>> case of fallback) attribute, the offerer must use the default >>> "rtp+1" port. >> >> I have a tendency to agree, which means that the first m= block in >> a bunde-only group will be required to contain a=rtcp and if RTCP >> mux is desired also that attribute. >> >> I think a=rtcp could be skipped for a bound-only m= block due to >> the requirement on supporting a=rtcp-mux if you do bundle. > > For bundle-only, I actually think BOTH can be skipped, because > bundle-only will by default use whatever address:port is negotiated - > both for RTP and RTCP. No, I see a path of grief to not explicitly signal things when you use them. I also thought the a=rtcp-mux is a MUST to implement, not a MUST use. > > But, for non-bundle-only, I still ask whether we really need a=rtcp. > Isn't a=rtcp-mux enough? If the answerer supports it, you will use > it, otherwise you will use rtp+1. My understanding is that a=rtcp has been required in any non-private network deployments due to NATs for the last 10 years. Thus, I don't see how you can remove them and expect it to work, unless you are doing a=rtcp-mux. Thus, my view would be that you can remove a=rtcp if you know that the peer supprots a=rtcp-mux. > > Otherwise, assume that the answerer supports BOTH a=rtcp and > a=rtcp-mux. Which has higher "priority"? How does the answerer knows > whether the offerer wants to use rtcp-mux, or whether it wants to use > whatever port is indicated in a=rtcp? That is a=rtcp-mux per RFC 5761 that has higher priority, please see Section 5.1.1. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 08:19:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503771A043E for ; Mon, 10 Mar 2014 08:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 T2ovF_zyoc9e for ; Mon, 10 Mar 2014 08:19:43 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id AE7791A031D for ; Mon, 10 Mar 2014 08:19:42 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-c3-531dd8088b69 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id D4.85.04853.808DD135; Mon, 10 Mar 2014 16:19:36 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:19:35 +0100 Message-ID: <531DD807.9090602@ericsson.com> Date: Mon, 10 Mar 2014 16:19:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson , Justin Uberti References: <53171C20.3020001@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+JvjS7HDdlgg+8rtS22ThWyuHbmH6PF 2n/t7A7MHjtn3WX3WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBlvrtsUnBermLjlA2sD41ah LkZODgkBE4nb9w6wQthiEhfurWfrYuTiEBI4wSjx59FrNpCEkMByRokdVwxAbF4BbYmfTzaz gNgsAqoSH08uArPZBCwkbv5oBKsXFQiW2HngNyNEvaDEyZlPwGpEgOK3jt5lBrGZBdQl7iw+ xw5iCwtYSTw5fIAFYvF+Jonp3y+DNXMKBEocf/ANyOYAuk5coqcxCKJXU6J1+292CFteonnr bGaIO7UlGpo6WCcwCs1CsnoWkpZZSFoWMDKvYpQsTi0uzk03MtDLTc8t0UstykwuLs7P0ytO 3cQIDO6DW34b7WA8ucf+EKM0B4uSOO911pogIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwr gwPCr+s5Xvp76mHprHJX0RftCkwZ9XV/DsdI75Zwmv8nK/jnlwUlUdtiUi23G4rEzmAw9k/h Dc1U0ZB5uf7ar/ehW6IuXFmhoDV778vme73Pbdt91x978y8n2kLV1Vny6JrL4jMnTU0VPJLq /Wx7eYxLrHJNjsf2ildTxapWFZ5R1/8ieUyJpTgj0VCLuag4EQCE6EwePAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/paDFvvmLjjJtCi5WbnT-uXaLnNI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 10 Mar 2014 15:19:44 -0000 On 2014-03-05 17:07, Martin Thomson wrote: > On 5 March 2014 14:30, Justin Uberti wrote: >> I am inclined to make CNAMEs per-PeerConnection (i.e. enforce scenario #2 >> behavior) for 1.0, as it has a smaller downside. > > I think that I am OK with this. It might still be possible to > synchronize in the first scenario, but it would require that the > playback protect itself against drift, because CNAME wouldn't be > providing a positive indication that synchronization is safe. > Please slow down here, Can you please think through the linkage issue a bit first before changing this property. I know that it might appear simple to mandate different CNAMES on a Per PC basis, but I do think it has downsides. One has to do with loop detection between the PCs, i.e. determine if one receives one self's MSTs. The next one is that it will prevent someone to easily determine if the MST in two different PCs are actually sharing the same synchronization context. As the default really needs to not synchronize RTP media with different SSRCs, having the JS app direct the browser to please consider some set of CNAMEs as being equal will be a problematic one, and require API surface. I want to understand what issue with linkages that we have here before determining what to do. So, different application contexts, i.e. different browser TABs on an end-point will have different CNAMEs, thus different applications will not allow linking between them. The linkage we have is between PCs originating in the same JS application instance. In cases where a set of end-points participate in a conference, they will see only one CNAME from this endpoint. I guess the linkage issue appears when one application have the endpoint participate in two or more conferences either simultaneous or in sequence (assuming that CNAME will be persistent as long as some PC exists or during the JS application lifetime). In that case an external endpoint participating in more than one of these conferences can see the same CNAME appears in both conferences. And thus link any input provided, if the applications doesn't otherwise reveal the user identity etc. anyway. I have a hard time determine the impact of this linkage issue, as it will depend on the application context, and also the CNAMEs persistence over time within a JS APP context. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 08:28:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888061A0457 for ; Mon, 10 Mar 2014 08:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 WZsI-XkkCbvy for ; Mon, 10 Mar 2014 08:28:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7068D1A0438 for ; Mon, 10 Mar 2014 08:28:12 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-e2-531dda06a72d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4A.17.10875.60ADD135; Mon, 10 Mar 2014 16:28:06 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:28:05 +0100 Message-ID: <531DDA05.5050707@ericsson.com> Date: Mon, 10 Mar 2014 16:28:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Huangyihong (Rachel)" , "rtcweb@ietf.org" References: <51E6A56BD6A85142B9D172C87FC3ABBB861952E2@nkgeml501-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB861952E2@nkgeml501-mbs.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3RpftlmywwckZKhZLO0+xW6z9187u wOTRcuQtq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIe7/zOWPCEp2J5b1ED4wquLkYODgkBE4kv /WZdjJxAppjEhXvr2boYuTiEBA4xSjxZ2MgC4SxnlHizeicjSBWvgLbE/zPr2EFsFgFVifmH 5jCB2GwCFhI3fzSygdiiAsESOw/8hqoXlDg58wkLiC0iEC3R076DGWSxsICpxK893CBhIYFQ iX/nFrCC2JwCYRLbHvUzQtwmLtHTGAQSZhYwkDiyaA4rhC0v0bx1NjNEq7ZEQ1MH6wRGwVlI ls1C0jILScsCRuZVjOy5iZk56eWGmxiBwXhwy2/dHYynzokcYpTmYFES5/3w1jlISCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA6OAt2blIc7TqbVfDVS3OgQJ7tme9sjCesaSOempnEqJpkd2 vE2f8DJJZbaL4hMJ58p5lYJMNakJDYZs/Jf55uuZCze1+CuIL1HtCtmwLCQk+/i1hYe1vkxM uMRsFOe5vi+7fM7BZuFz56Yd0wloVXluM0tYNXNy59XzW14mPft+NnmbY1OsjhJLcUaioRZz UXEiACcmUPAUAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TgZ_GU1ktiBFHSFFcpZ2AJyZ-vM Subject: Re: [rtcweb] RTP usage: supporting RTP ECN? 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, 10 Mar 2014 15:28:17 -0000 On 2014-03-06 10:56, Huangyihong (Rachel) wrote: > Hi, > > > > draft-ietf-rtcweb-rtp-usage-12 doesn’t have any description regarding to > RTP ECN RFC6679. I’m wondering why. But from my point of view, it’s > worth some discussion. The usage of ECN is a trend though it is not > universal in current network. Supporting it in browsers for RTP media > transport may be good for future. > Hi Rachel, (as individual/author) We did consider ECN for RTP and it was discussed a bit at the Stockholm interim meeting in June 2012. My recollection of this is that the complexity trade-off versus the potential gains and the risk for it causing negative impact resulted in that we did not included it at this stage. I do think adding ECN would be a good thing, but we do need to know that it is working reasonably well and provide a benefit sufficiently often. I think the importance of AQM will enable more deployment of ECN also. Thus enabling improved performance for real-time applications like WebRTC based ones. I would suggest that we revisit this question after the core set of specifications have been done. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 08:34:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236FD1A04A2 for ; Mon, 10 Mar 2014 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 Qcv25yj3xYaV for ; Mon, 10 Mar 2014 08:33:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 22E761A049E for ; Mon, 10 Mar 2014 08:33:52 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-75-531ddb5bab4d Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F4.DE.23809.B5BDD135; Mon, 10 Mar 2014 16:33:47 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:33:46 +0100 Message-ID: <531DDB5A.4060201@ericsson.com> Date: Mon, 10 Mar 2014 16:33:46 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simon Perreault , Justin Uberti References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> In-Reply-To: <53187960.2010709@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+JvjW70bdlgg6WXBSy2ThWyWPuvnd2i e+l/FgdmjwWbSj2WLPnJ5LHug3kAcxSXTUpqTmZZapG+XQJXxsGX61kKbrJXbFq7mq2BcS5b FyMnh4SAicS0GTOZIWwxiQv31gPFuTiEBA4xSuw/vJgFwlnOKNHcfpQFpIpXQFvi96mFjCA2 i4CqxLavF8BsNgELiZs/GsGmigoES+w88JsRol5Q4uTMJ2C9IgLhEp/W97CD2MwC6hJ3Fp8D s4UFjCRurb7NDLHsGYvE4T1bmUASnEDL1hxeAGRzAJ0nLtHTGATRqynRuv031Bx5ieats8E+ EAIqb2jqYJ3AKDQLyepZSFpmIWlZwMi8ipE9NzEzJ73caBMjMHQPbvmtuoPxzjmRQ4zSHCxK 4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBU1Oba6bLby255e4nL/Kcp1R9EmU69 fmRam7bv+uVU5ucX58qWpyZN0meren1GTsRMa7b44e6dV2x2HVbcWfhZ4uHK6qVem7f+X2v5 7Mo/wXYFazuxmex2FSfVErenul+6oSDVV5xqL/loe6dhn+u3maz2p5I8GyK+Rn0qe5/fc/qd wBHRNx+UWIozEg21mIuKEwE6nr7uKwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9GkX_hahOD5HXQHBniUXp7Nju1w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 10 Mar 2014 15:34:05 -0000 On 2014-03-06 14:34, Simon Perreault wrote: > Le 2014-03-06 13:23, Justin Uberti a écrit : >> can we agree that TURN TCP candidates are a SHOULD NOT? > > Not a SHOULD, sure. SHOULD NOT, no. > I would guess that the simplest is to remove discussion of TURN TCP altogether from Transports. That would not recommend it nor make it disallowed. If we want to be explicit, then simply motivate why we don't believe it necessary. Justin, what is the reason you wanted SHOULD NOT? cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 08:49:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6FF1A043E for ; Mon, 10 Mar 2014 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw_fBCy9Mne2 for ; Mon, 10 Mar 2014 08:49:14 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id E823E1A04B0 for ; Mon, 10 Mar 2014 08:49:10 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so8837822wgh.23 for ; Mon, 10 Mar 2014 08:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTpS9Ix6fmuRmmmEC2vPKO+eQoKCYW1CM2M25lwo+As=; b=d42Zrt4Lvb+BZxe5MOYPVNE/u7n4DVOEfBmSXBY9xax8Bb19YeZitj/bdqWuGFpzab EHiyMg77KWGiDnO5ogbGSH0MciYGPuts5KeLcNzCccKmjCTTpStHPORQMB7zud8YeTCV MjlWeWMBHQC14fXYM0Ya6+NLeB/9LqdVGvmXAh2iBPfQ10GY8NB+FMgohUOdzLg5Af+T aSTAQdColmhFUyGKXOCBd8IzZBDzYhRunZ55fB+wR+c8KdduapulLWKjOn1HD73teSsu nY1Gk3aV9hPjnrRIIPb3jSMjjYjkP3aRha3D1c4xObEexTC3Bkse4BkciqlCP9cH/8pW EjtA== MIME-Version: 1.0 X-Received: by 10.194.192.132 with SMTP id hg4mr6557988wjc.28.1394466544789; Mon, 10 Mar 2014 08:49:04 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 08:49:04 -0700 (PDT) In-Reply-To: <531DD807.9090602@ericsson.com> References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> Date: Mon, 10 Mar 2014 16:49:04 +0100 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-ccLUvX9CiMhWxkdxRRtyR_FJPc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 10 Mar 2014 15:49:16 -0000 On 10 March 2014 16:19, Magnus Westerlund wrote: > Can you please think through the linkage issue a bit first before > changing this property. We already came to the conclusion that if media was being forwarded by a peer, then that is new media originated by that peer, not the same media. Thus, if looping occurs, it is at the application layer. We definitely already agreed that RTP forwarding is not a function that a browser will support. Obviously, if we add that feature, CNAMEs will be just one of the manifold issues that will arise and we will have to reconsider. Compromising the privacy of users doesn't seem like a good trade-off against some minor advantages in terms of loop detection (unlikely) and synchronization (easy to apply manually). From nobody Mon Mar 10 08:58:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685FF1A04A7 for ; Mon, 10 Mar 2014 08:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 Yjc3YfZ3kXk1 for ; Mon, 10 Mar 2014 08:58:04 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 900FB1A0265 for ; Mon, 10 Mar 2014 08:58:03 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-74-531de10519a4 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EC.82.23809.501ED135; Mon, 10 Mar 2014 16:57:57 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:57:57 +0100 Message-ID: <531DE104.2010908@ericsson.com> Date: Mon, 10 Mar 2014 16:57:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti , "rtcweb@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3Rpf1oWywwbT9ehZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgy9vTuZys4JFyx6dEqxgbG5fxdjJwcEgImEkf7 t7NC2GISF+6tZ+ti5OIQEjjEKLGl7QsLhLOcUWLRlV/sIFW8AtoSy8+uAbNZBFQlzp1sYwax 2QQsJG7+aGQDsUUFgiV2HvjNCFEvKHFy5hMWEFtEwFui5f0EsLiwgK7EuuV7mLoYOYAWBEis 2xEBEuYUCJS403iNBSQsISAu0dMYBBJmFtCTmHK1hRHClpdo3jobbKsQ0DUNTR2sExgFZyFZ NgtJyywkLQsYmVcxsucmZuaklxttYgQG48Etv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjMn9jtrXnUWZNYw5osKY5ONzvGXT2lkdJGJFTL8kMrrtrJ6c Vl2soqZva3pKpuTDIXbTE89fGGVNm5L96NMRW167KqMzDcx2hjlz7uwx85b6sjH74oU4Bs6o H8s0ec70e/MYKBntPnE68LuGfcextbNZuKof8Oku+/5izoW27wvunha79vShEktxRqKhFnNR cSIAdPftTRQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_My-UyVdBHxKeb4cidwzVzWse7Y Subject: Re: [rtcweb] On ptimes and maxptimes 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, 10 Mar 2014 15:58:05 -0000 Hi, (As individual) On 2014-03-05 17:26, Justin Uberti wrote: > From the session this morning, I recall this consensus: > > * We will add recommendations on the frame sizes to use for PCMU/A to > the rtcweb audio codec I-D (20, 30, 60 ms frames). The above applies to sending payloads Yes, but that was given that a receiver will be capable of receiving any valid number of frames, or samples within a reasonable packetization, and I think that should be 120 ms. > * We will consider adding an a=maxptime attribute that represents the > "minimum maxptime" of all the offered codecs. That is, if both Opus > (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a > maxptime=60 SHOULD be included. > o Since maxptime spans all codecs, this means that some modes > (e.g. Opus 120ms) will be unavailable, unless only Opus is offered. I think you base the assumption on maxptime based on the sending recommendations, not what is capable of receiving. If one is capable of receiving 200 ms of a-law and Opus, then you would need to say 120 ms as Opus will limit you. > * We will consider adding an a=ptime attribute, set to the receiver's > preferred frame size to receive. Again, this value spans all codecs, > so the specified value may not be viable for all codecs (e.g. 30 ms > works for PCMU but not for Opus) > > After thinking about this some, I'm not sure the maxptime/ptime values > will lead to any different behavior than if they were not specified. > Since there is a complexity cost (especially if the values need to > change based on which codecs are offered), is there a clear upside here? The maxptime values may in some cases be limited downwards for interoperability, for example if one like to gateway AMR into a CS network then the gateway might indicate a maxptime that is less, more like 20 or 40 ms. Please remember that these rules do apply to any codec, not only the MTI ones. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 10 13:09:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA2C1A024B for ; Mon, 10 Mar 2014 13:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 tGDTVeFnla1D for ; Mon, 10 Mar 2014 13:09:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 112021A0495 for ; Mon, 10 Mar 2014 13:09:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-0f-531e1bf2d310 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 19.BE.10875.2FB1E135; Mon, 10 Mar 2014 21:09:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 21:09:21 +0100 From: Christer Holmberg To: Magnus Westerlund , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mw Date: Mon, 10 Mar 2014 20:09:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> In-Reply-To: <531DD756.50900@ericsson.com> 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+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje4nablggzmLJC1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozNN7+xFaxRq1hzaRFjA+NP uS5GTg4JAROJP8sPMULYYhIX7q1n62Lk4hASOMQo0bxtBlhCSGAJo8TbE9ldjBwcbAIWEt3/ tEFqRAQWMkq8/HiABaRGWMBYYkrnZDYQWwRo6NyJr1lA6kUEoiQu/40BCbMIqErs+r6XCcTm FfCV2Pl5AiPErn9MEv+bVoMlOAW0JB6dmA22lxHooO+n1oDFmQXEJW49mc8EcaiAxJI955kh bFGJl4//sULYShKLbn+GqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmF pGUBI8sqRvbcxMyc9HLDTYzA2Di45bfuDsZT50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgbEp/q+4bqcP13z5M4ETQpysq3Xc8yrf/onp/22ffXvHss9XXpe2627c fTQ20jVLZUXZs7iHuxIzmZedcUk6fzHiu4V2X9BiPrZpJ3ZMO70p+0LB8diLSvaLjord/vnT XCRoI8fvqtaXz2dckZ0QN6NQs2XzEsYArTt57/jOOqmGbmJ8UPrO5IISS3FGoqEWc1FxIgD6 GKfLWwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XYj2ef8oCYPqYr4mdQ7T84WksoM Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 10 Mar 2014 20:09:32 -0000 Hi, >>>>>> Before I comment on your proposal, let's take a few steps back=20 >>>>>> (maybe it can even solve your issue). >>>>>>=20 >>>>>> BUNDLE currently mandates the usage of both the SDP rtcp-mux and=20 >>>>>> rtcp attributes. I remember we had discussions about that, but I=20 >>>>>> don't remember the justification at the moment. >>>>>> But, I wonder whether that text is from before we made a decision=20 >>>>>> that, unless both endpoints support BUNDLE, no endpoint will use a=20 >>>>>> single address:port. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> So, the question is: do we really need the SDP rtcp attribute? >>>>>=20 >>>>> I think it is a question of how you want the fallback to work. >>>>> In the case of bundle only lines, a non bundle supporting peer=20 >>>>> will reject them, thus no issues with what is written around=20 >>>>> RTCP-mux and a=3Drtcp in those m=3D blocks. However, the first one if= =20 >>>>> you want that to support fallback that makes sense then you will=20 >>>>> need both a=3Drtcp-mux and an a=3Drtcp (with a different port) to=20 >>>>> handle that with optimal backwards compatibility. >>>>>=20 >>>>> Regarding the motivation for a=3Drtcp-mux and a=3Drtcp, I think it is= =20 >>>>> reasonably straight forward. We want a=3Drtcp-mux to minimize port=20 >>>>> usage, i.e. ports=3D1. Not supporting a=3Drtcp-mux with bundle that=20 >>>>> would mean two ports (RTP and RTCP) for the bundle group. >>>>> To get the backwards compatibility the usage of a=3Drtcp would be=20 >>>>> required. >>>>=20 >>>> Keep in mind that the offerer must always be prepared that the=20 >>>> answerer does not support the rtcp-mux attribute (or the rtcp=20 >>>> attribute). >>>=20 >>> Yes, that was what I meant with fallback in the above text. What you=20 >>> do in case the peer doesn't support bundle. >>>=20 >>>> So, at least my understanding is: no matter whether BUNDLE is used=20 >>>> or not, if the answer does not contain a rtcp-mux (e.g. in case of=20 >>>> fallback) attribute, the offerer must use the default "rtp+1" port. >>>=20 >>> I have a tendency to agree, which means that the first m=3D block in a= =20 >>> bunde-only group will be required to contain a=3Drtcp and if RTCP mux=20 >>> is desired also that attribute. >>>=20 >>> I think a=3Drtcp could be skipped for a bound-only m=3D block due to th= e=20 >>> requirement on supporting a=3Drtcp-mux if you do bundle. >>=20 >> For bundle-only, I actually think BOTH can be skipped, because=20 >> bundle-only will by default use whatever address:port is negotiated -=20 >> both for RTP and RTCP. > > No, I see a path of grief to not explicitly signal things when you use th= em.=20 But, the whole idea of using port zero in bundle-only was that, if the answ= erer supports BUNDLE, port zero will be replaced with the negotiated addres= s:port. When you send the offer, you don't yet know which address:port will be sele= cted, so there is no idea to insert a=3Drtcp. Inserting a=3Drtcp-mux probab= ly doesn't harm, though, so I won't argue about it :) >I also thought the a=3Drtcp-mux is a MUST to implement, not a MUST use. Currently the draft says MUST use. But, that may be a mistake, or a leftove= r from previous procedures. I agree that one should be able to use BUNDLE a= lso without rtcp-mux (i.e. using separate BUNDLE ports for the RTP traffic = and the RTCP traffic). =20 >> But, for non-bundle-only, I still ask whether we really need a=3Drtcp. >> Isn't a=3Drtcp-mux enough? If the answerer supports it, you will use it,= =20 >> otherwise you will use rtp+1. > >My understanding is that a=3Drtcp has been required in any non-private net= work deployments due to >NATs for the last 10 years. Thus, I don't see how = you can remove them and expect it to work, unless >you are doing a=3Drtcp-m= ux. Thus, my view would be that you can remove a=3Drtcp if you know that th= e >peer supprots a=3Drtcp-mux. Are you saying that we should use a=3Drtcp ONLY to indicate the RTP port, i= n case the answerer does not support a=3Drtcp-mux? =20 >> Otherwise, assume that the answerer supports BOTH a=3Drtcp and=20 >> a=3Drtcp-mux. Which has higher "priority"? How does the answerer knows=20 >> whether the offerer wants to use rtcp-mux, or whether it wants to use=20 >> whatever port is indicated in a=3Drtcp? > > That is a=3Drtcp-mux per RFC 5761 that has higher priority, please see Se= ction 5.1.1. You are right - my mistake. But, never the less, if the offerer sends both a=3Drtcp-mux and a=3Drtcp, u= nless a=3Drtcp points to the rtp port, the offerer needs to be prepared to = use 3 different ports for RTCP (rtp+1 port, rtp port and rtp+), because it does not know which attribute (if any) the answerer support= s, and which (if any) the answerer is willing to use. Regards, Christer From nobody Mon Mar 10 13:57:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0208F1A04B0 for ; Mon, 10 Mar 2014 13:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro-sTTOewfNe for ; Mon, 10 Mar 2014 13:57:17 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 104811A04A6 for ; Mon, 10 Mar 2014 13:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1748; q=dns/txt; s=iport; t=1394485032; x=1395694632; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=ZkCjE+ZRd6BMfuCQTz6rtQUZi4tG9I08uzTnaVtY5FA=; b=OpohU+xo6L/LeUTbnzeYULn5bKlGddpy2BgDADwCsHooZ+5suJ0WDwRO MvoLbxTNUo3DoKf+lmfBu+/AvNMp/iwqYuCB14xFoP5KZuroNuKHE7Ebv k7dpOIsWNFq0cdDOO/C8ScVmViaOi5E3PJ/geze0t1yYbIY/sEJJ1aU+X 4=; X-IronPort-AV: E=Sophos;i="4.97,626,1389744000"; d="scan'208";a="309281505" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Mar 2014 20:57:11 +0000 Received: from jmpolk-WS.cisco.com ([10.21.78.182]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2AKv90t026761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2014 20:57:11 GMT Message-Id: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2014 15:57:09 -0500 To: Justin Uberti , "Muthu Arul Mozhi Perumal (mperumal)" From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HH0qztqt4UtfZdpuxHTVcg7hZdE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 10 Mar 2014 20:57:19 -0000 At 12:16 AM 3/10/2014, Justin Uberti wrote: >I think that the existing guidance should be sufficient in >non-multiplexing cases (i.e. BUNDLE). For consent checks, I think >the same DSCP markings as any other ICE connectivity checks should >be used; for ICE-for-SCTP checks, the same DSCP markings as media >packets (i.e. the SCTP traffic) should be used. > >If multiplexing is being performed, the connectivity checks probably >should use the highest DSCP value being used by the multiplexed media. why is (seemingly) everyone's default position "use the highest DSCP available" for signaling packets? You just need to make sure the packets aren't starved or dropped by/at congestion points. James >On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Perumal (mperumal) ><mperumal@cisco.com> wrote: > >ICE says that an endpoint SHOULD apply the same DSCP marking as >media packets to connectivity checks. This looks insufficient for >RTCWEB, since it doesn't cover (at least) the following: > >- connectivity checks performed for a stream using different drop >pecedences (draft-dhesikan-tsvwg-rtcweb-qos). > >- connectivity checks performed for non-media/data-channel traffic. > >- DSCP markings for consent checks. > > > >Comments on where we need to specify them? The last one can probably >go into draft-ietf-rtcweb-stun-consent-freshness? > > > >Muthu > >_______________________________________________ >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 Mon Mar 10 14:39:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F111A04C5 for ; Mon, 10 Mar 2014 14:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYmZ3u2mr8DC for ; Mon, 10 Mar 2014 14:39:38 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 8418B1A0146 for ; Mon, 10 Mar 2014 14:39:38 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WN7v1-0004Oy-Ao; Mon, 10 Mar 2014 22:39:31 +0100 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WN7v0-0002Jv-Tr; Mon, 10 Mar 2014 22:39:31 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Welzl In-Reply-To: <531DDA05.5050707@ericsson.com> Date: Mon, 10 Mar 2014 22:39:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0B90C6-552F-465B-9481-EA878EE5DDDA@ifi.uio.no> References: <51E6A56BD6A85142B9D172C87FC3ABBB861952E2@nkgeml501-mbs.china.huawei.com> <531DDA05.5050707@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 5 sum msgs/h 3 total rcpts 13474 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 12CC5D15BD0C70D3FCD2CA73E3420F4389ADDCA1 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 963 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O-UiUSl57er53tIxw90fcqsCVZk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP usage: supporting RTP ECN? 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, 10 Mar 2014 21:39:41 -0000 > I would suggest that we revisit this question after the core set of > specifications have been done. +1 =3D> ECN for rtcweb could be great. Cheers, Michael >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 10 21:34:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF71C1A0574 for ; Mon, 10 Mar 2014 21:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_PayXVJmgPN for ; Mon, 10 Mar 2014 21:34:25 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BD5351A04AE for ; Mon, 10 Mar 2014 21:34:24 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so3486954wgh.29 for ; Mon, 10 Mar 2014 21:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tJV3tCjZxrtRiHeFgNPY02OrpdZPPa2VxWfeMG4alqQ=; b=FXD3fh3v9wt+ZmRRpTWD7Iil0NYuZdOM6ZxwnatMmdnkJhCtvPSUbQWyLz97CcPgU0 hfADd0y/VQI4WQq0H9YRIRYVGFMTlmmcGvUy1mHlxL4BSe0qS7j+DP2YkYN8frcADUlO ahKqZSg/4qT5+TNxk1r+iKjfpEP8h93diQF33nW1O/g/jf+yYdnMEMw4wB8vvaesZus+ KpvaQB0DpIy89FjB3eWeZDIa1GIpAqFseWerzKo1Sin2evcvr3fXPXoLlkRmv6kdDDqQ oqZCbN+m4b/VDr6v9j58XGuaGaWCIGgx6DqNoSN/UHPZlRQzjbSk7K4RAYZM8jej7qgd C7Jg== X-Received: by 10.180.87.9 with SMTP id t9mr1263312wiz.36.1394512458739; Mon, 10 Mar 2014 21:34:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.161.66 with HTTP; Mon, 10 Mar 2014 21:33:58 -0700 (PDT) In-Reply-To: <531DDA05.5050707@ericsson.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB861952E2@nkgeml501-mbs.china.huawei.com> <531DDA05.5050707@ericsson.com> From: Bernard Aboba Date: Mon, 10 Mar 2014 21:33:58 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d0444eb67bcf47a04f44d3b7c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tFCArxHx39Nv8vS9vyETVNtq_vA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP usage: supporting RTP ECN? 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, 11 Mar 2014 04:34:30 -0000 --f46d0444eb67bcf47a04f44d3b7c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 to what Magnus said. ECN for RTP isn't mature enough to make this a WebRTC requirement at this time. On Mon, Mar 10, 2014 at 8:28 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-06 10:56, Huangyihong (Rachel) wrote: > > Hi, > > > > > > > > draft-ietf-rtcweb-rtp-usage-12 doesn't have any description regarding t= o > > RTP ECN RFC6679. I'm wondering why. But from my point of view, it's > > worth some discussion. The usage of ECN is a trend though it is not > > universal in current network. Supporting it in browsers for RTP media > > transport may be good for future. > > > > Hi Rachel, > (as individual/author) > > We did consider ECN for RTP and it was discussed a bit at the Stockholm > interim meeting in June 2012. My recollection of this is that the > complexity trade-off versus the potential gains and the risk for it > causing negative impact resulted in that we did not included it at this > stage. > > I do think adding ECN would be a good thing, but we do need to know that > it is working reasonably well and provide a benefit sufficiently often. > I think the importance of AQM will enable more deployment of ECN also. > Thus enabling improved performance for real-time applications like > WebRTC based ones. > > I would suggest that we revisit this question after the core set of > specifications have been done. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 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 > --f46d0444eb67bcf47a04f44d3b7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 to what Magnus said.  ECN for RTP isn't mature= enough to make this a WebRTC requirement at this time. 


On Mon, Mar 10, 2014 = at 8:28 AM, Magnus Westerlund <magnus.westerlund@ericsson.com= > wrote:
On 2= 014-03-06 10:56, Huangyihong (Rachel) wrote:
> Hi,
>
>
>
> draft-ietf-rtcweb-rtp-usage-12 doesn’t have any description rega= rding to
> RTP ECN RFC6679. I’m wondering why. But from my point of view, i= t’s
> worth some discussion. The usage of ECN is a trend though it is not > universal in current network. Supporting it in browsers for RTP media<= br> > transport may be good for future.
>

Hi Rachel,
(as individual/author)

We did consider ECN for RTP and it was discussed a bit at the Stockholm
interim meeting in June 2012. My recollection of this is that the
complexity trade-off versus the potential gains and the risk for it
causing negative impact resulted in that we did not included it at this
stage.

I do think adding ECN would be a good thing, but we do need to know that it is working reasonably well and provide a benefit sufficiently often.
I think the importance of AQM will enable more deployment of ECN also.
Thus enabling improved performance for real-time applications like
WebRTC based ones.

I would suggest that we revisit this question after the core set of
specifications have been done.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone=  +46 10 7= 148287
F=E4r=F6gatan 6                 | M= obile +46 73 09= 49079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--f46d0444eb67bcf47a04f44d3b7c-- From nobody Mon Mar 10 21:44:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC51A04AE for ; Mon, 10 Mar 2014 21:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_55=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 jsrk-3Yv4ohK for ; Mon, 10 Mar 2014 21:44:01 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 611AA1A0361 for ; Mon, 10 Mar 2014 21:44:01 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so7193697wgh.3 for ; Mon, 10 Mar 2014 21:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Si3T0k9DMzGd+kKgddjEquMukmEt++54xH+wgF43Ac=; b=m1O5CfQXZm89mtiOw2jDrGBhitodzB/sggeP7p7vGbjkQCGKGF2jQtugwbRGRb2D5d 2fmNBVJKJnWTPyztw/HvOiiZLb3+RF0+gckXSO709uHVJwGg0ce4rnOhqaYluIa3eAin HwkP6+ik1t5+3u1LTAEogg7KT11ZlwgMRkgLi5dpIWk/7s9tL98x07QF80RD3zn1kasU pwd+5WfEmnSz0Es7gZN16p1G63sthd9ztUs6w6dslkIWQ4rOhZq26kduAem2ZpL3z+Hc KJjsF//iTBG73FDuOaPWeGR1UonD+k1xuF257c0O/5CzByZHL22BU0o8VXtkS+aWcTe8 nGYg== X-Received: by 10.180.98.200 with SMTP id ek8mr1294021wib.4.1394513035334; Mon, 10 Mar 2014 21:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.161.66 with HTTP; Mon, 10 Mar 2014 21:43:35 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Mon, 10 Mar 2014 21:43:35 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d044288601b1bb704f44d5e1a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aAYZM44S3fYb8tZK9OLy7C5b3no Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 11 Mar 2014 04:44:04 -0000 --f46d044288601b1bb704f44d5e1a Content-Type: text/plain; charset=ISO-8859-1 Christer said: "BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp attributes. I remember we had discussions about that, but I don't remember the justification at the moment." [BA] The justification was that an implementation interested in multiplexing A/V would almost certainly also want to multiplex RTP and RTCP, because the motivation for both is minimizing port usage. On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Before I comment on your proposal, let's take a few steps back (maybe it > can even solve your issue). > > > > BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp > attributes. I remember we had discussions about that, but I don't remember > the justification at the moment. But, I wonder whether that text is from > before we made a decision that, unless both endpoints support BUNDLE, no > endpoint will use a single address:port. > > > > So, the question is: do we really need the SDP rtcp attribute? > > > > Regards, > > > > Christer > > > > > > > > > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* 10. maaliskuuta 2014 8:18 > *To:* rtcweb@ietf.org; Eric Rescorla; Christer Holmberg > *Subject:* BUNDLE with implicit rtcp-mux > > > > In my JSEP preso during the RTCWEB session last Wednesday, I discussed > adding a new BUNDLE policy to JSEP. This policy, which would be called > something like "force-bundle", would force the use of the same ports for > BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the > other side supports BUNDLE, this would reduce candidate gathering even over > the currently defined "max-bundle" policy, since there would be no need to > gather RTCP ports at all, and also avoid the need for the BUNDLE fixup > offer (where the ports are updated to be the same for all BUNDLEd > m-sections). > > To explain the differences here, here are some example offers for an > audio+video call: > > Default bundle policy - separate ports for audio, video, RTP and RTCP: > m=audio 10000 > a=rtcp:10001 > a=rtcp-mux > m=video 11000 > a=rtcp:11001 > a=rtcp-mux > > Existing "max-bundle" policy - video port is 0 because bundle-only, but > both RTP and RTCP ports allocated for audio: > m=audio 10000 > a=rtcp:10001 > a=rtcp-mux > m=video 0 > a=bundle-only > a=rtcp-mux > > The new "force-bundle" policy - only a single set of ports allocated - > audio, video, RTP, RTCP share the same port. > m=audio 10000 > a=rtcp:10000 > a=rtcp-mux > m=video 10000 > a=rtcp:10000 > a=rtcp-mux > > During the discussion, the ability to avoid RTCP port gathering was seen > as valuable, but not the ability to avoid the fixup offer. However, after > thinking about it a bit, I don't think that there is a viable solution that > avoids RTCP port gathering that *doesn't* use a single set of ports. The > only other option would be to do something like this: > > m=audio 10000 > a=rtcp:10000 # same as m=audio port > a=rtcp-mux > m=video 0 > a=bundle-only > a=rtcp-mux > > but this will almost surely will result in a malfunction when talking to a > non-rtcp-mux client, due to the same port being used for RTP and RTCP, and > still requires the fixup offer, and as such is net worse than the > force-bundle approach indicated above. > > So I think we the force-bundle approach is the one we want to minimize > port gathering. The only question is whether we should keep max-bundle as > well. To be specific, we need to decide between: > > a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and > add a new force-bundle policy that creates an offer with a single port > shared between all m-sections (RTP and RTCP). max-bundle remains nominally > backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it > will still send a single audio stream. force-bundle is not backwards > compatible with non-BUNDLE endpoints. > > b) Add force-bundle, but get rid of max-bundle. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d044288601b1bb704f44d5e1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Christer said: 

"BUN= DLE currently mandates the usage of both the SDP rtcp-mux and rtcp attribut= es. I remember we had discussions about that, but I don’t remember th= e justification at the moment."

[BA] The justification was that an implementation inter= ested in multiplexing A/V would almost certainly also want to multiplex RTP= and RTCP, because the motivation for both is minimizing port usage. <= /div>


On Mon,= Mar 10, 2014 at 1:24 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:

Hi,<= /p>

 

Before I comment on your = proposal, let’s take a few steps back (maybe it can even solve your i= ssue).

 

BUNDLE currently mandates= the usage of both the SDP rtcp-mux and rtcp attributes. I remember we had = discussions about that, but I don’t remember the justification at the moment. But, I wonder whether that text is from before we made a de= cision that, unless both endpoints support BUNDLE, no endpoint will use a s= ingle address:port.

 

So, the question is: do w= e really need the SDP rtcp attribute?

 

Regards,

 

Christer

 

 

 

 

 

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: 10. maaliskuuta 2014 8:18
To: rtcweb@ietf= .org; Eric Rescorla; Christer Holmberg
Subject: BUNDLE with implicit rtcp-mux

=

 

In my JSEP preso during the RTCWEB session last Wedn= esday, I discussed adding a new BUNDLE policy to JSEP. This policy, which w= ould be called something like “force-bundle”, would force the use of the same ports for BUNDLEd m-sections, as well as RTCP mu= x. When one knows a priori that the other side supports BUNDLE, this would = reduce candidate gathering even over the currently defined “max-bundl= e” policy, since there would be no need to gather RTCP ports at all, and also avoid the need for the BUNDLE fixup = offer (where the ports are updated to be the same for all BUNDLEd m-section= s).

To explain the differences here, here are some examp= le offers for an audio+video call:

Default bundle policy - separate ports for audio, vi= deo, RTP and RTCP:
m=3Daudio 10000
a=3Drtcp:10001
a=3Drtcp-mux
m=3Dvideo 11000
a=3Drtcp:11001
a=3Drtcp-mux

Existing "max-bundle" policy - video port = is 0 because bundle-only, but both RTP and RTCP ports allocated for audio:<= br> m=3Daudio 10000
a=3Drtcp:10001
a=3Drtcp-mux
m=3Dvideo 0
a=3Dbundle-only
a=3Drtcp-mux

The new “force-bundle” policy - only a s= ingle set of ports allocated - audio, video, RTP, RTCP share the same port.=
m=3Daudio 10000
a=3Drtcp:10000
a=3Drtcp-mux
m=3Dvideo 10000
a=3Drtcp:10000
a=3Drtcp-mux

During the discussion, the ability to avoid RTCP por= t gathering was seen as valuable, but not the ability to avoid the fixup of= fer. However, after thinking about it a bit, I don’t think that there is a viable solution that avoids RTCP port gathering that= *doesn’t* use a single set of ports. The only other option would be = to do something like this:

m=3Daudio 10000
a=3Drtcp:10000 # same as m=3Daudio port
a=3Drtcp-mux
m=3Dvideo 0
a=3Dbundle-only
a=3Drtcp-mux

but this will almost surely will result in a malfunc= tion when talking to a non-rtcp-mux client, due to the same port being used= for RTP and RTCP, and still requires the fixup offer, and as such is net worse than the force-bundle approach indicated above.

So I think we the force-bundle approach is the one w= e want to minimize port gathering. The only question is whether we should k= eep max-bundle as well. To be specific, we need to decide between:

a) Keep max-bundle as it is (separate RTP and RTCP p= orts allocated), and add a new force-bundle policy that creates an offer wi= th a single port shared between all m-sections (RTP and RTCP). max-bundle remains nominally backwards compatible with non-BUND= LE/non-rtcp-mux endpoints, in that it will still send a single audio stream= . force-bundle is not backwards compatible with non-BUNDLE endpoints.

b) Add force-bundle, but get rid of max-bundle.


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


--f46d044288601b1bb704f44d5e1a-- From nobody Mon Mar 10 21:48:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED8F1A0361 for ; Mon, 10 Mar 2014 21:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJhrWLWtPTKg for ; Mon, 10 Mar 2014 21:47:55 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id E88FC1A04AE for ; Mon, 10 Mar 2014 21:47:54 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so326820wiw.5 for ; Mon, 10 Mar 2014 21:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YiSk2Mgy7qbBi5jV4CWMGuGJ1QmnUzwo4iYCl8aHO/g=; b=y/Gv7MxDQhDyXY9mn+y8AXgJNdPAkdPTF7UjpqIoCB8mHq5IlNIESHeIaDm9qjKyua iEPW20RfMml9rcNxCt330ZNcEOgGqFN56sWlvWbEeGLeaJvv8+eK2ABvRjgKKYvBcSaa YnDbI+C+gFVqGGQuxsOx9gyOQ5CK+1G1LriONE0+VC34ydo3ww/JLxjs7Zn22Ir+iUav KVzjXGGUAfjtoo7s1PWsxcynrJWNuL7HKH664cGRFbiZLwSnLxQJjlRnc1o5voD9jh38 ryH0IWMleIRtnB7ph/JlTBW7kdz+jDnfX6OS01RpXiA1+e+PrJ2kBbfJSZxXYDroMIlP wIpA== X-Received: by 10.180.98.200 with SMTP id ek8mr1304555wib.4.1394513268910; Mon, 10 Mar 2014 21:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.161.66 with HTTP; Mon, 10 Mar 2014 21:47:28 -0700 (PDT) In-Reply-To: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> From: Bernard Aboba Date: Mon, 10 Mar 2014 21:47:28 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=f46d0442886007319104f44d6c59 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8S-q1Xi3GlgbIGgUPRsskoeCSzk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 11 Mar 2014 04:47:58 -0000 --f46d0442886007319104f44d6c59 Content-Type: text/plain; charset=ISO-8859-1 Cullen said: "I am opposed to mandating that Client-to-Mixer Audio Level RTP header is REQUIRED to be encrypted. It means that we can not really build conferencing system where the mixers do not have access to decrypt the media." [BA] I am also not enthused about mandating encryption of header extensions. However, in the interest of fairness, it is worth pointing out that header extensions are optional, so if a particular extension is encrypted, the mixer can always ignore it (and in this case, thereby do more work mixing muted audio streams). So my take would be to say SHOULD encrypt Client-to-MIxer Audio level, but leave this up to negotiation so that if the mixer doesn't want it encrypted, it can turn that off. On Wed, Mar 5, 2014 at 4:32 AM, Cullen Jennings (fluffy) wrote: > > I am opposed to mandating that Client-to-Mixer Audio Level RTP header is > REQUIRED to be encrypted. It means that we can not really build > conferencing system where the mixers do not have access to decrypt the > media. > > I would like to propose that the JS application can control if the header > is encrypted or not. > > I am aware of the paper that suggests these audio levels can reveal the > contents of the conversation. There is some element of truth to this. There > is also some element of truth to the point that if this was true, speech > recognition system would work better than they do. Encrypting this or not > is a risk that the application using the header extension needs to > evaluate, and WebRTC system needs to provide the applications with a > control surfaces that allows them to use this in the way the applications > desires. > > I will note that an normal application that used this header could decide > if it was encrypted or not, what is different in RTCWeb is that we are > building a platform and my view is that this platform should allow the > applications build on the platform to decide the tradeoffs of risk for > encrypting this or not. > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d0442886007319104f44d6c59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Cullen said:=A0

"I am opposed to mandating that C= lient-to-Mixer Audio Level RTP header is REQUIRED to be encrypted. It means= that we can not really build conferencing system where the mixers do not h= ave access to decrypt the media."

[BA= ] I am also not enthused about mandating encryption of header extensions. H= owever, in the interest of fairness, it is worth pointing out that header e= xtensions are optional, so if a particular extension is encrypted, the mixe= r can always ignore it (and in this case, thereby do more work mixing muted= audio streams). =A0So my take would be to say SHOULD encrypt Client-to-MIx= er Audio level, but leave this up to negotiation so that if the mixer doesn= 't want it encrypted, it can turn that off.=A0


On Wed,= Mar 5, 2014 at 4:32 AM, Cullen Jennings (fluffy) <fluffy@cisco.com>= wrote:

I am opposed to mandating that Client-to-Mixer Audio Level RTP header is RE= QUIRED to be encrypted. It means that we can not really build conferencing = system where the mixers do not have access to decrypt the media.

I would like to propose that the JS application can control =A0if the heade= r is encrypted or not.

I am aware of the paper that suggests these audio levels can reveal the con= tents of the conversation. There is some element of truth to this. There is= also some element of truth to the point that if this was true, speech reco= gnition system would work better than they do. Encrypting this or not is a = risk that the application using the header extension needs to evaluate, and= WebRTC system needs to provide the applications with a control surfaces th= at allows them to use this in the way the applications desires.

I will note that an normal application that used this header could decide i= f it was encrypted or not, what is different in RTCWeb is that we are build= ing a platform and my view is that this platform should allow the applicati= ons build on the platform to decide the tradeoffs of risk for encrypting th= is or not.






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

--f46d0442886007319104f44d6c59-- From nobody Tue Mar 11 00:33:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2999C1A0181 for ; Tue, 11 Mar 2014 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-0.547] 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 ACoQh3d6_km3 for ; Tue, 11 Mar 2014 00:33:45 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6A70A1A0278 for ; Tue, 11 Mar 2014 00:33:44 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 43ACE1EB8468; Tue, 11 Mar 2014 08:33:38 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.208]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 08:33:38 +0100 From: "Stach, Thomas" To: Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla , Christer Holmberg Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh+GSOU+/8bGkO7u4qbcBKXjZrbfZNA Date: Tue, 11 Mar 2014 07:33:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE1217A60F57MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/65tpB7-Qci6Cl2CrbxkUQgb8dz8 Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 11 Mar 2014 07:33:47 -0000 --_000_F81CEE99482EFE438DAE2A652361EE1217A60F57MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSB0aG91Z2h0cy9wcm9wb3NhbCBhYm91dCB0aGUgZml4dXAgaW5saW5lLg0KDQpJbiBteSBK U0VQIHByZXNvIGR1cmluZyB0aGUgUlRDV0VCIHNlc3Npb24gbGFzdCBXZWRuZXNkYXksIEkgZGlz Y3Vzc2VkIGFkZGluZyBhIG5ldyBCVU5ETEUgcG9saWN5IHRvIEpTRVAuIFRoaXMgcG9saWN5LCB3 aGljaCB3b3VsZCBiZSBjYWxsZWQgc29tZXRoaW5nIGxpa2Ug4oCcZm9yY2UtYnVuZGxl4oCdLCB3 b3VsZCBmb3JjZSB0aGUgdXNlIG9mIHRoZSBzYW1lIHBvcnRzIGZvciBCVU5ETEVkIG0tc2VjdGlv bnMsIGFzIHdlbGwgYXMgUlRDUCBtdXguIFdoZW4gb25lIGtub3dzIGEgcHJpb3JpIHRoYXQgdGhl IG90aGVyIHNpZGUgc3VwcG9ydHMgQlVORExFLCB0aGlzIHdvdWxkIHJlZHVjZSBjYW5kaWRhdGUg Z2F0aGVyaW5nIGV2ZW4gb3ZlciB0aGUgY3VycmVudGx5IGRlZmluZWQg4oCcbWF4LWJ1bmRsZeKA nSBwb2xpY3ksIHNpbmNlIHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgdG8gZ2F0aGVyIFJUQ1AgcG9y dHMgYXQgYWxsLCBhbmQgYWxzbyBhdm9pZCB0aGUgbmVlZCBmb3IgdGhlIEJVTkRMRSBmaXh1cCBv ZmZlciAod2hlcmUgdGhlIHBvcnRzIGFyZSB1cGRhdGVkIHRvIGJlIHRoZSBzYW1lIGZvciBhbGwg QlVORExFZCBtLXNlY3Rpb25zKS4NClRvIGV4cGxhaW4gdGhlIGRpZmZlcmVuY2VzIGhlcmUsIGhl cmUgYXJlIHNvbWUgZXhhbXBsZSBvZmZlcnMgZm9yIGFuIGF1ZGlvK3ZpZGVvIGNhbGw6DQpEZWZh dWx0IGJ1bmRsZSBwb2xpY3kgLSBzZXBhcmF0ZSBwb3J0cyBmb3IgYXVkaW8sIHZpZGVvLCBSVFAg YW5kIFJUQ1A6DQptPWF1ZGlvIDEwMDAwDQphPXJ0Y3A6MTAwMDENCmE9cnRjcC1tdXgNCm09dmlk ZW8gMTEwMDANCmE9cnRjcDoxMTAwMQ0KYT1ydGNwLW11eA0KRXhpc3RpbmcgIm1heC1idW5kbGUi IHBvbGljeSAtIHZpZGVvIHBvcnQgaXMgMCBiZWNhdXNlIGJ1bmRsZS1vbmx5LCBidXQgYm90aCBS VFAgYW5kIFJUQ1AgcG9ydHMgYWxsb2NhdGVkIGZvciBhdWRpbzoNCm09YXVkaW8gMTAwMDANCmE9 cnRjcDoxMDAwMQ0KYT1ydGNwLW11eA0KbT12aWRlbyAwDQphPWJ1bmRsZS1vbmx5DQphPXJ0Y3At bXV4DQpUaGUgbmV3IOKAnGZvcmNlLWJ1bmRsZeKAnSBwb2xpY3kgLSBvbmx5IGEgc2luZ2xlIHNl dCBvZiBwb3J0cyBhbGxvY2F0ZWQgLSBhdWRpbywgdmlkZW8sIFJUUCwgUlRDUCBzaGFyZSB0aGUg c2FtZSBwb3J0Lg0KbT1hdWRpbyAxMDAwMA0KYT1ydGNwOjEwMDAwDQphPXJ0Y3AtbXV4DQptPXZp ZGVvIDEwMDAwDQphPXJ0Y3A6MTAwMDANCmE9cnRjcC1tdXgNCkR1cmluZyB0aGUgZGlzY3Vzc2lv biwgdGhlIGFiaWxpdHkgdG8gYXZvaWQgUlRDUCBwb3J0IGdhdGhlcmluZyB3YXMgc2VlbiBhcyB2 YWx1YWJsZSwgYnV0IG5vdCB0aGUgYWJpbGl0eSB0byBhdm9pZCB0aGUgZml4dXAgb2ZmZXIuDQpb VFNdIFRoZSBmaXh1cCBpcyBvbmx5IGludHJvZHVjZWQgdG8gYWNjb21tb2RhdGUgYSBjZXJ0YWlu IHZhcmlldHkgb2YgbWlkZGxlYm94ZXMgdGhhdCB3YW50IHRvIHNlZSB0aGUgdXNlZCBwb3J0cyBh bHNvICBpbiB0aGUgU0RQIG9mZmVyL2Fuc3dlci4gVGhlIGZpeHVwIG9mZmVyIGlzIG5vdCB0ZWNo bmljYWxseSBuZWNlc3NhcnkgZm9yIHRoZSB0d28gYnVuZGxlIGNsaWVudHMuIFRoZXkgYWxyZWFk eSBrbm93IGFmdGVyIHRoZSBmaXJzdCBvZmZlci9hbndlciBjeWNsZSB0aGF0IHVzYWdlIG9mIGJ1 bmRsZSBpcyBzdWNjZXNzZnVsbHkgbmVnb3RpYXRlZCBhbmQgd2hpY2ggcG9ydCB0byB1c2UuDQpI b3dldmVyLCB0aGVyZSBpcyBhbHNvIGV4aXN0IHNpdHVhdGlvbnMgYW5kIGFub3RoZXIgdmFyaWV0 eSBvZiBtaWRkbGVib3hlcyBmb3Igd2hpY2ggdGhlIGZpeHVwIG9mZmVyL2Fuc3dlciBleGNoYW5n ZSBkb2VzIGhhcm0uIFNvbWUgb2YgdGhlIHJlbGF0ZWQgaXNzdWVzIGFyZSBkZXNjcmliZWQgaW4g ZHJhZnQtZWx3ZWxsLW1tdXNpYy1pY2UtdXBkYXRlZC1vZmZlciwgYnV0IHRoZXJlIGFyZSBtb3Jl LiBJIHRoaW5rIHRoYXQgaGF2aW5nIHRoZSBwb3NzaWJpbGl0eSB0byBhdm9pZCB0aGUgZml4dXAg b2ZmZXIvYW5zd2VyIGlzIGEgZ29vZCB0aGluZy4gU2luY2UgYm90aCBzY2VuYXJpb3MgbXV0dWFs bHkgZXhjbHVkZSB0aGVtc2VsdmVzLCB0aGlzIGJlaGF2aW9yIG5lZWRzIHRvIGJlIGNvbmZpZ3Vy YWJsZSwgZGVwZW5kZW50IG9uIHRoZSBuZXR3b3JrIGVudmlyb25tZW50Lg0KSW5kZXBlbmRlbnQg b2YgdGhlIGZpeHVwIGJlaW5nIHVzZWQgb3Igbm90LCAgYm90aCBjYXNlcyBjb3VsZCB1c2UgdGhl IHNhbWUgb2ZmZXIuIFdpdGggdGhhdCBhICBuZXcgSlNFUCBwb2xpY3kgaXMgbm90IG5lZWRlZCBh bmQgdGhpbmdzIGNvdWxkIGJlIGtlcHQgYmFja3dhcmRjb21wYXRpYmxlLiBJdCBtaWdodCBob3dl dmVyIGJlIGJlbmVmaWNpYWwsIHRvIHVzZSBhbiBleHBsaWNpdCBpbmRpY2F0b3IgaW4gdGhlIFNE UCB0aGF0IGZpeHVwIGlzIGRvbmUvbXVzdCBiZSBkb25lL211c3Qgbm90IGJlIGRvbmXigKYNClJl Z2FyZHMNClRob21hcw0KQlRXOiBBbHRob3VnaHQgdGhpcyBkaXNjdXNzaW9uIGlzIGFib3V0IGEg bmV3IHBvbGljeSBmb3IgSlNFUCwgdGhlIGRldGFpbHMgIGFyZSBkZWVwIGluIHRoZSBTRFAgdGVy cml0b3J5IG9mIE1NVVNJQy4gU2hvdWxkIGl0IGJlIG1vdmVkIHRoZXJlIG9yIE1NVXNJQyBtYWRl IGF3YXJlPw0KSG93ZXZlciwgYWZ0ZXIgdGhpbmtpbmcgYWJvdXQgaXQgYSBiaXQsIEkgZG9u4oCZ dCB0aGluayB0aGF0IHRoZXJlIGlzIGEgdmlhYmxlIHNvbHV0aW9uIHRoYXQgYXZvaWRzIFJUQ1Ag cG9ydCBnYXRoZXJpbmcgdGhhdCAqZG9lc27igJl0KiB1c2UgYSBzaW5nbGUgc2V0IG9mIHBvcnRz LiBUaGUgb25seSBvdGhlciBvcHRpb24gd291bGQgYmUgdG8gZG8gc29tZXRoaW5nIGxpa2UgdGhp czoNCm09YXVkaW8gMTAwMDANCmE9cnRjcDoxMDAwMCAjIHNhbWUgYXMgbT1hdWRpbyBwb3J0DQph PXJ0Y3AtbXV4DQptPXZpZGVvIDANCmE9YnVuZGxlLW9ubHkNCmE9cnRjcC1tdXgNCmJ1dCB0aGlz IHdpbGwgYWxtb3N0IHN1cmVseSB3aWxsIHJlc3VsdCBpbiBhIG1hbGZ1bmN0aW9uIHdoZW4gdGFs a2luZyB0byBhIG5vbi1ydGNwLW11eCBjbGllbnQsIGR1ZSB0byB0aGUgc2FtZSBwb3J0IGJlaW5n IHVzZWQgZm9yIFJUUCBhbmQgUlRDUCwgYW5kIHN0aWxsIHJlcXVpcmVzIHRoZSBmaXh1cCBvZmZl ciwgYW5kIGFzIHN1Y2ggaXMgbmV0IHdvcnNlIHRoYW4gdGhlIGZvcmNlLWJ1bmRsZSBhcHByb2Fj aCBpbmRpY2F0ZWQgYWJvdmUuDQpTbyBJIHRoaW5rIHdlIHRoZSBmb3JjZS1idW5kbGUgYXBwcm9h Y2ggaXMgdGhlIG9uZSB3ZSB3YW50IHRvIG1pbmltaXplIHBvcnQgZ2F0aGVyaW5nLiBUaGUgb25s eSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHNob3VsZCBrZWVwIG1heC1idW5kbGUgYXMgd2VsbC4g VG8gYmUgc3BlY2lmaWMsIHdlIG5lZWQgdG8gZGVjaWRlIGJldHdlZW46DQphKSBLZWVwIG1heC1i dW5kbGUgYXMgaXQgaXMgKHNlcGFyYXRlIFJUUCBhbmQgUlRDUCBwb3J0cyBhbGxvY2F0ZWQpLCBh bmQgYWRkIGEgbmV3IGZvcmNlLWJ1bmRsZSBwb2xpY3kgdGhhdCBjcmVhdGVzIGFuIG9mZmVyIHdp dGggYSBzaW5nbGUgcG9ydCBzaGFyZWQgYmV0d2VlbiBhbGwgbS1zZWN0aW9ucyAoUlRQIGFuZCBS VENQKS4gbWF4LWJ1bmRsZSByZW1haW5zIG5vbWluYWxseSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3 aXRoIG5vbi1CVU5ETEUvbm9uLXJ0Y3AtbXV4IGVuZHBvaW50cywgaW4gdGhhdCBpdCB3aWxsIHN0 aWxsIHNlbmQgYSBzaW5nbGUgYXVkaW8gc3RyZWFtLiBmb3JjZS1idW5kbGUgaXMgbm90IGJhY2t3 YXJkcyBjb21wYXRpYmxlIHdpdGggbm9uLUJVTkRMRSBlbmRwb2ludHMuDQpiKSBBZGQgZm9yY2Ut YnVuZGxlLCBidXQgZ2V0IHJpZCBvZiBtYXgtYnVuZGxlLg0K --_000_F81CEE99482EFE438DAE2A652361EE1217A60F57MCHP04MSXglobal_ 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 OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvbWUgdGhvdWdodHMvcHJvcG9zYWwgYWJvdXQgdGhlIGZpeHVw IGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG15IEpTRVAgcHJlc28gZHVyaW5nIHRoZSBSVENX RUIgc2Vzc2lvbiBsYXN0IFdlZG5lc2RheSwgSSBkaXNjdXNzZWQgYWRkaW5nIGEgbmV3IEJVTkRM RSBwb2xpY3kgdG8gSlNFUC4gVGhpcyBwb2xpY3ksIHdoaWNoIHdvdWxkIGJlIGNhbGxlZCBzb21l dGhpbmcgbGlrZSDigJxmb3JjZS1idW5kbGXigJ0sIHdvdWxkDQogZm9yY2UgdGhlIHVzZSBvZiB0 aGUgc2FtZSBwb3J0cyBmb3IgQlVORExFZCBtLXNlY3Rpb25zLCBhcyB3ZWxsIGFzIFJUQ1AgbXV4 LiBXaGVuIG9uZSBrbm93cyBhIHByaW9yaSB0aGF0IHRoZSBvdGhlciBzaWRlIHN1cHBvcnRzIEJV TkRMRSwgdGhpcyB3b3VsZCByZWR1Y2UgY2FuZGlkYXRlIGdhdGhlcmluZyBldmVuIG92ZXIgdGhl IGN1cnJlbnRseSBkZWZpbmVkIOKAnG1heC1idW5kbGXigJ0gcG9saWN5LCBzaW5jZSB0aGVyZSB3 b3VsZCBiZSBubyBuZWVkDQogdG8gZ2F0aGVyIFJUQ1AgcG9ydHMgYXQgYWxsLCBhbmQgYWxzbyBh dm9pZCB0aGUgbmVlZCBmb3IgdGhlIEJVTkRMRSBmaXh1cCBvZmZlciAod2hlcmUgdGhlIHBvcnRz IGFyZSB1cGRhdGVkIHRvIGJlIHRoZSBzYW1lIGZvciBhbGwgQlVORExFZCBtLXNlY3Rpb25zKS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gZXhwbGFpbiB0aGUgZGlm ZmVyZW5jZXMgaGVyZSwgaGVyZSBhcmUgc29tZSBleGFtcGxlIG9mZmVycyBmb3IgYW4gYXVkaW8m IzQzO3ZpZGVvIGNhbGw6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRl ZmF1bHQgYnVuZGxlIHBvbGljeSAtIHNlcGFyYXRlIHBvcnRzIGZvciBhdWRpbywgdmlkZW8sIFJU UCBhbmQgUlRDUDo8YnI+DQptPWF1ZGlvIDEwMDAwPGJyPg0KYT1ydGNwOjEwMDAxPGJyPg0KYT1y dGNwLW11eDxicj4NCm09dmlkZW8gMTEwMDA8YnI+DQphPXJ0Y3A6MTEwMDE8YnI+DQphPXJ0Y3At bXV4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4aXN0aW5nICZxdW90 O21heC1idW5kbGUmcXVvdDsgcG9saWN5IC0gdmlkZW8gcG9ydCBpcyAwIGJlY2F1c2UgYnVuZGxl LW9ubHksIGJ1dCBib3RoIFJUUCBhbmQgUlRDUCBwb3J0cyBhbGxvY2F0ZWQgZm9yIGF1ZGlvOjxi cj4NCm09YXVkaW8gMTAwMDA8YnI+DQphPXJ0Y3A6MTAwMDE8YnI+DQphPXJ0Y3AtbXV4PGJyPg0K bT12aWRlbyAwPGJyPg0KYT1idW5kbGUtb25seTxicj4NCmE9cnRjcC1tdXg8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG5ldyDigJxmb3JjZS1idW5kbGXigJ0gcG9s aWN5IC0gb25seSBhIHNpbmdsZSBzZXQgb2YgcG9ydHMgYWxsb2NhdGVkIC0gYXVkaW8sIHZpZGVv LCBSVFAsIFJUQ1Agc2hhcmUgdGhlIHNhbWUgcG9ydC48YnI+DQptPWF1ZGlvIDEwMDAwPGJyPg0K YT1ydGNwOjEwMDAwPGJyPg0KYT1ydGNwLW11eDxicj4NCm09dmlkZW8gMTAwMDA8YnI+DQphPXJ0 Y3A6MTAwMDA8YnI+DQphPXJ0Y3AtbXV4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkR1cmluZyB0aGUgZGlzY3Vzc2lvbiwgdGhlIGFiaWxpdHkgdG8gYXZvaWQgUlRDUCBw b3J0IGdhdGhlcmluZyB3YXMgc2VlbiBhcyB2YWx1YWJsZSwgYnV0IG5vdCB0aGUgYWJpbGl0eSB0 byBhdm9pZCB0aGUgZml4dXAgb2ZmZXIuDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RTXSBUaGUgZml4dXAgaXMgb25s eSBpbnRyb2R1Y2VkIHRvIGFjY29tbW9kYXRlIGEgY2VydGFpbiB2YXJpZXR5IG9mIG1pZGRsZWJv eGVzIHRoYXQgd2FudA0KIHRvIHNlZSB0aGUgdXNlZCBwb3J0cyBhbHNvICZuYnNwO2luIHRoZSBT RFAgb2ZmZXIvYW5zd2VyLiBUaGUgZml4dXAgb2ZmZXIgaXMgbm90IHRlY2huaWNhbGx5IG5lY2Vz c2FyeSBmb3IgdGhlIHR3byBidW5kbGUgY2xpZW50cy4gVGhleSBhbHJlYWR5IGtub3cgYWZ0ZXIg dGhlIGZpcnN0IG9mZmVyL2Fud2VyIGN5Y2xlIHRoYXQgdXNhZ2Ugb2YgYnVuZGxlIGlzIHN1Y2Nl c3NmdWxseSBuZWdvdGlhdGVkIGFuZCB3aGljaCBwb3J0IHRvIHVzZS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgdGhlcmUgaXMgYWxzbyBl eGlzdCBzaXR1YXRpb25zIGFuZCBhbm90aGVyIHZhcmlldHkgb2YgbWlkZGxlYm94ZXMgZm9yIHdo aWNoIHRoZSBmaXh1cA0KIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBkb2VzIGhhcm0uIFNvbWUgb2Yg dGhlIHJlbGF0ZWQgaXNzdWVzIGFyZSBkZXNjcmliZWQgaW4gZHJhZnQtZWx3ZWxsLW1tdXNpYy1p Y2UtdXBkYXRlZC1vZmZlciwgYnV0IHRoZXJlIGFyZSBtb3JlLiBJIHRoaW5rIHRoYXQgaGF2aW5n IHRoZSBwb3NzaWJpbGl0eSB0byBhdm9pZCB0aGUgZml4dXAgb2ZmZXIvYW5zd2VyIGlzIGEgZ29v ZCB0aGluZy4gU2luY2UgYm90aCBzY2VuYXJpb3MgbXV0dWFsbHkgZXhjbHVkZQ0KIHRoZW1zZWx2 ZXMsIHRoaXMgYmVoYXZpb3IgbmVlZHMgdG8gYmUgY29uZmlndXJhYmxlLCBkZXBlbmRlbnQgb24g dGhlIG5ldHdvcmsgZW52aXJvbm1lbnQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JbmRlcGVuZGVudCBvZiB0aGUgZml4dXAgYmVpbmcgdXNlZCBvciBub3Qs ICZuYnNwO2JvdGggY2FzZXMgY291bGQgdXNlIHRoZSBzYW1lIG9mZmVyLiBXaXRoIHRoYXQNCiBh ICZuYnNwO25ldyBKU0VQIHBvbGljeSBpcyBub3QgbmVlZGVkIGFuZCB0aGluZ3MgY291bGQgYmUg a2VwdCBiYWNrd2FyZGNvbXBhdGlibGUuIEl0IG1pZ2h0IGhvd2V2ZXIgYmUgYmVuZWZpY2lhbCwg dG8gdXNlIGFuIGV4cGxpY2l0IGluZGljYXRvciBpbiB0aGUgU0RQIHRoYXQgZml4dXAgaXMgZG9u ZS9tdXN0IGJlIGRvbmUvbXVzdCBub3QgYmUgZG9uZeKApjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxicj4NClRob21hcyA8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJUVzogQWx0aG91Z2h0IHRoaXMgZGlz Y3Vzc2lvbiBpcyBhYm91dCBhIG5ldyBwb2xpY3kgZm9yIEpTRVAsIHRoZSBkZXRhaWxzICZuYnNw O2FyZSBkZWVwIGluIHRoZQ0KIFNEUCB0ZXJyaXRvcnkgb2YgTU1VU0lDLiBTaG91bGQgaXQgYmUg bW92ZWQgdGhlcmUgb3IgTU1Vc0lDIG1hZGUgYXdhcmU/IDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVyLCBhZnRlciB0aGlua2luZyBh Ym91dCBpdCBhIGJpdCwgSSBkb27igJl0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSB2aWFibGUgc29s dXRpb24gdGhhdCBhdm9pZHMgUlRDUCBwb3J0IGdhdGhlcmluZyB0aGF0ICpkb2VzbuKAmXQqIHVz ZSBhIHNpbmdsZSBzZXQgb2YgcG9ydHMuIFRoZSBvbmx5IG90aGVyIG9wdGlvbg0KIHdvdWxkIGJl IHRvIGRvIHNvbWV0aGluZyBsaWtlIHRoaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPm09YXVkaW8gMTAwMDA8YnI+DQphPXJ0Y3A6MTAwMDAgIyBzYW1lIGFzIG09YXVk aW8gcG9ydDxicj4NCmE9cnRjcC1tdXg8YnI+DQptPXZpZGVvIDA8YnI+DQphPWJ1bmRsZS1vbmx5 PGJyPg0KYT1ydGNwLW11eDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5i dXQgdGhpcyB3aWxsIGFsbW9zdCBzdXJlbHkgd2lsbCByZXN1bHQgaW4gYSBtYWxmdW5jdGlvbiB3 aGVuIHRhbGtpbmcgdG8gYSBub24tcnRjcC1tdXggY2xpZW50LCBkdWUgdG8gdGhlIHNhbWUgcG9y dCBiZWluZyB1c2VkIGZvciBSVFAgYW5kIFJUQ1AsIGFuZCBzdGlsbCByZXF1aXJlcyB0aGUgZml4 dXAgb2ZmZXIsDQogYW5kIGFzIHN1Y2ggaXMgbmV0IHdvcnNlIHRoYW4gdGhlIGZvcmNlLWJ1bmRs ZSBhcHByb2FjaCBpbmRpY2F0ZWQgYWJvdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlNvIEkgdGhpbmsgd2UgdGhlIGZvcmNlLWJ1bmRsZSBhcHByb2FjaCBpcyB0aGUg b25lIHdlIHdhbnQgdG8gbWluaW1pemUgcG9ydCBnYXRoZXJpbmcuIFRoZSBvbmx5IHF1ZXN0aW9u IGlzIHdoZXRoZXIgd2Ugc2hvdWxkIGtlZXAgbWF4LWJ1bmRsZSBhcyB3ZWxsLiBUbyBiZSBzcGVj aWZpYywgd2UgbmVlZCB0bw0KIGRlY2lkZSBiZXR3ZWVuOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5hKSBLZWVwIG1heC1idW5kbGUgYXMgaXQgaXMgKHNlcGFyYXRlIFJU UCBhbmQgUlRDUCBwb3J0cyBhbGxvY2F0ZWQpLCBhbmQgYWRkIGEgbmV3IGZvcmNlLWJ1bmRsZSBw b2xpY3kgdGhhdCBjcmVhdGVzIGFuIG9mZmVyIHdpdGggYSBzaW5nbGUgcG9ydCBzaGFyZWQgYmV0 d2VlbiBhbGwgbS1zZWN0aW9ucyAoUlRQDQogYW5kIFJUQ1ApLiBtYXgtYnVuZGxlIHJlbWFpbnMg bm9taW5hbGx5IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggbm9uLUJVTkRMRS9ub24tcnRjcC1t dXggZW5kcG9pbnRzLCBpbiB0aGF0IGl0IHdpbGwgc3RpbGwgc2VuZCBhIHNpbmdsZSBhdWRpbyBz dHJlYW0uIGZvcmNlLWJ1bmRsZSBpcyBub3QgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBub24t QlVORExFIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ YikgQWRkIGZvcmNlLWJ1bmRsZSwgYnV0IGdldCByaWQgb2YgbWF4LWJ1bmRsZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F81CEE99482EFE438DAE2A652361EE1217A60F57MCHP04MSXglobal_-- From nobody Tue Mar 11 00:51:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159BD1A02A0 for ; Tue, 11 Mar 2014 00:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=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 OoGENDYw2RUD for ; Tue, 11 Mar 2014 00:51:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 354E41A0139 for ; Tue, 11 Mar 2014 00:51:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-27-531ec0668f9d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CB.07.10875.660CE135; Tue, 11 Mar 2014 08:51:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Tue, 11 Mar 2014 08:51:01 +0100 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggAFFHoCAAERkzg== Date: Tue, 11 Mar 2014 07:51:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2009B4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2009B4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvjW7aAblgg39bDS027PvPbLHi9Tl2 i61ThSzW/mtnd2Dx2DnrLrvHgk2lHkuW/GTymPy4jTmAJYrLJiU1J7MstUjfLoEro/HPWbaC 87kVy1pPsjUw7orrYuTkkBAwkVi47wIbhC0mceHeeiCbi0NI4BCjxKRZN5khnCWMEq+3rQBy ODjYBCwkuv9pgzSICGhL9H3bxwRiMwtkS1x6toQVxBYWMJaY0jmZDaLGRGLuxNcsELaTxNrV C5hBbBYBVYn2NbfAbF4BX4k/x9awQOy6yShxet1qdpAEp0CgxLt/6xlBbEag676fWgO1TFzi 1pP5TBBXC0gs2XOeGcIWlXj5+B8rhK0osfNsO9jNzAL5Ek+6eCB2CUqcnPmEZQKj6Cwkk2Yh VM1CUgVRYiDx/tx8ZghbW2LZwtdQtr7Exi9nGZHFFzCyr2Jkz03MzEkvN9zECIy6g1t+6+5g PHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYC9lNxY9mrVzikv2o 1kyl0Dzn1bHX5zXSzOR3O0wMvrz33txfas2vZBmv7d4wa2qylTTPVzndSSeaHsSLH3t9+J7C 56nXy5gtN72aHZRUV72udzfXrBeHC0QE6gr4DxyyD4k/2DIxtqZDu776zkIpvrA/Mlzngtgu qmYkagYuEH11cP8Vlx8xSizFGYmGWsxFxYkAGfm/O4gCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9lWyG3vgJc17upoVr5ChC3rScDM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 11 Mar 2014 07:51:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2009B4ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, "BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp attr= ibutes. I remember we had discussions about that, but I don=92t remember th= e justification at the moment." [BA] The justification was that an implementation interested in multiplexin= g A/V would almost certainly also want to multiplex RTP and RTCP, because t= he motivation for both is minimizing port usage. [Christer] So, again, the idea is to use a=3Drtcp to indicate the *same* po= rt as a=3Drtcp-mux indicates, and hope that the receiver supports at least = either a=3Drtcp or a=3Drtcp-mux? Regards, Christer On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg > wrote: Hi, Before I comment on your proposal, let=92s take a few steps back (maybe it = can even solve your issue). BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp attri= butes. I remember we had discussions about that, but I don=92t remember the= justification at the moment. But, I wonder whether that text is from befor= e we made a decision that, unless both endpoints support BUNDLE, no endpoin= t will use a single address:port. So, the question is: do we really need the SDP rtcp attribute? Regards, Christer From: Justin Uberti [mailto:juberti@google.com] Sent: 10. maaliskuuta 2014 8:18 To: rtcweb@ietf.org; Eric Rescorla; Christer Holmbe= rg Subject: BUNDLE with implicit rtcp-mux In my JSEP preso during the RTCWEB session last Wednesday, I discussed addi= ng a new BUNDLE policy to JSEP. This policy, which would be called somethin= g like =93force-bundle=94, would force the use of the same ports for BUNDLE= d m-sections, as well as RTCP mux. When one knows a priori that the other s= ide supports BUNDLE, this would reduce candidate gathering even over the cu= rrently defined =93max-bundle=94 policy, since there would be no need to ga= ther RTCP ports at all, and also avoid the need for the BUNDLE fixup offer = (where the ports are updated to be the same for all BUNDLEd m-sections). To explain the differences here, here are some example offers for an audio+= video call: Default bundle policy - separate ports for audio, video, RTP and RTCP: m=3Daudio 10000 a=3Drtcp:10001 a=3Drtcp-mux m=3Dvideo 11000 a=3Drtcp:11001 a=3Drtcp-mux Existing "max-bundle" policy - video port is 0 because bundle-only, but bot= h RTP and RTCP ports allocated for audio: m=3Daudio 10000 a=3Drtcp:10001 a=3Drtcp-mux m=3Dvideo 0 a=3Dbundle-only a=3Drtcp-mux The new =93force-bundle=94 policy - only a single set of ports allocated - = audio, video, RTP, RTCP share the same port. m=3Daudio 10000 a=3Drtcp:10000 a=3Drtcp-mux m=3Dvideo 10000 a=3Drtcp:10000 a=3Drtcp-mux During the discussion, the ability to avoid RTCP port gathering was seen as= valuable, but not the ability to avoid the fixup offer. However, after thi= nking about it a bit, I don=92t think that there is a viable solution that = avoids RTCP port gathering that *doesn=92t* use a single set of ports. The = only other option would be to do something like this: m=3Daudio 10000 a=3Drtcp:10000 # same as m=3Daudio port a=3Drtcp-mux m=3Dvideo 0 a=3Dbundle-only a=3Drtcp-mux but this will almost surely will result in a malfunction when talking to a = non-rtcp-mux client, due to the same port being used for RTP and RTCP, and = still requires the fixup offer, and as such is net worse than the force-bun= dle approach indicated above. So I think we the force-bundle approach is the one we want to minimize port= gathering. The only question is whether we should keep max-bundle as well.= To be specific, we need to decide between: a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and ad= d a new force-bundle policy that creates an offer with a single port shared= between all m-sections (RTP and RTCP). max-bundle remains nominally backwa= rds compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it will stil= l send a single audio stream. force-bundle is not backwards compatible with= non-BUNDLE endpoints. b) Add force-bundle, but get rid of max-bundle. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1D2009B4ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

"BUNDLE currently mandates the usage of both the SDP rt= cp-mux and rtcp attributes. I remember we had discussions about that, but I= don=92t remember the justification at the moment."

[BA] The justification was that an implementation interested in multip= lexing A/V would almost certainly also want to multiplex RTP and RTCP, beca= use the motivation for both is minimizing port usage. 

[Christer] So, again, the idea is to use a=3Drtcp to indicate the *same* po= rt as a=3Drtcp-mux indicates, and hope that the receiver supports at least = either a=3Drtcp or a=3Drtcp-mux?

Regards,

Christer


On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

Before I comment on you= r proposal, let=92s take a few steps back (maybe it can even solve your iss= ue).

 

BUNDLE currently mandat= es the usage of both the SDP rtcp-mux and rtcp attributes. I remember we ha= d discussions about that, but I don=92t remember the justification at the moment. But, I wonder whether that text is from before we made a de= cision that, unless both endpoints support BUNDLE, no endpoint will use a s= ingle address:port.

 

So, the question is: do= we really need the SDP rtcp attribute?

 

Regards,<= /span>

 

Christer<= /span>

 

 

 

 

 

From: Justin= Uberti [mailto:jub= erti@google.com]
Sent: 10. maaliskuuta 2014 8:18
To: rtcweb@ietf= .org; Eric Rescorla; Christer Holmberg
Subject: BUNDLE with implicit rtcp-mux

 

In my JSEP preso during the RTCWEB session last Wedn= esday, I discussed adding a new BUNDLE policy to JSEP. This policy, which w= ould be called something like =93force-bundle=94, would force the use of th= e same ports for BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the other side supports BUN= DLE, this would reduce candidate gathering even over the currently defined = =93max-bundle=94 policy, since there would be no need to gather RTCP ports = at all, and also avoid the need for the BUNDLE fixup offer (where the ports are updated to be the same for all= BUNDLEd m-sections).

To explain the differences here, here are some examp= le offers for an audio+video call:

Default bundle policy - separate ports for audio, vi= deo, RTP and RTCP:
m=3Daudio 10000
a=3Drtcp:10001
a=3Drtcp-mux
m=3Dvideo 11000
a=3Drtcp:11001
a=3Drtcp-mux

Existing "max-bundle" policy - video port = is 0 because bundle-only, but both RTP and RTCP ports allocated for audio:<= br> m=3Daudio 10000
a=3Drtcp:10001
a=3Drtcp-mux
m=3Dvideo 0
a=3Dbundle-only
a=3Drtcp-mux

The new =93force-bundle=94 policy - only a single se= t of ports allocated - audio, video, RTP, RTCP share the same port.
m=3Daudio 10000
a=3Drtcp:10000
a=3Drtcp-mux
m=3Dvideo 10000
a=3Drtcp:10000
a=3Drtcp-mux

During the discussion, the ability to avoid RTCP por= t gathering was seen as valuable, but not the ability to avoid the fixup of= fer. However, after thinking about it a bit, I don=92t think that there is = a viable solution that avoids RTCP port gathering that *doesn=92t* use a single set of ports. The only other optio= n would be to do something like this:

m=3Daudio 10000
a=3Drtcp:10000 # same as m=3Daudio port
a=3Drtcp-mux
m=3Dvideo 0
a=3Dbundle-only
a=3Drtcp-mux

but this will almost surely will result in a malfunc= tion when talking to a non-rtcp-mux client, due to the same port being used= for RTP and RTCP, and still requires the fixup offer, and as such is net w= orse than the force-bundle approach indicated above.

So I think we the force-bundle approach is the one w= e want to minimize port gathering. The only question is whether we should k= eep max-bundle as well. To be specific, we need to decide between:

a) Keep max-bundle as it is (separate RTP and RTCP p= orts allocated), and add a new force-bundle policy that creates an offer wi= th a single port shared between all m-sections (RTP and RTCP). max-bundle r= emains nominally backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it will still send a singl= e audio stream. force-bundle is not backwards compatible with non-BUNDLE en= dpoints.

b) Add force-bundle, but get rid of max-bundle.


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


--_000_7594FB04B1934943A5C02806D1A2204B1D2009B4ESESSMB209erics_-- From nobody Tue Mar 11 07:02:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3E1A045C for ; Tue, 11 Mar 2014 07:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 AhHomlgZvQ3P for ; Tue, 11 Mar 2014 07:02:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDEC1A0423 for ; Tue, 11 Mar 2014 07:02:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d5d1:ac74:fa48:a37a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 46C0C403F8 for ; Tue, 11 Mar 2014 10:02:21 -0400 (EDT) Message-ID: <531F176C.2070305@viagenie.ca> Date: Tue, 11 Mar 2014 10:02:20 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> In-Reply-To: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1isr4_CBHdblWG_5Jj96trxIvNM Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 11 Mar 2014 14:02:29 -0000 Le 2014-03-10 16:57, James Polk a écrit : > At 12:16 AM 3/10/2014, Justin Uberti wrote: >> I think that the existing guidance should be sufficient in >> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the >> same DSCP markings as any other ICE connectivity checks should be >> used; for ICE-for-SCTP checks, the same DSCP markings as media packets >> (i.e. the SCTP traffic) should be used. >> >> If multiplexing is being performed, the connectivity checks probably >> should use the highest DSCP value being used by the multiplexed media. > > why is (seemingly) everyone's default position "use the highest DSCP > available" for signaling packets? > > You just need to make sure the packets aren't starved or dropped by/at > congestion points. The underlying principle is that connectivity checks need to *check connectivity* (duh!). That's why you use the same DSCP as the media. Connectivity is affected by the DSCP. For example some DSCPs could be filtered, or could be placed in a low-priority queue and get dropped such that connectivity fails. >From this principle follows this conclusion: on a given 5-tuple, if your media uses different DSCPs, you need to check connectivity for all those DSCPs. That is, you would send multiple connectivity checks, one for each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might need an alternative heuristic: try the lowest-priority DSCP, and assume that if that one works, the higher-priority ones should work as well. (Note that Justin suggested the contrary.) What you want to avoid is STUN packets getting through but not the corresponding media. That is an unworkable situation. The reverse is not ideal either (you think you have no connectivity when in fact you do), but at least ICE can work around it (by picking a different candidate). Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 11 07:41:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229C61A0735 for ; Tue, 11 Mar 2014 07:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LpAx7hmWq7w for ; Tue, 11 Mar 2014 07:41:47 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1341A044B for ; Tue, 11 Mar 2014 07:41:47 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so10237707wes.15 for ; Tue, 11 Mar 2014 07:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z6AebkgOSZPo0P3Irz1M/95fZ/er4869y0dbRKovcrI=; b=S01LIrcyuYOXv2PQyqepazIaCW2jY6ZWzi+b90lL+Be9aSHhTWOK8QKa9vZPyUprSx wjLGJ1h4ouwtV/cnMw2rVl3Qw8bJw8suEoNIRLIVpAqWFk6kzF+Us5APNG6CqJEBAQ7F 5D7im1wBt2MPzkZdKpZU92TM9lxJ3jZ7GvUHaLxRhywtQULqx/WCnNnO2VwiWAXeqHBg vbSbX1NLdWI87kpxYELY1BC4oT0f7/WQtZlcBppHRHr2WMXcHtpUI9gbLaaPNicicP5e 3TwFk7B/6XWc0KrSIrANvvEQPO+dH9acB9L5u6ZTVWYWO7ehlE9KKlppFyrMGRcJFdPG sdWg== X-Received: by 10.181.11.169 with SMTP id ej9mr3458444wid.18.1394548901097; Tue, 11 Mar 2014 07:41:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.161.66 with HTTP; Tue, 11 Mar 2014 07:41:21 -0700 (PDT) In-Reply-To: <531DDB5A.4060201@ericsson.com> References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> From: Bernard Aboba Date: Tue, 11 Mar 2014 07:41:21 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d043be1fcdf377204f455b704 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0Ir_08S8Hdrd-blFB8_OObqJK2w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 11 Mar 2014 14:41:50 -0000 --f46d043be1fcdf377204f455b704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus said: "I would guess that the simplest is to remove discussion of TURN TCP altogether from Transports. That would not recommend it nor make it disallowed. If we want to be explicit, then simply motivate why we don't believe it necessary." [BA] Removing a recommendation from the Transport document is OK with me. However, since we've had quite a bit of discussion on this topic, it would be good to state why we don't believe it to be necessary (so as to avoid rehashing this down the line). On Mon, Mar 10, 2014 at 8:33 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-06 14:34, Simon Perreault wrote: > > Le 2014-03-06 13:23, Justin Uberti a =E9crit : > >> can we agree that TURN TCP candidates are a SHOULD NOT? > > > > Not a SHOULD, sure. SHOULD NOT, no. > > > > I would guess that the simplest is to remove discussion of TURN TCP > altogether from Transports. That would not recommend it nor make it > disallowed. If we want to be explicit, then simply motivate why we don't > believe it necessary. > > Justin, what is the reason you wanted SHOULD NOT? > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 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 > --f46d043be1fcdf377204f455b704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Magnus said:

"I would = guess that the simplest is to remove discussion of TURN TCP
altogether = from Transports. That would not recommend it nor make it
disallowed. If= we want to be explicit, then simply motivate why we don't
believe it necessary."

[BA] Removing a recom= mendation from the Transport document=A0is OK with=A0 me.=A0 However, since= we've had quite a bit of discussion on this topic, it would be good to= state why we don't believe it to be necessary (so as to avoid rehashin= g this down the line).


On Mon,= Mar 10, 2014 at 8:33 AM, Magnus Westerlund <magnus.westerl= und@ericsson.com> wrote:
On 2014-03-06 14:34, Simon Perreault wrote:<= br> > Le 2014-03-06 13:23, Justin Uberti a =E9crit :
>> can we agree that TURN TCP candidates are a SHOULD NOT?
>
> Not a SHOULD, sure. SHOULD NOT, no.
>

I would guess that the simplest is to remove discussion of TURN TCP
altogether from Transports. That would not recommend it nor make it
disallowed. If we want to be explicit, then simply motivate why we don'= t
believe it necessary.

Justin, what is the reason you wanted SHOULD NOT?

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =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

--f46d043be1fcdf377204f455b704-- From nobody Tue Mar 11 07:44:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F3D1A073B for ; Tue, 11 Mar 2014 07:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk2YLKdYPQ1Y for ; Tue, 11 Mar 2014 07:44:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 56EBA1A0736 for ; Tue, 11 Mar 2014 07:44:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 038A07C4F20 for ; Tue, 11 Mar 2014 15:43:55 +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 6SNEKZbXW+OF for ; Tue, 11 Mar 2014 15:43:54 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 32CCB7C4F14 for ; Tue, 11 Mar 2014 15:43:54 +0100 (CET) Message-ID: <531F212A.4040102@alvestrand.no> Date: Tue, 11 Mar 2014 15:43:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> In-Reply-To: <531F176C.2070305@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ff5vuEuX5TjsYe9IZ9jdCnOWqGM Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 11 Mar 2014 14:44:04 -0000 On 03/11/2014 03:02 PM, Simon Perreault wrote: > Le 2014-03-10 16:57, James Polk a écrit : >> At 12:16 AM 3/10/2014, Justin Uberti wrote: >>> I think that the existing guidance should be sufficient in >>> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the >>> same DSCP markings as any other ICE connectivity checks should be >>> used; for ICE-for-SCTP checks, the same DSCP markings as media packets >>> (i.e. the SCTP traffic) should be used. >>> >>> If multiplexing is being performed, the connectivity checks probably >>> should use the highest DSCP value being used by the multiplexed media. >> why is (seemingly) everyone's default position "use the highest DSCP >> available" for signaling packets? >> >> You just need to make sure the packets aren't starved or dropped by/at >> congestion points. > The underlying principle is that connectivity checks need to *check > connectivity* (duh!). That's why you use the same DSCP as the media. > Connectivity is affected by the DSCP. For example some DSCPs could be > filtered, or could be placed in a low-priority queue and get dropped > such that connectivity fails. > > >From this principle follows this conclusion: on a given 5-tuple, if your > media uses different DSCPs, you need to check connectivity for all those > DSCPs. That is, you would send multiple connectivity checks, one for > each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might > need an alternative heuristic: try the lowest-priority DSCP, and assume > that if that one works, the higher-priority ones should work as well. > (Note that Justin suggested the contrary.) > > What you want to avoid is STUN packets getting through but not the > corresponding media. That is an unworkable situation. The reverse is not > ideal either (you think you have no connectivity when in fact you do), > but at least ICE can work around it (by picking a different candidate). This explanation makes sense for (ICE) connectivity checks. For other control information, especially information about delay, you want to have it delivered as fast as possible, and with as little loss as possible, because jitter in the return path will make the delay signal more noisy, and lost packets may cause drastic actions like those the circuit-breakers draft recommends. Whether that always translates to "the highest DSCP code point" is .... a good question. From nobody Tue Mar 11 10:18:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357E91A074F for ; Tue, 11 Mar 2014 10:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlSqLYbeuqQ8 for ; Tue, 11 Mar 2014 10:17:58 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 65F271A0768 for ; Tue, 11 Mar 2014 10:17:58 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so10357049wes.32 for ; Tue, 11 Mar 2014 10:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=01uRt8zmKHPVHi6dNZ568An4HXli/j6noIjkKYfYnE0=; b=yLOFfBZjID2SjKXpWAdhBoXCOkDEyG8fsnkQC5xHOIAr37AJ4OiCPQJfi9Gk/wNSYx hEvWs0nOLN/LN8WQAOFcC2NAUEegjdRCJQe9AXXHhGH2DcyQpWVTKW6Z+ED61M+e1/5W PkGluQdXEz1oBmMlvtiTy4plLweIf7im9cDuRywk4QaKvJFZc7WqZZ+GAoU2ezgWFVHG pHXl0kSRUD6FGEPhaTY7aL2lPgsBohbR+C5zU9WaXwkL/EpduID78LxPO+IBEl0RorNC pJI657VbZW60OyD5LIcCfqbeQMy9GgrIT952E7hx9L7QIRpl3LHebOl8gp8Rn5NNiKM9 Lq6w== MIME-Version: 1.0 X-Received: by 10.180.188.169 with SMTP id gb9mr3980862wic.17.1394558272077; Tue, 11 Mar 2014 10:17:52 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Tue, 11 Mar 2014 10:17:51 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Tue, 11 Mar 2014 10:17:51 -0700 (PDT) In-Reply-To: <531F212A.4040102@alvestrand.no> References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <531F212A.4040102@alvestrand.no> Date: Tue, 11 Mar 2014 17:17:51 +0000 Message-ID: From: Dave Taht To: Harald Tveit Alvestrand Content-Type: multipart/alternative; boundary=001a11c26bb86d04a004f457e631 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Hjqs_UkJOaXCFabsxncFpsNARN8 Cc: Keith Winstein , rtcweb@ietf.org Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 11 Mar 2014 17:18:01 -0000 --001a11c26bb86d04a004f457e631 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mar 11, 2014 7:44 AM, "Harald Alvestrand" wrote: > > On 03/11/2014 03:02 PM, Simon Perreault wrote: >> >> Le 2014-03-10 16:57, James Polk a =E9crit : >>> >>> At 12:16 AM 3/10/2014, Justin Uberti wrote: >>>> >>>> I think that the existing guidance should be sufficient in >>>> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the >>>> same DSCP markings as any other ICE connectivity checks should be >>>> used; for ICE-for-SCTP checks, the same DSCP markings as media packets >>>> (i.e. the SCTP traffic) should be used. >>>> >>>> If multiplexing is being performed, the connectivity checks probably >>>> should use the highest DSCP value being used by the multiplexed media. >>> >>> why is (seemingly) everyone's default position "use the highest DSCP >>> available" for signaling packets? >>> >>> You just need to make sure the packets aren't starved or dropped by/at >>> congestion points. >> >> The underlying principle is that connectivity checks need to *check >> connectivity* (duh!). That's why you use the same DSCP as the media. >> Connectivity is affected by the DSCP. For example some DSCPs could be >> filtered, or could be placed in a low-priority queue and get dropped >> such that connectivity fails. >> >> >From this principle follows this conclusion: on a given 5-tuple, if you= r >> media uses different DSCPs, you need to check connectivity for all those >> DSCPs. That is, you would send multiple connectivity checks, one for >> each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might >> need an alternative heuristic: try the lowest-priority DSCP, and assume >> that if that one works, the higher-priority ones should work as well. >> (Note that Justin suggested the contrary.) >> >> What you want to avoid is STUN packets getting through but not the >> corresponding media. That is an unworkable situation. The reverse is not >> ideal either (you think you have no connectivity when in fact you do), >> but at least ICE can work around it (by picking a different candidate). > > > This explanation makes sense for (ICE) connectivity checks. > > For other control information, especially information about delay, you want to have it delivered as fast as possible, and with as little loss as possible, because jitter in the return path will make the delay signal more noisy, and lost packets may cause drastic actions like those the circuit-breakers draft recommends. > > Whether that always translates to "the highest DSCP code point" is .... a good question. It doesn't. Keith added af42 support to mosh last year and had several reports of packets being dropped with that marking. Worse the drops happened after 10 seconds of connectivity. Ecn markings on the other hand have thus far survived (if occasionally stomped on) across the open internet in that protocol. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --001a11c26bb86d04a004f457e631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 11, 2014 7:44 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:
>
> On 03/11/2014 03:02 PM, Simon Perreault wrote:
>>
>> Le 2014-03-10 16:57, James Polk a =E9crit :
>>>
>>> At 12:16 AM 3/10/2014, Justin Uberti wrote:
>>>>
>>>> I think that the existing guidance should be sufficient in=
>>>> non-multiplexing cases (i.e. BUNDLE). For consent checks, = I think the
>>>> same DSCP markings as any other ICE connectivity checks sh= ould be
>>>> used; for ICE-for-SCTP checks, the same DSCP markings as m= edia packets
>>>> (i.e. the SCTP traffic) should be used.
>>>>
>>>> If multiplexing is being performed, the connectivity check= s probably
>>>> should use the highest DSCP value being used by the multip= lexed media.
>>>
>>> why is (seemingly) everyone's default position "use t= he highest DSCP
>>> available" for signaling packets?
>>>
>>> You just need to make sure the packets aren't starved or d= ropped by/at
>>> congestion points.
>>
>> The underlying principle is that connectivity checks need to *chec= k
>> connectivity* (duh!). That's why you use the same DSCP as the = media.
>> Connectivity is affected by the DSCP. For example some DSCPs could= be
>> filtered, or could be placed in a low-priority queue and get dropp= ed
>> such that connectivity fails.
>>
>> >From this principle follows this conclusion: on a given 5-tupl= e, if your
>> media uses different DSCPs, you need to check connectivity for all= those
>> DSCPs. That is, you would send multiple connectivity checks, one f= or
>> each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we = might
>> need an alternative heuristic: try the lowest-priority DSCP, and a= ssume
>> that if that one works, the higher-priority ones should work as we= ll.
>> (Note that Justin suggested the contrary.)
>>
>> What you want to avoid is STUN packets getting through but not the=
>> corresponding media. That is an unworkable situation. The reverse = is not
>> ideal either (you think you have no connectivity when in fact you = do),
>> but at least ICE can work around it (by picking a different candid= ate).
>
>
> This explanation makes sense for (ICE) connectivity checks.
>
> For other control information, especially information about delay, you= want to have it delivered as fast as possible, and with as little loss as = possible, because jitter in the return path will make the delay signal more= noisy, and lost packets may cause drastic actions like those the circuit-b= reakers draft recommends.
>
> Whether that always translates to "the highest DSCP code point&qu= ot; is .... a good question.

It doesn't.=A0 Keith added af42 support to mosh last yea= r and had several reports of packets being dropped with that marking. Worse= the drops happened after 10 seconds of connectivity.

Ecn markings on the other hand have thus far survived (if oc= casionally stomped on) across the open internet in that protocol.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--001a11c26bb86d04a004f457e631-- From nobody Tue Mar 11 13:01:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EBD1A063A for ; Tue, 11 Mar 2014 13:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OsX5YoD2vYT for ; Tue, 11 Mar 2014 13:00:58 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id C987F1A0538 for ; Tue, 11 Mar 2014 13:00:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7ACBA7C4F5C for ; Tue, 11 Mar 2014 21:00: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 tNHlnimkM6k9 for ; Tue, 11 Mar 2014 21:00:46 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 71B067C4F53 for ; Tue, 11 Mar 2014 21:00:46 +0100 (CET) Message-ID: <531F6B6E.6070609@alvestrand.no> Date: Tue, 11 Mar 2014 21:00:46 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010605070206010000020702" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EP-CCsQEJGpqnWp2L90qtywVkVA Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 11 Mar 2014 20:01:02 -0000 This is a multi-part message in MIME format. --------------010605070206010000020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 03/11/2014 03:41 PM, Bernard Aboba wrote: > Magnus said: > > "I would guess that the simplest is to remove discussion of TURN TCP > altogether from Transports. That would not recommend it nor make it > disallowed. If we want to be explicit, then simply motivate why we don't > believe it necessary." > > [BA] Removing a recommendation from the Transport document is OK with > me. However, since we've had quite a bit of discussion on this topic, > it would be good to state why we don't believe it to be necessary (so > as to avoid rehashing this down the line). In RFC 2119 theory, MAY and not mentioning it at all have exactly the same weight. MAY gives you a place to hang the discussion of why it's not anything stronger on. > > > On Mon, Mar 10, 2014 at 8:33 AM, Magnus Westerlund > > wrote: > > On 2014-03-06 14:34, Simon Perreault wrote: > > Le 2014-03-06 13:23, Justin Uberti a écrit : > >> can we agree that TURN TCP candidates are a SHOULD NOT? > > > > Not a SHOULD, sure. SHOULD NOT, no. > > > > I would guess that the simplest is to remove discussion of TURN TCP > altogether from Transports. That would not recommend it nor make it > disallowed. If we want to be explicit, then simply motivate why we > don't > believe it necessary. > > Justin, what is the reason you wanted SHOULD NOT? > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 --------------010605070206010000020702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/11/2014 03:41 PM, Bernard Aboba wrote:
Magnus said:

"I would guess that the simplest is to remove discussion of TURN TCP
altogether from Transports. That would not recommend it nor make it
disallowed. If we want to be explicit, then simply motivate why we don't
believe it necessary."

[BA] Removing a recommendation from the Transport document is OK with  me.  However, since we've had quite a bit of discussion on this topic, it would be good to state why we don't believe it to be necessary (so as to avoid rehashing this down the line).

In RFC 2119 theory, MAY and not mentioning it at all have exactly the same weight.
MAY gives you a place to hang the discussion of why it's not anything stronger on.




On Mon, Mar 10, 2014 at 8:33 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
On 2014-03-06 14:34, Simon Perreault wrote:
> Le 2014-03-06 13:23, Justin Uberti a écrit :
>> can we agree that TURN TCP candidates are a SHOULD NOT?
>
> Not a SHOULD, sure. SHOULD NOT, no.
>

I would guess that the simplest is to remove discussion of TURN TCP
altogether from Transports. That would not recommend it nor make it
disallowed. If we want to be explicit, then simply motivate why we don't
believe it necessary.

Justin, what is the reason you wanted SHOULD NOT?

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
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

--------------010605070206010000020702-- From nobody Tue Mar 11 13:26:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BD61A07F1 for ; Tue, 11 Mar 2014 13:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.547, 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 1IQ_ImNpIdOz for ; Tue, 11 Mar 2014 13:26:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5411A072C for ; Tue, 11 Mar 2014 13:26:48 -0700 (PDT) Received: from netb ([89.204.137.185]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MXqV1-1WhQfh2V0B-00Wo16; Tue, 11 Mar 2014 21:26:40 +0100 From: Bjoern Hoehrmann To: Harald Alvestrand Date: Tue, 11 Mar 2014 21:26:36 +0100 Message-ID: References: <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <531F6B6E.6070609@alvestrand.no> In-Reply-To: <531F6B6E.6070609@alvestrand.no> 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:EKnSnfoj5ZAxKmpEZ6P87ezx0+cn47r6C6WzXKUhzGj+axiG6Zm n+PfNWZGbPkya6M5ycoeoHPDsOeZP/nLqpA/prQfAPtCxeMgNvPW1K62buRogQ/V3+r5KSd Krc2zmX9g9vpXbLdET0wzFgHCz6AacIt+8XRC/GdBY9nT2SUNnKTwjk7NLUN4rPrKo0gwZd l771bAoMykjJdwkjIgWQw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Plm9_L3wL8zO3WqsROw5B-gEeYs Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 11 Mar 2014 20:26:50 -0000 * Harald Alvestrand wrote: >In RFC 2119 theory, MAY and not mentioning it at all have exactly the >same weight. (That depends on whether the default is "allowed" or "prohibited" and there are plenty of specifications where explicit MAY overrides a de- fault of "prohibited".) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Tue Mar 11 13:54:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38E11A07FE for ; Tue, 11 Mar 2014 13:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSa3WestJsCG for ; Tue, 11 Mar 2014 13:54:51 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id BE7AD1A07FC for ; Tue, 11 Mar 2014 13:54:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 990827C4F95; Tue, 11 Mar 2014 21:54:43 +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 ExqD7UtTa+Kw; Tue, 11 Mar 2014 21:54:43 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:ecf9:76b8:78ea:f58b] (unknown [IPv6:2001:470:de0a:27:ecf9:76b8:78ea:f58b]) by mork.alvestrand.no (Postfix) with ESMTPSA id D6E837C4F92; Tue, 11 Mar 2014 21:54:42 +0100 (CET) Message-ID: <531F7812.4030505@alvestrand.no> Date: Tue, 11 Mar 2014 21:54:42 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <531F6B6E.6070609@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mVkJ2RtYvHqICWBNoA6VMtFiHEg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 11 Mar 2014 20:54:53 -0000 On 03/11/2014 09:26 PM, Bjoern Hoehrmann wrote: > * Harald Alvestrand wrote: >> In RFC 2119 theory, MAY and not mentioning it at all have exactly the >> same weight. > (That depends on whether the default is "allowed" or "prohibited" and > there are plenty of specifications where explicit MAY overrides a de- > fault of "prohibited".) Probably true. But I can't think of any at the moment - do you have something specific in mind? Anyway, in this case, I don't think we have any default. My expectation of "normal" is that any implementation is free to add any extension (past, present or future), as long as it's possible to practice it; it is very rare that we do something explicit like the RTCWEB SDES "MUST NOT". -- Surveillance is pervasive. Go Dark. From nobody Tue Mar 11 14:23:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957AC1A0685 for ; Tue, 11 Mar 2014 14:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.547, 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 w12HM3ba5_Vm for ; Tue, 11 Mar 2014 14:23:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 794331A049C for ; Tue, 11 Mar 2014 14:23:20 -0700 (PDT) Received: from netb ([89.204.137.185]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LuKHz-1XLBWb1JyR-011jLR; Tue, 11 Mar 2014 22:23:12 +0100 From: Bjoern Hoehrmann To: Harald Alvestrand Date: Tue, 11 Mar 2014 22:23:08 +0100 Message-ID: References: <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <531F6B6E.6070609@alvestrand.no> <531F7812.4030505@alvestrand.no> In-Reply-To: <531F7812.4030505@alvestrand.no> 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:/Yxb9GXBznpL2OhC8xO6JbH8YzSKIrA78FBzp7JcmsGF4YsgeOj 9yp6SlEr2mmhxnNviWpm5FfknmQ91/JDI7HB2q9OgXRmKrT9au6mF2oVrcPnlSaJLXe9xB5 GnBGLJpcGx3tgJE6vQTBT9GsTUIA9/ysurA6luDuPMhwQ3Lvb8/BQ+/1skNdqZuWFhReV1E iOSp0bwmJOmLz/5mVVhsw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z4ue3bnE6PamBTiwLgk9AtFfhaY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 11 Mar 2014 21:23:22 -0000 * Harald Alvestrand wrote: >On 03/11/2014 09:26 PM, Bjoern Hoehrmann wrote: >> * Harald Alvestrand wrote: >>> In RFC 2119 theory, MAY and not mentioning it at all have exactly the >>> same weight. >> (That depends on whether the default is "allowed" or "prohibited" and >> there are plenty of specifications where explicit MAY overrides a de- >> fault of "prohibited".) > >Probably true. But I can't think of any at the moment - do you have >something specific in mind? (A typical example is when RFC 2119 keywords are used to describe how a protocol element is constructed, say, " elements MAY carry bar='' attributes"; you wouldn't assume you can use without that.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Tue Mar 11 14:39:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BA91A0804 for ; Tue, 11 Mar 2014 14:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE92lBKNHKel for ; Tue, 11 Mar 2014 14:39:23 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C3D3D1A063F for ; Tue, 11 Mar 2014 14:39:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9DC937C4F9F; Tue, 11 Mar 2014 22:39:16 +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 sojtsYdX0Dxd; Tue, 11 Mar 2014 22:39:16 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:ecf9:76b8:78ea:f58b] (unknown [IPv6:2001:470:de0a:27:ecf9:76b8:78ea:f58b]) by mork.alvestrand.no (Postfix) with ESMTPSA id E15FA7C4F93; Tue, 11 Mar 2014 22:39:15 +0100 (CET) Message-ID: <531F8283.7000604@alvestrand.no> Date: Tue, 11 Mar 2014 22:39:15 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <531F6B6E.6070609@alvestrand.no> <531F7812.4030505@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZUoRVxMcLmCnhm76pf3qX7eXtXQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 11 Mar 2014 21:39:26 -0000 On 03/11/2014 10:23 PM, Bjoern Hoehrmann wrote: > * Harald Alvestrand wrote: >> On 03/11/2014 09:26 PM, Bjoern Hoehrmann wrote: >>> * Harald Alvestrand wrote: >>>> In RFC 2119 theory, MAY and not mentioning it at all have exactly the >>>> same weight. >>> (That depends on whether the default is "allowed" or "prohibited" and >>> there are plenty of specifications where explicit MAY overrides a de- >>> fault of "prohibited".) >> Probably true. But I can't think of any at the moment - do you have >> something specific in mind? > (A typical example is when RFC 2119 keywords are used to describe how a > protocol element is constructed, say, " elements MAY carry bar='' > attributes"; you wouldn't assume you can use without that.) Any specific examples? Without context, this seems a strange way to specify protocol elements; more common is to use ABNF, and not 2119 keywords. And ABNF even allows "free" extensibility by having other specs use the /= operator.... -- Surveillance is pervasive. Go Dark. From nobody Tue Mar 11 14:45:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC4A1A0838 for ; Tue, 11 Mar 2014 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.547, 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 wXs1XBPFp-j9 for ; Tue, 11 Mar 2014 14:44:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id EBDDC1A081F for ; Tue, 11 Mar 2014 14:44:49 -0700 (PDT) Received: from netb ([89.204.137.185]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lip2P-1WszHD47y9-00cx7p; Tue, 11 Mar 2014 22:44:37 +0100 From: Bjoern Hoehrmann To: Harald Alvestrand Date: Tue, 11 Mar 2014 22:44:35 +0100 Message-ID: References: <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <531F6B6E.6070609@alvestrand.no> <531F7812.4030505@alvestrand.no> <531F8283.7000604@alvestrand.no> In-Reply-To: <531F8283.7000604@alvestrand.no> 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:iqnJg4BacKoYbo8Rc1xZIt9CX7zHec3vU9VA/6FjrmZfLmZE0od 94vlJn4r84pbQ5M8O8q13eDXSE2W6iC6z2ShKg2MFm2sxE3GSz1ULTAk0BBESB5hmfSq+Rm 7pS4qSYRdTL2crTISc1YagEXaDm6LW+I6f+CjyUyvxog+1c/vNJd9sY7r3N15Xmzv+HZI6C BdpbmrTIsILp69fKSRl1g== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ydGPGQTwkh3ZWUGvyAXD_lZygFI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 11 Mar 2014 21:45:00 -0000 * Harald Alvestrand wrote: >On 03/11/2014 10:23 PM, Bjoern Hoehrmann wrote: >> (A typical example is when RFC 2119 keywords are used to describe how a >> protocol element is constructed, say, " elements MAY carry bar='' >> attributes"; you wouldn't assume you can use without that.) > >Any specific examples? I think this is really very common, https://tools.ietf.org/html/rfc4287 is an instance of my example above. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Tue Mar 11 17:59:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2241A087C for ; Tue, 11 Mar 2014 17:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 KFuPjtz-z6f3 for ; Tue, 11 Mar 2014 17:59:13 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A3BA51A08AD for ; Tue, 11 Mar 2014 17:59:13 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so9111984veb.25 for ; Tue, 11 Mar 2014 17:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jNgmrHGluNLdEsWmY6Jv5EIjZeQWk+e4aXshqqf/WO4=; b=Vd//iaHVC/SKgMMBDzAzsUD+9iDO3hIH4bllinWh8eDt9+nNHy1YIRyLUrBX3QPVyC vIeuHLTJGbh4sr6H2gdexe++hSQgLDVLkDSk2GiR2du+JaLli8T6TiR+mHINLHkNnVpe vMmD2HvUv9A2gCyqfJx+yzY2tzCZ7nU2NTyjorAnevnT8sllOmgwpmXdPoDLXVhICoBY CDg4YH0p4JNsPu1oezRebCj4mUCpQF9NN9duaAmnOw310jzUrVA8SfMwHvvIifqQ1GnT y1uyX1TkKl+tEwC2vGPUsZzgmb6igFO/PDrbDf1kVOuSu9veuswOMliX7RbsA8zmVimu ePOQ== 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=jNgmrHGluNLdEsWmY6Jv5EIjZeQWk+e4aXshqqf/WO4=; b=eTbkTnWKUIAWLN5MhK95ZPu6kyLRxk8YhR3EyRr6jswxlCiiMU4CXv2/tU5/rguWkP GQ6VNtvSXOShNQCz3t6swfPHLVrsM1LIXWZaC9DgzIOxPbWtCr6she4jBbJWuTyB+raG BQo73aVV7QqpdXNfPK368pAmxsnPZhFQEghWAtTIRblkgin/AcfSHRXHW56uu8461//t jKHVdW15F72oQ0Ovg2KkG28CNyi1QpmCPRitpqiGjNmMMZq53LPLACPEpbbnWYtQU0yU fsBA955OlUYe5KXfHpYO55Y/bip+kEcJ2HuaJC1fOzTeSJ2TNN3DYQlaq3TTw5PAq90V i3Wg== X-Gm-Message-State: ALoCoQli2/b3EldTeP6uAB6S9vXGfya7iHF5d8PI1+t/gCqRKokU+0SCHBLQGSxaCqYsSfrUsYDNjNEBzF1b0Bku3n9rvhk8yhIgNAeBsa2WlqCqpV5B4aL5WD8u9Yf7wQtcGW/IyaUl+2m2tICLdfYMC3rNrKtGgHNyH+QyposBMD5sQIZpbJGHJh8lkVyk5MG5QS4jBOo2 X-Received: by 10.52.251.199 with SMTP id zm7mr20481881vdc.21.1394585947308; Tue, 11 Mar 2014 17:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 17:58:47 -0700 (PDT) In-Reply-To: <531DDB5A.4060201@ericsson.com> References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> From: Justin Uberti Date: Tue, 11 Mar 2014 17:58:47 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a1135f378ff9d1e04f45e57e2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6PxY7Pnp81xWIOpw79QoGR7W4GA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 12 Mar 2014 00:59:15 -0000 --001a1135f378ff9d1e04f45e57e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The reason I suggested SHOULD NOT is because I think this technique is unnecessary for WebRTC, and typically net harmful for the reasons that Matthew mentions. That said, I would be fine with saying MAY and including some explanatory text; my main concerns was to avoid the ambiguity that would arise from leaving this out altogether. On Mon, Mar 10, 2014 at 8:33 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-06 14:34, Simon Perreault wrote: > > Le 2014-03-06 13:23, Justin Uberti a =C3=A9crit : > >> can we agree that TURN TCP candidates are a SHOULD NOT? > > > > Not a SHOULD, sure. SHOULD NOT, no. > > > > I would guess that the simplest is to remove discussion of TURN TCP > altogether from Transports. That would not recommend it nor make it > disallowed. If we want to be explicit, then simply motivate why we don't > believe it necessary. > > Justin, what is the reason you wanted SHOULD NOT? > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a1135f378ff9d1e04f45e57e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The reason I suggested SHOULD NOT is because I think this = technique is unnecessary for WebRTC, and typically net harmful for the reas= ons that Matthew mentions.=C2=A0

That said, I would be f= ine with saying MAY and including some explanatory text; my main concerns w= as to avoid the ambiguity that would arise from leaving this out altogether= .


On Mon,= Mar 10, 2014 at 8:33 AM, Magnus Westerlund <magnus.westerl= und@ericsson.com> wrote:
On 2014-03-06 14:34, Simon P= erreault wrote:
> Le 2014-03-06 13:23, Justin Uberti a =C3=A9crit :
>> can we agree that TURN TCP candidates are a SHOULD NOT?
>
> Not a SHOULD, sure. SHOULD NOT, no.
>

I would guess that the simplest is to remove discussion of TURN TCP altogether from Transports. That would not recommend it nor make it
disallowed. If we want to be explicit, then simply motivate why we don'= t
believe it necessary.

Justin, what is the reason you wanted SHOULD NOT?

cheers

Magnus Westerlund

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


--001a1135f378ff9d1e04f45e57e2-- From nobody Tue Mar 11 20:53:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956361A03A7 for ; Tue, 11 Mar 2014 20:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 PkNFZtxo_Wpa for ; Tue, 11 Mar 2014 20:53:37 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 684DB1A03A5 for ; Tue, 11 Mar 2014 20:53:37 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so9397781veb.26 for ; Tue, 11 Mar 2014 20:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bc6YXgohZCT3FBgJfhqHciPMs3IVXj30qdO0wIlE2zg=; b=inh7h9zKnTMgF6n6eL0SqId9UiMvbWEd56KnzlXV0Kuxg7/Pu2nWX12HMRCYwkrTlO GeognUgEnNsfwXXvfdbg+NiF1giIDk3il3BjfzRoERM8stUdRcis2BsenYiHJFcMA24l 0LGJOofInm/RVH/JNxz+ytjM+/lVUESTqsz1IX+N3ocCREH1EOZ9q8gkhaXjhwJCJ3qo Vhs+SjjsaY1J2taXvwfHXo7wKQSeC/PHyr6XBcOBB063ep+MRSG69QiLW4A8eCIGwPbl OZt+JQNCyV5zy9RDA5szGA6BVXUzM8fMYgUVDf9TZ1D/1RJMcI4pbJ8uoas6+UILokY6 4t7A== 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=Bc6YXgohZCT3FBgJfhqHciPMs3IVXj30qdO0wIlE2zg=; b=Y5w7JCHn8DMXk5h00E/8DVpuUacjyuxAsJAvJJETmYNDgSeVPOxIDhBD8j3i7RdBEA riCctk6kjC9FbbSUCbgz9HCC0c1j2I3jUe7xnv+24gY0Icihkfq3lKxIILMM7VhlDkyu yD9+VpDJDPz4YYWBM6/ztbu50QBkVVEwJluGsIPjfgUkskXU2NK+fCRTCJFBwDJo9B72 Ns7kZdrdgwD4qxPJHuINPDf7PejqG1xToVHXIiG2r2xSz6L4GcgfV3U+yXq1e63Gn/XF k9WfI2vRd/eT0wmiJzhTHJCxdxb4/xNufe6u7BbhSsq/OlajuUkXdh6+W/qLvJ8eVY2B uCWA== X-Gm-Message-State: ALoCoQkGj6n66BdYhdCt9hKYi8XOeHUnH4MFxY5AfaphMs+HD7NBkJ6cFWZVdC0JUTsZD1IMo5swgYiNj0o10ez8DCIk+O1WHkBaZn9L+ca0ehtrt0o16lWZiInTUT0hhUrNy04p3m4A8qhVHDWLK+2QaxscLTAXP+TBsqscRD5hk8x4KNzj+QMt5xhb847ZuuwBPXojpEre X-Received: by 10.52.72.12 with SMTP id z12mr36470vdu.40.1394596411084; Tue, 11 Mar 2014 20:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 20:53:11 -0700 (PDT) In-Reply-To: <531F176C.2070305@viagenie.ca> References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> From: Justin Uberti Date: Tue, 11 Mar 2014 20:53:11 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf307f313cb029e004f460c7fd Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_4LlHfKzeQyY8Mq-ge_p57Nhsmk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 12 Mar 2014 03:53:39 -0000 --20cf307f313cb029e004f460c7fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-10 16:57, James Polk a =C3=A9crit : > > At 12:16 AM 3/10/2014, Justin Uberti wrote: > >> I think that the existing guidance should be sufficient in > >> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the > >> same DSCP markings as any other ICE connectivity checks should be > >> used; for ICE-for-SCTP checks, the same DSCP markings as media packets > >> (i.e. the SCTP traffic) should be used. > >> > >> If multiplexing is being performed, the connectivity checks probably > >> should use the highest DSCP value being used by the multiplexed media. > > > > why is (seemingly) everyone's default position "use the highest DSCP > > available" for signaling packets? > > > > You just need to make sure the packets aren't starved or dropped by/at > > congestion points. > > The underlying principle is that connectivity checks need to *check > connectivity* (duh!). That's why you use the same DSCP as the media. > Connectivity is affected by the DSCP. For example some DSCPs could be > filtered, or could be placed in a low-priority queue and get dropped > such that connectivity fails. > > >From this principle follows this conclusion: on a given 5-tuple, if your > media uses different DSCPs, you need to check connectivity for all those > DSCPs. That is, you would send multiple connectivity checks, one for > each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might > need an alternative heuristic: try the lowest-priority DSCP, and assume > that if that one works, the higher-priority ones should work as well. > (Note that Justin suggested the contrary.) > > What you want to avoid is STUN packets getting through but not the > corresponding media. That is an unworkable situation. The reverse is not > ideal either (you think you have no connectivity when in fact you do), > but at least ICE can work around it (by picking a different candidate). > We also need to consider the scenario of STUN consent checks, which will need to get through reliably even when media marked with DSCP is already flowing. In this case I think that using the highest DSCP value for STUN is unavoidable. --20cf307f313cb029e004f460c7fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-10 16:57, James Polk a =C3=A9crit= :
> At 12:16 AM 3/10/2014, Justin Uberti wrote:
>> I think that the existing guidance should be sufficient in
>> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think = the
>> same DSCP markings as any other ICE connectivity checks should be<= br> >> used; for ICE-for-SCTP checks, the same DSCP markings as media pac= kets
>> (i.e. the SCTP traffic) should be used.
>>
>> If multiplexing is being performed, the connectivity checks probab= ly
>> should use the highest DSCP value being used by the multiplexed me= dia.
>
> why is (seemingly) everyone's default position "use the highe= st DSCP
> available" for signaling packets?
>
> You just need to make sure the packets aren't starved or dropped b= y/at
> congestion points.

The underlying principle is that connectivity checks need to *check connectivity* (duh!). That's why you use the same DSCP as the media. Connectivity is affected by the DSCP. For example some DSCPs could be
filtered, or could be placed in a low-priority queue and get dropped
such that connectivity fails.

>From this principle follows this conclusion: on a given 5-tuple, if you= r
media uses different DSCPs, you need to check connectivity for all those DSCPs. That is, you would send multiple connectivity checks, one for
each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might
need an alternative heuristic: try the lowest-priority DSCP, and assume
that if that one works, the higher-priority ones should work as well.
(Note that Justin suggested the contrary.)

What you want to avoid is STUN packets getting through but not the
corresponding media. That is an unworkable situation. The reverse is not ideal either (you think you have no connectivity when in fact you do),
but at least ICE can work around it (by picking a different candidate).
=

We also need to consider the scenario of S= TUN consent checks, which will need to get through reliably even when media= marked with DSCP is already flowing. In this case I think that using the h= ighest DSCP value for STUN is unavoidable.
--20cf307f313cb029e004f460c7fd-- From nobody Tue Mar 11 20:55:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FFA1A0897 for ; Tue, 11 Mar 2014 20:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 3CeNsPD-QYOj for ; Tue, 11 Mar 2014 20:55:46 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADA71A0398 for ; Tue, 11 Mar 2014 20:55:46 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so8854403vcb.7 for ; Tue, 11 Mar 2014 20:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GYOthn6hxnFuEAZ4ww9qMDtrCOW6Fdyt0B8DcFRmbYo=; b=Ja2j/WUJdJFclLiVoagIfp9gyqfd//xIxCE7ljKHc9IMk+3/qzNcivZg/eEm1SL/bS Wpa4sJmTpVHUwu0Op9PSHdMgjKwPG4Nxj5X8X6O/IfvIxP9atgtLHdJixFCip8iV/trM MA4fwFHKMGTWdmv9Ldlx3Az005aacopZN6EuZwpshx+wslseIo+2RMPxtPCtLaxvWr8Y 2eFFnqAhXtnFVbhIzYEQ4N0BtqxysIrK6d/xTBNA54I9vvL5h81d8avHsNQqEEqpXVCk dFS0lqKZ52r9jIQEUXVCF5VRmaSaz9vrtdkBnxASqINS7Dbna52C5a8HbhD6cRaE2UDx ERQg== 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=GYOthn6hxnFuEAZ4ww9qMDtrCOW6Fdyt0B8DcFRmbYo=; b=U6sYFrLTz4kXX303K9INIBQRFuVEuX2dEb4HQrg0/ik76GqmO0JwaihoBrRPZiYxNc jmp0Y8678s5DalpWe5F4FO1uLsxX85E8YqmykKZo7GPY2I2K5ZAQakoNlYVJKSoc0t0c JPLqmRwWDWobvm95GQzIUjS4b+elvGyml6z4mcFq+3CyKSP2gbiXC1qSBtxxnV29UWx0 W/EziL0e5CmEoiaCwlwuGSp+/0d887XpIsP45Kbmmi+bjdojxbEpYWAiFCRU3kvamkU8 nk4oKxOuWMx7tpwCSrJ/uQdbIUj03DQmCpycz+H0R0qah2N3+NYvRI/j8Seg28G5a/Iz 8qAQ== X-Gm-Message-State: ALoCoQl9ZFsg+c3jsfC7NPvgWTAH1S4jrBKMczcc2vUr74zY8BAXt37f08zMaPfPVlse4CR+B9vlrM85RFiJvm0ky+WUMY1vMSh6w3eH4cLgBpij1r2bOEMh2CuSecah+1JYsmu06N3VyN2LdH3by6fhnpapgRxnAnh9h8ecrsKnneHmtTgb4Uf2L7dKRZyKv5DWOU7ZZU1k X-Received: by 10.52.65.132 with SMTP id x4mr120995vds.36.1394596540434; Tue, 11 Mar 2014 20:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 20:55:20 -0700 (PDT) In-Reply-To: References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <531F212A.4040102@alvestrand.no> From: Justin Uberti Date: Tue, 11 Mar 2014 20:55:20 -0700 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=20cf3071c8ac65e9e204f460cfab Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kfuVMfOmi2vclDlTCpntt5N7GiQ Cc: Keith Winstein , "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 12 Mar 2014 03:55:48 -0000 --20cf3071c8ac65e9e204f460cfab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht wrote: > > On Mar 11, 2014 7:44 AM, "Harald Alvestrand" wrote= : > > > > On 03/11/2014 03:02 PM, Simon Perreault wrote: > >> > >> Le 2014-03-10 16:57, James Polk a =C3=A9crit : > >>> > >>> At 12:16 AM 3/10/2014, Justin Uberti wrote: > >>>> > >>>> I think that the existing guidance should be sufficient in > >>>> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think th= e > >>>> same DSCP markings as any other ICE connectivity checks should be > >>>> used; for ICE-for-SCTP checks, the same DSCP markings as media packe= ts > >>>> (i.e. the SCTP traffic) should be used. > >>>> > >>>> If multiplexing is being performed, the connectivity checks probably > >>>> should use the highest DSCP value being used by the multiplexed medi= a. > >>> > >>> why is (seemingly) everyone's default position "use the highest DSCP > >>> available" for signaling packets? > >>> > >>> You just need to make sure the packets aren't starved or dropped by/a= t > >>> congestion points. > >> > >> The underlying principle is that connectivity checks need to *check > >> connectivity* (duh!). That's why you use the same DSCP as the media. > >> Connectivity is affected by the DSCP. For example some DSCPs could be > >> filtered, or could be placed in a low-priority queue and get dropped > >> such that connectivity fails. > >> > >> >From this principle follows this conclusion: on a given 5-tuple, if > your > >> media uses different DSCPs, you need to check connectivity for all tho= se > >> DSCPs. That is, you would send multiple connectivity checks, one for > >> each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we migh= t > >> need an alternative heuristic: try the lowest-priority DSCP, and assum= e > >> that if that one works, the higher-priority ones should work as well. > >> (Note that Justin suggested the contrary.) > >> > >> What you want to avoid is STUN packets getting through but not the > >> corresponding media. That is an unworkable situation. The reverse is n= ot > >> ideal either (you think you have no connectivity when in fact you do), > >> but at least ICE can work around it (by picking a different candidate)= . > > > > > > This explanation makes sense for (ICE) connectivity checks. > > > > For other control information, especially information about delay, you > want to have it delivered as fast as possible, and with as little loss as > possible, because jitter in the return path will make the delay signal mo= re > noisy, and lost packets may cause drastic actions like those the > circuit-breakers draft recommends. > > > > Whether that always translates to "the highest DSCP code point" is .... > a good question. > > It doesn't. Keith added af42 support to mosh last year and had several > reports of packets being dropped with that marking. Worse the drops > happened after 10 seconds of connectivity. > > Ecn markings on the other hand have thus far survived (if occasionally > stomped on) across the open internet in that protocol. > This is a concern of mine as well, which is why we haven't yet flipped the switch to turn DSCP on by default in Chrome. I think we'll need to do some experimentation to see how often DSCP makes things worse. --20cf3071c8ac65e9e204f460cfab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht <<= a href=3D"mailto:dave.taht@gmail.com" target=3D"_blank">dave.taht@gmail.com= > wrote:


On Mar 11, 2014 7:44 AM, "Harald Alvestrand" <harald@alvestrand.no> wrot= e:
>
> On 03/11/2014 03:02 PM, Simon Perreault wrote:
>>
>> Le 2014-03-10 16:57, James Polk a =C3=A9crit :
>>>
>>> At 12:16 AM 3/10/2014, Justin Uberti wrote:
>>>>
>>>> I think that the existing guidance should be sufficient in=
>>>> non-multiplexing cases (i.e. BUNDLE). For consent checks, = I think the
>>>> same DSCP markings as any other ICE connectivity checks sh= ould be
>>>> used; for ICE-for-SCTP checks, the same DSCP markings as m= edia packets
>>>> (i.e. the SCTP traffic) should be used.
>>>>
>>>> If multiplexing is being performed, the connectivity check= s probably
>>>> should use the highest DSCP value being used by the multip= lexed media.
>>>
>>> why is (seemingly) everyone's default position "use t= he highest DSCP
>>> available" for signaling packets?
>>>
>>> You just need to make sure the packets aren't starved or d= ropped by/at
>>> congestion points.
>>
>> The underlying principle is that connectivity checks need to *chec= k
>> connectivity* (duh!). That's why you use the same DSCP as the = media.
>> Connectivity is affected by the DSCP. For example some DSCPs could= be
>> filtered, or could be placed in a low-priority queue and get dropp= ed
>> such that connectivity fails.
>>
>> >From this principle follows this conclusion: on a given 5-tupl= e, if your
>> media uses different DSCPs, you need to check connectivity for all= those
>> DSCPs. That is, you would send multiple connectivity checks, one f= or
>> each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we = might
>> need an alternative heuristic: try the lowest-priority DSCP, and a= ssume
>> that if that one works, the higher-priority ones should work as we= ll.
>> (Note that Justin suggested the contrary.)
>>
>> What you want to avoid is STUN packets getting through but not the=
>> corresponding media. That is an unworkable situation. The reverse = is not
>> ideal either (you think you have no connectivity when in fact you = do),
>> but at least ICE can work around it (by picking a different candid= ate).
>
>
> This explanation makes sense for (ICE) connectivity checks.
>
> For other control information, especially information about delay, you= want to have it delivered as fast as possible, and with as little loss as = possible, because jitter in the return path will make the delay signal more= noisy, and lost packets may cause drastic actions like those the circuit-b= reakers draft recommends.
>
> Whether that always translates to "the highest DSCP code point&qu= ot; is .... a good question.

It doesn't.=C2=A0 Keith added af42 support t= o mosh last year and had several reports of packets being dropped with that= marking. Worse the drops happened after 10 seconds of connectivity.

Ecn markings on the other hand have thus far survived (if oc= casionally stomped on) across the open internet in that protocol.


This is a concern of mine as well, which is why = we haven't yet flipped the switch to turn DSCP on by default in Chrome.= I think we'll need to do some experimentation to see how often DSCP ma= kes things worse.
--20cf3071c8ac65e9e204f460cfab-- From nobody Tue Mar 11 21:21:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5331A0897 for ; Tue, 11 Mar 2014 21:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 tDTOclINkrGa for ; Tue, 11 Mar 2014 21:21:50 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0971A03A7 for ; Tue, 11 Mar 2014 21:21:50 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so9863760veb.0 for ; Tue, 11 Mar 2014 21:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tFVsn11fFRPtRwH9l6YvvaGPlQcid0EZSejAGqgeCZU=; b=Mmb+iEVdq//qy9e3iluM91hYM+Wlsrp2rc3i0xnCLLSYNBFxlBpTuD3QrmihzoJknP UFY+yO8hSwoZ1lKQFwUJH1FxzkN2AIljKgKeG6eX8I9+r0HMnq85/6JhhzBWaoJFnH6n XxnGw8AAM9aXi/5XC3MvRzh0zCqQtvwPFhvC0UQ7OlbKauX/W3vdO8d9UEdP9F1+mn/p eYpAUXGLWb9S1WUJAGZ122QB4hYydDnT5DjrdCuvERqksc4sBWdbi+xnES5UOUiNqC5x w3wNdoLW+F/mA2k4nwE3oELQdvaz1NjxDHlh1/RiOiLmsS1yPhNjp/2QqFIN3ypB+wmv 5P7Q== 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=tFVsn11fFRPtRwH9l6YvvaGPlQcid0EZSejAGqgeCZU=; b=NoxJ1ue6b15I0lXfTd2nERk/4+/ZrRqX8w0Chx8JRveJ0VEYa2NRwZ4IYxKkHnRLe8 kYM37B2or7U+bCPyuENj+iFJ2aMQYvpO9wYVjJ27HRJ1tp3GWDZLHO3/aTntjS4Fv2zP 5ZkarEBoKO0vu2jY9cJ/jmjaVFBpPCSLM9rQzTd+6vNDXCGqg4VXDFh4ov0nIGJ+osFf J7IEu7MiYrgzKZydbA+Rcq56JqjOG53RjcHYPsGQX3TI7C9osk2DX5zVomyzWaJ1P65Q liVMwQhCv8OK4ZD/mtARobahXkNcfzxtCZjFgB1lfnSTlp1BL55Xh5qR4DnGtdabAAd6 JM8A== X-Gm-Message-State: ALoCoQneVFmnMp/6i+h/R0CQhRgCuVfazwbt/27ZAva7HO2ESfCCB3WDAlKqLbGnbQDnroTxh5PLKRzZuIg43r6tpaph1CJAVxFdblcVwsaNfbhcsgrCBvuVa6lydT2FUjeys+S/S+j6A/BvkFQ5PUJXH01DY3d+IQw1riMfHf/l7JfsIRTAMExSgm8vUS/LXA/0pAaajWGr X-Received: by 10.58.69.111 with SMTP id d15mr30412166veu.3.1394598104320; Tue, 11 Mar 2014 21:21:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 21:21:24 -0700 (PDT) In-Reply-To: References: <1BC59A5D-D1C9-4E3F-ABFB-C1D664CD7ACF@cisco.com> From: Justin Uberti Date: Tue, 11 Mar 2014 21:21:24 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=e89a8ff1c2469ce62d04f4612cde Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pol5vbTjfEZZ6zl7bMvKMQguMHo Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level 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, 12 Mar 2014 04:21:53 -0000 --e89a8ff1c2469ce62d04f4612cde Content-Type: text/plain; charset=UTF-8 I agree we need to mandate implementation of encryption for the c2m audio level headers. For actual use, what controls do we want - the ability to offer one of (encrypted, encrypted + unencrypted, none)? On Mon, Mar 10, 2014 at 9:47 PM, Bernard Aboba wrote: > Cullen said: > > "I am opposed to mandating that Client-to-Mixer Audio Level RTP header is > REQUIRED to be encrypted. It means that we can not really build > conferencing system where the mixers do not have access to decrypt the > media." > > [BA] I am also not enthused about mandating encryption of header > extensions. However, in the interest of fairness, it is worth pointing out > that header extensions are optional, so if a particular extension is > encrypted, the mixer can always ignore it (and in this case, thereby do > more work mixing muted audio streams). So my take would be to say SHOULD > encrypt Client-to-MIxer Audio level, but leave this up to negotiation so > that if the mixer doesn't want it encrypted, it can turn that off. > > > On Wed, Mar 5, 2014 at 4:32 AM, Cullen Jennings (fluffy) > wrote: > >> >> I am opposed to mandating that Client-to-Mixer Audio Level RTP header is >> REQUIRED to be encrypted. It means that we can not really build >> conferencing system where the mixers do not have access to decrypt the >> media. >> >> I would like to propose that the JS application can control if the >> header is encrypted or not. >> >> I am aware of the paper that suggests these audio levels can reveal the >> contents of the conversation. There is some element of truth to this. There >> is also some element of truth to the point that if this was true, speech >> recognition system would work better than they do. Encrypting this or not >> is a risk that the application using the header extension needs to >> evaluate, and WebRTC system needs to provide the applications with a >> control surfaces that allows them to use this in the way the applications >> desires. >> >> I will note that an normal application that used this header could decide >> if it was encrypted or not, what is different in RTCWeb is that we are >> building a platform and my view is that this platform should allow the >> applications build on the platform to decide the tradeoffs of risk for >> encrypting this or not. >> >> >> >> >> >> >> _______________________________________________ >> 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 > > --e89a8ff1c2469ce62d04f4612cde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree we need to mandate implementation of encryption for the = c2m audio level headers. For actual use, what controls do we want - the abi= lity to offer one of (encrypted, encrypted + unencrypted, none)?=C2=A0

=
On Mon, Mar 10,= 2014 at 9:47 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Cullen said:=C2=A0
"I am oppo= sed to mandating that Client-to-Mixer Audio Level RTP header is REQUIRED to= be encrypted. It means that we can not really build conferencing system wh= ere the mixers do not have access to decrypt the media."

[BA] I am also not enthused about mandating encryption of header extensi= ons. However, in the interest of fairness, it is worth pointing out that he= ader extensions are optional, so if a particular extension is encrypted, th= e mixer can always ignore it (and in this case, thereby do more work mixing= muted audio streams). =C2=A0So my take would be to say SHOULD encrypt Clie= nt-to-MIxer Audio level, but leave this up to negotiation so that if the mi= xer doesn't want it encrypted, it can turn that off.=C2=A0


=
On Wed, Mar 5, 2014 at 4:32 AM, Cullen Jennings = (fluffy) <fluffy@cisco.com> wrote:

I am opposed to mandating that Client-to-Mixer Audio Level RTP header is RE= QUIRED to be encrypted. It means that we can not really build conferencing = system where the mixers do not have access to decrypt the media.

I would like to propose that the JS application can control =C2=A0if the he= ader is encrypted or not.

I am aware of the paper that suggests these audio levels can reveal the con= tents of the conversation. There is some element of truth to this. There is= also some element of truth to the point that if this was true, speech reco= gnition system would work better than they do. Encrypting this or not is a = risk that the application using the header extension needs to evaluate, and= WebRTC system needs to provide the applications with a control surfaces th= at allows them to use this in the way the applications desires.

I will note that an normal application that used this header could decide i= f it was encrypted or not, what is different in RTCWeb is that we are build= ing a platform and my view is that this platform should allow the applicati= ons build on the platform to decide the tradeoffs of risk for encrypting th= is or not.






_______________________________________________
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


--e89a8ff1c2469ce62d04f4612cde-- From nobody Tue Mar 11 21:38:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAC41A08D9 for ; Tue, 11 Mar 2014 21:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-0.547, 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 QiWX9Oq9qGmt for ; Tue, 11 Mar 2014 21:37:59 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 671D71A03AC for ; Tue, 11 Mar 2014 21:37:59 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so9472325veb.37 for ; Tue, 11 Mar 2014 21:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=plJd5ac5469l5DpiDZa1Ewcvj+0gGE071md2/Us6+h4=; b=eeS2izMgn3jz3xsQLPFHe1eEDK34EguDQQipPfhoiApXvNAq1lxkXsfmNi+mFByPtQ Y3m0vFUP8Kh8kEz6I3tUP7SFX0Q6YALBprAxCrcMRzz9e29jdoHAwpgGp98tpumpANJQ 2pvudBJRbvY7ET8QuaaxNuggsf+UcAY58OgocZCCSOpJiZkzQBO7Tt2e+1mLefhsKjOM QUcC7+nWzduvkXw2Cx8wJmaKeA3h/tnSBDyAiCxhdx6Ars8ReUqZpZ35CZVJ/jVQ+OOb b4BDH0KGmwXrlwwbZL2+FeblOibiNGAAi11gLOlzSHObb4HyFhXPo1gq/ayXTKvfUuFC VU7A== 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=plJd5ac5469l5DpiDZa1Ewcvj+0gGE071md2/Us6+h4=; b=gzXwCg0Xn9wIZpDZ+OT+qQH67LKjgWmU5bAZBN/ATVpox4TOuiPwbRHW7hyky1DkTv M3tKf8qagznh+w57QMD0q+HFxP2QSzH5VOfv+1mOD92n+kp/egIOmJC/jL92V2bdaK2b 7VYo2nhjra+t6mqGSqZm6S+zTK5KHYceIHpgs4kwGm1h7ACfCPP3unq6Q2SD5maKgXsw 2AoDZsgcma65DtiRLa5AOdEr+RQBV1Ryh29VyIdnJ20GsJyt0o+6uc04c6mAS/kjbF6l lBS1izhBchsh4/ksmaDOY9QFIPtp5WvYJOxhhlfkNO+G6OaOKLDISrE9+KW3JyuvDXSS tfPQ== X-Gm-Message-State: ALoCoQkYAd+LG75yWyFDs/1C2JxKm1TS5DuIzHrrrY45WOEEE6d3dPLApCb6xTjWFCoWcEGrkjhnTVGaEA6NJ88UiTBaZIc+LMmtBr3YN743y3J3K+ZQrENggDs62zbCJMkY2h7Awe8m858ZCUIMiXIPehVEvFvrhTzG5EkW6OsydBvz1vHMJdC6TQeG5jamiMK0XtiuiLCk X-Received: by 10.58.95.161 with SMTP id dl1mr13117916veb.21.1394599073163; Tue, 11 Mar 2014 21:37:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 21:37:33 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2009B4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2009B4@ESESSMB209.ericsson.se> From: Justin Uberti Date: Tue, 11 Mar 2014 21:37:33 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013cb9965c47e604f46166d1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HRKGqDTZUVIogXwPxb5OpfHMZj0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 12 Mar 2014 04:38:01 -0000 --089e013cb9965c47e604f46166d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sort of. The idea is whether JSEP should have a mode which _gathers_ only a single set of ports, in effect assuming the other side supports rtcp-mux. The use of a=3Drtcp is incidental here, and only used to point out that the RTP and RTCP ports that are offered will be identical. On Tue, Mar 11, 2014 at 12:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > "BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp > attributes. I remember we had discussions about that, but I don=E2=80=99t= remember > the justification at the moment." > > [BA] The justification was that an implementation interested in > multiplexing A/V would almost certainly also want to multiplex RTP and > RTCP, because the motivation for both is minimizing port usage. > > [Christer] So, again, the idea is to use a=3Drtcp to indicate the *same* > port as a=3Drtcp-mux indicates, and hope that the receiver supports at le= ast > either a=3Drtcp or a=3Drtcp-mux? > > Regards, > > Christer > > > > On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> Before I comment on your proposal, let=E2=80=99s take a few steps back (= maybe it >> can even solve your issue). >> >> >> >> BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp >> attributes. I remember we had discussions about that, but I don=E2=80=99= t remember >> the justification at the moment. But, I wonder whether that text is from >> before we made a decision that, unless both endpoints support BUNDLE, no >> endpoint will use a single address:port. >> >> >> >> So, the question is: do we really need the SDP rtcp attribute? >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> >> >> >> >> *From:* Justin Uberti [mailto:juberti@google.com] >> *Sent:* 10. maaliskuuta 2014 8:18 >> *To:* rtcweb@ietf.org; Eric Rescorla; Christer Holmberg >> *Subject:* BUNDLE with implicit rtcp-mux >> >> >> >> In my JSEP preso during the RTCWEB session last Wednesday, I discussed >> adding a new BUNDLE policy to JSEP. This policy, which would be called >> something like =E2=80=9Cforce-bundle=E2=80=9D, would force the use of th= e same ports for >> BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that th= e >> other side supports BUNDLE, this would reduce candidate gathering even o= ver >> the currently defined =E2=80=9Cmax-bundle=E2=80=9D policy, since there w= ould be no need to >> gather RTCP ports at all, and also avoid the need for the BUNDLE fixup >> offer (where the ports are updated to be the same for all BUNDLEd >> m-sections). >> >> To explain the differences here, here are some example offers for an >> audio+video call: >> >> Default bundle policy - separate ports for audio, video, RTP and RTCP: >> m=3Daudio 10000 >> a=3Drtcp:10001 >> a=3Drtcp-mux >> m=3Dvideo 11000 >> a=3Drtcp:11001 >> a=3Drtcp-mux >> >> Existing "max-bundle" policy - video port is 0 because bundle-only, but >> both RTP and RTCP ports allocated for audio: >> m=3Daudio 10000 >> a=3Drtcp:10001 >> a=3Drtcp-mux >> m=3Dvideo 0 >> a=3Dbundle-only >> a=3Drtcp-mux >> >> The new =E2=80=9Cforce-bundle=E2=80=9D policy - only a single set of por= ts allocated - >> audio, video, RTP, RTCP share the same port. >> m=3Daudio 10000 >> a=3Drtcp:10000 >> a=3Drtcp-mux >> m=3Dvideo 10000 >> a=3Drtcp:10000 >> a=3Drtcp-mux >> >> During the discussion, the ability to avoid RTCP port gathering was seen >> as valuable, but not the ability to avoid the fixup offer. However, afte= r >> thinking about it a bit, I don=E2=80=99t think that there is a viable so= lution that >> avoids RTCP port gathering that *doesn=E2=80=99t* use a single set of po= rts. The >> only other option would be to do something like this: >> >> m=3Daudio 10000 >> a=3Drtcp:10000 # same as m=3Daudio port >> a=3Drtcp-mux >> m=3Dvideo 0 >> a=3Dbundle-only >> a=3Drtcp-mux >> >> but this will almost surely will result in a malfunction when talking to >> a non-rtcp-mux client, due to the same port being used for RTP and RTCP, >> and still requires the fixup offer, and as such is net worse than the >> force-bundle approach indicated above. >> >> So I think we the force-bundle approach is the one we want to minimize >> port gathering. The only question is whether we should keep max-bundle a= s >> well. To be specific, we need to decide between: >> >> a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and >> add a new force-bundle policy that creates an offer with a single port >> shared between all m-sections (RTP and RTCP). max-bundle remains nominal= ly >> backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it >> will still send a single audio stream. force-bundle is not backwards >> compatible with non-BUNDLE endpoints. >> >> b) Add force-bundle, but get rid of max-bundle. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --089e013cb9965c47e604f46166d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sort of. The idea is whether JSEP should have a mode which= _gathers_ only a single set of ports, in effect assuming the other side su= pports rtcp-mux. The use of a=3Drtcp is incidental here, and only used to p= oint out that the RTP and RTCP ports that are offered will be identical.


On Tue, Mar 1= 1, 2014 at 12:51 AM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:
Hi,

"BUNDLE currently mandates the usage of both the SDP rtcp= -mux and rtcp attributes. I remember we had discussions about that, but I d= on=E2=80=99t remember the justification at the moment."

[BA] The justification was that an implementation interested in multip= lexing A/V would almost certainly also want to multiplex RTP and RTCP, beca= use the motivation for both is minimizing port usage.=C2=A0

[Christer] So, again, the idea is to use a=3Drtcp to indicate the *same* po= rt as a=3Drtcp-mux indicates, and hope that the receiver supports at least = either a=3Drtcp or a=3Drtcp-mux?

Regards,

Christer



On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,<= /p>

=C2=A0

Before I comment on your = proposal, let=E2=80=99s take a few steps back (maybe it can even solve your= issue).

=C2=A0

BUNDLE currently mandates= the usage of both the SDP rtcp-mux and rtcp attributes. I remember we had = discussions about that, but I don=E2=80=99t remember the justification at the moment. But, I wonder whether that text is from before we made a de= cision that, unless both endpoints support BUNDLE, no endpoint will use a s= ingle address:port.

=C2=A0

So, the question is: do w= e really need the SDP rtcp attribute?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: 10. maaliskuuta 2014 8:18
To: rtcweb@ietf= .org; Eric Rescorla; Christer Holmberg
Subject: BUNDLE with implicit rtcp-mux

=C2=A0

In my JSEP preso during the RTCWEB session last Wedn= esday, I discussed adding a new BUNDLE policy to JSEP. This policy, which w= ould be called something like =E2=80=9Cforce-bundle=E2=80=9D, would force t= he use of the same ports for BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the other side supports BUN= DLE, this would reduce candidate gathering even over the currently defined = =E2=80=9Cmax-bundle=E2=80=9D policy, since there would be no need to gather= RTCP ports at all, and also avoid the need for the BUNDLE fixup offer (where the ports are updated to be the same for all= BUNDLEd m-sections).

To explain the differences here, here are some examp= le offers for an audio+video call:

Default bundle policy - separate ports for audio, vi= deo, RTP and RTCP:
m=3Daudio 10000
a=3Drtcp:10001
a=3Drtcp-mux
m=3Dvideo 11000
a=3Drtcp:11001
a=3Drtcp-mux

Existing "max-bundle" policy - video port = is 0 because bundle-only, but both RTP and RTCP ports allocated for audio:<= br> m=3Daudio 10000
a=3Drtcp:10001
a=3Drtcp-mux
m=3Dvideo 0
a=3Dbundle-only
a=3Drtcp-mux

The new =E2=80=9Cforce-bundle=E2=80=9D policy - only= a single set of ports allocated - audio, video, RTP, RTCP share the same p= ort.
m=3Daudio 10000
a=3Drtcp:10000
a=3Drtcp-mux
m=3Dvideo 10000
a=3Drtcp:10000
a=3Drtcp-mux

During the discussion, the ability to avoid RTCP por= t gathering was seen as valuable, but not the ability to avoid the fixup of= fer. However, after thinking about it a bit, I don=E2=80=99t think that the= re is a viable solution that avoids RTCP port gathering that *doesn=E2=80=99t* use a single set of ports. The only other= option would be to do something like this:

m=3Daudio 10000
a=3Drtcp:10000 # same as m=3Daudio port
a=3Drtcp-mux
m=3Dvideo 0
a=3Dbundle-only
a=3Drtcp-mux

but this will almost surely will result in a malfunc= tion when talking to a non-rtcp-mux client, due to the same port being used= for RTP and RTCP, and still requires the fixup offer, and as such is net w= orse than the force-bundle approach indicated above.

So I think we the force-bundle approach is the one w= e want to minimize port gathering. The only question is whether we should k= eep max-bundle as well. To be specific, we need to decide between:

a) Keep max-bundle as it is (separate RTP and RTCP p= orts allocated), and add a new force-bundle policy that creates an offer wi= th a single port shared between all m-sections (RTP and RTCP). max-bundle r= emains nominally backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it will still send a singl= e audio stream. force-bundle is not backwards compatible with non-BUNDLE en= dpoints.

b) Add force-bundle, but get rid of max-bundle.


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



--089e013cb9965c47e604f46166d1-- From nobody Tue Mar 11 21:40:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CC61A08DB for ; Tue, 11 Mar 2014 21:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 H7nPBSo2bkbQ for ; Tue, 11 Mar 2014 21:40:44 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3175D1A08D9 for ; Tue, 11 Mar 2014 21:40:44 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id lf12so3906309vcb.11 for ; Tue, 11 Mar 2014 21:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VGmDqyARrgJo5ytkCuOqbuPekLkNWOSGbxfztmQMBIA=; b=CUutB/fzzvXaSQNKN/JwWjTEPxaSgsDsqFpUa6M7WhT65LCvYUVOnFO9fX5N2pQn/m 5kfDiqszy1ztGCmTdves6PZRvIXAcAE9KNJzIELI2V3sRb4q4tBUsT+BBAVFiMMy0M7k wjdyzAAOIgALykRJyIUz4rIS+1f9mEe46KH92eKEy+tEmFhk9yqBinc5VlU9DRobUy3z cWruLd6PgWLLDM5Pnpnd3ghX4E3QA8UXyn0+QP31F/o9+/erPtEnvezZFA8idVpCgtFr ND0lDVp8E17zOVkZHREwXZWaMJ3CPa9Ky5oLnFIffO9mDItfY2dca/XcQdEJsWo2/yak s36g== 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=VGmDqyARrgJo5ytkCuOqbuPekLkNWOSGbxfztmQMBIA=; b=kxuRn9JzpdlUtJfcg+cErJ0CFoVtdQlT5LdaKhqrMWmoG26eujwbjXUiVM79Hc9XxW TISCSgQD3oeJ9ialajlntFvkr+s7yvfdriAJQ+zzhwhZ0QVb5c05xIoGZPNwe7NStuSd QWnr35eZt39qwXSmefqCQMMCtUrbIhlI0DD0dY9IE4g/E5uliB7xFMd73A0mICWGGqzM Ay1jCGzD7kvYbJgYWmkf/AEQOjC3qxFAoY6QTCqe7FXbigWkUHpgrxwA6tOhgdUpDvH9 cS+wODCFHjre+VxvLVGDvc6hSM1t3oycWJZjAOco84haf0Ge6IOKYbCVHTU7MtmqtzuU EP8w== X-Gm-Message-State: ALoCoQn75eXlK9H0VoN3IYp0DLk8tStnrwrHZhFOaC0M+muBSFTn4AvJJYyyKlZ6upfL5MBwjN+xJ/oR5LQ8IAOGrF3xYr+PKR4lh51RguFAr8xgNnFsAmMSOba++Ze30tlmh1Ymn314oiPGn0ZrumcEvzODQS4FONmuTiI8TOInsBEpY/QzXw2EO4bKd8/YsHUmRs0e5jLY X-Received: by 10.58.100.100 with SMTP id ex4mr30870533veb.2.1394599238144; Tue, 11 Mar 2014 21:40:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 11 Mar 2014 21:40:17 -0700 (PDT) In-Reply-To: References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> From: Justin Uberti Date: Tue, 11 Mar 2014 21:40:17 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b33c70631aa3a04f461705a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sTT8NyiszTL_R6r12kbDojjn0sc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 12 Mar 2014 04:40:46 -0000 --047d7b33c70631aa3a04f461705a Content-Type: text/plain; charset=UTF-8 Future versions of the API should have the knobs needed to control the CNAMEs more exactly. For WebRTC 1.0 though, scoping CNAMEs to a PeerConnection feels like a prudent simplification. On Mon, Mar 10, 2014 at 8:49 AM, Martin Thomson wrote: > On 10 March 2014 16:19, Magnus Westerlund > wrote: > > Can you please think through the linkage issue a bit first before > > changing this property. > > We already came to the conclusion that if media was being forwarded by > a peer, then that is new media originated by that peer, not the same > media. Thus, if looping occurs, it is at the application layer. We > definitely already agreed that RTP forwarding is not a function that a > browser will support. > > Obviously, if we add that feature, CNAMEs will be just one of the > manifold issues that will arise and we will have to reconsider. > Compromising the privacy of users doesn't seem like a good trade-off > against some minor advantages in terms of loop detection (unlikely) > and synchronization (easy to apply manually). > --047d7b33c70631aa3a04f461705a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Future versions of the API should have the knobs needed to= control the CNAMEs more exactly. For WebRTC 1.0 though, scoping CNAMEs to = a PeerConnection feels like a prudent simplification.


On Mon, Mar 10, 2014 at 8:49 AM, Martin = Thomson <martin.thomson@gmail.com> wrote:
On 10 March 2014 16:19, Magnus Westerlund
<magnu= s.westerlund@ericsson.com> wrote:
> Can you please think through the linkage issue a bit first before
> changing this property.

We already came to the conclusion that if media was being forwarded b= y
a peer, then that is new media originated by that peer, not the same
media. =C2=A0Thus, if looping occurs, it is at the application layer. =C2= =A0We
definitely already agreed that RTP forwarding is not a function that a
browser will support.

Obviously, if we add that feature, CNAMEs will be just one of the
manifold issues that will arise and we will have to reconsider.
Compromising the privacy of users doesn't seem like a good trade-off against some minor advantages in terms of loop detection (unlikely)
and synchronization (easy to apply manually).

--047d7b33c70631aa3a04f461705a-- From nobody Tue Mar 11 22:11:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7E81A04A3 for ; Tue, 11 Mar 2014 22:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0leEcJWxqYE for ; Tue, 11 Mar 2014 22:11:29 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id C83311A07D5 for ; Tue, 11 Mar 2014 22:11:29 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so25826403ykq.7 for ; Tue, 11 Mar 2014 22:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N7xhvHqzuFQz867EeiEV79EEBwkj22FfYocjdd9eNQI=; b=wiXgeVsktVGkjwo+8cuNMpTpCvqmHY4vo75nn1vAoJHQRZeVi0cCls9D9CX2lLs24a xAzUjNWl+JLa+rrKXHjcvJrb/O4OUDhw8cxlZQd98rc9rNWrh943T8BxCjfZkTxhSnWV dJqR7nROG4+0KIv0gNnQxGBU7cEm07VzoVujOL1VDk2PnM1Sd6SPozmwyse4/UIxg0aT JnUVUIkm0HMUqWJwxTk0Az7DJrL7H4aaKt8fjWPzPb3ik/JkCTtxf5LiwmGEMqRRTAEh 82DIb39B1yK7cU4Ws5hlNM5bCoCzbzmg7zF9M2HKiZB/s6wVR4PB3IMP7MyDn1Rv/Zah oGeQ== MIME-Version: 1.0 X-Received: by 10.236.150.68 with SMTP id y44mr114848yhj.113.1394601083762; Tue, 11 Mar 2014 22:11:23 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Tue, 11 Mar 2014 22:11:23 -0700 (PDT) Date: Tue, 11 Mar 2014 22:11:23 -0700 Message-ID: From: Watson Ladd To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf303a3183337dca04f461deac Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2iF8qIN65vCRqTWDbxNphB9fZgo Subject: [rtcweb] Areas of security concern 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, 12 Mar 2014 05:11:36 -0000 --20cf303a3183337dca04f461deac Content-Type: text/plain; charset=UTF-8 Dear all, I've jotted down the following notes when reading the drafts from here and the W3C as potential problem areas. Maybe there are things I've missed in the drafts that address them, but I think they are still worth thinking about. Some of these are more W3C, but we seem to be in charge of the security. These issues vary widely in seriousness. One of them is a demonstrated break of confidentiality, while several are open questions about how we communicate to users. Problem 1: Which John Smith? Currently IdPs link attributes to identities. But the way in which identities are presented to the user can be misleading. Names are not unique. Do we need a way for an IdP to indicate more about the identity? Should IdPs be allowed to use social graph information, e.g. prevent me from calling people who I don't "friend" on a social network, and thus avoid the wrong John Smith? How does this information get handled? Who decides what policy is being used? Problem 2: IdP pointy bits An IdP has to cryptographically bind a username to some data. It would be nice if we could come up with a secure method to do this, and have the browser take care of it for the identity provider as much as possible, instead of everyone having to do it themselves in likely wrong ways. The webcrypto API has been roundly critiqued as being too low-level. Problem 3: Renegotiation The DTLS handshake being used is specified in RFC 4347. In particular, I don't see anything about the renegotiation bug being fixed. This enables an unknown key-share attack in which A thinks they are transmitting video to B, but really are transmitting it to C who knows that they are talking to A. Problem 4: HMAC-SHA1 in SRTP If I've chased the chain of references correctly this is the sole MAC provided. Is it okay? I have no idea: SHA-1 has been significantly weakened in recent years. Problem 5: What you see is not what I sent This is an area that is somewhat underspecified, depending as it does on the media API's capabilities. The video frame could be silently replaced by a different video frame with rather different contents. Any authentication of the contents of the video frame would not carry over, but if the contents were sufficiently shocking/subtle this might not be noticed. Authentication independent of the website offering the video chat makes this attack worse, because users will trust what they see more. Isolation doesn't help because this is wholesale replacement, not editing. Most uses of this attack are for puerile purposes. I don't think it's a big concern. Then again I could be very, very wrong. Problem 6: General UI issues Currently quite a bit of the security model depends on UI presentations of subtly different states. I don't know how well users will understand this, or how well the UI will work. Past experience suggests not well. Luckily we can mostly change this later/it isn't part of standardisation. Problem 7: VBR privacy leaks I can do no better then to refer to the paper. http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-can.pdfSpoken phrases could be identified from encrypted data alone, using a Hidden Markov Model when the length of packets was preserved by the encryption. Conclusion: Some of these issues result from well-known problems in older protocols. Others are longstanding difficult problems that have to be solved. Some are quite dangerous, while others will only permit the occasional prank. However, it is not enough to fix these specifically. Large areas of the proposal have not been explored by me. If I had to rate these by seriousness, problem 3 and 7 are the worst. They are luckily the easiest to fix. Sincerely, Watson Ladd --20cf303a3183337dca04f461deac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,
I've jotted down the following notes when= reading the drafts from here and the W3C as potential problem areas. Maybe= there are things I've missed in the drafts that address them, but I th= ink they are still worth thinking about. Some of these are more W3C, but we= seem to be in charge of the security. These issues vary widely in seriousn= ess. One of them is a demonstrated break of confidentiality, while several = are open questions about how we communicate to users.

Problem 1: Which John Smith?

Currently IdPs link attributes to i= dentities. But the way in which identities are presented to the user can be= misleading. Names are not unique. Do we need a way for an IdP to indicate = more about the identity? Should IdPs be allowed to use social graph informa= tion, e.g. prevent me from calling people who I don't "friend"= ; on a social network, and thus avoid the wrong John Smith? How does this i= nformation get handled? Who decides what policy is being used?

Problem 2: IdP pointy bits

An IdP has to cryptographically bind = a username to some data. It would be nice if we could come up with a secure= method to do this, and have the browser take care of it for the identity p= rovider as much as possible, instead of everyone having to do it themselves= in likely wrong ways. The webcrypto API has been roundly critiqued as bein= g too low-level.

Problem 3: Renegotiation

The DTLS handsha= ke being used is specified in RFC 4347. In particular, I don't see anyt= hing about the renegotiation bug being fixed. This enables an unknown key-s= hare attack in which A thinks they are transmitting video to B, but really = are transmitting it to C who knows that they are talking to A.

Problem 4: HMAC-SHA1 in SRTP

I= f I've chased the chain of references correctly this is the sole MAC pr= ovided. Is it okay? I have no idea: SHA-1 has been significantly weakened i= n recent years.

Problem 5: What you see is not what I sent
This is an area that is somewhat underspecified, depending as = it does on the media API's capabilities. The video frame could be silen= tly replaced by a different video frame with rather different contents. Any= authentication of the contents of the video frame would not carry over, bu= t if the contents were sufficiently shocking/subtle this might not be notic= ed. Authentication independent of the website offering the video chat makes= this attack worse, because users will trust what they see more. Isolation = doesn't help because this is wholesale replacement, not editing.

Most uses of this attack are for puerile purposes. I do= n't think it's a big concern. Then again I could be very, very wron= g.

Problem 6: General UI issues

Currently quite a bit of the security model depends on UI presen= tations of subtly different states. I don't know how well users will un= derstand this, or how well the UI will work. Past experience suggests not w= ell. Luckily we can mostly change this later/it isn't part of standardi= sation.

Problem 7: VBR privacy leaks

=
I can do no better then to refer to the paper.=C2=A0http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-= can.pdf Spoken phrases could be identified from encrypted data alone, u= sing a Hidden Markov Model when the length of packets was preserved by the = encryption.

Conclusion:
Some of these issues result from = well-known problems in older protocols. Others are longstanding difficult p= roblems that have to be solved. Some are quite dangerous, while others will= only permit the occasional prank. However, it is not enough to fix these s= pecifically. Large areas of the proposal have not been explored by me. If I= had to rate these by seriousness, problem 3 and 7 are the worst. They are = luckily the easiest to fix.

Sincerely,
Watson Ladd
--20cf303a3183337dca04f461deac-- From nobody Wed Mar 12 00:52:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A259D1A090D for ; Wed, 12 Mar 2014 00:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnsu6mQgXvxM for ; Wed, 12 Mar 2014 00:52:30 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1B71B1A08EB for ; Wed, 12 Mar 2014 00:52:29 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-69-53201237b22d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.5F.04249.73210235; Wed, 12 Mar 2014 08:52:23 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 08:52:22 +0100 Message-ID: <53201236.40702@ericsson.com> Date: Wed, 12 Mar 2014 08:52:22 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvja65kEKwwa1NwhZbpwpZrP3Xzm7R vfQ/iwOzx4JNpR5Llvxk8lj3wTyAOYrLJiU1J7MstUjfLoErY1HDIZaCh+IV3fNrGxhPC3Ux cnJICJhIrPx3gRXCFpO4cG89WxcjF4eQwBFGiZ1LjjNBOMsZJY4vvw5WxSugKTF/3Rwgm4OD RUBV4u8cdpAwm4CFxM0fjWwgtqhAsMTOA78ZIcoFJU7OfMICYosIqEk8nLULbAyzQITE8v5n YPXCAkYSt1bfZobYdZpVYtLzlWDNnAKBEjObljCC7JIQEJfoaQyC6NWUaN3+mx3Clpdo3jqb GcQWEtCWaGjqYJ3AKDQLyepZSFpmIWlZwMi8ipGjOLU4KTfdyGATIzBwD275bbGD8fJfm0OM 0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgLLbbY3FfwcyOY9/NDu0zS9/z LJqjuOZ47cq9h+4FzBVPa2Bf26Cw68r1eynSUr0SqaanqxbOqUlfOenqTrH1Bx6u/+Gq6Xun Xc2NVb3Lf1F9juK32Yu7dhtWZd5z+fJm7xI9Z+P3zKbBSx+lhhhX5C9lWqn26cubRRPlluQd PtvQtmepQcOvECWW4oxEQy3mouJEAKc65Q0qAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n5RAZjgvaRlFhZeJb41nE-6YyEM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 12 Mar 2014 07:52:32 -0000 On 2014-03-12 01:58, Justin Uberti wrote: > The reason I suggested SHOULD NOT is because I think this technique is > unnecessary for WebRTC, and typically net harmful for the reasons that > Matthew mentions. > > That said, I would be fine with saying MAY and including some > explanatory text; my main concerns was to avoid the ambiguity that would > arise from leaving this out altogether. Okay, as we have considerations, I would leave the RFC 2119 terms out. I think a statement along the lines of the below might be most suitable. Using TURN to provide TCP relay candidates [REF] was considered but not seen as providing any significant benefit. First, use of TURN TCP would only be relevant in cases which both peers requires to use TCP to establish a PeerConnection. Secondly, that use case is anyway supported by both side establishing UDP relay candidates using TURN over TCP [REF]. Thirdly, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking. Please provide feedback or word smith. Cheers Magnus (As individual) > > > On Mon, Mar 10, 2014 at 8:33 AM, Magnus Westerlund > > > wrote: > > On 2014-03-06 14:34, Simon Perreault wrote: > > Le 2014-03-06 13:23, Justin Uberti a écrit : > >> can we agree that TURN TCP candidates are a SHOULD NOT? > > > > Not a SHOULD, sure. SHOULD NOT, no. > > > > I would guess that the simplest is to remove discussion of TURN TCP > altogether from Transports. That would not recommend it nor make it > disallowed. If we want to be explicit, then simply motivate why we don't > believe it necessary. > > Justin, what is the reason you wanted SHOULD NOT? > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 12 01:03:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919D31A0913 for ; Wed, 12 Mar 2014 01:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 iWzD9_GaZLul for ; Wed, 12 Mar 2014 01:03:28 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7961A0910 for ; Wed, 12 Mar 2014 01:03:27 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-92-532014c9d36b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 9C.9F.04853.9C410235; Wed, 12 Mar 2014 09:03:21 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 09:03:20 +0100 Message-ID: <532014C8.2050908@ericsson.com> Date: Wed, 12 Mar 2014 09:03:20 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti , Simon Perreault References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvje5JEYVgg4Y2MYutU4Us1v5rZ7fo XvqfxYHZY8GmUo8lS34yeaz7YB7AHMVlk5Kak1mWWqRvl8CVMf+tS8FBpYrHT6YxNjC+lupi 5OCQEDCR6Prh2sXICWSKSVy4t56ti5GLQ0jgBKNEy+Eb7CAJIYHljBILH4eC2LwC2hILNi9m A7FZBFQltjT9B7PZBCwkbv5oBLNFBYIldh74zQhRLyhxcuYTFhBbRCBcYsr7LmYQm1lAXeLO 4nNg84UFjCWW/t3PDLF4JZPE08szwBo4BQIl7jx7yg5xqLhET2MQRK+exJSrLYwQtrxE89bZ zBB3aks0NHWwTmAUmoVk9SwkLbOQtCxgZF7FKFmcWlycm25koJebnluil1qUmVxcnJ+nV5y6 iREY2Ae3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFU2 Ox09FXbmmLWCcMkZPt0TCccstgoYxOQt/B0/ReQ4r+KjYOkrc4PMSxxmfjXoU/B3v1PU+GCt a4HW/u+/98pmrL3btkB1cnyj0rSrPpHtxy/1hzUuFjQT6DjwtKrqMq9zaepSpk9bXb2Vcz0/ vsz81VVS9Mlj88Vg1Q0/Nr5Z/UPKf6lBhRJLcUaioRZzUXEiAITC05s6AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ylMbyy8Lsp-hwQ9GBjK3v4ltNRQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 12 Mar 2014 08:03:29 -0000 On 2014-03-12 04:53, Justin Uberti wrote: > > > > On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault > > wrote: > > Le 2014-03-10 16:57, James Polk a écrit : > > At 12:16 AM 3/10/2014, Justin Uberti wrote: > >> I think that the existing guidance should be sufficient in > >> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the > >> same DSCP markings as any other ICE connectivity checks should be > >> used; for ICE-for-SCTP checks, the same DSCP markings as media > packets > >> (i.e. the SCTP traffic) should be used. > >> > >> If multiplexing is being performed, the connectivity checks probably > >> should use the highest DSCP value being used by the multiplexed > media. > > > > why is (seemingly) everyone's default position "use the highest DSCP > > available" for signaling packets? > > > > You just need to make sure the packets aren't starved or dropped by/at > > congestion points. > > The underlying principle is that connectivity checks need to *check > connectivity* (duh!). That's why you use the same DSCP as the media. > Connectivity is affected by the DSCP. For example some DSCPs could be > filtered, or could be placed in a low-priority queue and get dropped > such that connectivity fails. > > >From this principle follows this conclusion: on a given 5-tuple, if > your > media uses different DSCPs, you need to check connectivity for all those > DSCPs. That is, you would send multiple connectivity checks, one for > each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might > need an alternative heuristic: try the lowest-priority DSCP, and assume > that if that one works, the higher-priority ones should work as well. > (Note that Justin suggested the contrary.) > > What you want to avoid is STUN packets getting through but not the > corresponding media. That is an unworkable situation. The reverse is not > ideal either (you think you have no connectivity when in fact you do), > but at least ICE can work around it (by picking a different candidate). > > > We also need to consider the scenario of STUN consent checks, which will > need to get through reliably even when media marked with DSCP is already > flowing. In this case I think that using the highest DSCP value for STUN > is unavoidable. > (as individual) Sorry, I don't understand your reasoning here. Is it to provide the lowest possible drop probability, i.e. using the AFx class that has least drop probability? If there exist nodes that stomp on some DSCP markings, and not only remark them to Best Effort (BE), and instead drop then. Then, it is not obvious that that an AFx class is the most appropriate to use. In that case using BE might be more suitable for the consent freshness. I would also point out that highest DSCP value isn't clear. We are talking about forwarding behavior and I don't see how Expedited Forwarding (EF) can be compared with AF for example. I think we have to consider what our goals are here. To determine if we can get any packets through or determine if a particular 6-tuple (Source Address, Destination Address, Source Port, Destination Port, Protocol, and DSCP value) works? If it is the later then I think we need to have checks running on all the 6-tuples in use. This clearly have overhead concerns and helps worsening the ICE The Voice Hammer Attack (See section 18.5.1. of RFC 5245). If the goal is the first, isn't using BE a reasonable choice. Yes, it might have higher drop probability than AF, but it is likely to be robuster in general deployments and it determine if the peer is there or not. Dealing with broken 6-tuples needs to be a separate issue. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 12 01:16:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE001A090D for ; Wed, 12 Mar 2014 01:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 ctfqM8CnBcac for ; Wed, 12 Mar 2014 01:16:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 66C781A08FA for ; Wed, 12 Mar 2014 01:16:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-3f-532017dd77e5 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 74.55.23809.DD710235; Wed, 12 Mar 2014 09:16:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 09:16:28 +0100 Message-ID: <532017DD.1060500@ericsson.com> Date: Wed, 12 Mar 2014 09:16:29 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RveuuEKwwboLRhYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8biR5EFG0wrLm46y9bAeFGr i5GTQ0LARGLn1WVsELaYxIV764FsLg4hgUOMEp0rN7BDOMsZJdpuvGEFqeIV0Jb4euM9M4jN IqAqcX/PLHYQm03AQuLmj0awSaICwRI7D/xmhKgXlDg58wkLyCARgYWMEtsvb2YBSQgLGEsc uryUGWLDFmaJO9cvgSU4Bfwk1v3bB5TgALpJXKKnMQgkzCygJzHlagsjhC0v0bx1NtgRQkAH NTR1sE5gFJyFZN8sJC2zkLQsYGRexciem5iZk15utIkRGKQHt/xW3cF455zIIUZpDhYlcd4P b52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCWdEx5lHPwrF6b5qHn239E9zqVuq5MPSyk HzlV9UAV58S91j+tU/31b6okmzy4bhX9VOORQ3TkU0ub50cDo5WvKM7QvC14Z1blWYZ9+gIh Pv/KqwN7dv1zCa8ovtgov3Wf3cK370+KJwsIZxzezFfX/evU7+z/qc8mi5+6OTPb4ILMi6d+ +5crsRRnJBpqMRcVJwIAAugHxCACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Nn6a6lFkRMWF-9CEBKNMD5XkmBQ Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 12 Mar 2014 08:16:39 -0000 On 2014-03-10 21:09, Christer Holmberg wrote: > Hi, > >>>>>>> Before I comment on your proposal, let's take a few steps >>>>>>> back (maybe it can even solve your issue). >>>>>>> >>>>>>> BUNDLE currently mandates the usage of both the SDP >>>>>>> rtcp-mux and rtcp attributes. I remember we had >>>>>>> discussions about that, but I don't remember the >>>>>>> justification at the moment. But, I wonder whether that >>>>>>> text is from before we made a decision that, unless both >>>>>>> endpoints support BUNDLE, no endpoint will use a single >>>>>>> address:port. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So, the question is: do we really need the SDP rtcp >>>>>>> attribute? >>>>>> >>>>>> I think it is a question of how you want the fallback to >>>>>> work. In the case of bundle only lines, a non bundle >>>>>> supporting peer will reject them, thus no issues with what >>>>>> is written around RTCP-mux and a=rtcp in those m= blocks. >>>>>> However, the first one if you want that to support fallback >>>>>> that makes sense then you will need both a=rtcp-mux and an >>>>>> a=rtcp (with a different port) to handle that with optimal >>>>>> backwards compatibility. >>>>>> >>>>>> Regarding the motivation for a=rtcp-mux and a=rtcp, I think >>>>>> it is reasonably straight forward. We want a=rtcp-mux to >>>>>> minimize port usage, i.e. ports=1. Not supporting >>>>>> a=rtcp-mux with bundle that would mean two ports (RTP and >>>>>> RTCP) for the bundle group. To get the backwards >>>>>> compatibility the usage of a=rtcp would be required. >>>>> >>>>> Keep in mind that the offerer must always be prepared that >>>>> the answerer does not support the rtcp-mux attribute (or the >>>>> rtcp attribute). >>>> >>>> Yes, that was what I meant with fallback in the above text. >>>> What you do in case the peer doesn't support bundle. >>>> >>>>> So, at least my understanding is: no matter whether BUNDLE is >>>>> used or not, if the answer does not contain a rtcp-mux (e.g. >>>>> in case of fallback) attribute, the offerer must use the >>>>> default "rtp+1" port. >>>> >>>> I have a tendency to agree, which means that the first m= block >>>> in a bunde-only group will be required to contain a=rtcp and if >>>> RTCP mux is desired also that attribute. >>>> >>>> I think a=rtcp could be skipped for a bound-only m= block due >>>> to the requirement on supporting a=rtcp-mux if you do bundle. >>> >>> For bundle-only, I actually think BOTH can be skipped, because >>> bundle-only will by default use whatever address:port is >>> negotiated - both for RTP and RTCP. >> >> No, I see a path of grief to not explicitly signal things when you >> use them. > > But, the whole idea of using port zero in bundle-only was that, if > the answerer supports BUNDLE, port zero will be replaced with the > negotiated address:port. > > When you send the offer, you don't yet know which address:port will > be selected, so there is no idea to insert a=rtcp. Inserting > a=rtcp-mux probably doesn't harm, though, so I won't argue about it > :) Well, if you can't insert the port, the same applies to a=rtcp as to the port in the m= line. Because in the bundle-only case we are assuming and that assumption needs to apply also for a=rtcp. And for a bundle-only case I think the appropriate thing is to assume that a=rtcp-mux will be honored. To have it being honored you need explicit signal it. The a=rtcp can be considered redundant in this case, but I am sensitive to removing it as that would create a special case for a=bundle-only lines. I think it is better to simply include it, even if it will say a=rtcp:0 > >> I also thought the a=rtcp-mux is a MUST to implement, not a MUST >> use. > > Currently the draft says MUST use. But, that may be a mistake, or a > leftover from previous procedures. I agree that one should be able to > use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports > for the RTP traffic and the RTCP traffic). I hope if people disagree that they shout now. > >>> But, for non-bundle-only, I still ask whether we really need >>> a=rtcp. Isn't a=rtcp-mux enough? If the answerer supports it, you >>> will use it, otherwise you will use rtp+1. >> >> My understanding is that a=rtcp has been required in any >> non-private network deployments due to >NATs for the last 10 years. >> Thus, I don't see how you can remove them and expect it to work, >> unless >you are doing a=rtcp-mux. Thus, my view would be that you >> can remove a=rtcp if you know that the >peer supprots a=rtcp-mux. > > Are you saying that we should use a=rtcp ONLY to indicate the RTP > port, in case the answerer does not support a=rtcp-mux? It has its normal usage, i.e. RTCP port in cases when a=rtcp-mux is not agreed on. In a bundle-only offer, I think the only reasonable approach is to handle it identically to the m= line port number. > >>> Otherwise, assume that the answerer supports BOTH a=rtcp and >>> a=rtcp-mux. Which has higher "priority"? How does the answerer >>> knows whether the offerer wants to use rtcp-mux, or whether it >>> wants to use whatever port is indicated in a=rtcp? >> >> That is a=rtcp-mux per RFC 5761 that has higher priority, please >> see Section 5.1.1. > > You are right - my mistake. > > But, never the less, if the offerer sends both a=rtcp-mux and a=rtcp, > unless a=rtcp points to the rtp port, the offerer needs to be > prepared to use 3 different ports for RTCP (rtp+1 port, rtp port and > rtp+), because it does not know which attribute (if > any) the answerer supports, and which (if any) the answerer is > willing to use. This is actually not necessary, if one can get the rtp+1 port for RTCP, then include that in the a=rtcp line and everything is fine. I was under the impression that almost all SIP SDP O/A was using a=rtcp. But if that is a misunderstanding from my perspective, I still think the rules will hold. If you don't include the a=rtcp attribute, then the rtp+1 port is the equivalent of the a=rtcp value. >From a bundle perspective, I think what needs to be considered is the actual or implied values on the m= blocks for the rtcp port when using bundle-only as well as the other case. Cheers Magnus Westerlund (As individual) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 12 01:29:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D391A0916 for ; Wed, 12 Mar 2014 01:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xj6YVATXrGj for ; Wed, 12 Mar 2014 01:29:43 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CEACE1A090D for ; Wed, 12 Mar 2014 01:29:42 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-93-53201af095f4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A3.45.04249.0FA10235; Wed, 12 Mar 2014 09:29:36 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 09:29:35 +0100 Message-ID: <53201AEF.6090501@ericsson.com> Date: Wed, 12 Mar 2014 09:29:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje4HKYVggwN/RS22ThWyuHbmH6PF 2n/t7A7MHjtn3WX3WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBmP5l1kL3guWnF4x3nmBsbH gl2MnBwSAiYS93e+ZIawxSQu3FvP1sXIxSEkcIRRYv/CeYwQznJGiUnfIKp4BbQlnk54BWaz CKhK9Lyaxg5iswlYSNz80cgGYosKBEvsPPCbEaJeUOLkzCcsILaIgK7EorMPwOqZBbwlPi2C sIUFrCSeHD7AArFsCbPEg5bFYAlOgUCJfct2Ay3jADpPXKKnMQiiV1OidftvqDnyEs1bZ4Pd IwR0W0NTB+sERqFZSFbPQtIyC0nLAkbmVYwcxanFSbnpRgabGIHhe3DLb4sdjJf/2hxilOZg URLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDowWz+B2Ry/85xHcEaK3sz3S8wrrh eJ7IlmezppzX/DWDb/27eYJ6XwWPzGBxr8u9Umz7LXiTau71j+pvmg9m8q/vmrnpaoZLRIX5 pHzxA5df+rr4NF48mLHD7W/hiTlXz1v/2eD/ceWzt06JkbX31FakM7jFNyzNOW+bIad68G52 u7FRwwLJR0osxRmJhlrMRcWJALLkN+MtAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vVQnC1o0X12DPFg9OMqCFgLxBo4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 12 Mar 2014 08:29:45 -0000 On 2014-03-10 16:49, Martin Thomson wrote: > On 10 March 2014 16:19, Magnus Westerlund > wrote: >> Can you please think through the linkage issue a bit first before >> changing this property. > > We already came to the conclusion that if media was being forwarded by > a peer, then that is new media originated by that peer, not the same > media. Thus, if looping occurs, it is at the application layer. We > definitely already agreed that RTP forwarding is not a function that a > browser will support. I like to point out that the agreement and what is documented in rtp-usage is that WebRTC endpoint will have to make forwarded streams appear as locally originated. However, this as currently written does not apply to RTP middleboxes that interconnects multiple PeerConnections to form a multi-party session. This is deliberate to ensure that RTP topologies like RTP mixer and SFM do work on the RTP/RTCP level. > > Obviously, if we add that feature, CNAMEs will be just one of the > manifold issues that will arise and we will have to reconsider. > Compromising the privacy of users doesn't seem like a good trade-off > against some minor advantages in terms of loop detection (unlikely) > and synchronization (easy to apply manually). I am especially interested to know how you will "easy to apply manually" the synchronization. Can you please describe that. Because, that either requires an API call to tell the media framework, please consider the following CNAMES as equivalent, or some other method of telling the media framework that these different MST are actually originating from a common clock base. I protested about this, not to lower the users privacy, but over the concern that this was raised without providing a case where it was obvious that the user's privacy was impacted. Martin, you said that you would think about it, and the next statement was lets change it, without providing any motivation why the concern was significant. >From my perspective, if you can provide a good explanation how to actually accomplish the synchronization, I think a change of scoping the CNAME to a PeerConnection is okay. But, I would like to understand how you believe it is accomplished. Magnus Westerlund (As RTP-usage author) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 12 01:35:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BF51A091F for ; Wed, 12 Mar 2014 01:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSgmnyWv1AxE for ; Wed, 12 Mar 2014 01:35:36 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7A51A0915 for ; Wed, 12 Mar 2014 01:35:36 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so1987660wib.16 for ; Wed, 12 Mar 2014 01:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kxKRj2Jkign9Jl1xk2vG1qbNYDbKHA1DVoFkHjRsBm8=; b=KYvUd4VE6FiyNYz33zgfDiMZJZyZLX6Q+pV3Wmn0ShufP2Nih2ZGgmoEl3dNqeNkpE /IgCG3av9yYr/md4YQ/sKXpR/LrH3WbnbnEhb4RS7gIivVoboA48FYJXv6hlW80EYisa abWjFRf4Eeo875CJevhH5UQ7B/jMLOM0Us+Jnh8PJCO7DVuUoELzKskonIbKnopkp2dr Rz+QATAy21uqbyX4inSlGsPrJFHFXKxq/TIyx0P1uxFAPZpC7XV3YO6sJrsjDcHfL7PM yYRJavpvZ9gejMq3Ov77v7qVPYqxOAVsScxq5yxLXju/MQaooHQ1lsRpkxxDGCGd14pB FD3g== MIME-Version: 1.0 X-Received: by 10.194.63.145 with SMTP id g17mr191298wjs.72.1394613329985; Wed, 12 Mar 2014 01:35:29 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Wed, 12 Mar 2014 01:35:29 -0700 (PDT) In-Reply-To: References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <531F212A.4040102@alvestrand.no> Date: Wed, 12 Mar 2014 08:35:29 +0000 Message-ID: From: Dave Taht To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Dw5dxYYVU5fR_IDMgMkQovJDnms Cc: Keith Winstein , "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 12 Mar 2014 08:35:39 -0000 On Wed, Mar 12, 2014 at 3:55 AM, Justin Uberti wrote: > > > > On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht wrote: >> > >> > Whether that always translates to "the highest DSCP code point" is ...= . >> > a good question. >> >> It doesn't. Keith added af42 support to mosh last year and had several >> reports of packets being dropped with that marking. Worse the drops happ= ened >> after 10 seconds of connectivity. >> >> Ecn markings on the other hand have thus far survived (if occasionally >> stomped on) across the open internet in that protocol. > > > This is a concern of mine as well, which is why we haven't yet flipped th= e > switch to turn DSCP on by default in Chrome. I think we'll need to do som= e > experimentation to see how often DSCP makes things worse. Well, while I'm at this, I note that how linux handles DSCP in WIFI 802.11e is generally suboptimal. the CS6 and CS7 bit patterns map to the VO queue which is not aggregatable in wireless-n, CS4 and CS5 map to the VI queue which has a lot of good properties for videoconference and voice traffic (but limited aggregation), and CS1 and CS2, which map to the background queue, which has good aggregation but limited txops. I no longer have the bit patterns for AFxx memorized, but basically all that was returned to the 802.11e classifier was dscp >> 5 up until very recently. Lastly, there really is no interpretation whatsoever of the AF classes equating to "drop probability" in wifi (at least in lnux), they mer= ely control queue selection and it is generally better with wireless-n to aim for better aggregation in one queue rather than using multiple queues as the cost of acquiring the media dominates. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Wed Mar 12 01:47:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DA81A092C for ; Wed, 12 Mar 2014 01:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=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 cGXnRsQiSNbA for ; Wed, 12 Mar 2014 01:47:18 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0A1A0927 for ; Wed, 12 Mar 2014 01:47:17 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-88-53201f0fe52c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5E.48.04249.F0F10235; Wed, 12 Mar 2014 09:47:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Wed, 12 Mar 2014 09:47:10 +0100 From: Christer Holmberg To: Magnus Westerlund , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAABUUUA== Date: Wed, 12 Mar 2014 08:47:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D20A684@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> In-Reply-To: <532017DD.1060500@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjS6/vEKwwfdDghYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV0bLtT+sBXPVK54vcWlgnCbf xcjJISFgIvF6/UJGCFtM4sK99WxdjFwcQgJHGCV6zzewQzhLGCX+zV4MVMXBwSZgIdH9Txsk LiKwkFHi5ccDLCDdwgLGElM6J7OB2CJAU+dOfM0CYWdJXHm9HMxmEVCV+DP1MVgNr4CvxKsZ axkhFjxhlrjR+oMJJMEpoCPRcOIbmM0IdNL3U2vAbGYBcYlbT+YzQZwqILFkz3lmCFtU4uXj f6wgx0kIKEos75eDKNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoOgvJ1FlIWmYhaZmFpGUB I8sqRo7i1OKk3HQjg02MwOg4uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoHxxlo+9QVxrT2NFUuNGvccZen2arn3PZrl9K1lK9h65n/7P2XaxElb0l4r B20UjH/UaO9RclPr/MW3q2wTFVhkFPmOBnwMWXR7f8uBWi7pya8niVU66q60i1+8mnlBz7Qr vpWb3zSvzuXL8H7rIZi6vmzKUUtzjlm9bqeqJNdu7ZuxequToPcCJZbijERDLeai4kQAih5L tVwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vGfo6ZcDfoh2seUK1lkQKQqLIHM Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 12 Mar 2014 08:47:20 -0000 Hi, >> But, the whole idea of using port zero in bundle-only was that, if the=20 >> answerer supports BUNDLE, port zero will be replaced with the=20 >> negotiated address:port. >>=20 >> When you send the offer, you don't yet know which address:port will be=20 >> selected, so there is no idea to insert a=3Drtcp. Inserting a=3Drtcp-mux= =20 >> probably doesn't harm, though, so I won't argue about it >> :) > > Well, if you can't insert the port, the same applies to a=3Drtcp as to th= e port in the m=3D line. Exactly.=20 The bundle-only m- lines will "inherit" the port that is selected for the w= hole BUNDLE group. > Because in the bundle-only case we are assuming and that assumption needs= to apply also for a=3Drtcp. And for a bundle-only case=20 > I think the appropriate thing is to assume that a=3Drtcp-mux will be hono= red. To have it being honored you need explicit signal it.=20 Sure. But, the important thing is to include a=3Drtcp-mux in the m- line th= at will be used for selecting the BUNDLE address. That will determine wheth= er rtcp-mux will be used or not. > The a=3Drtcp can be considered redundant in this case, but I am sensitive= to removing it as that would create a special case for a=3Dbundle-only lin= es. I think it is better to simply include it, even if it will say a=3Drtcp= :0 We can do that, if people think it's a good idea. >>> I also thought the a=3Drtcp-mux is a MUST to implement, not a MUST use. >>=20 >> Currently the draft says MUST use. But, that may be a mistake, or a=20 >> leftover from previous procedures. I agree that one should be able to=20 >> use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports for=20 >> the RTP traffic and the RTCP traffic). > > I hope if people disagree that they shout now. And shout loud :) >>>>> But, for non-bundle-only, I still ask whether we really need a=3Drtcp= .=20 >>>>> Isn't a=3Drtcp-mux enough? If the answerer supports it, you will use= =20 >>>>> it, otherwise you will use rtp+1. >>>>=20 >>> My understanding is that a=3Drtcp has been required in any non-private= =20 >>> network deployments due to >NATs for the last 10 years. >>> Thus, I don't see how you can remove them and expect it to work,=20 >>> unless >you are doing a=3Drtcp-mux. Thus, my view would be that you can= =20 >>> remove a=3Drtcp if you know that the >peer supprots a=3Drtcp-mux. >>=20 >> Are you saying that we should use a=3Drtcp ONLY to indicate the RTP=20 >> port, in case the answerer does not support a=3Drtcp-mux? > > It has its normal usage, i.e. RTCP port in cases when a=3Drtcp-mux is not= agreed on. In a bundle-only offer, I think the only reasonable approach is= to handle it identically to the m=3D line port number. I don't know what you mean by "bundle-only offer". There must exist at leas= t one non-bundle-only m- line in an offer, in order to indicate the port va= lue. And, whatever a=3Drtcp value is used in that m- line will also be appl= ied to the bundle-only m- lines is the BUNDLE group is accepted. =20 >>>> Otherwise, assume that the answerer supports BOTH a=3Drtcp and=20 >>>> a=3Drtcp-mux. Which has higher "priority"? How does the answerer knows= =20 >>>> whether the offerer wants to use rtcp-mux, or whether it wants to=20 >>>> use whatever port is indicated in a=3Drtcp? >>>=20 >>> That is a=3Drtcp-mux per RFC 5761 that has higher priority, please see= =20 >>> Section 5.1.1. >>=20 >> You are right - my mistake. >>=20 >> But, never the less, if the offerer sends both a=3Drtcp-mux and a=3Drtcp= ,=20 >> unless a=3Drtcp points to the rtp port, the offerer needs to be prepared= =20 >> to use 3 different ports for RTCP (rtp+1 port, rtp port and >> rtp+), because it does not know which attribute (if >> any) the answerer supports, and which (if any) the answerer is willing=20 >> to use. > > This is actually not necessary, if one can get the rtp+1 port for RTCP, t= hen include that in the a=3Drtcp line and everything is fine. > > I was under the impression that almost all SIP SDP O/A was using a=3Drtcp= . > But if that is a misunderstanding from my perspective, I still think the = rules will hold. If you don't include the a=3Drtcp attribute, then the > rtp+1 port is the equivalent of the a=3Drtcp value. > > From a bundle perspective, I think what needs to be considered is the act= ual or implied values on the m=3D blocks for the rtcp port when using bundl= e-only as well as the other case. It may be that we agree, but talk past each other :) My understanding of bundle-only has been that it is a mechanism to ensure t= hat the m- line is accepted only if the BUNDLE group is accepted, e.g. in o= rder to avoid having to reserve extra ports. BUT, the bundle-only m- lines = are NOT used to negotiate the actual BUNDLE address - they will inherit the= selected BUNDLE address, negotiated using non-bundle-only m- lines. Regards, Christer From nobody Wed Mar 12 02:04:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3772F1A092A for ; Wed, 12 Mar 2014 02:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=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 84F-opQuh-rO for ; Wed, 12 Mar 2014 02:04:35 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id A7BD41A092E for ; Wed, 12 Mar 2014 02:04:34 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-91-5320231bdf7a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 60.D9.04853.B1320235; Wed, 12 Mar 2014 10:04:27 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 10:04:27 +0100 Message-ID: <5320231B.5000008@ericsson.com> Date: Wed, 12 Mar 2014 10:04:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D20A684@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D20A684@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvja60skKwwfYr1hYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8bhO6uYC2ZyVxxYs4qtgbGD s4uRk0NCwETix+v1zBC2mMSFe+vZuhi5OIQETjBK3Fv0gRUkISSwnFGibbEliM0roC3xbmc7 E4jNIqAqcfzVbUYQm03AQuLmj0Y2EFtUIFhi54HfjBD1ghInZz5hARkqIrCQUWL75c0sIAlh AWOJQ5eXMkNsm8YisX71d7AEp4CfxIdFR4ESHEAniUv0NAaBhJkF9CSmXG1hhLDlJZq3zmaG OE5boqGpg3UCo+AsJPtmIWmZhaRlASPzKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2M wEA+uOW30Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDo2PF6 qonjx4WHJ4Q/vDJxnr+u2P2lbq6dAv8/Fnz3ctF79PxP7MxLFxZtnnXNfG7NEmajigS3a0oh G9Tdd374bXvsdpXQlwPhzF3zRAvq1yfWHDZ/E+l4YDaru1Dk7PIzllkT1S/cPdG9YId+S9TX Fx+NjpswNN7MzHr4WHi2i8b6PL2owNdzlViKMxINtZiLihMBQTSEKTICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qeuQMVJBof7W1Rv-pq72LlEz-I0 Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 12 Mar 2014 09:04:37 -0000 On 2014-03-12 09:47, Christer Holmberg wrote: > It may be that we agree, but talk past each other :) > > My understanding of bundle-only has been that it is a mechanism to > ensure that the m- line is accepted only if the BUNDLE group is > accepted, e.g. in order to avoid having to reserve extra ports. BUT, > the bundle-only m- lines are NOT used to negotiate the actual BUNDLE > address - they will inherit the selected BUNDLE address, negotiated > using non-bundle-only m- lines. > I think we are agreeing. I think my main point is that the m= blocks that contains bundle-only needs to contain the attribute a=rtcp-mux if that is included in the first m= block for the bundle group that contains the actual addresses. Similar with the a=rtcp attribute. Simply to be explicit that they are configured similarly. This I think implies that we need a "to be replaced" value also for a=rtcp in the bundle only m= blocks. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 12 02:06:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F781A0937 for ; Wed, 12 Mar 2014 02:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6oXKIWosTDw for ; Wed, 12 Mar 2014 02:06:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BBC551A091D for ; Wed, 12 Mar 2014 02:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5773; q=dns/txt; s=iport; t=1394615174; x=1395824774; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4kIYc9OWMqlhfOMPa4Bti7d8BwZ6OfwAKO1xlsdK1/I=; b=bFeycbvR+lhGlIuQY3S+HJtkpuYB0ckeyCu1hNWcp+NAAQvfYKRdekFB CBsLvXmB7TzORFz0R1okQDbMRnUiIk1DWdqRhJocJO2aOjMO0JG4AiOwm if5oQGSGyL+OSeFQJt6i/Dt6otFKIi/jORlhegMU/QMd7FaG9DutFK72p 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFANsiIFOtJV2d/2dsb2JhbABagwY7V7ohhmFPgRkWdIIlAQEBBAEBAQliCwwCAgIBCBEEAQELHQcbDAsUCQgBAQQBDQUIh3EN0VYTBASOJzEHBoMegRQEiRmhWYMtgis X-IronPort-AV: E=Sophos;i="4.97,636,1389744000"; d="scan'208";a="309728313" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2014 09:06:13 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2C96DSg018206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 09:06:13 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.166]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 04:06:13 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Magnus Westerlund , Justin Uberti , Simon Perreault Thread-Topic: [rtcweb] DSCP marking for STUN packets Thread-Index: Ac85vcTs78cs2C8tSs2+vLGf/NxF+AEC/C2eAACAeTA= Date: Wed, 12 Mar 2014 09:06:12 +0000 Message-ID: References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <532014C8.2050908@ericsson.com> In-Reply-To: <532014C8.2050908@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.189.166] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/58TGyoWyyoNhT46HdW7VrMQeaUo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 12 Mar 2014 09:06:24 -0000 I think we are discussing two different problems: 1. Determining what DSCP actually works over the Internet, by using ICE. 2. For one or more DSCPs an endpoint uses for a traffic flow, what DSCP ICE= needs to use. In the case of #2, the endpoint uses those DSCPs because the network is pro= visioned that way by the network admin or the service provider. This could = possibly be achieved through a combination of some browser configuration an= d JS input. For this case, using the highest DSCP value among those that ar= e used for a given media or data-channel flow for ICE connectivity/consent = checks makes sense to me. On this other hand, #1 looks a bigger problem. In the absence of any inform= ation, starting with BE or not setting anything in the packet looks a good = option to me. Muthu |-----Original Message----- |From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlu= nd |Sent: Wednesday, March 12, 2014 1:33 PM |To: Justin Uberti; Simon Perreault |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] DSCP marking for STUN packets | |On 2014-03-12 04:53, Justin Uberti wrote: |> |> |> |> On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault |> > wrote= : |> |> Le 2014-03-10 16:57, James Polk a =E9crit : |> > At 12:16 AM 3/10/2014, Justin Uberti wrote: |> >> I think that the existing guidance should be sufficient in |> >> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think= the |> >> same DSCP markings as any other ICE connectivity checks should be |> >> used; for ICE-for-SCTP checks, the same DSCP markings as media |> packets |> >> (i.e. the SCTP traffic) should be used. |> >> |> >> If multiplexing is being performed, the connectivity checks proba= bly |> >> should use the highest DSCP value being used by the multiplexed |> media. |> > |> > why is (seemingly) everyone's default position "use the highest DS= CP |> > available" for signaling packets? |> > |> > You just need to make sure the packets aren't starved or dropped b= y/at |> > congestion points. |> |> The underlying principle is that connectivity checks need to *check |> connectivity* (duh!). That's why you use the same DSCP as the media. |> Connectivity is affected by the DSCP. For example some DSCPs could b= e |> filtered, or could be placed in a low-priority queue and get dropped |> such that connectivity fails. |> |> >From this principle follows this conclusion: on a given 5-tuple, if |> your |> media uses different DSCPs, you need to check connectivity for all t= hose |> DSCPs. That is, you would send multiple connectivity checks, one for |> each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we mi= ght |> need an alternative heuristic: try the lowest-priority DSCP, and ass= ume |> that if that one works, the higher-priority ones should work as well= . |> (Note that Justin suggested the contrary.) |> |> What you want to avoid is STUN packets getting through but not the |> corresponding media. That is an unworkable situation. The reverse is= not |> ideal either (you think you have no connectivity when in fact you do= ), |> but at least ICE can work around it (by picking a different candidat= e). |> |> |> We also need to consider the scenario of STUN consent checks, which will |> need to get through reliably even when media marked with DSCP is already |> flowing. In this case I think that using the highest DSCP value for STUN |> is unavoidable. |> | |(as individual) | |Sorry, I don't understand your reasoning here. Is it to provide the |lowest possible drop probability, i.e. using the AFx class that has |least drop probability? | |If there exist nodes that stomp on some DSCP markings, and not only |remark them to Best Effort (BE), and instead drop then. Then, it is not |obvious that that an AFx class is the most appropriate to use. In that |case using BE might be more suitable for the consent freshness. | |I would also point out that highest DSCP value isn't clear. We are |talking about forwarding behavior and I don't see how Expedited |Forwarding (EF) can be compared with AF for example. | |I think we have to consider what our goals are here. To determine if we |can get any packets through or determine if a particular 6-tuple (Source |Address, Destination Address, Source Port, Destination Port, Protocol, |and DSCP value) works? If it is the later then I think we need to have |checks running on all the 6-tuples in use. This clearly have overhead |concerns and helps worsening the ICE The Voice Hammer Attack (See |section 18.5.1. of RFC 5245). | |If the goal is the first, isn't using BE a reasonable choice. Yes, it |might have higher drop probability than AF, but it is likely to be |robuster in general deployments and it determine if the peer is there or |not. Dealing with broken 6-tuples needs to be a separate issue. | |Cheers | |Magnus Westerlund | |---------------------------------------------------------------------- |Services, Media and Network features, Ericsson Research EAB/TXM |---------------------------------------------------------------------- |Ericsson AB | Phone +46 10 7148287 |F=E4r=F6gatan 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 From nobody Wed Mar 12 02:13:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1681A0934 for ; Wed, 12 Mar 2014 02:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 95V4ChkKJkOz for ; Wed, 12 Mar 2014 02:13:55 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 15CA81A092F for ; Wed, 12 Mar 2014 02:13:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-6c-5320254b799a Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A5.BF.23809.B4520235; Wed, 12 Mar 2014 10:13:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Wed, 12 Mar 2014 10:13:46 +0100 From: Christer Holmberg To: Magnus Westerlund , Justin Uberti , "rtcweb@ietf.org" , Eric Rescorla Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAABUUUP//+FOAAAJJa8A= Date: Wed, 12 Mar 2014 09:13:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D20BE11@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D20A684@ESESSMB209.ericsson.se> <5320231B.5000008@ericsson.com> In-Reply-To: <5320231B.5000008@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvja6PqkKwwb7HChYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8a0dbsZC76yV8zc4dnAuJCt i5GTQ0LARGLb7mZGCFtM4sK99WBxIYFDjBKzu527GLmA7CWMEieaNwAVcXCwCVhIdP/TBomL CCxklHj58QALSIOwgLHElM7JYM0iQEPnTnzNAmGXSfRMWsYOYrMIqEosezENrIZXwFfi/JaZ rBALTrFI3Lr3hgkkwSmgI7F/2zswmxHoou+n1oDZzALiEreezGeCuFRAYsme88wQtqjEy8f/ WEGOkxBQlFjeLwdRriOxYPcnNghbW2LZwtfMEHsFJU7OfMIygVF0FpKps5C0zELSMgtJywJG llWM7LmJmTnp5UabGIGRcXDLb9UdjHfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QD45yEl8fZksObLexri3g3s9atP2nya6fFjE8TDTqSjx+ZO3FJzMxFJktvf1+4 gE99+x+3mPviz2+xXCmdfFkkfec38eXObwo4p1+tXVrGcOhV9GSfBrW9qc5GN1MPO3nkT7D1 vmTIyLPPdFmTGlf94bTbmxbf/mHDcPcLv69Z5sRl8dYcMXtvf1RiKc5INNRiLipOBAD+94zD WgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2sM5PSucDsccetBD4iQ8gfb9B6s Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 12 Mar 2014 09:13:57 -0000 Hi, >> It may be that we agree, but talk past each other :) >>=20 >> My understanding of bundle-only has been that it is a mechanism to=20 >> ensure that the m- line is accepted only if the BUNDLE group is=20 >> accepted, e.g. in order to avoid having to reserve extra ports. BUT,=20 >> the bundle-only m- lines are NOT used to negotiate the actual BUNDLE=20 >> address - they will inherit the selected BUNDLE address, negotiated=20 >> using non-bundle-only m- lines. >>=20 > > I think we are agreeing. I think my main point is that the m=3D blocks th= at contains bundle-only needs to contain the attribute a=3Drtcp-mux if that= is included in the first m=3D block for the bundle group that contains the= actual addresses.=20 > Similar with the a=3Drtcp attribute. Simply to be explicit that they are = configured similarly.=20 Correct. > This I think implies that we need a "to be replaced" value also for a=3Dr= tcp in the bundle only m=3D blocks. Yes. Regards, Christer From nobody Wed Mar 12 02:39:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745E21A093E for ; Wed, 12 Mar 2014 02:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zOmGehTkBN0 for ; Wed, 12 Mar 2014 02:39:45 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id DEDCB1A0930 for ; Wed, 12 Mar 2014 02:39:44 -0700 (PDT) Received: from [130.209.247.112] (port=64214 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 1WNfdR-0003jH-Jq; Wed, 12 Mar 2014 09:39:38 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_CB97D6F7-B3BE-4E0D-9437-4346E6DAD96D" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: Date: Wed, 12 Mar 2014 09:39:33 +0000 Message-Id: References: To: Watson Ladd X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Eh2Sv4UHDdgMuQl1KX-aaVKEU1o Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Areas of security concern 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, 12 Mar 2014 09:39:49 -0000 --Apple-Mail=_CB97D6F7-B3BE-4E0D-9437-4346E6DAD96D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 12 Mar 2014, at 05:11, Watson Ladd wrote: > Dear all, > I've jotted down the following notes when reading the drafts from here = and the W3C as potential problem areas. Maybe there are things I've = missed in the drafts that address them, but I think they are still worth = thinking about. Some of these are more W3C, but we seem to be in charge = of the security. These issues vary widely in seriousness. One of them is = a demonstrated break of confidentiality, while several are open = questions about how we communicate to users. =85 > Problem 7: VBR privacy leaks >=20 > I can do no better then to refer to the paper. = http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-= can.pdf Spoken phrases could be identified from encrypted data alone, = using a Hidden Markov Model when the length of packets was preserved by = the encryption. The security considerations in draft-ietf-rtcweb-rtp-usage-12 refer to = RFC 6562, which I believe gives recommendations to address this. Colin > Conclusion: > Some of these issues result from well-known problems in older = protocols. Others are longstanding difficult problems that have to be = solved. Some are quite dangerous, while others will only permit the = occasional prank. However, it is not enough to fix these specifically. = Large areas of the proposal have not been explored by me. If I had to = rate these by seriousness, problem 3 and 7 are the worst. They are = luckily the easiest to fix. >=20 > Sincerely, > Watson Ladd > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_CB97D6F7-B3BE-4E0D-9437-4346E6DAD96D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 12 = Mar 2014, at 05:11, Watson Ladd <watsonbladd@gmail.com> = wrote:
Dear all,
I've = jotted down the following notes when reading the drafts from here and = the W3C as potential problem areas. Maybe there are things I've missed = in the drafts that address them, but I think they are still worth = thinking about. Some of these are more W3C, but we seem to be in charge = of the security. These issues vary widely in seriousness. One of them is = a demonstrated break of confidentiality, while several are open = questions about how we communicate to = users.
=85
Problem 7: VBR privacy leaks

I = can do no better then to refer to the paper. http://www.infsec.cs.uni-saarland.de/teaching/WS08/Semina= r/reports/yes-we-can.pdf Spoken phrases could be identified from = encrypted data alone, using a Hidden Markov Model when the length of = packets was preserved by the = encryption.

The security = considerations in draft-ietf-rtcweb-rtp-usage-12 refer to RFC 6562, = which I believe gives recommendations to address = this.

Colin


Conclusion:
Some of these issues result from = well-known problems in older protocols. Others are longstanding = difficult problems that have to be solved. Some are quite dangerous, = while others will only permit the occasional prank. However, it is not = enough to fix these specifically. Large areas of the proposal have not = been explored by me. If I had to rate these by seriousness, problem 3 = and 7 are the worst. They are luckily the easiest to fix.

Sincerely,
Watson Ladd
_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb



-- 
Colin Perkins



= --Apple-Mail=_CB97D6F7-B3BE-4E0D-9437-4346E6DAD96D-- From nobody Wed Mar 12 02:54:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA601A0939 for ; Wed, 12 Mar 2014 02:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 4PazM8J29e8p for ; Wed, 12 Mar 2014 02:54:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5A71A0933 for ; Wed, 12 Mar 2014 02:54:12 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-f9-53202ebd4c20 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.02.10875.DBE20235; Wed, 12 Mar 2014 10:54:05 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.220]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Wed, 12 Mar 2014 10:54:05 +0100 From: John Mattsson To: Watson Ladd , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Areas of security concern Thread-Index: AQHPPbGLVDS5BScXzk6f38VicWm+iJrdNroA Date: Wed, 12 Mar 2014 09:54:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_CF45EAB910F08johnmattssonericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvje5ePYVgg13/zSzW/mtnt+jpPMnm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGW8mrqQqeCXXsWm10+ZGxhP6nYxcnJICJhI bJzTxwJhi0lcuLeerYuRi0NI4BCjxKvfZ6GcJYwS8z6+ZQapYhMwkJi7p4ENxBYR8JHov3GP CcQWFtCXaP83mxUibiDR3PQLKM4BZBtJTDuVDxJmEVCVuD71ENgyXgFzibPXG8DKhQQCJHov zgCzOQUCJXqavoGNZwQ66PupNWDjmQXEJW49mc8EcaiAxJI955khbFGJl4//gfWKCuhJ3Hs0 F+oZJYlFtz9D9cZIPF2wgRlir6DEyZlPWCYwis5CMnYWkrJZSMpmAX3ALKApsX6XPkSJosSU 7ofsELaGROucuVC2tcSqtVdYkNUsYORYxciem5iZk15uuIkRGGkHt/zW3cF46pzIIUZpDhYl cd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDaH1yX7rubO9v93LQvqian++wC99tM ez1L5ZuJ/4TyKzeCtZL9cjf+MFrNqS/Cfnb6BYP4s8v/pTDHpy75q1cz8dvOxsWTNRL8Vd8f 8npwcsaswMQI1/eX7I2tb+fX8LUlvmD5x/bTrmnOrIM/S9q9vKtepF578aX53Lnpt22Xz90S xHgv1lpJiaU4I9FQi7moOBEABjXsMoICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/D-_drIs10GJg7xiIWyqUFBtINyw Subject: Re: [rtcweb] Areas of security concern 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, 12 Mar 2014 09:54:21 -0000 --_000_CF45EAB910F08johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFdhdHNvbiBMYWRkIDx3YXRzb25ibGFkZEBnbWFpbC5jb208bWFpbHRvOndhdHNv bmJsYWRkQGdtYWlsLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXkgMTIgTWFyY2ggMjAxNCAwNToxMQ0K VG86ICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4iIDxydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbcnRjd2ViXSBBcmVhcyBv ZiBzZWN1cml0eSBjb25jZXJuDQoNCkRlYXIgYWxsLA0KSSd2ZSBqb3R0ZWQgZG93biB0aGUgZm9s bG93aW5nIG5vdGVzIHdoZW4gcmVhZGluZyB0aGUgZHJhZnRzIGZyb20gaGVyZSBhbmQgdGhlIFcz QyBhcyBwb3RlbnRpYWwgcHJvYmxlbSBhcmVhcy4gTWF5YmUgdGhlcmUgYXJlIHRoaW5ncyBJJ3Zl IG1pc3NlZCBpbiB0aGUgZHJhZnRzIHRoYXQgYWRkcmVzcyB0aGVtLCBidXQgSSB0aGluayB0aGV5 IGFyZSBzdGlsbCB3b3J0aCB0aGlua2luZyBhYm91dC4gU29tZSBvZiB0aGVzZSBhcmUgbW9yZSBX M0MsIGJ1dCB3ZSBzZWVtIHRvIGJlIGluIGNoYXJnZSBvZiB0aGUgc2VjdXJpdHkuIFRoZXNlIGlz c3VlcyB2YXJ5IHdpZGVseSBpbiBzZXJpb3VzbmVzcy4gT25lIG9mIHRoZW0gaXMgYSBkZW1vbnN0 cmF0ZWQgYnJlYWsgb2YgY29uZmlkZW50aWFsaXR5LCB3aGlsZSBzZXZlcmFsIGFyZSBvcGVuIHF1 ZXN0aW9ucyBhYm91dCBob3cgd2UgY29tbXVuaWNhdGUgdG8gdXNlcnMuDQoNCuKApg0KDQoNClBy b2JsZW0gNDogSE1BQy1TSEExIGluIFNSVFANCg0KPklmIEkndmUgY2hhc2VkIHRoZSBjaGFpbiBv ZiByZWZlcmVuY2VzIGNvcnJlY3RseSB0aGlzIGlzIHRoZSBzb2xlIE1BQyBwcm92aWRlZC4NCg0K Sm9objogWWVzIHRoaXMgaXMgY29ycmVjdCwgKEJ1dCBBRVMtR0NNIGFuZCBBRVMtQ0NNIHNob3Vs ZCAgYmUgYXZhaWxhYmxlIGJlZm9yZSBXZWJSVEMpDQoNCj5JcyBpdCBva2F5PyBJIGhhdmUgbm8g aWRlYTogU0hBLTEgaGFzIGJlZW4gc2lnbmlmaWNhbnRseSB3ZWFrZW5lZCBpbiByZWNlbnQgeWVh cnMuDQoNCkpvaG46IFRoaXMgaXMgb2suIFdoaWxlIFNIQS0xIGl0c2VsZiBpcyB3ZWFrIGFuZCBz aG91bGQgbm90IGJlIHVzZWQgZm9yIHNpZ25hdHVyZXMsIHRoZXJlIGFyZSBubyBhdHRhY2tzIG9u IEhNQUMtU0hBLTEuDQpOSVNUIGN1cnJlbnQgcmVjb21tZW5kYXRpb25zIHNheSB0aGF0IEhNQUMt U0hBLTEgaXMgZ29vZCBmb3IgdXNlIGJleW9uZCAyMDMwIChodHRwOi8vd3d3LmtleWxlbmd0aC5j b20vPGh0dHA6Ly93d3cua2V5bGVuZ3RoLmNvbS9lbi80Lz4gKQ0KDQoNCg== --_000_CF45EAB910F08johnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <18C14A465F6BB8479C101DDB2B7B1F02@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3Nw YW4+V2F0c29uIExhZGQgJmx0OzxhIGhyZWY9Im1haWx0bzp3YXRzb25ibGFkZEBnbWFpbC5jb20i PndhdHNvbmJsYWRkQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXkgMTIgTWFyY2ggMjAxNCAwNToxMTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bcnRjd2Vi XSBBcmVhcyBvZiBzZWN1cml0eSBjb25jZXJuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5EZWFyIGFsbCw8YnI+DQpJJ3ZlIGpvdHRl ZCBkb3duIHRoZSBmb2xsb3dpbmcgbm90ZXMgd2hlbiByZWFkaW5nIHRoZSBkcmFmdHMgZnJvbSBo ZXJlIGFuZCB0aGUgVzNDIGFzIHBvdGVudGlhbCBwcm9ibGVtIGFyZWFzLiBNYXliZSB0aGVyZSBh cmUgdGhpbmdzIEkndmUgbWlzc2VkIGluIHRoZSBkcmFmdHMgdGhhdCBhZGRyZXNzIHRoZW0sIGJ1 dCBJIHRoaW5rIHRoZXkgYXJlIHN0aWxsIHdvcnRoIHRoaW5raW5nIGFib3V0LiBTb21lIG9mIHRo ZXNlIGFyZSBtb3JlIFczQywgYnV0DQogd2Ugc2VlbSB0byBiZSBpbiBjaGFyZ2Ugb2YgdGhlIHNl Y3VyaXR5LiBUaGVzZSBpc3N1ZXMgdmFyeSB3aWRlbHkgaW4gc2VyaW91c25lc3MuIE9uZSBvZiB0 aGVtIGlzIGEgZGVtb25zdHJhdGVkIGJyZWFrIG9mIGNvbmZpZGVudGlhbGl0eSwgd2hpbGUgc2V2 ZXJhbCBhcmUgb3BlbiBxdWVzdGlvbnMgYWJvdXQgaG93IHdlIGNvbW11bmljYXRlIHRvIHVzZXJz Ljxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PuKApjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UHJv YmxlbSA0OiBITUFDLVNIQTEgaW4gU1JUUDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ Jmd0O0lmIEkndmUgY2hhc2VkIHRoZSBjaGFpbiBvZiByZWZlcmVuY2VzIGNvcnJlY3RseSB0aGlz IGlzIHRoZSBzb2xlIE1BQyBwcm92aWRlZC4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Sm9objogWWVzIHRoaXMgaXMgY29y cmVjdCwgKEJ1dCBBRVMtR0NNIGFuZCBBRVMtQ0NNIHNob3VsZCAmbmJzcDtiZSBhdmFpbGFibGUg YmVmb3JlIFdlYlJUQykmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXY+Jmd0O0lzIGl0IG9rYXk/IEkgaGF2ZSBubyBpZGVhOiBTSEEtMSBoYXMgYmVlbiBzaWduaWZp Y2FudGx5IHdlYWtlbmVkIGluIHJlY2VudCB5ZWFycy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+Sm9objogVGhp cyBpcyBvay4gV2hpbGUgU0hBLTEgaXRzZWxmIGlzIHdlYWsgYW5kIHNob3VsZCBub3QgYmUgdXNl ZCBmb3Igc2lnbmF0dXJlcywgdGhlcmUgYXJlIG5vIGF0dGFja3Mgb24gSE1BQy1TSEEtMS48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+TklTVCBjdXJyZW50IHJl Y29tbWVuZGF0aW9ucyBzYXkgdGhhdCBITUFDLVNIQS0xIGlzIGdvb2QgZm9yIHVzZSBiZXlvbmQg MjAzMCAoPGEgaHJlZj0iaHR0cDovL3d3dy5rZXlsZW5ndGguY29tL2VuLzQvIj5odHRwOi8vd3d3 LmtleWxlbmd0aC5jb20vPC9hPiZuYnNwOyk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CF45EAB910F08johnmattssonericssoncom_-- From nobody Wed Mar 12 06:49:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470751A09AB for ; Wed, 12 Mar 2014 06:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I053fL7uM97Z for ; Wed, 12 Mar 2014 06:49:47 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7EF1A0991 for ; Wed, 12 Mar 2014 06:49:46 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2CDnXs7004057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2014 08:49:34 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2CDnWUp029857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 14:49:32 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 12 Mar 2014 14:49:32 +0100 From: "DRAGE, Keith (Keith)" To: Bjoern Hoehrmann , Harald Alvestrand Thread-Topic: [rtcweb] Transports: RFC 6062 support Thread-Index: AQHPPWSkzAxG5Yy6NU67pN9kMRcnNJrcRNkAgAAH2gCAAAfxAIABFGQA Date: Wed, 12 Mar 2014 13:49:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B14A31C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <531F6B6E.6070609@alvestrand.no> <531F7812.4030505@alvestrand.no> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5Iy2Fz3S_HKW59oDq3yEcpris90 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 12 Mar 2014 13:49:51 -0000 And your example is poor. "If XXX sends foo, then XXX MAY include a bar ele= ment" and if necessary a corresponding receiving requirement would be more = correct. Given that the ABNF probably already specifies how the the element is inclu= ded, in other standards bodies I would write "can" here as in possibility, = rather than option. Many such requirements are dynamic, not static, as an o= ption should really be. How do you test what you have written. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Bjoern Hoehrmann > Sent: 11 March 2014 21:23 > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Transports: RFC 6062 support >=20 > * Harald Alvestrand wrote: > >On 03/11/2014 09:26 PM, Bjoern Hoehrmann wrote: > >> * Harald Alvestrand wrote: > >>> In RFC 2119 theory, MAY and not mentioning it at all have exactly=20 > >>> the same weight. > >> (That depends on whether the default is "allowed" or=20 > "prohibited" and=20 > >> there are plenty of specifications where explicit MAY=20 > overrides a de-=20 > >> fault of "prohibited".) > > > >Probably true. But I can't think of any at the moment - do you have=20 > >something specific in mind? >=20 > (A typical example is when RFC 2119 keywords are used to=20 > describe how a protocol element is constructed, say, "=20 > elements MAY carry bar=3D'' > attributes"; you wouldn't assume you can use =20 > without that.) > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20 > http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon:=20 > +49(0)160/4415681 =B7 http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20 > http://www.websitedev.de/=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Wed Mar 12 08:18:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7F71A073C for ; Wed, 12 Mar 2014 08:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 UR5nUpdKXeCu for ; Wed, 12 Mar 2014 08:18:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id DDC701A046F for ; Wed, 12 Mar 2014 08:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=868; q=dns/txt; s=iport; t=1394637471; x=1395847071; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6+1aiJjk4Z6DfX0NR1Nf6X8G9ZPIDhSJHCj1Qb/mpcU=; b=QiO/8jZnitTRQs9zMNxU087quz66pOVQ9uP1GtFrGNf3VrETFAxMMkQa Uv9kXkLDpHwTCoN53DdqJMRCIM3mrXMdxA0OP9WGteNA59CAw9Qxyup94 ECsrf/lQf4FdlMk/jtZJcF4rLwjM8V1YGAvOJJAOpp1QgloUAYDY8yRJi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAIZ5IFOrRDoH/2dsb2JhbABagwbCZoEcFnSCJQEBAQMBOj8FCwsYLiE2BhOHZQMJB8taDYYwF4xFgWQzB4MkgRQBA5ZYgW2GTIYZhUiDLT0 X-IronPort-AV: E=Sophos;i="4.97,638,1389744000"; d="scan'208";a="26898582" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by alln-iport-7.cisco.com with ESMTP; 12 Mar 2014 15:17:50 +0000 Received: from [10.21.79.5] ([10.21.79.5]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2CFGx06018410; Wed, 12 Mar 2014 15:17:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Wed, 12 Mar 2014 00:51:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qgtXUmpmX_79GKKAzrypqYiymtY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 12 Mar 2014 15:18:10 -0000 On Mar 8, 2014, at 6:48 AM, Martin Thomson = wrote: > On 7 March 2014 20:14, Dan Wing wrote: >> About half a year ago, AVTCORE published an updated recommendation = for CNAME as RFC7022. Is its guidance insufficient? >=20 > Necessary, but not sufficient. Unfortunately, the definition of a > "session", while sufficient for the description in 7022, is not quite > precise enough for this use case. The implication there is that it > means "RTP session", which is both not at the right level of > granularity, and not directly actionable. Perhaps AVTCORE can take on an update to use WebRTC terminology. > I also note this little gem: >=20 > A longer-term persistent RTCP CNAME is sometimes useful to = facilitate > third-party monitoring, consistent with [RFC3550]. Yep, it's true. -d From nobody Wed Mar 12 08:32:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA511A0761 for ; Wed, 12 Mar 2014 08:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 QQZMh4lDYlFG for ; Wed, 12 Mar 2014 08:32:11 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E04691A044B for ; Wed, 12 Mar 2014 08:32:10 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-b6-53207df39ff1 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 4A.68.04853.3FD70235; Wed, 12 Mar 2014 16:32:03 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Mar 2014 16:32:02 +0100 Message-ID: <53207DF3.9000706@ericsson.com> Date: Wed, 12 Mar 2014 16:32:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dan Wing , Martin Thomson References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvje7nWoVgg9/rDS0uXnvIZHHtzD9G i7X/2tkdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZezsO85W0MtXMeHnd9YG xh3cXYwcHBICJhKvLpt0MXICmWISF+6tZwOxhQROMEo8nVrXxcgFZC9nlNi45RpYgldAW2Lp +keMIDaLgKrEmvbf7CA2m4CFxM0fjWA1ogLBEjsP/GaEqBeUODnzCQuILSLgKTHl4WmwOLOA usSdxefAeoUFrCSeHD7AArHsO6PEuV0fwYo4BWwlrmzfxQRxqLhET2MQRK+exJSrLVBz5CWa t85mhjhaW6KhqYN1AqPQLCSrZyFpmYWkZQEj8ypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy9 4tRNjMAAP7jlt9EOxpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA uNX7RKYPl7/hbdHDf0+mGHLVLOd5pvxK2Ngmh/dw4dK/O/co3v1sqzjhu9uXqfa/Gz5MXDer TXnXDLUFKR/E047OzN788zmn3f/1izbvnHNOquaf53TLkuMcur8aXQ+9Xcu8e38ER6yPwZ+T Oyq9Jb9sleKNSFn1646Pf5H0okUrWdRv68mZLFFiKc5INNRiLipOBABrg3QQPgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qtoNhr2BF3nWO3xLrjNt5tP1-b8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 12 Mar 2014 15:32:16 -0000 On 2014-03-12 01:51, Dan Wing wrote: > > On Mar 8, 2014, at 6:48 AM, Martin Thomson wrote: > >> On 7 March 2014 20:14, Dan Wing wrote: >>> About half a year ago, AVTCORE published an updated recommendation for CNAME as RFC7022. Is its guidance insufficient? >> >> Necessary, but not sufficient. Unfortunately, the definition of a >> "session", while sufficient for the description in 7022, is not quite >> precise enough for this use case. The implication there is that it >> means "RTP session", which is both not at the right level of >> granularity, and not directly actionable. > > Perhaps AVTCORE can take on an update to use WebRTC terminology. I disagree! WebRTC is a particular usage of RTP/RTCP. The fact that RFC 7022's terminology is not sufficiently narrow to describe the particulars of WebRTC's usage is in my opinion not a bug. It is a feature. If the AVTCORE document would be using the narrowed down case of WebRTC the recommendations would no longer be applicable in a number of other usages of RTP. Deciding to apply RTP in a particular way to solve ones real-time transport problems, also means that one have may have to be more specific within that usage about things, this is such an example. Cheers Magnus Westerlund (As Individual) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 12 09:05:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4343D1A09CD for ; Wed, 12 Mar 2014 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 p5jfgup07urE for ; Wed, 12 Mar 2014 09:05:35 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D72301A09D2 for ; Wed, 12 Mar 2014 09:05:34 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so10483318veb.32 for ; Wed, 12 Mar 2014 09:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PXWSAq++PW/UZeUc4AEbEQVCOHum+vqz//54c7oWEow=; b=BHq9utIJfHnCKfPjH7FC7pimuXim5+jM4it2YDUQ65NIDWGPfSpcrQWjaoaKcFZXgC CB9scibE7Mdh99zGIh2zslz09ZnW1FDE/jHDamutF945SeF6/O8yMqryjs6L5PAuOHJQ B5y9gSj3zY7X4tc8HkJcqzth6PF41VDIOoWCtGk8cV4yqZ96QzuTjThnsnZ7e/xHqOvz fR5eFNAN533i1odDzHU6sF4XlG5yc82iXjrnB6wf/kfhZ+iuOFs9ovCCXIuV0PwkM3W0 dQU3hnykCXOIIPUkAvnxmeN0/lp4gHkcPCo4Zc4fT2lkyJ7rEbF5pNd7jGX97bRiLxGM Q4eA== 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=PXWSAq++PW/UZeUc4AEbEQVCOHum+vqz//54c7oWEow=; b=Qvp4bdIe6avhnPY8ZapL5cfKwo8eNCf+rbNJ1QoL4GGjtG8IOq9HY5uMloKRfNZeSF SKMlk+nM2BxUlm5Fj+GZgtdDHFUAPoKC3PwlAtol1O+cpG87dULBlue0hAWk4m5cG+3r wZSRqJfHTN8dgk7q7PA0rLOEcfneJpFnwaJGQ8E2aj68V1evtDfF+7tVQg48CY23cHjQ 5RfosrTcC7DB0pwydhVVI3hvjI0CY3lWV9piYlu6F5pqRQ3Tcb1m+FYoHxkp9Q9PQcM2 G153CP2zYMpPZjiWeUZwR0BTVMd45J94c8Z5SEqujQ2y1WLcCBnqoMV/yw4RojaapXuU yOqw== X-Gm-Message-State: ALoCoQnMuIu3KwyFAuZQTM62cUmVSkVKv2tRbfyhFhDPJfTdLXV8GlH3JTbSP/pYETiqgPX94vnPObQ6uWs0rFMoRQ4rbgkFDyDN0tBdasU8I9IeEh4PgUdpLSChlZHl9iSQ2aesfsS2S01Lr5Dc8nYV9/MDxxmjPAannCngy1DaPC2VnGuazGkwCAcQ9x9fWdmAZzVPNoyQ X-Received: by 10.52.101.135 with SMTP id fg7mr31423276vdb.17.1394640328439; Wed, 12 Mar 2014 09:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 12 Mar 2014 09:05:08 -0700 (PDT) In-Reply-To: <532014C8.2050908@ericsson.com> References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <532014C8.2050908@ericsson.com> From: Justin Uberti Date: Wed, 12 Mar 2014 09:05:08 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec54695055dd01104f46b0155 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/biw6I8BKqGVkHXwtftnkTAhsyyg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 12 Mar 2014 16:05:40 -0000 --bcaec54695055dd01104f46b0155 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-12 04:53, Justin Uberti wrote: > > > > > > > > On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault > > > > wrote: > > > > Le 2014-03-10 16:57, James Polk a =C3=A9crit : > > > At 12:16 AM 3/10/2014, Justin Uberti wrote: > > >> I think that the existing guidance should be sufficient in > > >> non-multiplexing cases (i.e. BUNDLE). For consent checks, I thin= k > the > > >> same DSCP markings as any other ICE connectivity checks should b= e > > >> used; for ICE-for-SCTP checks, the same DSCP markings as media > > packets > > >> (i.e. the SCTP traffic) should be used. > > >> > > >> If multiplexing is being performed, the connectivity checks > probably > > >> should use the highest DSCP value being used by the multiplexed > > media. > > > > > > why is (seemingly) everyone's default position "use the highest > DSCP > > > available" for signaling packets? > > > > > > You just need to make sure the packets aren't starved or dropped > by/at > > > congestion points. > > > > The underlying principle is that connectivity checks need to *check > > connectivity* (duh!). That's why you use the same DSCP as the media= . > > Connectivity is affected by the DSCP. For example some DSCPs could = be > > filtered, or could be placed in a low-priority queue and get droppe= d > > such that connectivity fails. > > > > >From this principle follows this conclusion: on a given 5-tuple, i= f > > your > > media uses different DSCPs, you need to check connectivity for all > those > > DSCPs. That is, you would send multiple connectivity checks, one fo= r > > each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we > might > > need an alternative heuristic: try the lowest-priority DSCP, and > assume > > that if that one works, the higher-priority ones should work as wel= l. > > (Note that Justin suggested the contrary.) > > > > What you want to avoid is STUN packets getting through but not the > > corresponding media. That is an unworkable situation. The reverse i= s > not > > ideal either (you think you have no connectivity when in fact you > do), > > but at least ICE can work around it (by picking a different > candidate). > > > > > > We also need to consider the scenario of STUN consent checks, which wil= l > > need to get through reliably even when media marked with DSCP is alread= y > > flowing. In this case I think that using the highest DSCP value for STU= N > > is unavoidable. > > > > (as individual) > > Sorry, I don't understand your reasoning here. Is it to provide the > lowest possible drop probability, i.e. using the AFx class that has > least drop probability? > The idea is to have the same drop probability as the most critical media that is flowing (e.g. voice), so that we don't end up in a situation where media flows fine, but the media crowds out STUN consent check packets, leading to call failure. > > If there exist nodes that stomp on some DSCP markings, and not only > remark them to Best Effort (BE), and instead drop then. Then, it is not > obvious that that an AFx class is the most appropriate to use. In that > case using BE might be more suitable for the consent freshness. > If nodes stomp on certain AF-marked packets, and this is widespread, this essentially dooms use of DSCP at all, unless we want to build some sophisticated detection and fallback mechanism. IOW, it's not clear to me that marking packets as BE confers any value over not marking at all. > > I would also point out that highest DSCP value isn't clear. We are > talking about forwarding behavior and I don't see how Expedited > Forwarding (EF) can be compared with AF for example. > > I think we have to consider what our goals are here. To determine if we > can get any packets through or determine if a particular 6-tuple (Source > Address, Destination Address, Source Port, Destination Port, Protocol, > and DSCP value) works? If it is the later then I think we need to have > checks running on all the 6-tuples in use. This clearly have overhead > concerns and helps worsening the ICE The Voice Hammer Attack (See > section 18.5.1. of RFC 5245). > > If the goal is the first, isn't using BE a reasonable choice. Yes, it > might have higher drop probability than AF, but it is likely to be > robuster in general deployments and it determine if the peer is there or > not. Dealing with broken 6-tuples needs to be a separate issue. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --bcaec54695055dd01104f46b0155 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
On 2014-03-12 04:53, Justin = Uberti wrote:
>
>
>
> On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault
> <simon.perreault@viagenie.ca <mailto:simon.perreault@viagenie.ca>> wrote:
>
> =C2=A0 =C2=A0 Le 2014-03-10 16:57, James Polk a =C3=A9crit :
> =C2=A0 =C2=A0 > At 12:16 AM 3/10/2014, Justin Uberti wrote:
> =C2=A0 =C2=A0 >> I think that the existing guidance should be su= fficient in
> =C2=A0 =C2=A0 >> non-multiplexing cases (i.e. BUNDLE). For conse= nt checks, I think the
> =C2=A0 =C2=A0 >> same DSCP markings as any other ICE connectivit= y checks should be
> =C2=A0 =C2=A0 >> used; for ICE-for-SCTP checks, the same DSCP ma= rkings as media
> =C2=A0 =C2=A0 packets
> =C2=A0 =C2=A0 >> (i.e. the SCTP traffic) should be used.
> =C2=A0 =C2=A0 >>
> =C2=A0 =C2=A0 >> If multiplexing is being performed, the connect= ivity checks probably
> =C2=A0 =C2=A0 >> should use the highest DSCP value being used by= the multiplexed
> =C2=A0 =C2=A0 media.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > why is (seemingly) everyone's default position = "use the highest DSCP
> =C2=A0 =C2=A0 > available" for signaling packets?
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > You just need to make sure the packets aren't s= tarved or dropped by/at
> =C2=A0 =C2=A0 > congestion points.
>
> =C2=A0 =C2=A0 The underlying principle is that connectivity checks nee= d to *check
> =C2=A0 =C2=A0 connectivity* (duh!). That's why you use the same DS= CP as the media.
> =C2=A0 =C2=A0 Connectivity is affected by the DSCP. For example some D= SCPs could be
> =C2=A0 =C2=A0 filtered, or could be placed in a low-priority queue and= get dropped
> =C2=A0 =C2=A0 such that connectivity fails.
>
> =C2=A0 =C2=A0 >From this principle follows this conclusion: on a gi= ven 5-tuple, if
> =C2=A0 =C2=A0 your
> =C2=A0 =C2=A0 media uses different DSCPs, you need to check connectivi= ty for all those
> =C2=A0 =C2=A0 DSCPs. That is, you would send multiple connectivity che= cks, one for
> =C2=A0 =C2=A0 each DSCPs in the set used on this 5-tuple. Yeah, it suc= ks, so we might
> =C2=A0 =C2=A0 need an alternative heuristic: try the lowest-priority D= SCP, and assume
> =C2=A0 =C2=A0 that if that one works, the higher-priority ones should = work as well.
> =C2=A0 =C2=A0 (Note that Justin suggested the contrary.)
>
> =C2=A0 =C2=A0 What you want to avoid is STUN packets getting through b= ut not the
> =C2=A0 =C2=A0 corresponding media. That is an unworkable situation. Th= e reverse is not
> =C2=A0 =C2=A0 ideal either (you think you have no connectivity when in= fact you do),
> =C2=A0 =C2=A0 but at least ICE can work around it (by picking a differ= ent candidate).
>
>
> We also need to consider the scenario of STUN consent checks, which wi= ll
> need to get through reliably even when media marked with DSCP is alrea= dy
> flowing. In this case I think that using the highest DSCP value for ST= UN
> is unavoidable.
>

(as individual)

Sorry, I don't understand your reasoning here. Is it to provide the
lowest possible drop probability, i.e. using the AFx class that has
least drop probability?

The idea is to = have the same drop probability as the most critical media that is flowing (= e.g. voice), so that we don't end up in a situation where media flows f= ine, but the media crowds out STUN consent check packets, leading to call f= ailure.=C2=A0

If there exist nodes that stomp on some DSCP markings, and not only
remark them to Best Effort (BE), and instead drop then. Then, it is not
obvious that that an AFx class is the most appropriate to use. In that
case using BE might be more suitable for the consent freshness.

If nodes stomp on certain AF-marked packets, and t= his is widespread, this essentially dooms use of DSCP at all, unless we wan= t to build some sophisticated detection and fallback mechanism. IOW, it'= ;s not clear to me that marking packets as BE confers any value over not ma= rking at all.

I would also point out that highest DSCP value isn't clear. We are
talking about forwarding behavior and I don't see how Expedited
Forwarding (EF) can be compared with AF for example.

I think we have to consider what our goals are here. To determine if we
can get any packets through or determine if a particular 6-tuple (Source Address, Destination Address, Source Port, Destination Port, Protocol,
and DSCP value) works? If it is the later then I think we need to have
checks running on all the 6-tuples in use. This clearly have overhead
concerns and helps worsening the ICE The Voice Hammer Attack (See
section 18.5.1. of RFC 5245).

If the goal is the first, isn't using BE a reasonable choice. Yes, it might have higher drop probability than AF, but it is likely to be
robuster in general deployments and it determine if the peer is there or not. Dealing with broken 6-tuples needs to be a separate issue.

Cheers

Magnus Westerlund

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


--bcaec54695055dd01104f46b0155-- From nobody Wed Mar 12 09:11:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCC91A0494 for ; Wed, 12 Mar 2014 09:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGGqDjSu0C5s for ; Wed, 12 Mar 2014 09:11:05 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4705A1A048E for ; Wed, 12 Mar 2014 09:11:05 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 9B13023F0517; Wed, 12 Mar 2014 17:10:58 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.208]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 17:10:58 +0100 From: "Hutton, Andrew" To: Magnus Westerlund , Justin Uberti Thread-Topic: [rtcweb] Transports: RFC 6062 support Thread-Index: AQHPPY45Yc4NJiKeNEC4rsuLa6/dk5rdBCAAgACZmKA= Date: Wed, 12 Mar 2014 16:10:56 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D3312B@MCHP04MSX.global-ad.net> References: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net> <53177A5E.7030704@viagenie.ca> <53183BBB.3040409@viagenie.ca> <531874A4.6010908@viagenie.ca> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <53201236.40702@ericsson.com> In-Reply-To: <53201236.40702@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hYgH-y9CEBtvX7ttw0W05SkB8bc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 6062 support 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, 12 Mar 2014 16:11:15 -0000 UGVyc29uYWxseSBJIHRoaW5rIGxlYXZpbmcgaW4gdGhlICJNQVkiIHN0YXRlbWVudCBpcyBhIGdv b2QgaWRlYSB1bmxlc3MgdGhlcmUgaXMgYSByZWFsbHkgcmVhc29uIHdoeSB3ZSBkb27igJl0IHdh bnQgYW4gaW1wbGVtZW50YXRpb24gdG8gZG8gdGhpcy4gIEluY2x1ZGluZyBzdWNoIGEgY2FuZGlk YXRlIGRvZXMgbm90IGFwcGVhciB0byBkbyBhbnlib2R5IGFueSBoYXJtIHNvIEkgdGhpbmsgd2Ug c2hvdWxkIHNheSBpdCAiTUFZIiBiZSBzdXBwb3J0ZWQuDQoNClNvIEkgc3VnZ2VzdCBtb2RpZnlp bmcgdGhlIGZpcnN0IGxpbmUgdGhlIHRleHQgTWFnbnVzIHN1Z2dlc3RlZCBhcyBmb2xsb3dzOg0K DQpVc2luZyBUVVJOIHRvIHByb3ZpZGUgVENQIHJlbGF5IGNhbmRpZGF0ZXMgW1JFRl0gTUFZIGJl IHN1cHBvcnRlZCBob3dldmVyIHN1Y2ggY2FuZGlkYXRlcyBhcmUgbm90DQpzZWVuIGFzIHByb3Zp ZGluZyBhbnkgc2lnbmlmaWNhbnQgYmVuZWZpdC4gRmlyc3QsIHVzZSBvZiBUVVJOIFRDUCB3b3Vs ZA0Kb25seSBiZSByZWxldmFudCBpbiBjYXNlcyB3aGljaCBib3RoIHBlZXJzIHJlcXVpcmVzIHRv IHVzZSBUQ1AgdG8NCmVzdGFibGlzaCBhIFBlZXJDb25uZWN0aW9uLiBTZWNvbmRseSwgdGhhdCB1 c2UgY2FzZSBpcyBhbnl3YXkgc3VwcG9ydGVkDQpieSBib3RoIHNpZGUgZXN0YWJsaXNoaW5nIFVE UCByZWxheSBjYW5kaWRhdGVzIHVzaW5nIFRVUk4gb3ZlciBUQ1ANCltSRUZdLiBUaGlyZGx5LCB1 c2luZyBUQ1Agb25seSBiZXR3ZWVuIHRoZSBlbmRwb2ludCBhbmQgaXRzIHJlbGF5IG1heQ0KcmVz dWx0IGluIGxlc3MgaXNzdWVzIHdpdGggVENQIGluIHJlZ2FyZHMgdG8gcmVhbC10aW1lIGNvbnN0 cmFpbnRzLCBlLmcuDQpkdWUgdG8gaGVhZCBvZiBsaW5lIGJsb2NraW5nLg0KDQoNCkFuZHkNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hZ251cw0KPiBXZXN0ZXJsdW5kDQo+ IFNlbnQ6IDEyIE1hcmNoIDIwMTQgMDc6NTINCj4gVG86IEp1c3RpbiBVYmVydGkNCj4gQ2M6IHJ0 Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gVHJhbnNwb3J0czogUkZDIDYw NjIgc3VwcG9ydA0KPiANCj4gT24gMjAxNC0wMy0xMiAwMTo1OCwgSnVzdGluIFViZXJ0aSB3cm90 ZToNCj4gPiBUaGUgcmVhc29uIEkgc3VnZ2VzdGVkIFNIT1VMRCBOT1QgaXMgYmVjYXVzZSBJIHRo aW5rIHRoaXMgdGVjaG5pcXVlDQo+IGlzDQo+ID4gdW5uZWNlc3NhcnkgZm9yIFdlYlJUQywgYW5k IHR5cGljYWxseSBuZXQgaGFybWZ1bCBmb3IgdGhlIHJlYXNvbnMNCj4gdGhhdA0KPiA+IE1hdHRo ZXcgbWVudGlvbnMuDQo+ID4NCj4gPiBUaGF0IHNhaWQsIEkgd291bGQgYmUgZmluZSB3aXRoIHNh eWluZyBNQVkgYW5kIGluY2x1ZGluZyBzb21lDQo+ID4gZXhwbGFuYXRvcnkgdGV4dDsgbXkgbWFp biBjb25jZXJucyB3YXMgdG8gYXZvaWQgdGhlIGFtYmlndWl0eSB0aGF0DQo+IHdvdWxkDQo+ID4g YXJpc2UgZnJvbSBsZWF2aW5nIHRoaXMgb3V0IGFsdG9nZXRoZXIuDQo+IA0KPiBPa2F5LCBhcyB3 ZSBoYXZlIGNvbnNpZGVyYXRpb25zLCBJIHdvdWxkIGxlYXZlIHRoZSBSRkMgMjExOSB0ZXJtcyBv dXQuDQo+IEkNCj4gdGhpbmsgYSBzdGF0ZW1lbnQgYWxvbmcgdGhlIGxpbmVzIG9mIHRoZSBiZWxv dyBtaWdodCBiZSBtb3N0IHN1aXRhYmxlLg0KPiANCj4gVXNpbmcgVFVSTiB0byBwcm92aWRlIFRD UCByZWxheSBjYW5kaWRhdGVzIFtSRUZdIHdhcyBjb25zaWRlcmVkIGJ1dCBub3QNCj4gc2VlbiBh cyBwcm92aWRpbmcgYW55IHNpZ25pZmljYW50IGJlbmVmaXQuIEZpcnN0LCB1c2Ugb2YgVFVSTiBU Q1Agd291bGQNCj4gb25seSBiZSByZWxldmFudCBpbiBjYXNlcyB3aGljaCBib3RoIHBlZXJzIHJl cXVpcmVzIHRvIHVzZSBUQ1AgdG8NCj4gZXN0YWJsaXNoIGEgUGVlckNvbm5lY3Rpb24uIFNlY29u ZGx5LCB0aGF0IHVzZSBjYXNlIGlzIGFueXdheSBzdXBwb3J0ZWQNCj4gYnkgYm90aCBzaWRlIGVz dGFibGlzaGluZyBVRFAgcmVsYXkgY2FuZGlkYXRlcyB1c2luZyBUVVJOIG92ZXIgVENQDQo+IFtS RUZdLiBUaGlyZGx5LCB1c2luZyBUQ1Agb25seSBiZXR3ZWVuIHRoZSBlbmRwb2ludCBhbmQgaXRz IHJlbGF5IG1heQ0KPiByZXN1bHQgaW4gbGVzcyBpc3N1ZXMgd2l0aCBUQ1AgaW4gcmVnYXJkcyB0 byByZWFsLXRpbWUgY29uc3RyYWludHMsDQo+IGUuZy4NCj4gZHVlIHRvIGhlYWQgb2YgbGluZSBi bG9ja2luZy4NCj4gDQo+IFBsZWFzZSBwcm92aWRlIGZlZWRiYWNrIG9yIHdvcmQgc21pdGguDQo+ IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251cw0KPiAoQXMgaW5kaXZpZHVhbCkNCj4gDQo+ID4NCj4g Pg0KPiA+IE9uIE1vbiwgTWFyIDEwLCAyMDE0IGF0IDg6MzMgQU0sIE1hZ251cyBXZXN0ZXJsdW5k DQo+ID4gPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiA8bWFpbHRvOm1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4+DQo+ID4gd3JvdGU6DQo+ID4NCj4gPiAgICAgT24gMjAx NC0wMy0wNiAxNDozNCwgU2ltb24gUGVycmVhdWx0IHdyb3RlOg0KPiA+ICAgICA+IExlIDIwMTQt MDMtMDYgMTM6MjMsIEp1c3RpbiBVYmVydGkgYSDDqWNyaXQgOg0KPiA+ICAgICA+PiBjYW4gd2Ug YWdyZWUgdGhhdCBUVVJOIFRDUCBjYW5kaWRhdGVzIGFyZSBhIFNIT1VMRCBOT1Q/DQo+ID4gICAg ID4NCj4gPiAgICAgPiBOb3QgYSBTSE9VTEQsIHN1cmUuIFNIT1VMRCBOT1QsIG5vLg0KPiA+ICAg ICA+DQo+ID4NCj4gPiAgICAgSSB3b3VsZCBndWVzcyB0aGF0IHRoZSBzaW1wbGVzdCBpcyB0byBy ZW1vdmUgZGlzY3Vzc2lvbiBvZiBUVVJODQo+IFRDUA0KPiA+ICAgICBhbHRvZ2V0aGVyIGZyb20g VHJhbnNwb3J0cy4gVGhhdCB3b3VsZCBub3QgcmVjb21tZW5kIGl0IG5vciBtYWtlDQo+IGl0DQo+ ID4gICAgIGRpc2FsbG93ZWQuIElmIHdlIHdhbnQgdG8gYmUgZXhwbGljaXQsIHRoZW4gc2ltcGx5 IG1vdGl2YXRlIHdoeQ0KPiB3ZSBkb24ndA0KPiA+ICAgICBiZWxpZXZlIGl0IG5lY2Vzc2FyeS4N Cj4gPg0KPiA+ICAgICBKdXN0aW4sIHdoYXQgaXMgdGhlIHJlYXNvbiB5b3Ugd2FudGVkIFNIT1VM RCBOT1Q/DQo+ID4NCj4gPiAgICAgY2hlZXJzDQo+ID4NCj4gPiAgICAgTWFnbnVzIFdlc3Rlcmx1 bmQNCj4gPg0KPiA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLQ0KPiA+ICAgICBTZXJ2aWNlcywgTWVk aWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UWE0NCj4gPiAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0tLS0NCj4gPiAgICAgRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAg IHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+ID4gICAgIDx0ZWw6JTJCNDYlMjAxMCUyMDcxNDgy ODc+DQo+ID4gICAgIEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3 MyAwOTQ5MDc5DQo+ID4gICAgIDx0ZWw6JTJCNDYlMjA3MyUyMDA5NDkwNzk+DQo+ID4gICAgIFNF LTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzoNCj4gbWFnbnVzLndlc3Rlcmx1bmRA ZXJpY3Nzb24uY29tDQo+ID4gICAgIDxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tPg0KPiA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLQ0KPiA+DQo+ID4NCj4gDQo+IA0KPiAtLQ0K PiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2VydmljZXMs IE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0 NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0 NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWls aW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Wed Mar 12 09:14:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D4D1A048E for ; Wed, 12 Mar 2014 09:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.547, 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 KZseCSje7kQT for ; Wed, 12 Mar 2014 09:14:23 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B62731A09CA for ; Wed, 12 Mar 2014 09:14:20 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so7470000vcb.36 for ; Wed, 12 Mar 2014 09:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H/g2cPjcescQF+zVAfc1+abdb3ar6JXMkRFd6OO0JMs=; b=XBa02y/Q+xygIqFvK9jE+MfkfQkyWvCrULwS5UpiyVRpknZatS72W6UQrzMlXCSfcK 3l5jnCzn90CQhQPXAWUjxk40gSwlRfbzGHhDU6TdmcAmHl9WE9bMdtyUFEvn7G3Yl02+ BgxA+oOkpZJDKHxtsbzcwp0+I48TlKNkxHpcpPzNWsgMp7UNDcPOnIbADIJYs/alsj// hLRuvwzGD4Q2yJOybsN+GBfm5/bQFyMaOF0+rHcdmvrgtWP9yOC0Cy94oJrLFQOBGobL kyT327qY96/60j6mYseq44NbTaxZ3gufAGUsXpzgst7O9KqiFIEhso7gn7o4xFTy73aA wH7w== 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=H/g2cPjcescQF+zVAfc1+abdb3ar6JXMkRFd6OO0JMs=; b=a7Ij5g03oSaDI6vCPX4/8d+G5AjN7iCMyxFh6e1hoWfJGc2VFrVSXbkuR7yaTBpXfd sgILaE14rsL1lblph2TYicqixr051MaXdZLGqA3JhhFceSP7VjKfVs5mBqR/wqI2Cqgt 8eAqhLQILMORejkIoFtvbJQLKxCrULrakpV+wi9x2Q9dWwe6gzkv3ZPOguVIawWPwE3y 2djOliBmtE4ygl62geKvuIs2t4kMqoeMMeqvEibtmAhfJMpPyB3ZrxxEKk3qOs3vWCnD HVIQsvhZOr2eTM5NGczNWM5f243bOj8Uji3TmH0UkTeZi9PMA05UfKIiPWdckLw4WbjT nGrQ== X-Gm-Message-State: ALoCoQkbmjniUvtBO8637WjmK+WM0Um/5Qw7f770fGJbgVsRhECEOuP7sPXOoo3b0JYeOr5RngmCucNneIyeK8Q2WtBbWM2p4BB/cyMxCLUxkKal+8DaJhrkSqoxIcBCGOEBJqHbsbpWUGXm4DR1KJzulIGla0lg7i03FkXHtV7TvEEIDrnYxf3O4jiDYqNl+AOk1lkNLl8J X-Received: by 10.52.184.161 with SMTP id ev1mr75376vdc.84.1394640854176; Wed, 12 Mar 2014 09:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 12 Mar 2014 09:13:54 -0700 (PDT) In-Reply-To: <532017DD.1060500@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> From: Justin Uberti Date: Wed, 12 Mar 2014 09:13:54 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec548661cb3eed504f46b2053 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/J891ZQpaqPYGcZUuV00u-5AR6KY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 12 Mar 2014 16:14:27 -0000 --bcaec548661cb3eed504f46b2053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 12, 2014 at 1:16 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-10 21:09, Christer Holmberg wrote: > > Hi, > > > >>>>>>> Before I comment on your proposal, let's take a few steps > >>>>>>> back (maybe it can even solve your issue). > >>>>>>> > >>>>>>> BUNDLE currently mandates the usage of both the SDP > >>>>>>> rtcp-mux and rtcp attributes. I remember we had > >>>>>>> discussions about that, but I don't remember the > >>>>>>> justification at the moment. But, I wonder whether that > >>>>>>> text is from before we made a decision that, unless both > >>>>>>> endpoints support BUNDLE, no endpoint will use a single > >>>>>>> address:port. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> So, the question is: do we really need the SDP rtcp > >>>>>>> attribute? > >>>>>> > >>>>>> I think it is a question of how you want the fallback to > >>>>>> work. In the case of bundle only lines, a non bundle > >>>>>> supporting peer will reject them, thus no issues with what > >>>>>> is written around RTCP-mux and a=3Drtcp in those m=3D blocks. > >>>>>> However, the first one if you want that to support fallback > >>>>>> that makes sense then you will need both a=3Drtcp-mux and an > >>>>>> a=3Drtcp (with a different port) to handle that with optimal > >>>>>> backwards compatibility. > >>>>>> > >>>>>> Regarding the motivation for a=3Drtcp-mux and a=3Drtcp, I think > >>>>>> it is reasonably straight forward. We want a=3Drtcp-mux to > >>>>>> minimize port usage, i.e. ports=3D1. Not supporting > >>>>>> a=3Drtcp-mux with bundle that would mean two ports (RTP and > >>>>>> RTCP) for the bundle group. To get the backwards > >>>>>> compatibility the usage of a=3Drtcp would be required. > >>>>> > >>>>> Keep in mind that the offerer must always be prepared that > >>>>> the answerer does not support the rtcp-mux attribute (or the > >>>>> rtcp attribute). > >>>> > >>>> Yes, that was what I meant with fallback in the above text. > >>>> What you do in case the peer doesn't support bundle. > >>>> > >>>>> So, at least my understanding is: no matter whether BUNDLE is > >>>>> used or not, if the answer does not contain a rtcp-mux (e.g. > >>>>> in case of fallback) attribute, the offerer must use the > >>>>> default "rtp+1" port. > >>>> > >>>> I have a tendency to agree, which means that the first m=3D block > >>>> in a bunde-only group will be required to contain a=3Drtcp and if > >>>> RTCP mux is desired also that attribute. > >>>> > >>>> I think a=3Drtcp could be skipped for a bound-only m=3D block due > >>>> to the requirement on supporting a=3Drtcp-mux if you do bundle. > >>> > >>> For bundle-only, I actually think BOTH can be skipped, because > >>> bundle-only will by default use whatever address:port is > >>> negotiated - both for RTP and RTCP. > >> > >> No, I see a path of grief to not explicitly signal things when you > >> use them. > > > > But, the whole idea of using port zero in bundle-only was that, if > > the answerer supports BUNDLE, port zero will be replaced with the > > negotiated address:port. > > > > When you send the offer, you don't yet know which address:port will > > be selected, so there is no idea to insert a=3Drtcp. Inserting > > a=3Drtcp-mux probably doesn't harm, though, so I won't argue about it > > :) > > Well, if you can't insert the port, the same applies to a=3Drtcp as to th= e > port in the m=3D line. > > Because in the bundle-only case we are assuming and that assumption > needs to apply also for a=3Drtcp. And for a bundle-only case I think the > appropriate thing is to assume that a=3Drtcp-mux will be honored. To have > it being honored you need explicit signal it. The a=3Drtcp can be > considered redundant in this case, but I am sensitive to removing it as > that would create a special case for a=3Dbundle-only lines. I think it is > better to simply include it, even if it will say a=3Drtcp:0 > > > > >> I also thought the a=3Drtcp-mux is a MUST to implement, not a MUST > >> use. > > > > Currently the draft says MUST use. But, that may be a mistake, or a > > leftover from previous procedures. I agree that one should be able to > > use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports > > for the RTP traffic and the RTCP traffic). > > I hope if people disagree that they shout now. > I think rtcp-mux has to be a MUST use when BUNDLE is used between the two endpoints. (If the endpoint doesn't support BUNDLE, rtcp-mux is not required.) Otherwise, you get into weird edge cases, such as where you have a data channel (no RTCP component), and then want to add audio (with RTP and RTCP components). You could bundle the audio RTP over the existing data channel transport, but it's not clear what you should do with the RTCP component. Mandating rtcp-mux avoids this issue completely. > > > > >>> But, for non-bundle-only, I still ask whether we really need > >>> a=3Drtcp. Isn't a=3Drtcp-mux enough? If the answerer supports it, you > >>> will use it, otherwise you will use rtp+1. > >> > >> My understanding is that a=3Drtcp has been required in any > >> non-private network deployments due to >NATs for the last 10 years. > >> Thus, I don't see how you can remove them and expect it to work, > >> unless >you are doing a=3Drtcp-mux. Thus, my view would be that you > >> can remove a=3Drtcp if you know that the >peer supprots a=3Drtcp-mux. > > > > Are you saying that we should use a=3Drtcp ONLY to indicate the RTP > > port, in case the answerer does not support a=3Drtcp-mux? > > It has its normal usage, i.e. RTCP port in cases when a=3Drtcp-mux is not > agreed on. In a bundle-only offer, I think the only reasonable approach > is to handle it identically to the m=3D line port number. > > > > >>> Otherwise, assume that the answerer supports BOTH a=3Drtcp and > >>> a=3Drtcp-mux. Which has higher "priority"? How does the answerer > >>> knows whether the offerer wants to use rtcp-mux, or whether it > >>> wants to use whatever port is indicated in a=3Drtcp? > >> > >> That is a=3Drtcp-mux per RFC 5761 that has higher priority, please > >> see Section 5.1.1. > > > > You are right - my mistake. > > > > But, never the less, if the offerer sends both a=3Drtcp-mux and a=3Drtc= p, > > unless a=3Drtcp points to the rtp port, the offerer needs to be > > prepared to use 3 different ports for RTCP (rtp+1 port, rtp port and > > rtp+), because it does not know which attribute (if > > any) the answerer supports, and which (if any) the answerer is > > willing to use. > > This is actually not necessary, if one can get the rtp+1 port for RTCP, > then include that in the a=3Drtcp line and everything is fine. > > I was under the impression that almost all SIP SDP O/A was using a=3Drtcp= . > But if that is a misunderstanding from my perspective, I still think the > rules will hold. If you don't include the a=3Drtcp attribute, then the > rtp+1 port is the equivalent of the a=3Drtcp value. > > From a bundle perspective, I think what needs to be considered is the > actual or implied values on the m=3D blocks for the rtcp port when using > bundle-only as well as the other case. > > Cheers > > Magnus Westerlund > (As individual) > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- > > --bcaec548661cb3eed504f46b2053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 12, 2014 at 1:16 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
On 2= 014-03-10 21:09, Christer Holmberg wrote:
> Hi,
>
>>>>>>> Before I comment on your proposal, let's t= ake a few steps
>>>>>>> back (maybe it can even solve your issue).
>>>>>>>
>>>>>>> BUNDLE currently mandates the usage of both th= e SDP
>>>>>>> rtcp-mux and rtcp attributes. I remember we ha= d
>>>>>>> discussions about that, but I don't rememb= er the
>>>>>>> justification at the moment. But, I wonder whe= ther that
>>>>>>> text is from before we made a decision that, u= nless both
>>>>>>> endpoints support BUNDLE, no endpoint will use= a single
>>>>>>> address:port.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So, the question is: do we really need the SDP= rtcp
>>>>>>> attribute?
>>>>>>
>>>>>> I think it is a question of how you want the fallb= ack to
>>>>>> work. In the case of bundle only lines, a non =C2= =A0bundle
>>>>>> supporting peer will reject them, thus no issues w= ith what
>>>>>> is written around RTCP-mux and a=3Drtcp in those m= =3D blocks.
>>>>>> However, the first one if you want that to support= fallback
>>>>>> that makes sense then you will need both a=3Drtcp-= mux and an
>>>>>> a=3Drtcp (with a different port) to handle that wi= th optimal
>>>>>> backwards compatibility.
>>>>>>
>>>>>> Regarding the motivation for a=3Drtcp-mux and a=3D= rtcp, I think
>>>>>> it is reasonably straight forward. We want a=3Drtc= p-mux to
>>>>>> minimize port usage, i.e. ports=3D1. Not supportin= g
>>>>>> a=3Drtcp-mux with bundle that would mean two ports= (RTP and
>>>>>> RTCP) for the bundle group. To get the backwards >>>>>> compatibility the usage of a=3Drtcp would be requi= red.
>>>>>
>>>>> Keep in mind that the offerer must always be prepared = that
>>>>> the answerer does not support the rtcp-mux attribute (= or the
>>>>> rtcp attribute).
>>>>
>>>> Yes, that was what I meant with fallback in the above text= .
>>>> What you do in case the peer doesn't support bundle. >>>>
>>>>> So, at least my understanding is: no matter whether BU= NDLE is
>>>>> used or not, if the answer does not contain a rtcp-mux= (e.g.
>>>>> in case of fallback) attribute, the offerer must use t= he
>>>>> default "rtp+1" port.
>>>>
>>>> I have a tendency to agree, which means that the first m= =3D block
>>>> in a bunde-only group will be required to contain a=3Drtcp= and if
>>>> RTCP mux is desired also that attribute.
>>>>
>>>> I think a=3Drtcp could be skipped for a bound-only m=3D bl= ock due
>>>> to the requirement on supporting a=3Drtcp-mux if you do bu= ndle.
>>>
>>> For bundle-only, I actually think BOTH can be skipped, because=
>>> bundle-only will by default use whatever address:port is
>>> negotiated - both for RTP and RTCP.
>>
>> No, I see a path of grief to not explicitly signal things when you=
>> use them.
>
> But, the whole idea of using port zero in bundle-only was that, if
> the answerer supports BUNDLE, port zero will be replaced with the
> negotiated address:port.
>
> When you send the offer, you don't yet know which address:port wil= l
> be selected, so there is no idea to insert a=3Drtcp. Inserting
> a=3Drtcp-mux probably doesn't harm, though, so I won't argue a= bout it
> :)

Well, if you can't insert the port, the same applies to a= =3Drtcp as to the
port in the m=3D line.

Because in the bundle-only case we are assuming and that assumption
needs to apply also for a=3Drtcp. And for a bundle-only case I think the appropriate thing is to assume that a=3Drtcp-mux will be honored. To have it being honored you need explicit signal it. The a=3Drtcp can be
considered redundant in this case, but I am sensitive to removing it as
that would create a special case for a=3Dbundle-only lines. I think it is better to simply include it, even if it will say a=3Drtcp:0

>
>> I also thought the a=3Drtcp-mux is a MUST to implement, not a MUST=
>> use.
>
> Currently the draft says MUST use. But, that may be a mistake, or a > leftover from previous procedures. I agree that one should be able to<= br> > use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports
> for the RTP traffic and the RTCP traffic).

I hope if people disagree that they shout now.
<= br>
I think rtcp-mux has to be a MUST use when BUNDLE is used bet= ween the two endpoints. (If the endpoint doesn't support BUNDLE, rtcp-m= ux is not required.)

Otherwise, you get into weird edge cases, such as where= you have a data channel (no RTCP component), and then want to add audio (w= ith RTP and RTCP components). You could bundle the audio RTP over the exist= ing data channel transport, but it's not clear what you should do with = the RTCP component. Mandating rtcp-mux avoids this issue completely.

>
>>> But, for non-bundle-only, I still ask whether we really need >>> a=3Drtcp. Isn't a=3Drtcp-mux enough? If the answerer suppo= rts it, you
>>> will use it, otherwise you will use rtp+1.
>>
>> My understanding is that a=3Drtcp has been required in any
>> non-private network deployments due to >NATs for the last 10 ye= ars.
>> Thus, I don't see how you can remove them and expect it to wor= k,
>> unless >you are doing a=3Drtcp-mux. Thus, my view would be that= you
>> can remove a=3Drtcp if you know that the >peer supprots a=3Drtc= p-mux.
>
> Are you saying that we should use a=3Drtcp ONLY to indicate the RTP > port, in case the answerer does not support a=3Drtcp-mux?

It has its normal usage, i.e. RTCP port in cases when a=3Drtcp-mux is= not
agreed on. In a bundle-only offer, I think the only reasonable approach
is to handle it identically to the m=3D line port number.

>
>>> Otherwise, assume that the answerer supports BOTH a=3Drtcp and=
>>> a=3Drtcp-mux. Which has higher "priority"? How does = the answerer
>>> knows whether the offerer wants to use rtcp-mux, or whether it=
>>> wants to use whatever port is indicated in a=3Drtcp?
>>
>> That is a=3Drtcp-mux per RFC 5761 that has higher priority, please=
>> see Section 5.1.1.
>
> You are right - my mistake.
>
> But, never the less, if the offerer sends both a=3Drtcp-mux and a=3Drt= cp,
> unless a=3Drtcp points to the rtp port, the offerer needs to be
> prepared to use 3 different ports for RTCP (rtp+1 port, rtp port and > rtp+<a=3Drtcp value>), because it does not know which attribute = (if
> any) the answerer supports, and which (if any) the answerer is
> willing to use.

This is actually not necessary, if one can get the rtp+1 port for RTC= P,
then include that in the a=3Drtcp line and everything is fine.

I was under the impression that almost all SIP SDP O/A was using a=3Drtcp.<= br> But if that is a misunderstanding from my perspective, I still think the rules will hold. If you don't include the a=3Drtcp attribute, then the<= br> rtp+1 port is the equivalent of the a=3Drtcp value.

>From a bundle perspective, I think what needs to be considered is the
actual or implied values on the m=3D blocks for the rtcp port when using bundle-only as well as the other case.

Cheers

Magnus Westerlund
(As individual)

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


--bcaec548661cb3eed504f46b2053-- From nobody Wed Mar 12 11:02:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97D11A063C for ; Wed, 12 Mar 2014 11:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi41usZnLrPd for ; Wed, 12 Mar 2014 11:02:04 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8E81A048A for ; Wed, 12 Mar 2014 11:02:03 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-6e-5320a114ca91 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id DF.D6.04853.411A0235; Wed, 12 Mar 2014 19:01:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Wed, 12 Mar 2014 19:01:56 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "rtcweb@ietf.org" Thread-Topic: Should we reference the pause/resume I-D? Thread-Index: Ac8+HSfEqf9sT+k2TCiwilJvB9C34g== Date: Wed, 12 Mar 2014 18:01:56 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvja7IQoVgg7ubrC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxraH99gLtnFVvP1wjbmB8SRHFyMnh4SAicSqzx9ZIWwxiQv3 1rN1MXJxCAmcYJSY2byTEcJZwihx7fg6dpAqNoFAia37FrCB2CIC6hKXH14AiwsLGEms37eV ESJuLnFxySmoGj2Jkzdug8VZBFQlXn+/BBTn4OAV8JVYvI4fJMwItPj7qTVMIDazgLjErSfz mSAOEpBYsuc8M4QtKvHy8T+oQ5UkFt3+DFWvJ3Fj6hQ2CFtbYtnC12D1vAKCEidnPmGZwCg8 C8nYWUhaZiFpmYWkZQEjyypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMBQP7jlt9EO xpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6Hot8tL2uRINaX6H bNfx3NPe5reeS0rLf7NhWd/WpOsrHrfOfh+RrcNX6zNlTmjxRY3i5k1pW46E3S8tLNudt8iq Jen2Tq9OS//8pX9//37LUGZ0e8f03c8+WhevXBDt83zlc33HSVI9p70eTvn89ke5yHWNRUu/ zl4lFxfK0y68cmdV0/5QGyWW4oxEQy3mouJEAKh63HxDAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h1o Subject: [rtcweb] Should we reference the pause/resume I-D? 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, 12 Mar 2014 18:02:09 -0000 Hi,=0A= =0A= at the IETF last week there was consensus in the AVTEXT WG meeting to=0A= adopt the pause/resume draft [1] as a WG draft.=0A= =0A= In rtcweb/webrtc we're have the situation that we're discussing so =0A= called "doo-hickeys" as an API surface where the web app (amongst other =0A= things) can pause and resume the sending of a track. This can=0A= be signaled with the direction attribute and a SDP O/A exchange (and the = =0A= app pausing/resuming sending of a track would presumably lead to a =0A= "negotiationneeded" event being fired).=0A= =0A= But I think we should in addition require the browser to signal it=0A= according to one of the methods in [1] (e.g. TMMBN =3D 0), and also=0A= understand that signaling (a browser receiving TMMBN =3D 0 must know that= =0A= the other end-point will pause sending).=0A= =0A= My argument is that we know that many dislike SDP in rtcweb, and a=0A= likely development is that it will be removed in a later version. My=0A= speculation is that signaling as outlined in [1] will then be used for=0A= pause/resume. If we support this from the beginning earlier=0A= implementations could more easily interop with those later versions.=0A= =0A= =0A= Stefan=0A= =0A= [1]=0A= https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt= =0A= From nobody Wed Mar 12 12:50:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94151A0473 for ; Wed, 12 Mar 2014 12:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To4jtSlwOgD9 for ; Wed, 12 Mar 2014 12:50:52 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B3C201A0493 for ; Wed, 12 Mar 2014 12:50:51 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so11879803wes.31 for ; Wed, 12 Mar 2014 12:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ea1ROHEmwb7+KAu0IP/Llw05OAC3KvJlpDDVhbGoZAo=; b=zrlD++gQy64gMSNxpk6OgLZAQ/2YNWa5vqLplxb1GUDZ2vpAJS9/u9xtzOKKZcSHhs eSVCH0lHPz7TS7NfOc7KQg76ICdOKbpZhg5zFogWSdLh8i5pHCL4RRYJC1f85jt9nKCQ 4nlKSivyGMFg8UCHNFcmIawz3UYIIVjKf2DGrACceqvtfQkcv4d/QU/WexW+C44J2jF7 PJOuHhTcxQawoZsjqfWkqAHXGh7nQmL+Zwcv/QLFXcwxp/YbmD5IGzsuW/Mlj9DAuR11 ukP1MCSxpN6Jcwf9I/R10dzPYCZfOsKxaP1eEKfeDfIJImZ7IEPB0y8wvFiBUEutRCNh DhlQ== X-Received: by 10.194.85.168 with SMTP id i8mr182540wjz.81.1394653845041; Wed, 12 Mar 2014 12:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.161.66 with HTTP; Wed, 12 Mar 2014 12:50:25 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Wed, 12 Mar 2014 12:50:25 -0700 Message-ID: To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=089e010d7efc04b77d04f46e2726 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NeSoL2hv43RgwnAjSVuRoJF3rdw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 12 Mar 2014 19:50:53 -0000 --089e010d7efc04b77d04f46e2726 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While I do like the pause/resume draft, having core RTCWEB WG documents (such as RTP Usage) depend on it seems like a bit of a stretch. After all, the document was only adopted last week, and it is a rare IETF WG document that can go from a -00 WG draft to publication as an RFC in under a year. On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > Hi, > > at the IETF last week there was consensus in the AVTEXT WG meeting to > adopt the pause/resume draft [1] as a WG draft. > > In rtcweb/webrtc we're have the situation that we're discussing so > called "doo-hickeys" as an API surface where the web app (amongst other > things) can pause and resume the sending of a track. This can > be signaled with the direction attribute and a SDP O/A exchange (and the > app pausing/resuming sending of a track would presumably lead to a > "negotiationneeded" event being fired). > > But I think we should in addition require the browser to signal it > according to one of the methods in [1] (e.g. TMMBN =3D 0), and also > understand that signaling (a browser receiving TMMBN =3D 0 must know that > the other end-point will pause sending). > > My argument is that we know that many dislike SDP in rtcweb, and a > likely development is that it will be removed in a later version. My > speculation is that signaling as outlined in [1] will then be used for > pause/resume. If we support this from the beginning earlier > implementations could more easily interop with those later versions. > > > Stefan > > [1] > https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e010d7efc04b77d04f46e2726 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
While I do like the pause/resume draft, having core RTCWEB= WG documents (such as RTP Usage) depend on it seems like a bit of a stretc= h. After all, the document was only adopted last week, and it is a rare IET= F WG document that can go from a -00 WG draft to publication as an RFC in u= nder a year.


On Wed,= Mar 12, 2014 at 11:01 AM, Stefan H=E5kansson LK <stefan.lk= .hakansson@ericsson.com> wrote:
Hi,

at the IETF last week there was consensus in the AVTEXT WG meeting to
adopt the pause/resume draft [1] as a WG draft.

In rtcweb/webrtc we're have the situation that we're discussing so<= br> called "doo-hickeys" as an API surface where the web app (amongst= other
things) can pause and resume the sending of a track. This can
be signaled with the direction attribute and a SDP O/A exchange (and the app pausing/resuming sending of a track would presumably lead to a
"negotiationneeded" event being fired).

But I think we should in addition require the browser to signal it
according to one of the methods in [1] (e.g. TMMBN =3D 0), and also
understand that signaling (a browser receiving TMMBN =3D 0 must know that the other end-point will pause sending).

My argument is that we know that many dislike SDP in rtcweb, and a
likely development is that it will be removed in a later version. My
speculation is that signaling as outlined in [1] will then be used for
pause/resume. If we support this from the beginning earlier
implementations could more easily interop with those later versions.


Stefan

[1]
https://tools.ietf.org/id/draft-westerlund-avt= ext-rtp-stream-pause-05.txt

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

--089e010d7efc04b77d04f46e2726-- From nobody Wed Mar 12 13:56:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1681A0778 for ; Wed, 12 Mar 2014 13:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 NKNs9HnnQKzz for ; Wed, 12 Mar 2014 13:56:35 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 431EC1A07A5 for ; Wed, 12 Mar 2014 13:56:35 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oz11so86610veb.20 for ; Wed, 12 Mar 2014 13:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BOR7Xc29Fo6JI3Yp4HdxLAMkArNSrzoaTVpCyK4aPoE=; b=ZduWq77590IIcWlG2tSxhKEiof2+ERtc2fm9Lb4JDpfdrhtMg6c1b3VqrjzIU6iU36 GVWUBcoqCHybYMCEpT4CeIpzUDERMGGjRis9/FASFeHqz3nd3HfogHqiI5ocu147lWbD 0BKmKmdazwgJHyv1mn7L931xnqwpdd2CAMGzWnGXWttNt7wJ0/pscWvg98x5UGLHNPc5 clOq8SEw/DiBobvbRt5H4YblS3X93nKohnXStH0xIB7xxDDPe7WRCZphoG1A1ogvpYrs 9pWeGPiEZIzOUk/AHoeMg59PItMwnbvE15libFtVMxDRAcfXtSopZ3t2pirpX2JXjFRz EZCQ== 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=BOR7Xc29Fo6JI3Yp4HdxLAMkArNSrzoaTVpCyK4aPoE=; b=ZKV2x3ksUJHyeV46W5LfXmmmA4v5K6Z+GqdU1I72briQqkGcDYUpg/zqqf5+e9H6KZ dWahxb6+e5rr+I3wLCChnvcmQp+4CW7JLGVRejzi89jRhpTOSGxfQrB+hixSLVXNI28s a5cCNt291oCVr1NFK5ra7dzAsl/ZfZxxy2X7BOEcG1+OjJD9WadL/GsDO+SoinAn6cpi tr/F+30Mbza862neZVeRgeTpqbSHOWWhvegicY3RnVUI3wg99bimJStov2DYLnFy6gfo cZ2ROuzpRN5/bGq6jAAVKu4TCvwS2xYGI4TWgGPrtIBMu/mDq8H5HvsQG8Mr8Ow0tPl6 csQw== X-Gm-Message-State: ALoCoQmWMDKvQhI+9s+hqRABfEYNw0+OLqMLu4pXspDWGdK+xCLbw4cRbsWnx5U4izzFwy1DFLGnwxsKXq7d8+d2OGOPcKDAD+7hyw892BYQkqB1Bvoaa5UwB3+8b/DF1Jf0MQxY6SzZb0d3+WX9VNfb/EFgaPOLanw3yflwwQpL69DdnYWzVfRCyqiXcgoIQus9eOU9kuCR X-Received: by 10.220.92.135 with SMTP id r7mr33521201vcm.11.1394657788763; Wed, 12 Mar 2014 13:56:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 12 Mar 2014 13:56:08 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> From: Justin Uberti Date: Wed, 12 Mar 2014 13:56:08 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b66f5fb153fd804f46f121f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_43IFRknJVW6rN-Pz9WROJnR3-A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 12 Mar 2014 20:56:38 -0000 --047d7b66f5fb153fd804f46f121f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. Aren't there also patent declarations against this doc from multiple holders? While SDP will likely be removed from the API in the future, the replacement would be a app-specific message sent over websockets, which seems like it would work just fine. On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba wr= ote: > While I do like the pause/resume draft, having core RTCWEB WG documents > (such as RTP Usage) depend on it seems like a bit of a stretch. After all= , > the document was only adopted last week, and it is a rare IETF WG documen= t > that can go from a -00 WG draft to publication as an RFC in under a year. > > > On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=C3=A5kansson LK < > stefan.lk.hakansson@ericsson.com> wrote: > >> Hi, >> >> at the IETF last week there was consensus in the AVTEXT WG meeting to >> adopt the pause/resume draft [1] as a WG draft. >> >> In rtcweb/webrtc we're have the situation that we're discussing so >> called "doo-hickeys" as an API surface where the web app (amongst other >> things) can pause and resume the sending of a track. This can >> be signaled with the direction attribute and a SDP O/A exchange (and the >> app pausing/resuming sending of a track would presumably lead to a >> "negotiationneeded" event being fired). >> >> But I think we should in addition require the browser to signal it >> according to one of the methods in [1] (e.g. TMMBN =3D 0), and also >> understand that signaling (a browser receiving TMMBN =3D 0 must know tha= t >> the other end-point will pause sending). >> >> My argument is that we know that many dislike SDP in rtcweb, and a >> likely development is that it will be removed in a later version. My >> speculation is that signaling as outlined in [1] will then be used for >> pause/resume. If we support this from the beginning earlier >> implementations could more easily interop with those later versions. >> >> >> Stefan >> >> [1] >> https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.tx= t >> >> _______________________________________________ >> 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 > > --047d7b66f5fb153fd804f46f121f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed. Aren't there also patent declarations against = this doc from multiple holders?

While SDP will likely be= removed from the API in the future, the replacement would be a app-specifi= c message sent over websockets, which seems like it would work just fine.


On Wed,= Mar 12, 2014 at 12:50 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
While I do like the pause/r= esume draft, having core RTCWEB WG documents (such as RTP Usage) depend on = it seems like a bit of a stretch. After all, the document was only adopted = last week, and it is a rare IETF WG document that can go from a -00 WG draf= t to publication as an RFC in under a year.

On Wed, Mar 12, 2014 at 11:01 AM, Stefan H= =C3=A5kansson LK <stefan.lk.hakansson@ericsson.com><= /span> wrote:
Hi,

at the IETF last week there was consensus in the AVTEXT WG meeting to
adopt the pause/resume draft [1] as a WG draft.

In rtcweb/webrtc we're have the situation that we're discussing so<= br> called "doo-hickeys" as an API surface where the web app (amongst= other
things) can pause and resume the sending of a track. This can
be signaled with the direction attribute and a SDP O/A exchange (and the app pausing/resuming sending of a track would presumably lead to a
"negotiationneeded" event being fired).

But I think we should in addition require the browser to signal it
according to one of the methods in [1] (e.g. TMMBN =3D 0), and also
understand that signaling (a browser receiving TMMBN =3D 0 must know that the other end-point will pause sending).

My argument is that we know that many dislike SDP in rtcweb, and a
likely development is that it will be removed in a later version. My
speculation is that signaling as outlined in [1] will then be used for
pause/resume. If we support this from the beginning earlier
implementations could more easily interop with those later versions.


Stefan

[1]
https://tools.ietf.org/id/draft-westerlund-avt= ext-rtp-stream-pause-05.txt

_______________________________________________
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


--047d7b66f5fb153fd804f46f121f-- From nobody Wed Mar 12 16:14:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6372F1A07A9 for ; Wed, 12 Mar 2014 16:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tjz0vFmKwYFo for ; Wed, 12 Mar 2014 16:14:37 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 441131A0781 for ; Wed, 12 Mar 2014 16:14:37 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id cmyH1n0030Fqzac53nEWkE; Wed, 12 Mar 2014 23:14:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id cnEW1n00Q3ZTu2S3UnEWlf; Wed, 12 Mar 2014 23:14:30 +0000 Message-ID: <5320EA56.1050507@alum.mit.edu> Date: Wed, 12 Mar 2014 19:14:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394666070; bh=SXrvzGS7wSEc4j7XnqvyoSqed6PPdXyQZaZC2PYf89g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j6VAvUWG48/HLvY/nm9jxV8QBdemVWFwlSdQJ3frbhn3quiGR61ywOAEIJQ3xaJ9s WgG7Ba463ZF6Z4TCiMa1lzssZVyFwOJoU58BnMaumQof9t31Ua1zI4VbBCXkfp6O40 ZcQvftQj6ayyTiAmDp6YSI0xYBQ0t7HpKs4qxTzTMsOEa0Hub07/3Bf/XTlXxBvKjR os/K4q2LxFgZKh4rrZ8E+xl8RzsAHHlixzjgbWY/yDS6E/dT0yQO/eGCcQQwL7nsIv AL77ZiqezytVIe/DLnQOmvtEjFR9Z3AI4KW8xhUlLwotPpanolj+GUMxe+RGMZ0465 QuehSOOtsy4qA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Er5wGVALEi989ZM_rX0ANVPxEoc Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 12 Mar 2014 23:14:38 -0000 On 3/10/14 4:09 PM, Christer Holmberg wrote: >> I also thought the a=rtcp-mux is a MUST to implement, not a MUST use. > > Currently the draft says MUST use. But, that may be a mistake, or a leftover from previous procedures. I agree that one should be able to use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports for the RTP traffic and the RTCP traffic). Now that I look carefully, I think you have been a little over zealous about this. Remember, at least in principle, there can be non-RTP m-lines in the bundle. You don't want to require using rtcp-mux with those. (And, at least in principle, bundle can be used even when there are *no* RTP m-lines.) So I think the draft must at least limit these requirements to RTP m-lines. (But finding a clean way to do that may be tricky, since there is a potentially open ended set of values that relate to RTP.) Thanks, Paul From nobody Thu Mar 13 00:31:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B461B1A03BD; Thu, 13 Mar 2014 00:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZdFj11124dT; Thu, 13 Mar 2014 00:31:00 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 510681A0155; Thu, 13 Mar 2014 00:30:57 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403130830476992; Thu, 13 Mar 2014 08:30:47 +0100 From: "Karl Stahl" To: "'Harald Alvestrand'" , "'Colin Perkins'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530D641F.6010504@alvestrand.no> In-Reply-To: <530D641F.6010504@alvestrand.no> Date: Thu, 13 Mar 2014 08:30:47 +0100 Message-ID: <021e01cf3e8e$2752ce10$75f86a30$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021F_01CF3E96.89173610" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8y8zez8ntJdzT0S+yXIDUU2yAcYwJrcLfg Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/D--6f01PvFCrr-YxpV6rbDTUDE8 Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments 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, 13 Mar 2014 07:31:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_021F_01CF3E96.89173610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Harald, =20 The answer to your question 26 of February: > Karl, what on Earth does TRAM milestone 3 have to do with whatever it = is you're proposing? TRAM milestone 3 is: Sep 2014 - Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG > There's no (zero, nada, none) mention of QoS within that charter. --- I didn=92t mention =93QoS=94 (*I want the QoS methods out!*), in my protest/request=20 http://www.ietf.org/mail-archive/web/tram/current/msg00304.html =93It = must be a clear objective of the TRAM WG that ISPs/NSPs are allowed and = encouraged to route quality demanding WebRTC media into their IP pipes that are = capable of transporting real-time traffic without quality issues, using TURN servers.=20 =20 The subject from the TRAM mailing initiation spells out: *Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs* The TRAM WG must assure that TURN servers offered by ISPs/NSPs can be = used for the above purpose. (The objective of the TRAM WG milestone 3 is *not only* to resolve restrictive enterprise NAT/firewall traversal problem using TURN = servers.)=94 =20 However, it is a way of "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff, which = I now have started under=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff =20 You were September 20 actually the first to answer my request for a DHCP provided turn server address (which I withdraw in favor of the anycast method, which is highly preferable): http://www.ietf.org/mail-archive/web/rtcweb/current/msg08920.html=20 =20 There I said: >There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting a =93WebRTC-ready=94 access and we can look forward to = telepresence for everyone. =20 I don=92t really see anyone objecting to those objectives, and I don=92t = think you do either. =20 The Anycast method were suggested October 22 (without further = discussions) http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html=20 and thereafter brought into TRAM WG list February 8=20 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html=20 =20 It took me some time to find the relevant emails from the discussions in September and October which ended up with my entry to the [tram]-list February 8, which is copied in full below, where I still say it was 95% ready (There are a few relevant points from Simon that I will address later). Thereafter, the QoS diversion and confusion started around = February 12th in what looks to me as effort to make it a =93Mission = Impossible=94. =20 I don=92t know how the TRAM WG was created, but I thought Milestrone 3 = was a result of Cullen=92s. See next email in response to Cullen=92s questions = and requests. =20 /Karl =20 Footnote: [1] I think both you (Harald) and Cullen, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned =93by = accident=94 that the TRAM WG was in progress at the November WebRTC conference=94 = and should handle the Auto Discovery of TURN-servers. =20 =20 Fr=E5n: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Skickat: den 8 februari 2014 14:11 Till: 'tram@ietf.org'; 'tireddy@icisco.com'; 'Simon Perreault' =C4mne: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 Karl from Ingate and Intertex just added himself to this list for = exactly the purpose of the subject of Milestone 3 above=20 =20 I welcome this initiative that I saw yesterday after being reminded by = China Mobile Research Institute who had seen the previous October discussion = on the WebRTC-list, parts of which are inserted below. Large carriers have = also expressed the importance of this milestone. -------------------- We are working on this draft, will publish it next week. -Tiru. =20 Great, please consider the input and suggestions below: =20 > -----Original Message----- > From: tram [ mailto:tram-bounces at ietf.org] On Behalf Of Simon Perreault > Sent: Friday, February 07, 2014 7:58 PM > To: tram at ietf.org > Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs >=20 =85 > Enterprises or ISPs wishing to provide > their own TURN server, in an attempt to reduce so-called "triangle routing", > need a new auto-discovery mechanism. --- There are more reasons heard for auto-discovery of a network = provided TURN server: =20 - NSPs (Network Service Providers) want to provide a path where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 - Note that to achieve some of the above points, TURN must be favored = over STUN to enforce that the TURN-path actually is used. (The Anycast method suggested below, =93automatically=94 does this.)=20 =20 -- In my view, a TURN server is the network providers=92 responsibility = to provide (just like the IP address, the default gateway, the DNS etc.) = =96 rather than the application provider=92s. Our current Internet accesses = may not cope with or be optimized for WebRTC usage =96 The NSP (or = Enterprise LAN administrator) should then be able to fix the access (here by offering a TURN server).=20 =20 > IMHO this is also a top-priority milestone. We need to quickly have a > mechanism that people can implement in WebRTC browsers now, while > there is still frenetic development happening.=20 --- Agree I don't foresee actual server- > side deployment happening quickly though. But as soon as clients are ready, > any ISP or enterprise can deploy and immediately benefit. - There is a definitive interest among forward SPs already, especially carriers owning the network. (They have learned that their networks (especially mobile) seem to = become data crowded no matter how much bandwidth they invest in.) =20 > I imagine that the solution will be fairly simple, spec- and implementation- > wise.=20 --- Agree that such solution should and could be found, but it is not obvious. Below you find 3 proposals (initiated by me or colleagues, = where I see flaws in the two first and now only suggest the third (the Anycast mechanism). From below: =20 - 1st: =85 withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that = you then also have to do something similar for: RA - Router Advertisement - = in IPv6, addition to the IPCP protocol for PPPoE and something for the = mobile OTT channel =96 wherever DHCP is NOT the method to give you an IP = address. (There were also concerns whether OSs actually supports forwards such extended DHCP information for the browser to use.) =20 - 2nd Reverse DNS-Based Service Discovery method: Justin Uberti pointed out: How does this get bootstrapped? That is, how = is the STUN server found? [Karl] Oops, that got lost when leaving the DHCP track, and is a problem when using DNS discovery. (There were also hesitations of having to provision this special reverse = DNS for every access.) =20 - 3rd The Anycast method below =96 I see no problem It also has the advantage of encouraging (but not requiring) the = STUN/TURN to be built in the default gateway or NAT/firewall/access router itself, with a second interface to a public IP address on the WAN side. (Current volume deployed, low cost NSP triple play modems usually have a quality assured level 2 or level 3 WAN pipe for just voice (and another for = IPTV) =96 The anycast discovered TURN-server can be the access gateway to such = quality pipe for WebRTC media, in a single NSP provided CPE, scaling from residential and up.) =20 So I think we can finish this very quickly once we have a candidate > draft. We just need authors. So I would target not long after Toronto. >=20 > Simon =20 WEB BROWSER BEHAVIOUR: =20 Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be =93manually=94 configured. It is previously suggested, and to some extent discussed, that the WebRTC = browser should select the TURN server to use in the following priority order, = where ICE would assure that you get some connectivity if several candidates = are found and needs to be tested: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing) 2) TURN server address configured by the network administrator via an = =93admin policy template=94 or a WPAD method as mentioned below 3) TURN server address auto-discovered by the mechanism discussed here 4) TURN server address being supplied by the web application =20 With a good step 3), step 2) becomes obsolete since the network administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.=20 =20 Even if the need for auto-discovery of the TURN server comes from WebRTC usage, a general mechanism that also can be used by SIP clients (and = other protocols using TURN via ICE) is preferable. The anycast method has no application dependence, but e.g. WPAD has (a SIP Client typically does = not have the luxury of a JS engine=85) =20 /Karl =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Harald Alvestrand Skickat: den 26 februari 2014 04:49 Till: Colin Perkins; Karl Stahl Kopia: Magnus Westerlund; rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [tram] [rtcweb] Payload Types assignments =20 Karl, what on Earth does TRAM milestone 3 have to do with whatever it is = you're proposing? TRAM milestone 3 is:=20 Sep 2014 - Send new proposed standard TURN server discovery mechanism = for enterprises and ISPs to IESG There's no (zero, nada, none) mention of QoS within that charter. ------=_NextPart_000_021F_01CF3E96.89173610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Harald,

 

T= he answer to your question 26 of February:
> Karl, what on Earth does TRAM milestone 3 have to do = with whatever it is you're proposing?
TRAM milestone 3 is: Sep 2014 - = Send new proposed standard TURN server discovery mechanism for = enterprises and ISPs to IESG
> There's no (zero, nada, none) = mention of QoS within that charter.

--= - I didn’t mention “QoS” (*I want the QoS methods = out!*), in my protest/request =

= http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = “It must be a clear objective of the TRAM WG that ISPs/NSPs = are allowed and encouraged to route quality demanding WebRTC media into = their IP pipes that are capable of transporting real-time traffic = without quality issues, using TURN servers.

 

The subject from the TRAM mailing initiation spells = out:

*Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs*

The TRAM WG must assure that TURN servers offered by ISPs/NSPs can = be used for the above purpose.

(The objective of the TRAM WG milestone 3 is *not only* to = resolve restrictive enterprise NAT/firewall traversal problem using TURN = servers.)”

 

Ho= wever, it is a way of "Interf= acing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to = lower level's QoS-stuff, wh= ich I now have started under <= /span>

= http://www.ietf.org/mail-archive/web/tram/current/msg00331.h= tml<= /span>

The way to = "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to = interface to lower level's QoS-stuff

 

Yo= u were September 20 actually the first to answer my request for a DHCP = provided turn server address (which I withdraw in favor of the anycast = method, which is highly preferable):

http://www.ietf.org/mail-archive/web/rtcweb/current/msg08920.html =

 

Th= ere I said:

>There are several reasons for a = network service provider to supply a TURN

server as part of his offered = access:

- to keep media paths short, specifically = not sending media outside its own

network to some distant application = provided TURN server

- to support mobility, i.e. you may want = to move from a LAN with a

configured TURN server to accessing via = WiFi or 3G/4G OTT channels

- to offer a media path with better = quality (than best effort data traffic).

Getting a “WebRTC-ready” = access and we can look forward to telepresence = for

everyone.

 

I = don’t really see anyone objecting to those objectives, and I = don’t think you do either.

 

Th= e Anycast method were suggested October 22 (without further = discussions)

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html =

an= d thereafter brought into TRAM WG list February 8 =

= http://www.ietf.org/mail-archive/web/tram/current/msg00132.html =

 

It= took me some time to find the relevant emails from the discussions in = September and October which ended up with my entry to the [tram]-list = February 8, which is copied in full below, where I still say it was 95% = ready (There are a few relevant points from Simon that I will address = later). Thereafter, the QoS diversion and confusion started around = February 12th in what looks to me as effort to make it a “Mission = Impossible”.

 

I = don’t know how the TRAM WG was created, but I thought Milestrone 3 = was a result of Cullen’s. See next email in response to = Cullen’s questions and requests.

 

/K= arl

 

Fo= otnote:

[1= ] I think both you (Harald) and Cullen, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned = “by accident” that the TRAM WG was in progress at the = November WebRTC conference” and should handle the Au= to Discovery of TURN-servers.

 

 

Fr=E5n: Karl Stahl = [mailto:karl.stahl@intertex.se]
Skickat: den 8 februari 2014 = 14:11
Till: 'tram@ietf.org'; 'tireddy@icisco.com'; 'Simon = Perreault'
=C4mne: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and ISPs

 

Ka= rl from Ingate and Intertex just added himself to this list for exactly = the purpose of the subject of Milestone 3 above

 

I = welcome this initiative that I saw yesterday after being reminded by = China Mobile Research Institute who had seen the previous October = discussion on the WebRTC-list, parts of which are inserted below. Large = carriers have also expressed the importance of this = milestone.

--= ------------------

We are working on this draft, will publish it next = week.

-Tiru.

 

Great, please = consider the input and suggestions below:

 

> -----Original Message-----

> From: = tram [mailto:tram-bounces at = ietf.org] On Behalf Of Simon Perreault

> Sent: = Friday, February 07, 2014 7:58 PM

> To: = tram at ietf.org

> Subject: [tram] Milestone 3: TURN server = auto-discovery mechanism for

> = enterprise and ISPs

>

…

> Enterprises or ISPs wishing to = provide

> their = own TURN server, in an attempt to reduce so-called "triangle = routing",

> need a new auto-discovery = mechanism.

--= - There are more reasons heard for auto-discovery of a network provided = TURN server:

 

- = NSPs (Network Service Providers) want to provide a path where the = bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

 

- = Note that to achieve some of the above points, TURN must be favored over = STUN to enforce that the TURN-path actually is used. (The Anycast method = suggested below, “automatically” does this.) =

 

--= In my view, a TURN server is the network providers’ = responsibility to provide (just like the IP address, the default = gateway, the DNS etc.) – rather than the application = provider’s. Our current Internet accesses may not cope with or be = optimized for WebRTC usage – The NSP (or Enterprise LAN = administrator) should then be able to fix the access (here by offering a = TURN server).

 

> IMHO = this is also a top-priority milestone. We need to quickly have = a

> = mechanism that people can implement in WebRTC browsers now, = while

> there = is still frenetic development happening.

--= - Agree

I don't foresee actual server-

> side = deployment happening quickly though. But as soon as clients are = ready,

> any = ISP or enterprise can deploy and immediately = benefit.

- = There is a definitive interest among forward SPs already, especially = carriers owning the network.

(T= hey have learned that their networks (especially mobile) seem to become = data crowded no matter how much bandwidth they invest in.)

 

> I imagine that the solution will be fairly simple, = spec- and implementation-

> wise. =

--= - Agree that such solution should and could be found, but it is not = obvious. Below you find 3 proposals (initiated by me or colleagues, = where I see flaws in the two first and now only suggest the third (the = Anycast mechanism). From below:

 

- = 1st: … withdraw my suggestion to use DHCP to find a = network provider offered TURN server in favor of the DNS-Based Service = Discovery method (inserted last below). The major problem with the DHCP = usage was that you then also have to do something similar for: RA - = Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE = and something for the mobile OTT channel – wherever DHCP is NOT = the method to give you an IP address. (There were also concerns whether = OSs actually supports forwards such extended DHCP information for the = browser to use.)

 

- = 2nd Reverse DNS-Based Service Discovery = method:

Ju= stin Uberti pointed out:  How does this = get bootstrapped? That is, how is the STUN server found?

[K= arl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery.

(T= here were also hesitations of having to provision this special reverse = DNS for every access.)

 

- = 3rd The Anycast method below – I see no = problem

It= also has the advantage of encouraging (but not requiring) the STUN/TURN = to be built in the default gateway or NAT/firewall/access router itself, = with a second interface to a public IP address on the WAN side. (Current = volume deployed, low cost NSP triple play modems usually have a quality = assured level 2 or level 3 WAN pipe for just voice (and another for = IPTV) – The anycast discovered TURN-server can be the access = gateway to such quality pipe for WebRTC media, in a single NSP provided = CPE, scaling from residential and up.)

 

So I think = we can finish this very quickly once we have a = candidate

> draft. = We just need authors. So I would target not long after = Toronto.

> =

> = Simon

 

WE= B BROWSER BEHAVIOUR:

 

Ne= twork provided TURN servers will not appear over night, applications may = for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be “manually” = configured. It is previously suggested, and to some extent discussed, = that the WebRTC browser should select the TURN server to use in the = following priority order, where ICE would assure that you get some = connectivity if several candidates are found and needs to be = tested:

 

1)= TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing)

2)= TURN server address configured by the network administrator via an = “admin policy template” or a WPAD method as mentioned = below

3)= TURN server address auto-discovered by the mechanism discussed = here

4)= TURN server address being supplied by the web = application

 

Wi= th a good step 3), step 2) becomes obsolete since the network = administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.

 

Ev= en if the need for auto-discovery of the TURN server comes from WebRTC = usage, a general mechanism that also can be used by SIP clients (and = other protocols using TURN via ICE) is preferable. The anycast method = has no application dependence, but e.g. WPAD has (a SIP Client typically = does not have the luxury of a JS engine…)

 

/K= arl

 

Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Harald = Alvestrand
Skickat: den 26 februari 2014 04:49
Till: = Colin Perkins; Karl Stahl
Kopia: Magnus Westerlund; = rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: [tram] [rtcweb] = Payload Types assignments

 

Karl,

what on Earth does TRAM milestone 3 have = to do with whatever it is you're proposing?

TRAM milestone 3 is: =

Sep 2014 - Send new proposed standard TURN server discovery = mechanism for enterprises and ISPs to IESG

There's no (zero, = nada, none) mention of QoS within that = charter.

------=_NextPart_000_021F_01CF3E96.89173610-- From nobody Thu Mar 13 00:38:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65F01A0155 for ; Thu, 13 Mar 2014 00:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 SilvHPaftFqz for ; Thu, 13 Mar 2014 00:38:42 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 381F01A08F7 for ; Thu, 13 Mar 2014 00:38:41 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-de-5321607a71d5 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id D3.52.04853.A7061235; Thu, 13 Mar 2014 08:38:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 08:38:34 +0100 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgANKxACAAJwfoA== Date: Thu, 13 Mar 2014 07:38:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D20FDE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <5320EA56.1050507@alum.mit.edu> In-Reply-To: <5320EA56.1050507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvjW51gmKwwcbpTBYrNhxgtVj7r53d gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4v+IEU8FizortP9qZGhgXsHcxcnJICJhI rDu8mxHCFpO4cG89WxcjF4eQwAlGic13JrNCOEsYJZa3PGTpYuTgYBOwkOj+pw3SICLgK9F7 +RxYs7CAscSUzslsEHETibkTX7NA2FkS59YeAYuzCKhKLP5wkQnE5gXqnb37NtSyJ8wSa/bt AiviFNCRaL13mRnEZgS66PupNWANzALiEreezGeCuFRAYsme88wQtqjEy8f/WCFsRYmPr/Yx QtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNkcWpxcW66 kYFebnpuiV5qUWZycXF+nl5x6iZGYMQc3PLbaAfjyT32hxilOViUxHmvs9YECQmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamB0mMr8MbfnvX/Ko7mTeQofL8178+HHwjdsEqdfHs1pFHO501ej a8n1dcm8hoXrrjduYwuLrLG12majkOV+nGdCebjm9cnMrIGb1+x3Ysz9/7NFMaS+pPFkdUJN rdSGR1r2Il1LFzpZsfRfYek5/kI5xoHrdo3gYUOTU0b6LRXVk2f0feSaK6LEUpyRaKjFXFSc CABGBTU3ZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GDm3jQHzh3r4MQr_DdFQA--XZTM Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 13 Mar 2014 07:38:43 -0000 Hi, >>> I also thought the a=3Drtcp-mux is a MUST to implement, not a MUST use. >> >> Currently the draft says MUST use. But, that may be a mistake, or a left= over from previous procedures. I agree that one should be=20 >> able to use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE por= ts for the RTP traffic and the RTCP traffic). > > Now that I look carefully, I think you have been a little over zealous ab= out this. > > Remember, at least in principle, there can be non-RTP m-lines in the bund= le. You don't want to require using rtcp-mux with=20 > those. (And, at least in principle, bundle can be used even when there ar= e *no* RTP > m-lines.) > > So I think the draft must at least limit these requirements to RTP m-line= s. (But finding a clean way to do that may be tricky, since there is a pote= ntially open ended set of values that relate to RTP.) I think it is enough if we limit it to protocols for which the rtcp-mux att= ribute has been defined. I don't think it's up to BUNDLE to generally defin= e for which type of m- lines rtcp-mux can be used, only the (if any) BUNDLE= specific aspects. Regards, Christer From nobody Thu Mar 13 00:57:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEF01A094F; Thu, 13 Mar 2014 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmibw6z-5Jh5; Thu, 13 Mar 2014 00:56:54 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF791A094E; Thu, 13 Mar 2014 00:56:53 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403130856442069; Thu, 13 Mar 2014 08:56:44 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'IESG IESG'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Mar 2014 08:56:44 +0100 Message-ID: <022301cf3e91$c7a31ed0$56e95c70$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0224_01CF3E9A.296786D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgACxezCAB08LAIAOOy+g Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bc0H4TXSP1tETRimFkiIJKzhafs Cc: tram@ietf.org, 'Spencer Dawkins' , rtcweb@ietf.org Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 13 Mar 2014 07:56:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0224_01CF3E9A.296786D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cullen, =20 You may first want to read the previous email to Harald:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00349.html=20 =20 Regarding your request from February 26: > Karl,=20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to be the point of debate, and = what your view is on what we should do. I think that would help make = progress.=20 > Thank you, Cullen =20 I already February 26 started a new thread for the =93mission to bring = quality to real-time traffic over our best effort Internet=94 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1]=20 =20 And from your email February 25 below: > Reading the charter, the above is *not* at all a clear objective of = the WG (note I am not the chair of this WG or the responsible AD).=20 =20 >That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP = for routing updates over TURN it would be within the scope of this charter.=20 =20 >My advice to the responsible AD is recharter this WG before IETF 90 or close it. I would be glad to help write a charter that is not an = infinite blank cheque. =20 I actually thought it was you (Cullen) that at least initiated tram Milestone 3 with Subject: =93TURN server auto-discovery mechanism for enterprise and ISPs=94 [2] =20 After your request http://www.ietf.org/mail-archive/web/rtcweb/current/msg09007.html=20 [Karl, I, had said]=93> I've heard several carries expressing that they = want to provide their own TURN servers with their accesses. =20 [Cullen asked] Any chance you could put me in touch with some of them. = I'd love to get more information on what is needed so we can solve this.=93 =20 The =93 huge European carrier and the cable operators in general =96 = CableLabs=94 that I refer to in http://www.ietf.org/mail-archive/web/tram/current/msg00275.html were = the ones I put you in touch with, and then China Mobile reached out for = getting the auto-discovery mechanism in place: =93Let me also point out draft-deng-tram-isp-turn-00 http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European carrier and = the cable operators in general - CableLabs) have expressed similar concerns = to me *=93This is exactly something we want to work on as the current way = will cause severe problem on traffic when rtcweb applications get popular=94* = is a direct quote from one of those.=93 =20 Whoever you left this to, it somehow appeared as [tram] Milestone 3. [2] =20 The complete Anycast method for auto discovery of ISP=92s TURN servers = was suggested October 22 (without further discussions) http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html=20 and thereafter brought into [tram] Milestone 3 by me February 8=20 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html=20 =20 It took me some time to find the relevant emails from the discussions in September and October which ended up with my entry to the [tram]-list February 8, where I still say it was 95% ready (there are a few relevant points from Simon that I will address later). Thereafter, the QoS = diversion and confusion started around February 12th in what looks to me as an = effort to make it a =93Mission Impossible=94. =20 So referring to http://www.ietf.org/mail-archive/web/tram/current/msg00275.html, step A) = is for the TRAM WG to allow ISPs/NSPs to route quality demanding WebRTC = media into their IP pipes that are capable of transporting real-time traffic, using TURN servers. Step B), how the WebRTC browser shall use the auto discovered TURN server, which I suggested in=20 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html=20 =20 WEB BROWSER BEHAVIOUR: =20 Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be =93manually=94 configured. It is previously suggested, and to some extent discussed, that the WebRTC = browser should select the TURN server to use in the following priority order, = where ICE would assure that you get some connectivity if several candidates = are found and needs to be tested: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing) 2) TURN server address configured by the network administrator via an = =93admin policy template=94 or a WPAD method as mentioned below 3) TURN server address auto-discovered by the mechanism discussed here 4) TURN server address being supplied by the web application =20 may be for the RTCWEB WG rather than TRAM WG to handle. Further I would guess step D) is an AVTEXT WG thing =96 What do you think? =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] I think both you (Cullen) and Harald, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned =93by = accident=94 that the TRAM WG was in progress at the November WebRTC conference and should handle the Auto Discovery of TURN-servers. =20 PS: To avoid being stopped by the =93to many recipients=94 spam filter, = the Guys (including Mary) from=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html=20 and the ones mentioned in the email are copied separately. =20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [ mailto:fluffy@cisco.com] Skickat: den 26 februari 2014 01:49 Till: Karl Stahl Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; David Singer; = Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; Henning = Schulzrinne =C4mne: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 > Karl,=20 =20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to be the point of debate, and = what your view is on what we should do. I think that would help make = progress.=20 =20 > Thank you,=20 =20 > Cullen =20 I just did something like that in: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html=20 Hoping this thread subject amplifies what this SHOULD be about. (An how = it will lead to the summary, after all diversion.) =20 Actually, the outcome of "Interfacing to QoS" will be=20 =20 =20 I challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem = IX78 that implements such CLEAR INTERFACE and the actual QoS methods, for = both the Congestion, Default gateway, Surf Pipe=20 Manipulating the RTP extension header etc etc on 6 USD CPU and also = include the ADSL part where that quality handling is based on heavy 57 bytes chopping up at this exact=20 =20 =20 =20 =20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [ mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 02:06 Till: Karl Stahl; IESG IESG Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo = Camarillo; rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins =C4mne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 =20 On Feb 25, 2014, at 7:02 AM, Karl Stahl < = karl.stahl@intertex.se> wrote: =20 > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers. > =20 =20 Reading the charter, the above is *not* at all a clear objective of the = WG (note I am not the chair of this WG or the responsible AD).=20 =20 That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP for routing updates over TURN it would be within the scope of this charter.=20 =20 My advice to the responsible AD is recharter this WG before IETF 90 or = close it. I would be glad to help write a charter that is not an infinite = blank cheque.=20 =20 =20 =20 =20 =20 ------=_NextPart_000_0224_01CF3E9A.296786D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Cullen,

 

Yo= u may first want to read the previous email to Harald: =

= http://www.ietf.org/mail-archive/web/tram/current/msg00349.html =

 <= /o:p>

R= egarding your request from February 26:
> Karl,

> I am totally lost on this = thread. Could you start a new tmead that summarize what the issues is, = what seems to be the point of debate, and what your view is on what we = should do. I think that would help make progress. =

> Thank you, = Cullen

<= o:p> 

I = already February 26 started a new thread for the = &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;= = http://www.ietf.org/mail-archive/web/tram/current/ms= g00331.html=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] =

<= o:p> 

A= nd from your email February 25 below:

> Reading the charter, the above is *not* at all a clear = objective of the WG (note I am not the chair of this WG or the = responsible AD).

 

>That said, I think you have pointed out this charter is = abysmally vague - it does not say what the WG is not going to do. If I = decided to do BGP for routing updates over TURN it would be within the = scope of this charter.

 

>My advice to the responsible = AD is recharter this WG before IETF 90 or close it. I would be glad to = help write a charter that is not an infinite blank = cheque.

 

I = actually thought it was you (Cullen) that at least initiated tram = Milestone 3 with Subject: “TURN server = auto-discovery mechanism for enterprise and ISPs&#= 8221; [2]

 

Af= ter your request http://www.ietf.org/mail-archive/web/rtcweb/current/msg09007.html = 

[Karl, I, had =
said]“> I've heard several carries =
expressing that they want to provide their own TURN servers with their =
accesses.

 

[C= ullen asked] Any chance = you could put me in touch with some of them. I'd love to get more = information on what is needed so we can solve this.&#= 8220;

 

Th= e “ huge European carrier and the cable = operators in general – CableLabs” that I refer to in = = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html = =A0were the ones I put you in touch with, and then China Mobile reached = out for getting the auto-discovery mechanism in place: = “Let me also point out = draft-deng-tram-isp-turn-00 =A0= http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out = the need and willingness from the ISP/NSP side to do something about QoS = for WebRTC traffic, that they expect to be large and have to bring to = their customers with best QoE. In fact they and some more (a huge = European carrier and the cable operators in general - CableLabs) have = expressed similar concerns to me *“This is exactly something we = want to work on as the current way will cause severe problem on traffic = when rtcweb applications get popular”* is a direct quote from one = of those.&#= 8220;

 

Wh= oever you left this to, it somehow appeared as [tram] Milestone 3. = [2]

 

Th= e complete Anycast method for auto discovery of ISP’s TURN servers = was suggested October 22 (without further = discussions)

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html =

an= d thereafter brought into [tram] Milestone 3 by me February 8 =

= http://www.ietf.org/mail-archive/web/tram/current/msg00132.html =

 

It= took me some time to find the relevant emails from the discussions in = September and October which ended up with my entry to the [tram]-list = February 8, where I still say it was 95% ready (there are a few relevant = points from Simon that I will address later). Thereafter, the QoS = diversion and confusion started around February 12th in what looks to me = as an effort to make it a “Mission = Impossible”.

 

So= referring to = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html, = step A) is for the TRAM WG =A0to allow = ISPs/NSPs to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic, using TURN servers. = Step B), how the WebRTC browser shall use the auto discovered TURN = server, which I suggested in

= http://www.ietf.org/mail-archive/web/tram/current/msg00132.html =

 

WEB BROWSER BEHAVIOUR:<= /span>

 

Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions = where the TURN server address is preferred to be “manually” = configured. It is previously suggested, and to some extent discussed, = that the WebRTC browser should select the TURN server to use in the = following priority order, where ICE would assure that you get some = connectivity if several candidates are found and needs to be = tested:

 

1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an = “admin policy template” or a WPAD method as mentioned = below

3) TURN server address auto-discovered by the mechanism discussed = here

4) TURN server address being supplied by the web = application

 

ma= y be for the RTCWEB WG rather than TRAM WG to handle. Further I would = guess step D) is an AVTEXT WG thing – What do you = think?

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] I think both you (Cullen) and Harald, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned = “by accident” that the TRAM WG was in progress at the = November WebRTC conference and should handle the Auto Discovery of = TURN-servers.

 

PS= : To avoid being stopped by the “to many recipients” spam = filter, the Guys (including Mary) from

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html =

an= d the ones mentioned in the email are copied = separately.

 

-----Ursprungligt meddelande-----

Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]

Skickat: den 26 = februari 2014 01:49

Till: Karl = Stahl

Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org;= Bernard Aboba; David Singer; Harald Tveit Alvestrand; Marc Robins; Eric = Burger; Mary Barnes; Henning Schulzrinne

=C4mne: Re: [rtcweb] [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

 

> = Karl,

 

> I am totally lost on this thread. Could you start a new tmead that summarize what the issues = is, what seems to be the point of debate, and what your view is on what = we should do. I think that would help make progress. =

 

> Thank you,

 

> = Cullen

 

I just did something like that in:

[tram] [rtcweb] The way to "Interfacing to = QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower = level's QoS-stuff

= http://www.ietf.org/mail-= archive/web/tram/current/msg00331.html

Hoping this thread subject amplifies what this = SHOULD be about. (An how it will lead to the summary, after all = diversion.)

 

Actually, the outcome of "Interfacing to = QoS" will be

 

 

I = challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to = QoS" that we have the tiny ADSL modem IX78 that implements such = CLEAR INTERFACE and the actual QoS methods, for both the Congestion, = Default gateway, Surf Pipe

Manipulating the RTP extension header etc etc on 6 = USD CPU and also include the ADSL part where that quality handling is = based on heavy 57 bytes chopping up

=A0=A0 at this exact

 

 

 

 

-----Ursprungligt meddelande-----

Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]

Skickat: den 26 = februari 2014 02:06

Till: Karl = Stahl; IESG IESG

Kopia: Magnus = Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo; rtcweb@ietf.org; tram@ietf.org;= Spencer Dawkins

=C4mne: Re: = [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification = regardig Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

 

 

 

On Feb = 25, 2014, at 7:02 AM, Karl Stahl <karl.stahl@intertex.se> wrote:

 

> = To the TRAM WG and RTCWEB WG and ADs:

>=A0

> = It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP = pipes that are capable of transporting real-time traffic without quality = issues, using TURN servers.

>=A0

 

Reading the charter, the above is *not* at all a = clear objective of the WG (note I am not the chair of this WG or the = responsible AD).

 

That = said, I think you have pointed out this charter is abysmally vague - it = does not say what the WG is not going to do. If I decided to do BGP for = routing updates over TURN it would be within the scope of this charter. =

 

My advice to the responsible AD is recharter this = WG before IETF 90 or close it. I would be glad to help write a charter = that is not an infinite blank cheque.

 

 

 

 

 

------=_NextPart_000_0224_01CF3E9A.296786D0-- From nobody Thu Mar 13 01:27:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3911A096F; Thu, 13 Mar 2014 01:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-cp3xrKI_FX; Thu, 13 Mar 2014 01:26:59 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2E1A095A; Thu, 13 Mar 2014 01:26:57 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403130926480855; Thu, 13 Mar 2014 09:26:48 +0100 From: "Karl Stahl" To: "'Pal Martinsen \(palmarti\)'" , "'Colin Perkins'" , "'Magnus Westerlund'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Mar 2014 09:26:49 +0100 Message-ID: <022d01cf3e95$fafd57b0$f0f80710$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_022E_01CF3E9E.5CC1BFB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMa7rPKSdbWG+c0KNNHF0bIvNNJrGUOCAgBSaP9A= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ae0n1il_-oPBGkfZPnHgOcuGusw Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] RTP header extension for "Interfacing to QoS" WAS: I-D Action: draft-thomson-tram-turn-bandwidth-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: Thu, 13 Mar 2014 08:27:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_022E_01CF3E9E.5CC1BFB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_022F_01CF3E9E.5CC1BFB0" ------=_NextPart_001_022F_01CF3E9E.5CC1BFB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the =93mission to bring quality to real-time traffic over our best = effort Internet=94 I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] =20 =20 *SUMMARY* to be brought into the common "Interfacing to QoS"-thread (From there it will be clearer how to split =93Interfacing to QoS=94 = into [tram], [rtcweb] and [avtext]-threads.) =20 The steps A), B) to D) for achieving the mission: http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =20 a: Step D) using the RTP extension header RCF5285 (that works for all IP network types) can obsolete step C) (Using STUN-attributes which is an incomplete transfer of traffic info to the network level.) We need = traffic info (bandwidth and type) that is unchanged through various networks and = can be read and used by network elements (here in a TURN-server flow) and = for traffic in both directions. =20 b: Here it is only discussed for RTP (not for the data channel), but it could be good to also consider this for the webrtc data channel. I will discuss that in next email responding to Magnus=92 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html coming soon. =20 c: How to find and pick out the traffic information from the RTP = extension header when RCF 5285 is used for this purpose is trivial, especially = when =93in-band=94 in a known TURN-flow.=20 =20 There are further detail in-line below for P=E5l, Colin, Magnus and = other interested. =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] Here it is about recreation of the idea/intention of the RTP payload type (PT) header that is not available for the network level anymore, by instead having the application/browser filling the RTP header extension = with relevant traffic info that all IP network types can use. There will be = more detail in the response to Magnus=92 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html coming soon. =20 Fr=E5n: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Skickat: den 25 februari 2014 13:48 Till: Karl Stahl Kopia: tram@ietf.org; rtcweb@ietf.org; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 On 24 Feb 2014, at 23:22 pm, Karl Stahl < = karl.stahl@intertex.se> wrote: =20 Hi P=E5l, =20 You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =20 Sorry about that. I did not notice any clear items to answer or comment = on.=20 [Karl -regarding =93Interfacing to QoS=94] From what you answer below, I conclude: a: step D) (that works for all IP network types) can obsolete step C) = (using STUN-attributes which is an incomplete transfer of traffic info to the network level) (We need a quality marking that is unchanged and can be = read and used throughout various networks and for traffic in both = directions). b: here it is only discussed for RTP (not for the data channel, but I = will discuss that in next email responding to Magnus. c: you have hesitations how to find and pick out the traffic information from the RTP extension header when RCF5285 is used for this purpose, but that is trivial, especially when =93in-band=94 in a known TURN-flow. See = further below. =20 =20 (DISCUSS/MALICE) by allowing the application/browser to transfer = relevant real-time traffic information (types and bandwidth) into every RTP = package by using the already IETF standardized RTP extension header RCF 5285, = which could be used by any current or future Internet (including OTT) network where WebRTC real-time traffic may flow. It seems to have been = standardized already 2008 to allow such usage. whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already 2008 to = allow such usage. =20 [P=E5l] draft-martinsen-tram-discuss is intended to solve internal = application stream prioritisation pr flow, i.e. it is more important for me to get = the video stream across than my application stream at this moment in time. = Its intention is to describe the 5-topple the STUN message was sent on.=20 =20 Moving to a pr packet prioritisation is interesting as it can solve the bundle problem, and mark the relative importance of specific video = frames (I-Frames for example). Since its pr packet the network element might = not keep stream state so it might be easier that way. But the information = needs to be in a fixed offset for quick network element processing. And we = want to describe other streams than just RTP. That makes RTP header extensions unsuitable.=20 =20 QoS related step C) draft-martinsen-tram-discuss can then be taken out = of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere. =20 [P=E5l] I was hoping to argue that the draft is only new signalling of = old concepts (DSCP and ECN). In the end it is the WG that decides if there = is enough interest.=20 =20 =20 I have repeated my suggestion to RTCWEB WG from the October discussions = on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC5285, where traffic information in RTP packets = simply would be filled by any browser under any OS. =20 Without step B), TRAM =93Enforcing the real-time traffic through the offered/discovered TURN servers=94, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used = (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT. =20 [P=E5l] If both clients supports draft-martinsen-tram-discuss you would = get an bi-directional end to end description of the flow that works through = NAT. The information in the STUN packet can be used to remark DSCP bits to whatever values that is of best use for the network the packet is = flowing though. [Karl] Again, this is only applicable for all-diffserve networks and you cannot even route the flow to a quality pipe, not even a duplicate pipe = that is not the default gateway surf pipe (which is a very common method used = for VoIP). =20 [P=E5l] I dont see how TURN gives that ability.=20 [Karl - ???] Haven=92t we many times agreed that you can add exactly the = same STUN-attributes to the TURN allocate request AND in addition to that, control where the flow goes? BUT THIS IS ALSO INSUFFICIENT.=20 I discarded such (similar) interface to QoS already October 22 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 =85 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =85 [P=E5l] Once the channel is bound you only have a channel number in = front of the UDP payload. And TURN is designed to carry alls sort of traffic. For this to work there must be some sort of only webRTC traffic is allowed through this TURN server. (And Ill bet bitorrent or others find a way to mimic webRTC to set up only a data channel..) [Karl] I owe Simon a response to misuse of prioritized channels =96 will = do later after first collecting these diversions. This has nothing to do = with STUN vs TURN! TURN just gives the addition of ALSO directing the flow. = In both cases it is insufficient to transfer traffic info in the STUN/TURN attributes. =20 That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers. I know a few of you Cisco guys are among the ones that have been = fighting against the general =93it is all about bandwidth=94 and =93it will go = away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but = the pointers given in the current QoS discussion within TRAM: =20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. =20 (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no = extra cost, *by proprietary usage* of RFC5285 by browsers. =20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explainations about QoS methods and their implementation were = given a few days ago in: http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =20 (i), (ii) and (iii) will *seriously delay* usage of telepresence capable = and quality demanding WebRTC (bandwidth being around 30 times higher over = best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 Below you are giving pointers saying =93They are currently working on a problem-statement draft and a use-case draft, any input to those would = be very helpful.=94 Those are unnecessary, risking leading to (i), (ii) and = (iii) above. =20 [P=E5l] We find them quite useful. It allows us to engage with potential = users and see if there are real problems to solve. If the customer/users do = not see a problem there is little incentive for us to invest in creating a solution that nobody wants. That said, it is always the danger of = crating a to complicated solution that solves to many problems. =20 [Karl] This is QoS stuff. Let=92s stick to =93Interfacing to QoS=94 and = with a general interface, that the =93QoS device including the TURN server=94 = should be able to do whatever network QoS-method you arrive at. So are pointers such as: =93RMCAT where congestion avoidance for RTP is = being developed=94. TRAMs Milestone 3 is for the purpose of directing = real-time traffic where congestion control isn=92t already in place. Using RFC5285 available since 2008, to fill traffic information in RTP packets (step = D)) is probably a necessity for most future =93congestion control=94 = discussed. =20 [P=E5l] There are some good example of RTP header extension usage. For = example draft-avtext-berger-framemarking. But that information may very well be encrypted and unavailable to the network element. [Karl] You (P=E5l), Colin and Magnus seem to worry about trivial things = when using the RTP header extension, for transferring traffic information = from the application (here browser) to the network level. Don=92t worry! J = These are really trivial things : - If we select to use the RTP extension header RCF5285 for this purpose, = it should of course NOT use RFC6904 encryption, since it is meant for = network level reading/usage! - Finding the RTP header extension (especially when =93in-band=94 in a = known TURN-flow) is really trivial. =20 Linking each RTP-flow by its SSRC and sequence number, and picking = exactly the right traffic type and bandwidth parameters is no problem (I am not aware of any =93Zero CPU=94 DPI device that needs to be considered =96 = But if we can ease the job, we should.) This link shows much more advanced things are available in Cisco = devices:=20 http://www.cisco.com/en/US/products/ps6616/products_white_paper09186a0080= 110 040.shtml#wp39132=20 and the ADSL 2+ modem doing a lot of advanced QoS-stuff, described in=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html=20 is our Intertex/Ingate IX78, just powered by a 6 USD 264 MHz ARM ADSL = chip set CPU and we have implemented a check box TO REMOVE the RTP Header extension (for the ugly reason that the ITSP=92s billing system requires = G.711 VoIP packets of a certain length) =96 It does not take noticeable CPU = power to do this at 100 Mbps wire speed!=20 /Karl=20 .-. P=E5l-Erik This chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to: http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos focusing on DSCP-mapping without even mentioning RFC 5285 available = since 2008, to fill traffic information in RTP packets where it is a = necessity and will allow: (1) applications to directly convey QoS related real-time traffic info = to the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS methods = for the particular network* for (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of using the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place, market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. l Please see further emails soon following this one, for details and = history. =20 /Karl =20 Fr=E5n: tram [ = mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen (palmarti) Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working = on a problem-statement draft and a use-case draft, any input to those would = be very helpful. ( = http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik ------=_NextPart_001_022F_01CF3E9E.5CC1BFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;I have started = = http://www.ietf.org/mail-archive/web/tram/current/msg00331.h= tml=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] [2]=

 

 

*S= UMMARY* = to be brought into the common "Interfacing to = QoS"-thread

(F= rom there it will be clearer how to split “Interfacing to = QoS” into [tram], [rtcweb] and = [avtext]-threads.)

 

Th= e steps A), B) to D) for achieving the mission:

= http://www.ietf.org/mail-archive/web/tram/current/msg00273.html<= /o:p>

 

a:= Step D) using the RTP extension header RCF5285 (that works for all IP = network types) can obsolete step C) (Using STUN-attributes which is an = incomplete transfer of traffic info to the network level.) We need = traffic info (bandwidth and type) that is unchanged through various = networks and can be read and used by network elements (here in a = TURN-server flow) and for traffic in both = directions.

 

b:= Here it is only discussed for RTP (not for the data channel), but it = could be good to also consider this for the webrtc data channel. I will = discuss that in next email responding to Magnus’ http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html = coming soon.

 

c:= How to find and pick out the traffic information from the RTP extension = header when RCF 5285 is used for this purpose is trivial, especially = when “in-band” in a known TURN-flow.

 

Th= ere are further detail in-line below for P=E5l, Colin, Magnus and other = interested.

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] Here it = is about recreation of the idea/intention of the RTP payload type (PT) = header that is not available for the network level anymore, by instead = having the application/browser filling the RT= P header extension with relevant traffic info that all IP network types = can use. There will be more detail in the response to Magnus’ http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html = coming soon.

 

Fr=E5n: Pal = Martinsen (palmarti) [mailto:palmarti@cisco.com]
Skickat: den = 25 februari 2014 13:48
Till: Karl Stahl
Kopia: = tram@ietf.org; rtcweb@ietf.org; Oleg Moskalenko; Alan Johnston; Yoakum, = John H (John)
=C4mne: Re: [tram] [rtcweb] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

On 24 Feb 2014, at 23:22 pm, Karl = Stahl <karl.stahl@intertex.se> = wrote:

 

Hi= P=E5l,

&n= bsp;

Yo= u did not comment nor answer, in response to any = of:

= http://www.ietf.org/mail-archive/web/tram/current/= msg00275.html

= http://www.ietf.org/mail-archive/web/tram/current/= msg00273.html

 

Sorry about that. I did not notice any clear items to = answer or comment on. 

[Karl = -regarding “Interfacing to QoS”] From what you answer below, = I conclude:

a: step D) (that works for all IP network types) = can obsolete step C) (using STUN-attributes which is an incomplete = transfer of traffic info to the network level) (We need a quality = marking that is unchanged and can be read and used throughout various = networks and for traffic in both directions).

b: here it = is only discussed for RTP (not for the data channel, but I will discuss = that in next email responding to Magnus.

c: you have = hesitations how to find and pick out the traffic information from the = RTP extension header when RCF5285 is used for this purpose, but that is = trivial, especially when “in-band” in a known TURN-flow. See = further below.

 

 

(D= ISCUSS/MALICE) by allowing the application/browser to transfer relevant = real-time traffic information (types and bandwidth) into every RTP = package by using the already IETF standardized RTP extension header RCF = 5285, which could be used by any current or future Internet (including = OTT) network where WebRTC real-time traffic may flow. It seems to have = been standardized already 2008 to allow such usage.



wh= ether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the = application/browser to transfer relevant real-time traffic information = (types and bandwidth) into every RTP package by using the already IETF = standardized RTP extension header RCF 5285, which could be used by any = current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already = 2008 to allow such usage.

&n= bsp;

[P=E5l] draft-martinsen-tram-discuss is intended to solve internal = application stream prioritisation pr flow, i.e. it is more important for = me to get the video stream across than my application stream at this = moment in time. Its intention is to describe the 5-topple the = STUN message was sent on. 

 

Moving to a pr packet prioritisation is interesting as = it can solve the bundle problem, and mark the relative importance of = specific video frames (I-Frames for example). Since its pr packet the = network element might not keep stream state so it might be easier that = way. But the information needs to be in a fixed offset for quick network = element processing. And we want to describe other streams than just RTP. = That makes RTP header extensions = unsuitable. 

 

Qo= S related step C) draft-martinsen-tram-discuss ca= n then be taken out of TRAM, and step D) (that was never intended to be = handled by TRAM anyway) will be handled = elsewhere.

 

[P=E5l] = I was hoping to argue that the draft is only = new signalling of old concepts (DSCP and ECN). In the end it is = the WG that decides if there is enough = interest. 

 

&n= bsp;

I = have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] [mmusic]&n= bsp;li= sts http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09129.html to introduce the QoS related = step D) into draft-ietf-rtcweb-rtp-usage sug= gesting usage of RFC5285, where traffic information in RTP packets = simply would be filled by any browser under any OS.

&n= bsp;

Wi= thout step B), TRAM “Enforcing the = real-time traffic through the offered/discovered TURN servers”, = the real-time traffic may happen through the IP default gateways often = congested by data traffic and QoS insensitive streaming video and file = sharing. Without specific QoS methods at those points, the network raw = bandwidth capacity may have to be 10-folded to achieve sufficient QoE = when WebRTC usage becomes popular. Methods like DISCUSS addresses such = things occurring when STUN instead TURN is used (by allowing flows into = such congestion points), but only provides direct traffic info for = outgoing (not incoming) real-time traffic and locally, therefore are not = even applicable to reservation type of networks like Cable Networks and = Mobile OTT.

 

[P=E5l] = If both clients supports = draft-martinsen-tram-discuss you would get an bi-directional end to end = description of the flow that works through = NAT.

The = information in the STUN packet can be used to remark DSCP bits to = whatever values that is of best use for the network the packet is = flowing though.

[Karl] = Again, this is only applicable for all-diffserve networks and you cannot = even route the flow to a quality pipe, not even a duplicate pipe that is = not the default gateway surf pipe (which is a very common method used = for VoIP).

 

[P=E5l] I = dont see how TURN gives that ability.

[Karl - = ???] Haven’t we many times agreed that you can add exactly the = same STUN-attributes to the TURN allocate request AND in addition to = that, control where the flow goes?

BUT THIS IS = ALSO INSUFFICIENT.

I discarded such (similar) = interface to QoS already October 22

http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg09129.html

…

PS Microsoft seems to have done work in this field, defining a = proprietary attribute “MS Service Quality”; =

However that seems to apply to the TURN server allocation request and = would therefore:

--- Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and

--- Does not handle = the bandwidth requirement for incoming real-time traffic (required to = reserve in RSVP type of networks)

However the quality attributes conveyed and their encoding may=A0 be = considered.

This is 2.2.2.19 MS-Service Quality Attribute from =

http://msdn.microsoft.com/en-us/library/cc431507(= v=3Doffice.12).aspx

…

[P=E5l] Once the channel = is bound you only have a channel number in front of the UDP payload. = And TURN is designed to carry alls sort of traffic. For this to = work there must be some sort of only webRTC traffic is allowed through = this TURN server. (And Ill bet bitorrent or others find a way to mimic = webRTC to set up only a data channel..)

[Karl] I owe Simon a response to misuse of prioritized channels – = will do later after first collecting these diversions. This has nothing to do with STUN vs = TURN! TURN just gives the addition of ALSO directing the flow. In both = cases it is insufficient to transfer traffic info in the STUN/TURN = attributes.
&n= bsp;

Th= at would leave certain network types to investing in raw bandwidth = increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable = for the carriers when delivering to their = customers.

I = know a few of you Cisco guys are among the ones that have been fighting = against the general “it is all about bandwidth” and = “it will go away with time”-attitude within IETF work, e.g. = see http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09031.html, but the pointers given in the current QoS = discussion within TRAM:

&n= bsp;

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time = traffic.

&n= bsp;

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. All networks will *also be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time = usage

(<= b>*by resisting TRAM implementation of step = B*)

Ne= wer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC5285 by browsers.

&n= bsp;

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may has to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

&n= bsp;

Fu= rther explainations about QoS methods and their implementation were = given a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/= msg00274.html

&n= bsp;

(i= ), (ii) and (iii) will *seriously delay* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

&n= bsp;

Be= low you are giving pointers saying “They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful.&#= 8221; Those are unnecessary, risking leading to (i), (ii) and (iii) = above.

&n= bsp;

[P=E5l] = We find them quite useful. It allows us = to engage with potential users and see if there are real problems to = solve. If the customer/users do not see a problem there is little = incentive for us to invest in creating a solution that nobody wants. = That said, it is always the danger of crating a to complicated solution = that solves to many problems.  

[Karl] This = is QoS stuff. Let’s stick to “Interfacing to QoS” and = with a general interface, that the “QoS device including the TURN = server” should be able to do whatever network QoS-method you = arrive at.

So= are pointers such as: “RMCAT where = congestion avoidance for RTP is being developed&#= 8221;. TRAMs Milestone 3 is for the purpose of directing real-time = traffic where congestion control isn’t already in place. Using = RFC5285 available since 2008, to fill traffic information in RTP packets = (step D)) is probably a necessity for most future “congestion = control” discussed.

&n= bsp;

[P=E5l] = There are some good example of RTP header = extension usage. For = example draft-avtext-berger-framemarking. But that information may = very well be encrypted and unavailable to the network = element.

[Karl] You (P=E5l), Colin and = Magnus seem to worry about trivial things when using the RTP header = extension, for transferring traffic information from the application = (here browser) to the network level. Don’t worry! J =A0These are really trivial things = :

- If we select to use the RTP extension header = RCF5285 for this purpose, it should of course NOT use RFC6904 = encryption, since it is meant for network level = reading/usage!

- Finding the RTP header extension = (especially when “in-band” in a known TURN-flow) is really = trivial. =A0

Linking each RTP-flow by its SSRC = and sequence number, and picking exactly the right traffic type and = bandwidth parameters is no problem (I am not aware of any “Zero = CPU” DPI device that needs to be considered – But if we can = ease the job, we should.)

This link shows much more advanced things are = available in Cisco devices:

http://www.cisco.com/en/US/products/ps6616/= products_white_paper09186a0080110040.shtml#wp39132 =

and the ADSL 2+ modem doing a lot of advanced = QoS-stuff, described in

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html =

is our Intertex/Ingate IX78, just powered by a 6 = USD 264 MHz ARM ADSL chip set CPU and we have implemented a check box TO = REMOVE the RTP Header extension (for the ugly reason that the = ITSP’s billing system requires G.711 VoIP packets of a certain = length) – It does not take noticeable CPU power to do this at 100 = Mbps wire speed!

/Karl =

.-.

P=E5l-Erik



Th= is chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:

= http://datatracker.ietf.org/doc/draft-dhesikan-tsv= wg-rtcweb-qos

fo= cusing on DSCP-mapping without even mentioning RFC 5285 available since = 2008, to fill traffic information in RTP packets where it  is a = necessity and will allow:

(1= ) applications to directly convey QoS related real-time traffic info to = the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS = methods for the particular network* = for

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of using the Internet (including = OTT).

&n= bsp;

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for current = and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09129.html

<snip><= /span>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic = scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 =

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

&n= bsp;

Th= en this could be assigned numbers to have the RFC in = place.

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it = MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

&n= bsp;l

Pl= ease see further emails soon following this one, for details and = history.

&n= bsp;

/K= arl

&n= bsp;

Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen = (palmarti)
Skickat: den 21 februari 2014 = 10:37
Till: tram@ietf.org
Kopia: Karl Stahl; Oleg Moskalenko; = Alan Johnston; Yoakum, John H (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

Hi,

 

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

------=_NextPart_001_022F_01CF3E9E.5CC1BFB0-- ------=_NextPart_000_022E_01CF3E9E.5CC1BFB0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAVUAAADlCAIAAABs0/O4AAAAAXNSR0IArs4c6QAAjaNJREFUeF7t vQeAXFX1Pz6zfVM3vZAQ0nsgECCQRHoNoQnoFxGQPyihRBBE/Yl0xIYgloggUhRpAtKRXmJCM5SQ nmwa6b1v/5/z+Zx735vZmd3ZtC15Ly+zb968d8u5p99zz4237dC9sqK8srJCzpJYeSyzI44jxj9y ZGXJmSV35D9+kJ/kIziqqpdbFdN/sViVHvjDD/zjTf7hhbufWQN39ClrfAzt9x1BT7R9bIg2lF/1 Qh+1j8RarcnopB32NIEDSLm341ay66uBJQXcdrRr/j0MD3qHNrDx/LcbDjfMBjyOcwDM3VBjqFuG otY7Anxnu4khceMSjA+75fF5j3RzB4CXVymkmp2dnQOCzYoXte0ilL+9qrRls2YTvv/9iy68sPZC HeIY/pLkSfnAaP8vDCkDDksPYBUAjfcd3MgMjBcYdyALSCw0TWulGY4yQ3iPezX0D795kiBheLpw 5I+SjXUBm9IQTkD+vsnAEeCgNYPoaOylqqoSdcincT3fYUIlfCTfSUDI6thpPXf99yzAmHiYI7AW ttIdQRdTg8/A7eii2kMGgRDLZ8k2nAk9SwBncknyvX2bou9+93uPPPRgDQO5Az/94U9/uuKyy3bg xXSv/OUH47/724m7sMCdKeqCsSf85dkX7vzdPXJs2rIlp1J4QE5WVna8VVHHkrKtN95805HHHv/B tC+/WrnSRiYB4fjFEFflfXZWdk5udm5Odk5Odm5eXn5eTn5+bn5BTl6u8Bb9OScrFs+iqORHpRKz fug1DvvDi4oK/1Wu5SwvK5f/FeXlleVyIXfK5ab8Im87AgyxAiCg4az8kWpMxgVt1nvG/o01GDXI 49o7VV+kzXFtf048JxsX2TE9c6S0qsqKKmmkdKGiIlZZEddmaEuEk6r+k50t3BToDCquikkP5BXf ZrkybpatvDImn9nxKjmlUvkai1VIX0vLK6TXpbwoq5TPisqYVAgQeTXJFCbTRbzIIYSNhTreaYqK fHWaDRqro5abLYOVkytHdl5OTq7+FxDI0IEnyPAF/7yGk8Au5CnA2T70EiQtUKzCP469NlzaLx8V OpQCQ/koK8NPel/+geSrOADSA4EkOJARv8gp+dXJ7vjl3zj7/Asv/Ndjjy1avjzEHhzv9n9FvkHC yYhqb3Cl/TL2lsBZ2rdu9ciDD1522WULtEyHMyE5lsgOQ5QY4u1edMlgtWvd6vVf3HjSd763afZ0 eTrbMVS9AJRyUIa0Bg2qlE+ImrRHkuQCisUqUYYAmtfyWQF5UqknqhE8rIo123e/G2+95f9NfOC9 Tz8fMbD/G6++evNNN+bEcwUPskTy33jzzb2HHfD0W2954k9sRaLoMUhQ3CvCCMZk5eQKIuXk5+bk 5ekp7EBYQn6ecAa5kDtZgmS5OfJYVk6O0JVQS1zpRbENgyQlgN7wkzZLqEp/kv8yePqAchMOotoZ wE4eghz4BRc6znriFUEZoy6lTJok+gAKhMIiz8tjfFnusBDoMtXGwd9HpdnyonYBDQQtgZyU/eXl 5sqncEa5g/5K1/QZuZYu4xVBSK3C2oKmZqGpRl7srrZNx1JbLVShFMBRp7ouzcZNULj8pN2RT/0V vcYFP8G65RkpqEqLjQt3k4Yp8ctIFeTnFRTmFxbmtWiW36J5XrNmec1byEWB/2zePL+5fG1ewJv4 mt+smZx5LeS6RYG+KJ9y3Uwf0PvN8gub5RUW6nWzQik/t7Agt6AgOy9fWI/ULvABDHWMFE0Be+0R L7S1QGScwD8j6zT0YeNl6hr+ODVOmYknfoezhjsBCsWNYIBaVGYBKLbAlRtcG7XyV/7uHybnilcJ 5QlrKy+PqRgTbl4WKyurKCupKiuJlZVWlpXGyksry0uryuVChVwVPtOdVSr/gpNfY3qGyikri4vY 0MJLqkq1RuGzUnulCFDhB/H4ijVrX3x/8sADR9x88y0V2SJySrNE7T/yuOM+/lK5VHAYLzdeGTCm sG6GniuOkgUIiiuWC97niCSRC6C+3BTsV4MDDxmZGe2SXEne8ul5gbIGvAKCIf3rhTwABkDGYXwB 9ZOe0R7HFMidwDVI2KBtjI2dykT0DkmCVG1sBQTjrTxQkIpQIJJyINOepKO5WdJfI/6cLKV8yFVw AfmJkjYrV+hNSU65m3I0MrVsKctLTZC51gC25RiZSmMlEtVEwLmUhtFKzy/wMMmekGRP2Sm+K8BB jVo5+KwQobQtPy9bGHRBvlBmrlBpoVBpoV40l89metGMX4WGm+c1b54rZwvhDnJdKCxA7gt55zaX x+QBua9nLj6lKN7JLWyWI8TfTIg/XzREEQxSo8AhxmYAKTzXZo+0naaMqT6DQTSKgoqnpI5b+GdM wlinQ2ASoLEAe8ZLDLIGStuQzBXFJCyAnfWmIx/673HC00qiEsoi0MhKIbxK+SgtLy2rKlWCB7UL LYLUK4QslTiFNVRVlAktVgolpz/BJoJTipJ3q+QsK68sK4/hUwrkV9GwqkTDEuJXjlMWV421HEik kvWzOfOPOfGkls2bCa+J3/yLX7bqtu/SVau8iRbmAiHRDwXERkLQKVtRR2S+qI8iQAqF3xfIp8gT 1f8p4YWnUmvVT2j8quOrSoyvzgyAYuyNAtGbRd1VtVmaXl5ejg7oVzMBtEDajabihgcCsNcRoMjw UiEQ5x5/qLbyB144xFISUspUkoOcNxxEE1G1yScVt/KcsjiQtzzv7B3tgaq72lm1ZdS9inui7VLU Z8UqRXuG9BZalfuq+ZdVVJZJx4WzS8flWg0f1f9VRxZlWQWK/IOeLzcUArzmMHm7IGwImP2Fzgnf EqNDhiZXjDXRy/LzddSE/vPlU2036GPKe0mEjsaMr5qF5GQx+S20fEDbmCTgiQFVjqlav7qW9VP6 V7K9vKS0rKSkQkSTIKv0qFztKb7KkkKi1Il+z7Xx6+VnnyX6/+P/+MeCpUtt1NywuzFUCje9ErJB u8M7Dif8G2h6rH3r1g/cf//3r7iiePkK3nEoE3/n1be/+OTLgCiqXQ09aPCRJxxpiORMnnatW79x 0w9PvOSK9Z9/pCIIKEYln1qaHGpV0jQQk8cMAb3/9NxVk5duYj2Hd215Zp8Ocue/iXfkJ0EAKPmq uYiSCOVfC1RbQJBEfwUbEv2/14Ab7rjtlocee+btSXRTdm7XZuXcmRNv/2P84+kznnztDcFNvmmD x8oTvDMB/auFJnJNiB8swNG/KHuFgliUMKILSO0w8knsZuSDCMRspt2n7EAfMHeXGLpiYystqMYi /8rKy0tLlSEov8SnvksigK/MHdX9Y4CMkbU23VRJFYcOCTDEiaxBh8mMCKgkkLrqAtCSyKWEfk2B oHqhWorq0soy5AF4OPRB9VyAlynngtdAOQJsZaFppX8dG5tOUOouVa4nHRcuIK/oW0IjWoR2VrtN kDnWR8In9TurXxupTwBIHGkyS2U50AtA4dkmjYVxg/LzyAXy8kkz6soQxmegoSilsUKGqR/aVQde D0WldtQFvgSzA5xc+aD0vaxc6L+spLS8pEROGVxVaEUYag+1fepPwQF9hkD2HJ1flXAuO+tMof9/ PPTgvMVfsY1e5FKBMg5i9j/0RChB5ACswjF+Q6Aubdv+9b77r/r+hDlLloTQSh+8/zf3PfX4vYk3 E76d9Y3vfffaS3DLEVBVVae2bd66/poTL71i3f8+gGzRn3JQK10A/ATZw0pzz8gDP/5gma9RCh/Z qXDKim3hO784tAs7QSIn5UsJwgV4B7KBvgCtuEXfwT/9+e0/f/Rfz747mTQtcBh72KEjRx6a1bFN G088aIQNsoEpxAgJMzwMxw/xy7n37Atfc8qT4SjIW73aMPBsYEE6qpCIegxLIQYNWVVTMf4hTjFP AQuC1gTMbCrV+pZ7UcmPPzmjg7/SBpECzRiRcsQHQf+CloATv+IBsC39pDkDXIF1onY09GjShgp8 a6pIUro2pGptGK/l1EpF0c3LM7+APKBukXy5KXdycvKEBlGYs3CqaPyo61Eds+hRXBwKymRhUGgJ ciH6MzqeC0VaS8OptbO/+goMEPG84Hk2zwwTba1cZ4mapqp4vnzqNYqSMy4tLMiP5xfE8wqy9NcC +ZpdUJAld+S+XMsdeUa4fGFBjtjzcqewQE99LD9L7uivUri+JZYF72QVaBVxbTzqEqBpdblxAEo9 qDodpfYXzT21CKCFqWmjOgv4Eb0ktNTiWdtLyzZt3SKu7M1bt27aulU+eaHX27bxYtM2ucZP8rlF LrbYA/5J9+K27du3l5aUlJZu2rIVJ0rWc3MNlO9/wpNyWi1btm7dLmrO9m2iupZs3oxzS+nmLfjU r6WbN5Vu0bNMPzeX4ZSv5TgPbZcjZM/CheyTiF9+rdiyuRyv4FNfqWBpm+VE4fq5uQw1yllWKgpX iULNjFCBdnb7olbGFUnJKY5ANib/qGQsh3fjQ8k3Ry+ElOqrTq6ro5x6qr7jBhh0KBhAwgbpwiEZ sADQJJ0IjkQ9hXPqwX1V9VuNjjCpm4VJngK3oprffIVeRjAXxyOCkhUdQZhgAnQbi0TKVmtAEBUy Uj0d6j6jnw98BEa1ci68LphNHgQtCdSo9AZXKFiGukvQX61JG6TEH8eUDLQnaFgKGU/GYDFkNI4P kuMIPZOuwB2UJYFHsAF4GFxD6FCc/OqaNa7kWIkyGiFO/czNjeUqodqZrxcxKVnYhLZcWIPyCC2K BKxlkr8ozct9YRBZ4AXC7NgqeUVYCYk/jr5r81CXIgBGR9wBwmJV21LZT81LFRbVtejHVS4gEzE6 O0PXoKgVpWIkiYIotpLoTPKJr/w0FUpnUTivUi6TKvqw6CBl+Mp3y8Q615uqWOIoLSvFWSZniZyl pR71hSaTTv+TPOZexLtqvIlpgwkgKV2MHfXGlYq/TTxzogWJLwDXOtMjlrw7zfk3tkPOIW2ywiyA FckduX9Kh1zMiMnD8qI6EeSUTshXLc1KLpF6UaN2GKanqgjGYZWZUs+lSVf9oIPEHRT87oRuAVIO lFFO52l3vclPCx92vxn4cEHT1afUQto22U5GAGxQEW0eBKgA9FdRbtsEgZ8scCUoXZKSvfS2qQT6 vfRF1f5QlGASXXFkGRT7bAnqQqXwP5L46Ts0mxJoCpq11hIvRYjJG6LCaPmswtxsgvSgQ6UfTgpg LoDMTmvNhVqLyQ66SmX2UecUlEFki6aASQTIeaPnQPcB63EKDtkQ+an62ExXAqFCEXBaEpiI+P88 j4jL1xyhfD1VJvPM4x1tv3yCL+ABcgelZK1FLngtJQR6hBA8lBR5EvxOGb28yxr1xHgJuDC9Ch9n VpaqsoohqiRW0iFv3lD4RPHVPDVC/5ViTzgyxkWpWBjqVVMvinIEvVBGoH4VnmpaGSOwd9XLBD8T LTWhf8dTyALkq1S7AYdcnHL+qTzHnX9q+L4SmRzgOzzVbKsQx56YOPD86Sme+eCkfy7dObZt/ODW SvCsWg65ljty35XGAsk7wAWs8FBFelOrVgurEiaCudLNIaIAXbJixT3/fNxZLgHNU4XnYddh34nK TkpmnUMSR7HM94izVyb8FHdBQjp4cHmp9FfdH8Opo4h/MKPNZ0RNQTgFB4Kmvo4Lhkacmf6mtyi0 WWwfLQ8zz91fU1D0dxiEdCzptZmR6sx3+MSftIl4Un9iO/0LaDT96jAnoRkYQyFbUZaBGD5rCExg OjnNAQJeCBap9+gbcApUcK1OAn0Odr8+yK98GW4/haUWgr57V593h6rXzZwCIc8g221NzZJJWRHR 4vajI0D9/yK01Y5Q1mOzs94Id8MFZuisVmeac2DVHQDyhH/D2Xtw08gACpabN2f79vLt4gIoqYAX UJw7KqNkYgz9g4nIWACMTDAAOsEptct9acHlZ5x2wXcu/MF1P3pt8hS69vRxHQ/VLcuWbqjYWhLg cbWrvNbN2wzs7jGbuHNA377/ePjhH1977fPvvQcAEqN0OFd9Mu+P99wi3y6fcEPH4T29WFwxtdjf 73JQbwjSoMkH9Os368pvjf3JrTP/fj8n/1W3qVJrXyJjxFGcE6sUd4Dcl0AAOcP+P7btrZa9Py/s yipY+7BtS4/aNM8JZpr95gUULqVuoqq4UHlFLEuuy807oCPS7YRTf/bb3zzw6eznP/jYuShiFxx7 VO8BA+iJTJD2DmLW0+q2gYKFKr5RrXqowT/JQ0nCoFnDf4ws+QmsaDf9Q4kdyHzc9xN7qgpi3KkQ Qlhy0ggud1XdXbAAnQUmwCFKbVYJ/h7OKhv/YwSI+fZDdbnpSXXjY4YP9E3vEWaQoUDYHTVWoY9A XUdd1je0GawCyiqDiKjVa/MkLgrzfxJTBEpDCaZgcMYBs4PaR/0JUQZqctBggW5CJUVVJygdnmIt ZokvcnYNn2pge+vGmk31B9OEaL8o1aZpIzABSrjiLKxuPCANViXcDPJs8Ve4pmr3VXvHY/y08dV3 c/irvQirXu5UQLDLQd+1+qvhtRQMYaiTnDpZZBf0H4E9OA4ryEUZXoKAKZW95eJCrRDiF5u5hrN0 wxZaB/ZJqwESG/q/ivESKhQ6+1Qm4wrhrhcrpxYL2fMM33fahJSjUx3qvYUwU/mHCSyeSSpADV/f bN5TiP/uO3/GquWQa7kj972crxLBHjqdOiCTgskah8r/igrKLsotpSnSYjpOmcosICsQ1YyucPJ5 U/IDmUYOAHiSBZicI08lzhEPXBQNv1qzgHkIVqGJAkEArZskCMsZdnvIgDd3QKDzB6VRgweXU7el qZEUV9RoUBEYhDUjYAGkfzAUcAFcm3sQZM/wIbAW79rk3Lu77ehQJxECjiD8Q07MLMqL+hMnHdlV L6stzIEkTcYBCsQwMp5CyscMBRkHPWd2TTNK4eQA6BtAgkQXKAG0GTjNR6tEixAj+aQejgAktcaz BAP0vlPOab3rTUAC8Qh014nMk3fNhwftii5rPVR80SvstBsoRTZTqjMG4ASgStC9Ywo25WEDaLFf HBoO6LoaD/aW3AdDxhJoWZic4OBBtdGbpMBf/+LHSafnC0BWfpjEIjrhuw60jakyTefdcEauKY/G r/WBt9v2/6J5N6mL5V91za2+AXL/7Tb9jVLUI+UYLkWFoVDAfym9AHjSERtJexZy0NE/RWRg9Ycn Baj9YtCoHJED6DfnNyHJc6IXlA9OqLN7HD9l7E5VBIVTRBrVUa2kheAZkjP5VB7B6CbBU5TRr0ZX FsIQ4NNC9BH4A6xxQwgXJyettage02lMHyF4OH4KEqVeOONtCtAIHooxFA29IK7zRbnW8CqSCo1Y ZQj2QEj0IdxNnfwQ9cbpLAyQ/ELpUCMnvN5BjUP5Hl0Y2ioK9kCocuyttaH74FkUzowLglFGdsbJ B7nHiEAfZ6NUjelCMAJ3YgI7iDi0LmucKfR9Wor2DDuiD4NEUZTNSIu+Ssmh4t1UflC3zQU7fCHt A5tgQFGrZPyFqeYKAnpJGWIlOKA6YZ78vrXGQx4gDkGfNFcwgaJOH+cfFpBJyVK+PA+vYtpDHqA3 1+LhxW2rnt3sKnWO5GYX5sWb52U1y48X5stnTjOdLokXNssqaBbPbxbPa1ZV0CxWUBgrtDNeWPhF 4T533HYt6/vhj38xtHS5fPKr3Jdf/cNyoa8XSlHNs6VAuZBymmlFWm9hXlZhXqyZuG9FC5Ohd0wS PMFM2iUrVt7zmNn/3tL3RoInRrtj0EdBzhsnRJibXygGZG5BoVzT2aaAg9RVjqFEBQLG7Br8Z0bU MFWJCKonwKtJmz8IhFRMYcy/c0gAwcSSCtgVLGM/B4FJc8eZTEsR1CHXAtfxnB6C1LiPV4rQa9QB aaYWpudX+jhASeqlRezZKmpgPZz+UBOY1g/QHB2FPgTlSHRE7TWuGOXvYyVgznEqRadZyk3TsrKc 9W8EgVl+nXKBSxb0SHNLDVk1ybXH1BoYncEYbWGaGpMXROappKJv1fXaw0EZmlOZGPkDHo64ABr/ plrhm/VdqFxUYXjhEfBTum17qdj/29QLIDNSEg5QsV0CAcRBZcxAum9BP6Jg0LAH7CnCOFhXnXXm Bd/5zo9+fP1rH34kv6mbVq0z2C3ZWdsXLi/ftM3jbfWLgrYt2w7uIy0kbDBGVQf06SX2/4+uueb5 9/9rr9C7VFW1ceGyras21FBgi05Fbfbbh9qH10GG9en9xRXnnn7D7XOe/DtBJydDfYSjQHxU6oUy I+dScXW8ldXli3h7fhtatfqoymXV75AYGOFTjmgf4a3AmayKyizwWVO15LrbkSf89Oe/+NunM178 36fOq1d13pgxfQYOFP/fyt8/9oST9ubpS6J/+5WimXjlJJLKZOG9oP8cXf+Tj0g4dfAyih5CQMcx S1aXQIBDiBFS2nWz8uA9EEcRYt8QyaiLksVu0T+sGZ/UGoh9eB36NzQRM0UYaAMrzCwP8gI0haX4 ApwhBNKAeoRfDfNM8Joip1RB29jYh1MPNeBFtQAUDuCwKqKWAkzJG9ILcyTKnED29PKxj+gAZo18 X9Qk5ntqDLOPKI3XGAvwB+dhxZOmmfE3ECpGwOZ+tEsan63TgX6lBtiBxiao4UO91NmHpDtPhNSR XBybIawwc4KUyqEd6LPc0vknnOLtK922rUwm2rdvUxbAKKBS+ZRAwEqZ0IOKL/RPNPOsFS3AoJCD XXXW179zySU/+dH/e2fqF/KO88nYz2bgwlIErmCILX6JGhlHxemAYAHDeu33yMMP/eSaa16c/KH/ yS4cI/A9M2wEtWPMzVwjgyLLGtyrx+dXfOu0m38+77knlPfi1PgfOPwYAijEr0oqfIFoIeMCQTVO 1PG7tZXISfBoFJke5XhJPsH+dQG/DILSv7gANRhL6sjpPOron95w6/3/+/zlqZ95xPzWmFF9Bg5y +r8rNRT4bzo/0Rp1eggYiw+UOYbxUeSS6ARjIZJprWFAgzIcYeCmkxb2BRXBWKEiKTwdCr2oVYK2 qmvIKUtWNGQtTyNYcS1LTQoL8tWPrQFt5tYW64DhQ0AKFddk90BNzk5SpYSMBVGZTmGmPnQZVTBV VOqiBj11dQNmsBwLU8tY6FOX6mGiw1MpvmmZ4phVVZleLrmuiJdXxnktoyU8m2SL6GK9NhjYSDv8 gVuhElZ6JXwHci04p6+IAw/eZfJEHDBuDZac5wX2kX9RWIG4oR3gJ4yw4YcXE4GQ5EDaaNng4ob0 l/D0Jeiv4NEEh6EGFSCgBvV7eYosGl8EgOAAfMNMfhr+/hMPx0TnbSZx5m2KWhfKUVBQWNBMPgpx FshElN4BNghOyJEvy5v0Mx+fuMlf7ZRfaUPKSMt1cLoytTScVkVQl1ZkTXC168OyjEJiJXKFwxbk tyqSM691UY6erfNatc6RUy7atM6Vs1XLnKJW0pOcoqKsNm2yi+Qs0q9t2uhZpKfclOtsnDlt9Fc9 i/QVlpnbunV+Ky1QT/mKKuRmbpHWW9ihc2WzVkWtmpN7mCLrGJVz/zisSaRyvMIPx9jDTID6kzls qcOTjDhL5VlsmJ2ZfCKu8T/xyv9nfAcsDJsQh9qgNKjkrytr7JCIVeUAyg1wIZQvY6qfcg2ZphNd Li6Q4gO8U0iOB3zOZARAYIo7rJnR+sl6ZBKeYXbmcZCSs0VUSgCf2Diq06mtaz4q+rSobbBQLHJV 8aYMAqdO0oDs9ULZgXAB3AHzxWI+DJTFvWBuHEJMA4TUcajGv17Ab5+LNqiAcd47TKRjsOmJ9JRv /kU6NenOhICEnU+mYTyaowz+RSbEoYY+YrDTaF1YLLhB0oVz2DERQwHGS8OtgNWKpq4oHeMlMF+G LAMTFBFsWRSgxCp8bHAs/tXqNfv27v3SKy8N7dO7Y7u2zWUxYoiiwQGABzhA83Io+eNCUUPDnpVv 6A1+yk2hf8EyvaOyRDkGWIedVlroDh8Ag9G/+pVV455MquYUaNBUXotWuS1b5cn6yJYt8lq0zGvV Mr9Vyzy9I2dLodW8lq3lgZyWrWQNZW5LnHLBk19xR0qQ0/3UUt/F6/mtWim1t2yZI4VLmVJOq5YF LfRrQVFR805d2w/ef+6qdUMOGE62jxOEQK0tQf8PRDRGJnS4L3bbTB0WJpQpHFTXk0iwJyJbNb5N JCT0c5PkMP5z1ATQuimQYUea8a8qscZtYGGjXJcD+wQvVM2xlYGkSlAm1wJqq6C3A1lpMSvxaZCX TjkjGEynhiQ6SxcRWTiC0KJglpOBvKDeKAqZOifgR4UfUYlcPTsMH+IkRVw0K9VzMMlD4WZxT+Bb gRJsPQCikwvYcgdKPf2Qlph7C3xDvlIKmmqvBKAQAsNSZkFSAbuRR41+FEpQuFSwcjEIKBcfkMMA EqdLdRJR1RkXLOhiEzVqCKYZ/KZw3UOzpdTANS6gmZtMcKqGXx0QyAmna0kUjC6AqyiVT9H/t6oJ sFW9AOUSlCqfJTIxVupMGugSZFxO6WSVqsZSn8/K6tttn0N797r+hhuGDhl89plfb9GmnVh66CPU Restv9incTYabgloTaVFMe3ee+/95Y03zF++QoCKSt3hxVhohZK3AUlEviq+SO31/e+effYfH9w4 bxbm/9XzC2KA9aTOKwkEUK+xXIZ4b7hxSdehxoeEMdVGdqJCbAHwUZoGsZy81dtLZ8xf+OIjD/34 70+sKClZum49CVkK+MZhh/YZNEjpP+T/Y0nqR0rQ9smZ+R6RStEBzuRYvKS0pHR7ydYtW+heVlEt vCA3r3XHjs2LiloUtVEkUtrRCT+6nTlhTkNeZaVitxrtIiV1zkC4gCbY0FER/o+xZ8CiI1QtTQUX cNKm+i3EQAsSBqBuJwaD6oITCeQSbFO3gvqjGIKjvj0qRCYPVd6r1aiKvbqF1U5WbR/R9erUsLAC aY8u7RH61zgvXbEUWttjI0wgKUUr0WrGEKpJCOrhnJZyDSV4BbUyAqVe8Dsa/BwHqAmKNrAU5Am1 DpR7UTDKhWlaWEVTpaXJ7/oOkJo6PgSqNJ4rKeCGRZiwpP3Q+EIuLuCyBaV/mwQFDmOYMMpm8wM/ ADg3deRRHuSmg4KuK7uSZzEBTheABPwo8W/bVrJlq3gBhP7FCyisQUKApL0cbrxl5XPNnBYCgnSs X8ehZ+dORwwZ/Lcnnlg4Z+6WDevYRmq2oD3nwEHLzatDNkbs9+TttE+pokAiIHl4ycfHzKxJokYT nyzNcRqtjVQiF/vN+nidESIJBbaZPgz+4jRwkgF/stZ5JZw3QHmYYMIj9hWAMbWZyixG3WwoamOx js2b9R806Kgbfzlv5erVupbBcY547JxDD+k7aDDl/+NhYW/ix2BBgCToAmzS1s2bN61bv2nDujVb yja3672qoHMsJ395fkf5tWv5mqzK8q7xDW23Le/UvrVwgU779Srq2JH0r1MA7D+YvLn3qVkiUEHu CN4I9YD4hacpQuisNiEt72E2nvNzqv0ywsRNUAkY1IOIeUhEeIvwLxH5ryuxoRToAmxdS+sGCrwM DIVzjKIHqoKtF8jhoXH+ulxH42HkUP7KkFGEjZAV6F9psCKvMnvpF5VnpX/IdcxIaF8R4GKHfFFK 0cbI3XKMJp4j+VIfjqmYqBAYCDwg2cEwlW0InPRtNTaEJ+hKWk1MZIq2Ok1pR5j0lzkvZW6hlVRY ecFVBoga1lkiameQ+yQlxRgMmF5xRkdVABA58dqwGhWRR6Pthp8ax0nIK/1vLdm6vWz71tKt22Qh sLoAGf+nCG7GhmE5Ywq1LnoSTABA+9P53/7duh06cECH1rqIxWhQu2rcyrXc7gREn0oFCDC8Gp4n cwRHmY5SSelASrIVwst98vUQuwkRFUk7DXOxekPk6gjXirQHwncTadSzOHly2pKvlqxdy7b49px9 yMF9B0P+i//fQODGzZqZ0DpvC8Y2bli3ce26JUtXLe40fPE+h7m2pv3bd9OXfbYV9+yzX5fevdt0 6WJWCDEKCgC8BpBnUAGgJVdmORYA+ldxrQ5SQwTFM02hJRY4Isy4VkzJTgJR1MHGSQAV+CL/hQWI /MfKD9UF1BZQMWszQMqYYZXANtGZS+TqQZIapX+R/3Jyvl3NDmkr15doVKuKcgaPcRbGuJAyLXPv gVyxrBlsDTVrV63X4K0wb1X+k5L1lhE/ZuOF+IUc5BOKAa0AfVbYGGrBu8o+1HyA7U8rgIRr/yXm 3693Uh1HvV1G9n4ZlQ4N9H86SjzyEq8x4QlpTNVMbSiMIJVuamjgzNQAiFTm/BeWLFx467aSrTAB tm1T+V8iI6IrVSD2LarM0z98EpgOBDzojyGxwatLp5COmd5hAKgKBTBpNIY/eRjYfU+l2j6bfqLd AcXLbBDQClgohwNdNphocwlWU0gVntQQyZ9YpRmYppx4SsdslS+Q17bw2ZMo6w6La/JZtsr01iQe AJ9PoLaT60BTw0BYf5yGEj/74INE/ofi//C610Icn/B8RKsXFW7RvLlzZ8x6t7L3fw+8LBPil3Lm tBz8csdTXvyq4LP33i/+4nPBAMNwdIBAZTuNfwO4EOiq7wojUF4gHgGdFGSOFFnwoKlU5AJ3RPtV kW6aipai0NdR4VpaRRRxGOvyGATJEZCqmavL3bzSHH1iLcUvSBfiWr13Yu2XS3oVXUGiyQmwpgS6 LZaYMHCBqZR9BCQsENNEEBXpcwKQaaBmbwzQDwnGAGUOqIgWguYVFeHyoHYgtC7fyQg492OQpGJj WO7kP+OmsaRJTihfTqhT76bVwT9eP3E+XYZ18x+TGjJSzwV9ocOMaaAflb5AWjlqlhCwLjLKKRPw dDImirMSCGREXJOOPx2HoXgqv0DI7D4IMywZ9P5LJB8g7wnpxhhtKJsW+acCQyc7BTxOG9VHQLEu JtL0JyN+gh0YFnyiXK5ZMg3JekEw4z74KaJIYLT6mNcgFlB/gHThrJOxUopJizWlierYC68h9gAl nuQ4HGFax3ZBqYZaEG/OyB0iidG/dgoA8hwozO94d/PGjV8tKJ69rfDt/S9f3vVA4z4Z/1nYss9T LY6bMnPF/E+nbly12phpksYFOUCZpSxf6V8oXwxapT/JYSQEL8q9yF+l/ApZ+aSULyYmDQdnV2OE HBdg4L2tuiMNmH5rzB08nzPt5s3mHVVH1FbHiVykGoapbiyVZPBnMUOJagOIKCcjQNIf3LC/jApn jjcN+NE4Jyb1gSPCeADUfjSB/If6P5phmCc9QstwV0UjSB8HpD1vG0ZS6hjemGhSIrAlCcZgbfSM BQR075yybB3gojEKzN9k0TrOm0pXBh/iTAo0GfnD8H7yU01NgT756QByKJ0KdxacXhCbEX2MEXTT BxpfbDzCSE71DkyRKOKSsKFDAI9xoVXjgYCJeEajfMM8RxY2C7XFu8gRE2lyQuv1iGp6KxsDTsoF IAQ1Iq9hrEKdpNsYbhed6zcFE5YmQw2hOHCRuy1gTbgGxYYWrVv4llsj4xgESksI+maUqqXSEF0P Jxfd2uJaBZKKAlBBEhVThPhDLjesWb1i8eKP4z0+760rH3f4mNT84NcXVy2aMW2NJFqhtCXS6l/j oQzrgQEK/7+atapDu4lmFUHMxsukwGZ+W4JgCyEHLuogQxPj8hsPI7B5sBo4zOE+ByWpsCI9Qasm eSKADTMJ6kkQS0JPuBVlKTeWnNsKUlodjheAJbivYnGUVUpsj1K+qgh01xm1m/ublGz/oeNT2hgn UDrUBiugcFe9Zorm+s10QniVKAxMPpg0sIVVtthWYGKxvRZ0YGyEzMTzQfsCp5JSL/IYuTZb6zgl oeyIFwZAK0QhSb8UxhrtJNlwWQQvbGIK0hKmHKNodPkQBB3cvybr6O5FKKJXEBxPMcVHG8PBRTFM IsLVDUa0WrjWYq5okqstr4AaauHVZAGO1KlFGNviggtH8zSayFuDNDa2bp2MwJacCyNwGS7IF9y6 9aQ8F46kzWXGBV1kBy4dDlw2WLvt2IdfIW7ZaJjhBg+IAwurzrkqXNkBBWSC/W/MwNgBVGFI/k0b Vixa9E7LQ9a1H7DDlB9+sdPWxWd0Wd9jyNBW7TvoYAGr4ON2nj+R+ciLmlVeFlfLVgZBFjJv37B2 7eqVK4XmFCGV3eqMbbt9urXu0CG7oHmVrlHLtWFWfZPONZXSSsW65FQmK8T/tF3EN2hVhbb2EZEG DFuGcamBQwoyCdnSuUBO8sOHj9ZSeRfCN9cdOAaahLU8cGFzelwboPxFL9RdBxLBbcgonR+g1WIz 3BLWRZK3H8T5B+8nYoRsFoDOP2WMpjPIIxL3hRLi4ihxiraqk4qVUGw1Up5Tmm6BIBVCpUMnrEyr hC4K0gHGe73QhSWA0HGomqZ0qDWozga1U6mCjJ3hP5qRUv0lzP8lIcDlkhxH4n+hSlXI/J8MtBao gw+3ibB+BY1a/8bqKMXN4oYCx0UeiNiHle+tb3zD7DAdAO6gi5eFKK1CPaJ1Z/weLM7GjHO4ZMgW 0kLODIDAOaJTwgwtgxfCrhN8AFqNailQTGiCOJLCBQ61502jg94SPkL6eNIl9GMqOjisbHfDhg4M kdqQygj3EF44fWD/fkOHmv9foe80HAocHnJTiGbJgvkfx3os6j56lxA/C+m/dcZxPbJ6HTBcYi1M x8Wcn7n9hSzLS+NC/Er/Fdu2bimeOUtaU9C8oEPXLrmy1KBFc+mPzCUJai0uXiheL8la3blX37wW rTEjoFKGsEEQsVLrtHfelTkoM9mRFIUGA8hGnQKMKXDz5BJXA1OZQXVQYumYN3cBVAMgiNzUeR69 gHgDxUBi6sN81Wx7N9DOVkcDHVShMmMUqBZBf1GaByXxQh/hXCCrNhUBei6tAOh1UAxgRAH9yAAg 7xTz0VlnakJxhU9E5LB72FBKMYf/GFFkh3kBiXYENWMDQFRAM/YAqKTw0mUOCm64YLEYFnOxkqAC fNQojfoMWYdBwdeKxF/oEdkA07PQIuZhNO98kTZJ5Jx0eBY6AwQ8VF+BJOdfoJpgkLR2bbYqX7QP MUR0jZiCyp5KcQNHjqRYnv3Rh8AcVqBFm3OF/FHBChGGfrnKAnhmeAV0Dn2EyTnECTgsPDx/2P/I I5PunNqvT/+hw6rJf4OEDZ98W7Zw4Zcbcz7rPS7DVmb+2JiSqSMHdNxvyFCisc70UAvQeBdH/xWl y4oXrFu9uku3fdp2bE961H7B8yEBsMh2mC2SY83K1cuWfNWqY5dOPftgEIzz0ecun1+8+/Z1F12I b0EAqmO9IdwFuZh7zNirx0YySaN6R4HAWmdGqfC3YTbNHaD0BC9XAY+njkKIef6Lp1kjpCKEDh8i NoauPbMgcnnSwVMhAU7KJI0G117AU0ARZoYzXlgErTXsc9Rt+OQEkJM0KMr1CRREOFEXojcVUte0 I8yD+O6jQwlVOnxyTfO9cszGugSqNnXFWBF66m8FPQq6Se5t3MpfKJjJa0NAt5teM7p14sRBhx1G 3X7WlCmnHXlkwADZluDTIGej4sGDrr00adLJhx9uhO06a38TAVENLA7UwQ8JCkTAKmKx5bLEMPH9 U3v16jdsWMj/FwCaCoN+37xh44qVqzIk/hN7tzm1X9ukLtTw9b384YvmzFu/QjIuO0Yb4DO06FjV kuIFG9atGzh8/3adO9qqoZApSIELhhpr3alTn+EHbli9esmc2eqWs7Wj8EwpToEdiKRWX5ya4GqI M9Gu5qaxE/N68pNmktJnNAevnXaN9FJyiv1gD+uFpu3Giy6rBDNPIULAck5ZjgompVLBB53Y0kXx ms1AaeZSQGoKPK/+h1DWiiBFMLNNIN0V3CGWQBzeeHRT+mKfcELwtOfFJ6FfZZIODr7gWu7offFY 6NJDf8oduDES7uhXmRPVEqq0KCtQHR7y1bWB5Wt1UiZrtMbgAq/jPjIh20+a0gsnLqyFuMBp2b74 jMJfq9NmsAprPEIjXUdk0tQ13nVEs+Uk3tRJXYZkuYbJA7zmTbMC4Fk3lzv5qmdCpktRFJO9gh84 qRSIaLO2+EBwGqv2OhVVCR/wRs8/FRovsZwqZBNonEOhLHMODro5NBgPbWWQRUi3I72SAYrbb+2a 6W0OyoSkhfj/ddZAOS8c1imT5/nMhyVdl82fS9lAu9jxY23S0gULZOJ+4IEHSCSOaZjQM2GPM3mD dgIv0Xmb3fvAg0q2b106f56a4/Rdh2RQSCEyTkne4Tvt9Fa9RzMbwHCatslx0/O9kupeD6ryV/SY sQz0zZ3yzRhXCFqmZ1BV9CpD+BLTfGwOOm1YQZ8fSiIWUu306kswwFaFKx8BS3YQU9nhEExYX+gZ 9MFjqldovRS1LhLy1tyQ7uLeJMEAZQ2VvUS3XoXuE9edboJxZ2u9xMMUgEKEnQgoyU0N0DajxhXq s80dhso3MqP4ZBXuM3RBb7/zArqmw+iU0wIj3DXVVj9GbCEPN2JWRUircVzD98WzhBRcwnMfK9Uj hmGFm0G0uUPGc6rlZkQUYCEHW17bvGH90pVrl3Wtnf6F+J89e1ChOJji8QfG9f3BofuEkLqmy+Lm fZYsXLpiwXy4y0xZJCItW7BQZhx7DhwQdB9uqTA0DNMYcAbMFXrrNmDQlg3rF02fRnUTZjrJTl7G Y4YigDxfszZWlZRX5m2f1nrTY33Ljuu7fFCvmft2nzs6pyyUE96hl7VER9WoRooNyIyYzyOBgHBH Cwnx3BAt+SZ5ArTxc8wChiTJPqBBh5ahsQ+xAAoO35h04xEWAvZ0QPWeYMJ4EirJmJL5JUznN7Ye YllsBimf3niuKiAbIM467yMfqvZpvkmFoI1eMPnnKZ9zgaR2N9yOZdhNBxUyCxbFBoQJnoNln3jI v27OB/gVjD1Z/XyO94JOGNHbzRASOkRJAWO+b+1yaOvQJdQ1cHzX1BQDbEW7vpLvoJEhaggRAn4U Z/vs9rUTv+j8Qvx5WAXOQ7hAOiSrfn9qVY+1spELdQCAQmTcti1b165e1XfYUD/9A3AGLF6QZO3K 1XM++2zThvWAECncNP0eQ4du37xx25ZNygLguaMQdlwgoRWiLk4u3nTvpBX/+Gha6aZbO8Z/2nnd 7ZXzF66pOGtZs1+uKbyo/aff1PKlT8bVPeoQ7AA9GKkfA1Mb0B0n9h14Q7BJZNKOSB3CYbQCuvXv YaCp/QTzUw4tPb6AkxA01jCjvWpDEEIOj+r+oUAXMS3GWctk1mbeJ9A9rX0jfsfTDRQs11MGfXn0 UPoruuzMgxaotAnswPFum/Z3tO2HwFEq+b3pBdQOQIcmLvyAGfhc2/B33dp11nvjDgwqCbWD/mKb VLCxIiIYXZkGE9CwVe9JFYRoA2AKU/L4VBMUSYOUCbGZwmhSiXSgh+1E5Kt04JFQv7IyifNd3qWW OB8h/ifOHOiJX6yjS16c8+spSZuo1MQNFrbos2n9epkWQuybtat4xvRO++4rcemYmHUwhrClb27N ypVL5xcfcehhK+YWr1+1CgAmMehYy1RX++7dRQVQLd6iUVx8uWsLhja+dEPpL99aOXVt7hEjel51 5LujOj8Tn7rojUVn3730zxOXXbqp2zc2d/tOpeKBO4gBWMNlHD5wfZNc3Wjy2nQpR9NBMZ4Fm0gx 6iTRO4QzYiHWeDngr0HfnCwn3bMBJjVI9+QACTgTNJJIYD8HTMuzLF2wS85qJ593cUe8qHZiyt/u k/OS9RILA3ZDmp/5xRcvPPHEQ3/440N//MMLTz4xc9o0zw4wE+nCAS1skZ1zWgD7bWCyC46s/Lv3 t3fee+edf77zN/f+5td//vVvJv7m1w/c8/tVfodr33mT+SR+K0wK+fcTj69bu8YaHIysFe5nSamG BMLYywKTDGiN471BVZ71cABsEJy9FPqaoEn6kQisSfOveqPQPeJNah0BOl5VGlpMp4lLv6AjTKI6 6Fs2bVq1JRyWnIKGz+jfLkz828orv/7UjL9+ih3U6nJ8tXLDpjUCaGKKRBmXykXbzrpSgKFU7lTK 18CsqqqFs+Yed9TRXTt3PuWE41cuLF6/ZjVWrMjstwxHhUwLFHVuL9O7pdu3arEmqAIipvhYvqn0 d++s6DOo77e+ln9a5/P23XLnV+8eMHnQU18M/+387sdOXlh67xvzBWbbOx3jKMuPM/m2TS6FlTzo Am7ETb4beRqFBuTtCZcaBB9zc+/gMUbXISHodUojkqBsRNFYGf5uIGoNSR0uup6QtVSb3iOoTE6E GICiEm6bNlBNB7A4QK8QUPkPeRRAq9bTWPydV16Z8vbbq1foqls5JLjjg7fffvc//3FTMAwo8BMy AfEDUH6WzWk6BLgdCsBjxo49Zuwpep5yyrFjT+nVr9+LTz65etUqY6gJWOr5iMFk65atzz35ZIgF hKkc4w+AIy2UHb7+8B3zlhjfIFMOsWV73YsYhezYQw4++WCeI/QcMeKkFOdBJ43QM7CviOlktPhr hpiGmmJZrSXEEqTmysRA/ocEF8hw8/r1G9r0qoGKzxrY/p9nDPCSf0NJ+QmPTntuNpcZ1e1YU7jP uuXLvRxav3plYYuWjBJj1CR3gGKwCmaqs/bp3XPj5k1y3bJly3EnnLCqeP7GNasQM6oZ0HUNbLyy oEXhxtXCjHRlDsNwgHsmICUa5973Vx5w4IBvDFzytfwzWsx+47/Pj7m+5I6/TCpcOG919w4tBx3U d0lFyz+9sWBL97NBukaMQqgSRPT0/X9ZZ3qHeWLxjKKqVoAQvOAO3bbww1rsPQNUnHCTC5nm/OC1 10DV+tPShQs/fOMNYlhA6oEyxNlm9x0XViJ0aveOex28in2YP2vW1w8bOX/WTA6Sk0xG8Ia4wAE7 wvLf9GnTJ83osgcSbgZSKCS/TE0HXKQtMz//vHjWLEnecsSJJ1501dUXff/qr51woiTSKJ49e9a0 L6j3MYjH8wCXgsEWhJPlJTMC8lBHktu3WTpAaeY++/bo0bv3C08+6X9NYH3x+LRPP/3X3//x59/+ 9t67fitlCAv49xPCAgSrDW+cJmaLq9mVRCAqXTlPE9Q/bYvpgU41CUDvW2JaAKFYl8NpYG4YPOWr FmZJWriDJvNr2raLwhskqqxaRVa5RLqua8ZtBlMcQvx/P62/J/7lm0u/9vAX7y/eWJdmB8+ujBeV cJAgJ9YsW9Z+n27wrzKmUtel6vSYmwMTbtZ+n04zFs377MtpAtDWrVudcvzxKxcUb16/ViLlJCxA N0GIVbTp0n7t8q9gier6e89fMCTxDxZsbNO29Ul9Vx+Q9a3cz6d9/Mkxm4+995pj9rl8TMcusY3z Pp3TPCu7y36dFm+qnFl5kOcagUXNgTVaU0yVqYp/P3D/utWr9Lqk9LkH/7Z+9RqGoDlU9uRrpItA NOULwpfnTpvW/8CDGG4oqto8+Tr8QLyIWSbLSsIk35ZGVeHDwpmdJKATiiVaKPpAoBrEs3oPGPj0 Bx/2HjBImUGCcurVX1CnzakkDqlJFyC8qQFOsfdsIuENH9+g8EK5JH5t66wvPpe7o485rt/goczp 3n/I0FHHHCuPzJr2ZahHlnwFIUwhlmd8kQ4ExwgsI6mxgDkzpn/xySdzZsxg9SUl2/fp0WPbli3h NjoKjr/+wgvvvf76yuXL6Timkig91SAxU9zZfOp++PSqWYij4NIUJLlYNL/4k3fenzNd24BmmB5h nN1ZFnLf6Vs7xgBMKTMqCox8GGyIs2K8vCgCMllK7cD8/67FvoF6sbFF15T0/I1BIvkD4pdnOrfI ++yS4ZU/HV3rmbLAdXmS7dQkrIZqx2Ia3sd4bHiDp035aMn0uUtmzlsya55+zpgrZ6y0vHjxgplz Zwsci4panXTU0ctmz96yfi2WxqkKIInAZMoWa+e5ZJ69o+4V//SrzScOzTms8JKceTPnTB/T7Mz7 OrZuWRXL6VRUeNqBHTdv2pJVViFhpYUtWvxnxkr/lqd5Q2UKH5AZnakOQdUHSur1M662As8ImPRp 5L1p3YYWrYvade4CJ1jWpvXytXW7zp2xcsuWLfDCVoQhjQoOLmliLLqxCR/4ansEkENodaG9Rkg8 QF9TyImZIc3U0JhwcyLNa87UZzGP4XQqE4UOxA7XHdHIfWN80m5ByHWr10gyt14DBjpGprxP2JPk WVu3ZrWIK0QoWzfBMaz9geudMEwyEpwCJK2TtHDnXHjRls2bFxcXCxf4ZPLkuY4OHTYYWkybOlUe kPxfR5908qXXXCun/FDYrPm4s89p37EjoUXYOEsK0PN6gf1IDTxgjkL8q5csveC8b8s+nElWkGMH ZIuGm0kEIqV9+eXMLVu2rF+3fvacYll/NnfeolWrxVgODlPyITylp9dfeeV13/vu0sWL0Ay0Rz1r tmRGVs2CC2hMvfzq5X/Acqg5Cc8ro1qTeJw7uMPfT+9fJw9/9UKS7pRgsl7pB+JMmJOgBcEtKC0d kDw8p48dh/NUdzHuDPl68riB/frReG3Xpuiko49eOnNWRXkJouiFeiV6WHLLWKiZVwA4ltvKyke3 u7vZxinTF553U4vfXfqPheP/MWf8o7PG/33G9x76clN5Tn4L2c88O5afN2+5iAtOU2Gg6JSSfSZW r3rkN7+6/9abpn/0kahLz95/79qVK5657y9vPfP0vx+4b+3Klc/+9b7Jr74intTnHri/eMbMR+++ 62933D7jf59Ir5YWL/jPE4+JmOEcsqyt6tqzF9cpybliyeKuvXrLqL32xONLFyzkTkHLFi54/UnJ 1FK1fs2ax35310O/+LmcEiIh5C8Lk5776/1ffvjBQ3fc9vAdt8363yfGOMARJHJowv+dc/i++xze veuUt97atHHjuUcdIVbApg0b/u+Ir/3nmaePG9B3ZJeOj/3lXungxvXrvzlm1EP3/O7Qzh3k/Oe9 90qHN67TmzddcdkpBwyVBwJlmEzbhDr/hoid1k0QgxJyY4D3kJkqD1MFhnH90PigViERk1p9ZKCi Ir367DN/vfsuOe+/C+fdd73y7DPCJshJEchso0MVQ7T9o08eKxuoHjfu1OI5c6XQcy/+rmiRaD/d tsa85Hr6Z5/J/a8dd/yAIUPJZwubNz/1nG8I8UsAlusynmcXyfQ5W0mCNw8W/yrhLZw7b81Xy84/ 97y2RW22b98WBG44XVQLUm+Ra4YjjK1bJeR9qxS5YOHiFavWFy9Ysnjp6lnTp7zz4l0zPn97ytuP Tfvw8bLSLStXrTXfitMcpICiNm1uvPPOrt0T9jiDc12jYFW1QUQ8eYP5/0IEaWs3aiXaXfyAjjgY Kq1UZ9yC3jQHL6VUcqU+lINJbyS5cm62BpKB/i3VBpei08lK9o3R+8awj7tVPbz49QPeGfyLYaOH nHzmqFPPHn3aWaNPPXvMaed87egTh2cVaEL10vK4BJ+xPRToyvRjcUl5NuezT791zQ9POu+Czyf/ V34989LL23bq9PVLLz/mnG+e8b3L5PrM71026pTTRIKJv2DuF5/931XXyn2hUhFuWgzYm/wXf+f8 6dM6dt8XiJ4jxFw8/ctO3feVNMdDDjt80ZzZXCgmF0NGHi6s8o0nHzvyjLP+v5/dLKVNfvWl9aul tGxZWiMum4tuuOWEb53/5ZT/iqCwRabZ2Z9MntS5e/cPlq2Sc9RxxwuVCShoLGzZtPH5fz768hcz Hn37vX/+5d55M2dKqzZv2ri4eP6HK9be/ejj/5j4ByF4eVJu9h+2/4uffdm6TVvQuJuJ8WPGobJw M8cJbFi90s7NcPSULK7tOnYU6i2eM0db4/QX+So35SfJKEn9hrZNXl7+8aef2V24pDu679fr+NPO kMecCgCidAxI/p585lkl20vEmyhtPunMM4ULyMMnnH5Guw4diAderZMAyzWrV0m6lz4DBgLN9Cch /nYdOkoA5r+ffFwWLhj3dzqOvQukovA0u50it6pq+VdLN65cLcTfpk2Rs+29Z46IbPiMksmO7M4H 7zz15Sf//nTKC9O/nFlYOXPFV/NWLZ3erkVJeeGIdq0knW/XZWubF09//cO3H/nvuy+HuEeYlfjC WRfncYLJGrYZ8t+rb5Skjivnhi1mR3mPfrnqgn/Pxo6+u+zIlyGW3WCh4MmnpA+UoFYDt4xtTo6Q 8rMvv/jsyy88+/Lz+AzO2XPnsB3r1q975Z032/XqLs8jlFA8HSVCOboC0JJoaN84b948+4sjO/9+ w1sF/x71wuqc9q//59OnH3v3GTkff+eZx3A+8c5zz743+e2Pli9Y1LNDCxsbN+EuaCbGxaHHnyiZ Tzt26y7XmzdtUpKA2AEZmy0AMsvOKyjUh2WpYpeu3Xr33b55S/e+/U/69oXA3exVS5f2Hrp/QbMW VGtX42t+s+byU6du+65buUJTGMmcSGWV6AhbN22W0pRZZGezNLFmpTq5OeiQkUIuaE+hPAaK0rNz t+5vv/SikHegKmOUpcEtWrW65rY7JOVtn4GDD/naESslECMel5vnXnq5/DzkoIPlepW4ZmN689Aj jgrZu4GgZ1HBTwmMIEHmh3mFPD/kwBECr0mvvTZ3+nSWIAxo0uuvSQEHjDzMI4ACEzgp9HncaWd0 69lLroURHH/6GSLbw2Ss156qY/GZ07548aknN23Y+L8pU7p27yEWx1svvySfJ591dhJqBzlbDam1 HCF+oeT/vPD8ymXLBZDAeNTgDxeB5Vwfbg4O2SyXLVx06injhPhJfgiKoLTmBy9Imv7TojEP+drX Bx98RvcePfPKP1+xLqtsy7ztG+aX5vTv269vRf6QVm17HTrqqH4HnDZizDdGjjo+1KRqVAmRSV4H GHoOY3Sf6P9DZkJoN3q03Lw0JYkLC/i/Z2aVIoMej0UbSwb++ZOs29+v9UxZYJuyNSb9VSoqypaU bHPKpPr+hxx2cPfB/fcd1HffwXL20c8hfWL5OT337dGvT18B4PoN6199782Ovbu3aNPaJ5KXICLO X4fiPW0AW8VezV02/+Wqi1ZUFEkqqmbxqr9eciDOgx747ogHvjfib9895MHvHfLQpYc+NH7ktaeo TDBT2aJHCTeqmfShQCTKhSE8HnAUiGcVv8X7IsEOpjdCZRV0nPPp1C779YLglK8Vs/GVpCtcQHjB 3C8+l1OoXTgjq/O0TdrTRb5G0frNt4dE1XfQkLfnLpTnDunU7r9vvg5XheoeXtDJT7IgevmSxdSM qGg5RLBr0774gD5DZkdlOBCkbtRCdw2l+Mfsf2nktm1bv/jkYylDsim8/fKLf/nNL//y61+++cLz 4jodMGz/vgMHE2JARqtC/kj69+NPO33EqNHCCGTfGSN+UkAIv0mm77/xuqS46tm3r2hAC+fNleAC mQt4+emnxJwE1XlVVzmLivqysnmzZoVQNC5fF8ybK/oCXnG05JwhRtKYVqKEN/mua6+yOu3b7d8v PC97EVqB5hB0U3L2hmdEZoyQATRv3qxZYUH7LoOPPPnKfoNHH37M+SOPOr9jp/b77btP+3ateuzb tVVLzeffuXNn3VDHkawjXLNRMIyBOPc6tWmx+CmJ/gODSBwnbbYJ4099PDVj9Xn/DljAvq3yJ12w /yFdW6Z7vub7HSvXy44OZPPSJHH+r/5qqY+WVrgJ75eE6vm617hsXCU5DFYtXTGwR6/9Bw+VHzds 2vjqu2936LVvy7Zt/DyLDMH65SvbdOqsrF15rVuaC3Qq3PLW2rlt38s+e+6iNWIKte7U5u7/FM9c ukksh62lFXOWb7792S8v/PMH50+ccsG9U17+XPggOaeJF+9KDOOQY67yDI0Fr2Gq/r984QLp4Ma1 a7du3ijSe8ncuS8/8qB4OjauXdOiqKhdly5kzhJzqV/FEehoS2T+V/PnrVi8qK+mcI/Lr1Laqq+W SBWiGqxYvFBKc6hvBEZlUh575k/3yDOkz2+Nv/zqW3++cN48oyjAWiKsP3z3HbkQhV8m4YcedHBI a0QTHALxQm5tXLfunFGHzps5XeyCc0aPnDdzhl3MsIu5M6az7XaGQefwQHSW5x/7pzgyhOq+dsJJ Hbt0VaTMzurQpcvR40494sSTwkQojfCiRi6EVg887HBJWxp4JPl0aObMZKwQkmTFz8/ff8Qhn/z3 v/vsu6/seNWseYvHHrgf5Oo+QLUHHjpS7r392quzpknYmB4yd/DOa/+RiwNHjnQ+PRjNrI0mPueW LdGD0TZDHzt26dKiXZu///NRsgAwC/6Cltp/xwbYR0DYwI5aBOMHDejVqlXrtu3aDhrQV1Y9DxzY r2NHyZoRPjy0HRPUoogFRtHwB2HHQ8tzgdxnjP/nQWcwzUL506pd2zbr5ydWk/BNWMA5T8/wWkDb wpy3vj1UFgLU8Eq6n9ptW9q6Y2foHjqvW9Spk87QIOAW29poR9ynDfTSeQtat24tT2zavPmVd97q 0LNby3btlPBU+unWmgLN7Vu3t2wvN5WuQgikXysWz6ro9XUJ/ls4a/HajVu69uzabJ8uD364/JK/ fnTtY58/NPmrrv0HHHniqEEjhrQpyD1uSBen4LEHVpjjAqZT5RU269y9x1N//N37zz+T36yw8764 fu5ZeUEMhDXLl//lZz+WO4cef7KmPDCgx5ctKN6nVx8vS+1riH5at+sg87bYt6aZwEE+Tzzvwjef elxKe+GB+44+65sFzViaG2xcO9mu16JRj+hQJOff//j7cd8815qLKkSrn/X5Z/LTN792+FU339a6 bVuHfKYzWsmuucSp5OocknlUqtk4lFTxzz/2qBB/2w4dxn7j/wbuP/z0b19wybU/uuSaH53x7Qtk U6qAJoxSrOAgpoVkaHp0Alp5C5ev0uUuFQ0dMUI+5Uav/v2lARYbg9Ek35B5hwHDholb542XXvzT r38p52svPFeyffvAocP69Je0N2QWjmeA5uFksnztrjmWiJEBkN167te8fdsH//7I2nXrZCMRpkgy K8AzAlMfgkBrgfB6pzVIxppZM2fKhqbs5ILi4k+nTt2+bTu/Llmsh5NKHPdg+Knzm+LqU6G4NYuG Mpr///EniTvkPsAP3bZt1mefPt/7OwnQrfYlKf5X2IHE/z7yxcqa30r69fyqSQcee1x+oVi8Wrtw oBlTJnXu0b19107xKsljLXlByrN0Vq9cvlJBWr1sxdK5C44cfcTbUyZ16NuzVbv2motHpjaxclNg u+DzGdl5+Z169YJpp1utzfzvlJ9dcokuB47Hu33We8n+89duKf3Z41/EmxV22G/fjh1aFhbkCQBk 2CSv36rVGzYuW71h5errTh3Qo4PqNY7oA9zmVYhQCDtV/sIdlNCG5x+496ivf7Ntp858wR+SCXfK qy+NGnuqpOKVm7IxHr6eJhllghpZS0KRVnEykF3TqIsmlSA3AkGKqw3r11089oQ77n9Q9oGo03gl PByCR0qnUFLDhWCe+ttf169dK0q1EH9hs2ahhibbxaQ2/V+t6HCxybAxKoj95Te/Djc1/Nj3rr0u iWvxV5kC/PyTj0UVkuv2nToNO+igvuIRhAIJi8HsaZmPuf3++weMHq0iNB6b/f57p44ZA3OC0cAJ iyqXLFiwYfnKgjZFvQfIYjaLU3AMOv7SlCknSx4RNtSN2qIpky+78kq5MfV//7vyssseffxxCVyS r08+/sQTjz/24MMPN2/RQr6ee843xp46ro1MoPL1uM7/TfzVry677jp5QK7vvuWWC6+4onWbNpva iiAMseWq2Kn9+vYfNiz7Bz/84YfTZ+j75mflnLCqCiXbtq/asG1zC2BtmmPWmm0fL9t89sAOuv+q 5tGKS1DwptKKyV9tyhCl9t04Z0in3M49+zj9X3lRyzZtvpo9q31XqIWW3JW6tqonkuGrmWx7VFg4 ffbsffr1EyGPtFvMGClntizUXrlwaedevbJz82Nx3We1Kpa9ZslXRxx4ILdMzSudGV8zL6fz6MP7 Fc2aO2v1ii2rV65bumrjsjWb1y5btWH5qq0rV2WVbr/mlIHd2yugA3XRDRL/hpf8Af7KXGwoXP8l bmn2/z7pOWiwBjX6QcbrQuc9BgxUhzyGRhKO29dk2FWjfofi4Qc92bOWsJbi172En5ckXM89+vdj Tzu9bQfZtUH5f8ozwbgPafYJnCxUX5hUU3AtseFz82Tq8eRzvkniR1dMsDpAO3rzlK+wxk3Pw0zQ +Q455hvirweNGjXi8FEHudNfywXHKFlxgaYwcNj+Bx122EGHHT5w2LB27dsHcKSEhoyUaYx3Pvlf O1pesdiqRYsG9OgBgNvoh/TNWKs2RR267dOmvQa5UJOlOkkWMGfxkn7dupnkxgjI7S4tW/bspdG3 Mhm0ceOGww4/nATftl2bzl26DB4yhN3etm3b1886a8Hq1ZDz+rI8//GkSQePGi1Wj1xPeffdAw45 ROBc1kKEa2jKJiurf9s2f/jznyFw0RSle7XBbAd08SvIDNbADZ8mo2K176/MW3f6k9Ml+N//Uqfo gMHbZ3UW7xcTJBl04vktW8o5639T5aam94lny2x+THL7ZeVWxpnkL7dNl679Dx7Rol07cX7rjsNx ye0tu4/JpFHewi9mFnXqXNCytWwQIK4DzQiGnAF+eNZ2vblg/Rtt/9Gmxyujbxz4+bcO69S7KDdr w7rtS5YUbtu0b7Oqcw7uevs3DtinbTMbKtM3aeCpfsHVFJZlwFJ4W6pcly2KDyNHH1VHRiL45DcI lXfLMVzBbtmcvezKsKSB7i6MzqR7oakd30y/CC9YkJOsv4SlQq1jnf4B10eXkdi3v3pL+w4ecvp5 58s+eeyCpWkw2xgAckB2Crw3lr3eb+yNo+OkpnP1KCoZlXHWyxi4a70jPwdcb8v7RlPim7qvo+cl gDIqQNqtVpfm2uauYFHYnQ1ncIEHeNIgAU+xjHu+EnNRgYkcfeyxbOy+Pfa98ZZbOnaynBpdunQ9 eexYPwrnnX++7D5KqRdwb8eFmrds8dNf/UriHZu3ZDQ9J14tYQk5V3zJypV/eOJfkPhK/EL+xpGB s/OmT3u7tMdXnYbXihnH9Sx69pxBQvl10v+7b5w9tuu2gYeP0T02sH0YzVhtW1XV0jkzN69dPXDk IRLPBxGpUf3MmKi/I700gK4XNt1fGZv/2ecy4SbCH2m3NcYZ6BOfOWnSDZdcJKt9nY3jQteczRQI LuqhyWIfQ2/jT3h4WnJyzksUL52c4i7vedGVQjt3bNjDubrkxE/Jcr/6YwmqStKwmbwjw08SoGkq tFpTjL8DEhAFSI0DX5PAkwZ7rEr9E/Ld8fWQFkFlOlHwW4neLAo9EvQr3CV/HS7MD1swlMFcEVEg PMpO/otbLivrlvvv73/4aA1PiMdnT3r/9DGjTPSHGKorH+RuCSnpQSGeK9W+OGXyKYcfFuALOjpW V/Vkerz8v//5R0Xnv+PHP5acnd+/4Qbxd7rmV61o3jyEfnr7lB49+u+/v83iwBVo4VMWWAo/Qad9 uu+/xdyhNTfnteL14x6fLopAnYz/4WWzO/YQPQdoHSRmsS1xu/Tu17xt+xkffizRAOWiAsRyKmMi +fWzQj9Fsc+VT1EQJG5Xryuy5nz8aV6BJALto2q/bpJNu0B3ByJ75hgikYBd2yAHcpEDGHYZGn46 8sdfCCqXyc5tdRHKDWreXqoJUAmoMvBFvzw+ENX0IztxGTyboCP4L3bhpWsgZr36EdQVXo1vpEVK zVD4OxmbGgV8SWQCVIrsj+sGAeMPSwTI79hIwMHJdCgvtS1kC1weOBKYI/4asy0+R7iP1TSkAqEl GTFU40Ppk7wMhbWJKSO7CKGlGfd4ESVIdAlxCbGAlpUFa9QDVZ8JyC3hus25Ev1CGKjF2Svy1yIC M6X/kE0Wb9Gy5e1//OOv7v+rxD6atsumco886vg4TdYuWbnqD08+jTui+TOdsgsKAhueLyso1ud8 ss/xGTcn0wcP3TB5eLfm/Q8+VGLBJOhHY3XMXelMa8WsyuXz5qxfubzTfj3bde4EB6Figgkal6dQ nLBrly5bXlzcskPHjvv1FGTSvXnVOatbiql0kdVm7793w8XfccIfyA9eEDTXc/xA+JtuqZKfflun gZoWR9w3YcqSnA82qXDPZpL4cDK0EiQ8GxdiTa65Qau9CLSC0sp/EztoLdrm3L1sdU3y33Usoa0m /20knIGjDCAkNxU+SZ3wFQVOMtdFA2YARdNr/Six3QRJAKgQpOXHMLTCo2v1puynFWlqH8pnMTa+ LMf6Qn5y8/0PDBg9huEesya9f+Zo9Sm4x8L1GtBMwjtU8WPwwpQPxh0mU49OIfNdTNT1amh97SMX i61s2coNnsFnbLduA/bfX/T/VX968ml1/mFLNawlMfoHolaJF1DS7HyU1bO448HJuLoT33uv/3x0 0cZ+Iw4pbNVad6EF/SsQlDMBkiB+fFZt27Jx2Zy5sphfwgTade8mQSCyw7k8JHPpsgPH6iWLt8ni iqqq7kOGSsAMJ2SwTY1IIY3hJS+fPek9clnbMSaRtAIR51R/WmrIHwTpzf1uIKvMPpW/jlNwdG3s qN4BMwxNQZQahRzyEAY2pUNvvu/cFMn8w1FSAukncB4OBw1UM16p5uirauC55YCQAG4bVWwfkgkO VR9t0/iptbhNwSDKncXu1PhQ+Y5ujZkqSMCKnUTEtq7hSHA0PgxgRUwV2E5OOnamnWdFQN2ACDEM PKynzNKso0GF31M7chFzO0BAUi98mdQjeAia9hszBoFY6v8/YxR9ima66mMB7wtVHAgLG+0Xp3xw iuQRJlQSuYP1JMzqqo1B2oEL/1AVW9mqFWugoSVXY/fpOuCAA5T+//jk0whaNfp3iGv9lkclx9a8 aV++3WzkmjY9qyPBDtxpt3HRsVlfCvG37tgJxK/7T8t+G6biYVydKek0QQnrL92+ftXKNV8tkcBe CRDWwdatrPPadu3aqn17USI4uQqF2+0VxEFUt4F0R3Ue+OeVxaBc+JRhmFNLIN8nMpDyKfeVm+iq Se7npzO/5AKaWRyFkOQ5+nSlkgfIp/xH9gETJqzXxBRqYnWe9h0bIcabHRIyhw2ZDBcTdQ/CzTkq tM/G7aUcrGnR3WlsxSBW2oDbwqMCjM1gLD1eKSY5m0WVLd0miamUxccSHJ4oQmUrwNFIfRAbHTCS VgdEhlSbKhvUMPJfpYJb24POmk4ASsRaDNvwBcEskkKe9agqifLAAAlJj9FyzXkgQp8zC0gQFdpQ 0SbrFWXwjHwiOIYTZD5YRq9nv//uGYH8J3IlHGyA5z6hL2L/C/2PJFsypSBgA+FXDEvSEny1CsM3 VrZq7coCyMX+7yr0r/a/iTALTKCaCxtOFTmMY4vWbfbt1+/IrVN6rfo4Awyp5ZFeaz89uvKz/QYN bqlzkmEzm1LSJBd/0nHRodHxkpj7Nl279zn4sP6HHzHwa0cPGHNU/1Gjex90SOsu+8jW4zL/oLvq 6QbC2EMAdhfmFBhWCFNN8UFxDb5ZCkmrhVAxZoMf2DTPDnANNq32nhK5Pg76QRglJzAoVJgjB3yB uUmBs+Z0wCOGjSZPgJrAbYcZrMc9aNgTADbwUtmbRhd80FGIFuKzg2FWlxtnmVri63PYGQjMuo2y 18StRMhHLyitPgbz0vj0cb0KVEIZohZkI68yElT3urIEUNz3irtryaypbW6HTfV0az3d40j3DtQF 424PIlKTq8sDmsv+xHRnNkedykOCYN1oUE5uNo7NwsCTdPNp5yZgNipCGqfNWLEcHviL0Uk4vW/f /eQA7HhSiL87hNSCIAgTCbt64Ul1WSNSDSG0MvIuNlgRl0ROHY7+GNvdFTu9Godu06FDnyFDR1Qt GLH8jbohR+LTB616++Dcr3oPP7BINgLXsefElNlZIBW0im4YJU6lWLml8hlb36hJb/nM4hWVWZro g/uGa1m60F9ekRxASCYIhq7jhC3lND0QRtf6rAUS95wNS+7jkBIt97vJkudj31jH/HULGsU5JCnh Mnx4T+wJy+gFvRsrWTm9Sj0c0zDBGn4rgct2mdbDIrYgA128v0v/QUFk6/1JViwQjhzz8HA5EQM/ 8VOwAxYClPXgWgHjCR6BaxrhaqLN6SleJrLhXM1rFqVQqczD6uZjDkjWVhcOAybB1YPGI7BJkb7G NNtKyigzRxc7cHdNbFtE6U+Gg84YSfl5LK8vgDyNnysLJ32p8gOTkySBBHKIMSFfIE82KeICTBwL sKUSIRLV0vhOcNgXBzgPQF4kwNMkjhc7JpHcM9UVi8SRMvGVKLUSGgI5xM3nOG4y//f7x58i0HU1 ajx+5IHDm+Xn8y3XFwMtoRv0zjU31GxToklRfB6qGBeGElWVGlijPuByV7gh1DZ4gvQgSiBLL6q9 um5ShBRrME2Eb2gUnNcwGfpQPTy47HX8cf56Kidq3ZJthMGvEt9BzUS+ASBcZAJmhEY/uJ8IYr7r upSIVx7fXUeAzwGeUa/nd5AI9QmH7ja4QIbqoEjErFTfWJMNjFP4qfr7BtdQikHSmC/aqAV6B7WL BwPCQdEPi1kHakpbb2pDnXM0lQTrxK8KKgdc0hVBhTawA3DX2JAaED0FkIKMjowsHAZ4VHN1OBAb q+RwsMRwMeEbxs38LUd3CWAIoMuhAAaGydseiMdKZP+r9RvDozF2n84D9hf7X+N/hf6BFlmxo0cc +M4bbzzy1L8ctMmPPfbYBRtfjaMRhgFlGNlrGZBQ3CaRSWy4kykyW0AowN4D//fASUQeP1qsOIH2 3NdUIx4QZai8pAdTomlC90DsxG2yieCfw6KkFqUo04ixhgdTEb9VmFSeYZDXPAkQX7RjTkGBbgyN FRDxwvVlApNwI3xvyIWhXPJgS9J007Uzif69IcgwFRMPZFyUz15mJQDJkSgpn/QS1F29TwGEDIf1 EeNk/k8wykmPO5abyI3SQI6kYBTBDrB9Ifo3WeSRuxrr5C+Jg0U+4sQk8IOdSRJJJpHkyTOPPOLY sSeTBRB8J3ft5On/CQUAyPyU0aO++Z3vzPnvpBTYG92KIBBBoHFC4MjLv//Anb/+aO16bySR/nWd HE183aidM1s6Yx4dEQQiCDQhCNAqprMtOMz/Z1qKm7atXZFtCICBVREdEQQiCNQEAZKqxay47SM9 /cYXr1jxu0efsK3jY7FTj/jaN86/YP5HHzQECq+5DdLpTz755O23354jCeSiI4JABIFUEPjTn/4k t8d874q/3XXnh6vWwROnM1RjRf+XjDKg/8fVdwDl4DSh/wsubBT0L/Nkd95558UXX9xOM39ERwSB CAIpICAZROTu6EuE/n/zwer1cMSrd/UUpf8DOAtMy6DxgW/+/PlC/M7rHP2NIBBBIBkCRtW0+21p NUleDyyrDbwC4dnTRsAO3CxqI2hq1MQIAvUIAZsfNFEfzBO7+F82LdE5WI/NzbBqRNbVddo6w7Kj xyIINB0IJIUkungBn/8TwRuNrrvMkxcdEQQiCNQMAWZ1d4F8QQgvF6iFNm1JDF3e9WB99XLJWITj 8lfTli4PHfH7ebVXrimDoiOCQASB2iBg6yzCC6/wCreqZ2S4xYfXVlTsb+7wT1a/k7qQeb8/4vTY s5K1UI5pA2YbA5C7ygwyJfpQ0dXp/5VLsYw5dIy+J5GRzLtndHbyvdq6nFDqpa/o42kqCt+uXov8 WteqqzdtlxRSW4+j35sWBBjErwu+dbUk102D/uV/QPyZ9fk73/kOHxSy959y4e+nLWbuzA8PGSDJ 7vXofeWVJ7ird7b98YTYCX/c9s6VvTNrgj1VXf8/8c+yg44cL14SO+yu2Xr1/oTEMntPeL/avQwq tdKk4PvGKgdIX5E9Ofuu2NUXJPGeDOqJHokgsBsgYEu/LCdNWP/nKhAXFpyhMy2JBWRE/PLQCade 9OF1FyVp9ir+05kEsBbS6wb1YP+fePolsWmzM7BNek+4/pLJT7yYwZO7YbijIiMIJEDAcpb4hXzO zHfyP2QFZAi5sLSvXfJboSLjp5311JCQ9f/q5UOuG0KTYNqvpp0eNvudtSC6QZojY/pXnfnSS0dn Z4vo9vozLl4Rc0AP+UEtAxw16eivPHvfYeeMrZuaktj6OVZNUIuvWFuhR2BF2I2Yb9zoe2YHxSW/ GO5mhsMYPbZXQABmPk7IfuR80sPy/7vkLHtgMq33le+Q1OEAnDd7WuyiU0ngva/8fxd9OHOujcdT Fw156qxpRvs7YBskD+vkaYMeqqj484kJ9ydffVtM7kKrz74Al3I9+epfkw5Dx+Sr+4E3PHt6htbD vHtuS8UpghpdLa9c2u+Jc2CqVLwYuw0WQ2Bc3Mcb8szVQ17URx6KPXGfNSvFi7FYym7uFSgedbIm CIDcmakonJ9EHQHh1QNJ84Q1lEjjn0f4OqNh6H3lA7865IHn0s8AxD6MxQ4JmEGaQjOW//J+Sql9 2F0PwT2gWr17ILWGD6t+9l2H3fdsNdaQmlMowSb7HrQZoRphRygHdMxl7H2Tp2MtgykAY43U5ZnD 7vohWJeaFaww5Yupu5nRmEQPNWEIMIsWttPU/TB02a8emgXJVtH5WYBMoOAJvrojoKbXX/29s/3n vfQUXIG9+w2JOT4w7/c/f8DpArFDznrgnWdjzh5IMzdQF/rPpFu1PdN7wkN3TaNETn84T2GyrlHD K5dAtOMQBUW0+rEx3BF+U3OTEl+srfnR73stBHxwj892QlDo/B+yy1m6uUwMgCTirwMLOKHfTLX9 5VCjH97+E/4IWwD3An2fjZPf1FmQPhRAdoCvlvFk9w6xiN8hu9atrxzQtHxr+pzpkw8b1Fcl/ItP TMY9ecZZC2pW8LnqL+7erkelN2oIaIAf9tURmY8tseQQdYDuf5cpUhlBrb0Ugufhn6x+J00hYse7 w3v14BDA4af/vLmP3+R2Gvtf6L/W1u7qB0784S6e2DvxzzpVSO8C/JCoQb9fMH2Iyf8T/wwPhd6L nWP6v3gJkl7c1V2Nyms6EBDKx2ofNQHMBaidiy9btfqBfz/n048dN/KQ07957vyPG8H6fyGG++67 b/z48XtYBWg6OBH1ZC+AQGlpqfTy6MuufOiuOz+T/F8m+OPH7NOp3zDJ/6/+P5eUE/msGxFMovjf RjRYUVPrFwKi6EvsH3PDa6JvtEZnBDQvu26jgP1/GhX914f+X7+DGNUeQWBHIIBZP9lFIc4zB5sm KP2L/If010NYQOOS/xH97wguRO/sjRBA/D8z7XM/GVsQaPJfiV+2VsH9RnN07Nhx06ZNbk+C6G8E gQgCyRAgMXNtn4h9OWX5j3wyFDC+cu26p15/07bUqKoadcD+J515VmPx/3311Vfr16/fsmVLo+FY UUMjCOxZCBx00EFS4XGX/+Dvd/9m9satxg4kuq5jUZ+h+8dXrVv3zJtvy13OCB42bMgJZ3y9UdA/ py33LDCj2iIINDIISBiZ0v8VP3j07jvnkP6h4h/cvnXvYQfEV69b//y77yntYxrt0CGDjzvtjEZB /41sHKLmRhCoPwgI/f/zd7+dt2mbb8KB7Vr1lvk/MQvU8yf7qmZn5zY2/1/9wTOqOYJAo4IANtbW TF8yC4ATgcBV8bUbNrw6GdE+0P+HD+h31CmnnnPsUY2qc1FjIwhEEKgJAh9vLH3i979dsDmQ//u3 bdVz6LD4uo0b3/zoE5cOvGpo3z5HnHzKsi8/34VBdTfffPNVV11VU+ve+0nRuNjz6+8YE36o+OET hz967tRXzu+pd/WRifh5/D33TJ1gP+gzE6bYWyPvwcOJ74VelFeT68CbQdHBA4mFJBUZtLJ6wxPv pCoa9fne+idG3nPP8AkTqkHB6krVUd/4hJf4pPT0u8UBbFJ3PCKZvQYCJ1/1o6f+cPeiEP0Padtq vyFD4+s3bXpv6meAg5L84F49R5948p6m/71mGKKORhCoFwicOOG6Z/70u8Wbt/np/UFtW+07eKhO A4rZL6fa/xIG2Kjm/+sFlFGlEQQaHQRkb2/J+SPL/nT9H05u+6MB/7m5Obk5OXm5uXk5udGMWqMb 2qjBEQRqhUCl0r85/0TEZyP6RxR+pX8h+7zcnLwc5QISG1RrWdEDEQQiCDQuCCipx2I5SvkSBahL ACT2j/QfE7KHBiAqgIYGN66ORa2NIBBBoHYIyPyfxv/Hc7JsCZBb/yf6v9J/NuW/bg4eHREEIgg0 OQiIqBfxLh4+BPuYn0/9f3LLrQBsZOt/m9wYRR2KILBbIKDrfXT9r55q/6MSjaAXPwBX/mNtYCPL /7FbQBUVGkGgyUEAe39qpk+efuNslf+Q/vIh24M1svX/TW6Yog5FENgtECDB6zYfSABE9R/y3x/i CWyEW4DvFmhFhUYQaFoQoP7v9vpjNiDQ/8YtW16f8qGcr0354LUPPly8YkXT6njUmwgCEQREyY+v 2lby2eoNn65a/9nq9Z+v3rBN1gUL/W8vKZk+v/jLefOnz1/w5bziNes3RNCKIBBBoIlBQDT/TWXl izZvXbJl+5ItJUu2lpRVVOneXxIHWF5RIWdZRXl5RXllVaXbGrSJQSDqTgSBvRkCEu0Tq6yqwokP bAGq9r9cIRrQLQLcm6EU9T2CQFOEAPb81Jh/YQJq+8s2APpp9B/uMSYKoiOCQASBJgUB2/FLnfyi 42P5jxwi/+Wvbgqi2gC4RMKkQJMCQdSZCAJ7KQQo/5HUA3QP+W/6PxMB6yHB/8iquZcCKep2BIFG C4Fp06bdcMMN8pmyB1TpaQJA1pMLYC9ALgWWsEDuCxQtAWq0OBA1fC+FgJD9I488snHjRvlMyQJs Wy/SOhQBmP+w/yH6JUBI1v5qcJBc7KVQjLodQaARQoDEX1JSIm2Xz5QsANt/UOU3TYB/sP83dgaq UsKH/h8tAW6ESBA1ee+EQJj4W7VqlY4FmP4v0/1Y+I+JAL2Gqa+LALBBULZsEBrZ/3snIkW9bnwQ CBP/kCFDbrnlFvlMyQIw5yd2vwp4m/pz+j9+ER2Awl/d/5H/r/GhQtTivRACXu0Xsr/44osFAvIZ ZgEBTMAAVPALE+D8Pw7a/2L2OxWAikB0RBCIINDgIUCb3xM/2xtmAYk9gOBX0jfiB/3TD0izgJQf 0X+DH/iogREECIEk4k9iAUn0X6GRv3pUavivk/9YB6CUz8mBSPpHuBVBoFFAICXxp2YBSvOxqkrh AMoEdJkPyN1MffUGmlJAJSE6IghEEGjoEKDNn+4I/6oSX0i/vLK8olKW+8l/kjzX/+DDxwRFDKCh j3vUvggCdYNApYh9ofyy0ooyLPQV+uf+H0r6GhZMuwDzgtGRAgKyT1/RT97TH2SDvaITHy6OoBRB oPFAQAhetgApLy8rLy+VT+ECpPgsGv2qHRgjqI8+KXGFDxIaduZMecjvSoXB0aTpMWI49YGTTavO KqF/yfFRKik+oAFA/1f5b/uAyaWygHoU/rJFrR3Pj584jgQ95o7gHnbvtcM2CpYNf3nj+eEThu8x FtDz/FfW26bETQtHot40XQhUivivovxX418Oqvqq/2NOANYA/9b3Mebk8bEpM5bUoRljvnvPyCmP vldNJ6fkfNhrEaI3BCqFUzKSNY3Q/ZCSYZuPJ+n/CQpKOg4E0+Fhr6+EHwu9H1RLU8N+OvFE7OI9 ZcJw1XaqV8EuvmelV1OMfKkpQOEBnKhLmZmTpH8lQKsOQxM92iAgQBNfTAB3wNiH/58072YG65/8 ix++fWJs/Mlj6gq34T17pnplyoQZJ0NJmHrPyInjim4fCJ0BX0JmxrippksEyoewiuETYl7FGJ+q 8EBBWf/8+CkTxqd1C0x8NDbRWhGbMNw7Eny1Ur3pPKxm4riX2OpXXnlF2hozVSe13jFlwu1WuihG qp7YkdBJKTQRFEHvU3dTGFAqqNR1WKLnGwgE6Oanl8+5+ZD/W+YCVTmwX+qrtUKbPIY/eu7U9abh Z9aY4ofHT5iSjmOMvOe7ZCU9ew4XG+Kn54NL9Bxz7sjY1GJoDO+9NHHkPRN5PwZVAspHwu3aG1Kz 1uLqDVX83l+k0dYcodqfCv/4i/k91NapAwSC1ic2M9xJ/SUARbreh95PA5XaARE90QAhwABfXe+H jQA0xh/T/LD/ne1fr8o/rXuVdRnr/qYUF0F+1YFeEsenuHiqU6/BfkTbVsagt2s/UloINb6mbCjj HtbegBRPBEaF9qWWI10300CltuKi3xsmBLD/h+z7JzsA5uhKH933F3xAnf+Q/MwNSu2g/g7RXkMa eC3t8P6/nfbHBSVR6TZloDbaeVhs8+HOK/l8SguhWhFKWCMHdttdIA5r7eCmO3HsGFR2osLo1d0F AU3tIzxA6F92/8xWLsC9QNz8P/IBW2LA3dWGDMsdc8fUe7yNnOE7O/MYVe/AdBeRrqaxKs9eI4dP otqxZMaUwFEh+nImrVCtf+S5Y8TYUEtj4u3mMdAKvHqeVE5dNAZwFxQvR/F7j9Yq/xO6qTaPVZ4G Kpl0MXqm4UFAdvgz+lf5L8v8JcePS/UpccEMAEIasPqV/4Bcz/Mnwle3p3zO4sXTGUTnf5gwHM5H U0Vwd3zs3BTSfcwdqqvYay/FapL//jF1qZl6oRW4alWPSKt1gFOgnlonORV0wjzZpvEzhtcu/x2w 8Ua4E6mh0vBQO2pRBhDQ1F7Q/6EIZPscP/F5S5f++L6/IvmnaAVZ3z72mO9fe+2ct9/ahYbAzTff fNVVV2XQyCb6iKrksefr5tKsJ1CI7qPu1wztn3pqZFRt3SFwxg9/dMfNN7+2+CsmARPv33cG9R9+ 8MFe/3fxv3UvOnqjyUBADQZvPTSZXkUdEQgw94cs/tedfuKy+o/rfoz+6flDBGAD0P+jAduTEAhN YdRohezJNkV17WIIkKwrdKYf/n636k/9/972r3fv/y7udAMpToOEdnh2cvf3IRQw1KDbufsh0ZRr 0Am+GFb/V+kpy/8QBIT5f0sK0iCCf5vyGER9iyBQTxCgVq+RfroOUJYCCzfQg/G/5AU+/0+UAKSe RimqNoLA7oMANH2hewvzwVdv/1sWAK09Iv/dNwZRyREE6gUCmNi3SD8G+3PTL4h+WwJkewJG+T/r ZYSiSiMI7D4IQKjbYn/N92EOQNK/2w0E1Uf5v3ffKEQlRxCoLwiEJvaQDBRyn/k/sQjIqf7BJmH1 1dKo3ggCEQR2AwR08k/df6L++/w/FP7GAbgXUENyADTYvHtBw5IHKv0v/skmmNKrIQ1UEwTvTnID 8+4jxqeiXLOBufx/9Aow7B8xQvWn/3Ph6p6K+t9JiIZez4Dgd7KyNAkSkxL3+HyIukwg8ZXGB9Sd hFj0eiIEwACwA4CkApYsgOVc72f6vwv84/4/9QM7XQI3fvz42MSXfBaM+mnIzta6m+J9UiRIDEJ3 QjmCQuuX3SuaXWjP8dUoQeLOYtDueB+BPjgqZBMA0QFwYP6fy//MB2D7ge2OJtRYpsaejz/5Dl3q lgkDCIk+tygurPWluw41IbPkgImqZApJLw9obkBb4KdyNvRQDan/klpisrvWBX76Wp0TJOpi3pR8 NTMYSJUpwK0t2TUJEhN0lQACqeqsCaDp8p6kKqda2sTEhNJNTl1imh9hAJoIXMi/DPRfafP/qhvo E9T/9zjpA5NA/pK+Tpbd+1XxaVuiqflc4g1dQ4vxwlJ25g3FyneXEVSW6adb1JJBcsDaoIFlwj45 cYo431Sp/xKJ3/cls8QHO5ggMV3SkdphoKsCHbjDTdw1CRKVgbrsi5KxJGYjmKZOgZwHaDjlIthw oO/4dc/p2i7lhNMmhhFKUjlaZrjaxr7+fp9Xl0ObiZh/oX3dBUSkf3k5Jb7l/6Iy4N0Ae75fSIbH ZfdKxSly+SaQTDhZRpBHQxNlQHkQ8o/d8/w9MRSjiexcRozkjtWeHHDnQZEi9V+4L8r3XLI/yOl0 uLcTCRLf+8m4nYABWHOKJu7CBIk+IZpwU7DQdHUq5DxAQ3pQwvMZgjc5baIH/Jg7muQCaE3yBfVf t/9D/K/G/3D9D1jEzuP6jpYAVHJ5OmtnAOmqUYSQUVTyP3fMmDHnKgPQjDhpUgPvaGt39L1UiXw0 h5Cn7KIiMSXSJQfcgQSJrmCVjDuO0mmauKsSJCYkIHEZTjIHCwdDn091ZFqOpnJx6SQbows6A5TU +D9O9XP/T7nSRADq/1f1gAnA9IE9bwBo2qkA+sh3X7MGUAMDmDLjPZB/T9UkhAG8NyNtauAMgLZL H0mX+i/w7CH7YI1rBeuUILHajik73J26NDGoJKx8yy4t6RIkBW7MhCTqO1Zn9S5mVo5P5Z6cNX2H YdYQX3QTfJr+U9qH/H9C8xINUI+LfyH9bSsf29AnIRl2MiATk2Un5NHuNnDkxAkTQP4wJWITJkzc qWybYZmdOgtgLCaVptXaQ20PUv+FbjK3V3jzj1pdgHs6QWKaJu6qBInv/STosUISR13Bopqfdxsp oA3EGZZjOR/xEvLEN8WD+f40EbhkA8zRlF/yXbUCrAkCH6gPOwCpL5MMdAxnDdMASgIypYVDnUde ZCLlvS8t8duOjWmQfC9NFkDNFKgZRJF0L4XjOFXqv1BTRPgFfdHepPNVJLyzRxMkpmniLkqQOObk hNyLZqjUFSzGFJnFcGCQ9zizcgRRHDolIdSOIU0DfAtRfZIFMFty/0oKUNC/fJ21ePGlv/2d3svP zynI+96JJ/z4pz+b/p+XYQvsmmMvzv/XiFL/7ZqxjkrZMxAQ93/mFfXu3fvUa3508403Pj17Ptx/ FTIT8KPRBx80gvn/9D+DAHcZzWfeuOjJCAIRBPYABBDYL3sASJbf7HiO5P/n/h+B3q/pQSIGsAdG IqoigsAehwBie3TbLzEB5Mhx+/9YaIAL/2sQGwDsceDsrgp3Uyjw7mpuVG7ThQAJXEW+bv6njID+ QEz5uf0/kBc4UgKaLhZEPdu7IcAw/2CNr8//s3eDJep9BIEmDQGf3sOCe3QbADkw/8e1ASL6ER4U eQCaNCJEnduLIaDUHZdlPm6RD+P/GPenIQBkBtERQSCCQFODgBG2rPELx/fGZy5adPGv79Q9gQsK c/LyLjvl5J/87Gcz/vNKvcz/33TTTZmAPcPHMikqeiaCQGOEQF3n/8f94Lpbbrrp6bkLofVrLNC1 Bw0ZccghoP9f3SlTAjkF+Tl5+ZefMrZ+6f+uu+6qeTyuvvrqiP4bI8pGba5HCDj6X8T8fjIZeA3o P5j/1wVADfaY88AZvXr1OuOBOQ22hVHDIgg0eAio41/tfbgAcLj1f/zGPQEa3DHngetu+2y3tKrh JYoMkgftQFZBnwFnT+SvaUgJP3cLcjTBQn2aD0flmP93B2f/G5oP0FH/ufc9c1HfGsckTZbMJjiO KbukWT5srWsD3m50949GKsbpGX1iytRg5SFxJ7z2cgf47+7v207UYNN8WObvvXvU/7kFECm/vjUA UfWvfyPo5hvXnwDZf+59tx2TSedTZMnM5LUG+ExdYwfTZRdogF3bvU3Cis3ExaOaHihYY+oXm2vq uBDJjx8/fMJ4SZ3cFA+SPbJ+61IfZ+xb/A+mAOtj8W8yqDepqv/oJc7Uf+P6Sx7VRzKl/nBxyVky 06SwdK8kCgZToJPtgzT2QvWslEFpCcv565JGMyx/EjSblAkCNIGdpE3BKmR7IPRSOL+ALlK2n1KV FIYDX6u98jDYw0+nSWWQAgrJwjb8PbP8naE2VMshiexgPz1fc0IkHMopwplmTr5DOMJfGnn66ZTc y8J8kOdHdwHmSh+//48ZAZYUrD7535hx52r1n912Qq/rr98J6pd8rrdPjDGloBw1pIG03gZJaCQJ pUvJkZhpJJaQaiQJSglZKYcPn/FTZDJJSlG5+9Jo6vp3yXyANCqa6iucVVPzC4RJceK4l05G66rl BEtI2CO5OItVGPrMOIndSYUlqXN5Jj6ZMndrkMQRDwf54DLM35lYRVIOSZdbNjVeJySHk3ZMvb1J qgAq37nzbzjVp8X/KWRgAdS3969l34tum//q9ftrgx59dAdkf+osmTWlk6yOFUgbYtkgw5lINE2Z 5yjJr3n5ojlsfDLDdCkqQ5k+d2EazaBNCZwqiYvFfDLP5D7gLZfpU9Ka3JEsMjPJPF4tl2dCLcj2 4lI9Ms0P6C1MsqGMMDUNXHL+zlA9CQwgyC2b1N/ih8e7rLP+F4FVUzUCYORXcgLAhfox/q+BEL8b hL4XPTP/PqgBddf8U2fJzCgNZOr88R5FEzE3tSyp6e5uTqNZ9wZl/EbKLP8p306ZyzOzesCkkPUx rK1nNHApKghKU10iiWu7VJPDJ8RCqaNcKTLgsSZpBOjkn078VWn4j00AWvwv++5cf/WtBGhbjoEa sCN2v76dKktmzWkgNVNPKAu9zx/vJZNkFU27jUBmGC5PZZaKMrm4DNNoZtyKOj1Yx8rT5PLMpEpR LqYI4VXT1ncMaFZayJTwbQiSTaZMiqxMrKkZAYz6cYeGAJIFmP9fib8hUH0CmogakJnPPyVyJWTJ rDUNJJznLvMedg8JDqrP40RVTOFCygSx+cxuTqOZ2JAEezpjzSWxicUP/0Q0c5XA3uhRWVrTkTKX Z8ILNeRuNQipVLZU8HXPAxqqi5bbT2rY/SFtT2AETKi5q5kPfIN4EgwgW7L/aNY/Cfe3Xb5zLP0X xb/7qMcWS3jvrqpd+fijw8cVxZ6XlNqSZTN2ojjHrXARAQneYD47vGiC/j5y/Hix/5NRaWJa0z/D BmsqyhRtUF1lRtG4IkW3kffcMz5WLZO9Jqe3B0SFkC0SMzhYqnVI9Y7q3u8UpYTbIj/La+L9q0Pl kstznKsTr6eoVRmzHwkZh1fMRSv1wfEyxbI3s3lpgJYBBMBOhkv656ShzuRVsiKfRTijVxr0Q5D3 SvpJLr74jIULL7zjV1k5kv8zT+L/rzx13P/72c9mvv6feln/02BBKNbB7QOn7vgWGg22Y1HD9g4I nHbNdTfdeNO/5i1Gd0XSx687aLDF/weKf0OYAWiA45EqQ3kDbGbUpAgCaSFA+a/ZvzQBGFYAqgMg bP83OAdAAxnOmmb9G0gTo2ZEEKgFAiB4cAEyAj4exP/W+9R/gx3BugbiNtiORA3beyFAfz+3/fIX IfkfCf+9Fzeinu8dEAgS//grN//fIHz/e8coRL2MILDnIUDXXrAMQF2AahGI//+Cn/9SNwSU/b/y C6487ZSf/uyG+vL/Z5jYJ8PH9jyQoxojCDRMCJx27Y9vuunGp9X/b7L/h8MHHuzy/1ibG0L6D8n/ VfPRMOEbtSqCQEOGgJn3FvwfxPow/0dk/DfksYvaFkFgpyGgmn9cdv7gTj8+yYet/6Fd0HSP0Lr9 hpfyKzXYm1r6maReBsOwmwakicOv7rRqtr+sAfKr/+j/b2oaANfx7YkUeDoIiXlDghRSycnIsDM9 25UuB1XdxzR6I4BARPA1YENIulvkPx92+/80HfmvwXoaI5+UAWq3UkqwoExyZkwYDtYTZM14XgL2 gzVslpovXQ4q3869JupAVwzuhsjqvQZ+O4XZQfxf/Wf+26mOuJe5evSO6ing0mvZgWDGM8l5t5wi kZF8CacOyaw/yTmo3Fuh6qghPwy1pgbVhm8kpvaqlgOsxoxmqTKGVS81dYavWtKrsVupUiyEW5RR F5KL0nxnmnhIFlBZ9hcdssThSp8L7WEBLo802coyG8ZG8FR4+t9lAAjTfyPoQq1NdIvHq6WAS/Vm 6hxZum7Ukv9guaspErpCuPYVgBorHCSarLW57oGEHFQp35oyYQZzdgXJyVI9l5DaK5zT4PnxE5ED LCkXUCjXRqqnrYpQqTEhtFCehNiMJfpM7enV+JBPUKzdSAOdWrtAPhK04vnhM5Yg4YNXs5LSH9eY C+3R2MRqmdoyHrdG9SCn/22zb7gBgvi/gDc0qi4lNzZI9ZSUAi5Vr9LlyJIEXkxEI+Q//nkhHM0l W2MOOZdQpqhonCw2rpMymyoHVarG+pxZNWsY4dReCYnFoGaAWBMymmnCL+ZITPM02pKUMKxahq+M 0qslPFQDltXeBeYzmOjWFo+5o+Z05zXnQnM5HTJJbdaoacNF/jL+1+IAkuV/454FCNJGJiaUq9u4 gXUIqSj5nzxG8EIZgKTBGDmwW5qCzJhXCWSaQ6011pyDqtbXM3hAFZaAMRVpemA2LsiPHYJX2qeT akqZ4SujLF36UB2PTBtVx2KbzOP3339/DX1J/DVxd19MB4bkvxXT6Mk/hPHIhw05XtdDGcDU4odB /pCXE196uHhq7Wp9QsqhWiqtJQdVXZtcM2OCghvk+3XGkZK/y3mkBQRtSp0dmJWkyfC1Y1m6au9n Zo2qvZym+MS0adPSsQC5L7/W2ummZP9Dmmn+a39o9u306dzT58jq2XP4FMn/ZJqxMoAJE6bUbqOn zjtY6xjspgdo6Qf7WYgV7FyZ/Gm4WOM+o1kNTye0L2WGr1rTq2kRsDtcbm3VyWvvd5pGJd1+7yfo l+ZdTql97VgutNpb1yCeSMkC0hE/koAlHI7+g4igeu6V5P+q+UjXvlRJOsKmbor31GkkGfnh/NXM /IHhri8G3r7Eb7UASPNlCW01BGeyTIH5/qGHbjcEEmOoh6DP9E+HuiwZvgxiYZhpli7ZZMBNUIyb GlYr3NumHuGhlwam9f8lwDdNo8JFiScQhpkxtRQTJOnHuZ6RfWerz8/PlyKSWIAnfv5a7WACALsd n75g4Xk/vyM7Kzs3vyC3IP/K0069/oZ6W/+zs/CI3o8gsDdBQCj/kUceKSkpkU4PGTLk4osvDhP/ t7/9bblJeIy75kc333Tzv+Yz/5ccVdcdOOjgg7n/t9v8r+GlAN6bBjPqawSBOkJAyFuI3GsBN9xw A21+uRMm/hpKDfb/QFRwlAagjiMQPR5BoF4hEGYBGzduTE/8VTGu/bHTGq35gCH+uSgIZ9NeClSv oxVVHkFgl0MgzAJqkvw64Qe7P7QASNf/VlVWkPiNEezyBkYFRhCIILA7IUAW0KpVq3Rqv4r1uDAA T/qc6a/C+h/ZEZh7gtssQOOOAtidcI7KjiDQQCEgLOCWW27xDr9UrYyD+vlpR/zL4uJv3nizbP8h yb9yCwqu/voZ199w46w3X6+X/T8yTOyV8rHWrYsa6Mg0qmZt2LC+UbU3amxGEBj3g+tuvuXmp+Yt 4tOi7f94+JCDDzmY+r8cYgJUygV8gPUp/2tL/3VXRt2NHoogEEEgDAFd9W87f3AvUP4o+n9VVUWF 6v6wAeqb/KNBiyAQQWB3QEBjfnTnT9kD0LYAklriIv+F8CtU/kML2Cv8/28pA3xrdwB558q8f3Rs dE0LOnak9LeujsV32Y6qO9KA6J2GAAHd8Ysb/+r/bPnkbkA6/w/ZrwcCgepX/d9hWBUL8SCyMfm8 f94Ol5nmRbCP8ElWMu/+1A1Qkk585eoGyHt2NZCi8hoUBLj1X05OVnaO/BMOIAxBZwMR/0PNH0yg 0SYD7Hnx+xa+MPe+WGxUbK6LZri4d7WBOEqfPGrnxudNV/6bV8WOHh0TJtP7YhddMVfqj903176+ f7HVZK/MjX10dCxiATsH/ujtukEAFn9cdvmA/FcNgJuBZWHer9KzAOj/Te2gDqyf0mOh1ZD+r0J7 dOx+/iSnqMohWZ2JnD7q1FhsUsz8qplArnfs1qtidz+X9tGrnXIR5hFh5cJrNAkqT1jJnxcb7Qo5 +u6EioJXwLP0IDRcryVFUHQ0PQhw518hfqF8kH92IP+F5Dn97zcIanr9j90de+5UCOT3Y8kKwaTY l/xJ5PbdsfjPTHe4b1Ts6Aws5/t/FotdVWdtYtTg1DCedEnsVGgWosXcfbQ5KYT4+1wSo/og9y/p Y/e9ysOWe35xdR9RP0z7EPXEH0L8lxxs90VJ6hPq3dHP2X2XVKcJosDe3iWKhCzxAgbr/5D/G8o/ JgDUBdAkVQAh0bvSafyjYlfwp96xg4WWbzUGcdSFsdhHTkhWw52jnYB98MJYVZ0mJd+KiUy+ME1j Rt1nrKT3UWpEzIOMfuvB2FVvuvsXS1fsftCo3rELR8U+okB/K3b3qNhDzugInpkXe3BS7E3X1Itv Teidv7+3E0kT7b9f9m+7f1P6W/5/tQAcE2ii/d/l3aI0Fh1h0peZlm0s42gl5hReifTFfDlJdQHv cbw7FvuS9kbIVLlkkr1PlpHiWCRmSsyzrfjRdTRbMu1l9FzDhAAzfmm0j51w9QXrf8EAosU/dRs8 0cCvujvTSTvvMkyriaSvXFhGePWWliDEf3TgZRROlMnh28DSdtIJmkmN0TMNAQJc4qeUH1P6t+y/ VRL/r8a//ia/GAdoCO1tPG24a24sdsnu9edfEfIFqNS/OiYuQJXzo2JH0ZkB3Z6HGg6TYn+wOcnY z0Rb4HGUaithj8bV3gXYeKAdtXRHIcCl/ZW6CBgsgOXY+l+V/PAB1rvxX1v6rww8cjsKoR18r3fs IdDn7pvSk5lFcft51f3oj5Ts5ab68OiGuCB2sJf/vWPvv+nshQtiF14VdEu0lfs+CuyIjy6s5grd QRBErzV8CHC+GsIfygBVgPjnc+aMu/oH2bm5kv8rr7DgJ+edd+Mtt8x55+16Wf+zM1CM1v/sDPT8 u9H6n10CxoZWyNevu+7WW299eclS37BLB/QbMULW/wRHpP43tFGL2hNBYBdBwDx79ieYDhD5f8rV P8D63/zcwsL/d955N916a2OU/7sITlExEQSaIATOvPaHt9526ytLvgrk/8ABI0aMCOf/1JUA/FkS 6G/YdcdVV4Vs0CYI26hLEQQaPATg2pMAfyz2xUp/HGr/n3LV1dm5mv8jL7/gJ+d/++Zbb/3o38/u gQ7NSztVvQcq39kqeveuvq5gZ8uM3o8gsJsgcPrVP7jttltfWLBQQ/+qquTz8mFDzf5nCjA3+9cE 4/93E0yjYiMINBYIVFZUyFleUqJnWZmcTPZB/58t+lHS3xXkL0nIf/SjH4naL0fNWxQ2FvBF7Ywg sDMQECogOQhdZLIt387UlfJdIX45jP5LSspKShj07/f/ssygO19x9T1Jdr7MqIQIAo0aArIzDzNz yl49smPPnmcBQv9V5RWlJaVlJaXlOBnvmzD/J7EBOyn+I+Jv1GgaNX73QaB+WQCze5WXqv5PFqDO /kT6d33fUR4QEf/uw56o5CYAgXpkAcjyUVVRVi6H2AFyBPLfggF2lOw5MBHxNwEEjbqwuyFQXyzA /PtI81dRLlOAFdwGKND/PfnvGB944oknuA+pbEIindzdcIzKjyDQSCEg1CE0Ql+AUM2e6YWt98e+ 39z8mwsC3f6fbMWOkT5ePeecc7gPqWxCGPn898ygRrU0RggIdfiNOoVq9lQXXAJgZAAXHkCtP+z/ 2ykekLQVccQC9tS4RvU0JggIXdR1i+5d0j3J+SlkL2F+cmZJEtCcHGUBzP/LlcFWzU7EAEQsYJcM VVRIU4VAfRG/6vya+1/oP1fOnNy8nNxcrgOvLv93CvgRC9gp8EUvN10I1CPxk/4l+3d2bh5O5QIu G2gI4lW6NejOHhEL2FkIRu83OQjUL/Eb/cdN/6cVwE0Adf3P2Kuukozgsv4nJz/v+vMvuPm22z5+ 7t97YAii9T97AMhRFREEBAKnfv+q22699dm5QXLYq0cc6Nb/Bua/zwsQAS2CQASBpgMB9fWJtY+9 P3hiGjDu5L/sCybyvyD/+vPP32Pyv+lAN+pJBIGGDYHTrr5G8n88X7zQN3PC/rL+d4TX/8UpmJed X3DZmWd8NHnyR1M/FQ+huQpyxFrIzZZP8AxsJCqcAzuG+E8GE7qcgSEvAlcZVmGyQTcg5T6EtgmB 2h8yA8G5SHywDEtD7ncitfL2jHISajx3SQebROP1IosbJ2CvJLa1QiIrZQNlTZ/K2wri6o4Ua72V 6EpOgTWYliGYQkBj9n+t2+/d3rAxLkXrHHxcMBp2ndCMlFiKZmOvPmmFAKBNGYU+E0ds2woHYiSx 9E9ZlamcWAa7mkBmrwGJiYEYYoyUHgZ5aw43ysTC2RB6AtG5s55raagoYAjwpIaW7qpRTYTCyJGH HnnCSW9+FeT/mzBs0EEHCf3PnXvK978fzzb6P3zYsIMGDmjfpg1oXucJlPJzhBfI1qGyZ5g/0BHD dnYI/XLoLRcONqAIUrzQP1kIKco+zRPBMgh6wsjilKzYtIDZhXyBQAN9+yHHQCa2N+g4Aiq5fTJy qhBp2FT/l7jjOuSwqVp/HIcg/WOr9iRG4NtmuGisJhXCuzZYU6oDj/ib0N3UEK7FJ1zt58QbSd8c XSEZjRI/Po34bdQN2pqkwuQGOAA5sf6x2BXLYEtMImsOUMU95MHOZ+zVpJ7iNeKrw2Wkyg0o1QZN eRMZEiv3D3jPuTEsT/8BqmjXjdMZengCcs2pBdRpKSD5h+oUsaWiYuGmzfM2bvI/XTFkoMr/W3/9 6/cXLJi5eElOXp6aAHl5ec2a5Tdrkd+iZUHzFvnNmuc3b5ZfKJ+FkiFYdw/n5uHSfQkhriDjtm2D dfNgLV6xViEal0TDmmxYfleUzs6JY/dRlqDhCHbGha+A50sCMk1OBDBxJ2LmKnZHGkLfhfQPskV1 hmgy0qL1oKXC/tB/aSlWU4DsZS1FWWl5aVlFWamsqsBtbqak3BHswLffcNjhIStIGHHBeFQtoALD 1U/hv2qtCQ/WBjhdBPhqDDIkhRLx1SsjRDcPxhCe855TtJxeY08msbEU2JdO2Qn1yvMhUD4IXcdX QVdWqRArx9L0ctGgJEOFAC8maqb0VD6zsgVWHkmgEcXiAiNhjhq4qsgmn0Ai3dlShQs4LeQQDw4k IMeSktiCySZHyop7GLvyCkVFWTNbUW6KKTkMGgZk0PpNT9ALaZE+APmvzBsxdkFyfZTqREWVILlB ARwAQxASFikAXcdbqSnCyWb527lZYfyDyff//o9Z99x997knnQS0c+CqNnqGyewudTbybiwYxjpC 20EU8tukt8Mth6ZslMn0hA4BNYKj2jV/RzV74GQdVEMSCSfcaAxcQnvQb+MLZIvGI9zAw1LA/YB9 CBeF9UADAhd8i4Ti+uvh40Y2GBIHU/KTFIhiUjPxFzAjGwsPb1xUMy+c5ZGy6JSFe5U5/Io+mShQ XU36C+NQrFXpGXqgV2N4TFck/WAbG9UnSMT40ZfkDAjiuTEHE+VesQiwk6+LhGPCPM2Z5z5NyzNN NRmPUxFq0AiDFrU3Y0hm5pE3BVafb+WOXNAAST48U4zHD+nQ7q7f/rZDh05ZG7dsWTpr1jnHHks2 lNx+FQnafmN2Dq7kW4bxvAmxBxZH4DkuYIyNzCc8JMlVKW9JBc5qbUrxYq3PpBqXHbmXoiLShwGb 4sqJ6QQF1mNdysFx9i1V3QRzFUIrkSZYhO+A/cxq/aPBM5BQIWpIInN2wJXmL1PT9o5ALc07VIVA 9gn4GnxVic+mhxpTnfQoRcE1yZS5k43xUKdDGod04+W5pRM/iWNrLACiTnkBhF3YUAnrdtbBatjh irbWS+I9XXJfBVpXuqI+IsxPT1zvgXNE+7afvPhCSWVFi5atsitLSt+bNOmkI4449YTj12zcuHbz FlU+xRbIyxdbQC7EC6jZwfNyA/tftR0IK5C9kT+TB0unHPJ74QnMUnuWZm0SW7LvpmYpgAI+4GUw pUN6uUD41/Z7Rqgb0qENUzBKVOqMQQcqM2w6fg2UczxsnICB12o4qAXBKEyqkbynimLoceqWou9r kLZ86qkWk5UAKIBYDZmTybpaF93DXvQkcwIW5fTQ6iCqBaiOqFIIjvRleRKFKqTPkXBBxs4u5D7V +gHSYL/JCsLMgHyQqjdEjBRlbcYrjhkD9Kq3QwjJE8Yrwko8WqK/g9pNs0VhJrgCm9Ust5AOQ6Ya 4vKoxNQUCkTYs3LFFltfjAGic+AB9j9ZfCd9J5M03mjXsKLdmeL9rs0Lj+rSafZ//nPD9de3zs4u 3b5FIRzLzspr2bJ18xZXXvX9M886SxFdURN2DvDV8BlyjYjnEAbEEnA9XJFMw2gD4Llx8n0PKJoj 6NAgjI17TK6nYw2+acS9QOpCvcRhqqa7EQZJiJfg0QAyBE+67pkkMKAZplQDa7o2u2bV/Hv41zTt qCP0M3g87JIwkgAGeaAp8bKjhFCAGtWxKoxijiUm9TkYPj961sokpDWYudfNsPAizI0VqTOtIILb K9R4P8IBtqTitBkArqbR8q+nYtUJ95587LHf3fXb7RWVh/bv16NHD1mGDPrPyT7mqKOmfPRROeQR xRV9Xe6avhM10jz5u2GzrqUXIK55Xm4Z/GxsTJQ5YnLwMZUucxzePU8SrzxGGhMLjasxAGMEdSA9 PzDVR99VCgERfEkYylRjvXtAsHOlVuudkxjAGxtlkn/waIgFhMk+VZ+pcIbkTVKF9o6nWYguHKH6 qiOvQ78Q4ZIfeUmWCBathuW6mtCuoLP+d7tIaHRdBzOhj6k7nG7UBu/TVci+a9euLVq0aN68+f8P xKidGrK/Q2sAAAAASUVORK5CYII= ------=_NextPart_000_022E_01CF3E9E.5CC1BFB0-- From nobody Thu Mar 13 02:02:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081191A097E; Thu, 13 Mar 2014 02:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRGo627rHd_s; Thu, 13 Mar 2014 02:02:34 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5F1A098E; Thu, 13 Mar 2014 02:02:33 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403131002241330; Thu, 13 Mar 2014 10:02:24 +0100 From: "Karl Stahl" To: "'Magnus Westerlund'" , "'Colin Perkins'" , "'Pal Martinsen \(palmarti\)'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530C56CD.3010003@ericsson.com> In-Reply-To: <530C56CD.3010003@ericsson.com> Date: Thu, 13 Mar 2014 10:02:25 +0100 Message-ID: <025d01cf3e9a$f4267340$dc7359c0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025E_01CF3EA3.55EADB40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8yBSCWxibhG6xCSg6taQKdZO7sAgMCDfJw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7gWkE4XICUYSQ_9CV-HVGf6aVt4 Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments 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, 13 Mar 2014 09:02:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_025E_01CF3EA3.55EADB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the =93mission to bring quality to real-time traffic over our best = effort Internet=94 I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] =20 Hi Magnus, =20 With the response just sent to P=E5l http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, = skipping all the QoS methods and functions that really does not belong here when creating an =93Interface to QoS=94, I only see the suggestion of =93data = channel information=94, i.e. also marking each data channel packet with traffic bandwidth and type information to be relevant and interesting. I = checked with one of our developers and I think the same traffic information as = for RTP can be transferred in data channel packets as follows: =20 The RTP header has the following format (RFC 3550): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | RFC5285 header extension ... | | 2 bytes Max Bandwidth | 2 bytes Traffic Type | | .... | RTP Payload (often encrypted) =20 A Data Channel header could have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Channel Magic Cookie | (sequence number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | RFC5285 header extension ... | | 2 bytes Max Bandwidth | 2 bytes Traffic Type | | .... | DTLS Header 13 bytes SCTP =20 The RFC5285 header extension is not in a fixed position in any of these cases, but still trivial to find (especially when in a TURN flow). This could be introduced in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5=20 by making room for these bytes after the UDP header, but before the DTLS header. =20 What do you think? =20 Please apply the thought that we must allow ISPs/NSPs to route the = WebRTC media to where it can be handled, by using TURN servers. A TURN server = in a QoS-box can then use the traffic info (max bandwidth and traffic type) = found in the extension header, to do whatever QoS method or function that is appropriate for the specific network type (none discriminated).=20 =20 Regarding what to encode, I have several times suggested, e.g. already October 22 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X(2 bits), Variation Y(2 bits), that could be combined as required to describe the stream. And with the highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the = individual bits. =20 Please provide what more you see required (for any QoS method/function = for any network type)! =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] Here it is about recreation of the idea/intention of the RTP payload type (PT) header that is not available for the network level anymore, by instead having the application/browser filling the RTP header extension = with relevant traffic info that all IP network types can use. Here, similar traffic type marking is suggested for the data channel. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Skickat: den 25 februari 2014 09:40 Till: Karl Stahl Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: SV: [rtcweb] [tram] Payload Types assignments =20 Karl, (As individual) =20 I also wish for more usable QoS mechanisms. However, I don't see that = being achieved by your proposal. In addition I agree with Colin about the = issues with putting the information in the RTP header extension. I would also = note that this would be very RTP specific, and not at all help with the data channels multiple streams and their priorities. There might be data = channel information that is more crucial than any of the RTP media stream = packets. =20 You are pushing for a small piece in the middle. A piece that will not = help with the more general issue of QoS.=20 --- Not at all! I am pushing for "Interfacing to QoS" rather mixing the application layer directly to lower level QoS methods like setting DSCP = bits etc.. =20 How does the application and the multiple ISPs that carries the traffic reach an agreement on what properties that can be provided, that the application in this instance have the right to request those properties = and that any cost is correctly associated with the user or the user's agent = in regards to carrying the associated cost. =20 When it comes to setting DSCP from user land in the OS, that is = restricted due to the security implications. If those implications where resolved, = then OS could open up those interfaces. There are many interlinked reasons = why things look like they do today. I don't believe in tugging on a single random thread in ball of yarn and hope that it comes out without any = knots and ties on it. =20 Show me the framework for the QoS functions you have in mind that at = least has less issues than the currently deployed and take care of at least = some of the bigger issues. If that requires information in the RTP streams = for some reasons, then let us talk about how to best encoded it. But, we need that framework first, the architecture that makes this a = better solution than the current Diffserv architecture or any other QoS architecture. =20 Cheers =20 Magnus Westerlund =20 ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------=_NextPart_000_025E_01CF3EA3.55EADB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;I have started = = http://www.ietf.org/mail-archive/web/tram/current/ms= g00331.html=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] [2]=

 

Hi= Magnus,

 

Wi= th the response just sent to P=E5l http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, = skipping all the QoS methods and functions that really does not belong = here when creating an “Interface to QoS”, I only see the = suggestion of “data channel = information&#= 8221;, i.e. also marking each data channel packet with traffic bandwidth = and type information =A0to be relevant and interesting. I checked with = one of our developers and I think the same traffic information as for = RTP can be transferred in data channel packets as = follows:

 

The RTP header has the following format (RFC = 3550):

    = 0            =        = 1            =        = 2            =        3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=3D2|P|X|  CC   = |M|     PT      = |       sequence = number         = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |            =             &= nbsp;  = timestamp          &nbs= p;            = ;    |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |           = synchronization source (SSRC) = identifier          &nb= sp; |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = contributing source (CSRC) = identifiers          &n= bsp;  |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = RFC5285 header extension = ...           &nbs= p;          = |

   |     2 bytes = Max Bandwidth     |   2 bytes Traffic = Type        |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

RTP Payload (often = encrypted)

 

A Data Channel header could have the following = format:

    = 0            =        = 1            =        = 2            =        3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Data Channel Magic = Cookie   |      (sequence = number)        = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |            =             &= nbsp;  = timestamp          &nbs= p;            = ;    |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |           = synchronization source (SSRC) = identifier          &nb= sp; |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = contributing source (CSRC) = identifiers          &n= bsp;  |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = RFC5285 header extension = ...           &nbs= p;          = |

   |     2 bytes = Max Bandwidth     |   2 bytes Traffic = Type        |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

  DTLS Header 13 = bytes

  SCTP

 

Th= e RFC5285 header extension is not in a fixed position in any of these = cases, but still trivial to find (especially when in=A0 a TURN flow). = This could be introduced in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#secti= on-5

by= making room for these bytes after the UDP header, but before the DTLS = header.

 

Wh= at do you think?

 

Pl= ease apply the thought that we must allow ISPs/NSPs to route the WebRTC = media to where it can be handled, by using TURN servers. A TURN server = in a QoS-box can then use the traffic info (max bandwidth and traffic = type) found in the extension header, to do whatever QoS method or = function that is appropriate for the specific network type (none = discriminated).

 

Re= garding what to encode, I have several times suggested, = e.g.

al= ready October 22 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type e.g: Best Effort, Audio, = Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video = streaming), Minimum Delay, Reliable Delivery, Prioritize X(2 bits), = Variation Y(2 bits), that could be combined as required to describe the = stream.

And with the = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

 

Pl= ease provide what more you see required (for any QoS method/function for = any network type)!

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] Here it = is about recreation of the idea/intention of the RTP payload type (PT) = header that is not available for the network level anymore, by instead = having the application/browser filling the RT= P header extension with relevant traffic info that all IP network types = can use. Here, similar traffic type marking is suggested for the data = channel.

 

 

-----Ursprungligt meddelande-----
Fr=E5n: Magnus = Westerlund [mailto:magnus.westerlund@ericsson.com]
Skickat: den 25 = februari 2014 09:40
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = tram@ietf.org
=C4mne: Re: SV: [rtcweb] [tram] Payload Types = assignments

 

Karl,

(As = individual)

 

I also = wish for more usable QoS mechanisms. However, I don't see that being = achieved by your proposal. In addition I agree with Colin about the = issues with putting the information in the RTP header extension. I would = also note that this would be very RTP specific, and not at all help with = the data channels multiple streams and their priorities. There might be = data channel information that is more crucial than any of the RTP media = stream packets.

 

You = are pushing for a small piece in the middle. A piece that will not help = with the more general issue of QoS.

--- Not at all! I am pushing for = "Interfacing to QoS" rather mixing the application layer = directly to lower level QoS methods like setting DSCP bits = etc..

 

How does the application and the multiple ISPs that carries = the traffic reach an agreement on what properties that can be provided, = that the application in this instance have the right to request those = properties and that any cost is correctly associated with the user or = the user's agent in regards to carrying the associated = cost.

 

When it comes to setting DSCP from user land in the OS, = that is restricted due to the security implications. If those = implications where resolved, then OS could open up those interfaces.=A0 = There are many interlinked reasons why things look like they do today. I = don't believe in tugging on a single random thread in ball of yarn and = hope that it comes out without any knots and ties on = it.

 

Show me the framework for the QoS functions you = have in mind that at least has less issues than the currently deployed = and take care of at least some of the bigger issues. If that requires = information in the RTP streams for some reasons, then let us talk about = how to best encoded it.

But, we = need that framework first, the architecture that makes this a better = solution than the current Diffserv architecture or any other QoS = architecture.

 

Cheers

 

Magnus = Westerlund

 

----------------------------------------------------= ------------------

Services, Media = and Network features, Ericsson Research EAB/TXM

----------------------------------------------------= ------------------

Ericsson = AB=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Phone=A0 +46 10 = 7148287

F=E4r=F6gatan = 6=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Mobile +46 73 = 0949079

SE-164 80 Stockholm, = Sweden | mailto: magnus.westerlund@ericsso= n.com

----------------------------------------------------= ------------------

------=_NextPart_000_025E_01CF3EA3.55EADB40-- From nobody Thu Mar 13 02:24:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0861A0991; Thu, 13 Mar 2014 02:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YADHXjM7GUsC; Thu, 13 Mar 2014 02:24:21 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEBF1A0928; Thu, 13 Mar 2014 02:24:20 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403131024119732; Thu, 13 Mar 2014 10:24:11 +0100 From: "Karl Stahl" To: "'Colin Perkins'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Mar 2014 10:24:11 +0100 Message-ID: <026201cf3e9d$ff05ee00$fd11ca00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0263_01CF3EA6.60CA5600" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8yhC9wiXnjCRHsTROqPtmeJmmGVQLhu7dw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/E0Ls2PFkOp9cU3h3sFWC9DQ9m10 Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments 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, 13 Mar 2014 09:24:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0263_01CF3EA6.60CA5600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the =93mission to bring quality to real-time traffic over our best = effort Internet=94 I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] =20 Hi Colin, =20 Please see the just sent email to P=E5l and Magnus where I address your concerns.=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg11847.html =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] Here it is about recreation of the idea/intention of the RTP payload type (PT) header that is not available for the network level anymore, by instead having the application/browser filling the RTP header extension = with relevant traffic info that all IP network types can use. Similar traffic type marking is suggested for the data channel. =20 Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 Skickat: den 26 februari 2014 00:49 Till: Karl Stahl Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand =C4mne: Re: [rtcweb] [tram] Payload Types assignments =20 Karl, =20 I sympathise with your goal, but I really do not think RTP header = extensions are appropriate for this purpose. =20 Ignoring the semantic mismatch, in order to identify an RTP header extension, you need access to the signalling data, and if you have = access to the signalling, you can signal the QoS parameters without using RTP.=20 =20 You state that only the payload is encrypted in SRTP. That is not necessarily true. RTP header extensions can be encrypted when RFC 6904 = is in use, and rtcweb-rtp-usage draft recommends this be done in some cases.=20 =20 The signalling channel is also likely encrypted end-to-end in new applications, so making it difficult to extract the information you need = to parse the RTP header extension, even if it is unencrypted.=20 =20 Besides these focussed issues, I would also urge you to consider the = much broader comments Magnus made. The QoS problem is broad, and a point = solution based on RTP header extensions - even if it were workable, which I doubt = - would address only a small part of the problem space. =20 =20 =20 Colin =20 =20 =20 =20 On 25 Feb 2014, at 01:45, Karl Stahl wrote: Colin, =20 If the below were the case, it would be =93DPI guesswork=94 that I also = advice against. RTP doesn=92t even have unique protocol header within UDP =96 = it can even be confused with other UDP payload.=20 =20 However, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS methods relevant to the network (which is not diffserve in Mobile OTT and Cable Networks) has not a too difficult tasks. Linking each RTP-flow by its ID = and sequence number, and picking exactly the right traffic type and = bandwidth parameters is doable (see inline below, we at Ingate do it already)! =20 Also DiffServ DSCP-bits are seldom maintained crossing network = boundaries, thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there is no bandwidth requirement information when entering networks requiring reservation. That is always (and dynamically set) available in the RTP extension header for each packet. =20 And, I am sure you are aware of the difficulties of getting DSCP-bits through OS sockets, which is even worse with multiple streams over the = same UDP-port =20 Further, defining the QoS RTP extension header as in RFC5285, does not = in anyway conflict with other RTP extension headers or DSCP transfer or settings. =20 /Karl =20 Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 Skickat: den 24 februari 2014 23:52 Till: Karl Stahl Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand =C4mne: Re: [rtcweb] [tram] Payload Types assignments =20 Karl, =20 I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not have a well-defined magic number in the header,=20 This is how to find the traffic info: The payload of the classifier header extension element can be encoded using either the one-byte or two-byte header defined in [rfc5285 ] and shown below in Figure 1 and 2 below. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D1 | Namespace | Value | 0 (pad) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 1: Classifier Using the One-Byte Header =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D2 | Namespace | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 Figure 2: Classifier Using the Two-Byte Header =20 indicated using a dynamically assigned identifier that is conveyed in an out-of-band=20 --- It is the TURN flow!!! Requested by the ICE protocol for the = specific media to come! and encrypted signalling channel,=20 --- Only the payload is encrypted in SRTP =96 leaving id, seq no and = header ext to be used as intended! --- Thus being the appropriate place=85 is not an appropriate place to put QoS information that has to be = processed on a per-packet basis.=20 If you want DiffServ, you know where to find it. --- True, but if it cannot be used=85 Colin =20 =20 On 24 Feb 2014, at 22:09, Karl Stahl wrote: I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: =20 (1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any suitable QoS = methods for the particular network* for=20 (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE=20 (3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT). =20 The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have an RFC in place. =20 With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established. =20 =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl Skickat: den 22 oktober 2013 16:37 Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' Kopia: 'Colin Perkins' =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But rather than = asking the application, let's convey the bandwidth and priority requirements to = the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be available = for incoming traffic, which is especially important in RSVP type of = networks, that has to reserve bandwidth for it. =20 =20 There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren=92t sufficient anyway).=20 =20 Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to = encode it though. =20 Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there can be = many header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions". =20 So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. =20 Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. =20 I suggest that two parameters (e.g. two bytes each) are encoded into the = RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Please note the totally different requirements a diffserv and an RSVP network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation networks = (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) =20 /Karl =20 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. =20 This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =20 MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the attribute is = not present in the Allocate request message, the TURN server SHOULD assume = that the data stream is audio with best effort delivery. The format of this attribute is as follows...=20 ... The following stream types are supported in this extension. All other = stream types are reserved for future use. =A7 "0x0001": Audio =A7 "0x0002": Video =A7 "0x0003": Supplemental Video =A7 "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. =A7 "0x0000": Best effort delivery. =A7 "0x0001": Reliable delivery. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, >=20 >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. >=20 > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of = > less importance as long as there is sufficient bandwidth for both). =20 You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. =20 >=20 > With diffserv you don=92t need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. =20 Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. =20 >=20 > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the bandwidth used... >=20 > I think the payload type field at best can reflect a maximum bandwidth = > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a = joke? =20 I think these ruminations only lead to one conclusion: =20 You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. =20 If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 --=20 Colin Perkins http://csperkins.org/ =20 =20 =20 =20 =20 --=20 Colin Perkins http://csperkins.org/ =20 =20 =20 ------=_NextPart_000_0263_01CF3EA6.60CA5600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;I have started = = http://www.ietf.org/mail-archive/web/tram/current/msg00331.h= tml=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] [2]=

 

Hi= Colin,

 

Pl= ease see the just sent email to P=E5l and Magnus where I address your = concerns.

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11847.html

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] Here it = is about recreation of the idea/intention of the RTP payload type (PT) = header that is not available for the network level anymore, by instead = having the application/browser filling the RT= P header extension with relevant traffic info that all IP network types = can use. Si= milar traffic type marking is suggested for the data = channel.

 

Fr=E5n: Colin = Perkins [mailto:csp@csperkins.org]
Skickat: den 26 februari = 2014 00:49
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = Magnus Westerlund; tram@ietf.org; Harald Alvestrand
=C4mne: = Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I = sympathise with your goal, but I really do not think RTP header = extensions are appropriate for this purpose.

 

Ignoring the semantic mismatch, in = order to identify an RTP header extension, you need access to the = signalling data, and if you have access to the signalling, you can = signal the QoS parameters without using RTP. 

 

You state that only the payload is encrypted in SRTP. = That is not necessarily true. RTP header extensions can be encrypted = when RFC 6904 is in use, and rtcweb-rtp-usage draft recommends this be = done in some cases.

 

The = signalling channel is also likely encrypted end-to-end in new = applications, so making it difficult to extract the information you need = to parse the RTP header extension, even if it is = unencrypted. 

 

Besides these focussed issues, I would also urge you = to consider the much broader comments Magnus made. The QoS problem is = broad, and a point solution based on RTP header extensions - even if it = were workable, which I doubt - would address only a small part of the = problem space.

 

 

 

Colin

 

 

 

 

On = 25 Feb 2014, at 01:45, Karl Stahl <karl.stahl@intertex.se> = wrote:

Co= lin,

&n= bsp;

If= the below were the case, it would be “DPI guesswork” that I = also advice against. RTP doesn’t even have unique protocol header = within UDP – it can even be confused with other UDP payload. =

&n= bsp;

Ho= wever, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS = methods relevant to the network (which is not diffserve in Mobile OTT = and Cable Networks) has not a too difficult tasks. Linking each RTP-flow = by its ID and sequence number, and picking exactly the right traffic = type and bandwidth parameters is doable (see inline below, we at Ingate = do it already)!

&n= bsp;

Al= so DiffServ DSCP-bits are seldom maintained crossing network boundaries, = thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there = is no bandwidth requirement information when entering networks requiring = reservation. That is always (and dynamically set) available in the RTP = extension header for each packet.

&n= bsp;

An= d, I am sure you are aware of the difficulties of getting DSCP-bits = through OS sockets, which is even worse with multiple streams over the = same UDP-port

&n= bsp;

Fu= rther, defining the QoS RTP extension header as in RFC5285, does not in = anyway conflict with other RTP extension headers or DSCP transfer or = settings.

&n= bsp;

/K= arl

&n= bsp;

Fr=E5n: Colin = Perkins [mailto:csp@csperkins.org] =
Skickat: den 24 februari 2014 23:52
Till: Karl = Stahl
Kopia: rtcweb@ietf.org; Magnus Westerlund; = tram@ietf.org; Harald = Alvestrand
=C4mne: Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I = strongly disagree with this suggestion. An RTP header extension, located = at an unknown and variable offset into a packet that does not have a = well-defined magic number in the header,

Th= is is how to find the traffic info:

   The payload of the classifier header = extension element can be encoded

   using either the one-byte or two-byte header = defined in [rfc5285] and

   shown below in Figure 1 and 2 = below.

 

      = 0            =        = 1            =        = 2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     |  ID   | len=3D1 = |   Namespace   |    = Value      |    0 = (pad)    |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

          = ;   Figure 1: Classifier Using the One-Byte = Header

 

      0     =             &= nbsp; 1          &= nbsp;        = 2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     |      = ID       |    = len=3D2      |   = Namespace   |    = Value      |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

 

          = ;   Figure 2: Classifier Using the Two-Byte = Header

&n= bsp;

indicated using a dynamically assigned identifier that is = conveyed in an out-of-band

--= - It is the TURN flow!!! Requested by the ICE protocol for the specific = media to come!

and encrypted signalling channel,

--= - Only the payload is encrypted in SRTP – leaving id, seq no and = header ext to be used as intended!

--= - Thus being the appropriate place…

is not an appropriate place to put = QoS information that has to be processed on a per-packet basis. =

If you = want DiffServ, you know where to find = it.

--- True, but if it cannot be = used…

Colin

 

 

On = 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I = suggest to the RTCWEB WG that the below from the September and October = discussions on the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage = fo= r usage of RFC 5285, to allow:

&n= bsp;

(1= ) WebRTC applications to directly convey QoS related real-time traffic = info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for =

(2= ) *all* WebRTC browsers *and* clients, under *all* = OSs, and *all* current and future IP network, to achieve best QoE =

(3= ) *without* ha= ving to force WebRTC into application specific networks (such as IMS) = instead of using the Internet (including OTT).

&n= bsp;

Th= e only further activity required, is to call for ISPs’ to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= /span>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 =

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

&n= bsp;

Th= en this could be assigned numbers to have an RFC in = place.

&n= bsp;

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just this, = without even having it MUST-established.

&n= bsp;

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

&n= bsp;

Pl= ease see further emails soon following this one, for details and = history.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good way to = show these needs to the network (without using the PT, or diffserv bits, = which aren’t sufficient anyway).

 

Let's use the RTP header = extension field that also is visible outside the encrypted payload. A = week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC = Use of RTP: Future Extensions".

 

So, it looks obvious to use the = RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in every = RTP packet so it can be set individually for each stream and could even = be changed during a session (e.g. when limiting the bandwidth based on = RTCP feedback). RFC 5286 also specifies how RTP extension header usage = can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly = specified now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence… on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to 0, = there could instead be a number for special usage that does not fit the = general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let’s put all into these bytes. (E.g. a diffserv network don't = need the bandwidth usage, but RSVP reservation networks (e.g. cable and = 3G/4G OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have = done work in this field, defining a proprietary attribute “MS = Service Quality”;

However that seems to apply = to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not handle the = bandwidth requirement for incoming real-time traffic (required to = reserve in RSVP type of networks)

However the quality = attributes conveyed and their encoding may  be = considered.

 

=

This is 2.2.2.19 MS-Service = Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).asp= x 

 

MS-Service Quality = Attribute

The MS-Service = Quality attribute is used to convey information about the data stream = that the protocol client is intending to transfer over an allocated = port. The protocol client SHOULD<21> include this attribute as = part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The following stream types = are supported in this extension. All other stream types are reserved for = future use.

=A7 "0x0001": = Audio

=A7 "0x0002": = Video

=A7 "0x0003": = Supplemental Video

=A7 = "0x0004": = Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The following service = quality levels are supported in this extension. All other service = quality levels are reserved for future use.

=A7 = "0x0000": Best = effort delivery.

=A7 = "0x0001": = Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really = interested in knowing that it is VP9 vs H.264,

>> = isn't

> the questions this is video of this priority that is = important?

>> I think you need to more carefully consider what = are the goals you

>> try to

> achieve = them.

> 

> Actually, my concern is to = get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized = over data (their individual priority is of

> less importance as long as = there is sufficient bandwidth for both).

 

You don't know that without = knowing what the application is for.

In, for instance, a shooter game = with voice backchannels, the movement and event information (data) is = MORE time sensitive than the voice data.

 

> 

> With diffserv you = don’t need to know the bandwidth requirement, but =

> = with RSVP reservation (like in cable and mobile networks) you need to =

> = know how much to reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide to = use QCIF or HD, and the bandwidth variation of screencast (semi-static = with sudden, large changes) is completely different from that of a = talking head, which is again completely different from a high-movement = scene.

 

> 

> To add to the complication = of codec variants, the video codecs in

> question for WebRTC have = variable bandwidth, and when there is a poor

> connection we see Chrome = reducing the video window size to reduce the bandwidth = used...

> 

> I think the payload type = field at best can reflect a maximum bandwidth

> to initially reserve = bandwidth for, and thereafter make new

> reservations if the = bandwidth changes during the call. So could we

> change RTP to show maximum = bandwidth instead of payload type in that

> field outside the encrypted = payload :) ... Or maybe that is not a joke?

 

I think these ruminations only = lead to one conclusion:

 

You can't tell what the needed = bandwidth is up front without asking the = application.

You can't tell what the right priority ranking is without = asking the application.

 

If you need to know the = bandwidth or the priority up front, the application has to tell you. = Anything else is pure heuristics.

 

_______________________________________________<= /o:p>

rtcweb mailing = list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb=

 

 

-- 

Colin Perkins

 

 

 

 

 

-- 

Colin = Perkins

 

 

 

------=_NextPart_000_0263_01CF3EA6.60CA5600-- From nobody Thu Mar 13 05:41:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDFF1A0981 for ; Thu, 13 Mar 2014 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 SixH6_u7QPzl for ; Thu, 13 Mar 2014 05:41:07 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6C1A0978 for ; Thu, 13 Mar 2014 05:41:06 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-41-5321a75b4cf4 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.7A.23809.B57A1235; Thu, 13 Mar 2014 13:41:00 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Mar 2014 13:40:59 +0100 Message-ID: <5321A75B.8080100@ericsson.com> Date: Thu, 13 Mar 2014 13:40:59 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <532014C8.2050908@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+JvjW7McsVgg0uXOC22ThWyWPuvnd2i e+l/FgdmjwWbSj2WLPnJ5LHug3kAcxSXTUpqTmZZapG+XQJXxuv1TUwFM8Ur/qzkb2BcJ9TF yMkhIWAi0fTiLjOELSZx4d56ti5GLg4hgUOMEjOvHmSFcJYzSnRv2AlWxSugLXF/w1cwm0VA VWLj7R3sIDabgIXEzR+NbCC2qECwxM4Dvxkh6gUlTs58wgJiiwioSTyctYsVxGYWiJBY3v8M rF5YwFhi6d/9zBDL+pgllk2ZC9bMKRAocWLDayCbA+g8cYmexiCIXk2J1u2/2SFseYnmrbPB 7hECuq2hqYN1AqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0cqNNjMDAPbjlt+oOxjvnRA4xSnOw KInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUUBXqd/Xqfj9ceG6kO1ch0/wPc2M E7e6zXPc9e+vVVmRfK2+6yPUA/XnHptqeL9kR1b/l/XWRQKnHzrEX3ty3qBwU+lModQZwYvm 3Kq50OjuFVG/J2Gja2eF14lwfgtdhRpPRVYudbNHM+MSboi0G8n/mPCJ9yp3su7xjp/zL126 0jOXZyqrEktxRqKhFnNRcSIATPt7IioCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Flh_gcjHzeYNujpI3RqXN0LxKnU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 13 Mar 2014 12:41:10 -0000 On 2014-03-12 17:05, Justin Uberti wrote: > > On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund > > > wrote: > > > Sorry, I don't understand your reasoning here. Is it to provide the > lowest possible drop probability, i.e. using the AFx class that has > least drop probability? > > > The idea is to have the same drop probability as the most critical media > that is flowing (e.g. voice), so that we don't end up in a situation > where media flows fine, but the media crowds out STUN consent check > packets, leading to call failure. Okay, that makes a certain sense. First of all this is not likely to have the "highest" DSCP value. In fact it might not have the lowest drop probability either. But, yes it might be prioritized over BE. This is assuming that this DSCP marking do work and doesn't prevent the 6-tuple to work. But lets take this as a separate issue. > > > If there exist nodes that stomp on some DSCP markings, and not only > remark them to Best Effort (BE), and instead drop then. Then, it is not > obvious that that an AFx class is the most appropriate to use. In that > case using BE might be more suitable for the consent freshness. > > > If nodes stomp on certain AF-marked packets, and this is widespread, > this essentially dooms use of DSCP at all, unless we want to build some > sophisticated detection and fallback mechanism. IOW, it's not clear to > me that marking packets as BE confers any value over not marking at all. BE is no marking at all, i.e. DSCP = 0. But, I wanted to be clear that I really meant best effort. But, the question is what we do about nodes that not simple down mark DSCP code points !=0. I see some potential solutions. 1) We recommend that one track the loss rates the different DSCP markings individually and in cases when loss rates for some markings doesn't match the expected relative behavior between different markings, then one stops using DSCP markings and send everything as BE. 2) One expands the initial STUN exchange to a second round after nomination to verify the DSCP code points that one intended to use is not being blocked. The alternative to do something is to ignore the issue. It might be small enough that it isn't significant. I don't have data on this. If someone has any data source it would be appreciated if they share. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 13 05:52:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C6E1A0848 for ; Thu, 13 Mar 2014 05:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 6Ct1EntpKVX2 for ; Thu, 13 Mar 2014 05:52:48 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id DD27E1A0833 for ; Thu, 13 Mar 2014 05:52:47 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-75-5321aa18daef Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 46.37.04853.81AA1235; Thu, 13 Mar 2014 13:52:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 13:52:39 +0100 From: Christer Holmberg To: Justin Uberti , Magnus Westerlund Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAAIVkAIABaJQg Date: Thu, 13 Mar 2014 12:52:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvja7EKsVgg565ShYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8a+m8tYCz5xVhy+OZu5gfEC ZxcjJ4eEgInE3G+/GCFsMYkL99azdTFycQgJnGCU+PZzPQuEs4RR4seuV0xdjBwcbAIWEt3/ tEFMEYEYiXdHi0F6mQVcJZoeLmUBsYUFjCWmdE5mA7FFQOZPfM0CYedJrN30HSzOIqAqsejt E1aQMbwCvhKXf8VBbFrNIvFs6z5WkBpOgUCJu71tzCA2I9Bt30+tYYLYJS5x68l8JoibBSSW 7DnPDGGLSrx8/I8VwlaU+PhqHyPIfGYBTYn1u/QhWhUlpnQ/ZAexeQUEJU7OfMIygVFsFpKp sxA6ZiHpmIWkYwEjyypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMCIOrjlt9EOxpN7 7A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWHll/0bBOxXrN9/cKTvx qUrupubfwrsXqUTtvqW4oUD/wMQWY92zfPOues9Pm+b4wc9Ia22wVkdv/o5Ejy9d4p1rHR5x yPIG3g8NUDsv6d9TN3lD3pa9JxMcTFrXf0sWMvIvixOb0yGyf71Fl1egtYqrAc82w/2XBAJX RmludulWW/pNNDRHiaU4I9FQi7moOBEA44STEnYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mKvRbIp-btOeInBwLaOqz5gBVOo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 13 Mar 2014 12:52:49 -0000 SGkgSnVzdGluLA0KDQo+IEkgdGhpbmsgcnRjcC1tdXggaGFzIHRvIGJlIGEgTVVTVCB1c2Ugd2hl biBCVU5ETEUgaXMgdXNlZCBiZXR3ZWVuIHRoZSB0d28gZW5kcG9pbnRzLiAoSWYgdGhlIGVuZHBv aW50IGRvZXNuJ3Qgc3VwcG9ydCANCj4gQlVORExFLCBydGNwLW11eCBpcyBub3QgcmVxdWlyZWQu KQ0KPg0KPiBPdGhlcndpc2UsIHlvdSBnZXQgaW50byB3ZWlyZCBlZGdlIGNhc2VzLCBzdWNoIGFz IHdoZXJlIHlvdSBoYXZlIGEgZGF0YSBjaGFubmVsIChubyBSVENQIGNvbXBvbmVudCksIGFuZCB0 aGVuIHdhbnQgDQo+IHRvIGFkZCBhdWRpbyAod2l0aCBSVFAgYW5kIFJUQ1AgY29tcG9uZW50cyku IFlvdSBjb3VsZCBidW5kbGUgdGhlIGF1ZGlvIFJUUCBvdmVyIHRoZSBleGlzdGluZyBkYXRhIGNo YW5uZWwgdHJhbnNwb3J0LCANCj4gYnV0IGl0J3Mgbm90IGNsZWFyIHdoYXQgeW91IHNob3VsZCBk byB3aXRoIHRoZSBSVENQIGNvbXBvbmVudC4gTWFuZGF0aW5nIHJ0Y3AtbXV4IGF2b2lkcyB0aGlz IGlzc3VlIGNvbXBsZXRlbHkuDQoNCkFjY29yZGluZyB0byBzZWN0aW9uIDQgaW4gUkZDIDU3NjEs IGlmIHlvdSBtdWx0aXBsZXggUlRQIGFuZCBSVENQIG9uIHRoZSBzYW1lIHBvcnQsIHlvdSBuZWVk IHRvIGFzc2lnbiBkZWRpY2F0ZWQgUFQgdmFsdWVzIHRvIHRoZSBSVENQIHBhY2tldHMsIHdoaWNo IG1lYW5zIHRoYXQgYXQgbGVhc3QgUFQgdmFsdWVzIDY0LTk1IGNhbm5vdCBiZSB1c2VkIGZvciBS VFAuDQoNCkFzIHlvdSBoYXZlIGJlZW4gb25lIG9mIHRob3NlIHRhbGtpbmcgYWJvdXQgdGhlIHJp c2sgb2YgcnVubmluZyBvdXQgb2YgUFQgdmFsdWVzLCBJIGp1c3Qgd2FudCB0byBtYWtlIHN1cmUg eW91IGhhdmUgdGFrZW4gdGhpcyBpbnRvIGNvbnNpZGVyYXRpb24gOikNCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg== From nobody Thu Mar 13 07:00:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBB21A096A; Thu, 13 Mar 2014 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGi_Kt-71k_u; Thu, 13 Mar 2014 07:00:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BB6CE1A095E; Thu, 13 Mar 2014 07:00:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A7FE3C94BD; Thu, 13 Mar 2014 10:00:09 -0400 (EDT) Date: Thu, 13 Mar 2014 10:00:09 -0400 From: John Leslie To: Karl Stahl Message-ID: <20140313140009.GS18217@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SmwJvvkjCHveL2XKeQRpe2hmNNk Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] [tram] Payload Types assignments 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, 13 Mar 2014 14:00:19 -0000 Karl Stahl wrote: > > [879 lines] > [2135 lines] > [816 lines] > [1598 lines] I do appreciate your commitment to our tasks, Karl, but there is no hope that very many of us can slog through all that text. If you want wide readership, may I suggest you limit the number of lines you impose on the rest of us per day? -- John Leslie From nobody Thu Mar 13 08:17:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DE61A0A0B for ; Thu, 13 Mar 2014 08:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6IAnSN6Tqrd for ; Thu, 13 Mar 2014 08:16:50 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 235731A09A8 for ; Thu, 13 Mar 2014 08:16:49 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so995612wgh.35 for ; Thu, 13 Mar 2014 08:16:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MJ1KU3DThxVvYO3sRhp0RMJbor4Al7tU395OtZ4PD1A=; b=lFo8LPz9BbHaWBBtUjwG1E1XufRBhpVSLfk3g32RAwE20wu7OXKFbvT8c7i1Kvmy71 68KBAdxZCVkxL48d7x9CSD0eiWO4XGHvHnr06zXpcM8Uwco1M6yLAZLsWZtsx6J0hrJw CDwB5plKrLEEQvrhw9v99RbsjbUxUcgPTKWwqHs8t2uj5WMkwU9mHh+L2YcMg1a9qG3a SvQ85TL1oFShoxXFnwSVvSDEvjR8TQfw8GvWMpVI4a+kLutGs3Jz5MQMfVF7H964KHZX p0rZbiVHbNMoGhnzBJYFnRilZdSgYmOGni91tepr+WduGqPwk2GWJSjVyzGqJd8xqkon 0AnQ== X-Gm-Message-State: ALoCoQlwpj0Kg8Hobtfye8QIMRIbiimA6ELvgoFDDRVQ7fNpWXEUqHaz8wISKVS1StnJ5OjrZkDq X-Received: by 10.180.164.174 with SMTP id yr14mr2126315wib.18.1394723801690; Thu, 13 Mar 2014 08:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 13 Mar 2014 08:16:01 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Thu, 13 Mar 2014 08:16:01 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=00248c0d7914c28bcb04f47e70f0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5o9RO02_JzhyOawOutI0qvFsA40 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Areas of security concern 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, 13 Mar 2014 15:16:55 -0000 --00248c0d7914c28bcb04f47e70f0 Content-Type: text/plain; charset=ISO-8859-1 Watson, Thanks for your comments. Responses below. On Tue, Mar 11, 2014 at 10:11 PM, Watson Ladd wrote: > > Problem 1: Which John Smith? > > Currently IdPs link attributes to identities. > The identities are phrased as RFC822-style names subordinated beneath the domain name of the IdP (or if the IdP is a universal trust point, then not subordinated). See: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09#section-5.6.5.3.3.1 There used to be a human-readable display-name property as well but that's gone as of this version, precisely because of concerns of this type. Perhaps you are reading a pre-09 version? > Problem 2: IdP pointy bits > > An IdP has to cryptographically bind a username to some data. It would be > nice if we could come up with a secure method to do this, and have the > browser take care of it for the identity provider as much as possible, > instead of everyone having to do it themselves in likely wrong ways. The > webcrypto API has been roundly critiqued as being too low-level. > We certainly considered this, but that would basically amount to choosing a specific identity system or standardizing our own, neither of which seems totally awesome. Incidentally, cryptography isn't actually required here (though it's probably the method of choice). The IdP could also just store all the identity assertions it generates in a database and retrieve it on demand. Problem 3: Renegotiation > > The DTLS handshake being used is specified in RFC 4347. In particular, I > don't see anything about the renegotiation bug being fixed. This enables an > unknown key-share attack in which A thinks they are transmitting video to > B, but really are transmitting it to C who knows that they are talking to A. > I'm certainly aware of this paper --- though as you know it just came out recently --- but it's not clear to me how applicable it is, since the client-authentication version of the attack (which I believe is the appropriate one here) depends on the TLS server changing its identity during the session, and RFC5763 requires that the certificates presented during the DTLS handshake match the fingerprints in the SDP: o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. The security properties of this mechanism are described in Section 8. RFC 5763 doesn't explicitly talk about renegotiation, so we probably could add something about handling renegotiation. If you think of some way in which the mechanisms above aren't sufficient please drop me a private e-mail so we can discuss. Problem 4: HMAC-SHA1 in SRTP > > If I've chased the chain of references correctly this is the sole MAC > provided. Is it okay? I have no idea: SHA-1 has been significantly weakened > in recent years. > As far as I know, HMAC-SHA1 is sufficiently secure for this purpose. Three notes about this: 1. We are discussing audio and video packets so there are a lot of them but modifying any particular one doesn't generally get you much. 2. The MACs are truncated to 80 or 32 bits. 3. There are GCM ciphersuites in the pipeline but they haven't landed yet. This is really an issue for the IETF AVTCORE WG, however, since it applies to all of SRTP, not just rtcweb. > Problem 5: What you see is not what I sent > > This is an area that is somewhat underspecified, depending as it does on > the media API's capabilities. The video frame could be silently replaced by > a different video frame with rather different contents. Any authentication > of the contents of the video frame would not carry over, but if the > contents were sufficiently shocking/subtle this might not be noticed. > Authentication independent of the website offering the video chat makes > this attack worse, because users will trust what they see more. Isolation > doesn't help because this is wholesale replacement, not editing. > > Most uses of this attack are for puerile purposes. I don't think it's a > big concern. Then again I could be very, very wrong. > We certainly know about this form of attack. For instance, you can just pretend to operate a calling service but instead of showing the remote video you can just embed a YouTube video. There are effectively two cases here: - The call is not using isolated streams in which case you didn't have any protection for the media from the site anyway. - The call is using isolated streams in which case the site will have no access to the true media and so can only blindly inject their own. Obviously this isn't ideal but it's pretty hard to get rid of since the Web already includes video and even without WebRTC, it's trivial for a site to play any video it wants to you. We've talked about having some sort of UI for showing each video element and its provenance, but it's a hard UX problem. > Problem 6: General UI issues > > Currently quite a bit of the security model depends on UI presentations of > subtly different states. I don't know how well users will understand this, > or how well the UI will work. Past experience suggests not well. Luckily we > can mostly change this later/it isn't part of standardisation. > Yes, we are aware of this. Not sure there's much to do about it. > Problem 7: VBR privacy leaks > > I can do no better then to refer to the paper. > http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-can.pdfSpoken phrases could be identified from encrypted data alone, using a > Hidden Markov Model when the length of packets was preserved by the > encryption. > Yeah, this is also a known issue. See RFC 6562 for some recommendations on how to address this. If you want to work on this issue, you should probably take it to the AVTCORE WG. -Ekr --00248c0d7914c28bcb04f47e70f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Wats= on,

Th= anks for your comments. Responses below.

On Tue, Mar 11, 2014 at 10:11 PM, Wats= on Ladd <watsonbladd@gmail.com> wrote:

Problem 1: Which John Smith?

Currently IdPs lin= k attributes to identities.

The iden= tities are phrased as RFC822-style names subordinated beneath
the domain name of the IdP (or if the IdP is a universal trust point, then<= /div>
not subordinated). See:


There used to be a human-readable display-name pr= operty as well but that's
gone as of this version, precisely = because of concerns of this type. Perhaps
you are reading a pre-0= 9 version?

=A0
Problem = 2: IdP pointy bits

An IdP has to cryp= tographically bind a username to some data. It would be nice if we could co= me up with a secure method to do this, and have the browser take care of it= for the identity provider as much as possible, instead of everyone having = to do it themselves in likely wrong ways. The webcrypto API has been roundl= y critiqued as being too low-level.

We certainly considered this, but th= at would basically amount to choosing
a specific identity system = or standardizing our own, neither of which seems
totally awesome.= Incidentally, cryptography isn't actually required here
(though it's probably the method of choice). The IdP could also ju= st
store all the identity assertions it generates in a database a= nd retrieve
it on demand.





Problem 3: Renegotiation

The DTLS handshake b= eing used is specified in RFC 4347. In particular, I don't see anything= about the renegotiation bug being fixed. This enables an unknown key-share= attack in which A thinks they are transmitting video to B, but really are = transmitting it to C who knows that they are talking to A.

I'm certainly aware of this pape= r --- though as you know it just came
out recently --- but it'= ;s not clear to me how applicable it is,
since the client-authent= ication version of the attack (which I believe
is the appropriate one here) depends on the TLS server changing
<= div>its identity during the session, and RFC5763 requires that the
certificates presented during the DTLS handshake match the
fingerprints in the SDP:

=A0 =A0o =A0The cert= ificate presented during the DTLS handshake MUST match the
=A0 = =A0 =A0 fingerprint exchanged via the signaling path in the SDP. =A0The
=A0 =A0 =A0 security properties of this mechanism are described in S= ection 8.

RFC 5763 doesn't explicitly talk about renego= tiation, so we probably
could add something about handling re= negotiation.

If you think of some way in which the= mechanisms above aren't sufficient
please drop me a private e-mail so we can discuss.


Problem 4: HMAC-SHA1 in SRTP

If I've chased the chain of references correctly this is the sole MAC = provided. Is it okay? I have no idea: SHA-1 has been significantly weakened= in recent years.

As far as I know, HMAC-SHA1 is suffi= ciently secure for this purpose. Three
notes about this:

1. We are discussing audio and video packets so there are = a lot of them
but modifying any particular one doesn't generally get you much.

2. The MACs are truncated to 80 or 32 bits.

3. There are GCM ciphersuites in the pipeline but they ha= ven't landed yet.

This is really an issue for the IETF AVTCORE WG, howeve= r, since it applies
to all of SRTP, not just rtcweb.



=A0
Problem 5: What you see is not what I sent
=
This is an area that is somewhat underspecified, depending a= s it does on the media API's capabilities. The video frame could be sil= ently replaced by a different video frame with rather different contents. A= ny authentication of the contents of the video frame would not carry over, = but if the contents were sufficiently shocking/subtle this might not be not= iced. Authentication independent of the website offering the video chat mak= es this attack worse, because users will trust what they see more. Isolatio= n doesn't help because this is wholesale replacement, not editing.

Most uses of this attack are for puerile purposes. I do= n't think it's a big concern. Then again I could be very, very wron= g.

We certainly know about this= form of attack. For instance, you can just
pretend to operate a calling service but instead of showing the remote=
video you can just embed a YouTube video. There are effectively = two
cases here:

- The call is not using = isolated streams in which case you didn't have
=A0 any protection for the media from the site anyway.

<= /div>
- The call is using isolated streams in which case the site will = have
=A0 no access to the true media and so can only blindly inje= ct their
=A0 own.

Obviously this isn't ideal but i= t's pretty hard to get rid of since the Web
already includes = video and even without WebRTC, it's trivial for a site
to pla= y any video it wants to you. We've talked about having some sort
of UI for showing each video element and its provenance, but it's = a hard
UX problem.


=A0
Problem 6: General UI issues

Currently quite a bit of the security model depends on UI presen= tations of subtly different states. I don't know how well users will un= derstand this, or how well the UI will work. Past experience suggests not w= ell. Luckily we can mostly change this later/it isn't part of standardi= sation.

Yes, we are aware of this. Not sure = there's much to do about it.

=A0
Problem 7: VBR privacy leaks

I can do no better then to refer to the paper.=A0http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/repo= rts/yes-we-can.pdf Spoken phrases could be identified from encrypted da= ta alone, using a Hidden Markov Model when the length of packets was preser= ved by the encryption.

Yeah, this is also a known issue. Se= e RFC 6562 for some recommendations
on how to address this. If yo= u want to work on this issue, you should probably
take it to the = AVTCORE WG.

-Ekr

--00248c0d7914c28bcb04f47e70f0-- From nobody Thu Mar 13 09:15:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AA71A09AB for ; Thu, 13 Mar 2014 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 VPKIIER-nO_f for ; Thu, 13 Mar 2014 09:15:42 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0D33D1A09F7 for ; Thu, 13 Mar 2014 09:15:41 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oz11so1328053veb.20 for ; Thu, 13 Mar 2014 09:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qvp7+2URpIZyNhipinOBvAydDvECj30sBIGibJT51xs=; b=Zt7wkXRLllA3pBTzNZY3v/giJBdHj+/Y1gazlPXoDBhuv13VeZp6o9Nr1OErUS6gia wTsb0CUv0TqY6UyH1Oap3J4DUU7UGTzIx0fBlWEqBDOwyzqWp/mN2ltuLTbz/pU+V2WT 2yHBB/Z2cy+XMb3lPyBqH2mvJHlloefqPsTRTvNOHkFS2SMbxgHgZc1kHvMxAWVLHwgA 7aM/hchE/Ztb3I9Q4Tj4jDGlRZeIsrLMfqIHcOtdJXxehiM8agQqH9LnZtaxT5EDf+Nw 5+01ds3T8jFgwLoEvpxlaFEwtnuykazrI3fXhZVsZf4laCQBLMbWutQTohLcKDJI6xKr SXgQ== 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=qvp7+2URpIZyNhipinOBvAydDvECj30sBIGibJT51xs=; b=A7C/SkGHOgTjyY8McV9E9ejBQDVCxPgeDg+5ZlBFGDjIOfn645C9i24lamePue7wSz lTrcfTOMC7stUzMdVn2wBolfXxtyT5cE/sTtH7xsXdbxFFchA9NXR8jURdf8XEKjiB+5 CtZBIyrSQ1wXjPaq2ZnELxmkTwkuOn1yZWGEcLwi+a0MnvzaKj/UnWSUg4g3u+wGEAcf C7vYWsxwc59PffojBqtL2e+8DFL3xPqGsVAG5r7mBeHCOhj3HSKB3g+0R710xi4d5qzb gaIKZOSqBTW6oPhZLBN6ek/Ymyc7amBHdFF+D8X8dhzi0qDePHyAQbbwmhENsxX/cJwF Bgig== X-Gm-Message-State: ALoCoQnc9DWalKGtITqSgpgx12+Cd4CBndazI2WMJEpOlSEXL41foyoERhHpThDOEoBe+E5RUfLvw6OYdbDtybncP6hv6UA7ZSp4ZLa8EMgPRh45+zhQ0bl/W88hPzZT1L37gwrizSkmb0zSly+7CtprzD8bMDYcUuS9zI/HuOCnbnL3bQeMgc+ajgs46OiBD/13UO6nps3m X-Received: by 10.52.8.225 with SMTP id u1mr138689vda.64.1394727335319; Thu, 13 Mar 2014 09:15:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 13 Mar 2014 09:15:15 -0700 (PDT) In-Reply-To: <5321A75B.8080100@ericsson.com> References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <532014C8.2050908@ericsson.com> <5321A75B.8080100@ericsson.com> From: Justin Uberti Date: Thu, 13 Mar 2014 09:15:15 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf302d497a617a9204f47f4393 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yAZ7jHQwPkj1mMWp7rEa_alr2wU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 13 Mar 2014 16:15:46 -0000 --20cf302d497a617a9204f47f4393 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 13, 2014 at 5:40 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-12 17:05, Justin Uberti wrote: > > > > On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund > > > > > wrote: > > > > > > > Sorry, I don't understand your reasoning here. Is it to provide the > > lowest possible drop probability, i.e. using the AFx class that has > > least drop probability? > > > > > > The idea is to have the same drop probability as the most critical media > > that is flowing (e.g. voice), so that we don't end up in a situation > > where media flows fine, but the media crowds out STUN consent check > > packets, leading to call failure. > > Okay, that makes a certain sense. First of all this is not likely to > have the "highest" DSCP value. In fact it might not have the lowest drop > probability either. But, yes it might be prioritized over BE. This is > assuming that this DSCP marking do work and doesn't prevent the 6-tuple > to work. But lets take this as a separate issue. > > > > > > > If there exist nodes that stomp on some DSCP markings, and not only > > remark them to Best Effort (BE), and instead drop then. Then, it is > not > > obvious that that an AFx class is the most appropriate to use. In > that > > case using BE might be more suitable for the consent freshness. > > > > > > If nodes stomp on certain AF-marked packets, and this is widespread, > > this essentially dooms use of DSCP at all, unless we want to build some > > sophisticated detection and fallback mechanism. IOW, it's not clear to > > me that marking packets as BE confers any value over not marking at all. > > BE is no marking at all, i.e. DSCP = 0. But, I wanted to be clear that I > really meant best effort. > > But, the question is what we do about nodes that not simple down mark > DSCP code points !=0. I see some potential solutions. > > 1) We recommend that one track the loss rates the different DSCP > markings individually and in cases when loss rates for some markings > doesn't match the expected relative behavior between different markings, > then one stops using DSCP markings and send everything as BE. > > 2) One expands the initial STUN exchange to a second round after > nomination to verify the DSCP code points that one intended to use is > not being blocked. > > The alternative to do something is to ignore the issue. It might be > small enough that it isn't significant. I don't have data on this. If > someone has any data source it would be appreciated if they share. > > We could perform an experiment to determine how often this occurs in real life. I was thinking about having clients send STUN requests with different DSCP markings to a STUN server, and then analyzing the success rate. Open to other ideas though. --20cf302d497a617a9204f47f4393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 13, 2014 at 5:40 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
On 2014-03-12 17:05, Justin Uberti wrot= e:
>
> On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund
> <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.c= om>>
> wrote:
>

>
> =C2=A0 =C2=A0 Sorry, I don't understand your reasoning here. Is it= to provide the
> =C2=A0 =C2=A0 lowest possible drop probability, i.e. using the AFx cla= ss that has
> =C2=A0 =C2=A0 least drop probability?
>
>
> The idea is to have the same drop probability as the most critical med= ia
> that is flowing (e.g. voice), so that we don't end up in a situati= on
> where media flows fine, but the media crowds out STUN consent check > packets, leading to call failure.

Okay, that makes a certain sense. First of all this is not likely to<= br> have the "highest" DSCP value. In fact it might not have the lowe= st drop
probability either. But, yes it might be prioritized over BE. This is
assuming that this DSCP marking do work and doesn't prevent the 6-tuple=
to work. But lets take this as a separate issue.

>
>
> =C2=A0 =C2=A0 If there exist nodes that stomp on some DSCP markings, a= nd not only
> =C2=A0 =C2=A0 remark them to Best Effort (BE), and instead drop then. = Then, it is not
> =C2=A0 =C2=A0 obvious that that an AFx class is the most appropriate t= o use. In that
> =C2=A0 =C2=A0 case using BE might be more suitable for the consent fre= shness.
>
>
> If nodes stomp on certain AF-marked packets, and this is widespread, > this essentially dooms use of DSCP at all, unless we want to build som= e
> sophisticated detection and fallback mechanism. IOW, it's not clea= r to
> me that marking packets as BE confers any value over not marking at al= l.

BE is no marking at all, i.e. DSCP =3D 0. But, I wanted to be clear t= hat I
really meant best effort.

But, the question is what we do about nodes that not simple down mark
DSCP code points !=3D0. I see some potential solutions.

1) We recommend that one track the loss rates the different DSCP
markings individually and in cases when loss rates for some markings
doesn't match the expected relative behavior between different markings= ,
then one stops using DSCP markings and send everything as BE.

2) One expands the initial STUN exchange to a second round after
nomination to verify the DSCP code points that one intended to use is
not being blocked.

The alternative to do something is to ignore the issue. It might be
small enough that it isn't significant. I don't have data on this. = If
someone has any data source it would be appreciated if they share.


We could perform= an experiment to determine how often this occurs in real life. I was think= ing about having clients send STUN requests with different DSCP markings to= a STUN server, and then analyzing the success rate. Open to other ideas th= ough.
--20cf302d497a617a9204f47f4393-- From nobody Thu Mar 13 09:17:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990CF1A0A1E for ; Thu, 13 Mar 2014 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 eA4jNjSrltlx for ; Thu, 13 Mar 2014 09:17:24 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 957971A073C for ; Thu, 13 Mar 2014 09:17:24 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id id10so1364786vcb.12 for ; Thu, 13 Mar 2014 09:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XMbokdT/7IEZLTI+MRPPImSu9RUyp9K9yNOSccnCGfk=; b=kYdQvSirt2BVuUDzZlgkhIosy05Yku4Wk2X/fIaLEEcLrgkL83gytcmM25mpSvK7/D J9vPsJUy7TjK9gqbtjl7g0jIRkr6dphtVzfuJ4t/1DedQi1yZkUxngQcTr9q/bOXpuQU Rx1cOLu4Hi4bZo6c1C+/eepF3GFN40s8I4rWQF2gPGXJ8UC3Y2iHffaXVYwvmOcdbO+8 2CN8NhJc5saFpjbooQmPjfdicNBE6rFa68yN2Jfs4THCH6qKTlAI6S6ihQGEdp/5INJR Jfmtfzf5z0xZv3cQZOzdT808P3x/eTlLMRyrR54Dslucn+8ypGFTjJOlxXFkz++bz7Se wz/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XMbokdT/7IEZLTI+MRPPImSu9RUyp9K9yNOSccnCGfk=; b=jMb1P4RW3OEAji7k33D9HBru2/Dft7Ja4hJo0DkTtEVOtcdZM33fNl3hhVC2LUNYDe 1hCmKh/XW0fVvwq7RWyzvuaKEIe3T24A4Zb2fuDrIySBF5ZItnVE9Wl4EecwBkFzgkFB 9npIBvg/rJjnDdqGWHlSZfGsqq65SlLnhI08a8HusfDFYyLvLDrf89CXKRjiELQuqs/t AGKjA87KXhJQFW49As7modVeVNKsUIDBatLuaKrA0yqnzeizXKaWL1W/GYDRAe8eaaHS ndH2FtRDrB+eD5df4S8CfGNHQSf/x4ozNE1myNulGtK1O0EuLtIuWNnK+8Int/V3w5IL e3VA== X-Gm-Message-State: ALoCoQldpshApVPx4RaIzRvHjd8pABgQylPCtWHcp0gipWxxhrPr7ilARLzFdPjB5uFL4NSq1EaTIARlJ/4WdUAZUpDl68Olq9VmFSG0xUGlF+xUhKOJkXNbLMlzNNH7mLQrdDSNMegdTNCE69uiVSHiz8Aa5VUHIJo+9cfLN1GQw/u3Wf+iU2pzbUL5YLHJVzeKBMsA+2Kq X-Received: by 10.220.109.1 with SMTP id h1mr2151039vcp.20.1394727437931; Thu, 13 Mar 2014 09:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 13 Mar 2014 09:16:57 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 13 Mar 2014 09:16:57 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c308d67f312904f47f49f6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4og_nu4vOzhWfyxOzU-eKQi91wM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 13 Mar 2014 16:17:26 -0000 --001a11c308d67f312904f47f49f6 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 13, 2014 at 5:52 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Justin, > > > I think rtcp-mux has to be a MUST use when BUNDLE is used between the > two endpoints. (If the endpoint doesn't support > > BUNDLE, rtcp-mux is not required.) > > > > Otherwise, you get into weird edge cases, such as where you have a data > channel (no RTCP component), and then want > > to add audio (with RTP and RTCP components). You could bundle the audio > RTP over the existing data channel transport, > > but it's not clear what you should do with the RTCP component. Mandating > rtcp-mux avoids this issue completely. > > According to section 4 in RFC 5761, if you multiplex RTP and RTCP on the > same port, you need to assign dedicated PT values to the RTCP packets, > which means that at least PT values 64-95 cannot be used for RTP. > > As you have been one of those talking about the risk of running out of PT > values, I just want to make sure you have taken this into consideration :) > > Yes. The upside of rtcp-mux far outweighs this minor limitation. --001a11c308d67f312904f47f49f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 13, 2014 at 5:52 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi Justin,

> I think rtcp-mux has to be a MUST use when BUNDLE is used between the = two endpoints. (If the endpoint doesn't support
> BUNDLE, rtcp-mux is not required.)
>
> Otherwise, you get into weird edge cases, such as where you have a dat= a channel (no RTCP component), and then want
> to add audio (with RTP and RTCP components). You could bundle the audi= o RTP over the existing data channel transport,
> but it's not clear what you should do with the RTCP component. Man= dating rtcp-mux avoids this issue completely.

According to section 4 in RFC 5761, if you multiplex RTP and RTCP on = the same port, you need to assign dedicated PT values to the RTCP packets, = which means that at least PT values 64-95 cannot be used for RTP.

As you have been one of those talking about the risk of running out of PT v= alues, I just want to make sure you have taken this into consideration :)

Yes. The upside of rtcp-mux far outwei= ghs this minor limitation.
--001a11c308d67f312904f47f49f6-- From nobody Thu Mar 13 09:53:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3011A0A27 for ; Thu, 13 Mar 2014 09:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtpTIdMwmxVA for ; Thu, 13 Mar 2014 09:53:53 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 71F511A09CE for ; Thu, 13 Mar 2014 09:53:53 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so4207849wib.14 for ; Thu, 13 Mar 2014 09:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LMNyOfm10gDRUmhcPV0LoNgeCbsarP5PnQ2SfzQ0fGM=; b=KZfz6iRISjSEmDE5EWm473IiCSF01grD6Nq47rDk3nNE3QJSwzS+UBGH/f7mdqATsF RJv5OdDtmiDdLOcaRR45won2EoV4CGmq3rAoPsPBAJ3HEy48qTTjkAR7HaSe2Aux4z+K bk/5/jEi2xg503STfnsCuzwUe7UCC68sq8B12vmXBw5NcpxQQtbeBmi6D9/MtCH/d040 UobZw0c38PyCdDRkEWOuKh7kS9iXhqzq/hO3XI5Rfc9eluMo0nuWe1lyUkrFmXWkcEf/ eVJYt3hmTSPZ95g+QpVCy3nR8+RGja1xnev7PiomNw75HEhn6vI5eC1VvqQ/T43qfhR2 Oc2w== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr2551507wjc.31.1394729626535; Thu, 13 Mar 2014 09:53:46 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Thu, 13 Mar 2014 09:53:46 -0700 (PDT) In-Reply-To: <53201AEF.6090501@ericsson.com> References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> Date: Thu, 13 Mar 2014 09:53:46 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Zt26DKIOIWe_LPlxR5X2zZ7xpXg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 13 Mar 2014 16:53:55 -0000 On 12 March 2014 01:29, Magnus Westerlund wrote: > I like to point out that the agreement and what is documented in > rtp-usage is that WebRTC endpoint will have to make forwarded streams > appear as locally originated. However, this as currently written does > not apply to RTP middleboxes that interconnects multiple PeerConnections > to form a multi-party session. This is deliberate to ensure that RTP > topologies like RTP mixer and SFM do work on the RTP/RTCP level. I'm still not clear on whether a middlebox interoperating with a WebRTC endpoint is obligated to respect these rules or not. I had assumed that WebRTC is such a bully that they would be forced to. > I am especially interested to know how you will "easy to apply manually" > the synchronization. Can you please describe that. Because, that either > requires an API call to tell the media framework, please consider the > following CNAMES as equivalent, or some other method of telling the > media framework that these different MST are actually originating from a > common clock base. In WebRTC, this would be: var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0]; var video = pc2.getRemoteStreams()[0].getVideoTracks()[0]; var synchronizedStream = new MediaStream(audio, video); We'd have to say that this implies a statement about the clock base of the tracks being the same. ... and that this statement could be wrong. As far as it goes, I'm sure that other systems could build a similar function, but none of those are standardized. > I protested about this, not to lower the users privacy, but over the > concern that this was raised without providing a case where it was > obvious that the user's privacy was impacted. Martin, you said that you > would think about it, and the next statement was lets change it, without > providing any motivation why the concern was significant. I'm sorry about that, I thought about it, but didn't want to waste everyone's time (mine included) with an essay on the subject. From nobody Thu Mar 13 10:21:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330B51A0A36 for ; Thu, 13 Mar 2014 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 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, GB_I_INVITATION=-2, J_CHICKENPOX_44=0.6, 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 YNDN0JVkAslG for ; Thu, 13 Mar 2014 10:21:50 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3139A1A0A33 for ; Thu, 13 Mar 2014 10:21:50 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so1367056yho.29 for ; Thu, 13 Mar 2014 10:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HQKLx24atJZBI7gORGUD9w297Y1/jRj4HKNGrM2k6bQ=; b=NzPMmIFK9jrlvjCQfE0892+8UFBfFWGajS1AW+oKytrIXO2aX/VKmANezZf//oTSSA omft4FQksEItmDPRld9xdOKcwjI4nkUkxd4yV6P0iuU6ydAV0HHgi6pN0UKlBRnsf8jQ 2kvR7y4sFkDOLm6gIt7rghIxwn5fekBKKL28Sf0tMjm7VLzfagmsnZ4tNjEjjIFWmQS3 /Q54KVtnVJHG3dN/rzXOftIkreVsn54MECujvVFd+xS+0i0T/VdcmePWGJMppRq2B2uS 368e6ZX6OkzK2YD1ZExfp1q0firHhqbO9lgNJUqrB8Wyr4XOKa7JKwaGld3NxNyZQAKB JKgQ== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr4004016yhi.4.1394731303551; Thu, 13 Mar 2014 10:21:43 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Thu, 13 Mar 2014 10:21:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 10:21:43 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jZRF2Bi-0o-84gd3z0OZOIRiAiA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Areas of security concern 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, 13 Mar 2014 17:21:53 -0000 On Thu, Mar 13, 2014 at 8:16 AM, Eric Rescorla wrote: > Watson, > > Thanks for your comments. Responses below. > > > On Tue, Mar 11, 2014 at 10:11 PM, Watson Ladd wrote: >> >> >> Problem 1: Which John Smith? >> >> Currently IdPs link attributes to identities. > > > The identities are phrased as RFC822-style names subordinated beneath > the domain name of the IdP (or if the IdP is a universal trust point, then > not subordinated). See: > > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09#section-5.6.5.3.3.1 > > There used to be a human-readable display-name property as well but that's > gone as of this version, precisely because of concerns of this type. Perhaps > you are reading a pre-09 version? No, I am reading the most recent version. Ask someone named John Smith how much email they get not addressed to them. Address-book style limitations might be a useful UI feature, but I don't see how to do it here without custom integration. We can always punt on this until later: there is nothing stopping a more extended set of interactions with IdP in their verification process. > > >> >> Problem 2: IdP pointy bits >> >> >> An IdP has to cryptographically bind a username to some data. It would be >> nice if we could come up with a secure method to do this, and have the >> browser take care of it for the identity provider as much as possible, >> instead of everyone having to do it themselves in likely wrong ways. The >> webcrypto API has been roundly critiqued as being too low-level. > > > We certainly considered this, but that would basically amount to choosing > a specific identity system or standardizing our own, neither of which seems > totally awesome. Incidentally, cryptography isn't actually required here > (though it's probably the method of choice). The IdP could also just > store all the identity assertions it generates in a database and retrieve > it on demand. As it stands you have an open invitation for everyone to try to roll their own, and fail miserably. Even a higher-level sign/verify API would assuage my complaint. Probably a W3C thing though/educating the people implementing/writing the higher-level API. > > > > > >> Problem 3: Renegotiation >> >> The DTLS handshake being used is specified in RFC 4347. In particular, I >> don't see anything about the renegotiation bug being fixed. This enables an >> unknown key-share attack in which A thinks they are transmitting video to B, >> but really are transmitting it to C who knows that they are talking to A. > > > I'm certainly aware of this paper --- though as you know it just came > out recently --- but it's not clear to me how applicable it is, > since the client-authentication version of the attack (which I believe > is the appropriate one here) depends on the TLS server changing > its identity during the session, and RFC5763 requires that the > certificates presented during the DTLS handshake match the > fingerprints in the SDP: > > o The certificate presented during the DTLS handshake MUST match the > fingerprint exchanged via the signaling path in the SDP. The > security properties of this mechanism are described in Section 8. > > RFC 5763 doesn't explicitly talk about renegotiation, so we probably > could add something about handling renegotiation. > > If you think of some way in which the mechanisms above aren't sufficient > please drop me a private e-mail so we can discuss. If the client and server stick to the flow in RFC 5764, then all is good, because the client's signature verify message signs the handshake and there is only one hello. However, it needs to be made explicit that you have to stick exactly to this message sequence. If a client lets the server trick it into renegotiating, we have a problem. Because you never put a state machine into the TLS 1.1 spec, I've had a devil of a time figuring out if this is possible. In particular, it could be that the transition to SRTP after the finished stops renegotiation from being possible. How does rekeying work in DTLS+SRTP? > > >> Problem 4: HMAC-SHA1 in SRTP >> >> If I've chased the chain of references correctly this is the sole MAC >> provided. Is it okay? I have no idea: SHA-1 has been significantly weakened >> in recent years. > > > As far as I know, HMAC-SHA1 is sufficiently secure for this purpose. Three > notes about this: > > 1. We are discussing audio and video packets so there are a lot of them > but modifying any particular one doesn't generally get you much. Video codecs are infamous for having exploitable bugs. Sending in a maliciously formed packet from outside could lead to fun. But yes, I agree that HMAC-SHA1 is probably fine, and given that we are getting CCM I'm not too worried. (Rekeying is a necessity with all of these because of the small MACs). > > 2. The MACs are truncated to 80 or 32 bits. > > 3. There are GCM ciphersuites in the pipeline but they haven't landed yet. > > This is really an issue for the IETF AVTCORE WG, however, since it applies > to all of SRTP, not just rtcweb. > > > > > >> >> Problem 5: What you see is not what I sent >> >> This is an area that is somewhat underspecified, depending as it does on >> the media API's capabilities. The video frame could be silently replaced by >> a different video frame with rather different contents. Any authentication >> of the contents of the video frame would not carry over, but if the contents >> were sufficiently shocking/subtle this might not be noticed. Authentication >> independent of the website offering the video chat makes this attack worse, >> because users will trust what they see more. Isolation doesn't help because >> this is wholesale replacement, not editing. >> >> Most uses of this attack are for puerile purposes. I don't think it's a >> big concern. Then again I could be very, very wrong. > > > We certainly know about this form of attack. For instance, you can just > pretend to operate a calling service but instead of showing the remote > video you can just embed a YouTube video. There are effectively two > cases here: > > - The call is not using isolated streams in which case you didn't have > any protection for the media from the site anyway. > > - The call is using isolated streams in which case the site will have > no access to the true media and so can only blindly inject their > own. > > Obviously this isn't ideal but it's pretty hard to get rid of since the Web > already includes video and even without WebRTC, it's trivial for a site > to play any video it wants to you. We've talked about having some sort > of UI for showing each video element and its provenance, but it's a hard > UX problem. Yeah, punting is perfectly fine on this one. I fully expect heavy exploitation. > > > >> >> Problem 6: General UI issues >> >> Currently quite a bit of the security model depends on UI presentations of >> subtly different states. I don't know how well users will understand this, >> or how well the UI will work. Past experience suggests not well. Luckily we >> can mostly change this later/it isn't part of standardisation. > > > Yes, we are aware of this. Not sure there's much to do about it. > > >> >> Problem 7: VBR privacy leaks >> >> I can do no better then to refer to the paper. >> http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-can.pdf >> Spoken phrases could be identified from encrypted data alone, using a Hidden >> Markov Model when the length of packets was preserved by the encryption. > > > Yeah, this is also a known issue. See RFC 6562 for some recommendations > on how to address this. If you want to work on this issue, you should > probably > take it to the AVTCORE WG. Why is RFC 6562 not cited in the security architecture document? My method was to work back from the security architecture RFC, so I missed that this was fixed. Hopefully an implementor doesn't do the same. Sincerely, Watson Ladd > > -Ekr > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 13 14:26:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FDB1A0A28 for ; Thu, 13 Mar 2014 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tzgrz--cQ3Ip for ; Thu, 13 Mar 2014 14:26:13 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id CEF191A07C8 for ; Thu, 13 Mar 2014 14:26:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4E63E7C4E43; Thu, 13 Mar 2014 22:26: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 y09yqarwXrll; Thu, 13 Mar 2014 22:25:52 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:350e:e079:732a:d69a] (unknown [IPv6:2001:470:de0a:27:350e:e079:732a:d69a]) by mork.alvestrand.no (Postfix) with ESMTPSA id 756967C4D83; Thu, 13 Mar 2014 22:25:52 +0100 (CET) Message-ID: <53222260.5000508@alvestrand.no> Date: Thu, 13 Mar 2014 22:25:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dave Taht , Justin Uberti References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <531F212A.4040102@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xrGgaHOXqTSPl2cfkFUA_63SP7s Cc: Keith Winstein , "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 13 Mar 2014 21:26:17 -0000 On 03/12/2014 09:35 AM, Dave Taht wrote: > On Wed, Mar 12, 2014 at 3:55 AM, Justin Uberti wrote: >> >> >> On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht wrote: > >>>> Whether that always translates to "the highest DSCP code point" is .... >>>> a good question. >>> It doesn't. Keith added af42 support to mosh last year and had several >>> reports of packets being dropped with that marking. Worse the drops happened >>> after 10 seconds of connectivity. >>> >>> Ecn markings on the other hand have thus far survived (if occasionally >>> stomped on) across the open internet in that protocol. >> >> This is a concern of mine as well, which is why we haven't yet flipped the >> switch to turn DSCP on by default in Chrome. I think we'll need to do some >> experimentation to see how often DSCP makes things worse. > Well, while I'm at this, I note that how linux handles DSCP in WIFI 802.11e > is generally suboptimal. the CS6 and CS7 bit patterns map to the VO > queue which is not aggregatable in wireless-n, CS4 and CS5 > map to the VI queue which has a lot of good properties for videoconference > and voice traffic (but limited aggregation), and CS1 and CS2, which map > to the background queue, which has good aggregation but limited txops. That sounds like a Linux bug.... I would expect this translation to be done via lookup tables, not copying one field into another with different semantics (with or without bit-shift). > > I no longer have the bit patterns for AFxx memorized, but basically > all that was returned to the 802.11e classifier was dscp >> 5 up until very > recently. Lastly, there really is no interpretation whatsoever of the AF > classes equating to "drop probability" in wifi (at least in lnux), they merely > control queue selection and > > it is generally better with wireless-n to aim for better aggregation in > one queue rather than using multiple queues as the cost of acquiring > the media dominates. > > > From nobody Thu Mar 13 22:56:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181B51A0052 for ; Thu, 13 Mar 2014 22:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWHN2BDFbvRd for ; Thu, 13 Mar 2014 22:56:48 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id A31B11A0040 for ; Thu, 13 Mar 2014 22:56:47 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-be-53229a175b53 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id F7.11.04853.71A92235; Fri, 14 Mar 2014 06:56:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 06:56:39 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAAIVkAIABaJQggAAqmoCAAPXJ+w== Date: Fri, 14 Mar 2014 05:56:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_cm0fhueueaioe4gj0u8m7vqa1394776596681emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvja74LKVgg8nHrC1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozjc1rZC/rkK55/lGtgvCHZ xcjJISFgIrF0cwsrhC0mceHeerYuRi4OIYETjBIrptxkgXCWMEpcfTKTuYuRg4NNwEKi+582 SIOIgJrEw1m7wJqZBaoltq34xwRiCwsYSxy6vJQZosZEYu7E1ywQdp1E59kJjCA2i4CqRO+y ZewgNq+Am0TjgiZmiF1bWCUWL/gBVsQpECjxYctesEGMQNd9P7WGCWKZuMStJ/OZIK4WkFiy 5zwzhC0q8fLxP6iDciQOvtnGDLFAUOLkzCcsExhFZiFpn4WkbBaSMoi4jsSC3Z/YIGxtiWUL XzPD2GcOPGZCFl/AyL6KUbI4tbg4N93IQC83PbdEL7UoM7m4OD9Przh1EyMw3g5u+W20g/Hk HvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEZpHL5Q7f71hHTGj6Mn HiWuTmdqqpHS9FxmpLfM5q3mgcfJRqmObC90rbdNOaJ8zX1mmNA5g/jy8K6o/znaRdGHpfhW GJvYqJTKxq/xYyj/u6dQgHV74pYVekvY7ubUC90w6nrC5nvg0+fs7gxpnVlavx+WZcf0rOvO ODjZyPSKNC/fwrh8JZbijERDLeai4kQAG47qoYUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PyEd834N4613BkR2en6GxcmPO4U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 05:56:50 -0000 --_000_cm0fhueueaioe4gj0u8m7vqa1394776596681emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just to clarify: you would still use the a=3Drtcp-mux attribute, right? It is e.g. needed to inform intermediaries (that may not understand BUNDLE)= about the usage of RTCP mux. Regards, Christer Sent from my Sony Ericsson Xperia arc S Justin Uberti wrote: On Thu, Mar 13, 2014 at 5:52 AM, Christer Holmberg > wrote: Hi Justin, > I think rtcp-mux has to be a MUST use when BUNDLE is used between the two= endpoints. (If the endpoint doesn't support > BUNDLE, rtcp-mux is not required.) > > Otherwise, you get into weird edge cases, such as where you have a data c= hannel (no RTCP component), and then want > to add audio (with RTP and RTCP components). You could bundle the audio R= TP over the existing data channel transport, > but it's not clear what you should do with the RTCP component. Mandating = rtcp-mux avoids this issue completely. According to section 4 in RFC 5761, if you multiplex RTP and RTCP on the sa= me port, you need to assign dedicated PT values to the RTCP packets, which = means that at least PT values 64-95 cannot be used for RTP. As you have been one of those talking about the risk of running out of PT v= alues, I just want to make sure you have taken this into consideration :) Yes. The upside of rtcp-mux far outweighs this minor limitation. --_000_cm0fhueueaioe4gj0u8m7vqa1394776596681emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,=0A=
=0A=
Just to clarify: you would still use the a=3Drtcp-mux attribute, right? =0A=
=0A=
It is e.g. needed to inform intermediaries (that may not understand BUNDLE)=
 about the usage of RTCP mux.=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Justin Uberti <juberti@google.com> wrote:=0A=
=0A=



On Thu, Mar 13, 2014 at 5:52 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi Justin,

> I think rtcp-mux has to be a MUST use when BUNDLE is used between the = two endpoints. (If the endpoint doesn't support
> BUNDLE, rtcp-mux is not required.)
>
> Otherwise, you get into weird edge cases, such as where you have a dat= a channel (no RTCP component), and then want
> to add audio (with RTP and RTCP components). You could bundle the audi= o RTP over the existing data channel transport,
> but it's not clear what you should do with the RTCP component. Mandati= ng rtcp-mux avoids this issue completely.

According to section 4 in RFC 5761, if you multiplex RTP and RTCP on the sa= me port, you need to assign dedicated PT values to the RTCP packets, which = means that at least PT values 64-95 cannot be used for RTP.

As you have been one of those talking about the risk of running out of PT v= alues, I just want to make sure you have taken this into consideration :)

Yes. The upside of rtcp-mux far outweighs this minor limitation.
--_000_cm0fhueueaioe4gj0u8m7vqa1394776596681emailandroidcom_-- From nobody Fri Mar 14 01:35:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2DA1A00AD for ; Fri, 14 Mar 2014 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 S-kynFy8EvZZ for ; Fri, 14 Mar 2014 01:35:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 45BBA1A00A6 for ; Fri, 14 Mar 2014 01:35:02 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-ec-5322bf2e7d73 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C1.5B.23809.E2FB2235; Fri, 14 Mar 2014 09:34:55 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Mar 2014 09:34:54 +0100 Message-ID: <5322BF2E.3060608@ericsson.com> Date: Fri, 14 Mar 2014 09:34:54 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja7+fqVgg5cJFlunCllcO/OP0WLt v3Z2B2aPnbPusnss2FTqsWTJT6YA5igum5TUnMyy1CJ9uwSujPnLzjMXdCtWTJoyib2B8alU FyMnh4SAiUTfthksELaYxIV769m6GLk4hAQOMUrsW7KVGcJZziix/PRHVpAqXgFtia5nO5hA bBYBVYn9f06DxdkELCRu/mhkA7FFBYIldh74zQhRLyhxcuYTsA0iAroSi84+YAexmQW8JT4t grCFBawknhw+wAKxrJNF4sn6RrAGToFAiet/nwLZHEDniUv0NAZB9GpKtG7/DTVHXqJ562xm EFsI6LaGpg7WCYxCs5CsnoWkZRaSlgWMzKsY2XMTM3PSy402MQJD9+CW36o7GO+cEznEKM3B oiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxj3X9oebbGB/VspgwPir5OWk1IM9 qxy2sta4B7YEcF+pitwcNMFlbWLsSa0Fr3WcLpdsf9XJdyDDIntLZezMKb373x3SjvyfePhj c1FHAtOTgr1yik3H7p+XDdCa8d991dIjV75ub+58cpOhhf2jmm+IxId5jcIrZ3hnlLsv2Bwh 82lOmSmzvBJLcUaioRZzUXEiADzKE+krAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Yple6ykhhKWTjwqc90wjE0x-HRU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 14 Mar 2014 08:35:05 -0000 On 2014-03-13 17:53, Martin Thomson wrote: > On 12 March 2014 01:29, Magnus Westerlund > wrote: >> I like to point out that the agreement and what is documented in >> rtp-usage is that WebRTC endpoint will have to make forwarded streams >> appear as locally originated. However, this as currently written does >> not apply to RTP middleboxes that interconnects multiple PeerConnections >> to form a multi-party session. This is deliberate to ensure that RTP >> topologies like RTP mixer and SFM do work on the RTP/RTCP level. > > I'm still not clear on whether a middlebox interoperating with a > WebRTC endpoint is obligated to respect these rules or not. I had > assumed that WebRTC is such a bully that they would be forced to. Well, I know Colin and I did put in quite some thought to make the WebRTC RTP usage rules such that you can use the common RTP middleboxes as long as you have the right front-end, i.e. DTLS-SRTP and signalling translation. > >> I am especially interested to know how you will "easy to apply manually" >> the synchronization. Can you please describe that. Because, that either >> requires an API call to tell the media framework, please consider the >> following CNAMES as equivalent, or some other method of telling the >> media framework that these different MST are actually originating from a >> common clock base. > In WebRTC, this would be: > > var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0]; > var video = pc2.getRemoteStreams()[0].getVideoTracks()[0]; > var synchronizedStream = new MediaStream(audio, video); > > We'd have to say that this implies a statement about the clock base of > the tracks being the same. ... and that this statement could be > wrong. I think this looks dangerous. If you default the assumption that different CNAMEs of the MST you add are actually sharing clock base, then a lot of basic programs that may group MST from different PCs into one MS for convenience are going to cause serious issue in the media frameworks, when they attempt to synchronize things. > > As far as it goes, I'm sure that other systems could build a similar > function, but none of those are standardized. > >> I protested about this, not to lower the users privacy, but over the >> concern that this was raised without providing a case where it was >> obvious that the user's privacy was impacted. Martin, you said that you >> would think about it, and the next statement was lets change it, without >> providing any motivation why the concern was significant. > > I'm sorry about that, I thought about it, but didn't want to waste > everyone's time (mine included) with an essay on the subject. > Having considered this a bit more, I do think the risk to privacy out weighs the other concerns, as long as the API and its handling can be sorted out, I don't think the above is sufficient to get good functionality. My understanding is that the risk to privacy exist when one have one JS application enabling communication in different contexts during the same application session. In cases where there might be participants in the different contexts that could link the same end-point and thus human user to different participant IDs (that otherwise are anonymous). Thus revealing privacy concerns. As it would take the application designer to take this risk into consideration to avoid it, I feel safer if the application designer would need to take active measurements to perform linkage. I will wait an see if there are other inputs on this within the next week. If nothing arises I will propose a text change to the rtp-usage to address this. Cheers Magnus Westerlund (As individual) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 14 01:57:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D518E1A00B8 for ; Fri, 14 Mar 2014 01:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pj43yhowG12 for ; Fri, 14 Mar 2014 01:57:36 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E12E71A00B2 for ; Fri, 14 Mar 2014 01:57:35 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-fb-5322c478a521 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B2.3B.04249.874C2235; Fri, 14 Mar 2014 09:57:28 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Mar 2014 09:57:25 +0100 Message-ID: <5322C475.5050402@ericsson.com> Date: Fri, 14 Mar 2014 09:57:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , Justin Uberti References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se>, In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+JvjW7FEaVggylPFCxWvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErowPnV1sBZ95K7afbGVvYFzA 3cXIySEhYCKxZdFCRghbTOLCvfVsILaQwBFGicvHYrsYuYDs5YwSSw7uYQZJ8ApoSzxd8YAF xGYRUJVYducFK4jNJmAhcfNHI1izqECwxM4Dvxkh6gUlTs58AlYvIhAj8avvDlicWcBVounh UrC4sICxxKHLS5khlt1mlTgz8zfYUE4Bd4nXR/4wdTFyAF0nLtHTGATRqycx5WoL1Bx5ieat s5khjtaWaGjqYJ3AKDQLyepZSFpmIWlZwMi8ipGjOLU4KTfdyGATIzB4D275bbGD8fJfm0OM 0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg3GWheepUiBUHh2PjW91g67jb rkefb9Q+kjDJq/us9qeJUcv3mIR/t5j3MvDYKt+iuT+kpmT2XOwKcvm8tLRlhUCEEIvl1uwn k1ycrCZ/MPHaOrOpcM+nxovmdcmOXN42q+f+Sfb29H0vvN9O64rSrr8fw9oKSvd279WxelpU aJOTuuNhtJqZEktxRqKhFnNRcSIAKX5kPiwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5jwrE10pYMUjqk8lGMVk4-WNTQU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 08:57:38 -0000 Hi, (as individual) Although this discussion really should be on MMUSIC, I am still following up here. Anything we come to conclude here really need to go to MMUSIC for confirmation. Justin, I do agree that it appear unnecessarily of having to include an RTCP transport in an OFFER when the offerer know the answerer is BUNDLE capable. I am fine with that and think the rule needed here is something along the line of the below: A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already required). In any answer by a BUNDLE capable endpoint, it MUST NOT change the usage of a=rtcp-mux. If it is present in the offer, it must be confirmed to be used in the answer, and if not present in the offer, it MUST NOT be added in the answer. An BUNDLE capable endpoint is RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not be suitable include, lack RTP payload types, or cases when RTCP traffic is needed to be on its own transport flow (5-tuple) to enable QoS or other traffic handling functionalities. The reason for writing the rule like the above, is that then an endpoint can choose when creating an offer to renegotiate the use of a=rtcp-mux. For example due to it running out of available PTs. Feedback on this proposal? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 14 02:35:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ADD1A00E3 for ; Fri, 14 Mar 2014 02:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 PsI0X6O-Ty8R for ; Fri, 14 Mar 2014 02:35:47 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEAE1A00C6 for ; Fri, 14 Mar 2014 02:35:45 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-cb-5322cd6acf83 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2E.55.23809.A6DC2235; Fri, 14 Mar 2014 10:35:38 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.220]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 10:35:37 +0100 From: John Mattsson To: "rtcweb@ietf.org" Thread-Topic: Comments on draft-ietf-rtcweb-security-06 Thread-Index: AQHPP2jBbcKLi1qPfU6JnWpSLmUKWw== Date: Fri, 14 Mar 2014 09:35:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [153.88.183.20] Content-Type: multipart/related; boundary="_005_CF488C1C11409johnmattssonericssoncom_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUyM+JvjW7WWaVgg3OP9C3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvOv31gKbnxgqtg2dyJbA+P+Z0xdjBwcEgImEotn53cxcgKZ YhIX7q1n62Lk4hASOMQo8ftnMzuEs4RR4uWEtywgVWwCBhJz9zSwgdgiAuoSlx9eYAexhQWM JNZ1tbKDDBURMJf4MpcdokRPYubzA0wgNouAqsSe841gY3iBSp7uns0MYjMCLf5+ag1YDbOA uMStJ/OZIA4SkXh48TQbhC0q8fLxP1YQWxRo5r1Hc1kg4ooSV6cvh+qtkJi4v5cZYr6gxMmZ T1gmMArPQjJ2FpKyWUjKIOIxEu++7mecBfQBs4CmxPpd+hBhRYkp3Q/ZIWwNidY5c9khSqwl eucJYirxlrg8YTEzhO0gMWXPbSCbC8g+xijxfeNhVoiEkcTnNWdZUTVzgDXfajaD6f06/RAL XO+tn3uZIWqMJCZ9SEbWuoBReBUje25iZk56udEmRmCyOLjlt+oOxjvnRA4xSnOwKInzfnjr HCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBceHRZ/VPhFK3CGfxWU9qfi56VXrKJfm7v6ew mU5IdGqf79koN2NHVJ+/xNGgWElFi/hERjvp3D+6E581zRL6lbNH7lixwcGmPqXmvmszZdos bzzi2f/ol/9mh+fPzhcENmZKzXdzSGxdueZe2NxCkXOTlrSytR8wU+Ys+Jb/7rjgKtY/8+bl K7EUZyQaajEXFScCADRJpkbkAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_2cf1vSU6hI9ZSjqkKF64AG74E8 Subject: [rtcweb] Comments on draft-ietf-rtcweb-security-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 09:35:50 -0000 --_005_CF488C1C11409johnmattssonericssoncom_ Content-Type: multipart/alternative; boundary="_000_CF488C1C11409johnmattssonericssoncom_" --_000_CF488C1C11409johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGZvciBXZWJSVEMgKGRyYWZ0 LWlldGYtcnRjd2ViLXNlY3VyaXR5LTA2KQ0KDQoNClNlZW1zIHRvIGJlIGluIGdvb2Qgc2hhcGUu DQoNCg0KQ2hlZXJzDQoNCkpvaG4NCg0KDQoNCg0KDQotW0dlbmVyYWxdDQoNClRoZSBkcmFmdCBz aG91bGQgZGlzY3VzcyB0aHJlYXRzIHdoZW4gdGhlIHVzZXJzIGJlbG9uZyB0byBkaWZmZXJlbnQg Y2FsbGluZyBzZXJ2aWNlcy4gVGhlcmUgYXJlIHRoZW4gdHdvIHBvdGVudGlhbGx5IG1hbGljaW91 cyBjYWxsaW5nIHNlcnZpY2VzIGFzIHdlbGwgYXMgdGhlIHRyYW5zcG9ydCBiZXR3ZWVuIHRoZW0u DQoNCg0KLVtHZW5lcmFsXQ0KDQpUaGUgZHJhZnQgc2hvdWxkIG1ha2UgY2xlYXIgaG93IHRoZSB0 aHJlYXRzLCBsZXZlbHMgb2YgY29uc2VudCwgYW5kIGNocm9tZSBpbmRpY2F0aW9ucyBkaWZmZXIg YmV0d2VlbiBkYXRhIGNoYW5uZWxzIGFuZCBtZWRpYSBjaGFubmVscy4gT2J2aW91c2x5IGNvbnNl bnQgYW5kIGNocm9tZSBpbmRpY2F0b3JzIGFyZSBuZWVkZWQgZm9yIGFjY2Vzc2luZyBtaWMgYW5k IGNhbWVyYS4gUmlnaHQgbm93IHRoZSBkcmFmdCBtb3N0bHkgdGFsa3MgYWJvdXQgY29uc2VudCBh bmQgaW5kaWNhdG9ycyBmb3IgYSAiY2FsbCIgYW5kIHNheXMgbm90aGluZyBhYm91dCBjYWxsZXIg YW5kIGNhbGxlZSBjb25zZW50IGFuZCBjaHJvbWUgaW5kaWNhdG9ycyBmb3IgcHVyZSBkYXRhIGNo YW5uZWxzLg0KDQoNCi1bR2VuZXJhbF0NCg0KQSBkcmFmdCBkaXNjdXNzaW5nIHRocmVhdHMgdG8g YSB1c2VyLXRvLXVzZXIgY29tbXVuaWNhdGlvbiBzeXN0ZW0gc2hvdWxkIHByb2JhYmx5IGRpc2N1 c3MgdW5zb2xpY2l0ZWQgY29tbXVuaWNhdGlvbiAoaS5lLiBTUElULCBTUElNKSBhIGxpdHRsZSBi aXQsIG5vdCBqdXN0IHdyaXRpbmcgdGhhdCAicHJhbmsgY2FsbHMiIGlzIG91dCBvZiBzY29wZS4N Cg0KDQoNCg0KMy4gIFRoZSBCcm93c2VyIFRocmVhdCBNb2RlbA0KDQoNCi1bczNdICJORVRXT1JL IEFUVEFDS0VSUywgd2hvIGFyZSBhYmxlIHRvIGNvbnRyb2wgeW91ciBuZXR3b3JrIg0KDQpTaG91 bGQgYmUgInRoZSBuZXR3b3JrIiBvciAicGFydCBvZiB0aGUgbmV0d29yayINCg0KDQoNCjQuMS4g IEFjY2VzcyB0byBMb2NhbCBEZXZpY2VzDQoNCg0KLVtzNC4xXSAiSW4gZWl0aGVyIGNhc2UsIGFs bCB0aGUgYnJvd3NlciBpcyBhYmxlIHRvIGRvIGlzIHZlcmlmeSBhbmQgY2hlY2sgYXV0aG9yaXph dGlvbiBmb3Igd2hvZXZlciBpcyBjb250cm9sbGluZyB3aGVyZSB0aGUgbWVkaWEgZ29lcy4iDQoN ClNob3VsZCBtZW50aW9uIHRoYXQgdGhlIGJyb3dzZXIgbWF5IGJlIGFibGUgdG8gYXV0aGVudGlj YXRlIHRoZSBtZWRpYSBkZXN0aW5hdGlvbi4NCg0KDQotW3M0LjFdICJCeSBjb250cmFzdCwgY29u c2VudCB0byBzZW5kIG5ldHdvcmsgdHJhZmZpYyBpcyBhYm91dCBwcmV2ZW50aW5nIHRoZSB1c2Vy J3MgYnJvd3NlciBmcm9tIGJlaW5nIHVzZWQgdG8gYXR0YWNrIGl0cyBsb2NhbCBuZXR3b3JrLiIN Cg0KICAgSXQncyBhbHNvIGFib3V0IERvUyAod2hpY2ggaXMgbWVudGlvbmVkIGluIHRoZSBiZWdp bm5pbmcpIGFuZCBwcm90ZWN0aW5nIG90aGVyIG5ldHdvcmtzIHRoYXQgbWF5IGhhdmUgZmlyZXdh bGxzIGJsb2NraW5nIHRyYWZmaWMgZnJvbSBEci4gRXZpbCBidXQgYWNjZXB0aW5nIHRyYWZmaWMg ZnJvbSB5b3UuDQoNCg0KLVtzNC4xLjIuMSwgNC4xLjIuMl0NCg0KNC4xLjIuMSAiSWYgSSBncmFu dCBwZXJtaXNzaW9uIHRvIGNhbGxpbmcgc2VydmljZSBBIHRvIG1ha2UgY2FsbHMgb24gbXkgYmVo YWxmLCB0aGVuIEkgYW0gaW1wbGljaXRseSBncmFudGluZyBpdCBwZXJtaXNzaW9uIHRvIGJ1ZyBt eSBjb21wdXRlciB3aGVuZXZlciBpdCB3YW50cy4iDQoNCg0KNC4xLjIuMiAiTm90ZSBhbHNvIHRo YXQgdGhlIHVzZXIgaW50ZXJmYWNlIGNocm9tZSBtdXN0IGNsZWFybHkgZGlzcGxheSBlbGVtZW50 cyBzaG93aW5nIHRoYXQgdGhlIGNhbGwgaXMgY29udGludWluZyBpbiBvcmRlciB0byBhdm9pZCBh dHRhY2tzIHdoZXJlIHRoZSBjYWxsaW5nIHNpdGUganVzdCBsZWF2ZXMgaXQgdXAgaW5kZWZpbml0 ZWx5IGJ1dCBzaG93cyBhIFdlYiBVSSB0aGF0IGltcGxpZXMgb3RoZXJ3aXNlLiINCg0KDQpUaGUg dGV4dCBvbiBjaHJvbWUgaW5kaWNhdGlvbnMgaXMgYWxzbyBoaWdobHkgcmVsZXZhbnQgZm9yIDQu MS4yLjEsIEV2ZW4gaWYgdGhlIHVzZXIgaGF2ZSBncmFudGVkIGxvbmcgdGVybSBjb25zZW50LCB0 aGUgYnJvd3NlciBzaG91bGQgc3RpbGwgc2hvdyB3aGVuIGEgc2l0ZSBhY2Nlc3NlcyBtaWMgYW5k IGNhbWVyYS4NCg0KDQoNCjQuMi4gIENvbW11bmljYXRpb25zIENvbnNlbnQgVmVyaWZpY2F0aW9u DQoNCg0KLVtzNC4yLjJdICJVRFAgb3ZlciBEVExTIg0KDQpJcyB0aGlzIHVzZWQgYW55d2hlcmUg b3IganVzdCBhIHRoZW9yZXRpY2FsIGV4YW1wbGU/DQoNCg0KDQo0LjMuICBDb21tdW5pY2F0aW9u cyBTZWN1cml0eQ0KDQoNCi1bczQuM10gInNlY3VyZSBhZ2FpbnN0IGJvdGggbWVzc2FnZSByZWNv dmVyeSBhbmQgbWVzc2FnZSBtb2RpZmljYXRpb24uIg0KDQpBZGQgcmVwbGF5DQoNCg0KLVtzNC4z XSAidGhlIHBlZXIncyBpZGVudGl0eSBpbmZvcm1hdGlvbiwgd2hpY2gsIGFmdGVyIGFsbCwgaXMg b25seSBtZWFuaW5nZnVsIGluIHRoZSBjb250ZXh0IG9mIHNvbWUgY2FsbGluZyBzZXJ2aWNlLiIN Cg0KTm90IGlmIGF1dGhlbnRpY2F0ZWQgdmlhIElkUCBvciBQS0kuDQoNCg0KLVtzNC4zLCA0LjMu MSwgYW5kIDQuMy4yXQ0KDQpJIHRoaW5rIHRoZSBkaXZpc2lvbiBpbiAidW5jb21wcm9taXNlZCBk dXJpbmcgY2FsbCwgbGF0ZXIgY29tcHJvbWlzZWQiIGFuZCAiYWN0aXZlIiBpcyBhIGJhZCBpZGVh LiBJIHdvdWxkIHN0cm9uZ2x5IHJlY29tbWVuZCByZXN0cnVjdHVyaW5nIHNlY3Rpb24gNC4zLCA0 LjMuMSwgYW5kIDQuMy4yIHRvIGZvbGxvdyB0aGUgZGVmaW5pdGlvbnMgb2YgInBhc3NpdmUgYXR0 YWNrcyIgYW5kICJhY3RpdmUgYXR0YWNrcyIgaW4gUkZDIDM1NTIuIFRoZSB0ZXh0IGNvdWxkIHRo ZW4gYWxzbzoNCg0KICAgICAgICAtIERpZmZlcmVudGlhdGUgYmV0d2VlbiBhdHRhY2tzIG9uIHRo ZSBzaWduYWxpbmcgcGxhbmUgYW5kIHRoZSB1c2VyIHBsYW5lLCBhbmQgY2xhcmlmeSB3aGVyZSBQ RlMgaXMgbmVlZGVkLg0KDQogICAgICAgIC0gRGlmZmVyZW50aWF0ZSBhY3RpdmUgYXR0YWNrcyBv biB0aGUga2V5IG1hbmFnZW1lbnQgdnMuIGFjdGl2ZSBhdHRhY2tzIGJ5IHNlbmRpbmcgdHJhZmZp YyB0byBhIHJlY29yZGluZyBzZXJ2aWNlLg0KDQogICAgICAgIC0gQWxzbyBjb25zaWRlciBwYXNz aXZlIGFuZCBhY3RpdmUgYXR0YWNrcyBmcm9tIG90aGVyIHRoYW4gdGhlIGNhbGxpbmcgc2Vydmlj ZS4NCg0KICAgICAgICAtIE1ha2UgaXQgY2xlYXIgdGhhdCAoaW4gbW9zdCBjYXNlcykgeW91IG5l ZWQgYWNjZXNzIHRvIGJvdGggY29udHJvbCBhbmQgdXNlciBwbGFuZSBkYXRhLg0KDQoNCi1bczQu M10gIlRoZSBjYWxsaW5nIHNlcnZpY2UgaXMgY29tcHJvbWlzZWQgZHVyaW5nIHRoZSBjYWxsIGl0 IHdpc2hlcyB0byBhdHRhY2sgKG9mdGVuIGNhbGxlZCBhbiAiYWN0aXZlIGF0dGFjayIpLiINCg0K V2hpbGUgImFjdGl2ZSBhdHRhY2siIGltcGxpZXMgImNvbXByb21pc2VkIGR1cmluZyBjYWxsIiB0 aGUgb3Bwb3NpdGUgaXMgbm90IHRydWUgYXMgYSBkdXJpbmctY2FsbCBhdHRhY2sgY2FuIHZlcnkg d2VsbCBiZSBwYXNzaXZlLg0KDQoNCi1bczQuM10gIlRoZSBjYWxsaW5nIHNlcnZpY2UgaXMgbm9u LW1hbGljaW91cyBkdXJpbmcgYSBjYWxsIGJ1dCBzdWJzZXF1ZW50bHkgaXMgY29tcHJvbWlzZWQg YW5kIHdpc2hlcyB0byBhdHRhY2sgYW4gb2xkZXIgY2FsbCAob2Z0ZW4gY2FsbGVkIGEgInBhc3Np dmUgYXR0YWNrIikiDQoNClNpbWlsYXJseSBhcyB0aGUgYWJvdmUgY29tbWVudCAicGFzc2l2ZSBh dHRhY2siIGRvZXMgbm90IGVxdWF0ZSB0aGUgY2FsbGluZyBzZXJ2aWNlIGJlaW5nIG5vbi1tYWxp Y2lvdXMgZHVyaW5nIHRoZSBjYWxsLg0KDQoNCi1bczQuM10gIldlIGRpc2N1c3Mgc29tZSBwb3Rl bnRpYWwgYXBwcm9hY2hlcyBhbmQgd2h5IHRoZXkgYXJlIGxpa2VseSB0byBiZSBpbXByYWN0aWNh bCBpbiBTZWN0aW9uIDQuMy4yLiINCg0KU2VjdGlvbiA0LjMuMiBkb2VzIG5vdCBkaXNjdXNzICJ3 aHkgdGhleSBhcmUgbGlrZWx5IHRvIGJlIGltcHJhY3RpY2FsIg0KDQoNCi1bczQuM10NCg0KRmFp bHMgdG8gY2xlYXJseSBkZXNjcmliZSB0aGF0IHRoZSBhdHRhY2tlciBuZWVkcyBhY2Nlc3MgdG8g dGhlIG1lZGlhIGNoYW5uZWwgYW5kIGRlc2NyaWJlIGhvdyB0aGUgYXR0YWNrZXIgZ2V0cyB0aGF0 LiBJZiB0aGUgY2FsbGluZyBzZXJ2aWNlIGlzIGNvbXByb21pc2VkIGl0IGNhbiBqdXN0IGluY2x1 ZGUgaXRzZWxmIGl0IHRoZSBtZWRpYSBwYXRoLCBidXQgb3RoZXJ3aXNlIHRoZSBhdHRhY2tlciBt dXN0IGludGVyY2VwdCB0aGUgbWVkaWEgcGF0aC4NCg0KDQotW3M0LjNdICJIb3dldmVyLCBpdCBp cyBleHRyZW1lbHkgZGlmZmljdWx0Ig0KDQpXZWxsIHRoZW9yZXRpY2FsbHkgaXQncyBzaW1wbGUg KGF1dGhlbnRpY2F0ZSksIG1heWJlIGV4cGxhaW4gdGhhdCB0aGUgZGlmZmljdWx0IHBhcnQgaXMg ZGVwbG95bWVudCBpbiB0aGUgV2ViUlRDIGNhc2UuDQoNCg0KLVtzNC4zLjFdDQoNClNob3VsZCBt ZW50aW9uIHRoYXQgdGhlIHJldHJvc3BlY3RpdmUgYXR0YWNrIHJlcXVpcmVzIHRoYXQgdGhlIGNh bGxpbmcgc2VydmljZSBoYXMgZWl0aGVyIHNhdmVkIGFsbCB0aGUgbWVkaWEgKG5vdCB0aGF0IGxp a2VseSkgb3IgdGhhdCB0aGUgYXR0YWNrZXIgaGFzIGNhcHR1cmVkIGl0IGJlZm9yZWhhbmQuDQoN Cg0KLVtzNC4zLjFdICJpbiBTREVTIFtSRkM0NTY4XSksIHRoZW4gcmV0cm9zcGVjdGl2ZSBhdHRh Y2sgaXMgdHJpdmlhbC4iDQoNCkkgd291bGQgcmVtb3ZlIHRyaXZpYWwuIEkgYWdyZWUgdGhhdCBp ZiB5b3UgaGF2ZSAxLiBiZWVuIGFibGUgdG8gY2FwdHVyZSB0aGUgZGF0YSBieSBpbnRlcmNlcHRp bmcgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgIHBlZXJzLCAyLiBiZWVuIGFibGUgdG8g Y29tcHJvbWlzZSB0aGUgY2FsbGluZyBzZXJ2aWNlLCBhbmQgMy4gYmVlbiBhYmxlIHRvIHJlYWQg dGhlIGtleSBmcm9tIHRoZSBsb2dzLCB0aGVuIGRlY3J5cHRpbmcgaXMgdHJpdmlhbCwgYnV0IDEs MiwzIGlzIG5vdCB0cml2aWFsLg0KDQoNCi1bczQuMy4yXQ0KDQpTaG91bGQgbWVudGlvbiB0aGF0 IGFueSBmaW5nZXJwcmludCBtZWNoYW5pc20gc2VudCB2aWEgdGhlIGNhbGxpbmcgc2VydmljZSAo c3VjaCBhcyB0aGUgb25lIGluIERUTFMtU1JUUCkgZG9lcyBub3QgaGVscCBhdCBhbGwgKHdoZW4g dGhlIGNhbGwgc2VydmljZSBpcyBtYWxpY2lvdXMpLg0KDQoNCi1bczQuMy4yLjRdDQoNCkluIHRo ZSBzZWN1cmUgbWVkaWEgbW9kZSwgdGhlIGNhbGxpbmcgc2l0ZSBzaG91bGQgbm90IG9ubHkgYmUg Zm9yYmlkZGVuIHRvIHZpZXcgYW5kIG1vZGlmeSB0aGUgbWVkaWEuIEl0IHNob3VsZCBhbHNvIGJl IGZvcmJpZGRlbiB0byBzZW5kIGF1ZGlvIHRvIHRoZSBzcGVha2Vycy4gT3RoZXJ2aXNlIGl0IGNh biBzdGlsbCBpbmRpcmVjdGx5IG1vZGlmeSB0aGUgbWVkaWEuDQoNCg0KDQo0LjQuICBQcml2YWN5 IENvbnNpZGVyYXRpb25zDQoNCg0KLVtzNC40LjFdDQoNClNob3VsZCBtZW50aW9uIHRoYXQgdGhl cmUgaXMgYSB0cmFkZS1vZmYgYmV0d2VlbiByZXNldHRpbmcgRFRMUyBjZXJ0cyBhbmQga2V5IGNv bnRpbnVpdHkuDQoNCg0KDQpFZGl0b3JpYWxzOg0KDQoNCi0iV2ViVEMiDQoNCi0iV2VzdGVybGFu ZCIgLT4gIldlc3Rlcmx1bmQiDQoNCi0iQ05BTUVTIiAtPiAiQ05BTUVzIg0KDQotImltcGxlbWVu dGF0ZWQiDQoNCi0icmVmbHJlY3QiDQoNCi0ic29mdCBwaG9uZXMiIG9yICJzb2Z0cGhvbmVzIg0K DQotInhyZWYgdGFyZ2V0PSJSRkM2NDU0Ii8+Ig0KDQotRmlyc3Qgc2VudGVuY2UgaW4gNC4yLjIg aXMgZHVwbGljYXRlZA0KDQotIlVzZSBvciBSVENQIg0KDQotInNpdGUgbm90IHdvcmsgd2VsbCIN Cg0KDQoNCkpPSE4gTUFUVFNTT04NCk1TYyBFbmdpbmVlcmluZyBQaHlzaWNzLCBNU2MgQnVzaW5l c3MgQWRtaW5pc3RyYXRpb24gYW5kIEVjb25vbWljcw0KRXJpY3Nzb24gSUVURiBTZWN1cml0eSBD b29yZGluYXRvcg0KU2VuaW9yIFJlc2VhcmNoZXIsIFNlY3VyaXR5DQoNCkVyaWNzc29uIEFCDQpT ZWN1cml0eSBSZXNlYXJjaA0KRsOkcsO2Z2F0YW4gNg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dl ZGVuDQpQaG9uZSArNDYgMTAgNzEgNDMgNTAxDQpTTVMvTU1TICs0NiA3NiAxMSA1MyA1MDENCmpv aG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNv bT4NCnd3dy5lcmljc3Nvbi5jb208aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vPg0KDQoNCltodHRw Oi8vd3d3LmVyaWNzc29uLmNvbS9dPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tLz4NCg0KVGhpcyBD b21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVt YWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdHd3dy5lcmljc3Nvbi5jb20v ZW1haWxfZGlzY2xhaW1lcjxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVy Pg0KDQo= --_000_CF488C1C11409johnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <289331C105F5D443866792052E252FF0@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5 OiBNZW5sbzsiPkkgaGF2ZSByZXZpZXdlZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBmb3IgV2Vi UlRDIChkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS0wNik8L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAx M3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7 IGZvbnQtZmFtaWx5OiBNZW5sbzsiPlNlZW1zIHRvIGJlIGluIGdvb2Qgc2hhcGUuPC9wPg0KPHAg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsg bWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij5DaGVlcnM8L3A+DQo8cCBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+Sm9objwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTog TWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4 OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZv bnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87IG1pbi1o ZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6 ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LVtHZW5lcmFsXTwvcD4NCjxwIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij5UaGUgZHJh ZnQgc2hvdWxkIGRpc2N1c3MgdGhyZWF0cyB3aGVuIHRoZSB1c2VycyBiZWxvbmcgdG8gZGlmZmVy ZW50IGNhbGxpbmcgc2VydmljZXMuIFRoZXJlIGFyZSB0aGVuIHR3byBwb3RlbnRpYWxseSBtYWxp Y2lvdXMgY2FsbGluZyBzZXJ2aWNlcyBhcyB3ZWxsIGFzIHRoZSB0cmFuc3BvcnQgYmV0d2VlbiB0 aGVtLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZh bWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LVtHZW5lcmFs XTwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWls eTogTWVubG87Ij5UaGUgZHJhZnQgc2hvdWxkIG1ha2UgY2xlYXIgaG93IHRoZSB0aHJlYXRzLCBs ZXZlbHMgb2YgY29uc2VudCwgYW5kIGNocm9tZSBpbmRpY2F0aW9ucyBkaWZmZXIgYmV0d2VlbiBk YXRhIGNoYW5uZWxzIGFuZCBtZWRpYSBjaGFubmVscy4gT2J2aW91c2x5IGNvbnNlbnQgYW5kIGNo cm9tZSBpbmRpY2F0b3JzIGFyZSBuZWVkZWQgZm9yIGFjY2Vzc2luZw0KIG1pYyBhbmQgY2FtZXJh LiBSaWdodCBub3cgdGhlIGRyYWZ0IG1vc3RseSB0YWxrcyBhYm91dCBjb25zZW50IGFuZCBpbmRp Y2F0b3JzIGZvciBhICZxdW90O2NhbGwmcXVvdDsgYW5kIHNheXMgbm90aGluZyBhYm91dCBjYWxs ZXIgYW5kIGNhbGxlZSBjb25zZW50IGFuZCBjaHJvbWUgaW5kaWNhdG9ycyBmb3IgcHVyZSBkYXRh IGNoYW5uZWxzLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBm b250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LVtH ZW5lcmFsXTwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250 LWZhbWlseTogTWVubG87Ij5BIGRyYWZ0IGRpc2N1c3NpbmcgdGhyZWF0cyB0byBhIHVzZXItdG8t dXNlciBjb21tdW5pY2F0aW9uIHN5c3RlbSBzaG91bGQgcHJvYmFibHkgZGlzY3VzcyB1bnNvbGlj aXRlZCBjb21tdW5pY2F0aW9uIChpLmUuIFNQSVQsIFNQSU0pIGEgbGl0dGxlIGJpdCwgbm90IGp1 c3Qgd3JpdGluZyB0aGF0ICZxdW90O3ByYW5rIGNhbGxzJnF1b3Q7IGlzIG91dCBvZiBzY29wZS48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6 IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNw eDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBm b250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+My4m bmJzcDsgVGhlIEJyb3dzZXIgVGhyZWF0IE1vZGVsPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4 OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsi Pjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250 LWZhbWlseTogTWVubG87Ij4tW3MzXSAmcXVvdDtORVRXT1JLIEFUVEFDS0VSUywgd2hvIGFyZSBh YmxlIHRvIGNvbnRyb2wgeW91ciBuZXR3b3JrJnF1b3Q7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPlNob3VsZCBiZSAmcXVv dDt0aGUgbmV0d29yayZxdW90OyBvciAmcXVvdDtwYXJ0IG9mIHRoZSBuZXR3b3JrJnF1b3Q7PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBN ZW5sbzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBw eDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7 Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9u dC1mYW1pbHk6IE1lbmxvOyI+NC4xLiZuYnNwOyBBY2Nlc3MgdG8gTG9jYWwgRGV2aWNlczwvcD4N CjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVu bG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LVtzNC4xXSAmcXVvdDtJbiBl aXRoZXIgY2FzZSwgYWxsIHRoZSBicm93c2VyIGlzIGFibGUgdG8gZG8gaXMgdmVyaWZ5IGFuZCBj aGVjayBhdXRob3JpemF0aW9uIGZvciB3aG9ldmVyIGlzIGNvbnRyb2xsaW5nIHdoZXJlIHRoZSBt ZWRpYSBnb2VzLiZxdW90OzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAx MXB4OyBmb250LWZhbWlseTogTWVubG87Ij5TaG91bGQgbWVudGlvbiB0aGF0IHRoZSBicm93c2Vy IG1heSBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgbWVkaWEgZGVzdGluYXRpb24uPC9wPg0K PHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5s bzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsg Zm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij4tW3M0LjFdICZxdW90O0J5IGNv bnRyYXN0LCBjb25zZW50IHRvIHNlbmQgbmV0d29yayB0cmFmZmljIGlzIGFib3V0IHByZXZlbnRp bmcgdGhlIHVzZXIncyBicm93c2VyIGZyb20gYmVpbmcgdXNlZCB0byBhdHRhY2sgaXRzIGxvY2Fs IG5ldHdvcmsuJnF1b3Q7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDEx cHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPiZuYnNwOyZuYnNwOyBJdCdzIGFsc28gYWJvdXQgRG9T ICh3aGljaCBpcyBtZW50aW9uZWQgaW4gdGhlIGJlZ2lubmluZykgYW5kIHByb3RlY3Rpbmcgb3Ro ZXIgbmV0d29ya3MgdGhhdCBtYXkgaGF2ZSBmaXJld2FsbHMgYmxvY2tpbmcgdHJhZmZpYyBmcm9t IERyLiBFdmlsIGJ1dCBhY2NlcHRpbmcgdHJhZmZpYyBmcm9tIHlvdS48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVp Z2h0OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPi1bczQuMS4yLjEsIDQuMS4yLjJdPC9wPg0KPHAg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsi PjQuMS4yLjEgJnF1b3Q7SWYgSSBncmFudCBwZXJtaXNzaW9uIHRvIGNhbGxpbmcgc2VydmljZSBB IHRvIG1ha2UgY2FsbHMgb24gbXkgYmVoYWxmLCB0aGVuIEkgYW0gaW1wbGljaXRseSBncmFudGlu ZyBpdCBwZXJtaXNzaW9uIHRvIGJ1ZyBteSBjb21wdXRlciB3aGVuZXZlciBpdCB3YW50cy4mcXVv dDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1p bHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPjQuMS4yLjIgJnF1 b3Q7Tm90ZSBhbHNvIHRoYXQgdGhlIHVzZXIgaW50ZXJmYWNlIGNocm9tZSBtdXN0IGNsZWFybHkg ZGlzcGxheSBlbGVtZW50cyBzaG93aW5nIHRoYXQgdGhlIGNhbGwgaXMgY29udGludWluZyBpbiBv cmRlciB0byBhdm9pZCBhdHRhY2tzIHdoZXJlIHRoZSBjYWxsaW5nIHNpdGUganVzdCBsZWF2ZXMg aXQgdXAgaW5kZWZpbml0ZWx5DQogYnV0IHNob3dzIGEgV2ViIFVJIHRoYXQgaW1wbGllcyBvdGhl cndpc2UuJnF1b3Q7PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7 IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij5U aGUgdGV4dCBvbiBjaHJvbWUgaW5kaWNhdGlvbnMgaXMgYWxzbyBoaWdobHkgcmVsZXZhbnQgZm9y IDQuMS4yLjEsIEV2ZW4gaWYgdGhlIHVzZXIgaGF2ZSBncmFudGVkIGxvbmcgdGVybSBjb25zZW50 LCB0aGUgYnJvd3NlciBzaG91bGQgc3RpbGwgc2hvdyB3aGVuIGEgc2l0ZSBhY2Nlc3NlcyBtaWMg YW5kIGNhbWVyYS48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsg Zm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWlu LWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1z aXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij40LjIuJm5ic3A7IENvbW11bmljYXRpb25z IENvbnNlbnQgVmVyaWZpY2F0aW9uPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTog TWVubG87Ij4tW3M0LjIuMl0gJnF1b3Q7VURQIG92ZXIgRFRMUyZxdW90OzwvcD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij5JcyB0 aGlzIHVzZWQgYW55d2hlcmUgb3IganVzdCBhIHRoZW9yZXRpY2FsIGV4YW1wbGU/PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsg bWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+ DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1p bHk6IE1lbmxvOyI+NC4zLiZuYnNwOyBDb21tdW5pY2F0aW9ucyBTZWN1cml0eTwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87IG1p bi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQt c2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LVtzNC4zXSAmcXVvdDtzZWN1cmUgYWdh aW5zdCBib3RoIG1lc3NhZ2UgcmVjb3ZlcnkgYW5kIG1lc3NhZ2UgbW9kaWZpY2F0aW9uLiZxdW90 OzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWls eTogTWVubG87Ij5BZGQgcmVwbGF5PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTog TWVubG87Ij4tW3M0LjNdICZxdW90O3RoZSBwZWVyJ3MgaWRlbnRpdHkgaW5mb3JtYXRpb24sIHdo aWNoLCBhZnRlciBhbGwsIGlzIG9ubHkgbWVhbmluZ2Z1bCBpbiB0aGUgY29udGV4dCBvZiBzb21l IGNhbGxpbmcgc2VydmljZS4mcXVvdDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQt c2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+Tm90IGlmIGF1dGhlbnRpY2F0ZWQgdmlh IElkUCBvciBQS0kuPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7 IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij4t W3M0LjMsIDQuMy4xLCBhbmQgNC4zLjJdPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250 LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPkkgdGhpbmsgdGhlIGRpdmlzaW9uIGlu ICZxdW90O3VuY29tcHJvbWlzZWQgZHVyaW5nIGNhbGwsIGxhdGVyIGNvbXByb21pc2VkJnF1b3Q7 IGFuZCAmcXVvdDthY3RpdmUmcXVvdDsgaXMgYSBiYWQgaWRlYS4gSSB3b3VsZCBzdHJvbmdseSBy ZWNvbW1lbmQgcmVzdHJ1Y3R1cmluZyBzZWN0aW9uIDQuMywgNC4zLjEsIGFuZCA0LjMuMiB0byBm b2xsb3cgdGhlIGRlZmluaXRpb25zDQogb2YgJnF1b3Q7cGFzc2l2ZSBhdHRhY2tzJnF1b3Q7IGFu ZCAmcXVvdDthY3RpdmUgYXR0YWNrcyZxdW90OyBpbiBSRkMgMzU1Mi4gVGhlIHRleHQgY291bGQg dGhlbiBhbHNvOjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBm b250LWZhbWlseTogTWVubG87Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSBEaWZmZXJl bnRpYXRlIGJldHdlZW4gYXR0YWNrcyBvbiB0aGUgc2lnbmFsaW5nIHBsYW5lIGFuZCB0aGUgdXNl ciBwbGFuZSwgYW5kIGNsYXJpZnkgd2hlcmUgUEZTIGlzIG5lZWRlZC48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0gRGlmZmVyZW50aWF0ZSBhY3RpdmUgYXR0YWNrcyBvbiB0 aGUga2V5IG1hbmFnZW1lbnQgdnMuIGFjdGl2ZSBhdHRhY2tzIGJ5IHNlbmRpbmcgdHJhZmZpYyB0 byBhIHJlY29yZGluZyBzZXJ2aWNlLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1z aXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgLSBBbHNvIGNvbnNpZGVyIHBhc3NpdmUgYW5kIGFjdGl2ZSBhdHRhY2tzIGZyb20gb3RoZXIg dGhhbiB0aGUgY2FsbGluZyBzZXJ2aWNlLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLSBNYWtlIGl0IGNsZWFyIHRoYXQgKGluIG1vc3QgY2FzZXMpIHlvdSBuZWVkIGFjY2Vz cyB0byBib3RoIGNvbnRyb2wgYW5kIHVzZXIgcGxhbmUgZGF0YS48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0 OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDEx cHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPi1bczQuM10gJnF1b3Q7VGhlIGNhbGxpbmcgc2Vydmlj ZSBpcyBjb21wcm9taXNlZCBkdXJpbmcgdGhlIGNhbGwgaXQgd2lzaGVzIHRvIGF0dGFjayAob2Z0 ZW4gY2FsbGVkIGFuICZxdW90O2FjdGl2ZSBhdHRhY2smcXVvdDspLiZxdW90OzwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij5X aGlsZSAmcXVvdDthY3RpdmUgYXR0YWNrJnF1b3Q7IGltcGxpZXMgJnF1b3Q7Y29tcHJvbWlzZWQg ZHVyaW5nIGNhbGwmcXVvdDsgdGhlIG9wcG9zaXRlIGlzIG5vdCB0cnVlIGFzIGEgZHVyaW5nLWNh bGwgYXR0YWNrIGNhbiB2ZXJ5IHdlbGwgYmUgcGFzc2l2ZS48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAx M3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7 IGZvbnQtZmFtaWx5OiBNZW5sbzsiPi1bczQuM10gJnF1b3Q7VGhlIGNhbGxpbmcgc2VydmljZSBp cyBub24tbWFsaWNpb3VzIGR1cmluZyBhIGNhbGwgYnV0IHN1YnNlcXVlbnRseSBpcyBjb21wcm9t aXNlZCBhbmQgd2lzaGVzIHRvIGF0dGFjayBhbiBvbGRlciBjYWxsIChvZnRlbiBjYWxsZWQgYSAm cXVvdDtwYXNzaXZlIGF0dGFjayZxdW90OykmcXVvdDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+U2ltaWxhcmx5IGFzIHRo ZSBhYm92ZSBjb21tZW50ICZxdW90O3Bhc3NpdmUgYXR0YWNrJnF1b3Q7IGRvZXMgbm90IGVxdWF0 ZSB0aGUgY2FsbGluZyBzZXJ2aWNlIGJlaW5nIG5vbi1tYWxpY2lvdXMgZHVyaW5nIHRoZSBjYWxs LjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWls eTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LVtzNC4zXSAmcXVv dDtXZSBkaXNjdXNzIHNvbWUgcG90ZW50aWFsIGFwcHJvYWNoZXMgYW5kIHdoeSB0aGV5IGFyZSBs aWtlbHkgdG8gYmUgaW1wcmFjdGljYWwgaW4gU2VjdGlvbiA0LjMuMi4mcXVvdDs8L3A+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+ U2VjdGlvbiA0LjMuMiBkb2VzIG5vdCBkaXNjdXNzICZxdW90O3doeSB0aGV5IGFyZSBsaWtlbHkg dG8gYmUgaW1wcmFjdGljYWwmcXVvdDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQt c2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+PGJyPg0K PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5 OiBNZW5sbzsiPi1bczQuM108L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTog MTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+RmFpbHMgdG8gY2xlYXJseSBkZXNjcmliZSB0aGF0 IHRoZSBhdHRhY2tlciBuZWVkcyBhY2Nlc3MgdG8gdGhlIG1lZGlhIGNoYW5uZWwgYW5kIGRlc2Ny aWJlIGhvdyB0aGUgYXR0YWNrZXIgZ2V0cyB0aGF0LiBJZiB0aGUgY2FsbGluZyBzZXJ2aWNlIGlz IGNvbXByb21pc2VkIGl0IGNhbiBqdXN0IGluY2x1ZGUgaXRzZWxmIGl0IHRoZSBtZWRpYQ0KIHBh dGgsIGJ1dCBvdGhlcndpc2UgdGhlIGF0dGFja2VyIG11c3QgaW50ZXJjZXB0IHRoZSBtZWRpYSBw YXRoLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZh bWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LVtzNC4zXSAm cXVvdDtIb3dldmVyLCBpdCBpcyBleHRyZW1lbHkgZGlmZmljdWx0JnF1b3Q7PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPldl bGwgdGhlb3JldGljYWxseSBpdCdzIHNpbXBsZSAoYXV0aGVudGljYXRlKSwgbWF5YmUgZXhwbGFp biB0aGF0IHRoZSBkaWZmaWN1bHQgcGFydCBpcyBkZXBsb3ltZW50IGluIHRoZSBXZWJSVEMgY2Fz ZS48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1p bHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPi1bczQuMy4xXTwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTog TWVubG87Ij5TaG91bGQgbWVudGlvbiB0aGF0IHRoZSByZXRyb3NwZWN0aXZlIGF0dGFjayByZXF1 aXJlcyB0aGF0IHRoZSBjYWxsaW5nIHNlcnZpY2UgaGFzIGVpdGhlciBzYXZlZCBhbGwgdGhlIG1l ZGlhIChub3QgdGhhdCBsaWtlbHkpIG9yIHRoYXQgdGhlIGF0dGFja2VyIGhhcyBjYXB0dXJlZCBp dCBiZWZvcmVoYW5kLjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4 OyBmb250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+ LVtzNC4zLjFdICZxdW90O2luIFNERVMgW1JGQzQ1NjhdKSwgdGhlbiByZXRyb3NwZWN0aXZlIGF0 dGFjayBpcyB0cml2aWFsLiZxdW90OzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1z aXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij5JIHdvdWxkIHJlbW92ZSB0cml2aWFsLiBJ IGFncmVlIHRoYXQgaWYgeW91IGhhdmUgMS4gYmVlbiBhYmxlIHRvIGNhcHR1cmUgdGhlIGRhdGEg YnkgaW50ZXJjZXB0aW5nIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlJm5ic3A7IHBlZXJz LCAyLiBiZWVuIGFibGUgdG8gY29tcHJvbWlzZSB0aGUgY2FsbGluZyBzZXJ2aWNlLCBhbmQgMy4g YmVlbg0KIGFibGUgdG8gcmVhZCB0aGUga2V5IGZyb20gdGhlIGxvZ3MsIHRoZW4gZGVjcnlwdGlu ZyBpcyB0cml2aWFsLCBidXQgMSwyLDMgaXMgbm90IHRyaXZpYWwuPC9wPg0KPHAgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdo dDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAx MXB4OyBmb250LWZhbWlseTogTWVubG87Ij4tW3M0LjMuMl08L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+U2hvdWxkIG1lbnRp b24gdGhhdCBhbnkgZmluZ2VycHJpbnQgbWVjaGFuaXNtIHNlbnQgdmlhIHRoZSBjYWxsaW5nIHNl cnZpY2UgKHN1Y2ggYXMgdGhlIG9uZSBpbiBEVExTLVNSVFApIGRvZXMgbm90IGhlbHAgYXQgYWxs ICh3aGVuIHRoZSBjYWxsIHNlcnZpY2UgaXMgbWFsaWNpb3VzKS48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0 OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDEx cHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPi1bczQuMy4yLjRdPC9wPg0KPHAgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPkluIHRoZSBzZWN1 cmUgbWVkaWEgbW9kZSwgdGhlIGNhbGxpbmcgc2l0ZSBzaG91bGQgbm90IG9ubHkgYmUgZm9yYmlk ZGVuIHRvIHZpZXcgYW5kIG1vZGlmeSB0aGUgbWVkaWEuIEl0IHNob3VsZCBhbHNvIGJlIGZvcmJp ZGRlbiB0byBzZW5kIGF1ZGlvIHRvIHRoZSBzcGVha2Vycy4gT3RoZXJ2aXNlIGl0IGNhbiBzdGls bCBpbmRpcmVjdGx5IG1vZGlmeQ0KIHRoZSBtZWRpYS48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4 OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZv bnQtZmFtaWx5OiBNZW5sbzsgbWluLWhlaWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij40LjQu Jm5ic3A7IFByaXZhY3kgQ29uc2lkZXJhdGlvbnM8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4taGVpZ2h0OiAxM3B4OyI+ PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQt ZmFtaWx5OiBNZW5sbzsiPi1bczQuNC4xXTwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij5TaG91bGQgbWVudGlvbiB0aGF0IHRo ZXJlIGlzIGEgdHJhZGUtb2ZmIGJldHdlZW4gcmVzZXR0aW5nIERUTFMgY2VydHMgYW5kIGtleSBj b250aW51aXR5LjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBm b250LWZhbWlseTogTWVubG87IG1pbi1oZWlnaHQ6IDEzcHg7Ij48YnI+DQo8L3A+DQo8cCBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyBtaW4t aGVpZ2h0OiAxM3B4OyI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsiPkVkaXRvcmlhbHM6PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGZvbnQtZmFtaWx5OiBNZW5sbzsgbWluLWhl aWdodDogMTNweDsiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXpl OiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij4tJnF1b3Q7V2ViVEMmcXVvdDs8L3A+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+ LSZxdW90O1dlc3RlcmxhbmQmcXVvdDsgLSZndDsgJnF1b3Q7V2VzdGVybHVuZCZxdW90OzwvcD4N CjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVu bG87Ij4tJnF1b3Q7Q05BTUVTJnF1b3Q7IC0mZ3Q7ICZxdW90O0NOQU1FcyZxdW90OzwvcD4NCjxw IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87 Ij4tJnF1b3Q7aW1wbGVtZW50YXRlZCZxdW90OzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsg Zm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTogTWVubG87Ij4tJnF1b3Q7cmVmbHJlY3QmcXVv dDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1p bHk6IE1lbmxvOyI+LSZxdW90O3NvZnQgcGhvbmVzJnF1b3Q7IG9yICZxdW90O3NvZnRwaG9uZXMm cXVvdDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1m YW1pbHk6IE1lbmxvOyI+LSZxdW90O3hyZWYgdGFyZ2V0PSZxdW90O1JGQzY0NTQmcXVvdDsvJmd0 OyZxdW90OzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250 LWZhbWlseTogTWVubG87Ij4tRmlyc3Qgc2VudGVuY2UgaW4gNC4yLjIgaXMgZHVwbGljYXRlZDwv cD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4OyBmb250LWZhbWlseTog TWVubG87Ij4tJnF1b3Q7VXNlIG9yIFJUQ1AmcXVvdDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1mYW1pbHk6IE1lbmxvOyI+LSZxdW90O3NpdGUgbm90 IHdvcmsgd2VsbCZxdW90OzwvcD4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgbWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMTJwdDsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsiPjxpbWcgd2lkdGg9IjI1NSIgaGVpZ2h0PSIzIiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNp ZDoyRkFBNjVFQi0xOEEzLTQ3QTEtODdCRC0zNTI1RDA0N0Q0MTUiIGFsdD0ibGluZSIgdHlwZT0i aW1hZ2UvcG5nIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7Ij5KT0hOIE1BVFRTU09OPG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IG1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsi Pk1TYyBFbmdpbmVlcmluZyBQaHlzaWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24gYW5k IEVjb25vbWljczwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwg NTEpOyI+PGZvbnQgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzcHg7Ij48 Yj5Fcmljc3NvbiBJRVRGIFNlY3VyaXR5IENvb3JkaW5hdG9yPC9iPjwvc3Bhbj48L2ZvbnQ+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIiBzaXplPSIzIj4mbmJzcDs8L2ZvbnQ+PC9zcGFu PjxiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7 Ij48YnI+DQpTZW5pb3IgUmVzZWFyY2hlciwgU2VjdXJpdHk8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEs IDUxKTsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsiPkVyaWNzc29u IEFCPGJyPg0KU2VjdXJpdHkgUmVzZWFyY2g8YnI+DQpGw6Ryw7ZnYXRhbiA2PGJyPg0KU0UtMTY0 IDgwIFN0b2NraG9sbSwgU3dlZGVuPGJyPg0KUGhvbmUgJiM0Mzs0NiAxMCA3MSA0MyA1MDE8YnI+ DQpTTVMvTU1TICYjNDM7NDYgNzYgMTEgNTMgNTAxPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmpvaG4u bWF0dHNzb25AZXJpY3Nzb24uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiPjxzcGFuIHN0eWxl PSJjb2xvcjogYmx1ZTsiPmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiA5cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig1MSwgNTEs IDUxKTsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tLyIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7Ij48c3BhbiBzdHlsZT0iY29sb3I6IGJsdWU7Ij53d3cuZXJpY3Nzb24uY29tPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPjxicj4NCjxi cj4NCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8iIHRhcmdldD0iX2Js YW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsg Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI1MDAiIGhlaWdodD0iODEiIGlkPSJf eDAwMDBfaTEwMjUiIHNyYz0iY2lkOkZENzdFNjVGLTI5QzktNDkyQi1CRkE2LThFRjQ5QzcwN0ND MiIgYWx0PSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8iIHR5cGU9ImltYWdlL3BuZyI+PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgbWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOHB0OyBmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7Ij5UaGlzIENvbW11 bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwg b24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0DQogYXQ8YSBocmVmPSJodHRwOi8vd3d3 LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIiB0aXRsZT0iaHR0cDovL3d3dy5lcmljc3Nv bi5jb20vZW1haWxfZGlzY2xhaW1lciIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7Ij48c3BhbiBzdHls ZT0iY29sb3I6IGJsdWU7Ij53d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8L3NwYW4+ PC9hPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_CF488C1C11409johnmattssonericssoncom_-- --_005_CF488C1C11409johnmattssonericssoncom_ Content-Type: image/png; name="13DEFB94-F735-49B0-8196-BDB5C9017A32[2].png" Content-Description: 13DEFB94-F735-49B0-8196-BDB5C9017A32[2].png Content-Disposition: inline; filename="13DEFB94-F735-49B0-8196-BDB5C9017A32[2].png"; size=2991; creation-date="Fri, 14 Mar 2014 09:35:37 GMT"; modification-date="Fri, 14 Mar 2014 09:35:37 GMT" Content-ID: <2FAA65EB-18A3-47A1-87BD-3525D047D415> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAP8AAAADCAIAAADTOk7/AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAABKUlEQVRI De1TMU4DQQycu5yokNKglEhIfIEf8JEoHSU/gAfkATQ8gMcgGigR0CYSDVRhzdheL7sogT6602o1 6xmPvb67TkQAvKzu7l+v1x9PSbovWwm9A+4R1EhCFhjbB2UapUwTJqHPwU1lpYlhZSaRWAU3stOf KYIeXNLpnjFBOXaQiHswH02guChbk8bzT5NGSZNdnqViCEonohMBX4HepwIW/J/6lV5nbaWsEMs1 zp61lSqNJUCSZQEpWavoRSa2BkCB7wEG0UsyPoCySmBHshPOS1CxJoMoRf1Plh4ps3KuL7VUVumb uLdkrH7hB2qrAj7HNxfTxTkBO9Tn4e3q/fPR8biPE9jjCfAfeL689Qvmr/90Nj86PNvjO49XGydQ JnCynDv+BsiTWPQxCGmXAAAAAElFTkSuQmCC --_005_CF488C1C11409johnmattssonericssoncom_ Content-Type: image/png; name="D377E800-0A1A-43D3-AF5E-165F697789B5[2].png" Content-Description: D377E800-0A1A-43D3-AF5E-165F697789B5[2].png Content-Disposition: inline; filename="D377E800-0A1A-43D3-AF5E-165F697789B5[2].png"; size=5392; creation-date="Fri, 14 Mar 2014 09:35:37 GMT"; modification-date="Fri, 14 Mar 2014 09:35:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAfQAAABRCAIAAACrEsM0AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAKiklEQVR4 Ae2dPWwURxiGA0oDCQSUVEFA6OwKE4gLBATrnEDHXZtItpFIEWEJJ1RGQoCQ7Cr8JEYpEsk2Rdo7 l4l8AgJKARicBrvjJ6FKpPAnUpLXfNHcaPe8d2u45Zh9rNNpdvab2ZlnrHe/+3ZmdtmzZ8/e4A8C EIAABMIisDys7tAbCEAAAhBYIIC4838AAQhAIEACiHuAg0qXIAABCCDu/A9AAAIQCJAA4h7goNIl CEAAAog7/wMQgAAEAiSAuAc4qHQJAhCAAOLO/wAEIACBAAkg7gEOKl2CAAQg8ObrguDO/b8r1ZkH j56qwbu7O3d3d7wuLaedEIAABLInsKz9tx+YKF+uVGenqtd9OgOlneMjB/wc0hCAAAQg4Ai0r7hf vDo/WblSmZ558HjBW4//Sdwl8fF8ciAAAQhAoO3EXeGXs+d/UQRGieThUWTmwuRwsg1nIQABCOST QLvE3B88/nei/Otk+crs/L18jgS9hgAEIPASCbx6ca8bUn+JPaQqCEAAAjkk8MrEvWFIveFg9Bd3 NLTBAAIQgEA+CWQt7s2H1JPHY6hvD09TkxFxFgIQyDOBjMT9ZYXUP1j3XrGw9VDfp0rkedjoOwQg AIFkAlmIu56RlgbPNpz9ktxQ+en7Cluk7MlmnIUABCAAARHIYirkltLRJc+B6erYID+92LttzaoV DBgEIAABCDRJoOWeu2R9CcpO+KXJ8cMMAhCAQF0CLRd32w2m7rXjmWtWrSz2btU0mPjWMbpDPJ8F f/edVW8XC108TY3TIwcCEICAI9BycXdXSk5IzaXp8fCLIvVarao1q37IXvvMaGcClqcmI+UsBCCQ ZwJZxNw39R72pdnHrfDLQki9sDUy+0WzayrTCwqu6fC+vZ8+PfyZJkT6OaQhAAEIQMAIZCHuiqj0 9I36+39Z+EWyruelkZGQnz5Vvallq5H8+CF7y8SZkAMBCEDACGQRlpGC366e0tYxv8//IVnf3LE+ HjG3kLo03b8HMEgQgAAEILA0AlmIu1qmiYx1QygWUl/afmF6srq0PlMKAhCAQPAEMhL3CEcLqcdf wRExSz4cKG1PNuAsBCAAgdwSyFrcLaSe8AqOZkZCsR09TWW1ajOssIEABPJJICNxV/ilyVdwJA+D wvf9pR0DpV0sWE0GxVkIQCDnBLIQ9/hsmbTQWbCalhj2EIBAzglkMRUyYZ57Q/rsF9YQEQYQgAAE 4gRa7rlrFdJiK5jirXE5iy1YdQYkIAABCEAggUDLxT3h2vFTCr9oEwJ565EFq7K0t/E9fPxE6Y8/ 6hjq30vYPQ6QHAhAAAJGoOXivmb1yoask/cLW3gSOz3jL27Sr4Gp6o0L54+g7w3ZYgABCOSTQBYx 957+0cW2iNlX2FZ3i0dFcuSqa2+ZhJDOsYPF44OlfA4bvYYABCCQTKDlnrsuXx4b6ukb0ZwZ1xRF XRL2C5Or7hu7UpHEpWuL7ikWseQQAhCAQN4IZCHuCp7cLJ/U8qXZuQV9147tdfcLmyj/pr188zYA 9BcCEIBAKwhkIe7Wbi0oja8plYceD6k32U/2lmkSFGYQgEAOCWQn7j7cZkLqvn3d9FDfJ3XzyYQA BCAAgUzF3fYLazKknjA2Ctlrb5n4q/gSinAKAhCAQK4IZCTuCr8cH5t68ZC6ZtdoM8h4eCdXY0Zn IQABCDQkkIW461FqafDbhk1JMNAD2IXZNb3bmNieQIlTEIAABByBLOa5r+3+0l+C5K7dMKHwi5x0 yXp8wWrDshhAAAIQyDOBlnvuWr6UVtltweq+whbCL3n+16TvEIDAixBoubinahz7haXChTEEIACB xQi0XNyb2VtGUZfF9gtbrN3kQwACEIBAAoGWi7uehcofr7u3jIVfFFKPL1hNaDGnIAABCECgIYEs Hqhqentp8Iyv74vtF9awuRhAAAIQgEAzBLIQd2uHprrPzt1VlKarYyOzX5oZG2wgAAEILJlAduK+ 5CZSEAIQgAAE0hJYnrYA9hCAAAQg0P4EEPf2HyNaCAEIQCA1AcQ9NTIKQAACEGh/Aoh7+48RLYQA BCCQmgDinhoZBSAAAQi0PwHEvf3HiBZCAAIQSE0AcU+NjAIQgAAE2p/Ay9l+QAuUHjx66vc2+TVJ 9komvWxPRbSgqatzo+1A4OdrudPu7s7kfBVXJRevzllVdV+97beKNAQgAIGcEEixiGlZZ38cyoXJ Yel4T/+ov7uAzLRvjN6EN1DaqbQVNEsdHh8rnzhXiVT1bG5Sd4ievlF/f2DVrFIT5ctfjf4Uz1cN yj9z/me/Kt0Mxke/sFuCa7C7tLXz2MHi8cGSX4o0BCAAgcAIpPbcpZv+Ro9+2kcjLd5/5Mf4u5N8 OZbPro9cfsm6ypYGz5qC2yXcTwGn7JF83SScsus2MDt3T8VV1f7hH26WT/qNOXGuvLt72M8hDQEI QCBsAqnF/fTw5wkhFzngCq309I2YXmszGd9YwRMnx/Lrh/r2GFwLqti3XH4nzarKvetDyu7nq6Be tG3FrSoZbyp8bfouZ99+NJiBKtHHb4nl8w0BCEAgVAKpH6jOzt81rbTvCJfnmbecTEf0VMFxs5dS O2VXju0jJllXWuq8qfewvHXdHvTGVIXjrYgOLV+VK18XMjdfpawqZTpBtwZYQcuU826HfEMAAhDI A4HUnrtk1+ciV90/VFDbDqW546MH/FNKO83dV/gwckqHcsAVyTEzOfj6SJfHRw5Iu83fV3HLV9Bc z1qthq7ODa6qjevetfSla/MuU8Zy5HUz0LfLJAEBCEAgbAKpxV2Cu/H9/zU0AY3c6jWr3ooYuAD9 7PyfkVM6VM3y0xVsqUzPmFcuOdarPCT6uhlMVq64fD2PNWdfpVxo3k9rV2FXvyyl7yril3JnSUAA AhAIkkDqsIzeh6epJu4TgSJHXlpsmZLjyFnnbk9Vr1tQPmKgcI1c9X+ufq+3edgp026Fd5R/u3pK Bpbv3SfuuR8EU9Ubdta58HY41L9XvyRkpoeulsM3BCAAgbAJpPbcJdkudC40credE22kBkq7LHQj R1uK7OOTNEumFSFR5pbSUfcjQHXenv6mOPjd2tUrNnes19lLV2+5ggq1FwtbpdcSeqfj8s1V3CIt mmYjB79SnbUbhnRcbXDFlVA4Xgby3O0HgX+KNAQgAIEgCaQW90jkWs54RNylpPK75ZtLSWUsCfbB lceG3Cv3/Kqk+BL0iPjqTqCPhdr9SuyOonk7mo0jQdfHgvWysVi/2uDbKy3nXQGfSP0RGw4hAAEI BEMghbgrch3vtim7H+OWzUBp+8PHT5QwR9sKmqVkV0uKKtWZqerNO/f/sgrtxXtyrv0HoYqzmwOu B6qaouMurbiQ3TBUlSZH6g4hn90up3pUibvZ+A2WcXnskP3mcNEhVycJCEAAAoERSLFCNbCe0x0I QAACARNI/UA1YBZ0DQIQgEAwBBD3YIaSjkAAAhCoEUDcayxIQQACEAiGAOIezFDSEQhAAAI1Aoh7 jQUpCEAAAsEQQNyDGUo6AgEIQKBGAHGvsSAFAQhAIBgCiHswQ0lHIAABCNQIIO41FqQgAAEIBEMA cQ9mKOkIBCAAgRqB/wAoLQQNWSy3+QAAAABJRU5ErkJggg== --_005_CF488C1C11409johnmattssonericssoncom_-- From nobody Fri Mar 14 04:26:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E681A011B for ; Fri, 14 Mar 2014 04:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfs17oJBJ-S3 for ; Fri, 14 Mar 2014 04:26:00 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0245F1A0108 for ; Fri, 14 Mar 2014 04:25:59 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-e5-5322e7405be8 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 4D.B3.04249.047E2235; Fri, 14 Mar 2014 12:25:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 12:25:52 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Justin Uberti , Bernard Aboba Thread-Topic: [rtcweb] Should we reference the pause/resume I-D? Thread-Index: Ac8+HSfEqf9sT+k2TCiwilJvB9C34g== Date: Fri, 14 Mar 2014 11:25:51 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF8C0FD@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja7Dc6Vgg/Z9qhYb9v1nttg6Vchi 7b92dgdmj52z7rJ7LNhU6rFkyU+mAOYoLpuU1JzMstQifbsEroym6y3sBb8VKqbvrGhgbJTs YuTkkBAwkTh9egYrhC0mceHeerYuRi4OIYEjjBLHr+5mhnCWMEqcuLiIGaSKTSBQYuu+BWwg tgiQfb11PwuIzSygLnFn8Tl2EFtYwF7iV/sddogaB4ldHU+g6vUkTt64zdjFyMHBIqAqsftJ IUiYV8BX4ld3F9Ti24wSfW8/g+1iBLro+6k1TBDzxSVuPZnPBHGpgMSSPeeZIWxRiZeP/0F9 oCTxY8MlqHv0JG5MncIGYWtLLFv4mhlimaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyipGj OLU4KTfdyGATIzA6Dm75bbGD8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9i ZOLglGpgZLv8X0rnYXjzYiGR+iUHvu/S4zjkmuRhdoG7LkehXqliDt8b3t8ZLMdVjF7/D/4b nS2tfrDgSpjP5o/CDMLhO0Uq7h+urrlxZ3tFs43LAk7dd/cnPO5KFTGrPT3nzoSa+lu7nkxV uhx9fYb3k4WdBkp/+IyjXhudnb3d4IHr1VerJvd8dl3np8RSnJFoqMVcVJwIAMmFKOhcAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/W28MobNZgRTNRrV6h6Ad-rNURYQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 14 Mar 2014 11:26:02 -0000 On 2014-03-12 21:56, Justin Uberti wrote:=0A= > Agreed.=0A= =0A= I may well be that the pause/resume doc will not be ready in time, so it = =0A= from that aspect is a bad idea. What about just stating that TMMBN/TMMBR = =0A= 0 meaning pause should be supported?=0A= =0A= > Aren't there also patent declarations against this doc from=0A= > multiple holders?=0A= =0A= I've not looked into that, but I deliberately chose to propose the "old" = =0A= TMMBN 0 way to signal that is mentioned in [1] (and not any of the "new" = =0A= signaling in [1]).=0A= =0A= >=0A= > While SDP will likely be removed from the API in the future, the=0A= > replacement would be a app-specific message sent over websockets, which= =0A= > seems like it would work just fine.=0A= =0A= s/would/could/: I don't think this has been discussed or agreed (and =0A= websocket is of course just an example).=0A= =0A= I think it is worthwhile to push this kind of signaling into the media =0A= plane if possible. For example, this would enable the UA to save =0A= transmission/battery even if the app is badly written.=0A= =0A= As an example: if a MST sent over a PC is not used in any way at the =0A= receiving end, the receiving end UA could signal TMMBR 0 to tell the =0A= sending UA to not send. Sure, the receiving UA could also fire a =0A= "negotiationneeded" event, but maybe the app doesn't listen.=0A= =0A= >=0A= >=0A= > On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba > wrote:=0A= >=0A= > While I do like the pause/resume draft, having core RTCWEB WG=0A= > documents (such as RTP Usage) depend on it seems like a bit of a=0A= > stretch. After all, the document was only adopted last week, and it= =0A= > is a rare IETF WG document that can go from a -00 WG draft to=0A= > publication as an RFC in under a year.=0A= >=0A= >=0A= > On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > Hi,=0A= >=0A= > at the IETF last week there was consensus in the AVTEXT WG=0A= > meeting to=0A= > adopt the pause/resume draft [1] as a WG draft.=0A= >=0A= > In rtcweb/webrtc we're have the situation that we're discussing s= o=0A= > called "doo-hickeys" as an API surface where the web app=0A= > (amongst other=0A= > things) can pause and resume the sending of a track. This can=0A= > be signaled with the direction attribute and a SDP O/A exchange= =0A= > (and the=0A= > app pausing/resuming sending of a track would presumably lead to = a=0A= > "negotiationneeded" event being fired).=0A= >=0A= > But I think we should in addition require the browser to signal i= t=0A= > according to one of the methods in [1] (e.g. TMMBN =3D 0), and al= so=0A= > understand that signaling (a browser receiving TMMBN =3D 0 must= =0A= > know that=0A= > the other end-point will pause sending).=0A= >=0A= > My argument is that we know that many dislike SDP in rtcweb, and = a=0A= > likely development is that it will be removed in a later version.= My=0A= > speculation is that signaling as outlined in [1] will then be=0A= > used for=0A= > pause/resume. If we support this from the beginning earlier=0A= > implementations could more easily interop with those later versio= ns.=0A= >=0A= >=0A= > Stefan=0A= >=0A= > [1]=0A= > https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-paus= e-05.txt=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= =0A= From nobody Fri Mar 14 05:32:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105421A00B1 for ; Fri, 14 Mar 2014 05:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JanTpep4WIG0 for ; Fri, 14 Mar 2014 05:32:43 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EECCC1A0133 for ; Fri, 14 Mar 2014 05:32:41 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so2048472wgh.15 for ; Fri, 14 Mar 2014 05:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H28c7rjIHPIVFRP99Rwp+nUdL9i0E5nRh8EH5A5uZAk=; b=gqUHaAR05DQCJvQxj0YfYq7+oHjRVbJoR5h26n4q9MJZDWznY6ZWvecI1nwFVA2Wk1 DO7SQKLCVZI9NnyHk6H5SEl9OaKR6zY/SJI+iVpMw9uIYRFI/b7R2GgrZQCfz+nMYF/G 7E0TJdSQUXUXHZUyg4JV9B/BrLsWW3RRTfCX2DzlkmMhrvc0nWJp+LQ/lTlMhTSdwLY4 v/VPmHJtU5H/l9mfCSRypxS6nY0YFoRnVt+KhPWq0xfF3C8NGnpKpdGv33+KP991wR7U b6Xt5UZ7FwuqJXlZtiL6TGFPFeyHQH8bws9kpIM0YzEitF9OrPfExfW8eoY0OT+sDho/ GKXw== MIME-Version: 1.0 X-Received: by 10.180.189.169 with SMTP id gj9mr6005761wic.17.1394800354730; Fri, 14 Mar 2014 05:32:34 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Fri, 14 Mar 2014 05:32:34 -0700 (PDT) In-Reply-To: <53222260.5000508@alvestrand.no> References: <201403102057.s2AKv90t026761@rcdn-core-5.cisco.com> <531F176C.2070305@viagenie.ca> <531F212A.4040102@alvestrand.no> <53222260.5000508@alvestrand.no> Date: Fri, 14 Mar 2014 05:32:34 -0700 Message-ID: From: Dave Taht To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uvZuEygAUAYbiPWmU0othrbngV4 Cc: Keith Winstein , "rtcweb@ietf.org" Subject: Re: [rtcweb] DSCP marking for STUN packets 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, 14 Mar 2014 12:32:46 -0000 On Thu, Mar 13, 2014 at 2:25 PM, Harald Alvestrand w= rote: > On 03/12/2014 09:35 AM, Dave Taht wrote: >> >> On Wed, Mar 12, 2014 at 3:55 AM, Justin Uberti wrot= e: >>> >>> >>> >>> On Tue, Mar 11, 2014 at 10:17 AM, Dave Taht wrote= : >> >> >>>>> Whether that always translates to "the highest DSCP code point" is ..= .. >>>>> a good question. >>>> >>>> It doesn't. Keith added af42 support to mosh last year and had severa= l >>>> reports of packets being dropped with that marking. Worse the drops >>>> happened >>>> after 10 seconds of connectivity. >>>> >>>> Ecn markings on the other hand have thus far survived (if occasionally >>>> stomped on) across the open internet in that protocol. >>> >>> >>> This is a concern of mine as well, which is why we haven't yet flipped >>> the >>> switch to turn DSCP on by default in Chrome. I think we'll need to do >>> some >>> experimentation to see how often DSCP makes things worse. >> >> Well, while I'm at this, I note that how linux handles DSCP in WIFI >> 802.11e >> is generally suboptimal. the CS6 and CS7 bit patterns map to the VO >> queue which is not aggregatable in wireless-n, CS4 and CS5 >> map to the VI queue which has a lot of good properties for videoconferen= ce >> and voice traffic (but limited aggregation), and CS1 and CS2, which map >> to the background queue, which has good aggregation but limited txops. > > That sounds like a Linux bug.... I would expect this translation to be do= ne That has existed since 802.11e was standardized in 2005. > via lookup tables, not copying one field into another with different > semantics (with or without bit-shift). The diffserv codepoint IS preserved however it is classified into an 802.11= e queue based on the top 3 bits up until recently. In linux 3.14 and later there is an optional classifier that does a diffser= v lookup to 802.11e queue translation. These queues determine txop scheduling and bandwidth characteristics, not drop probability. http://en.wikipedia.org/wiki/IEEE_802.11e-2005#802.11e_MAC_protocol_operati= on In some versions of cerowrt I have obsoleted the VO queue entirely, pushed several AFxx markings into the VI queue, and respected background markings to push them into the BK queue, and am working on something that will try to maximize txops and aggregation by "pushing" traffic into better queues when needed. > >> >> I no longer have the bit patterns for AFxx memorized, but basically >> all that was returned to the 802.11e classifier was dscp >> 5 up until >> very >> recently. Lastly, there really is no interpretation whatsoever of the AF >> classes equating to "drop probability" in wifi (at least in lnux), they >> merely >> control queue selection and I am not aware of any OS that translates AFxx markings into drop probability directly on wifi. >> it is generally better with wireless-n to aim for better aggregation in >> one queue rather than using multiple queues as the cost of acquiring >> the media dominates. >> >> >> > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Fri Mar 14 06:05:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561FE1A014E for ; Fri, 14 Mar 2014 06:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 AdiF1mDsM6zK for ; Fri, 14 Mar 2014 06:05:12 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0E11A013B for ; Fri, 14 Mar 2014 06:05:11 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-e5-5322fe7f690e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A0.C6.23809.F7EF2235; Fri, 14 Mar 2014 14:05:04 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Mar 2014 14:05:03 +0100 Message-ID: <5322FE7F.9040007@ericsson.com> Date: Fri, 14 Mar 2014 14:05:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+JvjW7DP6Vgg2d32Szmd6xjs1j7r53d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mpo+bmPqeBrQsXXl/PZGhhfeHcxcnJICJhI bF42nR3CFpO4cG89WxcjF4eQwCFGiV8d71khnOWMEgc2nmTqYuTg4BXQlvj/Kg6kgUVAVWLO jE5WEJtNwELi5o9GNhBbVCBYYueB34wgNq+AoMTJmU9YQGwRgSCJdQu7mUBsYQE9iQ0bd7OA jJQQEJfoaQwCCTMDhadcbWGEsOUlmrfOZgaxhYC2NjR1sE5g5J+FZOosJC2zkLQsYGRexcie m5iZk15utIkRGGAHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTBWVJZtmrtVZ+aJB5tMrd3ela+fOz/P5uRrHsuytf5L72zXTlv2mvfq/6hbfMs0MrNt ahO1z9svknRUKDnML8sz61kyy/7ih0ems25vvdX45+Q2ifOr2zZsDzoipHIhyl1Qa+LVnc/7 /F8G6yRsDPnbxc224pLcAkvpp5tPFLZWsX5kVilbUeKixFKckWioxVxUnAgAm+Kqy/4BAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2oz2yirHR7J83IWUtLQApP-I0vE Subject: [rtcweb] Comments on draft-ietf-rtcweb-jsep-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:05:15 -0000 Hi, I did review the JSEP -06 prior to the meeting. Now I have had time to write-up my comments. 1) Section 1): [W3C.WD-webrtc-20111027] This is very old version of the API, please update to the currently relevant version. 2) Section 3.4.1.1: The m-line index is a zero-based index, referring to the Nth m-line in the SDP. a) I think the above is a bit confusing. As a zero-based index would mean that the first m= section would have index 0. Thus, the referring to the Nth m-line in the SDP is unclear. Is N, the provided index, in which case it would be the N+1th m-line. Please rewrite. b) I also wonder if one has to be clearer on what "the SDP" is. I assume it is the one that has been generated by the agent, rather than the latest sent or received? 3) Section 3.4.1.1: "The MID uses the "media stream identification", as defined in [RFC5888] , to identify the m-line." a spurious space after ref. 4) JSEP applications typically inform the browser to begin ICE gathering via the information supplied to setLocalDescription, as this is where the app specifies the number of media streams to gather candidates for. I find the statement that ICE candidate gathering starts first with setLocalDescription. Doesn't the created offer already contain local candidates, thus one must have already gathered some candidates? To me it appears reasonable to start gathering earlier, rather than later. Thus, as soon as one create the PeerConnection object and have added any MST to it or a data channel, one can start gathering. 5) Section 3.5.2: In the parallel forking case where the Javascript application wishes to simultaneously exchange media with multiple peers, the flow is slightly more complex, but the Javascript application can follow the strategy that [RFC3960] describes using UPDATE. (It is worth noting that use cases where this is the desired behavior are very unusual.) I mostly react to the last sentence within the paragraph. I think the poster child for semi-parallel forking was the MMORG that like to establish PCs with anyone that is coming close in the virtual world. Thus either needs to have a number of PCs on standby or have just one, but treat that as parallel forking. And if you like to discourage the later, then I think you might need to at least inform about the possibility to have stand-by PCs. 6. Section 3.6: In the event that the local application state is reinitialized, either due to a user reload of the page, or a decision within the application to reload itself (perhaps to update to a new version), it is possible to keep an existing session alive, via a process called "rehydration". The explicit goal of rehydration is to carry out this session resumption with no interaction with the remote side other than normal call signaling messages. I think this paragraph makes two erronous statements: a) "keep an existing session alive" I think "resume" an existing session would be more correct. Because it would be broken when the reload happens. b) "with no interaction with the remote side" My understanding is that due to DTLS and key handling a DTLS renegotiation will be required with the peer. Isn't also a signalling exchange likely to be required due to change of local DTLS cert as well as ICE candidates as parameters? Any other parameters that will be required to exchanges when rehydrating? 7. Section 3.6: Next, a new offer is generated by the new PeerConnection; this offer will have new ICE and possibly new DTLS-SRTP certificate fingerprints (since the old ICE and SRTP state has been lost). I think this may require quite a bit more details. A forward pointer to where you will specify that? 8. Section 3.6: [OPEN ISSUE: EKR proposed an alternative rehydration approach where the actual internal PeerConnection object in the browser was kept alive for some time after the web page was killed and provided some way for a new page to acquire the old PeerConnection object.] Can't we declare this open issue closed? I have seen no details on the alternative proposal. Thus, lets work with the one that is present. 9. Section 4.1.1: There is no discussion of how the bundle policies relate to the Data Channels? Are they included or do they have a specific set of policies. Please extend this to discuss this. 10. Section 4.1.3: This text doesn't appear to contain a requirement on that one MUST have called setRemote prior to being able to call it. 11. Section 4.1.4.1: While this could also be done with an inactive "pranswer", followed by a sendrecv "answer", the initial "pranswer" leaves the offer- answer exchange open, which means the caller cannot send an updated offer during this time. Should one mention that also the callee can't send an offer without doing a "final" answer? 12. Section 4.1.4.1 By the time the human has accepted the call and triggered the new offer, it is likely that the ICE and DTLS handshaking for all the channels will already be set up. Wouldn't the handshaking have "finished" rather than "set up"? 13. Section 4.1.4.2: Rollback can only be used to cancel proposed changes; there is no support for rolling back from a stable state to a previous stable state. What is meant with "proposed changes"? From my side it is not clear how much you can do after having performed a SetLocal or SetRemote. I think these needs to be treated separately. For an offerer, they can createOffer, SetLocal, send to peer, receive reject and then undo the SetLocal. That is straight forward, and if they done the SetRemote, they would be consider in a new Stable state and can't roll back anymore? For the answering side, it receive an offer, does SetRemote, CreateAnswer, determines that it doesn't like it, the can undo the SetRemote and send a reject message to offerer. But what about this case? it receive an offer, does SetRemote, CreateAnswer, SetLocal and sends the message, then receive a reject from the peer, because it didn't like the answer? Are the answerer then in a stable state that can't be unrolled, or? 14. Section 4.1.5: This API indirectly controls the candidate gathering process. When a local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and begin gathering candidates for them. Another part of an earlier question regarding what triggers ICE gathering? 15. Section 4.1.7: TODO: Do we need to expose accessors for both the current and proposed local description? This needs to be resolved, I don't know if I can answer this question. 16. Section 4.1.9: Should this section discuss that it might be browser that has overriding controls regarding if other candidates then relay ones may be provided, i.e. privacy mode? 17. Section 4.1.9: Regardless of the configuration, the gathering process collects all available candidates, but excluded candidates will not be surfaced in onicecandidate callback or used for connectivity checks. Doesn't this result in both resource consumption and that the configured TURN server will learn the external IP address and port for the client? 18. Section 5.2.1: Structure in relation between RTP media and DATA channel. Maybe you should try to find a structure that makes the difference between the two types of transport more clear, and what applies to the perspective. 19. Section 5.2.1: o For the current default candidate, a "c=" line, as specific in [RFC5245], Section 4.3., paragraph 6. If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. What about host candidates? 20. Section 5.2.1: The CNAME must be generated in accordance with draft-rescorla-random-cname-00. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?] I think you should point to the RTP usage for this particular piece. Because we do have text there both for the CNAME generation and how CNAMES among MSTs and between PeerConnection. Likely to be changed soon based on the mailing list discussion. 21. Section 5.2.1: o [OPEN ISSUE: Handling of a=imageattr] Yes, I think imageattr should be supported to give guidance on suitable resolutions that an endpoint like to receive for a particular MST. 22. Section 5.2.1: Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in [RFC5888]. This attribute MUST have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. Isn't this overriding BUNDLE as currently specified, forcing everything into a single bundle group. Thus, preventing the bundle policies to work. 23. Section 5.2.2: o If any MediaStreamTracks have been added, and there exist m= sections of the appropriate media type with no associated MediaStreamTracks Isnt' the last a "MediaStreamTrack" rather than plural ones? 24. 5.2.3.3. VoiceActivityDetection If the "VoiceActivityDetection" constraint is specified, with a value of "true", the offer MUST indicate support for silence suppression by including comfort noise ("CN") codecs for each supported clock rate, as specified in [RFC3389], Section 5.1. As currently specified this text requires the usage of a comfort noise codec, currently there is no such on required. I think the "MUST" needs to be rewritten. 25. Section 5.3.1: Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. I react to the word simplicity here. I never consider usage of different PTs per direction anything simple. But, yes it is allowed by RFC 3264. But I kind of protest to encourage the usage. 26. Section 5.3.2 etc. When will we see a first draft of the text in the sections: 5.3.2, 5.3.3., 5.4, 5.5, 5.6, 5.7? I really like to see it prior to the Interim meeting. 27. Section 6: Note: This section is still very early and is likely to significantly change as we get a better understanding of a) the use cases for this b) the implications at the protocol level c) feedback from implementors on what they can do. Shouldn't this mention W3C discussion also? 28. Section 7 - Security Considerations: First of all there are no references to the Security Considerations or architecture document. Secondly, I would like to have some security discussion on significant issues with JSEP itself. Resource attacks on the local endpoint for example? 29. section 10 There are a couple of draft references that are either published RFCs or at least WG versions. Please update the reference list. 30. Section 10.2: Looking at the spec, I think the following references are normative: [I-D.ietf-mmusic-trickle-ice] Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf- mmusic-trickle-ice-00 (work in progress), March 2013. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Protocol", draft-ietf-rtcweb-data-protocol-04 (work in progress), February 2013. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 14 09:15:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5FB1A0180 for ; Fri, 14 Mar 2014 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 dcCBRE92n3Jt for ; Fri, 14 Mar 2014 09:15:49 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 20EDB1A017B for ; Fri, 14 Mar 2014 09:15:48 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so3043514vcb.27 for ; Fri, 14 Mar 2014 09:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DjFHQZfKSzsrCyr3NZxNOCWXcuWmOObUbvO/TSSYEN0=; b=P5hrJ/BZLvqlbGmMBb/Hp5reCyoFaHKS87EqjA4UgWQL2sgfAI3Wq56fqGN90Szphp i40WYT09UUoCE9GYcgANVVpfOp0mfXLAox+NJgbqPVr3x4UGophU7GBZTvNgQXaFi6rj kHH4h1dV5l5InXdH36IwFAmaN13HtL7JLF/Il+Rxb25DR5CKtMtb+R2F0eAJzAYdK/VG VzVrtzN/0GeDJJbHgeZWOc2waJ6Q7zG3Rcb4T/y7Y7L2lJWfJAnKT5EqsRnbSk0Z7atF sDkD4jcd02b3mguej7xHtgL6EZ0Q7GDLzJOlSFDhTi7QqJHm2xDDqJHva2UwjQarlS12 tiPQ== 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=DjFHQZfKSzsrCyr3NZxNOCWXcuWmOObUbvO/TSSYEN0=; b=mZvuPdkUOCObqDI55E6IeXW6ygyE0zIhu2BnwuTNNnQMPl0PYYlXaoXEK170WiyxPU nBMrsq/B1BXSMeLTJ8U93Pr+5foQkuq5baSniK5yp/nE9tKjLYYhpSW0U2xZD36FtOmX lL/pCqphHitc6n/TkbDgoyVMqVU2QnELqF0JNNwqcghGmFCVfp/48EALbrXQvJ6Gdkno VKGFouezosoNvFNaMIqykgmQQm6u4A/6Vj6j+hSbgk8EbInhbVCh+AcMumtwvEJnnxs2 xqW8YAddQlOVrVol5AW7zMBV31W236Iwp6pK7C5b082g9Clf3KMaJKvA0TtKVfABoVs+ 1k6Q== X-Gm-Message-State: ALoCoQlkZO70dTjCF8AKvQfR0QZuJqlS5G7Up3VELjxVouH9iJJipTZFzjqzQE71jSep4YGmOTnrEN6qkrh3LIH6+D6Tp9Bi9gGQDYUUNVEhSNIgJe9HtFFO+dgMNiG3go7NTao+Dffdnb5ZDtLmfrEEFZFkDssSbvwlPm6Zf9FHedb8B8mIz/OdoebD7FxMNDo0d8oqS8WH X-Received: by 10.58.96.36 with SMTP id dp4mr5245799veb.21.1394813740959; Fri, 14 Mar 2014 09:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 09:15:20 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CF8C0FD@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1CF8C0FD@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 14 Mar 2014 09:15:20 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=089e013a26e68ee4bb04f493615f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/N7gFju9GeaN0RGZw00LXuGnyMrU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 14 Mar 2014 16:15:52 -0000 --089e013a26e68ee4bb04f493615f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2014 at 4:25 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 2014-03-12 21:56, Justin Uberti wrote: > > Agreed. > > I may well be that the pause/resume doc will not be ready in time, so it > from that aspect is a bad idea. What about just stating that TMMBN/TMMBR > 0 meaning pause should be supported? > It's not clear to me what the interactions are between the signaling and media plane when this occurs. That is, if I do doohickey.active =3D false, should that cause a=3Drecvonly signaling and a TMMBN notification that the track is paused? I am concerned that things can get out of sync (i.e. what happens if we get TMMBR indicating resume, but signaling is still a=3Drecvonly)? > > Aren't there also patent declarations against this doc from > > multiple holders? > > I've not looked into that, but I deliberately chose to propose the "old" > TMMBN 0 way to signal that is mentioned in [1] (and not any of the "new" > signaling in [1]). > OK. > > > > > While SDP will likely be removed from the API in the future, the > > replacement would be a app-specific message sent over websockets, which > > seems like it would work just fine. > > s/would/could/: I don't think this has been discussed or agreed (and > websocket is of course just an example). > Right, the whole thing is an example, but the point is that the new API directions don't really affect this particular problem. > > I think it is worthwhile to push this kind of signaling into the media > plane if possible. For example, this would enable the UA to save > transmission/battery even if the app is badly written. > > As an example: if a MST sent over a PC is not used in any way at the > receiving end, the receiving end UA could signal TMMBR 0 to tell the > sending UA to not send. Sure, the receiving UA could also fire a > "negotiationneeded" event, but maybe the app doesn't listen. > True, if the app doesn't perform the necessary signaling, things are not going to work, but that applies to a lot of operations on the PeerConnection. Overall this feels to me like something that needs some thought to figure out all the interactions between the API, the signaling plane, and the media plane. As such I am inclined to leave this out of 1.0. > > > > > > > On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba > > wrote: > > > > While I do like the pause/resume draft, having core RTCWEB WG > > documents (such as RTP Usage) depend on it seems like a bit of a > > stretch. After all, the document was only adopted last week, and it > > is a rare IETF WG document that can go from a -00 WG draft to > > publication as an RFC in under a year. > > > > > > On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=C3=A5kansson LK > > > > wrote: > > > > Hi, > > > > at the IETF last week there was consensus in the AVTEXT WG > > meeting to > > adopt the pause/resume draft [1] as a WG draft. > > > > In rtcweb/webrtc we're have the situation that we're discussing > so > > called "doo-hickeys" as an API surface where the web app > > (amongst other > > things) can pause and resume the sending of a track. This can > > be signaled with the direction attribute and a SDP O/A exchange > > (and the > > app pausing/resuming sending of a track would presumably lead t= o > a > > "negotiationneeded" event being fired). > > > > But I think we should in addition require the browser to signal > it > > according to one of the methods in [1] (e.g. TMMBN =3D 0), and = also > > understand that signaling (a browser receiving TMMBN =3D 0 must > > know that > > the other end-point will pause sending). > > > > My argument is that we know that many dislike SDP in rtcweb, an= d > a > > likely development is that it will be removed in a later > version. My > > speculation is that signaling as outlined in [1] will then be > > used for > > pause/resume. If we support this from the beginning earlier > > implementations could more easily interop with those later > versions. > > > > > > Stefan > > > > [1] > > > https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt > > > > _______________________________________________ > > 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 > > > > > > --089e013a26e68ee4bb04f493615f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 4:25 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 2014-03-12 21:56, Justin Uberti wrote: > Agreed.

I may well be that the pause/resume doc will not be ready in time, so it from that aspect is a bad idea. What about just stating that TMMBN/TMMBR 0 meaning pause should be supported?

It= 's not clear to me what the interactions are between the signaling and = media plane when this occurs. That is, if I do doohickey.active =3D false, = should that cause a=3Drecvonly signaling and a TMMBN notification that the = track is paused? I am concerned that things can get out of sync (i.e. what = happens if we get TMMBR indicating resume, but signaling is still a=3Drecvo= nly)?


> Aren't there also patent declarations against this doc from
> multiple holders?

I've not looked into that, but I deliberately chose to propose th= e "old"
TMMBN 0 way to signal that is mentioned in [1] (and not any of the "ne= w"
signaling in [1]).

OK.
=C2=A0=

>
> While SDP will likely be removed from the API in the future, the
> replacement would be a app-specific message sent over websockets, whic= h
> seems like it would work just fine.

s/would/could/: I don't think this has been discussed or agreed (= and
websocket is of course just an example).

Right, the whole thing is an example, but the point is that the new API d= irections don't really affect this particular problem.=C2=A0

I think it is worthwhile to push this kind of signaling into the media
plane if possible. For example, this would enable the UA to save
transmission/battery even if the app is badly written.

As an example: if a MST sent over a PC is not used in any way at the
receiving end, the receiving end UA could signal TMMBR 0 to tell the
sending UA to not send. Sure, the receiving UA could also fire a
"negotiationneeded" event, but maybe the app doesn't listen.<= br>

True, if the app doesn't perform th= e necessary signaling, things are not going to work, but that applies to a = lot of operations on the PeerConnection.

Overall this feels to me like something that needs some= thought to figure out all the interactions between the API, the signaling = plane, and the media plane. As such I am inclined to leave this out of 1.0.= =C2=A0

>
>
> On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <bernard.aboba@gmail.com
> <mailto:bernard.aboba@gmail.com>> wrote:
>
> =C2=A0 =C2=A0 While I do like the pause/resume draft, having core RTCW= EB WG
> =C2=A0 =C2=A0 documents (such as RTP Usage) depend on it seems like a = bit of a
> =C2=A0 =C2=A0 stretch. After all, the document was only adopted last w= eek, and it
> =C2=A0 =C2=A0 is a rare IETF WG document that can go from a -00 WG dra= ft to
> =C2=A0 =C2=A0 publication as an RFC in under a year.
>
>
> =C2=A0 =C2=A0 On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=C3=A5kansson = LK
> =C2=A0 =C2=A0 <= stefan.lk.hakansson@ericsson.com
> =C2=A0 =C2=A0 <mailto:stefan.lk.hakansson@ericsson.com>= ;> wrote:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 at the IETF last week there was consensus = in the AVTEXT WG
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 meeting to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 adopt the pause/resume draft [1] as a WG d= raft.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 In rtcweb/webrtc we're have the situat= ion that we're discussing so
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 called "doo-hickeys" as an API s= urface where the web app
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (amongst other
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 things) can pause and resume the sending o= f a track. This can
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 be signaled with the direction attribute a= nd a SDP O/A exchange
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (and the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 app pausing/resuming sending of a track wo= uld presumably lead to a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "negotiationneeded" event being = fired).
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 But I think we should in addition require = the browser to signal it
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 according to one of the methods in [1] (e.= g. TMMBN =3D 0), and also
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 understand that signaling (a browser recei= ving TMMBN =3D 0 must
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 know that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the other end-point will pause sending). >
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 My argument is that we know that many disl= ike SDP in rtcweb, and a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 likely development is that it will be remo= ved in a later version. My
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 speculation is that signaling as outlined = in [1] will then be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 used for
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 pause/resume. If we support this from the = beginning earlier
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementations could more easily interop = with those later versions.
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 [1]
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools= .ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rtcweb mailing list
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rtcweb@ietf.org <mailto:rtcw= eb@ietf.org>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailm= an/listinfo/rtcweb
>
>
>
> =C2=A0 =C2=A0 _______________________________________________
> =C2=A0 =C2=A0 rtcweb mailing list
> =C2=A0 =C2=A0 rtcweb@ietf.org= <mailto:rtcweb@ietf.org><= br> > =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtcweb
>
>


--089e013a26e68ee4bb04f493615f-- From nobody Fri Mar 14 09:26:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976B71A0168 for ; Fri, 14 Mar 2014 09:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 pqPSkwb98kPL for ; Fri, 14 Mar 2014 09:26:38 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5A21A0164 for ; Fri, 14 Mar 2014 09:26:38 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so2942514veb.18 for ; Fri, 14 Mar 2014 09:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lexa7iuDR6QT5BqGKtn3PmMsqS9DW09Vydw2ElWE7yM=; b=jMlXqiG/vzJGfKc1RiaW/sKviWm8u5f5ZLhxUNe4wB9s6VKpxN3ibgL5XeAl83Gj3k hdcQd5RHUz7qLM48DwKIxP/ZR8nMa83LQnGcEuiLP3CvpX6TO8yiHHgOwUgYAonBS1sX YviKjQxs217q5MjZn0fCyFmhrdBmV/6govGLP4j5S1Eq+3ff9RGKZMVhktTyII/spdpI rMVEuesjXC7PKyb+DasC1MKtLQpIKzhwUaj5Fheg1h0UcKQn9Gmp6de7KGh1lznkmnhq 2wUYTqghfMsSXJss0kdn78L9g3Tfy6O+hmrgS8Jj3YogxPaqoX8GyhrMF5Doxhzp2t14 iedw== 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=lexa7iuDR6QT5BqGKtn3PmMsqS9DW09Vydw2ElWE7yM=; b=DObIrZFp8cB2sHfNetw/CVbqGA0HpU4VP79cPg7d53KiRHRI2gyGv1AXwFnwTBVqTl 1dzydsUsXNrr3HWpPe8GTrRmGo1Ier5QNGqXnih9enEehPdYcUQ95rO+nlMKWMnPeVfK QSZjohOkqyv9A0qllDm5+BCbU0QRCDnDeDMCT7/y4jCGI75gUoSVthhH1siEVlwgl2/S MWPftbnN7RF+fXr6dM65meHQess6pUD3EasCdv3IY4OYXL/IZRr8f0wjGUWCf4AULvFU TO3FUP0eEfHlNILr7935IZtQmybGElWpnHN5hn2nBfeNSle1BjQf5/uas14rX47OMCBo ca8w== X-Gm-Message-State: ALoCoQlKnSjAWurIPYmhiJyfTclMTj1TWRV44gJv7LQNUfKwrQFir1ekdOgKU/enEbU2MTu9ZO2kqRF7Bsv53uRdJH9WSvQ5ccq7JI0M12ltjcmrHU+t4Cx6eFmR848OlpQPFmTSZDNPxOyluLc+lLdthfkc8NP+Ei7us1iSraAkHalsz/Cw8kfs8iBbRCvZtCKj69+34olP X-Received: by 10.52.101.135 with SMTP id fg7mr5895757vdb.17.1394814391200; Fri, 14 Mar 2014 09:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 09:26:10 -0700 (PDT) In-Reply-To: <5322C475.5050402@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> From: Justin Uberti Date: Fri, 14 Mar 2014 09:26:10 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec546950550c86c04f49388f5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Mr1NNM_3lqNMAn5QdqYcDLq2qsg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 16:26:40 -0000 --bcaec546950550c86c04f49388f5 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > (as individual) > > Although this discussion really should be on MMUSIC, I am still > following up here. Anything we come to conclude here really need to go > to MMUSIC for confirmation. > > Justin, I do agree that it appear unnecessarily of having to include an > RTCP transport in an OFFER when the offerer know the answerer is BUNDLE > capable. I am fine with that and think the rule needed here is something > along the line of the below: > > A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already > required). In any answer by a BUNDLE capable endpoint, it MUST NOT > change the usage of a=rtcp-mux. If it is present in the offer, it must > be confirmed to be used in the answer, and if not present in the offer, > it MUST NOT be added in the answer. An BUNDLE capable endpoint is > RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not > be suitable include, lack RTP payload types, or cases when RTCP traffic > is needed to be on its own transport flow (5-tuple) to enable QoS or > other traffic handling functionalities. > > The reason for writing the rule like the above, is that then an endpoint > can choose when creating an offer to renegotiate the use of a=rtcp-mux. > For example due to it running out of available PTs. > > Feedback on this proposal? > I am not OK with this. It just gets too complicated to deal with all the cases, especially if with the provision that rtcp-mux can change during the session. I think Christer's current language is what we want - if you are going to BUNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer cannot do that, it needs to reject the BUNDLE. I agree with your initial point though - if you know that both sides are going to BUNDLE and rtcp-mux, it makes sense to allow them to do that from the outset, i.e. no need to include a RTCP transport in the offer. --bcaec546950550c86c04f49388f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
Hi,
(as individual)

Although this discussion really should be on MMUSIC, I am still
following up here. Anything we come to conclude here really need to go
to MMUSIC for confirmation.

Justin, I do agree that it appear unnecessarily of having to include an
RTCP transport in an OFFER when the offerer know the answerer is BUNDLE
capable. I am fine with that and think the rule needed here is something along the line of the below:

A BUNDLE supporting endpoint MUST implement a=3Drtcp-mux (that is already required). In any answer by a BUNDLE capable endpoint, it MUST NOT
change the usage of a=3Drtcp-mux. If it is present in the offer, it must be confirmed to be used in the answer, and if not present in the offer,
it MUST NOT be added in the answer. An BUNDLE capable endpoint is
RECOMMENDED to use a=3Drtcp-mux whenever suitable. Cases when it might not<= br> be suitable include, lack RTP payload types, or cases when RTCP traffic
is needed to be on its own transport flow (5-tuple) to enable QoS or
other traffic handling functionalities.

The reason for writing the rule like the above, is that then an endpoint can choose when creating an offer to renegotiate the use of a=3Drtcp-mux. For example due to it running out of available PTs.

Feedback on this proposal?

I am not OK = with this. It just gets too complicated to deal with all the cases, especia= lly if with the provision that rtcp-mux can change during the session.

I think Christer's current language is what we want= - if you are going to BUNDLE, you MUST also use rtcp-mux for any RTP m-lin= es. If the answerer cannot do that, it needs to reject the BUNDLE.

I agree with your initial point though - if you know th= at both sides are going to BUNDLE and rtcp-mux, it makes sense to allow the= m to do that from the outset, i.e. no need to include a RTCP transport in t= he offer.
--bcaec546950550c86c04f49388f5-- From nobody Fri Mar 14 09:30:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8657B1A0161 for ; Fri, 14 Mar 2014 09:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=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 6hd3Fm2WUTbn for ; Fri, 14 Mar 2014 09:30:48 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 91B551A00F1 for ; Fri, 14 Mar 2014 09:30:45 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-a4-53232ead1a31 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8C.1E.04249.DAE23235; Fri, 14 Mar 2014 17:30:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 17:30:37 +0100 From: Christer Holmberg To: Justin Uberti , Magnus Westerlund Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAAIVkAIABaJQggAAqmoCAAPXJ+4AAIb6AgAB9YgCAABFvsQ== Date: Fri, 14 Mar 2014 16:30:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D215AAB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje46PeVggwWLGC1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozb77rZC+6IVGzcMJ+pgfG2 QBcjJ4eEgInEho8H2CBsMYkL99YD2VwcQgJHGCUOblkH5SxhlGg9upC9i5GDg03AQqL7nzaI KSIQI/HuaDFIL7OAq0TTw6UsILawgLHElM7JYDNFgObPnfiaBWSMiMAkRonlf/oYQRIsAqoS M6feYgKZwyvgK9E+0Qdi1S02ibUzG5lBajgFAiW+b3rGBGIzAh33/dQaJohl4hK3nsxngjha QGLJnvPMELaoxMvH/1ghbCWJHxsusUDU60gs2P2JDcLWlli28DVYPa+AoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKkaM4tTgpN93IYBMjMGoObvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmk J5akZqemFqQWxReV5qQWH2Jk4uCUamBk1r8vLCld+Pudn2tyv4aORPG+zV+7jL0VjPVY/6bz /vwivtBI89yS+ZIZ014uKLkr/O6d7bkO0Vqe1ed6y52U3nx5UXtuQfjqH5HeDCvrDLMTNHWe XOoPmnWxzJit/Jl21Wm1PJEzSgEi7kmPJJM2z57SI2lkee31JN5exTrbv3IejwT21SuxFGck GmoxFxUnAgCTr7NxaAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LYeMOpvJU9WpGHMTjcAFr_I8W20 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 16:30:49 -0000 Hi Justin, What do you mean by "RTCP transport in the offer"? Are you referring to the= a=3Drtcp attribute, or? Even if we mandate rtcp-mux within a BUNDLE group, the a=3Drtcp-mux attribu= te must still always be present - even if you know the remote endpoint supp= orts rtcp-mux (or, even if you have already negotiated usage of rtcp-mux). Regards, Christer ________________________________________ From: Justin Uberti [juberti@google.com] Sent: Friday, 14 March 2014 6:26 PM To: Magnus Westerlund Cc: Christer Holmberg; rtcweb@ietf.org; Eric Rescorla Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund > wrote: Hi, (as individual) Although this discussion really should be on MMUSIC, I am still following up here. Anything we come to conclude here really need to go to MMUSIC for confirmation. Justin, I do agree that it appear unnecessarily of having to include an RTCP transport in an OFFER when the offerer know the answerer is BUNDLE capable. I am fine with that and think the rule needed here is something along the line of the below: A BUNDLE supporting endpoint MUST implement a=3Drtcp-mux (that is already required). In any answer by a BUNDLE capable endpoint, it MUST NOT change the usage of a=3Drtcp-mux. If it is present in the offer, it must be confirmed to be used in the answer, and if not present in the offer, it MUST NOT be added in the answer. An BUNDLE capable endpoint is RECOMMENDED to use a=3Drtcp-mux whenever suitable. Cases when it might not be suitable include, lack RTP payload types, or cases when RTCP traffic is needed to be on its own transport flow (5-tuple) to enable QoS or other traffic handling functionalities. The reason for writing the rule like the above, is that then an endpoint can choose when creating an offer to renegotiate the use of a=3Drtcp-mux. For example due to it running out of available PTs. Feedback on this proposal? I am not OK with this. It just gets too complicated to deal with all the ca= ses, especially if with the provision that rtcp-mux can change during the s= ession. I think Christer's current language is what we want - if you are going to B= UNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer cann= ot do that, it needs to reject the BUNDLE. I agree with your initial point though - if you know that both sides are go= ing to BUNDLE and rtcp-mux, it makes sense to allow them to do that from th= e outset, i.e. no need to include a RTCP transport in the offer. From nobody Fri Mar 14 09:44:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3EF1A016F for ; Fri, 14 Mar 2014 09:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 BLY0CMxm7O-O for ; Fri, 14 Mar 2014 09:44:34 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id C05F21A0164 for ; Fri, 14 Mar 2014 09:44:33 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so3018969veb.11 for ; Fri, 14 Mar 2014 09:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C4YY4/BNelB/xyvlO4dXanWzb9J+gu4MiBbWu4JnoVs=; b=cujZvWxy5o5OI5LkrSX4jhUm22pUetEeYlBHwmyHmV7BO4aDn/3QYwJowKJhoa52dS Go0luzappcLuqeAimCmwh4zm97kMG9Gi8fQCzdznLCFBeGeeKYOv1uVNW1131/U11B02 9c73RqqXiZnmPFpXAjQ4Kh3/Fokg4CusRstaLnmLdbnGoB5CzuNJk4L5NuHeOvLmjPTO Lg+KCxFbydczOO+OkhIPCM8SZMef64/8TjRup07LlIixi+dnznuhkfRhIMHa59i4VTFI YvXIXQTcH8qJXN8jP0WqD/6cieczuV9yoMTDw3rbqswGoH1gLHMD2RhkqB9+jj0/fZTi N99A== 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=C4YY4/BNelB/xyvlO4dXanWzb9J+gu4MiBbWu4JnoVs=; b=N3k8/pIwSNN/QNxafr3hcICFGrWKjDYnTey2cRf2PuUR6onaAeqdKFZldVZWOHpq/l tLAEZWehxsWNUBZD3e7ALzjZoSiUHbrOwzlR5Gf9mY+NYc1x2vFi8AWTSX56aoCnFM2f cN6DghShaHxGJRixAIAh/X17wEpVrpx8gzcmnV3WEytFmM1B3hp85b63Nyrzv7ED2fne sdGY1BFSuy7bhw5ZcjkM6bYq+OKvzZOHchm+o+hoZHEOWQwvDHyhNZUYphw5BLm6X7ly Y8G4gct5+qWit1UUFokNnqaSHMHe/WuPJJk1BytYTKfe9awFTqaOFHs1ZKOv5LJeNN/5 l0tQ== X-Gm-Message-State: ALoCoQk64ljsQVWIuGPERDEvBEPOhHvsJoOGVFuyD2iAunXgFI78ivZKFXZ8isRLRhqMxtG/JwZDU8nCvSOp0QVFEfkKiS10cMA4iciV019GYnpjTyvF3LBzH9hyBUguzpNVEHYmiecf4zdQXPIm6wzKtj1T9IXxahEEIrx9gA85fBzMXh5VdmiJzYiVUA03tfyWRDxq/ntd X-Received: by 10.221.61.210 with SMTP id wx18mr1666201vcb.27.1394815466710; Fri, 14 Mar 2014 09:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 09:44:06 -0700 (PDT) In-Reply-To: <5322BF2E.3060608@ericsson.com> References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> From: Justin Uberti Date: Fri, 14 Mar 2014 09:44:06 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a1134a86e6bcbad04f493c89b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Nw2VNWq3Ss32qU6IAYo7RKIp8B8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 14 Mar 2014 16:44:37 -0000 --001a1134a86e6bcbad04f493c89b Content-Type: text/plain; charset=UTF-8 On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-13 17:53, Martin Thomson wrote: > > On 12 March 2014 01:29, Magnus Westerlund > > wrote: > >> I like to point out that the agreement and what is documented in > >> rtp-usage is that WebRTC endpoint will have to make forwarded streams > >> appear as locally originated. However, this as currently written does > >> not apply to RTP middleboxes that interconnects multiple PeerConnections > >> to form a multi-party session. This is deliberate to ensure that RTP > >> topologies like RTP mixer and SFM do work on the RTP/RTCP level. > > > > I'm still not clear on whether a middlebox interoperating with a > > WebRTC endpoint is obligated to respect these rules or not. I had > > assumed that WebRTC is such a bully that they would be forced to. > > Well, I know Colin and I did put in quite some thought to make the > WebRTC RTP usage rules such that you can use the common RTP middleboxes > as long as you have the right front-end, i.e. DTLS-SRTP and signalling > translation. > > > > >> I am especially interested to know how you will "easy to apply manually" > >> the synchronization. Can you please describe that. Because, that either > >> requires an API call to tell the media framework, please consider the > >> following CNAMES as equivalent, or some other method of telling the > >> media framework that these different MST are actually originating from a > >> common clock base. > > In WebRTC, this would be: > > > > var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0]; > > var video = pc2.getRemoteStreams()[0].getVideoTracks()[0]; > > var synchronizedStream = new MediaStream(audio, video); > > > > We'd have to say that this implies a statement about the clock base of > > the tracks being the same. ... and that this statement could be > > wrong. > > I think this looks dangerous. If you default the assumption that > different CNAMEs of the MST you add are actually sharing clock base, > then a lot of basic programs that may group MST from different PCs into > one MS for convenience are going to cause serious issue in the media > frameworks, when they attempt to synchronize things. > > > > > As far as it goes, I'm sure that other systems could build a similar > > function, but none of those are standardized. > > > >> I protested about this, not to lower the users privacy, but over the > >> concern that this was raised without providing a case where it was > >> obvious that the user's privacy was impacted. Martin, you said that you > >> would think about it, and the next statement was lets change it, without > >> providing any motivation why the concern was significant. > > > > I'm sorry about that, I thought about it, but didn't want to waste > > everyone's time (mine included) with an essay on the subject. > > > > Having considered this a bit more, I do think the risk to privacy out > weighs the other concerns, as long as the API and its handling can be > sorted out, I don't think the above is sufficient to get good > functionality. > > My understanding is that the risk to privacy exist when one have one JS > application enabling communication in different contexts during the same > application session. In cases where there might be participants in the different contexts that could link the same end-point and thus human > user to different participant IDs (that otherwise are anonymous). Thus > revealing privacy concerns. As it would take the application designer to > take this risk into consideration to avoid it, I feel safer if the > application designer would need to take active measurements to perform > linkage. > I will wait an see if there are other inputs on this within the next > week. If nothing arises I will propose a text change to the rtp-usage to > address this. > > At an implementation level, one could imagine at least 3 policies for generating CNAMEs: a) per-session (i.e. per-PeerConnection) b) per-page (i.e. shared between all PCs on a page) c) per-page, persistent (i.e. shared between all PCs on a page, including across page loads) While we seem to agree that a) is the right solution for CNAMEs, it is worth pointing out that we (Chrome) are currently doing c) for DTLS certificates, to avoid performance problems with cert generation at page load. Ergo, this linkability concern already exists, and I don't think it is easy to solve it in the default case. There have been some proposals to allow generation/storage of unique certs to prevent this linkability, but this will require app input. Ergo, we might want to match the DTLS behavior (i.e. generate unique CNAMEs only when the certs are unique), to ensure we treat linkability consistently. --001a1134a86e6bcbad04f493c89b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
On 2014-03-13 17:53, Martin = Thomson wrote:
> On 12 March 2014 01:29, Magnus Westerlund
> <magnus.westerlun= d@ericsson.com> wrote:
>> I like to point out that the agreement and what is documented in >> rtp-usage is that WebRTC endpoint will have to make forwarded stre= ams
>> appear as locally originated. However, this as currently written d= oes
>> not apply to RTP middleboxes that interconnects multiple PeerConne= ctions
>> to form a multi-party session. This is deliberate to ensure that R= TP
>> topologies like RTP mixer and SFM do work on the RTP/RTCP level. >
> I'm still not clear on whether a middlebox interoperating with a > WebRTC endpoint is obligated to respect these rules or not. =C2=A0I ha= d
> assumed that WebRTC is such a bully that they would be forced to.

Well, I know Colin and I did put in quite some thought to make the WebRTC RTP usage rules such that you can use the common RTP middleboxes
as long as you have the right front-end, i.e. DTLS-SRTP and signalling
translation.

>
>> I am especially interested to know how you will "easy to appl= y manually"
>> the synchronization. Can you please describe that. Because, that e= ither
>> requires an API call to tell the media framework, please consider = the
>> following CNAMES as equivalent, or some other method of telling th= e
>> media framework that these different MST are actually originating = from a
>> common clock base.
> In WebRTC, this would be:
>
> var audio =3D pc1.getRemoteStreams()[0].getAudioTracks()[0];
> var video =3D pc2.getRemoteStreams()[0].getVideoTracks()[0];
> var synchronizedStream =3D new MediaStream(audio, video);
>
> We'd have to say that this implies a statement about the clock bas= e of
> the tracks being the same. =C2=A0... and that this statement could be<= br> > wrong.

I think this looks dangerous. If you default the assumption that
different CNAMEs of the MST you add are actually sharing clock base,
then a lot of basic programs that may group MST from different PCs into
one MS for convenience are going to cause serious issue in the media
frameworks, when they attempt to synchronize things.

>
> As far as it goes, I'm sure that other systems could build a simil= ar
> function, but none of those are standardized.
>
>> I protested about this, not to lower the users privacy, but over t= he
>> concern that this was raised without providing a case where it was=
>> obvious that the user's privacy was impacted. Martin, you said= that you
>> would think about it, and the next statement was lets change it, w= ithout
>> providing any motivation why the concern was significant.
>
> I'm sorry about that, I thought about it, but didn't want to w= aste
> everyone's time (mine included) with an essay on the subject.
>

Having considered this a bit more, I do think the risk to privacy out=
weighs the other concerns, as long as the API and its handling can be
sorted out, I don't think the above is sufficient to get good
functionality.

My understanding is that the risk to privacy exist when one have one JS
application enabling communication in different contexts during the same application session. In cases where there might be participants in the
different contexts that could link the same end-point and thus human
user to different participant IDs (that otherwise are anonymous). Thus
revealing privacy concerns. As it would take the application designer to take this risk into consideration to avoid it, I feel safer if the
application designer would need to take active measurements to perform
linkage.

I will wait an see if there are other inputs on this within the next
week. If nothing arises I will propose a text change to the rtp-usage to address this.


At an implementation level, one could imagin= e at least 3 policies for generating CNAMEs:
a) per-session (= i.e. per-PeerConnection)
b) per-page (i.e. shared between all PCs on a page)
c) per-p= age, persistent (i.e. shared between all PCs on a page, including across pa= ge loads)

While we seem to agree that a) is the ri= ght solution for CNAMEs, it is worth pointing out that we (Chrome) are curr= ently doing c) for DTLS certificates, to avoid performance problems with ce= rt generation at page load. Ergo, this linkability concern already exists, = and I don't think it is easy to solve it in the default case. There hav= e been some proposals to allow generation/storage of unique certs to preven= t this linkability, but this will require app input.

Ergo, we might want to match the DTLS behavior (i.e. ge= nerate unique CNAMEs only when the certs are unique), to ensure we treat li= nkability consistently.
--001a1134a86e6bcbad04f493c89b-- From nobody Fri Mar 14 09:46:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF10B1A0166 for ; Fri, 14 Mar 2014 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.547, 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 xTWGPH1XHkDV for ; Fri, 14 Mar 2014 09:46:55 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCBE1A00F1 for ; Fri, 14 Mar 2014 09:46:54 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so3022532veb.11 for ; Fri, 14 Mar 2014 09:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NqgJf9/W/iF0wX4MouSJtmf0Qt8OnxrwlYMbZqL+h+4=; b=QrZMzB3Yn8ybqKcLp+a+utG57h3U9+bIVZEJexEJqdZo/0ACX9lSrBUpNwajeK3mQZ oUWl6vZpZejBfCgO6LcTLGXFTlOKfhYpaKPc+8hR2/E/lFs44ULQlXQIjaPqzeiPP0gL FtiMlu1aR/pLc7Y9moTMoDSYcDW+zxtitJZ6c82qNL75Muf7Zb2pEdqm2dDtqqeXew6B /WiCPXy/MupQwrRJoLO3g9cU9NlI80DXZiEz3WnN85uK6Q6vLP+hquJQhJDwAlgWgbS8 60vpmr9h5Hpiv3O0hQ2/ILL0hhgyxN3lF5j5myUFOKJmM2Ud5eu4wYdHvGHZD+hjnZIi tJRw== 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=NqgJf9/W/iF0wX4MouSJtmf0Qt8OnxrwlYMbZqL+h+4=; b=Jw7T/5G/yg6HCH+HQzXqQqOBm3TpGPTku/hCjEMmtFBiUPmNhYratwYEHw4fSQJVqU fIHBw2xtWZ5m13BzanwZKcXbzQkwGdlgYJDdBeOJzcLNYbu87fdxr+P7wacSgcu2gmbI Nw5GnbuVSgoSgzTYHKFIvWB5ZkkrMjLpkkARW3h6J24ExSFvFG5cPv+zSnj3S07/mqCT Pl+x4CBks4k9039a1tO26owmncwjI+ZJE0OMOTB0UZjECleCGHXakV+a41O+OYD53rnR GfPe73K3MmK6kyJfjCOGiizBTo6WvR52rTsQW8wgYxd+D4pfu2jDiDbRBNs8WkbezUKu DxsQ== X-Gm-Message-State: ALoCoQmJM9BXNhkAGW8NBsJpJSDaP5myMfVLZSoriLJ2UIOHzCm2JqgX9JjBOKjbeApQGNmDc/MKPHEApkVUOcOizJdFnhlVXdcIJcHnwlWpt481MkdNUYax/nxzotQNTs5nVIF7LTlzmSgSU8sHMt+MdLBV3hJLf5mNj6RPZ3PG6ABJ0ky6HaNZ19d/uHXXqzN4MiqqPgSm X-Received: by 10.58.202.106 with SMTP id kh10mr1035364vec.31.1394815608021; Fri, 14 Mar 2014 09:46:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 09:46:27 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D215AAB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D215AAB@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 14 Mar 2014 09:46:27 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bdc945ed8002204f493d034 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cfxkrdHDnFEe-cS1GlrIFema2Yw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 16:46:57 -0000 --047d7bdc945ed8002204f493d034 Content-Type: text/plain; charset=UTF-8 By "RTCP transport in the offer", I mean separate ICE candidates generated for a RTCP ICE component, the original problem that I was proposing to solve. I agree the rtcp-mux attribute must always be present if you are going to do rtcp-mux. On Fri, Mar 14, 2014 at 9:30 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi Justin, > > What do you mean by "RTCP transport in the offer"? Are you referring to > the a=rtcp attribute, or? > > Even if we mandate rtcp-mux within a BUNDLE group, the a=rtcp-mux > attribute must still always be present - even if you know the remote > endpoint supports rtcp-mux (or, even if you have already negotiated usage > of rtcp-mux). > > Regards, > > Christer > ________________________________________ > From: Justin Uberti [juberti@google.com] > Sent: Friday, 14 March 2014 6:26 PM > To: Magnus Westerlund > Cc: Christer Holmberg; rtcweb@ietf.org; Eric Rescorla > Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux > > On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> > wrote: > Hi, > (as individual) > > Although this discussion really should be on MMUSIC, I am still > following up here. Anything we come to conclude here really need to go > to MMUSIC for confirmation. > > Justin, I do agree that it appear unnecessarily of having to include an > RTCP transport in an OFFER when the offerer know the answerer is BUNDLE > capable. I am fine with that and think the rule needed here is something > along the line of the below: > > A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already > required). In any answer by a BUNDLE capable endpoint, it MUST NOT > change the usage of a=rtcp-mux. If it is present in the offer, it must > be confirmed to be used in the answer, and if not present in the offer, > it MUST NOT be added in the answer. An BUNDLE capable endpoint is > RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not > be suitable include, lack RTP payload types, or cases when RTCP traffic > is needed to be on its own transport flow (5-tuple) to enable QoS or > other traffic handling functionalities. > > The reason for writing the rule like the above, is that then an endpoint > can choose when creating an offer to renegotiate the use of a=rtcp-mux. > For example due to it running out of available PTs. > > Feedback on this proposal? > > I am not OK with this. It just gets too complicated to deal with all the > cases, especially if with the provision that rtcp-mux can change during the > session. > > I think Christer's current language is what we want - if you are going to > BUNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer > cannot do that, it needs to reject the BUNDLE. > > I agree with your initial point though - if you know that both sides are > going to BUNDLE and rtcp-mux, it makes sense to allow them to do that from > the outset, i.e. no need to include a RTCP transport in the offer. > --047d7bdc945ed8002204f493d034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By "RTCP transport in the offer", I mean separat= e ICE candidates generated for a RTCP ICE component, the original problem t= hat I was proposing to solve.

I agree the rtcp-mux attri= bute must always be present if you are going to do rtcp-mux.


On Fri,= Mar 14, 2014 at 9:30 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:

Hi Justin,

What do you mean by "RTCP transport in the offer"? Are you referr= ing to the a=3Drtcp attribute, or?

Even if we mandate rtcp-mux within a BUNDLE group, the a=3Drtcp-mux attribu= te must still always be present - even if you know the remote endpoint supp= orts rtcp-mux (or, even if you have already negotiated usage of rtcp-mux).<= br>
Regards,

Christer
________________________________________
From: Justin Uberti [juberti@google.c= om]
Sent: Friday, 14 March 2014 6:26 PM
To: Magnus Westerlund
Cc: Christer Holmberg; rtcweb@ietf.org; Eric Rescorla
Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux

On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:= magnus.westerlund@ericsso= n.com>> wrote:
Hi,
(as individual)

Although this discussion really should be on MMUSIC, I am still
following up here. Anything we come to conclude here really need to go
to MMUSIC for confirmation.

Justin, I do agree that it appear unnecessarily of having to include an
RTCP transport in an OFFER when the offerer know the answerer is BUNDLE
capable. I am fine with that and think the rule needed here is something along the line of the below:

A BUNDLE supporting endpoint MUST implement a=3Drtcp-mux (that is already required). In any answer by a BUNDLE capable endpoint, it MUST NOT
change the usage of a=3Drtcp-mux. If it is present in the offer, it must be confirmed to be used in the answer, and if not present in the offer,
it MUST NOT be added in the answer. An BUNDLE capable endpoint is
RECOMMENDED to use a=3Drtcp-mux whenever suitable. Cases when it might not<= br> be suitable include, lack RTP payload types, or cases when RTCP traffic
is needed to be on its own transport flow (5-tuple) to enable QoS or
other traffic handling functionalities.

The reason for writing the rule like the above, is that then an endpoint can choose when creating an offer to renegotiate the use of a=3Drtcp-mux. For example due to it running out of available PTs.

Feedback on this proposal?

I am not OK with this. It just gets too complicated to deal with all the ca= ses, especially if with the provision that rtcp-mux can change during the s= ession.

I think Christer's current language is what we want - if you are going = to BUNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer = cannot do that, it needs to reject the BUNDLE.

I agree with your initial point though - if you know that both sides are go= ing to BUNDLE and rtcp-mux, it makes sense to allow them to do that from th= e outset, i.e. no need to include a RTCP transport in the offer.

--047d7bdc945ed8002204f493d034-- From nobody Fri Mar 14 09:48:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDC41A018A for ; Fri, 14 Mar 2014 09:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 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, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.547, 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 fFh657izQ6oq for ; Fri, 14 Mar 2014 09:48:36 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 646DB1A016F for ; Fri, 14 Mar 2014 09:48:36 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ik5so3109314vcb.0 for ; Fri, 14 Mar 2014 09:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HTypKET3gkcrip/S+Nb9rol80ovJoZ9lzOp1eGWHHMs=; b=fHCy+/IxtThTFtKDZLzDdUv6aSW1YIa9MWnMBifQDmwT+S4AvIzOLKwcrTxou9i1u4 jv1hUwktZXY+jf9yYshN9+uwNLiwRO9aeHxVDh1HbySrA7Nygvh/8OzI7/hUYh6fkm8D dUSAsxfl0xT6/eCTJiCRwjH8oVnSK4H34iet/g5LMuXI4AG6kKLhZEgZXeg8jPCCgp0N mkBKtYQst4PIXhWpAcyx11x7tQYk4kOltiBda4uC3pyOeH8qh4IdgDdu9hJnomsNarhc Q4J6VOxxhGHKouIJ3TWLL/gdgYyIjZD8xcVaX5zFhaSOjIFy81VsKubOpvxqPxxReJb1 aSRw== 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=HTypKET3gkcrip/S+Nb9rol80ovJoZ9lzOp1eGWHHMs=; b=hE3tIfTwMgA42W/crHLyUTQ2bF+Jdu9SOyTSFYcSPzvulm+CYWf38TImpH2ArJW/MG pcr3//jGP+TB7oXfHvirwuxXKJ8irmLna0X+4YN1mf9tTsgOmGX/2HxbAsyBPHGoMw79 2LZ8LXLf3w8yI/kGCJgOrzd3WSIprhs5KvSJtzIHKr5/+VdLsZ5pj/DunB20qRkBbKTC q3yFFYKhGw910UxikhCdQmcWwgcvCGClyuM+JC84DsFDn5fobVZBo8TnJeTftIjKd7Kn OZRciq1g9RN+5ECLAGpyxUyocQ6S4ZilD97QY4v9xXB9gy3QkcF+PyJLAk1CtbW7mDE1 1MRA== X-Gm-Message-State: ALoCoQnQaq/9vW/qFaT/DirnOZk1SRnhWj1BgIHxTTcaJRi6fvQ3UyvINCSgvkgIZ8Cel++QaFICFVGb1GWuraBpW1A6OylDtT2dx+T7IrjSw6LQGpHBS79VFeQpD1N+csjrPMd/UIOVuKqtSDz4MVofBwU4j8R6/JR4/3rEuUImhm3fcxpV0Mr6Rb1n/akS48nLI77g6jYB X-Received: by 10.221.74.65 with SMTP id yv1mr1034191vcb.31.1394815709069; Fri, 14 Mar 2014 09:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 09:48:07 -0700 (PDT) In-Reply-To: <5322FE7F.9040007@ericsson.com> References: <5322FE7F.9040007@ericsson.com> From: Justin Uberti Date: Fri, 14 Mar 2014 09:48:07 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11365638dddf9f04f493d6f3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/E4xwSZkIb3bqodW_5A7nzmuw4eE Cc: draft-ietf-rtcweb-jsep@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-jsep-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:48:43 -0000 --001a11365638dddf9f04f493d6f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the detailed review. We will work through these comments over the next few days. On Fri, Mar 14, 2014 at 6:05 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I did review the JSEP -06 prior to the meeting. Now I have had time to > write-up my comments. > > 1) Section 1): > > [W3C.WD-webrtc-20111027] > This is very old version of the API, please update to the currently > relevant version. > > 2) Section 3.4.1.1: > The m-line index is a zero-based index, referring to the Nth m-line in > the SDP. > > a) I think the above is a bit confusing. As a zero-based index would > mean that the first m=3D section would have index 0. Thus, the referring > to the Nth m-line in the SDP is unclear. Is N, the provided index, in > which case it would be the N+1th m-line. Please rewrite. > > b) I also wonder if one has to be clearer on what "the SDP" is. I assume > it is the one that has been generated by the agent, rather than the > latest sent or received? > > 3) Section 3.4.1.1: > "The MID uses the "media stream identification", as defined in > [RFC5888] , to identify the m-line." > > a spurious space after ref. > > 4) JSEP applications typically inform the browser to begin ICE gathering > via the information supplied to setLocalDescription, as this is where > the app specifies the number of media streams to gather candidates > for. > > I find the statement that ICE candidate gathering starts first with > setLocalDescription. Doesn't the created offer already contain local > candidates, thus one must have already gathered some candidates? To me > it appears reasonable to start gathering earlier, rather than later. > Thus, as soon as one create the PeerConnection object and have added any > MST to it or a data channel, one can start gathering. > > 5) Section 3.5.2: > In the parallel forking case where the Javascript application wishes > to simultaneously exchange media with multiple peers, the flow is > slightly more complex, but the Javascript application can follow the > strategy that [RFC3960] describes using UPDATE. (It is worth noting > that use cases where this is the desired behavior are very unusual.) > > I mostly react to the last sentence within the paragraph. I think the > poster child for semi-parallel forking was the MMORG that like to > establish PCs with anyone that is coming close in the virtual world. > Thus either needs to have a number of PCs on standby or have just one, > but treat that as parallel forking. And if you like to discourage the > later, then I think you might need to at least inform about the > possibility to have stand-by PCs. > > 6. Section 3.6: > > In the event that the local application state is reinitialized, > either due to a user reload of the page, or a decision within the > application to reload itself (perhaps to update to a new version), it > is possible to keep an existing session alive, via a process called > "rehydration". The explicit goal of rehydration is to carry out this > session resumption with no interaction with the remote side other > than normal call signaling messages. > > I think this paragraph makes two erronous statements: > a) "keep an existing session alive" > I think "resume" an existing session would be more correct. Because it > would be broken when the reload happens. > > b) "with no interaction with the remote side" > My understanding is that due to DTLS and key handling a DTLS > renegotiation will be required with the peer. Isn't also a signalling > exchange likely to be required due to change of local DTLS cert as well > as ICE candidates as parameters? Any other parameters that will be > required to exchanges when rehydrating? > > 7. Section 3.6: > Next, a new offer is > generated by the new PeerConnection; this offer will have new ICE and > possibly new DTLS-SRTP certificate fingerprints (since the old ICE > and SRTP state has been lost). > > I think this may require quite a bit more details. A forward pointer to > where you will specify that? > > 8. Section 3.6: > [OPEN ISSUE: EKR proposed an alternative rehydration approach where > the actual internal PeerConnection object in the browser was kept > alive for some time after the web page was killed and provided some > way for a new page to acquire the old PeerConnection object.] > > Can't we declare this open issue closed? I have seen no details on the > alternative proposal. Thus, lets work with the one that is present. > > 9. Section 4.1.1: > There is no discussion of how the bundle policies relate to the Data > Channels? Are they included or do they have a specific set of policies. > Please extend this to discuss this. > > 10. Section 4.1.3: > > This text doesn't appear to contain a requirement on that one MUST have > called setRemote prior to being able to call it. > > 11. Section 4.1.4.1: > While this could also be done with an inactive "pranswer", followed > by a sendrecv "answer", the initial "pranswer" leaves the offer- > answer exchange open, which means the caller cannot send an updated > offer during this time. > > Should one mention that also the callee can't send an offer without > doing a "final" answer? > > 12. Section 4.1.4.1 > > By the time the human has accepted the call and > triggered the new offer, it is likely that the ICE and DTLS > handshaking for all the channels will already be set up. > > Wouldn't the handshaking have "finished" rather than "set up"? > > 13. Section 4.1.4.2: > Rollback can only be used to cancel proposed changes; there is no > support for rolling back from a stable state to a previous stable > state. > > What is meant with "proposed changes"? From my side it is not clear how > much you can do after having performed a SetLocal or SetRemote. I think > these needs to be treated separately. > > For an offerer, they can createOffer, SetLocal, send to peer, receive > reject and then undo the SetLocal. That is straight forward, and if they > done the SetRemote, they would be consider in a new Stable state and > can't roll back anymore? > > For the answering side, it receive an offer, does SetRemote, > CreateAnswer, determines that it doesn't like it, the can undo the > SetRemote and send a reject message to offerer. > > But what about this case? it receive an offer, does SetRemote, > CreateAnswer, SetLocal and sends the message, then receive a reject from > the peer, because it didn't like the answer? Are the answerer then in a > stable state that can't be unrolled, or? > > 14. Section 4.1.5: > This API indirectly controls the candidate gathering process. When a > local description is supplied, and the number of transports currently > in use does not match the number of transports needed by the local > description, the PeerConnection will create transports as needed and > begin gathering candidates for them. > > Another part of an earlier question regarding what triggers ICE gathering= ? > > 15. Section 4.1.7: > TODO: Do we need to expose accessors for both the current and > proposed local description? > > This needs to be resolved, I don't know if I can answer this question. > > 16. Section 4.1.9: > > Should this section discuss that it might be browser that has overriding > controls regarding if other candidates then relay ones may be provided, > i.e. privacy mode? > > 17. Section 4.1.9: > Regardless of the configuration, the gathering process collects all > available candidates, but excluded candidates will not be surfaced in > onicecandidate callback or used for connectivity checks. > > Doesn't this result in both resource consumption and that the configured > TURN server will learn the external IP address and port for the client? > > 18. Section 5.2.1: > > Structure in relation between RTP media and DATA channel. Maybe you > should try to find a structure that makes the difference between the two > types of transport more clear, and what applies to the perspective. > > 19. Section 5.2.1: > > > o For the current default candidate, a "c=3D" line, as specific in > [RFC5245], Section 4.3., paragraph 6. If no candidates have been > gathered yet, the default candidate should be set to the 'null' > value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. > > What about host candidates? > > 20. Section 5.2.1: > The CNAME must be generated > in accordance with draft-rescorla-random-cname-00. [OPEN ISSUE: > How are CNAMEs specified for MSTs? Are they randomly generated > for each MediaStream? If so, can two MediaStreams be synced?] > > I think you should point to the RTP usage for this particular piece. > Because we do have text there both for the CNAME generation and how > CNAMES among MSTs and between PeerConnection. Likely to be changed soon > based on the mailing list discussion. > > 21. Section 5.2.1: > o [OPEN ISSUE: Handling of a=3Dimageattr] > > Yes, I think imageattr should be supported to give guidance on suitable > resolutions that an endpoint like to receive for a particular MST. > > 22. Section 5.2.1: > Once all m=3D sections have been generated, a session-level "a=3Dgroup= " > attribute MUST be added as specified in [RFC5888]. This attribute > MUST have semantics "BUNDLE", and MUST include the mid identifiers of > each m=3D section. > > Isn't this overriding BUNDLE as currently specified, forcing everything > into a single bundle group. Thus, preventing the bundle policies to work. > > 23. Section 5.2.2: > > o If any MediaStreamTracks have been added, and there exist m=3D > sections of the appropriate media type with no associated > MediaStreamTracks > > Isnt' the last a "MediaStreamTrack" rather than plural ones? > > 24. 5.2.3.3. VoiceActivityDetection > > If the "VoiceActivityDetection" constraint is specified, with a value > of "true", the offer MUST indicate support for silence suppression by > including comfort noise ("CN") codecs for each supported clock rate, > as specified in [RFC3389], Section 5.1. > > As currently specified this text requires the usage of a comfort noise > codec, currently there is no such on required. I think the "MUST" needs > to be rewritten. > > 25. Section 5.3.1: > Note > that for simplicity, the answerer MAY use different payload types > for codecs than the offerer, as it is not prohibited by > Section 6.1. > > I react to the word simplicity here. I never consider usage of different > PTs per direction anything simple. But, yes it is allowed by RFC 3264. > But I kind of protest to encourage the usage. > > 26. Section 5.3.2 etc. > > When will we see a first draft of the text in the sections: > 5.3.2, 5.3.3., 5.4, 5.5, 5.6, 5.7? > > I really like to see it prior to the Interim meeting. > > 27. Section 6: > Note: This section is still very early and is likely to significantly > change as we get a better understanding of a) the use cases for this > b) the implications at the protocol level c) feedback from > implementors on what they can do. > > Shouldn't this mention W3C discussion also? > > 28. Section 7 - Security Considerations: > > First of all there are no references to the Security Considerations or > architecture document. > > Secondly, I would like to have some security discussion on significant > issues with JSEP itself. Resource attacks on the local endpoint for > example? > > 29. section 10 > > There are a couple of draft references that are either published RFCs or > at least WG versions. Please update the reference list. > > 30. Section 10.2: > Looking at the spec, I think the following references are normative: > > [I-D.ietf-mmusic-trickle-ice] > Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: > Incremental Provisioning of Candidates for the Interactive > Connectivity Establishment (ICE) Protocol", draft-ietf- > mmusic-trickle-ice-00 (work in progress), March 2013. > > [I-D.ietf-rtcweb-data-protocol] > Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel > Protocol", draft-ietf-rtcweb-data-protocol-04 (work in > progress), February 2013. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11365638dddf9f04f493d6f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the detailed review. We will work through these= comments over the next few days.


<= div class=3D"gmail_quote">On Fri, Mar 14, 2014 at 6:05 AM, Magnus Westerlun= d <magnus.westerlund@ericsson.com> wrote:
Hi,

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

1) Section 1):

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

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

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

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

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

a spurious space after ref.

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

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

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

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

6. Section 3.6:

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

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

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

7. Section 3.6:
Next, a new offer is
=C2=A0 =C2=A0generated by the new PeerConnection; this offer will have new = ICE and
=C2=A0 =C2=A0possibly new DTLS-SRTP certificate fingerprints (since the old= ICE
=C2=A0 =C2=A0and SRTP state has been lost).

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

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

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

10. Section 4.1.3:

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

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

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

12. Section 4.1.4.1

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

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

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

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

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

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

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

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

Another part of an earlier question regarding what triggers ICE gathering?<= br>
15. Section 4.1.7:
=C2=A0 =C2=A0TODO: Do we need to expose accessors for both the current and<= br> =C2=A0 =C2=A0proposed local description?

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

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

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

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

18. Section 5.2.1:

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

19. Section 5.2.1:


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

What about host candidates?

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

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

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

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

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

Isn't this overriding BUNDLE as currently specified, forcing everything=
into a single bundle group. Thus, preventing the bundle policies to work.
23. Section 5.2.2:

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

Isnt' the last a "MediaStreamTrack" rather than plural ones?<= br>
24. 5.2.3.3. =C2=A0VoiceActivityDetection

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

As currently specified this text requires the usage of a comfort noise
codec, currently there is no such on required. I think the "MUST"= needs
to be rewritten.

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

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

26. Section 5.3.2 etc.

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

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

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

Shouldn't this mention W3C discussion also?

28. Section 7 - Security Considerations:

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

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

29. section 10

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

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

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

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

Cheers

Magnus Westerlund

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

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

--001a11365638dddf9f04f493d6f3-- From nobody Fri Mar 14 09:53:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3811A0180 for ; Fri, 14 Mar 2014 09:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a34Q1-VAXFhg for ; Fri, 14 Mar 2014 09:53:31 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA771A017E for ; Fri, 14 Mar 2014 09:53:31 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so2830473yho.32 for ; Fri, 14 Mar 2014 09:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1gh+GZVpxl/jeDIv5R7Agnkd+iYzccQBG3ZHQJVk4dw=; b=bTdjIV1qunxcE9X3mLC9onjyDTUPLp/6+vEZ2mzd+3swHuO0XCatdEZWZFol/zUQ0s gesNjyf2dnG6UlJLHfsHc/wWf3xzlqts9zbRUOfIbv62QAFOFlwdcEmK4k7Hcivm5pB+ WnghT+zsV0WRsGp86y/pXCJQeIpJjqv4gVJvCSJXQX/kp6p/NqK9IrhrpUxh+0T76T0I +W4X8bTuGxdk757rHte5jV/KT6SDL0yEP3KHCd0C+GYl8wrOubi7xJk33yrc+/VWXjuS oo6D0VW1dlOb6953QXiF27Z2y1WNqIJd/GLt4ajylJ9+ScZUYezLwLSbFYG62Z7/vhOl QGRg== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr12120775yhi.4.1394816004301; Fri, 14 Mar 2014 09:53:24 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 14 Mar 2014 09:53:24 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 14 Mar 2014 09:53:24 -0700 (PDT) In-Reply-To: References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> Date: Fri, 14 Mar 2014 09:53:24 -0700 Message-ID: From: Watson Ladd To: Justin Uberti Content-Type: multipart/alternative; boundary=485b397dce3376a90504f493e84c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/62Qu1_jhGnvpgdIjaL-jqSGM3_8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 14 Mar 2014 16:53:35 -0000 --485b397dce3376a90504f493e84c Content-Type: text/plain; charset=UTF-8 On Mar 14, 2014 9:44 AM, "Justin Uberti" wrote: > > > > > On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: >> >> On 2014-03-13 17:53, Martin Thomson wrote: >> > On 12 March 2014 01:29, Magnus Westerlund >> > wrote: >> >> I like to point out that the agreement and what is documented in >> >> rtp-usage is that WebRTC endpoint will have to make forwarded streams >> >> appear as locally originated. However, this as currently written does >> >> not apply to RTP middleboxes that interconnects multiple PeerConnections >> >> to form a multi-party session. This is deliberate to ensure that RTP >> >> topologies like RTP mixer and SFM do work on the RTP/RTCP level. >> > >> > I'm still not clear on whether a middlebox interoperating with a >> > WebRTC endpoint is obligated to respect these rules or not. I had >> > assumed that WebRTC is such a bully that they would be forced to. >> >> Well, I know Colin and I did put in quite some thought to make the >> WebRTC RTP usage rules such that you can use the common RTP middleboxes >> as long as you have the right front-end, i.e. DTLS-SRTP and signalling >> translation. >> >> > >> >> I am especially interested to know how you will "easy to apply manually" >> >> the synchronization. Can you please describe that. Because, that either >> >> requires an API call to tell the media framework, please consider the >> >> following CNAMES as equivalent, or some other method of telling the >> >> media framework that these different MST are actually originating from a >> >> common clock base. >> > In WebRTC, this would be: >> > >> > var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0]; >> > var video = pc2.getRemoteStreams()[0].getVideoTracks()[0]; >> > var synchronizedStream = new MediaStream(audio, video); >> > >> > We'd have to say that this implies a statement about the clock base of >> > the tracks being the same. ... and that this statement could be >> > wrong. >> >> I think this looks dangerous. If you default the assumption that >> different CNAMEs of the MST you add are actually sharing clock base, >> then a lot of basic programs that may group MST from different PCs into >> one MS for convenience are going to cause serious issue in the media >> frameworks, when they attempt to synchronize things. >> >> > >> > As far as it goes, I'm sure that other systems could build a similar >> > function, but none of those are standardized. >> > >> >> I protested about this, not to lower the users privacy, but over the >> >> concern that this was raised without providing a case where it was >> >> obvious that the user's privacy was impacted. Martin, you said that you >> >> would think about it, and the next statement was lets change it, without >> >> providing any motivation why the concern was significant. >> > >> > I'm sorry about that, I thought about it, but didn't want to waste >> > everyone's time (mine included) with an essay on the subject. >> > >> >> Having considered this a bit more, I do think the risk to privacy out >> weighs the other concerns, as long as the API and its handling can be >> sorted out, I don't think the above is sufficient to get good >> functionality. >> >> My understanding is that the risk to privacy exist when one have one JS >> application enabling communication in different contexts during the same >> application session. In cases where there might be participants in the >> >> different contexts that could link the same end-point and thus human >> user to different participant IDs (that otherwise are anonymous). Thus >> revealing privacy concerns. As it would take the application designer to >> take this risk into consideration to avoid it, I feel safer if the >> application designer would need to take active measurements to perform >> linkage. >> >> >> I will wait an see if there are other inputs on this within the next >> week. If nothing arises I will propose a text change to the rtp-usage to >> address this. >> > > At an implementation level, one could imagine at least 3 policies for generating CNAMEs: > a) per-session (i.e. per-PeerConnection) > b) per-page (i.e. shared between all PCs on a page) > c) per-page, persistent (i.e. shared between all PCs on a page, including across page loads) > > While we seem to agree that a) is the right solution for CNAMEs, it is worth pointing out that we (Chrome) are currently doing c) for DTLS certificates, to avoid performance problems with cert generation at page load. Ergo, this linkability concern already exists, and I don't think it is easy to solve it in the default case. There have been some proposals to allow generation/storage of unique certs to prevent this linkability, but this will require app input. > One exponentiation, fixed base, per certificate. Use an addition multichain. Cert generation is cheap with ECDSA. Sincerely, Watson Ladd > Ergo, we might want to match the DTLS behavior (i.e. generate unique CNAMEs only when the certs are unique), to ensure we treat linkability consistently. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --485b397dce3376a90504f493e84c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 14, 2014 9:44 AM, "Justin Uberti" <juberti@google.com> wrote:
>
>
>
>
> On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> w= rote:
>>
>> On 2014-03-13 17:53, Martin Thomson wrote:
>> > On 12 March 2014 01:29, Magnus Westerlund
>> > <magnus.= westerlund@ericsson.com> wrote:
>> >> I like to point out that the agreement and what is docume= nted in
>> >> rtp-usage is that WebRTC endpoint will have to make forwa= rded streams
>> >> appear as locally originated. However, this as currently = written does
>> >> not apply to RTP middleboxes that interconnects multiple = PeerConnections
>> >> to form a multi-party session. This is deliberate to ensu= re that RTP
>> >> topologies like RTP mixer and SFM do work on the RTP/RTCP= level.
>> >
>> > I'm still not clear on whether a middlebox interoperating= with a
>> > WebRTC endpoint is obligated to respect these rules or not. = =C2=A0I had
>> > assumed that WebRTC is such a bully that they would be forced= to.
>>
>> Well, I know Colin and I did put in quite some thought to make the=
>> WebRTC RTP usage rules such that you can use the common RTP middle= boxes
>> as long as you have the right front-end, i.e. DTLS-SRTP and signal= ling
>> translation.
>>
>> >
>> >> I am especially interested to know how you will "eas= y to apply manually"
>> >> the synchronization. Can you please describe that. Becaus= e, that either
>> >> requires an API call to tell the media framework, please = consider the
>> >> following CNAMES as equivalent, or some other method of t= elling the
>> >> media framework that these different MST are actually ori= ginating from a
>> >> common clock base.
>> > In WebRTC, this would be:
>> >
>> > var audio =3D pc1.getRemoteStreams()[0].getAudioTracks()[0];<= br> >> > var video =3D pc2.getRemoteStreams()[0].getVideoTracks()[0];<= br> >> > var synchronizedStream =3D new MediaStream(audio, video);
>> >
>> > We'd have to say that this implies a statement about the = clock base of
>> > the tracks being the same. =C2=A0... and that this statement = could be
>> > wrong.
>>
>> I think this looks dangerous. If you default the assumption that >> different CNAMEs of the MST you add are actually sharing clock bas= e,
>> then a lot of basic programs that may group MST from different PCs= into
>> one MS for convenience are going to cause serious issue in the med= ia
>> frameworks, when they attempt to synchronize things.
>>
>> >
>> > As far as it goes, I'm sure that other systems could buil= d a similar
>> > function, but none of those are standardized.
>> >
>> >> I protested about this, not to lower the users privacy, b= ut over the
>> >> concern that this was raised without providing a case whe= re it was
>> >> obvious that the user's privacy was impacted. Martin,= you said that you
>> >> would think about it, and the next statement was lets cha= nge it, without
>> >> providing any motivation why the concern was significant.=
>> >
>> > I'm sorry about that, I thought about it, but didn't = want to waste
>> > everyone's time (mine included) with an essay on the subj= ect.
>> >
>>
>> Having considered this a bit more, I do think the risk to privacy = out
>> weighs the other concerns, as long as the API and its handling can= be
>> sorted out, I don't think the above is sufficient to get good<= br> >> functionality.
>>
>> My understanding is that the risk to privacy exist when one have o= ne JS
>> application enabling communication in different contexts during th= e same
>> application session. In cases where there might be participants in= the
>>
>> different contexts that could link the same end-point and thus hum= an
>> user to different participant IDs (that otherwise are anonymous). = Thus
>> revealing privacy concerns. As it would take the application desig= ner to
>> take this risk into consideration to avoid it, I feel safer if the=
>> application designer would need to take active measurements to per= form
>> linkage.
>>
>>
>> I will wait an see if there are other inputs on this within the ne= xt
>> week. If nothing arises I will propose a text change to the rtp-us= age to
>> address this.
>>
>
> At an implementation level, one could imagine at least 3 policies for = generating CNAMEs:
> a) per-session (i.e. per-PeerConnection)
> b) per-page (i.e. shared between all PCs on a page)
> c) per-page, persistent (i.e. shared between all PCs on a page, includ= ing across page loads)
>
> While we seem to agree that a) is the right solution for CNAMEs, it is= worth pointing out that we (Chrome) are currently doing c) for DTLS certif= icates, to avoid performance problems with cert generation at page load. Er= go, this linkability concern already exists, and I don't think it is ea= sy to solve it in the default case. There have been some proposals to allow= generation/storage of unique certs to prevent this linkability, but this w= ill require app input.
>

One exponentiation, fixed base, per certificate. Use an addi= tion multichain. Cert generation is cheap with ECDSA.

Sincerely,
Watson Ladd
> Ergo, we might want to match the DTLS behavior (i.e. generate unique C= NAMEs only when the certs are unique), to ensure we treat linkability consi= stently.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--485b397dce3376a90504f493e84c-- From nobody Fri Mar 14 10:16:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6611A0176 for ; Fri, 14 Mar 2014 10:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6DxXjkRdrYr for ; Fri, 14 Mar 2014 10:16:41 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id CBA931A0170 for ; Fri, 14 Mar 2014 10:16:40 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so2910145wiw.11 for ; Fri, 14 Mar 2014 10:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UMnE+Nek5Cv+a3qvBPx+UOBVSOydRBveMRzP+u5ARws=; b=FJfWGdwBXoLv9AbysNIV6mke48O1WIWBEDtCRzH9dsRnwkR+ZHxm3UZsLbqZDGEevP S09Ko82AuJGlFVfGhKYrXBd7nKBxLbre95gWtapGAFhXbdeguKYkos7dkfkUw098Z5ZD tAfs/7ZOAG0AR2fdmVMotGrEnchuR/grb/xSA5zDTr2nSHED5lR1DCFjx/XFZk2fg0EN 37u7hJaf1TWZkgPhDusyP2yZwyTxYhY42vGjg8X2v8RJVhu6FlrJuVQsYqBvTEXjMjzZ yYOVooFAInAJ4xoQhnYxGJT9ySkMDRCM38xh1pUgaqUgWg1sGN3dhfJoP8WOjTtEs9qF syvg== MIME-Version: 1.0 X-Received: by 10.180.185.197 with SMTP id fe5mr7088348wic.56.1394817393520; Fri, 14 Mar 2014 10:16:33 -0700 (PDT) Received: by 10.227.10.196 with HTTP; Fri, 14 Mar 2014 10:16:33 -0700 (PDT) In-Reply-To: References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> Date: Fri, 14 Mar 2014 10:16:33 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DyVg7Gc9p5bm_I91-dQBOQM8cMg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 14 Mar 2014 17:16:42 -0000 On 14 March 2014 09:44, Justin Uberti wrote: > While we seem to agree that a) is the right solution for CNAMEs, it is worth > pointing out that we (Chrome) are currently doing c) for DTLS certificates, > to avoid performance problems with cert generation at page load. Firefox does 1-per PC. There are plans to allow more granular control over this (following ekr's proposal), but that's currently low priority. There are plenty of other places where we can make performance improvements. From nobody Fri Mar 14 10:40:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEB71A01A0 for ; Fri, 14 Mar 2014 10:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 7-1CGkOfP-4I for ; Fri, 14 Mar 2014 10:40:07 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED711A017C for ; Fri, 14 Mar 2014 10:40:07 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id cz12so3040784veb.16 for ; Fri, 14 Mar 2014 10:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z92DMLz8JjKpEQi/YIzY8ipwnTazhSfuFwQgTWVB+Lk=; b=BA94M5YzVWE/QyJtsCs/3I7u4XtOjSyDLeTuDAs5FYStGANZex9daP4WL02bimuEZp 03xrgeyY4+uEiTsRUyuoCUaDUpX527DW0hhVGWvSR6VDfYMMEQ7vGIUYxWjl2XQqfXMn /Pu/8tPsGAzLX6nJcZpBRaetLoeh6S6pTWDZz+Swx8Hc86V0OKe/bEi0+fcr/iyikhff i1CaahggvUMODRu/Or/MOtzpsAARrNqm2KzDBj9pX1rYOYKtf8oAh5wV7qVxvnBMaYzi YFZdSfxr4dQSMHvP8Lndwjl+VOM9JY0RsNs/E+ORveWfzXc6lEitEwFykE7F1wX/RQsB GC4A== 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=Z92DMLz8JjKpEQi/YIzY8ipwnTazhSfuFwQgTWVB+Lk=; b=FoYouE5pUodcCtk1YWDq3Y3LmxZ5D+0RU+bymFiSuTNcKXiz44W/UFZ2JQTotrblmV qYIej0KiqtFJSm1325ECAVAj+EJVYXhocgcAC8jL831T8Rnfipx+nd2iXrLCYXfH6eHl L2mPP4oYVhPX3qmY4C2P9/jL16OojjPviqrMHOi/48+N7u0JOBILIoki8zAoPjelsgs/ kWgb93lI1EWKB1mH+jbH1kUkxOiNk7VycWU+B55K7K8Vp3rUKpi0x+8RvctDaZPIuxls rAgjcCETJls4xM6HLpRNyzzs4EhUgOdoiLL10N6Mn5Nab7xMPH8G2xiz8xhTx4cJn8SC 8Ieg== X-Gm-Message-State: ALoCoQnlMsAbqmacWxsHW+OvbqrfqcjK0kc6IoS6wn0E45YeNAMHJKE7kphVhQf8j0Doz1PNR9iS9GEI8PI6uGsOQTtKaRKDO1WWNCc1yJMS1ynzp1OwQLQBSrqLJRC23haVjQ4fimhuSfPwIJd5mmh960L4KGfnQNaf24L9Qgts+rCBzskyPy7561cjK/nLBZLWhkbHMsXe X-Received: by 10.52.124.66 with SMTP id mg2mr66387vdb.50.1394818800169; Fri, 14 Mar 2014 10:40:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 10:32:02 -0700 (PDT) In-Reply-To: References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> From: Justin Uberti Date: Fri, 14 Mar 2014 10:32:02 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=bcaec52997451c4dbd04f4948f03 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tPtsVy4d47fxHs6_k-bKgiy76zE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 14 Mar 2014 17:40:10 -0000 --bcaec52997451c4dbd04f4948f03 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd wrote: > > On Mar 14, 2014 9:44 AM, "Justin Uberti" wrote: > > > > > > > > > > On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> > >> On 2014-03-13 17:53, Martin Thomson wrote: > >> > On 12 March 2014 01:29, Magnus Westerlund > >> > wrote: > >> >> I like to point out that the agreement and what is documented in > >> >> rtp-usage is that WebRTC endpoint will have to make forwarded streams > >> >> appear as locally originated. However, this as currently written does > >> >> not apply to RTP middleboxes that interconnects multiple > PeerConnections > >> >> to form a multi-party session. This is deliberate to ensure that RTP > >> >> topologies like RTP mixer and SFM do work on the RTP/RTCP level. > >> > > >> > I'm still not clear on whether a middlebox interoperating with a > >> > WebRTC endpoint is obligated to respect these rules or not. I had > >> > assumed that WebRTC is such a bully that they would be forced to. > >> > >> Well, I know Colin and I did put in quite some thought to make the > >> WebRTC RTP usage rules such that you can use the common RTP middleboxes > >> as long as you have the right front-end, i.e. DTLS-SRTP and signalling > >> translation. > >> > >> > > >> >> I am especially interested to know how you will "easy to apply > manually" > >> >> the synchronization. Can you please describe that. Because, that > either > >> >> requires an API call to tell the media framework, please consider the > >> >> following CNAMES as equivalent, or some other method of telling the > >> >> media framework that these different MST are actually originating > from a > >> >> common clock base. > >> > In WebRTC, this would be: > >> > > >> > var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0]; > >> > var video = pc2.getRemoteStreams()[0].getVideoTracks()[0]; > >> > var synchronizedStream = new MediaStream(audio, video); > >> > > >> > We'd have to say that this implies a statement about the clock base of > >> > the tracks being the same. ... and that this statement could be > >> > wrong. > >> > >> I think this looks dangerous. If you default the assumption that > >> different CNAMEs of the MST you add are actually sharing clock base, > >> then a lot of basic programs that may group MST from different PCs into > >> one MS for convenience are going to cause serious issue in the media > >> frameworks, when they attempt to synchronize things. > >> > >> > > >> > As far as it goes, I'm sure that other systems could build a similar > >> > function, but none of those are standardized. > >> > > >> >> I protested about this, not to lower the users privacy, but over the > >> >> concern that this was raised without providing a case where it was > >> >> obvious that the user's privacy was impacted. Martin, you said that > you > >> >> would think about it, and the next statement was lets change it, > without > >> >> providing any motivation why the concern was significant. > >> > > >> > I'm sorry about that, I thought about it, but didn't want to waste > >> > everyone's time (mine included) with an essay on the subject. > >> > > >> > >> Having considered this a bit more, I do think the risk to privacy out > >> weighs the other concerns, as long as the API and its handling can be > >> sorted out, I don't think the above is sufficient to get good > >> functionality. > >> > >> My understanding is that the risk to privacy exist when one have one JS > >> application enabling communication in different contexts during the same > >> application session. In cases where there might be participants in the > >> > >> different contexts that could link the same end-point and thus human > >> user to different participant IDs (that otherwise are anonymous). Thus > >> revealing privacy concerns. As it would take the application designer to > >> take this risk into consideration to avoid it, I feel safer if the > >> application designer would need to take active measurements to perform > >> linkage. > >> > >> > >> I will wait an see if there are other inputs on this within the next > >> week. If nothing arises I will propose a text change to the rtp-usage to > >> address this. > >> > > > > At an implementation level, one could imagine at least 3 policies for > generating CNAMEs: > > a) per-session (i.e. per-PeerConnection) > > b) per-page (i.e. shared between all PCs on a page) > > c) per-page, persistent (i.e. shared between all PCs on a page, > including across page loads) > > > > While we seem to agree that a) is the right solution for CNAMEs, it is > worth pointing out that we (Chrome) are currently doing c) for DTLS > certificates, to avoid performance problems with cert generation at page > load. Ergo, this linkability concern already exists, and I don't think it > is easy to solve it in the default case. There have been some proposals to > allow generation/storage of unique certs to prevent this linkability, but > this will require app input. > > > > One exponentiation, fixed base, per certificate. Use an addition > multichain. Cert generation is cheap with ECDSA. > You're going to have to explain a bit more for me to grok this. Also, define 'cheap', especially on ARM CPUs. Currently RSA generation on best-in-class ARM CPUs is 500 ms for 1024-bit, 2 seconds for 2048-bit. That is a problem. --bcaec52997451c4dbd04f4948f03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:


On Mar 14, 2014 9:44 AM, "Justin Uberti" <juberti@google.com> wrote:
>
>
>
>
> On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund <magnus.westerlund@eric= sson.com> wrote:
>>
>> On 2014-03-13 17:53, Martin Thomson wrote:
>> > On 12 March 2014 01:29, Magnus Westerlund
>> > <magnus.westerlund@ericsson.com> wrote:
>> >> I like to point out that the agreement and what is docume= nted in
>> >> rtp-usage is that WebRTC endpoint will have to make forwa= rded streams
>> >> appear as locally originated. However, this as currently = written does
>> >> not apply to RTP middleboxes that interconnects multiple = PeerConnections
>> >> to form a multi-party session. This is deliberate to ensu= re that RTP
>> >> topologies like RTP mixer and SFM do work on the RTP/RTCP= level.
>> >
>> > I'm still not clear on whether a middlebox interoperating= with a
>> > WebRTC endpoint is obligated to respect these rules or not. = =C2=A0I had
>> > assumed that WebRTC is such a bully that they would be forced= to.
>>
>> Well, I know Colin and I did put in quite some thought to make the=
>> WebRTC RTP usage rules such that you can use the common RTP middle= boxes
>> as long as you have the right front-end, i.e. DTLS-SRTP and signal= ling
>> translation.
>>
>> >
>> >> I am especially interested to know how you will "eas= y to apply manually"
>> >> the synchronization. Can you please describe that. Becaus= e, that either
>> >> requires an API call to tell the media framework, please = consider the
>> >> following CNAMES as equivalent, or some other method of t= elling the
>> >> media framework that these different MST are actually ori= ginating from a
>> >> common clock base.
>> > In WebRTC, this would be:
>> >
>> > var audio =3D pc1.getRemoteStreams()[0].getAudioTracks()[0];<= br> >> > var video =3D pc2.getRemoteStreams()[0].getVideoTracks()[0];<= br> >> > var synchronizedStream =3D new MediaStream(audio, video);
>> >
>> > We'd have to say that this implies a statement about the = clock base of
>> > the tracks being the same. =C2=A0... and that this statement = could be
>> > wrong.
>>
>> I think this looks dangerous. If you default the assumption that >> different CNAMEs of the MST you add are actually sharing clock bas= e,
>> then a lot of basic programs that may group MST from different PCs= into
>> one MS for convenience are going to cause serious issue in the med= ia
>> frameworks, when they attempt to synchronize things.
>>
>> >
>> > As far as it goes, I'm sure that other systems could buil= d a similar
>> > function, but none of those are standardized.
>> >
>> >> I protested about this, not to lower the users privacy, b= ut over the
>> >> concern that this was raised without providing a case whe= re it was
>> >> obvious that the user's privacy was impacted. Martin,= you said that you
>> >> would think about it, and the next statement was lets cha= nge it, without
>> >> providing any motivation why the concern was significant.=
>> >
>> > I'm sorry about that, I thought about it, but didn't = want to waste
>> > everyone's time (mine included) with an essay on the subj= ect.
>> >
>>
>> Having considered this a bit more, I do think the risk to privacy = out
>> weighs the other concerns, as long as the API and its handling can= be
>> sorted out, I don't think the above is sufficient to get good<= br> >> functionality.
>>
>> My understanding is that the risk to privacy exist when one have o= ne JS
>> application enabling communication in different contexts during th= e same
>> application session. In cases where there might be participants in= the
>>
>> different contexts that could link the same end-point and thus hum= an
>> user to different participant IDs (that otherwise are anonymous). = Thus
>> revealing privacy concerns. As it would take the application desig= ner to
>> take this risk into consideration to avoid it, I feel safer if the=
>> application designer would need to take active measurements to per= form
>> linkage.
>>
>>
>> I will wait an see if there are other inputs on this within the ne= xt
>> week. If nothing arises I will propose a text change to the rtp-us= age to
>> address this.
>>
>
> At an implementation level, one could imagine at least 3 policies for = generating CNAMEs:
> a) per-session (i.e. per-PeerConnection)
> b) per-page (i.e. shared between all PCs on a page)
> c) per-page, persistent (i.e. shared between all PCs on a page, includ= ing across page loads)
>
> While we seem to agree that a) is the right solution for CNAMEs, it is= worth pointing out that we (Chrome) are currently doing c) for DTLS certif= icates, to avoid performance problems with cert generation at page load. Er= go, this linkability concern already exists, and I don't think it is ea= sy to solve it in the default case. There have been some proposals to allow= generation/storage of unique certs to prevent this linkability, but this w= ill require app input.
>

One exponentiation, fixed base, per certificate.= Use an addition multichain. Cert generation is cheap with ECDSA.

You're going to have to explain a bit more for me to grok t= his.

Also, define 'cheap', especially on ARM CPUs. C= urrently RSA generation on best-in-class ARM CPUs is 500 ms for 1024-bit, 2= seconds for 2048-bit. That is a problem.

--bcaec52997451c4dbd04f4948f03-- From nobody Fri Mar 14 10:40:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CC71A018E for ; Fri, 14 Mar 2014 10:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 2LR3JyVYpFdw for ; Fri, 14 Mar 2014 10:40:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8648A1A0194 for ; Fri, 14 Mar 2014 10:40:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c8-53233f0c4990 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A0.90.10875.C0F33235; Fri, 14 Mar 2014 18:40:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 18:40:28 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAAIVkAIABaJQggAAqmoCAAPXJ+4AAIb6AgAB9YgCAABFvsf//9DuAAAPsbrM= Date: Fri, 14 Mar 2014 17:40:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D215B4C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D215AAB@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjS6vvXKwwcHnLBYrXp9jt9g6Vchi 7b92dgdmjwWbSj2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8bvo0YFU6Ur1h5SbmD8KdrF yMkhIWAisfnfAyYIW0ziwr31bF2MXBxCAocYJXo/XGWBcJYwSuxasQXI4eBgE7CQ6P6nDdIg IqAm8XDWLlYQm1mgWmLbin9gg4QFjCWmdE5mg6gxkZg78TXYHBGBeYwS12adBGtgEVCV2Nz4 FKyBV8BXYvWFBVCbn7JLbLnVygiS4BQIlJg58TdYAyPQed9PrWGC2CYucevJfKizBSSW7DnP DGGLSrx8/I8VwlaUaH/awAhRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELS MgtJywJGllWM7LmJmTnp5YabGIExc3DLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QD44RpPEUFH0Nijfzmf9mmw9k/73H81He3FosXRon6rloXv9uQQe5X 2KVSzW7ddZ+TTW/+3CAhsym7ZF/61FuuCZdTGwP3xNyV1W/vucWkkbG+5v+mzXa7mT19WA5/ u+t2fXXWykRhsdnanwxnTZv8/dGTl8yt76Y+uNCvtn8dn+oCU5n+J7zBPEosxRmJhlrMRcWJ AMQKBoVnAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JU0i-H0nfl1HLi_dmZzmuvsz1aU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 17:40:41 -0000 Hi, > By "RTCP transport in the offer", I mean separate ICE candidates generate= d for a RTCP ICE component, the original problem that I was proposing to so= lve. Ok. But, again, we do have a decision that we are not going to specify procedur= es based on pre-knoweldge of BUNDLE support by the answerer. Or, at least t= hat was the outcome in London, I guess it still has to be verified on the l= ist. > I agree the rtcp-mux attribute must always be present if you are going to= do rtcp-mux. Good :) Regards, Christer On Fri, Mar 14, 2014 at 9:30 AM, Christer Holmberg > wrote: Hi Justin, What do you mean by "RTCP transport in the offer"? Are you referring to the= a=3Drtcp attribute, or? Even if we mandate rtcp-mux within a BUNDLE group, the a=3Drtcp-mux attribu= te must still always be present - even if you know the remote endpoint supp= orts rtcp-mux (or, even if you have already negotiated usage of rtcp-mux). Regards, Christer ________________________________________ From: Justin Uberti [juberti@google.com] Sent: Friday, 14 March 2014 6:26 PM To: Magnus Westerlund Cc: Christer Holmberg; rtcweb@ietf.org; Eric Rescor= la Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund >> wrote: Hi, (as individual) Although this discussion really should be on MMUSIC, I am still following up here. Anything we come to conclude here really need to go to MMUSIC for confirmation. Justin, I do agree that it appear unnecessarily of having to include an RTCP transport in an OFFER when the offerer know the answerer is BUNDLE capable. I am fine with that and think the rule needed here is something along the line of the below: A BUNDLE supporting endpoint MUST implement a=3Drtcp-mux (that is already required). In any answer by a BUNDLE capable endpoint, it MUST NOT change the usage of a=3Drtcp-mux. If it is present in the offer, it must be confirmed to be used in the answer, and if not present in the offer, it MUST NOT be added in the answer. An BUNDLE capable endpoint is RECOMMENDED to use a=3Drtcp-mux whenever suitable. Cases when it might not be suitable include, lack RTP payload types, or cases when RTCP traffic is needed to be on its own transport flow (5-tuple) to enable QoS or other traffic handling functionalities. The reason for writing the rule like the above, is that then an endpoint can choose when creating an offer to renegotiate the use of a=3Drtcp-mux. For example due to it running out of available PTs. Feedback on this proposal? I am not OK with this. It just gets too complicated to deal with all the ca= ses, especially if with the provision that rtcp-mux can change during the s= ession. I think Christer's current language is what we want - if you are going to B= UNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer cann= ot do that, it needs to reject the BUNDLE. I agree with your initial point though - if you know that both sides are go= ing to BUNDLE and rtcp-mux, it makes sense to allow them to do that from th= e outset, i.e. no need to include a RTCP transport in the offer. From nobody Fri Mar 14 10:57:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815081A019E for ; Fri, 14 Mar 2014 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=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 yksmBePxAp7x for ; Fri, 14 Mar 2014 10:57:07 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC11A017C for ; Fri, 14 Mar 2014 10:57:06 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so2459773wes.17 for ; Fri, 14 Mar 2014 10:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n8EelCPfFA+A+q4zQ4oMRP+mhaiaTJIoqbRQbXkFKCE=; b=qEAssVLbYLNWg1tcVy3ohZV625AlcjJgVv7nAO75KAmGVdOM23KUljvhubT46jofF1 8WPhgptXoNTCkMKrA1MHjb6khKnIMbD++ZsNvDEzKmdt/0NPl6dogmhDBDbdYEYc8Gzd hJC8uBkz06JuPfC0fw/7jIELzwSirMG6yyYlhpt5vCB04wzXZLDrOJGXaQ2aEb1KNo0B OglG5UX3tQ0ZN+nhaqKzyom2Qsh60EqiEOnXyECrObmw+S4aUXm2DcMg0p/j9kMLrq59 XuX2Ry/k3ugD1cEThCqDYPepI9nWEhR2iDZoERINJP7yIjicA0yLT+sCgFVK7XWKOBbs i82w== X-Received: by 10.194.63.145 with SMTP id g17mr2934522wjs.72.1394819819170; Fri, 14 Mar 2014 10:56:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.161.66 with HTTP; Fri, 14 Mar 2014 10:56:39 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1CF8C0FD@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Fri, 14 Mar 2014 10:56:39 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bacb502d8f03404f494cb47 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LuHg5dWQ-ZMvSx4qd-LwaoyL4io Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 14 Mar 2014 17:57:10 -0000 --047d7bacb502d8f03404f494cb47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Justin said: "Overall this feels to me like something that needs some thought to figure out all the interactions between the API, the signaling plane, and the media plane. As such I am inclined to leave this out of 1.0." [BA] I agree. "It's not clear to me what the interactions are between the signaling and media plane when this occurs. That is, if I do doohickey.active =3D false, should that cause a=3Drecvonly signaling and a TMMBN notification that the track is paused? I am concerned that things can get out of sync (i.e. what happens if we get TMMBR indicating resume, but signaling is still a=3Drecvonly)?" [BA] A few thoughts: a. Even though TMMBR/TMMBN is mandatory-to-implement in the RTP usage document, I don't think we can assume that the pause/resume will be supported by all mixers.. It therefore probably isn't a good idea for a browser to automatically send a TMMBN 0 indication when setting rtpsender.active =3D false. Since the application might or might not use S= DP for signaling, this is probably something that needs to be under application control. BTW, Section 6.3, isn't clear about the response to an unsolicited TMMBN (TMMBR 0?). b. As described in Section 1, pause/resume is for use in scenarios where signaling might not meet the performance requirements. Due to the differing transport characteristics of RTCP and signaling over reliable transport, trying to use both pause/resume and signaling is quite likely to result in them being out of sync, so my assumption was that an application wishing to support pause/resume would not choose to use signaling for the same purpose. There is also the potential for conflict between codec-specific messages (e.g. layer drop in H.264/SVC) and some potential uses of pause/resume (e.g. unsolicited TMMBN to indicate layer pause in multi-stream SVC). Where there are conflicts, my assumption would be that signaling and codec-specific messages should win. On Fri, Mar 14, 2014 at 9:15 AM, Justin Uberti wrote: > > > > On Fri, Mar 14, 2014 at 4:25 AM, Stefan H=E5kansson LK < > stefan.lk.hakansson@ericsson.com> wrote: > >> On 2014-03-12 21:56, Justin Uberti wrote: >> > Agreed. >> >> I may well be that the pause/resume doc will not be ready in time, so it >> from that aspect is a bad idea. What about just stating that TMMBN/TMMBR >> 0 meaning pause should be supported? >> > > It's not clear to me what the interactions are between the signaling and > media plane when this occurs. That is, if I do doohickey.active =3D false= , > should that cause a=3Drecvonly signaling and a TMMBN notification that th= e > track is paused? I am concerned that things can get out of sync (i.e. wha= t > happens if we get TMMBR indicating resume, but signaling is still > a=3Drecvonly)? > > >> > Aren't there also patent declarations against this doc from >> > multiple holders? >> >> I've not looked into that, but I deliberately chose to propose the "old" >> TMMBN 0 way to signal that is mentioned in [1] (and not any of the "new" >> signaling in [1]). >> > > OK. > > >> >> > >> > While SDP will likely be removed from the API in the future, the >> > replacement would be a app-specific message sent over websockets, whic= h >> > seems like it would work just fine. >> >> s/would/could/: I don't think this has been discussed or agreed (and >> websocket is of course just an example). >> > > Right, the whole thing is an example, but the point is that the new API > directions don't really affect this particular problem. > >> >> I think it is worthwhile to push this kind of signaling into the media >> plane if possible. For example, this would enable the UA to save >> transmission/battery even if the app is badly written. >> >> As an example: if a MST sent over a PC is not used in any way at the >> receiving end, the receiving end UA could signal TMMBR 0 to tell the >> sending UA to not send. Sure, the receiving UA could also fire a >> "negotiationneeded" event, but maybe the app doesn't listen. >> > > True, if the app doesn't perform the necessary signaling, things are not > going to work, but that applies to a lot of operations on the > PeerConnection. > > Overall this feels to me like something that needs some thought to figure > out all the interactions between the API, the signaling plane, and the > media plane. As such I am inclined to leave this out of 1.0. > >> >> > >> > >> > On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba < >> bernard.aboba@gmail.com >> > > wrote: >> > >> > While I do like the pause/resume draft, having core RTCWEB WG >> > documents (such as RTP Usage) depend on it seems like a bit of a >> > stretch. After all, the document was only adopted last week, and i= t >> > is a rare IETF WG document that can go from a -00 WG draft to >> > publication as an RFC in under a year. >> > >> > >> > On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=E5kansson LK >> > > > > wrote: >> > >> > Hi, >> > >> > at the IETF last week there was consensus in the AVTEXT WG >> > meeting to >> > adopt the pause/resume draft [1] as a WG draft. >> > >> > In rtcweb/webrtc we're have the situation that we're discussin= g >> so >> > called "doo-hickeys" as an API surface where the web app >> > (amongst other >> > things) can pause and resume the sending of a track. This can >> > be signaled with the direction attribute and a SDP O/A exchang= e >> > (and the >> > app pausing/resuming sending of a track would presumably lead >> to a >> > "negotiationneeded" event being fired). >> > >> > But I think we should in addition require the browser to signa= l >> it >> > according to one of the methods in [1] (e.g. TMMBN =3D 0), and >> also >> > understand that signaling (a browser receiving TMMBN =3D 0 mus= t >> > know that >> > the other end-point will pause sending). >> > >> > My argument is that we know that many dislike SDP in rtcweb, >> and a >> > likely development is that it will be removed in a later >> version. My >> > speculation is that signaling as outlined in [1] will then be >> > used for >> > pause/resume. If we support this from the beginning earlier >> > implementations could more easily interop with those later >> versions. >> > >> > >> > Stefan >> > >> > [1] >> > >> https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.tx= t >> > >> > _______________________________________________ >> > 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 >> > >> > >> >> > --047d7bacb502d8f03404f494cb47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Justin said:=A0

"Overall this feels to me like so= mething that needs some thought to figure out all the interactions between = the API, the signaling plane, and the media plane. As such I am inclined to= leave this out of 1.0."

[BA] I agree.=A0


"It'= s not clear to me what the interactions are between the signaling and media= plane when this occurs. That is, if I do doohickey.active =3D false, shoul= d that cause a=3Drecvonly signaling and a TMMBN notification that the track= is paused? I am concerned that things can get out of sync (i.e. what happe= ns if we get TMMBR indicating resume, but signaling is still a=3Drecvonly)?= "

[BA] A few thoughts:=A0

a. Eve= n though TMMBR/TMMBN is mandatory-to-implement in the RTP usage document, I= don't think we can assume that the pause/resume will be supported by a= ll mixers.. It therefore probably isn't a good idea for a browser to au= tomatically send a TMMBN 0 indication when setting rtpsender.active =3D fal= se. =A0Since the application might or might not use SDP for signaling, this= is probably something that needs to be under application control. =A0BTW, = Section 6.3, isn't clear about the response to an unsolicited TMMBN (TM= MBR 0?).=A0

b. As described in Section 1, pause/resume is for use i= n scenarios where signaling might not meet the performance requirements. = =A0Due to the differing transport characteristics of RTCP and signaling ove= r reliable transport, trying to use both pause/resume and signaling is quit= e likely to result in them being out of sync, so my assumption was that an = application wishing to support pause/resume would not choose to use signali= ng for the same purpose. =A0 There is also the potential for conflict betwe= en codec-specific messages (e.g. layer drop in H.264/SVC) and some potentia= l uses of pause/resume (e.g. unsolicited TMMBN to indicate layer pause in m= ulti-stream SVC). =A0Where there are conflicts, my assumption would be that= signaling and codec-specific messages should win.=A0


On Fri,= Mar 14, 2014 at 9:15 AM, Justin Uberti <juberti@google.com> wrote:



On Fri, Mar 14, 2014= at 4:25 AM, Stefan H=E5kansson LK <stefan.lk.hakansson@eri= csson.com> wrote:
On 2014-03-12 21:56, Justin Uberti wrote: > Agreed.

I may well be that the pause/resume doc will not be ready in time, so it from that aspect is a bad idea. What about just stating that TMMBN/TMMBR 0 meaning pause should be supported?

<= div>It's not clear to me what the interactions are between the signalin= g and media plane when this occurs. That is, if I do doohickey.active =3D f= alse, should that cause a=3Drecvonly signaling and a TMMBN notification tha= t the track is paused? I am concerned that things can get out of sync (i.e.= what happens if we get TMMBR indicating resume, but signaling is still a= =3Drecvonly)?


> Aren't there also patent declarations against this doc from
> multiple holders?

I've not looked into that, but I deliberately chose to propose th= e "old"
TMMBN 0 way to signal that is mentioned in [1] (and not any of the "ne= w"
signaling in [1]).

OK.
=A0

>
> While SDP will likely be removed from the API in the future, the
> replacement would be a app-specific message sent over websockets, whic= h
> seems like it would work just fine.

s/would/could/: I don't think this has been discussed or agreed (= and
websocket is of course just an example).

Right, the whole thing is an example, but the point is that the new= API directions don't really affect this particular problem.=A0

I think it is worthwhile to push this kind of signaling into the media
plane if possible. For example, this would enable the UA to save
transmission/battery even if the app is badly written.

As an example: if a MST sent over a PC is not used in any way at the
receiving end, the receiving end UA could signal TMMBR 0 to tell the
sending UA to not send. Sure, the receiving UA could also fire a
"negotiationneeded" event, but maybe the app doesn't listen.<= br>

True, if the app doesn't perf= orm the necessary signaling, things are not going to work, but that applies= to a lot of operations on the PeerConnection.

Overall this feels to me like something that needs some= thought to figure out all the interactions between the API, the signaling = plane, and the media plane. As such I am inclined to leave this out of 1.0.= =A0

>
>
> On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <bernard.aboba@gmail.com
> <mailto:bernard.aboba@gmail.com>> wrote:
>
> =A0 =A0 While I do like the pause/resume draft, having core RTCWEB WG<= br> > =A0 =A0 documents (such as RTP Usage) depend on it seems like a bit of= a
> =A0 =A0 stretch. After all, the document was only adopted last week, a= nd it
> =A0 =A0 is a rare IETF WG document that can go from a -00 WG draft to<= br> > =A0 =A0 publication as an RFC in under a year.
>
>
> =A0 =A0 On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=E5kansson LK
> =A0 =A0 <stefan.lk.hakansson@ericsson.com
> =A0 =A0 <mailto:stefan.lk.hakansson@ericsson.com>= > wrote:
>
> =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 at the IETF last week there was consensus in the AVTEX= T WG
> =A0 =A0 =A0 =A0 meeting to
> =A0 =A0 =A0 =A0 adopt the pause/resume draft [1] as a WG draft.
>
> =A0 =A0 =A0 =A0 In rtcweb/webrtc we're have the situation that we&= #39;re discussing so
> =A0 =A0 =A0 =A0 called "doo-hickeys" as an API surface where= the web app
> =A0 =A0 =A0 =A0 (amongst other
> =A0 =A0 =A0 =A0 things) can pause and resume the sending of a track. T= his can
> =A0 =A0 =A0 =A0 be signaled with the direction attribute and a SDP O/A= exchange
> =A0 =A0 =A0 =A0 (and the
> =A0 =A0 =A0 =A0 app pausing/resuming sending of a track would presumab= ly lead to a
> =A0 =A0 =A0 =A0 "negotiationneeded" event being fired).
>
> =A0 =A0 =A0 =A0 But I think we should in addition require the browser = to signal it
> =A0 =A0 =A0 =A0 according to one of the methods in [1] (e.g. TMMBN =3D= 0), and also
> =A0 =A0 =A0 =A0 understand that signaling (a browser receiving TMMBN = =3D 0 must
> =A0 =A0 =A0 =A0 know that
> =A0 =A0 =A0 =A0 the other end-point will pause sending).
>
> =A0 =A0 =A0 =A0 My argument is that we know that many dislike SDP in r= tcweb, and a
> =A0 =A0 =A0 =A0 likely development is that it will be removed in a lat= er version. My
> =A0 =A0 =A0 =A0 speculation is that signaling as outlined in [1] will = then be
> =A0 =A0 =A0 =A0 used for
> =A0 =A0 =A0 =A0 pause/resume. If we support this from the beginning ea= rlier
> =A0 =A0 =A0 =A0 implementations could more easily interop with those l= ater versions.
>
>
> =A0 =A0 =A0 =A0 Stefan
>
> =A0 =A0 =A0 =A0 [1]
> =A0 =A0 =A0 =A0 https://tools.ietf.org/id= /draft-westerlund-avtext-rtp-stream-pause-05.txt
>
> =A0 =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 =A0 rtcweb mailing list
> =A0 =A0 =A0 =A0 rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/rtcweb<= br> >
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 rtcweb mailing list
> =A0 =A0 rtc= web@ietf.org <mailto:rtcweb@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/rtcweb
>
>



--047d7bacb502d8f03404f494cb47-- From nobody Fri Mar 14 11:14:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324D51A01B7 for ; Fri, 14 Mar 2014 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 VU7kXE3m4CCc for ; Fri, 14 Mar 2014 11:14:50 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3444A1A0185 for ; Fri, 14 Mar 2014 11:14:50 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so3094067vcb.36 for ; Fri, 14 Mar 2014 11:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WLBNIvNKUQdo5IW79TCNNSEHzGgwNTmk3UMF65mckx0=; b=SrwP9uqJgWt8wo1q7ySL2Xl7zzsdT4xuImF8FWiWr4fcWz1qf8MCzGKsMTCodCtJg7 NgTv/WSF53ryX6ER7tIl6VFvDQLoMrM7bErKU5vsDmpLiiJv6Sp4es9sKcncwFXa9Fcq EVr24nAy95KTydfYksfbSg+XoL8yCkSkkIWdE/wYKY/sv6xez6gj52MFmlxPjWgQcgHG Ddq0RKlStl+ZAoH4SN7v26bBKpDVZ6nUBQwAI0Yqc3zJKMg4SmUrX0aUO71vf0XjPquI QVudh0noj2TSomrL+NUJu6aTA8koVYkIMTQ4Vc0JnJMEdXmHrsMZMD5EnsPupcIQ9LPn Gc8A== 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=WLBNIvNKUQdo5IW79TCNNSEHzGgwNTmk3UMF65mckx0=; b=KswJERy9SnOtSB0lDzXMKCl3PB+pl13W0bndMcoz+a2meAhiGL6wH/EMbEPSJd+e40 Sl+850bRDLc94ghx6t3bAsbgXzgO9tlZz9I8Bc/kOcuki6p/m2ZegCQjwr3gwLMSDvn2 Dxmrm0fXUuU+Om+gZPpGKKzN5SVE9N/S0QpSvg+5aoYg/sc53Em86F4BOphyTFdbqSQ0 k4+8zbGhQLPITCdDwC7cMYA6ZI+NRL6sEl2KjF/RipimdaT958v5+a0mNTt66NuN8bRw V3iigP4TG7VAldhl+HOUyux/EmeoNSDN4n9T6IJObKJBIce/AqbxXvbvAApiWGxDtqUr 70Xw== X-Gm-Message-State: ALoCoQlc4KyQSuXNYLRD02uh7LHOkFNevk+0yO2JIAfAAt36xKrL5/e9rN3n9kVPL74BnfhPFEiDu9Q83MKHRierzJCdKQB+Za53E2I04Av+JfwiJe8IMvCQa1OTOl3EPpfSwY4jzNvSxkfF1+nP+cCV/eCm/EuDcmyzsuKPyqcWwNqmJTfnWKOzs1lrjskpnKCqY0x/9GYZ X-Received: by 10.220.139.198 with SMTP id f6mr10044vcu.47.1394820883143; Fri, 14 Mar 2014 11:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 11:14:23 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D215B4C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D215AAB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D215B4C@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 14 Mar 2014 11:14:23 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b34394043fac004f4950b46 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q97ZjE5iR40JSTWoVRtXrw8HLcE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 18:14:52 -0000 --047d7b34394043fac004f4950b46 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 14, 2014 at 10:40 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > > By "RTCP transport in the offer", I mean separate ICE candidates > generated for a RTCP ICE component, the original problem that I was > proposing to solve. > > Ok. > > But, again, we do have a decision that we are not going to specify > procedures based on pre-knoweldge of BUNDLE support by the answerer. Or, at > least that was the outcome in London, I guess it still has to be verified > on the list. > ??? I was there and I don't recall this decision; I spent half an hour discussing this exact point in rtcweb based on a scenario you suggested (namely, a new PC created from a fork). The discussion ended with some interest but no consensus, which is why we are discussing it here in email... For sanity's sake, can you make it clear that you support this proposal? --047d7b34394043fac004f4950b46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 10:40 AM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:

Hi,

> By "RTCP transport in the offer", I mean separate ICE candid= ates generated for a RTCP ICE component, the original problem that I was pr= oposing to solve.

Ok.

But, again, we do have a decision that we are not going to specify procedur= es based on pre-knoweldge of BUNDLE support by the answerer. Or, at least t= hat was the outcome in London, I guess it still has to be verified on the l= ist.

???=C2=A0

I was t= here and I don't recall this decision; I spent half an hour discussing = this exact point in rtcweb based on a scenario you suggested (namely, a new= PC created from a fork). The discussion ended with some interest but no co= nsensus, which is why we are discussing it here in email...

For sanity's sake, can you make it clear that you s= upport this proposal?
--047d7b34394043fac004f4950b46-- From nobody Fri Mar 14 11:29:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5F1A017C for ; Fri, 14 Mar 2014 11:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 FAKHtWyqtZQV for ; Fri, 14 Mar 2014 11:29:14 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D63DB1A016F for ; Fri, 14 Mar 2014 11:29:13 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id il7so3130421vcb.4 for ; Fri, 14 Mar 2014 11:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/EjIuFXpJWGgFZgtWkAFlW53BZMJAVK0ZEDYU/mEiYw=; b=NqXXvgT8aMELMVaFCFn7QCX7NRA3XtCP+YiNZO3OvjIVmZvJsPNmbOJ7AoStXecSWw qmETpoJyJLgXZkYaSl+oscqLJRSD7a55wqfjunL9RRd/aQF3GTr3xnmLIkIHCLBMFcFB yX23Uzuw/BD1tG3196u+gz626xx8dAB7Es1/PbeT/j23IY+Sp/cBj7LMoQk5ElrLplIR +xoTnvmUztWYbaYlE6reWHiPizrjNU7Rm/uYZkGFHuVsUv8yWDb/mEuRAzavWwqyDVDq fn0kwntJkx+4Y9V4XkDTRrL8a8VWhpDhBRPCmFvPYHBAR6E5HHJdmp9ueHpiJLCFGdIQ cJnQ== 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=/EjIuFXpJWGgFZgtWkAFlW53BZMJAVK0ZEDYU/mEiYw=; b=P2NLyBRz/gi8k8w6N5ZWELKNjjoUFS4BkBfetJ3JyyuSPkohG5VgIMDTt9thRuGljK o1y4ye9pcoOpSA7bfBVVozw1tE/aNMalk3YqVEXHEPlrknDV6Hp0lWd0dMQynfN5aAn7 J5GdUgNw4jSDvrH6R/ektduRJxyuoSAfltmKTydXjDDr6S1yu1z4k5CAIXC35weovaGz U9RV59TmJ9XjtTOPhVegBBhjpUurTmgdlQ/wpzjV/l65WMHCi6mGmfO4dA2BhHH85vSm L8ijxy1KRJPlRbowBpgAHkaiOIEM3i4YaPwHUQqh9BLbOXWaQoFcHklWoRLC9nEyKq1E mgqQ== X-Gm-Message-State: ALoCoQlGwTZFulXnq5AkkojAeWQuX7fNxyKg/kHaI4V+j1nAsPchSF3Yp9w7p0L0Y21lkTCn2elnRZ+XEr0ERNK5PFvEOLKBS+kfV90+XoFcvV4esPn2UntENfwu06hK90DeM14l8BJPoBRJ3oceVv4H2fAxTBqseD0Tzq9EA7KUOV04eCSAt8r9zsoTXcSLtWopDgvVqpHG X-Received: by 10.58.57.42 with SMTP id f10mr7605830veq.1.1394821746743; Fri, 14 Mar 2014 11:29:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 11:28:46 -0700 (PDT) In-Reply-To: References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> From: Justin Uberti Date: Fri, 14 Mar 2014 11:28:46 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1136ac66bd753a04f4953e5c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Pc03hQS7Zml9h48qwxSEWNGuWzc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 14 Mar 2014 18:29:17 -0000 --001a1136ac66bd753a04f4953e5c Content-Type: text/plain; charset=UTF-8 On Fri, Mar 14, 2014 at 10:32 AM, Justin Uberti wrote: > > > > On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd wrote: > >> >> On Mar 14, 2014 9:44 AM, "Justin Uberti" wrote: >> > >> > >> > >> > >> > On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >> >> >> On 2014-03-13 17:53, Martin Thomson wrote: >> >> > On 12 March 2014 01:29, Magnus Westerlund >> >> > wrote: >> >> >> I like to point out that the agreement and what is documented in >> >> >> rtp-usage is that WebRTC endpoint will have to make forwarded >> streams >> >> >> appear as locally originated. However, this as currently written >> does >> >> >> not apply to RTP middleboxes that interconnects multiple >> PeerConnections >> >> >> to form a multi-party session. This is deliberate to ensure that RTP >> >> >> topologies like RTP mixer and SFM do work on the RTP/RTCP level. >> >> > >> >> > I'm still not clear on whether a middlebox interoperating with a >> >> > WebRTC endpoint is obligated to respect these rules or not. I had >> >> > assumed that WebRTC is such a bully that they would be forced to. >> >> >> >> Well, I know Colin and I did put in quite some thought to make the >> >> WebRTC RTP usage rules such that you can use the common RTP middleboxes >> >> as long as you have the right front-end, i.e. DTLS-SRTP and signalling >> >> translation. >> >> >> >> > >> >> >> I am especially interested to know how you will "easy to apply >> manually" >> >> >> the synchronization. Can you please describe that. Because, that >> either >> >> >> requires an API call to tell the media framework, please consider >> the >> >> >> following CNAMES as equivalent, or some other method of telling the >> >> >> media framework that these different MST are actually originating >> from a >> >> >> common clock base. >> >> > In WebRTC, this would be: >> >> > >> >> > var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0]; >> >> > var video = pc2.getRemoteStreams()[0].getVideoTracks()[0]; >> >> > var synchronizedStream = new MediaStream(audio, video); >> >> > >> >> > We'd have to say that this implies a statement about the clock base >> of >> >> > the tracks being the same. ... and that this statement could be >> >> > wrong. >> >> >> >> I think this looks dangerous. If you default the assumption that >> >> different CNAMEs of the MST you add are actually sharing clock base, >> >> then a lot of basic programs that may group MST from different PCs into >> >> one MS for convenience are going to cause serious issue in the media >> >> frameworks, when they attempt to synchronize things. >> >> >> >> > >> >> > As far as it goes, I'm sure that other systems could build a similar >> >> > function, but none of those are standardized. >> >> > >> >> >> I protested about this, not to lower the users privacy, but over the >> >> >> concern that this was raised without providing a case where it was >> >> >> obvious that the user's privacy was impacted. Martin, you said that >> you >> >> >> would think about it, and the next statement was lets change it, >> without >> >> >> providing any motivation why the concern was significant. >> >> > >> >> > I'm sorry about that, I thought about it, but didn't want to waste >> >> > everyone's time (mine included) with an essay on the subject. >> >> > >> >> >> >> Having considered this a bit more, I do think the risk to privacy out >> >> weighs the other concerns, as long as the API and its handling can be >> >> sorted out, I don't think the above is sufficient to get good >> >> functionality. >> >> >> >> My understanding is that the risk to privacy exist when one have one JS >> >> application enabling communication in different contexts during the >> same >> >> application session. In cases where there might be participants in the >> >> >> >> different contexts that could link the same end-point and thus human >> >> user to different participant IDs (that otherwise are anonymous). Thus >> >> revealing privacy concerns. As it would take the application designer >> to >> >> take this risk into consideration to avoid it, I feel safer if the >> >> application designer would need to take active measurements to perform >> >> linkage. >> >> >> >> >> >> I will wait an see if there are other inputs on this within the next >> >> week. If nothing arises I will propose a text change to the rtp-usage >> to >> >> address this. >> >> >> > >> > At an implementation level, one could imagine at least 3 policies for >> generating CNAMEs: >> > a) per-session (i.e. per-PeerConnection) >> > b) per-page (i.e. shared between all PCs on a page) >> > c) per-page, persistent (i.e. shared between all PCs on a page, >> including across page loads) >> > >> > While we seem to agree that a) is the right solution for CNAMEs, it is >> worth pointing out that we (Chrome) are currently doing c) for DTLS >> certificates, to avoid performance problems with cert generation at page >> load. Ergo, this linkability concern already exists, and I don't think it >> is easy to solve it in the default case. There have been some proposals to >> allow generation/storage of unique certs to prevent this linkability, but >> this will require app input. >> > >> >> One exponentiation, fixed base, per certificate. Use an addition >> multichain. Cert generation is cheap with ECDSA. >> > You're going to have to explain a bit more for me to grok this. > > Also, define 'cheap', especially on ARM CPUs. Currently RSA generation on > best-in-class ARM CPUs is 500 ms for 1024-bit, 2 seconds for 2048-bit. That > is a problem. > As to the choice of RSA as the algorithm... we just mandated use of TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09. --001a1136ac66bd753a04f4953e5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 10:32 AM, Justin Uberti &= lt;juberti@google.c= om> wrote:



On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd <w= atsonbladd@gmail.com> wrote:


On Mar 14, 2014 9:44 AM, "Justin Uberti" <juberti@google.com> wrote:
>
>
>
>
> On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund <magnus.westerlund@eric= sson.com> wrote:
>>
>> On 2014-03-13 17:53, Martin Thomson wrote:
>> > On 12 March 2014 01:29, Magnus Westerlund
>> > <magnus.westerlund@ericsson.com> wrote:
>> >> I like to point out that the agreement and what is docume= nted in
>> >> rtp-usage is that WebRTC endpoint will have to make forwa= rded streams
>> >> appear as locally originated. However, this as currently = written does
>> >> not apply to RTP middleboxes that interconnects multiple = PeerConnections
>> >> to form a multi-party session. This is deliberate to ensu= re that RTP
>> >> topologies like RTP mixer and SFM do work on the RTP/RTCP= level.
>> >
>> > I'm still not clear on whether a middlebox interoperating= with a
>> > WebRTC endpoint is obligated to respect these rules or not. = =C2=A0I had
>> > assumed that WebRTC is such a bully that they would be forced= to.
>>
>> Well, I know Colin and I did put in quite some thought to make the=
>> WebRTC RTP usage rules such that you can use the common RTP middle= boxes
>> as long as you have the right front-end, i.e. DTLS-SRTP and signal= ling
>> translation.
>>
>> >
>> >> I am especially interested to know how you will "eas= y to apply manually"
>> >> the synchronization. Can you please describe that. Becaus= e, that either
>> >> requires an API call to tell the media framework, please = consider the
>> >> following CNAMES as equivalent, or some other method of t= elling the
>> >> media framework that these different MST are actually ori= ginating from a
>> >> common clock base.
>> > In WebRTC, this would be:
>> >
>> > var audio =3D pc1.getRemoteStreams()[0].getAudioTracks()[0];<= br> >> > var video =3D pc2.getRemoteStreams()[0].getVideoTracks()[0];<= br> >> > var synchronizedStream =3D new MediaStream(audio, video);
>> >
>> > We'd have to say that this implies a statement about the = clock base of
>> > the tracks being the same. =C2=A0... and that this statement = could be
>> > wrong.
>>
>> I think this looks dangerous. If you default the assumption that >> different CNAMEs of the MST you add are actually sharing clock bas= e,
>> then a lot of basic programs that may group MST from different PCs= into
>> one MS for convenience are going to cause serious issue in the med= ia
>> frameworks, when they attempt to synchronize things.
>>
>> >
>> > As far as it goes, I'm sure that other systems could buil= d a similar
>> > function, but none of those are standardized.
>> >
>> >> I protested about this, not to lower the users privacy, b= ut over the
>> >> concern that this was raised without providing a case whe= re it was
>> >> obvious that the user's privacy was impacted. Martin,= you said that you
>> >> would think about it, and the next statement was lets cha= nge it, without
>> >> providing any motivation why the concern was significant.=
>> >
>> > I'm sorry about that, I thought about it, but didn't = want to waste
>> > everyone's time (mine included) with an essay on the subj= ect.
>> >
>>
>> Having considered this a bit more, I do think the risk to privacy = out
>> weighs the other concerns, as long as the API and its handling can= be
>> sorted out, I don't think the above is sufficient to get good<= br> >> functionality.
>>
>> My understanding is that the risk to privacy exist when one have o= ne JS
>> application enabling communication in different contexts during th= e same
>> application session. In cases where there might be participants in= the
>>
>> different contexts that could link the same end-point and thus hum= an
>> user to different participant IDs (that otherwise are anonymous). = Thus
>> revealing privacy concerns. As it would take the application desig= ner to
>> take this risk into consideration to avoid it, I feel safer if the=
>> application designer would need to take active measurements to per= form
>> linkage.
>>
>>
>> I will wait an see if there are other inputs on this within the ne= xt
>> week. If nothing arises I will propose a text change to the rtp-us= age to
>> address this.
>>
>
> At an implementation level, one could imagine at least 3 policies for = generating CNAMEs:
> a) per-session (i.e. per-PeerConnection)
> b) per-page (i.e. shared between all PCs on a page)
> c) per-page, persistent (i.e. shared between all PCs on a page, includ= ing across page loads)
>
> While we seem to agree that a) is the right solution for CNAMEs, it is= worth pointing out that we (Chrome) are currently doing c) for DTLS certif= icates, to avoid performance problems with cert generation at page load. Er= go, this linkability concern already exists, and I don't think it is ea= sy to solve it in the default case. There have been some proposals to allow= generation/storage of unique certs to prevent this linkability, but this w= ill require app input.
>

One exponentiation, fixed base, per certificate.= Use an addition multichain. Cert generation is cheap with ECDSA.

You're going to have to explain a bit more for = me to grok this.

Also, define 'cheap', especially on ARM CPUs. C= urrently RSA generation on best-in-class ARM CPUs is 500 ms for 1024-bit, 2= seconds for 2048-bit. That is a problem.

As to the choice of RSA as the algorithm... we just man= dated use of=C2=A0TLS_DHE_RS= A_WITH_AES_128_GCM_SHA256=C2=A0and=C2=A0 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256=C2=A0in=C2= =A0http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09.

--001a1136ac66bd753a04f4953e5c-- From nobody Fri Mar 14 11:33:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF2B1A019E for ; Fri, 14 Mar 2014 11:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN3A_XUtkylY for ; Fri, 14 Mar 2014 11:33:46 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28C1A019C for ; Fri, 14 Mar 2014 11:33:46 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so7676224ykq.7 for ; Fri, 14 Mar 2014 11:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y97rGfyhSbdeveAwwC2/plKEY1xF3qqAYRrfavLrcIo=; b=ZkEWXxsiqpcxmqAKqKyCHlBp0hYjYZXZgAPjhOwMPeg654W6x0rM0a1eQvuwilZ2qh SyyDlvur9irCTX2C9/2++vJ5GOo5kciJMV/UFtEEk2WxYaPA9RaINyavLOOPw09TPKcu aQMnCnDabTEJr2rXmsaW+JsYMOJA0EBFWgsilMhyjoQ77pgvInAArzHrLp+7H/RTUM8+ AszSzKw6VfSHS1mq4ZaazDB63rP4XvSS7PxkERKRqekd9v9356OkteEh4XtaH+e9e4v/ i4JgPzGZcwNONtu2n5f1rAwxjZTssSYGxSFTRG65Mwp5UU72QipYVyrWsEtfQU0ojBrv DezA== MIME-Version: 1.0 X-Received: by 10.236.191.67 with SMTP id f43mr12728433yhn.60.1394822019384; Fri, 14 Mar 2014 11:33:39 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 14 Mar 2014 11:33:39 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 14 Mar 2014 11:33:39 -0700 (PDT) In-Reply-To: References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> Date: Fri, 14 Mar 2014 11:33:39 -0700 Message-ID: From: Watson Ladd To: Justin Uberti Content-Type: multipart/alternative; boundary=20cf3040e42efd8ecd04f4954e09 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/u4P82myWMcBFxU0KYmILru_A4zs Cc: rtcweb@ietf.org Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 14 Mar 2014 18:33:49 -0000 --20cf3040e42efd8ecd04f4954e09 Content-Type: text/plain; charset=UTF-8 On Mar 14, 2014 11:29 AM, "Justin Uberti" wrote: > > > > > On Fri, Mar 14, 2014 at 10:32 AM, Justin Uberti wrote: >> >> >> >> >> On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd wrote: >>> >>> >>> On Mar 14, 2014 9:44 AM, "Justin Uberti" wrote: >>> > >>> > >>> > >>> > >>> > On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: >>> >> >>> >> On 2014-03-13 17:53, Martin Thomson wrote: >>> >> > On 12 March 2014 01:29, Magnus Westerlund >>> >> > wrote: >>> >> >> I like to point out that the agreement and what is documented in >>> >> >> rtp-usage is that WebRTC endpoint will have to make forwarded streams >>> >> >> appear as locally originated. However, this as currently written does >>> >> >> not apply to RTP middleboxes that interconnects multiple PeerConnections >>> >> >> to form a multi-party session. This is deliberate to ensure that RTP >>> >> >> topologies like RTP mixer and SFM do work on the RTP/RTCP level. >>> >> > >>> >> > I'm still not clear on whether a middlebox interoperating with a >>> >> > WebRTC endpoint is obligated to respect these rules or not. I had >>> >> > assumed that WebRTC is such a bully that they would be forced to. >>> >> >>> >> Well, I know Colin and I did put in quite some thought to make the >>> >> WebRTC RTP usage rules such that you can use the common RTP middleboxes >>> >> as long as you have the right front-end, i.e. DTLS-SRTP and signalling >>> >> translation. >>> >> >>> >> > >>> >> >> I am especially interested to know how you will "easy to apply manually" >>> >> >> the synchronization. Can you please describe that. Because, that either >>> >> >> requires an API call to tell the media framework, please consider the >>> >> >> following CNAMES as equivalent, or some other method of telling the >>> >> >> media framework that these different MST are actually originating from a >>> >> >> common clock base. >>> >> > In WebRTC, this would be: >>> >> > >>> >> > var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0]; >>> >> > var video = pc2.getRemoteStreams()[0].getVideoTracks()[0]; >>> >> > var synchronizedStream = new MediaStream(audio, video); >>> >> > >>> >> > We'd have to say that this implies a statement about the clock base of >>> >> > the tracks being the same. ... and that this statement could be >>> >> > wrong. >>> >> >>> >> I think this looks dangerous. If you default the assumption that >>> >> different CNAMEs of the MST you add are actually sharing clock base, >>> >> then a lot of basic programs that may group MST from different PCs into >>> >> one MS for convenience are going to cause serious issue in the media >>> >> frameworks, when they attempt to synchronize things. >>> >> >>> >> > >>> >> > As far as it goes, I'm sure that other systems could build a similar >>> >> > function, but none of those are standardized. >>> >> > >>> >> >> I protested about this, not to lower the users privacy, but over the >>> >> >> concern that this was raised without providing a case where it was >>> >> >> obvious that the user's privacy was impacted. Martin, you said that you >>> >> >> would think about it, and the next statement was lets change it, without >>> >> >> providing any motivation why the concern was significant. >>> >> > >>> >> > I'm sorry about that, I thought about it, but didn't want to waste >>> >> > everyone's time (mine included) with an essay on the subject. >>> >> > >>> >> >>> >> Having considered this a bit more, I do think the risk to privacy out >>> >> weighs the other concerns, as long as the API and its handling can be >>> >> sorted out, I don't think the above is sufficient to get good >>> >> functionality. >>> >> >>> >> My understanding is that the risk to privacy exist when one have one JS >>> >> application enabling communication in different contexts during the same >>> >> application session. In cases where there might be participants in the >>> >> >>> >> different contexts that could link the same end-point and thus human >>> >> user to different participant IDs (that otherwise are anonymous). Thus >>> >> revealing privacy concerns. As it would take the application designer to >>> >> take this risk into consideration to avoid it, I feel safer if the >>> >> application designer would need to take active measurements to perform >>> >> linkage. >>> >> >>> >> >>> >> I will wait an see if there are other inputs on this within the next >>> >> week. If nothing arises I will propose a text change to the rtp-usage to >>> >> address this. >>> >> >>> > >>> > At an implementation level, one could imagine at least 3 policies for generating CNAMEs: >>> > a) per-session (i.e. per-PeerConnection) >>> > b) per-page (i.e. shared between all PCs on a page) >>> > c) per-page, persistent (i.e. shared between all PCs on a page, including across page loads) >>> > >>> > While we seem to agree that a) is the right solution for CNAMEs, it is worth pointing out that we (Chrome) are currently doing c) for DTLS certificates, to avoid performance problems with cert generation at page load. Ergo, this linkability concern already exists, and I don't think it is easy to solve it in the default case. There have been some proposals to allow generation/storage of unique certs to prevent this linkability, but this will require app input. >>> > >>> >>> One exponentiation, fixed base, per certificate. Use an addition multichain. Cert generation is cheap with ECDSA. >> >> You're going to have to explain a bit more for me to grok this. >> >> Also, define 'cheap', especially on ARM CPUs. Currently RSA generation on best-in-class ARM CPUs is 500 ms for 1024-bit, 2 seconds for 2048-bit. That is a problem. > > > As to the choice of RSA as the algorithm... we just mandated use of TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09. > That's ridiculous. It should be changed. I'll email the list to explain why. --20cf3040e42efd8ecd04f4954e09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 14, 2014 11:29 AM, "Justin Uberti" <juberti@google.com> wrote:
>
>
>
>
> On Fri, Mar 14, 2014 at 10:32 AM, Justin Uberti <juberti@google.com> wrote:
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>>
>>>
>>> On Mar 14, 2014 9:44 AM, "Justin Uberti" <juberti@google.com> wrote:
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund <magnus.westerlund@ericsson.= com> wrote:
>>> >>
>>> >> On 2014-03-13 17:53, Martin Thomson wrote:
>>> >> > On 12 March 2014 01:29, Magnus Westerlund
>>> >> > <magnus.westerlund@ericsson.com> wrote:
>>> >> >> I like to point out that the agreement and w= hat is documented in
>>> >> >> rtp-usage is that WebRTC endpoint will have = to make forwarded streams
>>> >> >> appear as locally originated. However, this = as currently written does
>>> >> >> not apply to RTP middleboxes that interconne= cts multiple PeerConnections
>>> >> >> to form a multi-party session. This is delib= erate to ensure that RTP
>>> >> >> topologies like RTP mixer and SFM do work on= the RTP/RTCP level.
>>> >> >
>>> >> > I'm still not clear on whether a middlebox i= nteroperating with a
>>> >> > WebRTC endpoint is obligated to respect these ru= les or not. =C2=A0I had
>>> >> > assumed that WebRTC is such a bully that they wo= uld be forced to.
>>> >>
>>> >> Well, I know Colin and I did put in quite some though= t to make the
>>> >> WebRTC RTP usage rules such that you can use the comm= on RTP middleboxes
>>> >> as long as you have the right front-end, i.e. DTLS-SR= TP and signalling
>>> >> translation.
>>> >>
>>> >> >
>>> >> >> I am especially interested to know how you w= ill "easy to apply manually"
>>> >> >> the synchronization. Can you please describe= that. Because, that either
>>> >> >> requires an API call to tell the media frame= work, please consider the
>>> >> >> following CNAMES as equivalent, or some othe= r method of telling the
>>> >> >> media framework that these different MST are= actually originating from a
>>> >> >> common clock base.
>>> >> > In WebRTC, this would be:
>>> >> >
>>> >> > var audio =3D pc1.getRemoteStreams()[0].getAudio= Tracks()[0];
>>> >> > var video =3D pc2.getRemoteStreams()[0].getVideo= Tracks()[0];
>>> >> > var synchronizedStream =3D new MediaStream(audio= , video);
>>> >> >
>>> >> > We'd have to say that this implies a stateme= nt about the clock base of
>>> >> > the tracks being the same. =C2=A0... and that th= is statement could be
>>> >> > wrong.
>>> >>
>>> >> I think this looks dangerous. If you default the assu= mption that
>>> >> different CNAMEs of the MST you add are actually shar= ing clock base,
>>> >> then a lot of basic programs that may group MST from = different PCs into
>>> >> one MS for convenience are going to cause serious iss= ue in the media
>>> >> frameworks, when they attempt to synchronize things.<= br> >>> >>
>>> >> >
>>> >> > As far as it goes, I'm sure that other syste= ms could build a similar
>>> >> > function, but none of those are standardized. >>> >> >
>>> >> >> I protested about this, not to lower the use= rs privacy, but over the
>>> >> >> concern that this was raised without providi= ng a case where it was
>>> >> >> obvious that the user's privacy was impa= cted. Martin, you said that you
>>> >> >> would think about it, and the next statement= was lets change it, without
>>> >> >> providing any motivation why the concern was= significant.
>>> >> >
>>> >> > I'm sorry about that, I thought about it, bu= t didn't want to waste
>>> >> > everyone's time (mine included) with an essa= y on the subject.
>>> >> >
>>> >>
>>> >> Having considered this a bit more, I do think the ris= k to privacy out
>>> >> weighs the other concerns, as long as the API and its= handling can be
>>> >> sorted out, I don't think the above is sufficient= to get good
>>> >> functionality.
>>> >>
>>> >> My understanding is that the risk to privacy exist wh= en one have one JS
>>> >> application enabling communication in different conte= xts during the same
>>> >> application session. In cases where there might be pa= rticipants in the
>>> >>
>>> >> different contexts that could link the same end-point= and thus human
>>> >> user to different participant IDs (that otherwise are= anonymous). Thus
>>> >> revealing privacy concerns. As it would take the appl= ication designer to
>>> >> take this risk into consideration to avoid it, I feel= safer if the
>>> >> application designer would need to take active measur= ements to perform
>>> >> linkage.
>>> >>
>>> >>
>>> >> I will wait an see if there are other inputs on this = within the next
>>> >> week. If nothing arises I will propose a text change = to the rtp-usage to
>>> >> address this.
>>> >>
>>> >
>>> > At an implementation level, one could imagine at least 3 = policies for generating CNAMEs:
>>> > a) per-session (i.e. per-PeerConnection)
>>> > b) per-page (i.e. shared between all PCs on a page)
>>> > c) per-page, persistent (i.e. shared between all PCs on a= page, including across page loads)
>>> >
>>> > While we seem to agree that a) is the right solution for = CNAMEs, it is worth pointing out that we (Chrome) are currently doing c) fo= r DTLS certificates, to avoid performance problems with cert generation at = page load. Ergo, this linkability concern already exists, and I don't t= hink it is easy to solve it in the default case. There have been some propo= sals to allow generation/storage of unique certs to prevent this linkabilit= y, but this will require app input.
>>> >
>>>
>>> One exponentiation, fixed base, per certificate. Use an additi= on multichain. Cert generation is cheap with ECDSA.
>>
>> You're going to have to explain a bit more for me to grok this= .
>>
>> Also, define 'cheap', especially on ARM CPUs. Currently RS= A generation on best-in-class ARM CPUs is 500 ms for 1024-bit, 2 seconds fo= r 2048-bit. That is a problem.
>
>
> As to the choice of RSA as the algorithm... we just mandated use of=C2= =A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256=C2=A0and=C2=A0 TLS_ECDHE_RSA_WITH_AE= S_128_GCM_SHA256=C2=A0in=C2=A0http://tools.ietf.org/html/draft-ietf-rtcweb-s= ecurity-arch-09.
>

That's ridiculous. It should be changed.=C2=A0 I'll = email the list to explain why.

--20cf3040e42efd8ecd04f4954e09-- From nobody Fri Mar 14 11:34:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF1D1A01A7 for ; Fri, 14 Mar 2014 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERwKehRnrKJe for ; Fri, 14 Mar 2014 11:34:32 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3806F1A019C for ; Fri, 14 Mar 2014 11:34:32 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-cd-53234bb0bc22 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 7A.67.04249.0BB43235; Fri, 14 Mar 2014 19:34:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Fri, 14 Mar 2014 19:34:23 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] BUNDLE with implicit rtcp-mux Thread-Index: AQHPPCh4uGvaKjLTukeJMcClx2WsG5rZ+rmggABOAICAABMwcP//9NqAgAASK5D///t0AIAAX2mwgAJP3YCAAIVkAIABaJQggAAqmoCAAPXJ+4AAIb6AgAB9YgCAABFvsf//9DuAAAPsbrP///kugIAAFYbT Date: Fri, 14 Mar 2014 18:34:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D215BD0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D215AAB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D215B4C@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje4Gb+Vgg+l3DS1WvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsEroyLuzYyFbziqHjfKdfA+Jat i5GDQ0LAROLFiuAuRk4gU0ziwr31QGEuDiGBI4wS/c+OsEA4Sxgl/t75zwjSwCZgIdH9Txuk QURATeLhrF2sIDazQLXEthX/mEBsYQFjiSmdk9kgakwk5k58DTZHRGAVo8TUW5NYQOawCKhK zF7jAVLDK+Ar8W9aAxPErg8cEl9OnAJr5hQIlFjwvpUZxGYEuu77qTVMEMvEJW49mc8EcbWA xJI955khbFGJl4//sULYShI/NlxigajXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZ SFpmIWmZhaRlASPLKkaO4tTipNx0I4NNjMCYObjlt8UOxst/bQ4xSnOwKInzfnzrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0eZf79FXVyLuT5l40HZRtHIi/wy+p0m6i5RKhYXjz0XM 0k9mNWG9+HbaZOclTy3LtY5n/1f9/++2ZvST0983a8VpsjqLZzbJ6K/aO1Vk04Zk1XmbVX1O ZJwUP7BDb82a9KXlDFcanpXaTKvnXpZXkOyzkGXnxMbk41HnoxdZTrnKuuBcvLPyZSWW4oxE Qy3mouJEABYaizVnAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yoP0aHpcfFp1wBCDqoiVr4gA63U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 14 Mar 2014 18:34:34 -0000 Hi, >>> By "RTCP transport in the offer", I mean separate ICE candidates genera= ted for a RTCP ICE component, the original problem that I was proposing to = solve. >> >> Ok. >> >>But, again, we do have a decision that we are not going to specify proced= ures based on pre-knoweldge of BUNDLE support by the answerer. Or, at least= that was the outcome in London, I guess it still has to be verified on the= list. > > ??? > > I was there and I don't recall this decision; I spent half an hour discus= sing this exact point in rtcweb based on a scenario you suggested (namely, = a new PC created from a fork). The discussion ended with some interest but = no consensus, which is why we are discussing it here in email... Ok. My recall was that there was no support to do the "optimization" forkin= g, i.e. allowing identical port values (and, in this case, also rtcp-mux) a= lready in the initial offer for a PC, and therefor we were not going to do = it.=20 I'm glad if I'm wrong :) > For sanity's sake, can you make it clear that you support this proposal? Yes, I do. Regards, Christer From nobody Fri Mar 14 17:07:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3E41A0116 for ; Fri, 14 Mar 2014 17:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds0hLs8bOR23 for ; Fri, 14 Mar 2014 17:07:12 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4231C1A00C9 for ; Fri, 14 Mar 2014 17:07:12 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so8630686ykq.7 for ; Fri, 14 Mar 2014 17:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WwfHrXU1NJiIsmLML8Lm8LWIAg4q8hH/zhp9Br4nsD8=; b=Qk+86VolD/3RP6vKdlnVN1PJ7iLpjWhL+1NKf/3LXB58n5d3qybNpOjzm67Tv8tJgY 9CBDiqmb6uP5UIGIpX/cae37FH4m0E5Gk2yktjeiWiZ0du9LkhcmFBF/Kaq8Lgk9qGNZ kqLVrqoBnvkQAueSh+k4+8xP13t/Cuk6sGs0ai9wYUQprqj9pyhM7pUiGtaEigZgVoJ1 OBQeOK6o6oqDZZZpRdka1bMv3jLuIaDTpb2v6J0EOJnu1Q93ZpPipVO4DdiitNh7rAV+ De8EmbiigYCbWjRHLyYNeMH67VgZu2EuFe3bpIJohoaCZzYmwe5YtfZwQJOjC45Npr17 Ao0g== MIME-Version: 1.0 X-Received: by 10.236.122.99 with SMTP id s63mr15212226yhh.19.1394842025193; Fri, 14 Mar 2014 17:07:05 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Fri, 14 Mar 2014 17:07:05 -0700 (PDT) Date: Fri, 14 Mar 2014 17:07:05 -0700 Message-ID: From: Watson Ladd To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1be0b9qwTTaC2-x905lL6bd5jgQ Subject: [rtcweb] Unlinkability and RSA 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, 15 Mar 2014 00:07:14 -0000 Dear all, draft-ietf-rtcweb-security-arch-09 asks "[[OPEN ISSUE: Are these the right cipher suites?]]" and then describes two RSA suites. They are secure, but slow, and certificates need to be regenerated frequently to preserve unlinkability. ECDSA is much more performant, and this would ameliorate issues relating to certificate regeneration performance on low-power devices, as well as enable lower-power CPUs on video devices that intend to interoperate, via custom signalling, with webRTC. Secondly, ditch DHE. If you have ECDSA, you have everything for ECDHE, and it avoids slow, frequently skipped, and necessary checks in the protocol. I can think of no reason to use it. Thanks to Justin Uberti for pointing out this issue and the unlinkability consequences on constrained devices. Sincerely, Watson Ladd From nobody Mon Mar 17 03:30:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF511A03C7 for ; Mon, 17 Mar 2014 03:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 drlVFsZgJT1B for ; Mon, 17 Mar 2014 03:30:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA511A00AE for ; Mon, 17 Mar 2014 03:30:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-eb-5326cea0d368 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FF.D3.23809.0AEC6235; Mon, 17 Mar 2014 11:29:52 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Mar 2014 11:29:51 +0100 Message-ID: <5326CE9F.6060008@ericsson.com> Date: Mon, 17 Mar 2014 11:29:51 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvje6Cc2rBBs97VSy2ThWyuHbmH6PF 2n/t7A7MHjtn3WX3WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBkT5zxmKrjKV9F4dh9bA+M7 7i5GTg4JAROJX2uWMELYYhIX7q1nA7GFBA4xSrx6W9/FyAVkL2eUaG2bBVbEK6At0dm/jx3E ZhFQlZi6cAkriM0mYCFx80cjWLOoQLDEzgO/oeoFJU7OfMICYosIqEk8nLULrJ5ZIETi4dl3 zCC2sICVxJPDB1gglr1jkTj6ZQ1YEadAoMTeS0+Yuhg5gK4Tl+hpDILo1ZRo3f6bHcKWl2je OpsZ4mhtiYamDtYJjEKzkKyehaRlFpKWBYzMqxjZcxMzc9LLjTYxAkP34JbfqjsY75wTOcQo zcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG/9CDRqftv82XfbqOJ+l8yiTB o8dfVHD5N/lZ3dU92vfZNcsxL/NDn5G763eHCuY5e1iuvn3dsvrXwe7wT0WmDnud4rpq685l M3gbbA2csWmZztwsDiNxgS9/HcLz7z04xvrmjrvF6eLPOzk9vgm+MX0z/9mHWwJRX0+ePTlh tZ48w7zrdnMblFiKMxINtZiLihMB3yiZMSsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mA0F8gbj0y7kf4uRDtujnkjkIvA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 17 Mar 2014 10:30:03 -0000 On 2014-03-14 17:44, Justin Uberti wrote: > > At an implementation level, one could imagine at least 3 policies for > generating CNAMEs: > a) per-session (i.e. per-PeerConnection) > b) per-page (i.e. shared between all PCs on a page) > c) per-page, persistent (i.e. shared between all PCs on a page, > including across page loads) > > While we seem to agree that a) is the right solution for CNAMEs, it is > worth pointing out that we (Chrome) are currently doing c) for DTLS > certificates, to avoid performance problems with cert generation at page > load. Ergo, this linkability concern already exists, and I don't think > it is easy to solve it in the default case. There have been some > proposals to allow generation/storage of unique certs to prevent this > linkability, but this will require app input. > > Ergo, we might want to match the DTLS behavior (i.e. generate unique > CNAMEs only when the certs are unique), to ensure we treat linkability > consistently. Actually, the DTLS cert and the CNAME is actually not equivalent when it comes to visibility scope. The DTLS is show only to the DTLS peer, i.e. the address at the other end of a peer connection. The CNAME in cases of SFM or RTP mixer based using CSRC lists type of RTP middleboxes, can result in the CNAME being forward to all participants in the same multi-party conference. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 17 06:23:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50F1A0201 for ; Mon, 17 Mar 2014 06:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w-HbpXODCtk for ; Mon, 17 Mar 2014 06:23:40 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E5DCA1A011C for ; Mon, 17 Mar 2014 06:23:39 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-a4-5326f753a14e Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 43.0E.04249.357F6235; Mon, 17 Mar 2014 14:23:31 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Mar 2014 14:23:30 +0100 Message-ID: <5326F752.5050303@ericsson.com> Date: Mon, 17 Mar 2014 14:23:30 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvjW7wd7Vgg3/LZSxWvD7HbrF1qpDF 2n/t7A7MHgs2lXosWfKTyWPy4zbmAOYoLpuU1JzMstQifbsErozlnz8wFlxTr/g6s5WlgXGF fBcjJ4eEgInEgalNrBC2mMSFe+vZuhi5OIQEjjBKnF26mhXCWc4osXrDJxaQKl4BbYlXVxcy gtgsAqoS/xe9ArPZBCwkbv5oZAOxRQWCJXYe+M0IUS8ocXLmE7BeEQE1iYezdoFtYxaolnh6 8CU7iC0sYCxx6PJSZohlB9gk9lyZATaIUyBQ4vumZ0xdjBxA54lL9DQGQfRqSrRu/80OYctL NG+dzQxiCwHd1tDUwTqBUWgWktWzkLTMQtKygJF5FSNHcWpxUm66kcEmRmD4Htzy22IH4+W/ NocYpTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAeOWKac/X3qMrON3+L442 VWQzqiwPUVsYmDL9Qf/z5auWGW5K59rnzZXbcvBxZcWxUpXmz1xHTuYHVtyTWn1zcUXydMO6 e7dMQ7LjtoY4uL89bVursojjep5pSurJu61duq88nwWdW7JEenLyrifbZNVaXf8tqLZPuHGy aqNh/+YLjmwTz3e9VGIpzkg01GIuKk4EACWrmjAtAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jkUJEvc1xb50lz892kTE08L5qXc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 17 Mar 2014 13:23:42 -0000 On 2014-03-14 17:26, Justin Uberti wrote: > > > > On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund > > > wrote: > > Hi, > (as individual) > > Although this discussion really should be on MMUSIC, I am still > following up here. Anything we come to conclude here really need to go > to MMUSIC for confirmation. > > Justin, I do agree that it appear unnecessarily of having to include an > RTCP transport in an OFFER when the offerer know the answerer is BUNDLE > capable. I am fine with that and think the rule needed here is something > along the line of the below: > > A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already > required). In any answer by a BUNDLE capable endpoint, it MUST NOT > change the usage of a=rtcp-mux. If it is present in the offer, it must > be confirmed to be used in the answer, and if not present in the offer, > it MUST NOT be added in the answer. An BUNDLE capable endpoint is > RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not > be suitable include, lack RTP payload types, or cases when RTCP traffic > is needed to be on its own transport flow (5-tuple) to enable QoS or > other traffic handling functionalities. > > The reason for writing the rule like the above, is that then an endpoint > can choose when creating an offer to renegotiate the use of a=rtcp-mux. > For example due to it running out of available PTs. > > Feedback on this proposal? > > > I am not OK with this. It just gets too complicated to deal with all the > cases, especially if with the provision that rtcp-mux can change during > the session. (still as individual) Lets be clear what we are discussing here. I don't think this is lot of cases. And if you don't want to implement this in your code generating offer, that is fine. What this describes is that your code handling reception of offers and generating answers must be able to handle the lack of a=rtcp-mux in any offer, rather than just the initial one. I would question if even that assumption holds considering what happens if people start implementing session resumption or session mobility between devices using rehydration style establishment procedures. What one sides consider an initial offer might not be the state the answering party is in. Thus, I am worried about cases that are first offer/answer exchange related. To my understanding you will have code to handle the following cases when offers contains: 1) No bundle, no a=rtcp-mux 2) No bundle, with a=rtcp-mux 3) Bundle, with a=rtcp-mux Considering that you support bundle, and you support usage or not of a=rtcp-mux. Then I don't see how the code handling the SDP logic for Bundle, without a=rtcp-mux is that significant. First of all, to be robust, you have to be capable of handling significant reconfigurations of the Peer Connection session in an Offer. If someone moves the peer of one peer connection to another device anything can happen, and everything can change. Secondly, to be able to turn off a=rtcp-mux is one method which can free up PTs if one run out. The other would be first unbundle the media types, then to completely unbundle the media sources. The later would be far worse when it comes to requiring providing ICE candidates and dealing with new transports. I however think unbundling the media types is likely to resolve many of the PT shortage situations. Just to confirm, you are also against allowing any initial offer request with bundle but without a=rtcp-mux within that bundle-group? This, I would question, as it prevents anyone from treating the RTCP packets differently from the RTP packets within one RTP session. I know that this has been done in some cases, including IMS. >From a principal point of view I think this should be either be use of BUNDLE groups results in MUST use a=rtcp-mux with RTP or that any offer may change the usage of a=rtcp-mux. Anything else depending on initial offer appears very messy and prone to errors. I would appreciate if someone else would provide their input and views here! First on the question if they need to separate the RTP and RTCP at all within a BUNDLE group? Secondly if they see that splitting a bundle group into different groups if one runs into issue is a sufficient and more preferred method for dealing with any PT exhaustion issue? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 17 08:38:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1E1A02F5 for ; Mon, 17 Mar 2014 08:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHAQmlEwzmXx for ; Mon, 17 Mar 2014 08:38:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 39BF71A02FD for ; Mon, 17 Mar 2014 08:38:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BA26B7C5023 for ; Mon, 17 Mar 2014 16:38: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 mZB4tweLQEU9 for ; Mon, 17 Mar 2014 16:38:25 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id CA2387C4F48 for ; Mon, 17 Mar 2014 16:38:25 +0100 (CET) Message-ID: <532716F1.4030109@alvestrand.no> Date: Mon, 17 Mar 2014 16:38:25 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530C56CD.3010003@ericsson.com> <025d01cf3e9a$f4267340$dc7359c0$@stahl@intertex.se> In-Reply-To: <025d01cf3e9a$f4267340$dc7359c0$@stahl@intertex.se> Content-Type: multipart/alternative; boundary="------------000209070002030103090505" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kDP84R1VCPto80woR5memXBCTU8 Subject: Re: [rtcweb] [tram] Payload Types assignments 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, 17 Mar 2014 15:38:42 -0000 This is a multi-part message in MIME format. --------------000209070002030103090505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 03/13/2014 10:02 AM, Karl Stahl wrote: > > For the"mission to bring quality to real-time traffic over our best > effort Internet" I have started > http://www.ietf.org/mail-archive/web/tram/current/msg00331.html > > [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 > IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] > > Hi Magnus, > > With the response just sent to Pål > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, > skipping all the QoS methods and functions that really does not belong > here when creating an "Interface to QoS", I only see the suggestion of > "data channel information", i.e. also marking each data channel packet > with traffic bandwidth and type information to be relevant and > interesting. I checked with one of our developers and I think the same > traffic information as for RTP can be transferred in data channel > packets as follows: > > The RTP header has the following format (RFC 3550): > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |V=2|P|X| CC |M| PT | sequence number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | timestamp | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | synchronization source (SSRC) identifier | > > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > | contributing source (CSRC) identifiers | > > | .... | > > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > | RFC5285 header extension ... | > > | 2 bytes Max Bandwidth | 2 bytes Traffic Type | > > | .... | > > RTP Payload (often encrypted) > > A Data Channel header could have the following format: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Data Channel Magic Cookie | (sequence number) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | timestamp | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | synchronization source (SSRC) identifier | > > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > | contributing source (CSRC) identifiers | > > | .... | > > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > | RFC5285 header extension ... | > > | 2 bytes Max Bandwidth | 2 bytes Traffic Type | > > | .... | > > DTLS Header 13 bytes > > SCTP > > The RFC5285 header extension is not in a fixed position in any of > these cases, but still trivial to find (especially when in a TURN > flow). This could be introduced in > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5 > > by making room for these bytes after the UDP header, but before the > DTLS header. > > What do you think? > No. We've chosen to make Data Channel a protocol within DTLS, and not use any unencrypted headers for it. Neither does the data channel have any concept resembling SSRC, CSRC or timestamp. Changing to an RTP-based format such as the one you propose would be a drastic revision of the spec. There's no reason to believe such a revision at this time has any traction in the WG. --------------000209070002030103090505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/13/2014 10:02 AM, Karl Stahl wrote:

For the “mission to bring quality to real-time traffic over our best effort Internet” I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html

[tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2]

 

Hi Magnus,

 

With the response just sent to Pål http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, skipping all the QoS methods and functions that really does not belong here when creating an “Interface to QoS”, I only see the suggestion of “data channel information”, i.e. also marking each data channel packet with traffic bandwidth and type information  to be relevant and interesting. I checked with one of our developers and I think the same traffic information as for RTP can be transferred in data channel packets as follows:

 

The RTP header has the following format (RFC 3550):

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=2|P|X|  CC   |M|     PT      |       sequence number         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            RFC5285 header extension ...                      |

   |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |

   |                             ....                              |

RTP Payload (often encrypted)

 

A Data Channel header could have the following format:

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Data Channel Magic Cookie   |      (sequence number)        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            RFC5285 header extension ...                      |

   |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |

   |                             ....                              |

  DTLS Header 13 bytes

  SCTP

 

The RFC5285 header extension is not in a fixed position in any of these cases, but still trivial to find (especially when in  a TURN flow). This could be introduced in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5

by making room for these bytes after the UDP header, but before the DTLS header.

 

What do you think?



No.

We've chosen to make Data Channel a protocol within DTLS, and not use any unencrypted headers for it. Neither does the data channel have any concept resembling SSRC, CSRC or timestamp. Changing to an RTP-based format such as the one you propose would be a drastic revision of the spec.

There's no reason to believe such a revision at this time has any traction in the WG.

--------------000209070002030103090505-- From nobody Tue Mar 18 15:59:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F751A0446 for ; Tue, 18 Mar 2014 15:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 oz0gwo4O8W9O for ; Tue, 18 Mar 2014 15:59:08 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC551A040E for ; Tue, 18 Mar 2014 15:59:07 -0700 (PDT) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:3667 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQ2yI-0006zZ-Jh for rtcweb@ietf.org; Tue, 18 Mar 2014 17:58:59 -0500 Message-ID: <5328CF7D.1020703@jesup.org> Date: Tue, 18 Mar 2014 18:58:05 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xqNTB8HkXxGdTdwI9HXHA0z3bcc Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 18 Mar 2014 22:59:09 -0000 On 3/12/2014 4:56 PM, Justin Uberti wrote: > Agreed. Aren't there also patent declarations against this doc from > multiple holders? > > While SDP will likely be removed from the API in the future, the > replacement would be a app-specific message sent over websockets, > which seems like it would work just fine. Except that WebSockets doesn't work peer2peer, which means both delay and issues with signaling configurations without a server sitting between the users. However, an app-specific message sent over a DataChannel should work just fine. The downside would be that everything becomes app-specific, which would be a problem for any sort of federation or peering setup, and likely gatewaying to legacy. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Mar 18 18:00:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086771A04B1 for ; Tue, 18 Mar 2014 18:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 nApjm_Jwjs3v for ; Tue, 18 Mar 2014 18:00:31 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 70F6E1A046F for ; Tue, 18 Mar 2014 18:00:31 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so8142809veb.13 for ; Tue, 18 Mar 2014 18:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=MfPFJXFQHEKu5V//a/6XEbAsvr/Km6Mrq7yOeKESVdY=; b=hZ+NZZadiJMDTj7/xb+NiK+z5XThOLYISdPjeughTuNB8/b7Z8dw3yG/vNkfPFH3tH 8NsqrhkQ0z5T4LDqFS/7pLVCATzpWWFMbIE9hqto0ruJNVQnUOTatdBiC9FkwFUTGt+w izaYMI1RC+ceTg5Gedud3mzZp9dKgL00DISX97Axt7ozclC6p7av2CLY4S7Iea7Z1k43 X3t1FmKo2FKYo7yqg9TIHWdJCgdeEE1FmSQsUX4PjXIeVtRbYvhP+PNuxi+/p5+JIy5s RIcIjDuHd+xs7aIyGQw6CaTw8jyIcHqaoOMiNICsT2bfbzij0w+A4aKZpWkgvbUN2/M4 oqew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=MfPFJXFQHEKu5V//a/6XEbAsvr/Km6Mrq7yOeKESVdY=; b=H+lt7YayXSbEsopuAQNCMcvns68p9lBXiaTN4WxPtlcvQjKiOLOJz5mPU5PFf8ytJF yZy6oSKQXw24jPhbbvUH2WKDjXS2X6RqnWL9M6bqlKGD0DEDaNdYq/Pyl/IFCFtftWIT G7crYkqQTGgaUYzit7Xg+NRFpeRyz4zIKc4OhdjtrQUIiZ0mgcLq2Ccrtz+KvcISRE3E 62YjZq4ifCY0bJziJ0rLH89Y7s9676t2FSA1MrsQKUal+VYVjdpRBaOZK+My13jcwvpR nCYC5SlsWJI/mPPIeoRPG9/AG3onoLHRBJEDKSpEmo3aiqIYlz2vC7RQnMIQrBCPDHb0 K83w== X-Gm-Message-State: ALoCoQlPI7sLI3R6TICTs89PdVfXrCio7MQe+Xv3BbDvEm5mXDDTamz9q0H1JnLl9ESaiQwxrt067xPd8M7WwRsfZSeNrQAI8L4AwggVFZeXPnDbmJqCjVxGVIup/7WgbIRdNxAD+n/hOUyv0Ty/AZBvqqMB5+/NhiN0PKfuGjDDJfNcMHgqxWa0E60ZqzyAa4bhg4SLgZl9 X-Received: by 10.58.188.78 with SMTP id fy14mr7173624vec.23.1395190822645; Tue, 18 Mar 2014 18:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 18 Mar 2014 18:00:02 -0700 (PDT) From: Justin Uberti Date: Tue, 18 Mar 2014 18:00:02 -0700 Message-ID: To: "rtcweb@ietf.org" , Harald Alvestrand Content-Type: multipart/alternative; boundary=089e013a12f060ceae04f4eb2d43 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YoC0qd8A0ljH-CW5Wn-sqX7trXw Subject: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 01:00:34 -0000 --089e013a12f060ceae04f4eb2d43 Content-Type: text/plain; charset=UTF-8 https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system: inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf *temporary * As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session. Is this something we want to recommend in the transports doc? --089e013a12f060ceae04f4eb2d43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://to= ols.ietf.org/html/rfc4941 defines the concept of temporary IPv6 address= es. For, example, as enumerated on my local system:

= = inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
= inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf=C2= =A0
= inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf t= emporary=C2=A0

As indicated in the RFC, the temporary add= resses expire after hours or days, and therefore could be used to prevent l= ong-term linkability of sessions. Expiration shouldn't be an issue for = WebRTC, since we can simply do ICE restart if this occurs during a session.=

Is this something we want to recommend in the transport= s doc?
--089e013a12f060ceae04f4eb2d43-- From nobody Tue Mar 18 22:14:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A921A0381 for ; Tue, 18 Mar 2014 22:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7cfafpt1KqT for ; Tue, 18 Mar 2014 22:14:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 829B31A04AA for ; Tue, 18 Mar 2014 22:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3995; q=dns/txt; s=iport; t=1395206041; x=1396415641; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=cGNk5HZ6xjyxy1Jdsbr3Y0VdxNItRPe1g/Ks3O05bkI=; b=SSqYNK4SevPeC3ljrCgvEe93bFCGKN5dzuIa6Ic5xrd+UwDvemclAp++ hw049MxRN5pIMIAPK6GpBQgU1tIYEz/BjvVCV/PVNio7kqfFGcv4yfyJI TdFhBFaO/Dmn95uOzylWFlUutDKjip1xWFL9p1Htj6W93GDi0EO+miIhp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGcnKVOrRDoH/2dsb2JhbABagkJEO8MmgSAWdIIlAQEBAwF5BQsLBAo4VwYTh3EHDtA3EwSOXgQHgySBFASJUo51kjCDTR2BLCQ X-IronPort-AV: E=Sophos;i="4.97,683,1389744000"; d="scan'208,217";a="108471851" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 19 Mar 2014 05:14:00 +0000 Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2J5DxnH022887; Wed, 19 Mar 2014 05:13:59 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_B31ED087-23B5-4C3D-BF23-16861A720391" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Tue, 18 Mar 2014 22:14:00 -0700 Message-Id: References: To: Justin Uberti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O8HPuDMmOlPj_UHvONRP9VJ5hjA Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 05:14:12 -0000 --Apple-Mail=_B31ED087-23B5-4C3D-BF23-16861A720391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 18, 2014, at 6:00 PM, Justin Uberti wrote: > https://tools.ietf.org/html/rfc4941 defines the concept of temporary = IPv6 addresses. For, example, as enumerated on my local system: >=20 > inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 > inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf=20 > inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf = temporary=20 >=20 > As indicated in the RFC, the temporary addresses expire after hours or = days, and therefore could be used to prevent long-term linkability of = sessions. Expiration shouldn't be an issue for WebRTC, since we can = simply do ICE restart if this occurs during a session. >=20 > Is this something we want to recommend in the transports doc? Yes. And it should be as frequent as every new 'call', if IPv6 privacy = addresses are to provide the same privacy as a NAPT44, as a NAPT44 = should be assigning random ports per reasons described in RFC6056. The transport document should also recommend doing port randomization = (RFC6056), as that was found pretty useful for DNS, but randomizing = ports is still not popular with many OS's TCP stacks for whatever = reason. -d --Apple-Mail=_B31ED087-23B5-4C3D-BF23-16861A720391 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:

https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system:

inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf 
inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf temporary 

As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session.

Is this something we want to recommend in the transports doc?

Yes.

And it should be as frequent as every new 'call', if IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a NAPT44 should be assigning random ports per reasons described in RFC6056.

The transport document should also recommend doing port randomization (RFC6056), as that was found pretty useful for DNS, but randomizing ports is still not popular with many OS's TCP stacks for whatever reason.

-d


--Apple-Mail=_B31ED087-23B5-4C3D-BF23-16861A720391-- From nobody Wed Mar 19 00:03:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1951A0652 for ; Wed, 19 Mar 2014 00:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 vjXv43UaKzbL for ; Wed, 19 Mar 2014 00:03:00 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 30C821A0640 for ; Wed, 19 Mar 2014 00:03:00 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so8566237veb.1 for ; Wed, 19 Mar 2014 00:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=09oJ00h4yvfaOmdtJw86Z+y8+9EffoFU3dcten5ZMf0=; b=bovE0n0QhSS6en8lppnG9V9fTBEvjVotMMP7/IAaP02fQ2dXtFp0w9KCUT2PGM+Xu5 MorO3MVnRuxykd1ng4vEr/5l1L+rvec7c/p6dbOUZO+XaZeUNqRaP0OccR+fhjo9mACi lCdtSdOiL2+/og7ruvNSthC/QKdPny+JwIVwVRXOudDlz+B6kfSxkGzvXqdVhhh7QQ8f OW1EC6/P9Ef5uSgSuFVBWDlypW36vGb/rG4sBuYa59hhnO9lVG8ol5cHlARNt/kDgvEH 9rfemn7UNrR1SmngUGGDTWFD2bixa09Z51buUs3ittaK0LL/hsXHkiYlWIhxWfEkfLay JYRA== 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=09oJ00h4yvfaOmdtJw86Z+y8+9EffoFU3dcten5ZMf0=; b=hSLicqEqi2wopaEbgOG+pVYIh/urZRNu0+vZ832voX7F7JOPfcL4OB5w2hIriPtHfv xdevkNh9I0sfsSS/eGBfXUoX1C7mqyWMvaQeDD4gDLTmWzjLhJJT52n3nsF66GF+vwec L5ySWsPDa2GIMdd48l03urkhJnuDBQMCFAqahrjNS+CzL1g5lfC89d50F8L8xqvKNdX7 voj1l/YXjhSK6Yt2Jgzg1HEBkGyF6KkZdmZTWuSy/qHetofLlcgFX2ekEbVdjEHfaw7q gwOaWoxYWEMo9C2NYXvhJlID90FM7cNSZXHgkqKbSCpKmcePwIxXzU9pXHob3RP+TZU8 //KQ== X-Gm-Message-State: ALoCoQkRxlXpOICrah4NgeRbDAlw5hGLMyN5OFMEpsoddxx2bgNnVOWN97b8r5X0op26c6X45nPk+Bj5iECuwJIi/Y9KKOK+yd3kiLPRUeewpkKXbMQcYFUtKO8UsmW+Icgf1GqCbegdgc48erCe95klLK5YdHJTaFZzrxq0jO9twVUZRxwgHoNz3Wo82jbHXnLRO/BgmRrS X-Received: by 10.52.165.105 with SMTP id yx9mr24305456vdb.22.1395212571382; Wed, 19 Mar 2014 00:02:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.128.178 with HTTP; Wed, 19 Mar 2014 00:02:31 -0700 (PDT) In-Reply-To: References: From: Harald Alvestrand Date: Wed, 19 Mar 2014 08:02:31 +0100 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=001a11c210ccb43d2004f4f03de4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HavE-APfn_VlwyuVbQZirTeM_8w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 07:03:03 -0000 --001a11c210ccb43d2004f4f03de4 Content-Type: text/plain; charset=UTF-8 I'd like to be silent on the issue, since which IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness. On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing wrote: > > On Mar 18, 2014, at 6:00 PM, Justin Uberti wrote: > > https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 > addresses. For, example, as enumerated on my local system: > > inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 > inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf > inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf > *temporary * > > As indicated in the RFC, the temporary addresses expire after hours or > days, and therefore could be used to prevent long-term linkability of > sessions. Expiration shouldn't be an issue for WebRTC, since we can simply > do ICE restart if this occurs during a session. > > Is this something we want to recommend in the transports doc? > > > Yes. > > And it should be as frequent as every new 'call', if IPv6 privacy > addresses are to provide the same privacy as a NAPT44, as a NAPT44 should > be assigning random ports per reasons described in RFC6056. > > The transport document should also recommend doing port randomization > (RFC6056), as that was found pretty useful for DNS, but randomizing ports > is still not popular with many OS's TCP stacks for whatever reason. > > -d > > > --001a11c210ccb43d2004f4f03de4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd like to be silent on the issue, since which IPv6 a= ddresses to prefer is likely to be a matter of system policy. Trying to ove= rride system policy in an application specific profile usually leads to sad= ness.



On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:


--001a11c210ccb43d2004f4f03de4-- From nobody Wed Mar 19 08:02:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0DB1A045A for ; Wed, 19 Mar 2014 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_ayqiTkqmVr for ; Wed, 19 Mar 2014 08:02:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B01F11A0743 for ; Wed, 19 Mar 2014 08:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10885; q=dns/txt; s=iport; t=1395241311; x=1396450911; h=from:to:subject:date:message-id:mime-version; bh=wat5GepDK6kl5g4z7XshlFgPeCQrBQI+R8h2f22A5NI=; b=ON5JPT0HQe9JAKzueRnxOW095IU+3D5kWCzza1jBCauEckaffImRFiMV ItS247RRtR3is1VBxQj75+yEvT8RD5a3la7+mAfqNZAdxwuy2W87I2x9Z 9cJMrWD7Ds1ro24/z09mJitvFrhJ1F/Ng3MihECfi+iz+HHMYDqRY0DJ6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFABCwKVOtJV2Y/2dsb2JhbABagkJEO1fCRYEZFnSCJwEELV4BKlYmAQQbh3GeFbFLF440g1yBFASqd4Mtgis X-IronPort-AV: E=Sophos;i="4.97,686,1389744000"; d="scan'208,217";a="311410363" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2014 15:01:51 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2JF1oJG025879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Mar 2014 15:01:50 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.166]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 10:01:50 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "rtcweb@ietf.org" Thread-Topic: Should consent checks be optimized further? Thread-Index: Ac9Ddg2wwxMgoYNeSLCvKCoxDf8YUw== Date: Wed, 19 Mar 2014 15:01:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.70.214] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5xmbrcdx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9R14AOH8lwaTDloITduU_PB6Cvk Subject: [rtcweb] Should consent checks be optimized further? 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, 19 Mar 2014 15:02:02 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Though the WG's decision is to go with the STUN consent mechanism (draft-ie= tf-rtcweb-stun-consent-freshness) instead of the DTLS consent mechanism (dr= aft-thomson-rtcweb-consent), I think the later raises a question that we ha= ven't discussed in the context of the former, yet: Should reception of authenticated traffic from the peer on the inverted 5-t= uple be considered as peer granting consent to send traffic to it? Should t= he browser refrain from performing consent freshness when it continues to r= eceive such traffic from the peer? Here, authenticated traffic could be DTLS-SRTP or DTLS-SRTCP or data-channe= l or STUN binding requests. Some of the reasons why we may not want to do such optimization: - To keep the mechanism simple. - To not introduce layering violations. - Might help network elements to piggyback metadata about change in network conditions to other network elements and endpoints (in line with what Matthew in the meeting). - The overhead of performing consent freshness compared to processing actua= l traffic is generally minimal. - Might help in calculating RTT for the data channel (that doesn't have RTC= P). - Introduces a security weakness: SRTP is encrypted and authenticated with symmetric keys; that is, both sender and receiver know the keys. With two party sessions, receipt of an authenticated packet from the single remote party is a strong assurance the packet came from that party. However, whe= n a session involves more than two parties, all of whom know each other's keys, any of those parties could have sent the packet. Such shared key distributions are possible with some MIKEY [RFC3830] modes, Security Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. On the other hand, there might be some constrained networks that allocate f= ixed bit rate for traffic and the occasional consent checks could break tha= t fixed bit rate. This looks the only benefit of not performing consent fre= shness when receiving authenticated traffic. It should be noted that draft-ietf-rtcweb-stun-consent-freshness already ha= s the following: When not actively sending traffic on a nominated candidate pair, performing consent freshness does not serve any purpose from a security perspective. Which itself is good optimization, I think. Comments welcome.. Muthu --_000_E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Though the WG's decision is to go with the STUN consent me= chanism (draft-ietf-rtcweb-stun-consent-freshness) instead of the DTLS cons= ent mechanism (draft-thomson-rtcweb-consent), I think the later raises a question that we haven't discussed in the conte= xt of the former, yet:

 

Should reception of authenticated traffic from the peer on= the inverted 5-tuple be considered as peer granting consent to send traffi= c to it? Should the browser refrain from performing consent freshness when it continues to receive such traffic from the peer?=

 

Here, authenticated traffic could be DTLS-SRTP or DTLS-SRT= CP or data-channel or STUN binding requests.

 

Some of the reasons why we may not want to do such optimiz= ation:

- To keep the mechanism simple.

- To not introduce layering violations.

- Might help network elements to piggyback metada= ta about change in network

  conditions to other network elements = and endpoints (in line with what

  Matthew in the meeting).

- The overhead of performing consent freshness compared to= processing actual

  traffic is generally minimal.

- Might help in calculating RTT for the data channel (that= doesn't have RTCP).

- Introduces a security weakness: SRTP is encrypt= ed and authenticated with

  symmetric keys; that is, both sender = and receiver know the keys. With two

  party sessions, receipt of an authent= icated packet from the single remote

  party is a strong assurance the packe= t came from that party. However, when

  a session involves more than two part= ies, all of whom know each other's

  keys, any of those parties could have sent= the packet. Such shared key

  distributions are possible with some = MIKEY [RFC3830] modes,

  Security Descriptions [RFC4568], and = EKT [I-D.ietf-avtcore-srtp-ekt].

 

On the other hand, there might be some constrained network= s that allocate fixed bit rate for traffic and the occasional consent check= s could break that fixed bit rate. This looks the only benefit of not performing consent freshness when receiving authen= ticated traffic.

 

It should be noted that draft-ietf-rtcweb-stun-consent-fre= shness already has the following:

 

   When not actively sending traffic on a nomina= ted candidate pair,

   performing consent freshness does not serve a= ny purpose from a

   security perspective.

 

Which itself is good optimization, I think.

 

Comments welcome..

 

Muthu

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5xmbrcdx02ciscoc_-- From nobody Wed Mar 19 08:08:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3AE1A075F for ; Wed, 19 Mar 2014 08:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymOBeYRUH8iP for ; Wed, 19 Mar 2014 08:08:23 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7693F1A0768 for ; Wed, 19 Mar 2014 08:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6308; q=dns/txt; s=iport; t=1395241692; x=1396451292; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=bRDqh5CHzZVaowojwnMXafQ8yWaLfTKB30H8Cc2UapE=; b=LDQ3swzGcZSyJ1LTQkNXXbb0+6wVeza6HastcDp5OKuyM1vxko7JEmyS dlBaEL0cwE092eRn19e16i8RzxCpOdc4WBxxIhQNsiYn5lhMp95CFNQeB Mmlw/50WKuV1o6iMcHCcjldeZOk0+o3EA6wnleGDMsSkWwmBsB2iJdACa I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALCxKVOrRDoI/2dsb2JhbABagkJEO8McgRkWdIIlAQEBAwF5BQsLDgouVwYTh3EHDs9FEwSOYQQHgySBFASJUo51kjCDTR2BLCQ X-IronPort-AV: E=Sophos;i="4.97,686,1389744000"; d="scan'208,217";a="105931938" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 19 Mar 2014 15:08:11 +0000 Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2JF86fB000502; Wed, 19 Mar 2014 15:08:10 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_FA6711E7-B681-4D2D-828D-DB5F6FB573FB" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Wed, 19 Mar 2014 08:08:09 -0700 Message-Id: References: To: Harald Alvestrand X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vSkHKnEQl9A2-kjPwi1yWAYjAJ4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 15:08:26 -0000 --Apple-Mail=_FA6711E7-B681-4D2D-828D-DB5F6FB573FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 19, 2014, at 12:02 AM, Harald Alvestrand wrote: > I'd like to be silent on the issue, since which IPv6 addresses to = prefer is likely to be a matter of system policy. Trying to override = system policy in an application specific profile usually leads to = sadness. The application needs to indicate if it wants a temporary address. If = the host's policy (or configuration or network) does not support = temporary addresses, the application won't get a temporary address. I = don't see why being silent helps? -d >=20 >=20 >=20 > On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing wrote: >=20 > On Mar 18, 2014, at 6:00 PM, Justin Uberti wrote: >=20 >> https://tools.ietf.org/html/rfc4941 defines the concept of temporary = IPv6 addresses. For, example, as enumerated on my local system: >>=20 >> inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 >> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf=20 >> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf = temporary=20 >>=20 >> As indicated in the RFC, the temporary addresses expire after hours = or days, and therefore could be used to prevent long-term linkability of = sessions. Expiration shouldn't be an issue for WebRTC, since we can = simply do ICE restart if this occurs during a session. >>=20 >> Is this something we want to recommend in the transports doc? >=20 > Yes. >=20 > And it should be as frequent as every new 'call', if IPv6 privacy = addresses are to provide the same privacy as a NAPT44, as a NAPT44 = should be assigning random ports per reasons described in RFC6056. >=20 > The transport document should also recommend doing port randomization = (RFC6056), as that was found pretty useful for DNS, but randomizing = ports is still not popular with many OS's TCP stacks for whatever = reason. >=20 > -d >=20 >=20 >=20 --Apple-Mail=_FA6711E7-B681-4D2D-828D-DB5F6FB573FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I'd like to be silent on the issue, = since which IPv6 addresses to prefer is likely to be a matter of system = policy. Trying to override system policy in an application specific = profile usually leads to = sadness.

The application needs to = indicate if it wants a temporary address. If the host's policy (or = configuration or network) does not support temporary addresses, the = application won't get a temporary address.  I don't see why being = silent = helps?

-d





On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:

On = Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:

https://tools.ietf.org/html/rfc4941 defines the = concept of temporary IPv6 addresses. For, example, as enumerated on my = local system:

inet 172.31.x.y netmask 0xfffffe00 = broadcast 172.31.x.255
inet6 = 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 = autoconf 
inet6 = 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf = temporary 

As indicated in the = RFC, the temporary addresses expire after hours or days, and therefore = could be used to prevent long-term linkability of sessions. Expiration = shouldn't be an issue for WebRTC, since we can simply do ICE restart if = this occurs during a session.

Is this something we want to recommend in the = transports = doc?

Yes.

And it should be as frequent as every new 'call', if = IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a = NAPT44 should be assigning random ports per reasons described in = RFC6056.

The transport document should also recommend doing = port randomization (RFC6056), as that was found pretty useful for DNS, = but randomizing ports is still not popular with many OS's TCP stacks for = whatever reason.

-d




= --Apple-Mail=_FA6711E7-B681-4D2D-828D-DB5F6FB573FB-- From nobody Wed Mar 19 08:20:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618301A03FF for ; Wed, 19 Mar 2014 08:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 VdyBubQDvyfx for ; Wed, 19 Mar 2014 08:20:21 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 104051A0781 for ; Wed, 19 Mar 2014 08:20:16 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-9a-5329b5a7e68a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 87.AE.04853.7A5B9235; Wed, 19 Mar 2014 16:20:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.347.0; Wed, 19 Mar 2014 16:20:06 +0100 Message-ID: <5329B5A6.8090908@ericsson.com> Date: Wed, 19 Mar 2014 16:20:06 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEJMWRmVeSWpSXmKPExsUyM+Jvje7yrZrBBv8mG1qs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDeHVrMWTGOv2Df9NnsD4wPWLkYODgkBE4l390W7GDmBTDGJ C/fWs3UxcnEICZxglDjc+pcZwlnOKLFn9kUmkCpeAW2Jn49vs4HYLAKqEr2PloLF2QQsJG7+ aASLiwoES+w88JsRol5Q4uTMJywgtoiAusTlhxfYQRYLC9hI/HmWAnGDuERPYxBIBbOAnsSU qy2MELa8RPPW2cwgthDQ1oamDtYJjPyzkAydhaRlFpKWBYzMqxgli1OLi3PTjQz0ctNzS/RS izKTi4vz8/SKUzcxAsPt4JbfRjsYT+6xP8QozcGiJM57nbUmSEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAPj2t81dqcu/w4SMvjocufY5onuT9iib2xhvz19c1C5t8pvgaKnIlO9NJq1n3fu DNg34+9Wk4Uhh6efmOuhXuoqO9lm0d57ZaWu7neK0gJFHziJvpK+WMV93sBXcLeczbZt38Sj BA7ukFFv+33GfI+3ooftvvyCd8KLe2X/P3+6Tixtf5mlzruZSizFGYmGWsxFxYkATJCMRAUC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9dsHuhPiFTpoM6STPmKZWV5RUe8 Subject: [rtcweb] Announcing location of Face to Face Interim Meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 15:20:22 -0000 WG, We will get this announce the official way (IETF announce list) also. Our joint f2f meeting of the RTCWEB WG and the W3C WebRTC WG and Media Capture TF on *May 19th to 21st is in Washington DC USA*. The meeting will take place in the Google office at 1101 New York Ave NW, Washington, DC 20005. Agenda and time split between RTCWEB WG, W3C WebRTC and Media Capture TF will be decided later. Cheers Magnus Westerlund (As chair) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 19 08:22:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD011A0778 for ; Wed, 19 Mar 2014 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQfIolINglPS for ; Wed, 19 Mar 2014 08:22:10 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC781A03FF for ; Wed, 19 Mar 2014 08:22:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D6D6E7C4E21 for ; Wed, 19 Mar 2014 16:22:00 +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 uy9LZ5Ivnxh2 for ; Wed, 19 Mar 2014 16:21:59 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 937A47C4DE1 for ; Wed, 19 Mar 2014 16:21:59 +0100 (CET) Message-ID: <5329B617.2070001@alvestrand.no> Date: Wed, 19 Mar 2014 16:21:59 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050300090907080509030004" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xsHVQIzvP32Xiu4HP4m2fB7uODY Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 15:22:19 -0000 This is a multi-part message in MIME format. --------------050300090907080509030004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/19/2014 04:08 PM, Dan Wing wrote: > > On Mar 19, 2014, at 12:02 AM, Harald Alvestrand > wrote: > >> I'd like to be silent on the issue, since which IPv6 addresses to >> prefer is likely to be a matter of system policy. Trying to override >> system policy in an application specific profile usually leads to >> sadness. > > The application needs to indicate if it wants a temporary address. If > the host's policy (or configuration or network) does not support > temporary addresses, the application won't get a temporary address. I > don't see why being silent helps? What API is it using? With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer temporary addresses". I'm happy to say "it is a good idea for systems to implement the recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications. > > -d > > >> >> >> >> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing > > wrote: >> >> >> On Mar 18, 2014, at 6:00 PM, Justin Uberti > > wrote: >> >>> https://tools.ietf.org/html/rfc4941 defines the concept of >>> temporary IPv6 addresses. For, example, as enumerated on my >>> local system: >>> >>> inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 >>> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf >>> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf >>> *temporary * >>> >>> As indicated in the RFC, the temporary addresses expire after >>> hours or days, and therefore could be used to prevent long-term >>> linkability of sessions. Expiration shouldn't be an issue for >>> WebRTC, since we can simply do ICE restart if this occurs during >>> a session. >>> >>> Is this something we want to recommend in the transports doc? >> >> Yes. >> >> And it should be as frequent as every new 'call', if IPv6 privacy >> addresses are to provide the same privacy as a NAPT44, as a >> NAPT44 should be assigning random ports per reasons described in >> RFC6056. >> >> The transport document should also recommend doing port >> randomization (RFC6056), as that was found pretty useful for DNS, >> but randomizing ports is still not popular with many OS's TCP >> stacks for whatever reason. >> >> -d >> >> >> > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050300090907080509030004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/19/2014 04:08 PM, Dan Wing wrote:

On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> wrote:

I'd like to be silent on the issue, since which IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness.

The application needs to indicate if it wants a temporary address. If the host's policy (or configuration or network) does not support temporary addresses, the application won't get a temporary address.  I don't see why being silent helps?

What API is it using?

With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer  temporary addresses".

I'm happy to say "it is a good idea for systems to implement the recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications.


-d





On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:

On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:

https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system:

inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf 
inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf temporary 

As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session.

Is this something we want to recommend in the transports doc?

Yes.

And it should be as frequent as every new 'call', if IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a NAPT44 should be assigning random ports per reasons described in RFC6056.

The transport document should also recommend doing port randomization (RFC6056), as that was found pretty useful for DNS, but randomizing ports is still not popular with many OS's TCP stacks for whatever reason.

-d






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

--------------050300090907080509030004-- From nobody Wed Mar 19 08:39:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0261A0754 for ; Wed, 19 Mar 2014 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 xSFlaW4Q1Juu for ; Wed, 19 Mar 2014 08:39:12 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A84EB1A0457 for ; Wed, 19 Mar 2014 08:39:12 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C6B634037C for ; Wed, 19 Mar 2014 11:39:03 -0400 (EDT) Message-ID: <5329BA17.7080701@viagenie.ca> Date: Wed, 19 Mar 2014 11:39:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7HHWzCll-x9WRxRw9ws1cFd5LTQ Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 15:39:14 -0000 Le 2014-03-19 03:02, Harald Alvestrand a écrit : > I'd like to be silent on the issue, since which IPv6 addresses to prefer > is likely to be a matter of system policy. Trying to override system > policy in an application specific profile usually leads to sadness. What would be useful to mention IMHO is that ICE restart should be used to gracefully handle the issue of IP address expiry, of which temporary IPv6 addresses are a frequently-encountered example. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 19 08:42:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882D71A077F for ; Wed, 19 Mar 2014 08:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 2bqF3Iyi2I4G for ; Wed, 19 Mar 2014 08:42:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 675681A0442 for ; Wed, 19 Mar 2014 08:41:55 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB63B4037C for ; Wed, 19 Mar 2014 11:41:46 -0400 (EDT) Message-ID: <5329BABA.6020003@viagenie.ca> Date: Wed, 19 Mar 2014 11:41:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5329B617.2070001@alvestrand.no> In-Reply-To: <5329B617.2070001@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/apNyUw3VacILRLvjdxa8-H50qyg Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 15:42:11 -0000 Le 2014-03-19 11:21, Harald Alvestrand a écrit : >> The application needs to indicate if it wants a temporary address. If >> the host's policy (or configuration or network) does not support >> temporary addresses, the application won't get a temporary address. I >> don't see why being silent helps? > > What API is it using? > > With a little Googling, the system policy I was thinking of was the > policy in RFC 6724 ("Default Address Selection for IPv6"), in particular > section 5 rule 7: "Prefer temporary addresses". > > I'm happy to say "it is a good idea for systems to implement the > recommendations of RFC 6724" (or some more 2119-like language). I > wouldn't want to claim that if a system has chosen to prefer > non-temporary addresses, it would have to change its non-conformance to > RFC 6724 in order to be conformant with RTCWEB specifications. IMHO it would be perfectly sensible to recommend the use of IPV6_PREFER_SRC_TMP [RFC5014]. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 19 09:09:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176461A07BF for ; Wed, 19 Mar 2014 09:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 b10hgO57T3TP for ; Wed, 19 Mar 2014 09:09:20 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B69771A07AA for ; Wed, 19 Mar 2014 09:09:20 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id i7so8538308oag.33 for ; Wed, 19 Mar 2014 09:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vBPrnFYqp11MpNwNuI0Ij95NcpzyAXA1qzvGMZgKGhU=; b=XErhqWRxOxg/XcRtq1m2NmBuIbv+zdq2CpO9zSOE3srs+Y1uLm8psu+7D3LHz6YsYG d3BS8zyjqyrWcLlc8gja6dSP+gtn7CpP5ECaLewNcoYVL6+r4A9vYCXVT+hNSOuNaxpD wEZdWmYtaeDcDLxEKUWplebBAdk9Af/Lh6JSGsWGi/XbUjiWOMEFiqt5LuqHa0bJzzfd ncVSJLXcSCh1r/3e+PK2ut8CCzkfpOHHHMikfQt/Adu+XEatv1ijlu5mNKnTRwfq72I8 WpInvN9yplt3GeXz9nmoVn597wRks0zh9k8ElP5uDywlpKPZZD02L6IM8/xUA9kl1Bww 18Yg== 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=vBPrnFYqp11MpNwNuI0Ij95NcpzyAXA1qzvGMZgKGhU=; b=Gp5PwQba24PUpH1yjQuQRO8IYScM+VGybx2JD3TtjPt96y4mNiNgnCTu7FtmAl2GzQ 3aWWFz7DGQKJYJAt6XX1IDInnOoHVykuxi1BVpodhcLdAjNRaiIyv3THmgaum6KaLzXp p1paNAvCtxa2yyaImvfjyyWYQezvqik2XqndUY+bcnov6tZqENeIY720ykII8c/+mGkZ 8EWqMXy2vP76Btt4j9snrLsglp7+obsOfSsUkTEAEY5h7kB/muiF5phNL7qLMqtAnyeV elF29wmBxwDn7GmVsGzw0Wuh4JR3zTR+8uz0t+kuoWHWZZdi1bW6anMkq+gmYdveGcj9 t9aA== X-Gm-Message-State: ALoCoQlpu/TWHPAVRXfDzgesmLpRvwDcLqqQwr01lHdEe4lqQPqxE4ocUDMDqodtDTPaf/+ZPiM+mXhs9tTHGmb+RN3q1HaJISxFfiBnzWCtEdY9e67qLIkYdQsOaYBWI2Kr3o4U3DHMS3927FPU9qAM4EhQBP2/Gnx00hUDauLToy74aftPJ+uzPzL9kdCCnHfLnC6Oxx4u X-Received: by 10.182.156.19 with SMTP id wa19mr1049793obb.80.1395245351118; Wed, 19 Mar 2014 09:09:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 19 Mar 2014 09:08:49 -0700 (PDT) In-Reply-To: <5329B617.2070001@alvestrand.no> References: <5329B617.2070001@alvestrand.no> From: Justin Uberti Date: Wed, 19 Mar 2014 09:08:49 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d0444ee91932c7704f4f7df79 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lVIqpSVYgMRwxLUjC4i24FCssZ0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 16:09:24 -0000 --f46d0444ee91932c7704f4f7df79 Content-Type: text/plain; charset=UTF-8 ICE by default is going to gather host candidates from all interfaces, which means that the non-temporary addresses are going to be used, regardless of priority, for connectivity checks at least. As a result, if we don't do anything, it means 2x the v6 interfaces, and 4x the v6-v6 ICE checks, in addition to any linkability concerns. We could say that if a system has chosen to prefer non-temporary-addresses, or privacy is not a concern, then non-temporary-addresses can be used. On Wed, Mar 19, 2014 at 8:21 AM, Harald Alvestrand wrote: > On 03/19/2014 04:08 PM, Dan Wing wrote: > > > On Mar 19, 2014, at 12:02 AM, Harald Alvestrand wrote: > > I'd like to be silent on the issue, since which IPv6 addresses to prefer > is likely to be a matter of system policy. Trying to override system policy > in an application specific profile usually leads to sadness. > > > The application needs to indicate if it wants a temporary address. If > the host's policy (or configuration or network) does not support temporary > addresses, the application won't get a temporary address. I don't see why > being silent helps? > > > What API is it using? > > With a little Googling, the system policy I was thinking of was the policy > in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 > rule 7: "Prefer temporary addresses". > > I'm happy to say "it is a good idea for systems to implement the > recommendations of RFC 6724" (or some more 2119-like language). I wouldn't > want to claim that if a system has chosen to prefer non-temporary > addresses, it would have to change its non-conformance to RFC 6724 in order > to be conformant with RTCWEB specifications. > > > -d > > > > > > On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing wrote: > >> >> On Mar 18, 2014, at 6:00 PM, Justin Uberti wrote: >> >> https://tools.ietf.org/html/rfc4941 defines the concept of temporary >> IPv6 addresses. For, example, as enumerated on my local system: >> >> inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 >> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf >> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf >> *temporary * >> >> As indicated in the RFC, the temporary addresses expire after hours or >> days, and therefore could be used to prevent long-term linkability of >> sessions. Expiration shouldn't be an issue for WebRTC, since we can simply >> do ICE restart if this occurs during a session. >> >> Is this something we want to recommend in the transports doc? >> >> >> Yes. >> >> And it should be as frequent as every new 'call', if IPv6 privacy >> addresses are to provide the same privacy as a NAPT44, as a NAPT44 should >> be assigning random ports per reasons described in RFC6056. >> >> The transport document should also recommend doing port randomization >> (RFC6056), as that was found pretty useful for DNS, but randomizing ports >> is still not popular with many OS's TCP stacks for whatever reason. >> >> -d >> >> >> > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d0444ee91932c7704f4f7df79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ICE by default is going to gather host candidates from all= interfaces, which means that the non-temporary addresses are going to be u= sed, regardless of priority, for connectivity checks at least.

As a result, if we don't do anything, it means 2x the v6 interface= s, and 4x the v6-v6 ICE checks, in addition to any linkability concerns.=C2= =A0

We could say that if a system has chosen to pr= efer non-temporary-addresses, or privacy is not a concern, then non-tempora= ry-addresses can be used.


On Wed,= Mar 19, 2014 at 8:21 AM, Harald Alvestrand <harald@alvestrand.no= > wrote:
=20 =20 =20
On 03/19/2014 04:08 PM, Dan Wing wrote:
=20
On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> wrote:

=20
I'd like to be silent on the issue, since wh= ich IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness.

The application needs to indicate if it wants a temporary address. If the host's policy (or configuration or network) does not support temporary addresses, the application won't get a temporary address. =C2=A0I don't see why being silent h= elps?

What API is it using?

With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer=C2=A0 temporary addresses&quo= t;.

I'm happy to say "it is a good idea for systems to implement t= he recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications.


-d





On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:

On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:

https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system:

inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
inet6 2620::1008:100b:e2f8:47ff:wwww= :xxxx prefixlen 64 autoconf=C2=A0
inet6 2620::1008:100b:819e:1d3f:yyyy= :zzzz prefixlen 64 autoconf temporary=C2=A0

As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session.

Is this something we want to recommend in the transports doc?

Yes.

And it should be as frequent as every new 'call&= #39;, if IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a NAPT44 should be assigning random ports per reasons described in RFC6056.

The transport document should also recommend doing port randomization (RFC6056), as that was found pretty useful for DNS, but randomizing ports is still not popular with many OS's TCP stacks for whatever reason.

-d






_______________________________________________
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


--f46d0444ee91932c7704f4f7df79-- From nobody Wed Mar 19 11:18:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130C21A0451 for ; Wed, 19 Mar 2014 11:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UegUtMR-qsph for ; Wed, 19 Mar 2014 11:18:32 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 662531A042C for ; Wed, 19 Mar 2014 11:18:32 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so7286992wgg.1 for ; Wed, 19 Mar 2014 11:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IhghE+vNVgWGqDehNiSaTHAdgmG5lxYdHOGyRE6A95g=; b=lo9ujfotQXX2Ol/6WaQEGWVRlh+6ahKzsU/gytqvpiXnJH6rLeoESYYcZQOWWdYHvM tFXzmJdIhUpKeUCLFQDFnYkDFav/dJ78KiYx713Yh+K8WGHWweratRKtGp3B1Ppk7iE6 PGvRJziaB2qllLlRd84/nxzxG+SoLsZM79tqYeG6M7EbtDbDHhq/AfycPfi1HgDWPzxF QjBKwYo3LkjTy+R4yLFwSx0QwJuy4FW0D9xxGzxPpmU+YY8Jloxj7zCTMT+0WCZoCqHj EEyXRb56j8kz95oXI19Z4girtU4ay08gzWTXJKyAvMEZCzAZ8gRe6sJ8DBGP3MZC9XYt MRjg== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr21079256wiw.50.1395253103295; Wed, 19 Mar 2014 11:18:23 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Wed, 19 Mar 2014 11:18:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Mar 2014 11:18:23 -0700 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YrRMWSgjTGzk5ReH36jIATTaAYE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should consent checks be optimized further? 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, 19 Mar 2014 18:18:34 -0000 On 19 March 2014 08:01, Muthu Arul Mozhi Perumal (mperumal) wrote: > Should reception of authenticated traffic from the peer on the inverted > 5-tuple be considered as peer granting consent to send traffic to it? Should > the browser refrain from performing consent freshness when it continues to > receive such traffic from the peer? You forgot to mention another concern here, which is that the receipt of an authenticated packet is not sufficient if the path has changed. You need to verify that the peer on the new path has both consented to receive data AND is in possession of the session keys. Otherwise, in combination with source IP/port spoofing, you get an attack that a victim cannot opt out of. From nobody Wed Mar 19 13:44:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1895D1A0783 for ; Wed, 19 Mar 2014 13:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 DvgvpuD4HDZr for ; Wed, 19 Mar 2014 13:44:16 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 49CA61A06D3 for ; Wed, 19 Mar 2014 13:44:16 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ik5so10170336vcb.28 for ; Wed, 19 Mar 2014 13:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QQhYTlL5ak/QUNjQnakl3sdaAfmBMN33Bm3dcKZjT/E=; b=YcvD9QTZjCe32x/a+SJeiDz1onDKHxUbIyaf2EhQ/q9gN+5pSFXyU3kM6jYofzlycl TSJ/ZZCU9Z54Lmt4bHCD9H3CFjxrHVc8KJB4stg54RCbssPwHOsZHTcxuLNcSM87oxPy +0GD/6h+wg2isXfzK02OzU2ewhkvMWE2NUKIfIb3rUkJoRHPaHK2N8erbSpKxSt4fgER 5tt+nKuHFf+8fUEeekiZHSJYFwd+eOAwG5WipNcjCnKKRmG2GxeWW315fGAtPq3rkm0T YF4KIJHIkmbT1XKuujGDdmy+OkI0ye4guP6T2u+KOcxiHkXHi3czOPOyuBoB8sFevM92 s1Sw== 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=QQhYTlL5ak/QUNjQnakl3sdaAfmBMN33Bm3dcKZjT/E=; b=GqLtxa1Q/saM1HnNA5f/HHH9BfQw3y7cDG73lMngh2u/cTHYL1yTweqNQS2orekJUj VH+EX2zHz79IHswwd0uv1DgYjhNVZ25xT9PkXVp+PY3ODEGJJI3VTy7mu6KnX3N3S5gq s9pzfc41uTpOkwJr8oA1Gzegs03gIZDleKCnTgz3Re3qUFVJj2plvF9YNKy7EXJGEUdz V51F9a6x9owlSlSjJpHPQ92wkAhKVburlpSyZgYQE6AajIQMMq8l/mKBtiVqu1+nJSxz sJ4DQITRdBiswbdgLP3ZrH0BzwyRgwnTwPtOLVMiseO0IWa+qatbkRS2mkkjkzNxg/JM HZnw== X-Gm-Message-State: ALoCoQlSoOEAU4S3tE3zNVVltOtNgGaIFvmaWKmc4qrbKhf60Kw4XF3BVNsd1qOtFIF3qhsfhCezJhHNdOHP+HHVpEH8YJ+xHE8vhzmw+Kt1FltUHEKkIP4F9yI4R3LEntjTvl43lZgpAFv2TM2EtrhqrzT1L56Yq9gb8fT1/+84uN/N1fGcZA7Fp6u5mYL6hjnYgakBBml1 X-Received: by 10.52.136.35 with SMTP id px3mr233255vdb.66.1395261847180; Wed, 19 Mar 2014 13:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 13:43:47 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> From: Justin Uberti Date: Wed, 19 Mar 2014 13:43:47 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec52d4acfc5375904f4fbb622 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e-_3ODsIzYDwcK9bxzheIg33z0Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 19 Mar 2014 20:44:19 -0000 --bcaec52d4acfc5375904f4fbb622 Content-Type: text/plain; charset=UTF-8 (and, to be clear, that by default, non-temporary addresses SHOULD NOT be used by clients) On Wed, Mar 19, 2014 at 9:08 AM, Justin Uberti wrote: > ICE by default is going to gather host candidates from all interfaces, > which means that the non-temporary addresses are going to be used, > regardless of priority, for connectivity checks at least. > > As a result, if we don't do anything, it means 2x the v6 interfaces, and > 4x the v6-v6 ICE checks, in addition to any linkability concerns. > > We could say that if a system has chosen to prefer > non-temporary-addresses, or privacy is not a concern, then > non-temporary-addresses can be used. > > > On Wed, Mar 19, 2014 at 8:21 AM, Harald Alvestrand wrote: > >> On 03/19/2014 04:08 PM, Dan Wing wrote: >> >> >> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand wrote: >> >> I'd like to be silent on the issue, since which IPv6 addresses to >> prefer is likely to be a matter of system policy. Trying to override system >> policy in an application specific profile usually leads to sadness. >> >> >> The application needs to indicate if it wants a temporary address. If >> the host's policy (or configuration or network) does not support temporary >> addresses, the application won't get a temporary address. I don't see why >> being silent helps? >> >> >> What API is it using? >> >> With a little Googling, the system policy I was thinking of was the >> policy in RFC 6724 ("Default Address Selection for IPv6"), in particular >> section 5 rule 7: "Prefer temporary addresses". >> >> I'm happy to say "it is a good idea for systems to implement the >> recommendations of RFC 6724" (or some more 2119-like language). I wouldn't >> want to claim that if a system has chosen to prefer non-temporary >> addresses, it would have to change its non-conformance to RFC 6724 in order >> to be conformant with RTCWEB specifications. >> >> >> -d >> >> >> >> >> >> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing wrote: >> >>> >>> On Mar 18, 2014, at 6:00 PM, Justin Uberti wrote: >>> >>> https://tools.ietf.org/html/rfc4941 defines the concept of temporary >>> IPv6 addresses. For, example, as enumerated on my local system: >>> >>> inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 >>> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf >>> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf >>> *temporary * >>> >>> As indicated in the RFC, the temporary addresses expire after hours or >>> days, and therefore could be used to prevent long-term linkability of >>> sessions. Expiration shouldn't be an issue for WebRTC, since we can simply >>> do ICE restart if this occurs during a session. >>> >>> Is this something we want to recommend in the transports doc? >>> >>> >>> Yes. >>> >>> And it should be as frequent as every new 'call', if IPv6 privacy >>> addresses are to provide the same privacy as a NAPT44, as a NAPT44 should >>> be assigning random ports per reasons described in RFC6056. >>> >>> The transport document should also recommend doing port randomization >>> (RFC6056), as that was found pretty useful for DNS, but randomizing ports >>> is still not popular with many OS's TCP stacks for whatever reason. >>> >>> -d >>> >>> >>> >> >> >> >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --bcaec52d4acfc5375904f4fbb622 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(and, to be clear, that by default, non-temporary addresse= s SHOULD NOT be used by clients)


On Wed, Mar 19, 2014 at 9:08 AM, Justin Uberti <= juberti@google.com> wrote:
ICE by default is going to = gather host candidates from all interfaces, which means that the non-tempor= ary addresses are going to be used, regardless of priority, for connectivit= y checks at least.

As a result, if we don't do anything, it means 2x the v6 interface= s, and 4x the v6-v6 ICE checks, in addition to any linkability concerns.=C2= =A0

We could say that if a system has chosen to pr= efer non-temporary-addresses, or privacy is not a concern, then non-tempora= ry-addresses can be used.

On Wed, Mar 19, 2014 at 8:21 AM, Harald Al= vestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 03/19/2014 04:08 PM, Dan Wing wrote:
=20
On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> wrote:

=20
I'd like to be silent on the issue, since wh= ich IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness.

The application needs to indicate if it wants a temporary address. If the host's policy (or configuration or network) does not support temporary addresses, the application won't get a temporary address. =C2=A0I don't see why being silent h= elps?

What API is it using?

With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer=C2=A0 temporary addresses&quo= t;.

I'm happy to say "it is a good idea for systems to implement t= he recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications.


-d





On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:

On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:

https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system:

inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
inet6 2620::1008:100b:e2f8:47ff:wwww= :xxxx prefixlen 64 autoconf=C2=A0
inet6 2620::1008:100b:819e:1d3f:yyyy= :zzzz prefixlen 64 autoconf temporary=C2=A0

As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session.

Is this something we want to recommend in the transports doc?

Yes.

And it should be as frequent as every new 'call&= #39;, if IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a NAPT44 should be assigning random ports per reasons described in RFC6056.

The transport document should also recommend doing port randomization (RFC6056), as that was found pretty useful for DNS, but randomizing ports is still not popular with many OS's TCP stacks for whatever reason.

-d






_______________________________________________
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



--bcaec52d4acfc5375904f4fbb622-- From nobody Wed Mar 19 17:21:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F031A0852 for ; Wed, 19 Mar 2014 17:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 cmbWZzIKl3oB for ; Wed, 19 Mar 2014 17:21:35 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4F1A0851 for ; Wed, 19 Mar 2014 17:21:35 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so112972veb.1 for ; Wed, 19 Mar 2014 17:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n1jaKxGXVmoVycy94GKOi2DLX5okQTRwiLvPJx9qUbE=; b=cBi/nUGIZ87ukINltKL1pvqTALxXdtIuuglOZjtKsMPOXwReHr+jXZMZH3W0m2Ouew rSMsz6sB7RY2016Vr50dHSB/8QSglN2oM+/06D9oqifWhk4/OmzYfdExcXhRIznZYBL2 gHgNCo7b7llkbU4K2dnSrWCltPsSl+ehM1/s5Z6ZFWD2YWeqU2Z02y9gyr0UWqKq0xKe P/aUty42h8uU3sBuyNQChW+OTGf0AnItOXqzF7p8ltoq1WVsaeBgZNIg71GaQlEDk7Fl zRzEzkpNe4hVhbRn0DDFGoN1ubqe1IYLMOjuYpqLt6y/WbF8p1TuJ5gWw+s9DfGqZR5w vFWQ== 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=n1jaKxGXVmoVycy94GKOi2DLX5okQTRwiLvPJx9qUbE=; b=Bw3fxCB5sNpUbD+03WJHDTR1H2QZ6VtlgVwRS6q9pNPi3D2KOJ3CC2SnmgbX+IKCug nqIIseuBx9eMh5ostVa288XVLbd1fewU+ata5c+x3y+fteT7OOfFwF61GQW7AgRwpmpU QGurwt5Z9H+/geWorzd11qSmaOLoZNvYsyHxVcrFe3uygDCAFN+MdtRXGoQ+yJG2I6Ub /ssxvm2Ltxgea5v9pkPB0ogOFb5cfLtp/e8BS8gy7ye4p4++04yvfxj0jOPZwH4SMn+g XT1dgdRtV1BNykKtf+VnHIY/3o5U8xXsQHNDdmn5Jn6LFT8QTZAn4jHEEL51EJC/rJDI AcbQ== X-Gm-Message-State: ALoCoQmyc0GNUeqFonZv0uoC8Do8810H55KSTfSZJaSP5Cn9/am28gzEhNqWhFS6E5/nC1NOpvFE9gTfcNMXUUndGQhoMNJ8FmceL0qtqIktvRxS533AK5Nl2DEKPXrs9G3wnp4fSn/X2zJnNTWn11cLYVBvT7BgIJAKuGsRiEWvCqJwlu8CtO95h5Nt8aKKsww5cafJ5ulm X-Received: by 10.52.163.236 with SMTP id yl12mr1960940vdb.39.1395274886240; Wed, 19 Mar 2014 17:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 17:21:05 -0700 (PDT) In-Reply-To: <5326F752.5050303@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> <5326F752.5050303@ericsson.com> From: Justin Uberti Date: Wed, 19 Mar 2014 17:21:05 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11c2c932f5759804f4febf36 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DGX8bAQOTFSXO8HWbhovg-l1nHQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 20 Mar 2014 00:21:38 -0000 --001a11c2c932f5759804f4febf36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-14 17:26, Justin Uberti wrote: > > > > > > > > On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund > > = > > > wrote: > > > > Hi, > > (as individual) > > > > Although this discussion really should be on MMUSIC, I am still > > following up here. Anything we come to conclude here really need to > go > > to MMUSIC for confirmation. > > > > Justin, I do agree that it appear unnecessarily of having to includ= e > an > > RTCP transport in an OFFER when the offerer know the answerer is > BUNDLE > > capable. I am fine with that and think the rule needed here is > something > > along the line of the below: > > > > A BUNDLE supporting endpoint MUST implement a=3Drtcp-mux (that is > already > > required). In any answer by a BUNDLE capable endpoint, it MUST NOT > > change the usage of a=3Drtcp-mux. If it is present in the offer, it > must > > be confirmed to be used in the answer, and if not present in the > offer, > > it MUST NOT be added in the answer. An BUNDLE capable endpoint is > > RECOMMENDED to use a=3Drtcp-mux whenever suitable. Cases when it mi= ght > not > > be suitable include, lack RTP payload types, or cases when RTCP > traffic > > is needed to be on its own transport flow (5-tuple) to enable QoS o= r > > other traffic handling functionalities. > > > > The reason for writing the rule like the above, is that then an > endpoint > > can choose when creating an offer to renegotiate the use of > a=3Drtcp-mux. > > For example due to it running out of available PTs. > > > > Feedback on this proposal? > > > > > > I am not OK with this. It just gets too complicated to deal with all th= e > > cases, especially if with the provision that rtcp-mux can change during > > the session. > > (still as individual) > > Lets be clear what we are discussing here. I don't think this is lot of > cases. And if you don't want to implement this in your code generating > offer, that is fine. What this describes is that your code handling > reception of offers and generating answers must be able to handle the > lack of a=3Drtcp-mux in any offer, rather than just the initial one. > > I would question if even that assumption holds considering what happens > if people start implementing session resumption or session mobility > between devices using rehydration style establishment procedures. What > one sides consider an initial offer might not be the state the answering > party is in. Thus, I am worried about cases that are first offer/answer > exchange related. > > To my understanding you will have code to handle the following cases > when offers contains: > > 1) No bundle, no a=3Drtcp-mux > 2) No bundle, with a=3Drtcp-mux > 3) Bundle, with a=3Drtcp-mux > > Considering that you support bundle, and you support usage or not of > a=3Drtcp-mux. Then I don't see how the code handling the SDP logic for > Bundle, without a=3Drtcp-mux is that significant. > It is significant because you always know you can rtcp-mux. And you always know you can BUNDLE when rtcp-muxing. But I think trying to BUNDLE a no-rtcp-mux m=3D line into a rtcp-mux m=3D line is asking for problems. > > First of all, to be robust, you have to be capable of handling > significant reconfigurations of the Peer Connection session in an Offer. > If someone moves the peer of one peer connection to another device > anything can happen, and everything can change. > > Secondly, to be able to turn off a=3Drtcp-mux is one method which can fre= e > up PTs if one run out. The other would be first unbundle the media > types, then to completely unbundle the media sources. The later would be > far worse when it comes to requiring providing ICE candidates and > dealing with new transports. I however think unbundling the media types > is likely to resolve many of the PT shortage situations. > > Just to confirm, you are also against allowing any initial offer request > with bundle but without a=3Drtcp-mux within that bundle-group? > I am against _any_ offer request with bundle and without a=3Drtcp-mux (as indicated in the current bundle draft). > > This, I would question, as it prevents anyone from treating the RTCP > packets differently from the RTP packets within one RTP session. I know > that this has been done in some cases, including IMS. > > From a principal point of view I think this should be either be use of > BUNDLE groups results in MUST use a=3Drtcp-mux with RTP or that any offer > may change the usage of a=3Drtcp-mux. Anything else depending on initial > offer appears very messy and prone to errors. > > I would appreciate if someone else would provide their input and views > here! > > First on the question if they need to separate the RTP and RTCP at all > within a BUNDLE group? > > Secondly if they see that splitting a bundle group into different groups > if one runs into issue is a sufficient and more preferred method for > dealing with any PT exhaustion issue? > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a11c2c932f5759804f4febf36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
On 2014-03-14 17:26, Justin = Uberti wrote:
>
>
>
> On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund
> <magnus.wes= terlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
> wrote:
>
> =C2=A0 =C2=A0 Hi,
> =C2=A0 =C2=A0 (as individual)
>
> =C2=A0 =C2=A0 Although this discussion really should be on MMUSIC, I a= m still
> =C2=A0 =C2=A0 following up here. Anything we come to conclude here rea= lly need to go
> =C2=A0 =C2=A0 to MMUSIC for confirmation.
>
> =C2=A0 =C2=A0 Justin, I do agree that it appear unnecessarily of havin= g to include an
> =C2=A0 =C2=A0 RTCP transport in an OFFER when the offerer know the ans= werer is BUNDLE
> =C2=A0 =C2=A0 capable. I am fine with that and think the rule needed h= ere is something
> =C2=A0 =C2=A0 along the line of the below:
>
> =C2=A0 =C2=A0 A BUNDLE supporting endpoint MUST implement a=3Drtcp-mux= (that is already
> =C2=A0 =C2=A0 required). In any answer by a BUNDLE capable endpoint, i= t MUST NOT
> =C2=A0 =C2=A0 change the usage of a=3Drtcp-mux. If it is present in th= e offer, it must
> =C2=A0 =C2=A0 be confirmed to be used in the answer, and if not presen= t in the offer,
> =C2=A0 =C2=A0 it MUST NOT be added in the answer. An BUNDLE capable en= dpoint is
> =C2=A0 =C2=A0 RECOMMENDED to use a=3Drtcp-mux whenever suitable. Cases= when it might not
> =C2=A0 =C2=A0 be suitable include, lack RTP payload types, or cases wh= en RTCP traffic
> =C2=A0 =C2=A0 is needed to be on its own transport flow (5-tuple) to e= nable QoS or
> =C2=A0 =C2=A0 other traffic handling functionalities.
>
> =C2=A0 =C2=A0 The reason for writing the rule like the above, is that = then an endpoint
> =C2=A0 =C2=A0 can choose when creating an offer to renegotiate the use= of a=3Drtcp-mux.
> =C2=A0 =C2=A0 For example due to it running out of available PTs.
>
> =C2=A0 =C2=A0 Feedback on this proposal?
>
>
> I am not OK with this. It just gets too complicated to deal with all t= he
> cases, especially if with the provision that rtcp-mux can change durin= g
> the session.

(still as individual)

Lets be clear what we are discussing here. I don't think this is lot of=
cases. And if you don't want to implement this in your code generating<= br> offer, that is fine. What this describes is that your code handling
reception of offers and generating answers must be able to handle the
lack of a=3Drtcp-mux in any offer, rather than just the initial one.

I would question if even that assumption holds considering what happens
if people start implementing session resumption or session mobility
between devices using rehydration style establishment procedures. What
one sides consider an initial offer might not be the state the answering party is in. Thus, I am worried about cases that are first offer/answer
exchange related.

To my understanding you will have code to handle the following cases
when offers contains:

1) No bundle, no a=3Drtcp-mux
2) No bundle, with a=3Drtcp-mux
3) Bundle, with a=3Drtcp-mux

Considering that you support bundle, and you support usage or not of
a=3Drtcp-mux. Then I don't see how the code handling the SDP logic for<= br> Bundle, without a=3Drtcp-mux is that significant.

=
It is significant because you always know you can rtcp-mux. And = you always know you can BUNDLE when rtcp-muxing. But I think trying to BUND= LE a no-rtcp-mux m=3D line into a rtcp-mux m=3D line is asking for problems= .=C2=A0

First of all, to be robust, you have to be capable of handling
significant reconfigurations of the Peer Connection session in an Offer. If someone moves the peer of one peer connection to another device
anything can happen, and everything can change.

Secondly, to be able to turn off a=3Drtcp-mux is one method which can free<= br> up PTs if one run out. The other would be first unbundle the media
types, then to completely unbundle the media sources. The later would be far worse when it comes to requiring providing ICE candidates and
dealing with new transports. I however think unbundling the media types
is likely to resolve many of the PT shortage situations.

Just to confirm, you are also against allowing any initial offer request with bundle but without a=3Drtcp-mux within that bundle-group?

I am against _any_ offer request with bundle and wi= thout a=3Drtcp-mux (as indicated in the current bundle draft).=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
This, I would question, as it prevents anyone from treating the RTCP
packets differently from the RTP packets within one RTP session. I know
that this has been done in some cases, including IMS.

>From a principal point of view I think this should be either be use of
BUNDLE groups results in MUST use a=3Drtcp-mux with RTP or that any offer may change the usage of a=3Drtcp-mux. Anything else depending on initial offer appears very messy and prone to errors.

I would appreciate if someone else would provide their input and views
here!

First on the question if they need to separate the RTP and RTCP at all
within a BUNDLE group?

Secondly if they see that splitting a bundle group into different groups if one runs into issue is a sufficient and more preferred method for
dealing with any PT exhaustion issue?


Cheers

Magnus Westerlund

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


--001a11c2c932f5759804f4febf36-- From nobody Wed Mar 19 17:23:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7F31A084D for ; Wed, 19 Mar 2014 17:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 xVNK762kt4Qp for ; Wed, 19 Mar 2014 17:23:39 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DC51A1A0821 for ; Wed, 19 Mar 2014 17:23:38 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz11so110677veb.5 for ; Wed, 19 Mar 2014 17:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FjYxp1uSjuVfE+im2O0MQfWI2be0LBTzgTyyoGlOrPk=; b=UbJCHTqzKXykhpZB0XJqquiJSs9wz/kD7efdjaf8TYkHdcj2HGB7LU8rBK4Ysvsuz3 /Hp8UJY3AIo6YCJPaRm7kFtA+8v+FV5TEvRIVfAbR0pli2KmpJK8/hlPXOZ5toc9ORRY cC+t/IMOG24mBSsMUN26O2mbjEnSarkaeDkBn/TB9N4meVaBAdAkDbd3XVyYEuE3uOw8 2Nd+1E1SkqTFGFPAQ5tmCMsMF5w2blwHibVpPzfO9C9iwABXYM09aEhqvRBbsSTxZuzL DE86R4ztklBRjeW1Ybw9DDS3919dYg3WI3nbHnd+V5ZhFjvVD15meApdw8Lu2Gk5I2EJ Ggjg== 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=FjYxp1uSjuVfE+im2O0MQfWI2be0LBTzgTyyoGlOrPk=; b=OFjLY6ayJXAN2b13cBTX77NdGFutxn20IJ/eTy/7ZX6Yoox3zUjmrseScf0RnfL6RW U1IJRjmOLO2QrDyeV7SLtUas5auUOTxrmY1HRXbIkP4mL26ANVLqLWNBKmD2fdd5fsGc mAC9Avu/KIR17JSbutcSyLQuYSwAgmgPJs/rYBXAY7MZ+BfaK01o0yQlI9NgxM11qMsn sHxKYHnYBg79dD/Ik7eTGvu6/o+fntVHn5+4IO3fymO1AOvRnO1M+WrnHijy92CdpLHV eVjEykdrjRL82XqYzWvV12LY47rbdaJWyboz0vuzHsSE5/Njs9El863s75p+ehJR2fvb OWyw== X-Gm-Message-State: ALoCoQlVdsqHqz7UL+D+0mCB4QwERfvv2erKwscvt13D8a/b3FGTkggA4ENT6khnBilIp2vQ+qbNcd+i8I65Iywra9Ular2JDybvILSC3MexzQbNQJLsnw9T6cX9O8uvU46QL+aGshMAeVoLTKb1laSmEWFb0PSTMJJ5VeDYwPbiUHRkWxgR52RUQ2Ko0a0vdml2VBTPWIsb X-Received: by 10.220.83.4 with SMTP id d4mr917163vcl.39.1395275009867; Wed, 19 Mar 2014 17:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 17:23:09 -0700 (PDT) In-Reply-To: <5326CE9F.6060008@ericsson.com> References: <53171C20.3020001@ericsson.com> <531DD807.9090602@ericsson.com> <53201AEF.6090501@ericsson.com> <5322BF2E.3060608@ericsson.com> <5326CE9F.6060008@ericsson.com> From: Justin Uberti Date: Wed, 19 Mar 2014 17:23:09 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=e89a8f92190653db7204f4fec737 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KJa9IqZ9PnVfiP7uEKHXJ64F530 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAMEs and multiple peer connections 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, 20 Mar 2014 00:23:41 -0000 --e89a8f92190653db7204f4fec737 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good point. So CNAME is perhaps the most important in terms of linkability, but DTLS certificate and also IPv6 address may allow linkage by some network elements. On Mon, Mar 17, 2014 at 3:29 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-14 17:44, Justin Uberti wrote: > > > > > At an implementation level, one could imagine at least 3 policies for > > generating CNAMEs: > > a) per-session (i.e. per-PeerConnection) > > b) per-page (i.e. shared between all PCs on a page) > > c) per-page, persistent (i.e. shared between all PCs on a page, > > including across page loads) > > > > While we seem to agree that a) is the right solution for CNAMEs, it is > > worth pointing out that we (Chrome) are currently doing c) for DTLS > > certificates, to avoid performance problems with cert generation at pag= e > > load. Ergo, this linkability concern already exists, and I don't think > > it is easy to solve it in the default case. There have been some > > proposals to allow generation/storage of unique certs to prevent this > > linkability, but this will require app input. > > > > Ergo, we might want to match the DTLS behavior (i.e. generate unique > > CNAMEs only when the certs are unique), to ensure we treat linkability > > consistently. > > Actually, the DTLS cert and the CNAME is actually not equivalent when it > comes to visibility scope. The DTLS is show only to the DTLS peer, i.e. > the address at the other end of a peer connection. The CNAME in cases of > SFM or RTP mixer based using CSRC lists type of RTP middleboxes, can > result in the CNAME being forward to all participants in the same > multi-party conference. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --e89a8f92190653db7204f4fec737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good point. So CNAME is perhaps the most important in term= s of linkability, but DTLS certificate and also IPv6 address may allow link= age by some network elements.


On Mon, Mar 17, 2014 at 3:29 AM, Magnus Westerlund <magnus.we= sterlund@ericsson.com> wrote:
On 2014-03-14 17:44, Justin Uberti wrote:

>
> At an implementation level, one could imagine at least 3 policies for<= br> > generating CNAMEs:
> a) per-session (i.e. per-PeerConnection)
> b) per-page (i.e. shared between all PCs on a page)
> c) per-page, persistent (i.e. shared between all PCs on a page,
> including across page loads)
>
> While we seem to agree that a) is the right solution for CNAMEs, it is=
> worth pointing out that we (Chrome) are currently doing c) for DTLS > certificates, to avoid performance problems with cert generation at pa= ge
> load. Ergo, this linkability concern already exists, and I don't t= hink
> it is easy to solve it in the default case. There have been some
> proposals to allow generation/storage of unique certs to prevent this<= br> > linkability, but this will require app input.
>
> Ergo, we might want to match the DTLS behavior (i.e. generate unique > CNAMEs only when the certs are unique), to ensure we treat linkability=
> consistently.

Actually, the DTLS cert and the CNAME is actually not equivalent when= it
comes to visibility scope. The DTLS is show only to the DTLS peer, i.e.
the address at the other end of a peer connection. The CNAME in cases of SFM or RTP mixer based using CSRC lists type of RTP middleboxes, can
result in the CNAME being forward to all participants in the same
multi-party conference.

Cheers

Magnus Westerlund

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


--e89a8f92190653db7204f4fec737-- From nobody Wed Mar 19 17:28:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAE21A0853 for ; Wed, 19 Mar 2014 17:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.547, 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 C7pAj-s7z7u2 for ; Wed, 19 Mar 2014 17:27:58 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 613261A0447 for ; Wed, 19 Mar 2014 17:27:58 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so108448veb.41 for ; Wed, 19 Mar 2014 17:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i3QNX0wiis3BIA8B7dueLTY829JMMl8M0kC1OuffWF8=; b=KB2wQboCwGdTQP3jWzDBlZ8Wq771OyjcR+2i5KYJNTYlHD6iDVKmQG8OosnWV+O8G9 gDLGIvB9tlXVU9dDL2xzyNugoZ2CAQYZ7L32pVz9MStOT2WMTxbA5J55zKLyYrqv3Yrh VOfOy5JgqjN0AsG1wtDsHUpmxXAYcdZpTlFliYV7Lf9u3Gu4Aipi6Za98DxvrA+R16YU 0iMYpwz3jCInS+9A4TUOMYpIi2aBV94+CwXgIvcnMKXjxeiX7VoXysYNJ4aF7zLqFWIW GFf+JZp8mphPpLOIZe5YM1r718yHdm7Xa2aB3eq7wVIi95lTe3aDnNfaZyKOFiillDtd nThA== 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=i3QNX0wiis3BIA8B7dueLTY829JMMl8M0kC1OuffWF8=; b=GGthWh9hdhh7ZpWDoaL2bYtzMhUG5qQq/dN09l2SjI92KFgkCuDWPmpuf+Z7aOpEL3 rtmgv2jg+ekL2cy7mYbP9azWNQNj0hg9eOQPvbIsixB7IGNrJ4OawT0d29iflgJ+tbx7 AeAO+k3ImTofjrw9MTat7IWpgsHl17W4EQN3ObMonzKTpLnDityiX+ifc1OylQBCSqjr hDnSU3myr3ctry6vcEY9NJ3ocV9CDa9g4jfs9KFUzjnlJh2JD3pQeB+WB/dFnzPSaIH5 CucMrndY2a2XwZhSrE076Js1KT4HzxE3wVcUkaWf8vkGMZCQ8m6ayO34BQWFjKTWd4go TZjg== X-Gm-Message-State: ALoCoQkpImajmz1qefZyqyGkfeNPutiGpJDhKidE9I/b2YbYTiC2x6FUeYEYHTht6pfpcyIZF42fDXftzoMulnggYRBEzshoNZ4vXabh02dIHuy+ipoDqoGmBjASwsig6wxU52/Tom5NMunH3YY0U5udSw2aPV0PoDvXjbImTVh6t+7P4cFmLrKJJLxEKuT3vPKA9X7tq+nW X-Received: by 10.221.37.1 with SMTP id tc1mr2324943vcb.32.1395275269434; Wed, 19 Mar 2014 17:27:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 17:27:29 -0700 (PDT) In-Reply-To: <531DE104.2010908@ericsson.com> References: <531DE104.2010908@ericsson.com> From: Justin Uberti Date: Wed, 19 Mar 2014 17:27:29 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11334c38cc8e4004f4fed6d4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/80nK9T7szYkeUL99iRUPYQBBPao Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On ptimes and maxptimes 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, 20 Mar 2014 00:28:00 -0000 --001a11334c38cc8e4004f4fed6d4 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > (As individual) > > On 2014-03-05 17:26, Justin Uberti wrote: > > From the session this morning, I recall this consensus: > > > > * We will add recommendations on the frame sizes to use for PCMU/A to > > the rtcweb audio codec I-D (20, 30, 60 ms frames). > > The above applies to sending payloads > Right, thanks for pointing that out. > > Yes, but that was given that a receiver will be capable of receiving any > valid number of frames, or samples within a reasonable packetization, > and I think that should be 120 ms. > > > * We will consider adding an a=maxptime attribute that represents the > > "minimum maxptime" of all the offered codecs. That is, if both Opus > > (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a > > maxptime=60 SHOULD be included. > > o Since maxptime spans all codecs, this means that some modes > > (e.g. Opus 120ms) will be unavailable, unless only Opus is > offered. > > I think you base the assumption on maxptime based on the sending > recommendations, not what is capable of receiving. If one is capable of > receiving 200 ms of a-law and Opus, then you would need to say 120 ms as > Opus will limit you. > I agree that Opus' maxptime is 120, but should that prevent sending PCMU with 200 ms? That is, since sending Opus with 200 ms is not legal, is there any point in forcing WebRTC impls to indicate this in SDP? > > > * We will consider adding an a=ptime attribute, set to the receiver's > > preferred frame size to receive. Again, this value spans all codecs, > > so the specified value may not be viable for all codecs (e.g. 30 ms > > works for PCMU but not for Opus) > > > > After thinking about this some, I'm not sure the maxptime/ptime values > > will lead to any different behavior than if they were not specified. > > Since there is a complexity cost (especially if the values need to > > change based on which codecs are offered), is there a clear upside here? > > The maxptime values may in some cases be limited downwards for > interoperability, for example if one like to gateway AMR into a CS > network then the gateway might indicate a maxptime that is less, more > like 20 or 40 ms. > Sure - WebRTC impls need to respect any maxptime value that they receive, but it's not clear to me that they need to include one in the SDP they send. > > Please remember that these rules do apply to any codec, not only the MTI > ones. > Yes. > > --001a11334c38cc8e4004f4fed6d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
Hi,

(As individual)

On 2014-03-05 17:26, Justin Uberti wrote:
> From the session this morning, I recall this consensus:
>
> =C2=A0 * We will add recommendations on the frame sizes to use f= or PCMU/A to
> =C2=A0 =C2=A0 the rtcweb audio codec I-D (20, 30, 60 m= s frames).

The above applies to sending payloads

=
Right, thanks for pointing that out.=C2=A0

Yes, but that was given that a receiver will be capable of receiving any valid number of frames, or samples within a reasonable packetization,
and I think that should be 120 ms.

> =C2=A0 * We will consider adding an a=3Dmaxptime attribute that repres= ents the
> =C2=A0 =C2=A0 "minimum maxptime" of all the = offered codecs. That is, if both Opus
> =C2=A0 =C2=A0 (maxptime of 120ms) and PCMU (maxptime of 60) are offere= d, a
> =C2=A0 =C2=A0 maxptime=3D60 SHOULD be included.
> =C2=A0 =C2=A0 =C2=A0 o Since maxptime spans all codecs, this mea= ns that some modes
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g. Opus 120ms) will be = unavailable, unless only Opus is offered.

I think you base the assumption on maxptime based on the sending
recommendations, not what is capable of receiving. If one is capable of
receiving 200 ms of a-law and Opus, then you would need to say 120 ms as Opus will limit you.

I agree that Opus&= #39; maxptime is 120, but should that prevent sending PCMU with 200 ms? Tha= t is, since sending Opus with 200 ms is not legal, is there any point in fo= rcing WebRTC impls to indicate this in SDP?
=C2=A0

> =C2=A0 * We will consider adding an a=3Dptime attribute, set to the re= ceiver's
> =C2=A0 =C2=A0 preferred frame size to receive. Again, = this value spans all codecs,
> =C2=A0 =C2=A0 so the specified value may not be viable for all codecs = (e.g. 30 ms
> =C2=A0 =C2=A0 works for PCMU but not for Opus)
>
> After thinking about this some, I'm not sure the maxptime/ptime va= lues
> will lead to any different behavior than if they were not specified. > Since there is a complexity cost (especially if the values need to
> change based on which codecs are offered), is there a clear upside her= e?

The maxptime values may in some cases be limited downwards for
interoperability, for example if one like to gateway AMR into a CS
network then the gateway might indicate a maxptime that is less, more
like 20 or 40 ms.

Sure - WebRTC impls n= eed to respect any maxptime value that they receive, but it's not clear= to me that they need to include one in the SDP they send.=C2=A0

Please remember that these rules do apply to any codec, not only the MTI ones.

Yes.=C2=A0

--001a11334c38cc8e4004f4fed6d4-- From nobody Wed Mar 19 20:42:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E471A034F for ; Wed, 19 Mar 2014 20:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t2q40nW3MvK for ; Wed, 19 Mar 2014 20:41:59 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 15C741A0345 for ; Wed, 19 Mar 2014 20:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2304; q=dns/txt; s=iport; t=1395286910; x=1396496510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4vZ3nJ61py903WgSAvFHMjKP51K2HsKMeU09ceBvIW8=; b=J+0C4T9HSM5qgGKgta0v9BD+3mX+OxWOT91StVhFFrCFUqAGPaJoxae6 6CLrLL24tlhGBZRQ2j5pDIR901nmOv+bID8K3iqbKeqdOiYGCXS1NQAGu 7IUMCyeECpuL6Wb1RxL6uB5Y2MVZznBu4X5YGl6Q23d/PiYZ5WiV3U4gg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFANdiKlOtJXG//2dsb2JhbABagwaBEoMHv0YZgQYWdIIlAQEBBCMRRQwEAgEIEQQBAQMCBg8CDAMCAgIfERQBCAgBAQQOBQiHXQMRrVGbKw2HJReBKYskgWcWGwcGIQKCRjWBFAEDllqOVYVIgy2BTR5A X-IronPort-AV: E=Sophos;i="4.97,691,1389744000"; d="scan'208";a="28878213" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 20 Mar 2014 03:41:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2K3fnHR017119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 03:41:49 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.166]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 22:41:49 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson Thread-Topic: [rtcweb] Should consent checks be optimized further? Thread-Index: Ac9Ddg2wwxMgoYNeSLCvKCoxDf8YUwAU3gmAAAiUahA= Date: Thu, 20 Mar 2014 03:41:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vY-ljdy4rIH2p0d8fHst-Tcm9eU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should consent checks be optimized further? 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, 20 Mar 2014 03:42:01 -0000 R29vZCBwb2ludC4gVGhhdCB3b3VsZCByZXF1aXJlIGRpdmluZyBpbnRvIHRoZSBrZXkgZXhjaGFu Z2UgYW5kIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB1c2VkIGZvciB0aGUgcmV2ZXJzZSB0cmFm ZmljLCBpbnRyb2R1Y2luZyBtb3JlIGxheWVyaW5nIGlzc3Vlcy4NCg0KSSB0aGluayBleHBsaWNp dGx5IHJlcXVlc3RpbmcgZm9yIGNvbnNlbnQgd2hlbmV2ZXIgdGhlcmUgaXMgc29tZSB0cmFmZmlj IHRvIGJlIHNlbnQgaXMgbXVjaCBzaW1wbGVyIGFuZCBuZWF0ZXIgdGhhbiBpbmRpcmVjdGx5IGlu ZmVycmluZyBpdCBiYXNlZCBvbiB0aGUgdHJhZmZpYyByZWNlaXZlZCBhbmQgdHJ5aW5nIHRvIGZp eCB0aGUgc2VjdXJpdHkgbG9vcGhvbGVzLiBUaGUgZm9ybWVyIG5vdCBvbmx5IGtlZXBzIHRoZSBm dW5jdGlvbmFsaXR5IGNvbmZpbmVkIHRvIHRoZSBTVFVOIG1vZHVsZSAodGh1cyBlYXNpZXIgdG8g bWFpbnRhaW4pLCBidXQgYWxzbyBlbnN1cmVzIGl0IGhhcyB3aWRlciBhcHBsaWNhYmlsaXR5IC0t IGV2ZW4gd2hpbGUgcmVjZWl2aW5nIHVuYXV0aGVudGljYXRlZCB0cmFmZmljLiBJbiBhZGRpdGlv biwgSSBkb24ndCBzZWUgYW55IGJpZyBzYXZpbmdzIGlmIHdlIGluZmVyIGl0IGJhc2VkIG9uIHRo ZSB0cmFmZmljIHJlY2VpdmVkLg0KDQpNdXRodQ0KDQp8LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCnxGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bV0NCnxTZW50OiBXZWRuZXNkYXksIE1hcmNoIDE5LCAyMDE0IDExOjQ4IFBNDQp8VG86IE11dGh1 IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQp8Q2M6IHJ0Y3dlYkBpZXRmLm9yZw0KfFN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBTaG91bGQgY29uc2VudCBjaGVja3MgYmUgb3B0aW1pemVkIGZ1 cnRoZXI/DQp8DQp8T24gMTkgTWFyY2ggMjAxNCAwODowMSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1 bWFsIChtcGVydW1hbCkNCnw8bXBlcnVtYWxAY2lzY28uY29tPiB3cm90ZToNCnw+IFNob3VsZCBy ZWNlcHRpb24gb2YgYXV0aGVudGljYXRlZCB0cmFmZmljIGZyb20gdGhlIHBlZXIgb24gdGhlIGlu dmVydGVkDQp8PiA1LXR1cGxlIGJlIGNvbnNpZGVyZWQgYXMgcGVlciBncmFudGluZyBjb25zZW50 IHRvIHNlbmQgdHJhZmZpYyB0byBpdD8gU2hvdWxkDQp8PiB0aGUgYnJvd3NlciByZWZyYWluIGZy b20gcGVyZm9ybWluZyBjb25zZW50IGZyZXNobmVzcyB3aGVuIGl0IGNvbnRpbnVlcyB0bw0KfD4g cmVjZWl2ZSBzdWNoIHRyYWZmaWMgZnJvbSB0aGUgcGVlcj8NCnwNCnwNCnxZb3UgZm9yZ290IHRv IG1lbnRpb24gYW5vdGhlciBjb25jZXJuIGhlcmUsIHdoaWNoIGlzIHRoYXQgdGhlIHJlY2VpcHQN CnxvZiBhbiBhdXRoZW50aWNhdGVkIHBhY2tldCBpcyBub3Qgc3VmZmljaWVudCBpZiB0aGUgcGF0 aCBoYXMgY2hhbmdlZC4NCnxZb3UgbmVlZCB0byB2ZXJpZnkgdGhhdCB0aGUgcGVlciBvbiB0aGUg bmV3IHBhdGggaGFzIGJvdGggY29uc2VudGVkIHRvDQp8cmVjZWl2ZSBkYXRhIEFORCBpcyBpbiBw b3NzZXNzaW9uIG9mIHRoZSBzZXNzaW9uIGtleXMuICBPdGhlcndpc2UsIGluDQp8Y29tYmluYXRp b24gd2l0aCBzb3VyY2UgSVAvcG9ydCBzcG9vZmluZywgeW91IGdldCBhbiBhdHRhY2sgdGhhdCBh DQp8dmljdGltIGNhbm5vdCBvcHQgb3V0IG9mLg0K From nobody Thu Mar 20 02:15:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235091A06E8 for ; Thu, 20 Mar 2014 02:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRTVCVz7hYV3 for ; Thu, 20 Mar 2014 02:15:21 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BA3071A06F5 for ; Thu, 20 Mar 2014 02:15:20 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-6a-532ab19f29da Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C6.9D.04249.F91BA235; Thu, 20 Mar 2014 10:15:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 10:15:10 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Should we reference the pause/resume I-D? Thread-Index: Ac8+HSfEqf9sT+k2TCiwilJvB9C34g== Date: Thu, 20 Mar 2014 09:15:10 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFA4E43@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> <5328CF7D.1020703@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje78jVrBBqu/CFqc3ZZlsfZfO7sD k8eSJT+ZPD4sX8cWwBTFZZOSmpNZllqkb5fAlXG17SBLwQ7OiidbGtkaGG+zdzFyckgImEi8 vfufCcIWk7hwbz1bFyMXh5DAEUaJLb8PsEA4Sxgl/h5vYAGpYhMIlNi6bwEbiC0CZB/93QU2 SVjAXuJX+x12iLiDxK6OJ1A1ehInb9xmBLFZBFQlWmd0gtXwCvhKrLn/lAliwS9GiWs/H4Et YAQ64/upNWAnMQuIS9x6Mh/qPAGJJXvOM0PYohIvH/9jhbAVJT6+2scIUa8ncWPqFDYIW1ti 2cLXzBDLBCVOznzCMoFRZBaSsbOQtMxC0jILScsCRpZVjBzFqcVJuelGBpsYgWF/cMtvix2M l//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj7vWCM0qqii/cFN+w 7lpp7L3oE5EXtq/TdqmaEsavLRC9OfXIlU+xXA8Xmis9b9tzevWDV2vPlp/r21x8Y2vQ/5l9 976G593dbf9PkFWU9XHMCyNNxYfPJj99wztL2vySkv12jbKzBzvVYu82uMtP5Zjwerss44SA qwXbu888XBR4+IaPm6HlSyWW4oxEQy3mouJEAKNh64tJAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6eI000zqonaUhranHYziUs7DrsQ Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 20 Mar 2014 09:15:22 -0000 On 2014-03-18 23:59, Randell Jesup wrote:=0A= > On 3/12/2014 4:56 PM, Justin Uberti wrote:=0A= >> Agreed. Aren't there also patent declarations against this doc from=0A= >> multiple holders?=0A= >>=0A= >> While SDP will likely be removed from the API in the future, the=0A= >> replacement would be a app-specific message sent over websockets,=0A= >> which seems like it would work just fine.=0A= >=0A= > Except that WebSockets doesn't work peer2peer, which means both delay=0A= > and issues with signaling configurations without a server sitting=0A= > between the users.=0A= >=0A= > However, an app-specific message sent over a DataChannel should work=0A= > just fine.=0A= >=0A= > The downside would be that everything becomes app-specific, which would= =0A= > be a problem for any sort of federation or peering setup, and likely=0A= > gatewaying to legacy.=0A= =0A= I'm of the opinion that we should push a lot of signaling like this =0A= (pause/resume) to RTP/RTCP for those reasons, and in addition to enable =0A= the UA to save power/transmission for the user.=0A= =0A= But perhaps Bernard and Justin are right, this (v1) is not the right time.= =0A= =0A= >=0A= >=0A= =0A= From nobody Thu Mar 20 02:37:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968341A06F5 for ; Thu, 20 Mar 2014 02:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 BCNdqVREluGQ for ; Thu, 20 Mar 2014 02:37:23 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 751C91A08AC for ; Thu, 20 Mar 2014 02:37:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-55-532ab6becfe1 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 44.70.23809.EB6BA235; Thu, 20 Mar 2014 10:37:03 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.347.0; Thu, 20 Mar 2014 10:36:37 +0100 Message-ID: <532AB6A5.3070806@ericsson.com> Date: Thu, 20 Mar 2014 10:36:37 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <5322C475.5050402@ericsson.com> <5326F752.5050303@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvje7+bVrBBot/sFiseH2O3WLrVCGL tf/a2R2YPRZsKvVYsuQnk8fkx23MAcxRXDYpqTmZZalF+nYJXBknFs5iLbgsW3GtvZelgXGe eBcjB4eEgInEi9nFXYycQKaYxIV769lAbCGBQ4wSZzdHdTFyAdnLGSV2X3/EDpLgFdCWWLHn NJjNIqAqcWLXHrAGNgELiZs/GsFsUYFgiZ0HfjNC1AtKnJz5hAXEFhFQk3g4axcriM0sUC3x 9OBLsDnCAsYShy4vZYZYtpRdYu3ONWANnAKBEpc2/GKHOFRcoqcxCKJXU6J1+292CFteonnr bGaIo7UlGpo6WCcwCs1CsnoWkpZZSFoWMDKvYmTPTczMSS832sQIDNyDW36r7mC8c07kEKM0 B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjjM2RkGoQlW352bvx1umbVfHX1 toYyhYzNnPpxcmWzli60VJn+5vS8irKcWUe6X3DfOLagQ9X9hv5FtZtqfr/lLe5+YxWu/Rh+ /aOGJ3denIBV7c99mp9XPLvN/Ha9Wjxf1dYYr66QN/cd7NWEmqWOfZ4tdHnOC84bXd1/Nvum mJWpx1ir/lBiKc5INNRiLipOBABLeSNIKgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gt1585Gjj9i8QqjVXj5JSPnzgLE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux 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, 20 Mar 2014 09:37:25 -0000 Please see inline. This is as an individual! On 2014-03-20 01:21, Justin Uberti wrote: > On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund > > > wrote: > > > (still as individual) > > Lets be clear what we are discussing here. I don't think this is lot of > cases. And if you don't want to implement this in your code generating > offer, that is fine. What this describes is that your code handling > reception of offers and generating answers must be able to handle the > lack of a=rtcp-mux in any offer, rather than just the initial one. > > I would question if even that assumption holds considering what happens > if people start implementing session resumption or session mobility > between devices using rehydration style establishment procedures. What > one sides consider an initial offer might not be the state the answering > party is in. Thus, I am worried about cases that are first offer/answer > exchange related. > > To my understanding you will have code to handle the following cases > when offers contains: > > 1) No bundle, no a=rtcp-mux > 2) No bundle, with a=rtcp-mux > 3) Bundle, with a=rtcp-mux > > Considering that you support bundle, and you support usage or not of > a=rtcp-mux. Then I don't see how the code handling the SDP logic for > Bundle, without a=rtcp-mux is that significant. > > > It is significant because you always know you can rtcp-mux. And you > always know you can BUNDLE when rtcp-muxing. But I think trying to > BUNDLE a no-rtcp-mux m= line into a rtcp-mux m= line is asking for > problems. To be clear, I am arguing for consistent behavior and usage across the whole bundle group. Certainly you MUST NOT be allowed to have some m= line for RTP to use a=rtcp-mux and some other m= line in the same bundle group to not use it. What I am considering is the possibility to have a bundle group with multiple m= RTP lines that do not use a=rtcp-mux and instead have RTCP over a separate port. I started arguing that this was important for being able to recover PT space. But there is actually another reason for this. In cases when you have QoS, for example in cellular environment, mandating the use of rtcp-mux forces one to send the RTCP over the expensive QoS bearer. The amount of RTCP to support adaptation as well as codec control means that it is still likely that you want to spend at least 5% of the Video bandwidth on RTCP. If the cost associated with providing QoS for video can be reduced by 3-5% we in the cellular business definitely like to be able to utilize it. I would also like to stress that we are discussing what BUNDLE enables. RTCWEB is the first user of bundle, but likely not the only one. We have to be careful to apply all WebRTC context specific limitations on a general mechanism. First of all I really like to see that BUNDLE does not restrict ones choices if one like to multiplex RTP or RTCP when doing BUNDLE. As a general IETF SDP Signaling mechanism we need this generality. Secondly, I would strongly prefer that also RTCWEB's specifications do support this mode of operation. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 20 03:53:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60361A06CF for ; Thu, 20 Mar 2014 03:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 hnygrl3qnN_G for ; Thu, 20 Mar 2014 03:53:15 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0C82B1A06D9 for ; Thu, 20 Mar 2014 03:53:14 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-eb-532ac8910914 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 1C.7A.04853.198CA235; Thu, 20 Mar 2014 11:53:05 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.347.0; Thu, 20 Mar 2014 11:53:04 +0100 Message-ID: <532AC890.7000602@ericsson.com> Date: Thu, 20 Mar 2014 11:53:04 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <531DE104.2010908@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje7EE1rBBvsvSFtsnSpksfZfO7sD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK2L3qP2vBa/mKpgWtzA2M58W7GDk5JARMJM4u nsoIYYtJXLi3nq2LkYtDSOAEo8T3C1/YIZzljBI31/xjBaniFdCW+PNyP1gHi4CqxL9fz9lB bDYBC4mbPxrZQGxRgWCJnQd+M0LUC0qcnPmEBcQWEVCTeDhrF9gcZgF1iTuLz4H1CgvoSqxb vocJYtlWRokl3zaDNXAKBEpMvLgGyOYAOk9coqcxCKJXU6J1+292CFteonnrbGYQWwjotoam DtYJjEKzkKyehaRlFpKWBYzMqxgli1OLi3PTjQz0ctNzS/RSizKTi4vz8/SKUzcxAoP54Jbf RjsYT+6xP8QozcGiJM57nbUmSEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj7t2oh182aP7e WKuQeXrSRH3vI7xv3fu5P3LG3f7SmSS0tFLHIfTV143GajHea25uerCpSp+5+MvaFZsmL/0w SUGr7D+jwwb1Ve0eCo9+XxcxTtHK2b6da6lqjfaJzy8v2Icfufs47lVk3cP7L9P37Xgmebnw +KVVRuetLm87ZPQ2wm2mnOmxYiWW4oxEQy3mouJEAGryzdc0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AQ3-PiCApvxYDSD7hTbjrvJCrFU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On ptimes and maxptimes 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, 20 Mar 2014 10:53:17 -0000 On 2014-03-20 01:27, Justin Uberti wrote: > > > > On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund > > > wrote: > > Hi, > > (As individual) > > On 2014-03-05 17:26, Justin Uberti wrote: > > From the session this morning, I recall this consensus: > > > > * We will add recommendations on the frame sizes to use for > PCMU/A to > > the rtcweb audio codec I-D (20, 30, 60 ms frames). > > The above applies to sending payloads > > > Right, thanks for pointing that out. > > > Yes, but that was given that a receiver will be capable of receiving any > valid number of frames, or samples within a reasonable packetization, > and I think that should be 120 ms. > > > * We will consider adding an a=maxptime attribute that > represents the > > "minimum maxptime" of all the offered codecs. That is, if both > Opus > > (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a > > maxptime=60 SHOULD be included. > > o Since maxptime spans all codecs, this means that some modes > > (e.g. Opus 120ms) will be unavailable, unless only Opus is > offered. > > I think you base the assumption on maxptime based on the sending > recommendations, not what is capable of receiving. If one is capable of > receiving 200 ms of a-law and Opus, then you would need to say 120 ms as > Opus will limit you. > > > I agree that Opus' maxptime is 120, but should that prevent sending PCMU > with 200 ms? That is, since sending Opus with 200 ms is not legal, is > there any point in forcing WebRTC impls to indicate this in SDP? What I wished we fixed this issue with maxptime a long time ago. This is a well known problem that it really has PT scope, but are signalled on m= line scope. > > > > > * We will consider adding an a=ptime attribute, set to the > receiver's > > preferred frame size to receive. Again, this value spans all > codecs, > > so the specified value may not be viable for all codecs (e.g. > 30 ms > > works for PCMU but not for Opus) > > > > After thinking about this some, I'm not sure the maxptime/ptime values > > will lead to any different behavior than if they were not specified. > > Since there is a complexity cost (especially if the values need to > > change based on which codecs are offered), is there a clear upside > here? > > The maxptime values may in some cases be limited downwards for > interoperability, for example if one like to gateway AMR into a CS > network then the gateway might indicate a maxptime that is less, more > like 20 or 40 ms. > > > Sure - WebRTC impls need to respect any maxptime value that they > receive, but it's not clear to me that they need to include one in the > SDP they send. Ok, but then we are back to my previous argument for writing down what receiver requirement in regards to each payload type one is required to support in the audio draft for the ones specified there. But what about the other codecs that aren't included in the audio draft? How can a peer know if there are limitations? I wouldn't attempt to solve the general problem of the scope issue with maxptime. Simply state that you should include this. It is going to be limited but still provide information in many cases that is quite useful for the sender. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 20 04:42:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD651A0780 for ; Thu, 20 Mar 2014 04:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NpckmIOzXWo for ; Thu, 20 Mar 2014 04:42:04 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D76A41A071B for ; Thu, 20 Mar 2014 04:42:03 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d17so551134eek.29 for ; Thu, 20 Mar 2014 04:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=By8SfoLMNOcJcj+epJDEz2nxtOW2RC2ajGcCHakXpQ8=; b=c3PhfxC0WW35u0t50vh5JD75Vw7dyclIgadTccNiq/xP2AYcQStK8yKdHCsW0BLkUN feZNj/mfdWFccRiRjT1SoU6gtz9nDJgx9PVYn2gCdmXcaOOahDU4l/DQonPmZZTbrHe4 cC4xnUd4cl/3U5dcpEhHAPZi++fa7VXIl0VmSk2/yGRHGq1Wgbb0MSwkSJFDL5Da1Ouh TC8THISGs+8Dm7Xlbmu37V/RL2GFE7c+3/E+22agAG7jC1wAGZk4YCLSV3/J6PmDh4Du 8KY+TjJ6d+L2xN+W+Aai4XK5F/tr9NZQddYGAptCOrX53UceL0qNzNpihAiFHMS6BKR2 Nlnw== X-Received: by 10.15.41.140 with SMTP id s12mr41417465eev.4.1395315714447; Thu, 20 Mar 2014 04:41:54 -0700 (PDT) Received: from RoniE (bzq-79-177-105-122.red.bezeqint.net. [79.177.105.122]) by mx.google.com with ESMTPSA id x45sm3657169eef.15.2014.03.20.04.41.51 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Mar 2014 04:41:53 -0700 (PDT) From: "Roni Even" To: "'Justin Uberti'" , "'Bernard Aboba'" References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> In-Reply-To: Date: Thu, 20 Mar 2014 13:41:47 +0200 Message-ID: <03c301cf4431$62655c90$273015b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C4_01CF4442.25EF16F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG40hOjRt6QEED99AEB0hJqlXDfEwGYh9JwAvRKJ7ea8ld8UA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VdJNKCY1pl-pfxmXHU0Toi62hwA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 20 Mar 2014 11:42:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03C4_01CF4442.25EF16F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The pause and resume has the tmmbr=3D0 option based on RFC5104 (No IPR = in the data base for RFC 5104; = http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft-ietf-avt-avpf-ccm) . this works well for point to point case. Roni =20 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 March, 2014 10:56 PM To: Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Should we reference the pause/resume I-D? =20 Agreed. Aren't there also patent declarations against this doc from = multiple holders? =20 While SDP will likely be removed from the API in the future, the = replacement would be a app-specific message sent over websockets, which = seems like it would work just fine. =20 On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba = wrote: While I do like the pause/resume draft, having core RTCWEB WG documents = (such as RTP Usage) depend on it seems like a bit of a stretch. After = all, the document was only adopted last week, and it is a rare IETF WG = document that can go from a -00 WG draft to publication as an RFC in = under a year.=20 =20 On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=C3=A5kansson LK = wrote: Hi, at the IETF last week there was consensus in the AVTEXT WG meeting to adopt the pause/resume draft [1] as a WG draft. In rtcweb/webrtc we're have the situation that we're discussing so called "doo-hickeys" as an API surface where the web app (amongst other things) can pause and resume the sending of a track. This can be signaled with the direction attribute and a SDP O/A exchange (and the app pausing/resuming sending of a track would presumably lead to a "negotiationneeded" event being fired). But I think we should in addition require the browser to signal it according to one of the methods in [1] (e.g. TMMBN =3D 0), and also understand that signaling (a browser receiving TMMBN =3D 0 must know = that the other end-point will pause sending). My argument is that we know that many dislike SDP in rtcweb, and a likely development is that it will be removed in a later version. My speculation is that signaling as outlined in [1] will then be used for pause/resume. If we support this from the beginning earlier implementations could more easily interop with those later versions. Stefan [1] https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt= _______________________________________________ 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 ------=_NextPart_000_03C4_01CF4442.25EF16F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

The pause and resume has the tmmbr=3D0 option based on RFC5104 (No = IPR in the data base for RFC 5104; = http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3D= draft-ietf-avt-avpf-ccm)=C2=A0 . this works well for point to point = case.

Roni

 

From:= = rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: 12 March, 2014 10:56 PM
To: Bernard = Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] = Should we reference the pause/resume = I-D?

 

Agreed. = Aren't there also patent declarations against this doc from multiple = holders?

 

While SDP will likely be removed from the API in the = future, the replacement would be a app-specific message sent over = websockets, which seems like it would work just = fine.

 

On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <bernard.aboba@gmail.com> = wrote:

While I do like the = pause/resume draft, having core RTCWEB WG documents (such as RTP Usage) = depend on it seems like a bit of a stretch. After all, the document was = only adopted last week, and it is a rare IETF WG document that can go = from a -00 WG draft to publication as an RFC in under a year. =

 

On Wed, Mar 12, 2014 at 11:01 AM, Stefan = H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> = wrote:

Hi,

at the IETF last = week there was consensus in the AVTEXT WG meeting to
adopt the = pause/resume draft [1] as a WG draft.

In rtcweb/webrtc we're have = the situation that we're discussing so
called "doo-hickeys" = as an API surface where the web app (amongst other
things) can pause = and resume the sending of a track. This can
be signaled with the = direction attribute and a SDP O/A exchange (and the
app = pausing/resuming sending of a track would presumably lead to = a
"negotiationneeded" event being fired).

But I = think we should in addition require the browser to signal = it
according to one of the methods in [1] (e.g. TMMBN =3D 0), and = also
understand that signaling (a browser receiving TMMBN =3D 0 must = know that
the other end-point will pause sending).

My argument = is that we know that many dislike SDP in rtcweb, and a
likely = development is that it will be removed in a later version. = My
speculation is that signaling as outlined in [1] will then be used = for
pause/resume. If we support this from the beginning = earlier
implementations could more easily interop with those later = versions.


Stefan

[1]
https://tools.ietf.org/id/draft-westerlund-avtext-rtp-s= tream-pause-05.txt

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

 

------=_NextPart_000_03C4_01CF4442.25EF16F0-- From nobody Thu Mar 20 07:53:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311941A046A for ; Thu, 20 Mar 2014 07:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GedswjfwdkYj for ; Thu, 20 Mar 2014 07:53:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B00041A0747 for ; Thu, 20 Mar 2014 07:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10227; q=dns/txt; s=iport; t=1395327176; x=1396536776; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=ujTpFfmoFZeFfOL2U6m9IQTmtx76w1wbH9B94nj2PFk=; b=dRwYdHrmRp0mq4xJC4oxr06GPBXuy7L30yXvrFQNletpbdRAY3pmxb5Z z32G8jdn7Tu07lss6C5UzfvwaHgHWqLP3TNK3R2/YyBKKad4H8RLvucvP 8Fmax1/y02MWJF30VmWeBHQn2Ykz1+1b/pF3pgJXxFsmMpKEp99mfhhjx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAOz/KlOrRDoH/2dsb2JhbABZgkJEO4UftlSGYlGBGBZ0giUBAQEDAQEBAWsLBQsLGC4nMAYTh3EHDs9XEwSOYQQHgySBFASJUosJg2ySMINNHYEsJA X-IronPort-AV: E=Sophos;i="4.97,695,1389744000"; d="scan'208,217";a="106021096" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 20 Mar 2014 14:52:55 +0000 Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2KEqtTT002903; Thu, 20 Mar 2014 14:52:55 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_62047197-D5B8-4167-8334-CAF775DE4C11" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: <5329B617.2070001@alvestrand.no> Date: Thu, 20 Mar 2014 07:52:58 -0700 Message-Id: <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> References: <5329B617.2070001@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KD-qtdvwUC50r7xKkWDBBg-Z_3U Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 14:53:10 -0000 --Apple-Mail=_62047197-D5B8-4167-8334-CAF775DE4C11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 19, 2014, at 8:21 AM, Harald Alvestrand = wrote: > On 03/19/2014 04:08 PM, Dan Wing wrote: >>=20 >> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand = wrote: >>=20 >>> I'd like to be silent on the issue, since which IPv6 addresses to = prefer is likely to be a matter of system policy. Trying to override = system policy in an application specific profile usually leads to = sadness. >>=20 >> The application needs to indicate if it wants a temporary address. If = the host's policy (or configuration or network) does not support = temporary addresses, the application won't get a temporary address. I = don't see why being silent helps? >=20 > What API is it using? >=20 > With a little Googling, the system policy I was thinking of was the = policy in RFC 6724 ("Default Address Selection for IPv6"), in particular = section 5 rule 7: "Prefer temporary addresses". >=20 > I'm happy to say "it is a good idea for systems to implement the = recommendations of RFC 6724" (or some more 2119-like language). I = wouldn't want to claim that if a system has chosen to prefer = non-temporary addresses, it would have to change its non-conformance to = RFC 6724 in order to be conformant with RTCWEB specifications. So perhaps: "An RTCWEB implementation SHOULD prefer to use temporary addresses = [RFC4941] where host and network policy permit [RFC6724]." ? -d >=20 >>=20 >> -d >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing wrote: >>>=20 >>> On Mar 18, 2014, at 6:00 PM, Justin Uberti = wrote: >>>=20 >>>> https://tools.ietf.org/html/rfc4941 defines the concept of = temporary IPv6 addresses. For, example, as enumerated on my local = system: >>>>=20 >>>> inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 >>>> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf=20 >>>> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf = temporary=20 >>>>=20 >>>> As indicated in the RFC, the temporary addresses expire after hours = or days, and therefore could be used to prevent long-term linkability of = sessions. Expiration shouldn't be an issue for WebRTC, since we can = simply do ICE restart if this occurs during a session. >>>>=20 >>>> Is this something we want to recommend in the transports doc? >>>=20 >>> Yes. >>>=20 >>> And it should be as frequent as every new 'call', if IPv6 privacy = addresses are to provide the same privacy as a NAPT44, as a NAPT44 = should be assigning random ports per reasons described in RFC6056. >>>=20 >>> The transport document should also recommend doing port = randomization (RFC6056), as that was found pretty useful for DNS, but = randomizing ports is still not popular with many OS's TCP stacks for = whatever reason. >>>=20 >>> -d >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_62047197-D5B8-4167-8334-CAF775DE4C11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Mar 19, 2014, at 8:21 AM, Harald = Alvestrand <harald@alvestrand.no> = wrote:

On = 03/19/2014 04:08 PM, Dan Wing wrote:

On Mar 19, 2014, at 12:02 AM, Harald = Alvestrand <hta@google.com> wrote:

I'd like to be silent on the issue, since which IPv6 = addresses to prefer is likely to be a matter of system policy. Trying to = override system policy in an application specific profile usually leads = to sadness.

The application needs = to indicate if it wants a temporary address. If the host's policy (or = configuration or network) does not support temporary addresses, the = application won't get a temporary address.  I don't see why being = silent helps?

What API is it = using?

With a little Googling, the system policy I was thinking = of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in = particular section 5 rule 7: "Prefer  temporary = addresses".

I'm happy to say "it is a good idea for systems to = implement the recommendations of RFC 6724" (or some more 2119-like = language). I wouldn't want to claim that if a system has chosen to = prefer non-temporary addresses, it would have to change its = non-conformance to RFC 6724 in order to be conformant with RTCWEB = specifications.

So = perhaps:
   "An RTCWEB implementation SHOULD prefer = to use temporary addresses [RFC4941] where host and network policy = permit = [RFC6724]."
?

-d



-d





On Wed, Mar 19, = 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:

On Mar 18, 2014, at = 6:00 PM, Justin Uberti <juberti@google.com> wrote:

https://tools.ietf.org/html/rfc4941 defines the concept of = temporary IPv6 addresses. For, example, as enumerated on my local = system:

inet 172.31.x.y netmask 0xfffffe00 = broadcast 172.31.x.255
inet6 = 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 = autoconf 
inet6 = 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 = autoconf temporary =

As indicated in the RFC, the = temporary addresses expire after hours or days, and therefore could be = used to prevent long-term linkability of sessions. Expiration shouldn't = be an issue for WebRTC, since we can simply do ICE restart if this = occurs during a session.

Is this something we = want to recommend in the transports = doc?

Yes.

And it should be as frequent as every new 'call', if = IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a = NAPT44 should be assigning random ports per reasons described in = RFC6056.

The transport document should also = recommend doing port randomization (RFC6056), as that was found pretty = useful for DNS, but randomizing ports is still not popular with many = OS's TCP stacks for whatever reason.

-d






_______________________________________________
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

= --Apple-Mail=_62047197-D5B8-4167-8334-CAF775DE4C11-- From nobody Thu Mar 20 07:54:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B121A046A for ; Thu, 20 Mar 2014 07:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0FeohlJVZwY for ; Thu, 20 Mar 2014 07:54:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 70B7C1A03EF for ; Thu, 20 Mar 2014 07:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=835; q=dns/txt; s=iport; t=1395327249; x=1396536849; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=j2iEXSDFpmZixOk91v3X6AqG6EEh87v1yEznoI/X8F8=; b=G39foDTGKTKLSO/XUs1bVsZZLWgaJL6NT5tWqksJ1XDdilqtQLKoziBy lZPQCKSWUow83/BnAUVzpcZF4ODdgkh25y4nlsWWgVvAoNRR6MI7B0Ogn TXUHHinNF00SSyd66wbmDPqgtufZo8olCxSLUumzp4S43/J20qvTZOq3Y Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJsAK1OrRDoG/2dsb2JhbABZgwbDYYEYFnSCJQEBAQMBeQULC0ZXBhOHcQfPaBeOMjMHgySBFASJUo51kjCDTR2BLCQ X-IronPort-AV: E=Sophos;i="4.97,695,1389744000"; d="scan'208";a="108541481" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 20 Mar 2014 14:54:09 +0000 Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2KEs5HV027493; Thu, 20 Mar 2014 14:54:08 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: <5329BA17.7080701@viagenie.ca> Date: Thu, 20 Mar 2014 07:54:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5329BA17.7080701@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dszuEFs5n03HCv09lE1AV620tF4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 14:54:21 -0000 On Mar 19, 2014, at 8:39 AM, Simon Perreault = wrote: > Le 2014-03-19 03:02, Harald Alvestrand a =E9crit : >> I'd like to be silent on the issue, since which IPv6 addresses to = prefer >> is likely to be a matter of system policy. Trying to override system >> policy in an application specific profile usually leads to sadness. >=20 > What would be useful to mention IMHO is that ICE restart should be = used > to gracefully handle the issue of IP address expiry, of which = temporary > IPv6 addresses are a frequently-encountered example. When a temporary address expires, existing sockets bound that address = should continue working with that expired address -- have you found = otherwise on any OS, such that we would need ICE Mobility for temporary = address expiration? -d From nobody Thu Mar 20 08:20:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A241A0764 for ; Thu, 20 Mar 2014 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG4miMsMMeH7 for ; Thu, 20 Mar 2014 08:20:03 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 96D051A046A for ; Thu, 20 Mar 2014 08:20:00 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-8e-532b07167e6a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6E.D7.04249.6170B235; Thu, 20 Mar 2014 16:19:50 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.347.0; Thu, 20 Mar 2014 16:19:49 +0100 Message-ID: <532B0716.8080506@ericsson.com> Date: Thu, 20 Mar 2014 16:19:50 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvja4Yu3awwaEZJhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro7f/MHNBJ1vF05NrmBoYW1i7GDk5JARMJPad74KyxSQu3FvP 1sXIxSEkcIRR4sCkfSwQznJGiWX77rCDVPEKaEv8m/sGqIqDg0VAVeLahCiQMJuAhcTNH41s ILaoQLDE0jmLWSDKBSVOznwCZosIqEtcfngBbIywgLXEpAPnWUHGSAiIS/Q0BoGEmQX0JKZc bWGEsOUlmrfOZgaxhYC2NjR1sE5g5J+FZOosJC2zkLQsYGRexchRnFqclJtuZLCJERhOB7f8 ttjBePmvzSFGaQ4WJXHej2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwem+vjp06q+zA s1XsvPPCxHblBP5OyZ3ZmvpKQPzopcjPNqFS1/R+Lvxyv/9v8OE7C4zEjIs7w1KdJs2ev8Di rvrx/2/WS+W/PLXNbrKn+LtJ7Lb3f2z+L7bO1j7f9N/R0qN8rzf5bAkJ/WQwoWtqwSvNz4Xz WjdGiIpacJS+5mTJzazN49QXV2Ipzkg01GIuKk4EAIZ1zr31AQAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MDiFC2jcOjNmxyJSjF38uO4dhlg Subject: [rtcweb] Draft minutes for Tuesday RTCWEB session in London 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, 20 Mar 2014 15:20:05 -0000 WG, Here is the initial version of the minutes for Tuesdays (2014-03-04) RTCWEB WG session in London. It is available here: http://www.ietf.org/proceedings/89/minutes/minutes-89-rtcweb Please send any corrections to the mailing list. Wednesday's minutes are forthcoming. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 20 08:52:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712B01A076C for ; Thu, 20 Mar 2014 08:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 vjKx_QvWi3mp for ; Thu, 20 Mar 2014 08:51:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7001A0743 for ; Thu, 20 Mar 2014 08:51:53 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E2BF6403B0; Thu, 20 Mar 2014 11:51:43 -0400 (EDT) Message-ID: <532B0E8F.3000002@viagenie.ca> Date: Thu, 20 Mar 2014 11:51:43 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dan Wing References: <5329BA17.7080701@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CbB6Wre8Ou8OyWoYwf_PlQHPYZY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 15:51:58 -0000 Le 2014-03-20 10:54, Dan Wing a écrit : > > On Mar 19, 2014, at 8:39 AM, Simon Perreault wrote: > >> Le 2014-03-19 03:02, Harald Alvestrand a écrit : >>> I'd like to be silent on the issue, since which IPv6 addresses to prefer >>> is likely to be a matter of system policy. Trying to override system >>> policy in an application specific profile usually leads to sadness. >> >> What would be useful to mention IMHO is that ICE restart should be used >> to gracefully handle the issue of IP address expiry, of which temporary >> IPv6 addresses are a frequently-encountered example. > > When a temporary address expires, existing sockets bound that address should continue working with that expired address -- have you found otherwise on any OS, such that we would need ICE Mobility for temporary address expiration? When the address is removed from the interface, it doesn't matter if the socket is still "good" or not. The address is no longer on the interface so you will not receive packets sent to that address. I'm looking at the Linux and OpenBSD IPv6 stacks right now and neither seems to care about existing sockets before expiring an address. Haven't tried it though. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 20 09:30:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24C31A03BF for ; Thu, 20 Mar 2014 09:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 8REbjcoeeY2O for ; Thu, 20 Mar 2014 09:30:38 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DD9BF1A0782 for ; Thu, 20 Mar 2014 09:30:37 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so1219165vcb.8 for ; Thu, 20 Mar 2014 09:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rRRs3esRzkDZZ6+HpIG1HAfz2RqHsHJWjRUN+0ZDG8M=; b=WP/j9mMbs8/WWSRyLMyexIIyrPDdiY1LJ/5mdSEKYrOTaHbQijKFoLNkxK3HXZoS/f dy+IrgTck1RyAbv/6u69b+uxyJ94rzHJwj6gQ0NSvFa2WK0hwG85RnTOxYGpPnTYoQnf xL1HQVPQIB3/j2CUVVudNnMAsc9SC97AM8UmBhQxrLYLSrJGORFGzQ41Z7+pPCrJZfY+ g1+b26NJJuDlDUAoCxEIbuLkOTTnJDQRWX5T31okiXDLY+fejfhaWSiWoZsZKeXVv2wr DUvgmNoZFUJgkZeUkx8YAEtcwQg4r5MxLRMXhjm4MvOc2w67abnvabZwg5S1rJ27w0ye 6CEA== 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=rRRs3esRzkDZZ6+HpIG1HAfz2RqHsHJWjRUN+0ZDG8M=; b=Ky/SzWpV35tSySc8Cl7GfppICeRahHoPuS7hArTTixkpEZw9T8FAuejTypVDw5m48D ZuQVSui6DW8R2L40M+/xNyppFBByhgtrinwSys6FMQ9yCzN7xSVys5869f/lj6/1iiv4 Rbv6BCKz5k0VEwmcjZ6VPptAkfyv+geds7kp0TF5SlV18hZKi4JuvZYP+D3wS15mmHhL 3cgg+KGPbblBJw/GSeGqnt22iDeRrhhmAWVG5ZPPnpYCBnX8un3yNYlEzR+vPPXJpil7 EdUYBty8VKiXB7qz5SptRj4pSFjzsFqyaNB92UgZumSpJIQTSiwCV9ZfE277wSO4bXq3 y8Uw== X-Gm-Message-State: ALoCoQlacUI3Et3e7ZQKGnjzFPjxwl22QkvMUe7PTbKZ9Y6paoJdRsvDU4xBmMJgo8wn79szov4+GpGEqAewPfSi6OA6L+EO6jiYxumQjodf5OWMki5T38grkchAk5dxNkM1YLiubNtCy5cW59e43b+DYF4osnUCfTVO9IsUR/kxGZ2iFnSF04coJVF0x11ibnbO8I3yyRbS X-Received: by 10.58.152.142 with SMTP id uy14mr2394712veb.4.1395333028677; Thu, 20 Mar 2014 09:30:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 09:30:08 -0700 (PDT) In-Reply-To: <532B0E8F.3000002@viagenie.ca> References: <5329BA17.7080701@viagenie.ca> <532B0E8F.3000002@viagenie.ca> From: Justin Uberti Date: Thu, 20 Mar 2014 09:30:08 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=089e0129421884a16104f50c499c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_CxAbGs0qCntND5k1BJGfcA-XT0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 16:30:39 -0000 --089e0129421884a16104f50c499c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2014 at 8:51 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-20 10:54, Dan Wing a =C3=A9crit : > > > > On Mar 19, 2014, at 8:39 AM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > > > >> Le 2014-03-19 03:02, Harald Alvestrand a =C3=A9crit : > >>> I'd like to be silent on the issue, since which IPv6 addresses to > prefer > >>> is likely to be a matter of system policy. Trying to override system > >>> policy in an application specific profile usually leads to sadness. > >> > >> What would be useful to mention IMHO is that ICE restart should be use= d > >> to gracefully handle the issue of IP address expiry, of which temporar= y > >> IPv6 addresses are a frequently-encountered example. > > > > When a temporary address expires, existing sockets bound that address > should continue working with that expired address -- have you found > otherwise on any OS, such that we would need ICE Mobility for temporary > address expiration? > > When the address is removed from the interface, it doesn't matter if the > socket is still "good" or not. The address is no longer on the interface > so you will not receive packets sent to that address. > > I'm looking at the Linux and OpenBSD IPv6 stacks right now and neither > seems to care about existing sockets before expiring an address. Haven't > tried it though. > > On Mac, the temporary addresses seem to change every day, but any existing addresses seem to remain valid for a week. --089e0129421884a16104f50c499c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 8:51 AM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-20 10:54, Dan Wing a =C3=A9crit :=
>
> On Mar 19, 2014, at 8:39 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
>
>> Le 2014-03-19 03:02, Harald Alvestrand a =C3=A9crit :
>>> I'd like to be silent on the issue, since which IPv6 addre= sses to prefer
>>> is likely to be a matter of system policy. Trying to override = system
>>> policy in an application specific profile usually leads to sad= ness.
>>
>> What would be useful to mention IMHO is that ICE restart should be= used
>> to gracefully handle the issue of IP address expiry, of which temp= orary
>> IPv6 addresses are a frequently-encountered example.
>
> When a temporary address expires, existing sockets bound that address = should continue working with that expired address -- have you found otherwi= se on any OS, such that we would need ICE Mobility for temporary address ex= piration?

When the address is removed from the interface, it doesn't matter= if the
socket is still "good" or not. The address is no longer on the in= terface
so you will not receive packets sent to that address.

I'm looking at the Linux and OpenBSD IPv6 stacks right now and neither<= br> seems to care about existing sockets before expiring an address. Haven'= t
tried it though.


On Mac,= the temporary addresses seem to change every day, but any existing address= es seem to remain valid for a week.=C2=A0
--089e0129421884a16104f50c499c-- From nobody Thu Mar 20 09:35:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8341A07C1 for ; Thu, 20 Mar 2014 09:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 f_KjyI1XE0g5 for ; Thu, 20 Mar 2014 09:35:05 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E78921A0770 for ; Thu, 20 Mar 2014 09:35:04 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id id10so1234403vcb.26 for ; Thu, 20 Mar 2014 09:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PfaFudb1lJAzVQDlGJ4mBN+kOhnLly6nqdBG98XxVYg=; b=D6IeIWBtWy28xlbxzXZtmqyPwsxcLPxyZORqjqgwMhK5PQrxt/zFgC3wq9tnw63ugh R6Sfion7Bu2Doys9WFgKMp1MdDfltq7VT+XpKa8+eR1ipF7UmDRZ/Eqbs3zepvmHv3MP E08wCKYEVOFI9nUvskRdXbMOuczBayOqY/sXPdarnS3y3RtQeNEx8AsFGEXBh1+ZfnET ag4j6b19tUHkoUdq2TNo6UB4JG6WC1xuJr1V6ON2DjbqpDfTH5rsskWwvxoTm0Cpdjfy JGNdcEHLhpwW1FTT4Jv9rvBRkLzq/7iH66V/AZ5OP0bUapowlFHATF8ZgeStBpQ6AXy/ TYYg== 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=PfaFudb1lJAzVQDlGJ4mBN+kOhnLly6nqdBG98XxVYg=; b=Spmm0nu00Gea2kx1H7CjKmsFIQIBmDk+Dx7RzW1Rs9LIPufn6fQiSGO4MAB/s6n7jJ aGu+L74vqH+kcKyPiNzEHT4TR5tl8Ihyi71ySV3EIRZ4K/Ko/U5C7KX7hgutRlFzidPS 8a1kAC1RyDxb+N6SP7yem3lI4eYS4LFf6e8EpUxjIqP/o7x/VlpgtZpB7nEwePGpUB6p 9HzITjodPkBSkk+cGO1CkSGqn9O6MctnZNpDjoGyYmeDFZmopIAMgvNMranOBEd/QQ7P 6t30SkjcSdSBDyEID2QLXMqcx4R79ZDClwTBSw0beaD5ImY/dIkN8vO98o57bnNMO++8 6srA== X-Gm-Message-State: ALoCoQl1rn/6e4BulIbrrWGuKFzLjrLWoOi6GMeR/WH8qPymJ4k83FyiQGb0A160u1oQci6d246wtdli3HB1XmQfwSffyh/9kBGZ57nJTGaAQezpmOotcSYsBDruylJeP/AHUz/AQzn5OmbWL2TERz+cHm6zTTetH9UDgU5qyuAuxUO+j2GfL56OeH6mhdwbNthpv3Vkg0Uv X-Received: by 10.52.69.146 with SMTP id e18mr29097831vdu.15.1395333295732; Thu, 20 Mar 2014 09:34:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 09:34:35 -0700 (PDT) In-Reply-To: <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> From: Justin Uberti Date: Thu, 20 Mar 2014 09:34:35 -0700 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=20cf3071cd0e6f99fb04f50c59f7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eFsDcREVpS8Try4lXXMNqOXS9Hg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 16:35:07 -0000 --20cf3071cd0e6f99fb04f50c59f7 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing wrote: > > On Mar 19, 2014, at 8:21 AM, Harald Alvestrand > wrote: > > On 03/19/2014 04:08 PM, Dan Wing wrote: > > > On Mar 19, 2014, at 12:02 AM, Harald Alvestrand wrote: > > I'd like to be silent on the issue, since which IPv6 addresses to prefer > is likely to be a matter of system policy. Trying to override system policy > in an application specific profile usually leads to sadness. > > > The application needs to indicate if it wants a temporary address. If the > host's policy (or configuration or network) does not support temporary > addresses, the application won't get a temporary address. I don't see why > being silent helps? > > > What API is it using? > > With a little Googling, the system policy I was thinking of was the policy > in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 > rule 7: "Prefer temporary addresses". > > I'm happy to say "it is a good idea for systems to implement the > recommendations of RFC 6724" (or some more 2119-like language). I wouldn't > want to claim that if a system has chosen to prefer non-temporary > addresses, it would have to change its non-conformance to RFC 6724 in order > to be conformant with RTCWEB specifications. > > > So perhaps: > "An RTCWEB implementation SHOULD prefer to use temporary addresses > [RFC4941] where host and network policy permit [RFC6724]." > ? > I think it needs to be stronger than that - something like "where host and network policy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses". Preferring to use temporary addresses is probably not sufficient to prevent linkage, since you will have connectivity checks from the non-temporary addresses. (i.e. an eavesdropper listening over an extended period of time could determine calls are from the same endpoint) --20cf3071cd0e6f99fb04f50c59f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing <dwing@cisco.com> wrote:

On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <harald@alvestrand.n= o> wrote:

On 03/19/2014 04:08 PM, Dan Wing wrote:

On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> wrot= e:

I'd like to be silent on= the issue, since which IPv6 addresses to prefer is likely to be a matter o= f system policy. Trying to override system policy in an application specifi= c profile usually leads to sadness.

The application needs to indicate if it wa= nts a temporary address. If the host's policy (or configuration or netw= ork) does not support temporary addresses, the application won't get a = temporary address. =C2=A0I don't see why being silent helps?

What API is it using?

With a little Googling,= the system policy I was thinking of was the policy in RFC 6724 ("Defa= ult Address Selection for IPv6"), in particular section 5 rule 7: &quo= t;Prefer=C2=A0 temporary addresses".

I'm happy to say "it is a good idea for systems to implement t= he recommendations of RFC 6724" (or some more 2119-like language). I w= ouldn't want to claim that if a system has chosen to prefer non-tempora= ry addresses, it would have to change its non-conformance to RFC 6724 in or= der to be conformant with RTCWEB specifications.

So perhaps:
=C2=A0 = =C2=A0"An RTCWEB implementation SHOULD prefer to use temporary address= es [RFC4941] where host and network policy permit [RFC6724]."
?

I think it needs to be stronge= r than that - something like=C2=A0
"where host and network p= olicy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses= and SHOULD NOT gather non-temporary addresses".

Preferring to use temporary addresses is probably not s= ufficient to prevent linkage, since you will have connectivity checks from = the non-temporary addresses. (i.e. an eavesdropper listening over an extend= ed period of time could determine calls are from the same endpoint)

--20cf3071cd0e6f99fb04f50c59f7-- From nobody Thu Mar 20 09:40:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3134D1A07AA for ; Thu, 20 Mar 2014 09:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.547, 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 34r6VzkpZFPh for ; Thu, 20 Mar 2014 09:40:18 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3555E1A07A8 for ; Thu, 20 Mar 2014 09:40:18 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id id10so1243548vcb.26 for ; Thu, 20 Mar 2014 09:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CFI7jg6jLy/3RDMIBnDJRJlFEv5/iDDaiak4NBbSZM0=; b=W8VH6R51eCVV4QX1tHjgPD05WixN+Jii9vFNiue8UCFp4ARSK+ffd49ilszE8K0eLT 4xeEwFdOTo9iGEHFKP6V44Azspzo7b7jJvKPtakn+jWNIwRTlS8kmZ/To6NfQc8pCR69 GMLZBJL9Q/E8wrthwdh4vnl2xXVp2BoRGEKjt9kb/KFfgGPa8CuXrqygREiiY/Ts7dWd bPkhpKNicWd/9NoEC64iNzTne0WB6QeqoJi+vQ00tdcR9S5O8y1qF/+X4hGgH4V5pDfw P8h0JhSRMH7bIOHKRmD1M35OC1U3UjpDwF+ugcRRf5txiwfke/nBlNapYfsjmG24wWEF e9VA== 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=CFI7jg6jLy/3RDMIBnDJRJlFEv5/iDDaiak4NBbSZM0=; b=J0QCzf3Cm6eoL2s2CoF4JkO4MXaPk7gpFYDF4K3ZcwP2/y8q6FdcqUjjDpQ0L0nCwV rifVcxSCFGzh47BFO1Xh72CJHrsvfQcpUvTEI9b04xlI8VRcFjFyDVB51QxKspSW3Vh3 Si4HqQIlPwRRTiBs49OBJq4Ya7B834ir7+7/QCl5f4Zx/FuqV22kZ53OZ1pA1AOWOLoT GYIGyGyYixeR7BXwPV4ZQkeSncXSZINI5caZjWG3hOS+bR1TYOd6sxr9dUvsUaJeGBNn Pm0gY8sPlQQDmXTU89FLjNEzMdkzu3v0vCz45zHEArMaOQnZ4xDvEXUBSjQVZmzq1rz0 VNkg== X-Gm-Message-State: ALoCoQm1cKwCAPefUo0u+q0nzoXSt4N5y4wyWCriNhHKeUYa+BFZSO/C5J1TCHVx3F3MdHkwvmByvx8QGSU9s9PUqYDwZBaZj8lOOwDTqhFDbF4hk7/r+E9NRNkrHGYYxLR0mSFUKF8auZdjqOq8NOuMfBvr9oZx3Quz22N3Se69lVGhWLT1Ams6hYodzj+XCo+ms2GtzwDO X-Received: by 10.52.8.225 with SMTP id u1mr882798vda.64.1395333608958; Thu, 20 Mar 2014 09:40:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 09:39:48 -0700 (PDT) In-Reply-To: <532AC890.7000602@ericsson.com> References: <531DE104.2010908@ericsson.com> <532AC890.7000602@ericsson.com> From: Justin Uberti Date: Thu, 20 Mar 2014 09:39:48 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf302d497a1b169504f50c6c87 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cY8AHk7lx9j1n3ksFTm4ONaOSFU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On ptimes and maxptimes 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, 20 Mar 2014 16:40:20 -0000 --20cf302d497a1b169504f50c6c87 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2014-03-20 01:27, Justin Uberti wrote: > > > > > > > > On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund > > > > > wrote: > > > > Hi, > > > > (As individual) > > > > On 2014-03-05 17:26, Justin Uberti wrote: > > > From the session this morning, I recall this consensus: > > > > > > * We will add recommendations on the frame sizes to use for > > PCMU/A to > > > the rtcweb audio codec I-D (20, 30, 60 ms frames). > > > > The above applies to sending payloads > > > > > > Right, thanks for pointing that out. > > > > > > Yes, but that was given that a receiver will be capable of receiving > any > > valid number of frames, or samples within a reasonable packetization, > > and I think that should be 120 ms. > > > > > * We will consider adding an a=maxptime attribute that > > represents the > > > "minimum maxptime" of all the offered codecs. That is, if both > > Opus > > > (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a > > > maxptime=60 SHOULD be included. > > > o Since maxptime spans all codecs, this means that some modes > > > (e.g. Opus 120ms) will be unavailable, unless only Opus is > > offered. > > > > I think you base the assumption on maxptime based on the sending > > recommendations, not what is capable of receiving. If one is capable > of > > receiving 200 ms of a-law and Opus, then you would need to say 120 > ms as > > Opus will limit you. > > > > > > I agree that Opus' maxptime is 120, but should that prevent sending PCMU > > with 200 ms? That is, since sending Opus with 200 ms is not legal, is > > there any point in forcing WebRTC impls to indicate this in SDP? > > What I wished we fixed this issue with maxptime a long time ago. This is > a well known problem that it really has PT scope, but are signalled on > m= line scope. > > > > > > > > > > * We will consider adding an a=ptime attribute, set to the > > receiver's > > > preferred frame size to receive. Again, this value spans all > > codecs, > > > so the specified value may not be viable for all codecs (e.g. > > 30 ms > > > works for PCMU but not for Opus) > > > > > > After thinking about this some, I'm not sure the maxptime/ptime > values > > > will lead to any different behavior than if they were not > specified. > > > Since there is a complexity cost (especially if the values need to > > > change based on which codecs are offered), is there a clear upside > > here? > > > > The maxptime values may in some cases be limited downwards for > > interoperability, for example if one like to gateway AMR into a CS > > network then the gateway might indicate a maxptime that is less, more > > like 20 or 40 ms. > > > > > > Sure - WebRTC impls need to respect any maxptime value that they > > receive, but it's not clear to me that they need to include one in the > > SDP they send. > > Ok, but then we are back to my previous argument for writing down what > receiver requirement in regards to each payload type one is required to > support in the audio draft for the ones specified there. But what about > the other codecs that aren't included in the audio draft? > > How can a peer know if there are limitations? I wouldn't attempt to > solve the general problem of the scope issue with maxptime. Simply state > that you should include this. It is going to be limited but still > provide information in many cases that is quite useful for the sender. > > Just to be sure I understand, your position is that WebRTC impls SHOULD include an a=maxptime attribute indicating the "minimum maximum" frame size they can receive, across all codecs? Do you think anything needs to be included regarding a=ptime? --20cf302d497a1b169504f50c6c87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
On 2014-03-20 01:27, Justin = Uberti wrote:
>
>
>
> On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund
> <magnus.wes= terlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
> wrote:
>
> =C2=A0 =C2=A0 Hi,
>
> =C2=A0 =C2=A0 (As individual)
>
> =C2=A0 =C2=A0 On 2014-03-05 17:26, Justin Uberti wrote:
> =C2=A0 =C2=A0 > From the session this morning, I recall this consen= sus:
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > =C2=A0 * We will add recommendations on the frame s= izes to use for
> =C2=A0 =C2=A0 PCMU/A to
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 the rtcweb audio codec I-D (20, 30, 6= 0 ms frames).
>
> =C2=A0 =C2=A0 The above applies to sending payloads
>
>
> Right, thanks for pointing that out.
>
>
> =C2=A0 =C2=A0 Yes, but that was given that a receiver will be capable = of receiving any
> =C2=A0 =C2=A0 valid number of frames, or samples within a reasonable p= acketization,
> =C2=A0 =C2=A0 and I think that should be 120 ms.
>
> =C2=A0 =C2=A0 > =C2=A0 * We will consider adding an a=3Dmaxptime at= tribute that
> =C2=A0 =C2=A0 represents the
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 "minimum maxptime" of all t= he offered codecs. That is, if both
> =C2=A0 =C2=A0 Opus
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 (maxptime of 120ms) and PCMU (maxptim= e of 60) are offered, a
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 maxptime=3D60 SHOULD be included.
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 o Since maxptime spans all cod= ecs, this means that some modes
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g. Opus 120ms) will = be unavailable, unless only Opus is
> =C2=A0 =C2=A0 offered.
>
> =C2=A0 =C2=A0 I think you base the assumption on maxptime based on the= sending
> =C2=A0 =C2=A0 recommendations, not what is capable of receiving. If on= e is capable of
> =C2=A0 =C2=A0 receiving 200 ms of a-law and Opus, then you would need = to say 120 ms as
> =C2=A0 =C2=A0 Opus will limit you.
>
>
> I agree that Opus' maxptime is 120, but should that prevent sendin= g PCMU
> with 200 ms? That is, since sending Opus with 200 ms is not legal, is<= br> > there any point in forcing WebRTC impls to indicate this in SDP?

What I wished we fixed this issue with maxptime a long time ago= . This is
a well known problem that it really has PT scope, but are signalled on
m=3D line scope.

>
>
>
> =C2=A0 =C2=A0 > =C2=A0 * We will consider adding an a=3Dptime attri= bute, set to the
> =C2=A0 =C2=A0 receiver's
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 preferred frame size to receive. Agai= n, this value spans all
> =C2=A0 =C2=A0 codecs,
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 so the specified value may not be via= ble for all codecs (e.g.
> =C2=A0 =C2=A0 30 ms
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0 works for PCMU but not for Opus)
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > After thinking about this some, I'm not sure th= e maxptime/ptime values
> =C2=A0 =C2=A0 > will lead to any different behavior than if they we= re not specified.
> =C2=A0 =C2=A0 > Since there is a complexity cost (especially if the= values need to
> =C2=A0 =C2=A0 > change based on which codecs are offered), is there= a clear upside
> =C2=A0 =C2=A0 here?
>
> =C2=A0 =C2=A0 The maxptime values may in some cases be limited downwar= ds for
> =C2=A0 =C2=A0 interoperability, for example if one like to gateway AMR= into a CS
> =C2=A0 =C2=A0 network then the gateway might indicate a maxptime that = is less, more
> =C2=A0 =C2=A0 like 20 or 40 ms.
>
>
> Sure - WebRTC impls need to respect any maxptime value that they
> receive, but it's not clear to me that they need to include one in= the
> SDP they send.

Ok, but then we are back to my previous argument for writing down wha= t
receiver requirement in regards to each payload type one is required to
support in the audio draft for the ones specified there. But what about
the other codecs that aren't included in the audio draft?

How can a peer know if there are limitations? I wouldn't attempt to
solve the general problem of the scope issue with maxptime. Simply state that you should include this. It is going to be limited but still
provide information in many cases that is quite useful for the sender.

<= br>
Just to be sure I understand, your position is that WebRTC im= pls SHOULD include an a=3Dmaxptime attribute indicating the "minimum m= aximum" frame size they can receive, across all codecs?

Do you think anything needs to be included regarding a= =3Dptime?
--20cf302d497a1b169504f50c6c87-- From nobody Thu Mar 20 09:58:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2441A0700 for ; Thu, 20 Mar 2014 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 lgUw3UHYLugv for ; Thu, 20 Mar 2014 09:58:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B31301A0709 for ; Thu, 20 Mar 2014 09:58:28 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 705D0403B0; Thu, 20 Mar 2014 12:58:19 -0400 (EDT) Message-ID: <532B1E2B.3000606@viagenie.ca> Date: Thu, 20 Mar 2014 12:58:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti References: <5329BA17.7080701@viagenie.ca> <532B0E8F.3000002@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GHud2fPEhzyMGTdgXu4J1q3R3ug Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 16:58:31 -0000 Le 2014-03-20 12:30, Justin Uberti a écrit : > On Mac, the temporary addresses seem to change every day, but any > existing addresses seem to remain valid for a week. Correct. Addresses go from "preferred and valid" (one day) to "valid" (one week) to "invalid". The address is removed from the interface when it becomes invalid. So in theory you would need to use WebRTC for a whole week before an temporary address is yanked from under your feet. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 20 10:08:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291801A0785 for ; Thu, 20 Mar 2014 10:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si3pszPaRt_A for ; Thu, 20 Mar 2014 10:08:08 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5515D1A03BF for ; Thu, 20 Mar 2014 10:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6182; q=dns/txt; s=iport; t=1395335279; x=1396544879; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=9UATpVjrvIl3cNfG5rOeMHDIke7DVvhdWaYKkGQJbEw=; b=kMZYuX844x1ac7iLXaTlfnPFHDPPAzJhKdoLjSBR2WJCFw/TcykfZNx6 1bVZ/4cH7l6xFyI1MSbDvXnVlrMki+YMRMFdkr2FJvZVsbwi8F0pAD232 lhjEle7xppnch7VUEG4WHponHsRVGM3yj00TY5pDENSuSjBqZaRDDh9/x 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAIgfK1OrRDoI/2dsb2JhbABZgkJEw2GBGRZ0giUBAQEEeRALDgouVwYTh3jPcReOZQeDJIEUBIlSiwmDbJIwg00dgSwk X-IronPort-AV: E=Sophos;i="4.97,695,1389744000"; d="scan'208,217";a="105328425" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 20 Mar 2014 17:07:59 +0000 Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2KH77Pv017753; Thu, 20 Mar 2014 17:07:58 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_1B3B2EBA-B610-4FDC-8B23-6B54AB78DAC9" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Thu, 20 Mar 2014 10:07:58 -0700 Message-Id: <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> To: Justin Uberti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5TWbslruwP6v-bQkFf_bQCCg20U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 17:08:10 -0000 --Apple-Mail=_1B3B2EBA-B610-4FDC-8B23-6B54AB78DAC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 20, 2014, at 9:34 AM, Justin Uberti wrote: >=20 >=20 >=20 > On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing wrote: >=20 > On Mar 19, 2014, at 8:21 AM, Harald Alvestrand = wrote: >=20 >> On 03/19/2014 04:08 PM, Dan Wing wrote: >>>=20 >>> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand = wrote: >>>=20 >>>> I'd like to be silent on the issue, since which IPv6 addresses to = prefer is likely to be a matter of system policy. Trying to override = system policy in an application specific profile usually leads to = sadness. >>>=20 >>> The application needs to indicate if it wants a temporary address. = If the host's policy (or configuration or network) does not support = temporary addresses, the application won't get a temporary address. I = don't see why being silent helps? >>=20 >> What API is it using? >>=20 >> With a little Googling, the system policy I was thinking of was the = policy in RFC 6724 ("Default Address Selection for IPv6"), in particular = section 5 rule 7: "Prefer temporary addresses". >>=20 >> I'm happy to say "it is a good idea for systems to implement the = recommendations of RFC 6724" (or some more 2119-like language). I = wouldn't want to claim that if a system has chosen to prefer = non-temporary addresses, it would have to change its non-conformance to = RFC 6724 in order to be conformant with RTCWEB specifications. >=20 > So perhaps: > "An RTCWEB implementation SHOULD prefer to use temporary addresses = [RFC4941] where host and network policy permit [RFC6724]." > ? >=20 > I think it needs to be stronger than that - something like=20 > "where host and network policy permit, RTCWEB implementations SHOULD = gather IPv6 temporary addresses and SHOULD NOT gather non-temporary = addresses". >=20 > Preferring to use temporary addresses is probably not sufficient to = prevent linkage, since you will have connectivity checks from the = non-temporary addresses. (i.e. an eavesdropper listening over an = extended period of time could determine calls are from the same = endpoint) Agreed. I like your suggested wording. -d --Apple-Mail=_1B3B2EBA-B610-4FDC-8B23-6B54AB78DAC9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Mar 20, 2014, at 9:34 AM, Justin Uberti <juberti@google.com> wrote:




On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing <dwing@cisco.com> wrote:

On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

On 03/19/2014 04:08 PM, Dan Wing wrote:

On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> wrote:

I'd like to be silent on the issue, since which IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness.

The application needs to indicate if it wants a temporary address. If the host's policy (or configuration or network) does not support temporary addresses, the application won't get a temporary address.  I don't see why being silent helps?

What API is it using?

With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer  temporary addresses".

I'm happy to say "it is a good idea for systems to implement the recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications.

So perhaps:
   "An RTCWEB implementation SHOULD prefer to use temporary addresses [RFC4941] where host and network policy permit [RFC6724]."
?

I think it needs to be stronger than that - something like 
"where host and network policy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses".

Preferring to use temporary addresses is probably not sufficient to prevent linkage, since you will have connectivity checks from the non-temporary addresses. (i.e. an eavesdropper listening over an extended period of time could determine calls are from the same endpoint)

Agreed.  I like your suggested wording.

-d

--Apple-Mail=_1B3B2EBA-B610-4FDC-8B23-6B54AB78DAC9-- From nobody Thu Mar 20 10:48:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046681A0700; Thu, 20 Mar 2014 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, 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 vYuqohEwKX9p; Thu, 20 Mar 2014 10:48:30 -0700 (PDT) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5A52A1A0790; Thu, 20 Mar 2014 10:48:30 -0700 (PDT) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2KHl5Di080514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 20 Mar 2014 12:47:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88] claimed to be unnumerable.local Message-ID: <532B299C.3070909@nostrum.com> Date: Thu, 20 Mar 2014 12:47:08 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org, mmusic@ietf.org, rtcweb@ietf.org, avt@ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FSsm7tk0xeOnDfIkWWmpwPIPhu8 Subject: [rtcweb] Registration for SIPit 31 is open X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rai@ietf.org 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, 20 Mar 2014 17:48:32 -0000 (Please forgive the crosspost, and reply only to the rai list): Please see From nobody Thu Mar 20 13:09:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B98C1A0754; Thu, 20 Mar 2014 13:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiNNNMtIVLwj; Thu, 20 Mar 2014 13:09:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E151A048C; Thu, 20 Mar 2014 13:09:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140320200912.14103.79701.idtracker@ietfa.amsl.com> Date: Thu, 20 Mar 2014 13:09:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/w5vzYEdFdERCC9CYQUT18w5REbM Cc: rtcweb@ietf.org Subject: [rtcweb] RTCWEB WG Interim Meeting, May 19-21, 2014 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 20 Mar 2014 20:09:14 -0000 The RTCWEB working group will hold an Interim meeting with The W3c WEBRTC and Media Capture groups May 19-21, 2014 in Washington DC. The location will be : 1101 New York Ave NW, Washington, DC 20005 Details on remote participation and registration will be sent to the RTCWEB list (https://www.ietf.org/mailman/listinfo/rtcweb) in the next few weeks. From nobody Thu Mar 20 13:25:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C36C1A074E for ; Thu, 20 Mar 2014 13:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVOuVzknF3Ba for ; Thu, 20 Mar 2014 13:25:15 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 734B91A073B for ; Thu, 20 Mar 2014 13:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13508; q=dns/txt; s=iport; t=1395347106; x=1396556706; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W1y8enXbnS7K7ftOHghSC+JpuvV58g+Yp2w90hts4p0=; b=RxEFW0SLHVyjOBxWzTrTWdelOQPbZrA79tlOoI0+Je81vZs8eZB6l1D/ 5uDOGRnnqa5x/RepxnL/g5SjgBV2SfMVEWozqgRNwGrz1Ui/vwbixkc3Y dw3o9gQM7bID5tfhcQcsgLKr2QZvlM/equZPZHg2b9j5DOR+wFuWt7P2v w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGAKlNK1OtJXG8/2dsb2JhbABZgkJEO1esIY0/gT2GYVGBGhZ0giUBAQEEAQEBKkELEAIBCA4DAwEBASgHIQYLFAkIAQEEAQ0Fh2UDEAENyEANhxkXjE2CBw0EBgEGhDIEiRqDV4lpgW2BMoYXhR+FSIMtgis X-IronPort-AV: E=Sophos; i="4.97,697,1389744000"; d="scan'208,217"; a="29092880" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 20 Mar 2014 20:25:06 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2KKP5Md024375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 20:25:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 15:25:06 -0500 From: "Charles Eckel (eckelcu)" To: Roni Even , "'Justin Uberti'" , "'Bernard Aboba'" Thread-Topic: [rtcweb] Should we reference the pause/resume I-D? Thread-Index: Ac8+HSfEqf9sT+k2TCiwilJvB9C34gAORCOAAAJLjQABfviNgAADm0eA Date: Thu, 20 Mar 2014 20:25:05 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1CF8B463@ESESSMB209.ericsson.se> <03c301cf4431$62655c90$273015b0$@gmail.com> In-Reply-To: <03c301cf4431$62655c90$273015b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.16] Content-Type: multipart/alternative; boundary="_000_CF509A2E233ACeckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/B0AEYIqYYCetpYeKGCCRQ7UVbtc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Should we reference the pause/resume I-D? 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, 20 Mar 2014 20:25:18 -0000 --_000_CF509A2E233ACeckelcuciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Caveats to be aware of with the tmmbr=3D0 approach include: * tmmbr=3D0 implies pause, but it is indistinguishable for tmmbr being = set to 0 for other reasons * knowledge of an appropriate value to set for resume is not always ava= ilable at the RTCP layer (implementation dependent) * theoretically not appropriate to jump directly back to tmmbr=3D even when known Despite these caveats, I agree with Roni that using tmmbr=3D0 for pause has= worked relatively well in enterprise SIP deployments. Cheers, Charles From: Roni Even > Date: Thursday, March 20, 2014 at 4:41 AM To: Justin Uberti >, 'Bernard= Aboba' > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] Should we reference the pause/resume I-D? Hi, The pause and resume has the tmmbr=3D0 option based on RFC5104 (No IPR in t= he data base for RFC 5104; http://datatracker.ietf.org/ipr/search/?option= =3Ddocument_search&id=3Ddraft-ietf-avt-avpf-ccm) . this works well for poi= nt to point case. Roni From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 March, 2014 10:56 PM To: Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Should we reference the pause/resume I-D? Agreed. Aren't there also patent declarations against this doc from multipl= e holders? While SDP will likely be removed from the API in the future, the replacemen= t would be a app-specific message sent over websockets, which seems like it= would work just fine. On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba > wrote: While I do like the pause/resume draft, having core RTCWEB WG documents (su= ch as RTP Usage) depend on it seems like a bit of a stretch. After all, the= document was only adopted last week, and it is a rare IETF WG document tha= t can go from a -00 WG draft to publication as an RFC in under a year. On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=E5kansson LK > wrote: Hi, at the IETF last week there was consensus in the AVTEXT WG meeting to adopt the pause/resume draft [1] as a WG draft. In rtcweb/webrtc we're have the situation that we're discussing so called "doo-hickeys" as an API surface where the web app (amongst other things) can pause and resume the sending of a track. This can be signaled with the direction attribute and a SDP O/A exchange (and the app pausing/resuming sending of a track would presumably lead to a "negotiationneeded" event being fired). But I think we should in addition require the browser to signal it according to one of the methods in [1] (e.g. TMMBN =3D 0), and also understand that signaling (a browser receiving TMMBN =3D 0 must know that the other end-point will pause sending). My argument is that we know that many dislike SDP in rtcweb, and a likely development is that it will be removed in a later version. My speculation is that signaling as outlined in [1] will then be used for pause/resume. If we support this from the beginning earlier implementations could more easily interop with those later versions. Stefan [1] https://tools.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-05.txt _______________________________________________ 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 --_000_CF509A2E233ACeckelcuciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Caveats to be aware of with the tmmbr=3D0 approach include:
  • tmmbr=3D0 implies pause, but it is indistinguishable for tmmbr being se= t to 0 for other reasons
  • knowledge of an appropriate value to set f= or resume is not always available at the RTCP layer (implementation depende= nt)
  • theoretically not appropriate to jump directly back to tmmbr=3D= <value prior to pause> even when known
Despite these caveats, I agree with Roni that using tmmbr=3D0 for paus= e has worked relatively well in enterprise SIP deployments.

Cheers,
Charles


From: Roni Even <ron.even.tlv@gmail.com>
Date: Thursday, March 20, 2014 at 4= :41 AM
To: Justin Uberti <juberti@google.com>, 'Bernard Aboba' <bernard.aboba@gmail.com> Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: Re: [rtcweb] Should we ref= erence the pause/resume I-D?

Hi,

The pause and resume has the tmmbr= =3D0 option based on RFC5104 (No IPR in the data base for RFC 5104; http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Dd= raft-ietf-avt-avpf-ccm)  . this works well for point to point case= .

Roni

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 12 March, 2014 10:56 PM
To: Bernard Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Should we reference the pause/resume I-D?=

 

Agreed. Aren't there also patent declarations agains= t this doc from multiple holders?

 

While SDP will likely be removed from the API in the= future, the replacement would be a app-specific message sent over websocke= ts, which seems like it would work just fine.

 

On Wed, Mar 12, 2014 at 12:50 PM, Bernard Aboba <= bernard.aboba@= gmail.com> wrote:

While I do like the pause/resume draft, having core = RTCWEB WG documents (such as RTP Usage) depend on it seems like a bit of a = stretch. After all, the document was only adopted last week, and it is a ra= re IETF WG document that can go from a -00 WG draft to publication as an RFC in under a year.

 

On Wed, Mar 12, 2014 at 11:01 AM, Stefan H=E5kansson= LK <stefan.lk.hakansson@ericsson.com> wrote:

Hi,

at the IETF last week there was consensus in the AVTEXT WG meeting to
adopt the pause/resume draft [1] as a WG draft.

In rtcweb/webrtc we're have the situation that we're discussing so
called "doo-hickeys" as an API surface where the web app (amongst= other
things) can pause and resume the sending of a track. This can
be signaled with the direction attribute and a SDP O/A exchange (and the app pausing/resuming sending of a track would presumably lead to a
"negotiationneeded" event being fired).

But I think we should in addition require the browser to signal it
according to one of the methods in [1] (e.g. TMMBN =3D 0), and also
understand that signaling (a browser receiving TMMBN =3D 0 must know that the other end-point will pause sending).

My argument is that we know that many dislike SDP in rtcweb, and a
likely development is that it will be removed in a later version. My
speculation is that signaling as outlined in [1] will then be used for
pause/resume. If we support this from the beginning earlier
implementations could more easily interop with those later versions.


Stefan

[1]
https://tools.ietf.org/id/draft-westerlund-avt= ext-rtp-stream-pause-05.txt

_______________________________________________
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

 

 --_000_CF509A2E233ACeckelcuciscocom_-- From nobody Thu Mar 20 13:56:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160681A07EF for ; Thu, 20 Mar 2014 13:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub_MF3r_1Mc1 for ; Thu, 20 Mar 2014 13:56:14 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2106D1A08BD for ; Thu, 20 Mar 2014 13:56:14 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id h18so18398835igc.0 for ; Thu, 20 Mar 2014 13:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TApEPG7ez5Z7tXUuw3gCqdAnU8ZlNdJCXzZ+ChaFdEg=; b=GqAaI82BkimqcNuHmjX10jA0kkd2xD505IpTFoBn7bWnl1m+/gVgw/AalQQtucQTh5 tQ/kxrBe5MJGVtfSSlpFul0l93AL7wi4DNAjF+oS2uzv7C9aV4m+Yt5XyMshIQeJPmSP er55x/Y02XwH6IQdWWbOWAlMbtt11gITPgg1DS3k6t8Ya5pljgTzsJ8/LtUWRmS6ZIL3 VGOvhxdW1vNPZgIoU9SgjklrPUeUf0yrpKGLd6+w429rdHk7HasH5EKma99dp10N6ZLT P5mIi+aS5Wk+Tc27sPPJFAU5fGifzExbICvOOHUChtcclFlP/8ij0x2xr1DPjFsuNApO i5DA== MIME-Version: 1.0 X-Received: by 10.50.83.38 with SMTP id n6mr33146144igy.30.1395348964983; Thu, 20 Mar 2014 13:56:04 -0700 (PDT) Received: by 10.42.237.206 with HTTP; Thu, 20 Mar 2014 13:56:04 -0700 (PDT) In-Reply-To: <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> Date: Thu, 20 Mar 2014 13:56:04 -0700 Message-ID: From: Ted Hardie To: Dan Wing Content-Type: multipart/alternative; boundary=089e010d97f8654c8304f50fff5c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PxMu9TutHZsziv2TRvG8QrBhxCA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 20:56:16 -0000 --089e010d97f8654c8304f50fff5c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 10:07 AM, Dan Wing wrote: > > On Mar 20, 2014, at 9:34 AM, Justin Uberti wrote: > > > > > > So perhaps: >> "An RTCWEB implementation SHOULD prefer to use temporary addresses >> [RFC4941] where host and network policy permit [RFC6724]." >> ? >> > > I think it needs to be stronger than that - something like > "where > > host and network policy permit, RTCWEB implementations SHOULD gather IPv6 > temporary addresses and SHOULD NOT gather non-temporary addresses". > > Preferring to use temporary addresses is probably not sufficient to > prevent linkage, since you will have connectivity checks from the > non-temporary addresses. (i.e. an eavesdropper listening over an extended > period of time could determine calls are from the same endpoint) > > > Agreed. I like your suggested wording. > > -d > > > So, I note that in this case where a non-temporary IPv6 address is present and no temporary IPv6 address is present, this appears to push IPv6 out of the gathered list completely. If I have that right, then my view as an individual is that this is the wrong result. It will either force the use of IPv4 addresses which are just as linkable as IPv6 non-temporary addresses or rely on NATs to get the non-linkability (and provide us all the other subtle joys of NAT). As a friendly amendment, may I suggest "Where both non-temporary and temporary addresses are present and host and network policy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses"? I also confess to a suspicion that Harald's view is the most sensible--having a separate policy for this application either won't happen or doesn't make much sense. But if we have one, I'd prefer one that doesn't shove IPv6 out the door completely if the host doesn't use temporary addresses. regards, Ted --089e010d97f8654c8304f50fff5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 20, 2014 at 10:07 A= M, Dan Wing <dwing@cisco.com> wrote:

On= Mar 20, 2014, at 9:34 AM, Justin Uberti <juberti@google.com> wrote:





So perhaps:
=A0 =A0"An RTCWEB implementation SHOUL= D prefer to use temporary addresses [RFC4941] where host and network policy= permit [RFC6724]."
?

I think it needs to be stronge= r than that - something like=A0
"where
host and n= etwork policy permit, RTCWEB implementations SHOULD gather IPv6 temporary a= ddresses and SHOULD NOT gather non-temporary addresses".

Preferring to use temporary addresses is probably not s= ufficient to prevent linkage, since you will have connectivity checks from = the non-temporary addresses. (i.e. an eavesdropper listening over an extend= ed period of time could determine calls are from the same endpoint)

Agreed. =A0I like your suggested wo= rding.

-d=



So, I note that in this case where a non-temporary IPv6 address is present = and=A0 no temporary IPv6 address is present, this appears to push IPv6 out = of the gathered list completely.=A0 If I have that right, then my view as a= n individual is that this is the wrong result.=A0 It will either force the = use of IPv4 addresses which are just as linkable as IPv6 non-temporary addr= esses or rely on NATs to get the non-linkability (and provide us all the ot= her subtle joys of NAT).

As a friendly amendment, may I suggest "Where both non-= temporary and temporary addresses are present and host and network policy permit, RTCWEB implementations SHOULD gather IPv6=20 temporary addresses and SHOULD NOT gather non-temporary addresses"?
I also confess to a suspicion that Harald's view is the= most sensible--having a separate policy for this application either won= 9;t happen or doesn't make much sense.=A0 But if we have one, I'd p= refer one that doesn't shove IPv6 out the door completely if the host d= oesn't use temporary addresses.

regards,

Ted
--089e010d97f8654c8304f50fff5c-- From nobody Thu Mar 20 14:51:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68221A08EB for ; Thu, 20 Mar 2014 14:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=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 O5rV9N_KRMet for ; Thu, 20 Mar 2014 14:51:30 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6A1A0796 for ; Thu, 20 Mar 2014 14:51:30 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so1618540ieb.40 for ; Thu, 20 Mar 2014 14:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KdjznD78d/TOr/f6eskYohZWAFwoZcQx4aBN2MYffog=; b=T5kMUnqJRAuIazN0FcqJD4zQERjXMIqbHzYg3F+ewuudFjJt2+4e+89kC/ul5FDofa FT+Yl/DdK+D6ZlhyYyYlwdFNrhVToY2gYn4AhErjmWqgNTsqDbntEZxlXYBHFuT2x0K5 aHvK4pQ9h63WscjXUKJJYpUG4jgEsYJ1KSa1UmWwUzJ2LJxLO8HjAbK6oaskHQuTxmVt rDqKmP7cGDSAWDTqo94kyuwnSECOGzZzhQ24fpVnbMYMb/o0zt1jsFB6ZETELDTJGKHV bRse4BL0dmODSzvBHuqn3e1rO9v/+fVB40DAoe4/lFSbb2N9DQb7Me6+kn6RhNeqXS0M Crbw== MIME-Version: 1.0 X-Received: by 10.50.57.17 with SMTP id e17mr5600805igq.13.1395352281412; Thu, 20 Mar 2014 14:51:21 -0700 (PDT) Received: by 10.42.237.206 with HTTP; Thu, 20 Mar 2014 14:51:21 -0700 (PDT) Date: Thu, 20 Mar 2014 14:51:21 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/mixed; boundary=e89a8f2354fd12137704f510c5e1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FYEbHob2knhMlymiNdF1DK8ssZI Subject: [rtcweb] DRAFT Minutes for Day 2 IETF 89 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, 20 Mar 2014 21:51:33 -0000 --e89a8f2354fd12137704f510c5e1 Content-Type: multipart/alternative; boundary=e89a8f2354fd12137104f510c5df --e89a8f2354fd12137104f510c5df Content-Type: text/plain; charset=ISO-8859-1 Attached are the draft minutes for the second day of the last meeting; thanks to Dan and Matt for taking the notes. Please send comments to the list; we'll then aggregate the edits for day one and day two in order to produce consolidated minutes. Ted --e89a8f2354fd12137104f510c5df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Attached are the draft minutes for the second day of the last meetin= g; thanks to Dan and Matt for taking the notes.=A0 Please send comments to = the list; we'll then aggregate the edits for day one and day two in ord= er to produce consolidated minutes.

= Ted
--e89a8f2354fd12137104f510c5df-- --e89a8f2354fd12137704f510c5e1 Content-Type: text/plain; charset=US-ASCII; name="IETF89-RTCWEB-Minutes2.txt" Content-Disposition: attachment; filename="IETF89-RTCWEB-Minutes2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ht0kpsh80 UlRDV0VCIE1pbnV0ZXMgTWFyY2ggNSwgMjAxNAoKQ2hhaXJzOiBNYWdudXMgV2VzdGVybHVuZCwg Q3VsbGVuIEplbm5pbmdzLCBUZWQgSGFyZGllCk5vdGUgdGFrZXJzOiBEYW4gQnVybmV0dCwgTWF0 dCBNaWxsZXIKCkpTRVAgLSBKdXN0aW4gVWJlcnRpCi0tLS0tLS0KCklzc3VlIDE6ICBNU0lEIGFu ZCBkaXJlY3Rpb24gaW50ZXJhY3Rpb25zCgooSnVzdGluJ3Mgc2xpZGVzIHNheTopClR3byBjYXNl czoKMS4gWCBvZmZlcnMgdmlkZW8sIFkgd2FudHMgdG8gcmVqZWN0IGJ1dCBhZGQgaXRzIG93bgoy LiB2aWRlbyBmbG93aW5nIGluIGJvdGggZGlyZWN0aW9ucywgWCB3YW50cyB0byBzdG9wIHJlbW90 ZSB2aWRlbwoKS2V5IGlzIHBlcm1hbmVuY2Ugb2YgaW5hY3Rpdml0eSAtLSB0aGlzIGlzIG5vdCBh IHBhdXNlLCBidXQgYSB0ZXJtaW5hdGlvbiB0aGF0IGFsbG93cyBmb3IgdGhlIG1lZGlhIHN0cmVh bSByZXNvdXJjZXMgKHRyYW5zcG9ydHMgYW5kIGNhbmRpZGF0ZSBzZXRzKSB0byBiZSByZWNvdmVy ZWQvY29sbGVjdGVkIGFuZCBtLWxpbmVzIHRvIGJlIHJldXNlZC4KU3VnZ2VzdGlvbiBpcyB0byBh ZGQgbmV3ICJhPW1zaWQtY29udHJvbDogc3RvcCIuICBJbiBmaXJzdCBjYXNlIHdvdWxkIGJlIFkg dGhhdCBpbmNsdWRlcywgaW4gc2Vjb25kIGNhc2Ugd291bGQgYmUgWC4KClF1ZXN0aW9ucyBhcm9z ZSBhcm91bmQgbmFtZSBvZiB0aGlzIGF0dHJpYnV0ZSAobXNpZC1jb250cm9sIGRvZXMgbm90IHJl ZmVyIHRvIGxvY2FsIG1zaWQpLCBlZmZlY3RzIG9uIFJUQ1AgKG5vbmUpLCBzZW1hbnRpYyBkaWZm ZXJlbmNlIGJldHdlZW4gcmVzdGFydGluZyBhbmQgbmV3bHkgY3JlYXRpbmcgYSBtZWRpYSBzdHJl YW0sIGNvbmNlcm5zIHdpdGggbGVnYWN5IGJlaGF2aW9yLCBxdWVzdGlvbiBhYm91dCB3aGV0aGVy IHRoaXMgaXMgcmVhbGx5IGEgVzNDIEFQSSBpc3N1ZQoKSnVzdGluIG5vdGVzIHRoYXQgYWN0dWFs IHByb3Bvc2FsIGZvciBtc2lkLWNvbnRyb2wgYXR0cmlidXRlIHdpbGwgY29tZSBpbiBNTVVTSUMg YnV0IGlzIGJlaW5nIGRpc2N1c3NlZCBoZXJlIGZvciBjb21wbGV0ZW5lc3MuCgpDb25zZW5zdXMg Y2FsbDoKKiBIb3cgbWFueSBwZW9wbGUgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbT8gIChmZXcgaGFu ZHMpCiogSG93IG1hbnkgdG8gaGF2ZSBNTVVTSUMgc29sdmUgdGhpcyBpc3N1ZSAoc29tZSBodW1z KQoqIEhvdyBtYW55IHRvIG5vdCBoYXZlIE1NVVNJQyBzb2x2ZSB0aGlzIGlzc3VlIChub25lKQoK SXNzdWUgMjogIHB0aW1lCgpDdWxsZW4gSmVubmluZ3MgKENKKTogV2Ugc2hvdWxkIHB1dCBpbiBh IG1heCBwdGltZSBvZiB3aGF0ZXZlciB5b3UgYXJlIGdvaW5nIHRvIHNlbmQuICBJdCB3aWxsIGhl bHAgd2l0aCBpbnRlcm9wZXJhYmlsaXR5LiAgSSBkb24ndCBjYXJlIGlmIGl0J3MgNjAgb3IgMzAw MCwgYnV0IHlvdSBzaG91bGQgcHV0IGluIHRoZSBtYXggcHRpbWUgZm9yIHdoYXRldmVyIHlvdXIg YnJvd3NlciBzdXBwb3J0cy4gIE5vbmUgb2YgdGhpcyBhcHBsaWVzIHRvIE9wdXMuCk1hcnRpbiBU aG9tc29uIChNVCk6IEkgYWdyZWUKSnVzdGluIFViZXJ0aSAoSlUpOiBUaGlzIGlzIHdoYXQgdmFs dWVzIHNob3VsZCBiZSB1c2VkIHdoZW4gc2VuZGluZyBhdWRpby4gIFdoYXQgeW91IHNlbmQgc2hv dWxkIG9ubHkgYmUgb25lIG9mIHRoZXNlIDIwLCAzMCxvciA2MC4KU3BlYWtlcjogV2hlbiB3ZSBo YXZlIGEgZ2F0ZXdheSwgSSBkb24ndCB3YW50IHRoZSByZXF1aXJlbWVudCB0byBzcmlwIG91dCB2 YWx1ZXMuICBJZiB0aGUgcGF5bG9hZCB3YW50cyB0byBzcGVjaWZ5IHNvbWV0aGluZywgbGV0IHRo ZW0uCkNKOiBJIHdhbnQgdG8gcmVjZWl2ZSBhbnl0aGluZywgYW5kIEZGIGFuZCBDaHJvbWUgd2ls bC4gMCBpcyBhbiBpbnZhbGlkIHZhbHVlLgpKTDogVGhlIDIwLzMwLzYwIHNob3VsZCBiZSBpbiB0 aGUgY29kZWNzIGRyYWZ0LCBub3QgaGVyZS4KSlU6IFNvIHdoYXQgSSd2ZSBoZWFyZCBpcyB0byBz ZW5kIHRoZSBicm93c2VyJ3MgdmFsdWUgZm9yIG1heCBwdGltZSwgYW5kIGZvciBwdGltZSBzZW5k IG9uZSBvZiB0aGUgMjAvMzAvNjAgZnJhbWUgc2l6ZXMuCkNKOiBUaGUgbWF4IGlzIHRoZSBjcml0 aWNhbCB0aGluZyB0aGVyZS4gIEkgdGhpbmsgd2Ugc2hvdWxkIGJlIGFibGUgdG8gcmVjZWl2ZSBh bnl0aGluZywgYnV0IHdoYXQgdGhlIGJyb3dzZXIgY2hvb3NlcyB0byBzZW5kIGlzIG9uZSBvZiB0 aGUgdGhyZWUgdmFsdWVzLgpKTDogSXQncyBub3Qga25vd24gd2hhdCBoYXBwZW5zIHdpdGggcHRp bWUgYWNyb3NzIEJVTkRMRXMgKGJ1dCB0aGF0IGlzIG5vdCBmb3IgdGhpcyBncm91cCkuCk1UOiBZ b3UgcHJvYmFibHkgd2FudCB0byBzYXkgd2hhdCBwdGltZSBjYW4gYmUgd2hlbiBpdCdzIE9wdXMu ICBJdCdzIG1vc3RseSBhIGNhc2UgZm9yIFBDTVUsIGFuZCB3aGF0J3MgdGhlIG1heCBpbiBPcHVz ICgxMjApLiAgVGhpcyBtZWFucyB0aGUgbS1saW5lIHdpbGwgaW5kaWNhdGUgMTIwLiAgSXQncyB0 aGUgbWF4aW11bS1tYXhpbXVtLgpDSjogSXQncyBnb2luZyB0byBtaW5pbXVtLW1heGltdW0gb2Yg YWxsIHRoZSBjb2RlY3MuICBUaGVyZSBhcmUgaGFyZHdhcmUtYmFzZWQgY29kZWNzIHRoYXQgb25s eSBzdXBwb3J0IDIwIG9yIDMwLgpTcGVha2VyOiBJcyB0aGlzIG9ubHkgZm9yIHRoZSBNVEkgY29k ZWNzLCB3aHkgaGF2ZW4ndCB3ZSBhbmFseXplZCBhbGwgb2YgdGhlIGNvZGVjcz8KQ2hhaXJzOiBJ IHRoaW5rIHdlIHNob3VsZCBzdGFydCB3aXRoIHRoZSBsYXRlc3QgYW5kIHRyeSB0byBpbmNsdWRl IGl0LgpXM0M6IEkgdGhpbmsgdGhlIGNvZGVjIHF1ZXN0aW9uIGlzIGEgbGFyZ2VyIG9uZS4gIFRo ZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBhcm91bmQgSFRNTDUuLmRvIHlvdSBpbnRlbmQgdG8gbGlh c2Ugb3ZlciB0aGlzPyAgSXQgd291bGQgYmUgZ29vZCB0byBiZSBhbGlnbmVkLgpDaGFpcnM6IFRo YXQgY29tbWVudCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRpc2N1c3Npb24uClNwZWFr ZXI6IEkgdGhpbmsgd2Ugc2hvdWxkIGRlYWwgd2l0aCB0aGVzZSB0aGluZ3MgaW4gcGF5bG9hZC4K Q0o6IExldCdzIHNheSB0aGUgcGF5bG9hZCBzYWlkIHRoYXQgdGhlIHB0aW1lIGlzIDIwLiAgVGhp cyBpcyBhYm91dCBwdXR0aW5nIHRoYXQgaW4gdGhlIFNEUC4gIG1heHB0aW1lIGlzIHdlbGwgZGVm aW5lZCwgc28gd2UnZCBiZSB2aW9sYXRpbmcgdmFyaW91cyBTRFAuClRpbSBQOiBXb3VsZCB0aGVz ZSB2YWx1ZXMgYmUgbWFsZWFibGUgYmV0d2VlbiBjcmVhdGUgYW5kIHNldD8gCkpVOiBJdCB3b3Vs ZCBkZXBlbmQgb24gd2hhdCB0aGUgYnJvd3NlciBzdXBwb3J0cy4KVFA6IFdoZW4gd2UgYXJlIGFk ZGluZyB0aGluZ3MsIHdlIHNob3VsZCB0aGluayBhYm91dCBob3cgdGhpcyBnbyB1cCBpbiB0aGUg YXBwLgpSb25ueTogSWYgdGhlIG9mZmVyIGluY2x1ZGVkIGJvdGggT1BVUyBhbmQgUENNVSwgdGhl biBpdCB0b29rIGF3YXkgUENNVSwgeW91IGNvdWxkIGp1c3QgY2hlY2sgdGhlIG1heCBwdGltZS4K CkNvbnNlbnN1cyBjYWxsOgoqIERvIHlvdSBzdXBwb3J0IGluY2x1ZGluZyBhIG1heHB0aW1lPyAo bW9kZXJhdGUgaHVtcykKKiBEbyB5b3Ugbm90IHN1cHBvcnQgaW5jbHVkaW5nPyAodmVyeSBmZXcg aHVtcykKCkNoYWlyczogSSB0aGluayBzb21lb25lIG5lZWRzIHRvIHdyaXRlIHRoZSBjb2RlYyBk cmFmdCBwcm9wb3NhbCwgYW5kIHRoZSBwdGltZS9tYXhwdGltZSBwcm9wb3NhbCBhbmQgdGFrZSBp dCB0byB0aGUgbGlzdC4KCklzc3VlIDM6ICBDTkFNRXMKClByb3Bvc2FsIGFyb3VuZCBzeW5jaHJv bml6YXRpb24gaXMgdG8gdXNlIHRoZSBzYW1lIENOQU1FIGZvciBhbGwgTWVkaWFTdHJlYW1UcmFj a3MgKE1TVHMpLCBldmVuIHRob3VnaCBiZWhhdmlvciBvZiBub24tV2ViUlRDIGVuZHBvaW50cyB3 aWxsIGJlIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudC4KClNvbWUgcmVtZW1iZXIgYSBkaWZmZXJl bnQgZGVjaXNpb24gZnJvbSBJRVRGLTg4LCB0aGF0IHdlIGFncmVlZCB0byB1c2UgbGlwIHN5bmMg Z3JvdXBzLgoKSnVzdGluIHdpbGwgY29uZm9ybSB3aXRoIFJUUCB1c2FnZSBndWlkZWxpbmVzIGFu ZCB3aWxsIGxvb2sgaW50byBsaXAgc3luYyBncm91cHMuCgpNYXJ0aW4gZXhwcmVzc2VzIGNvbmNl cm4gYWJvdXQgdXNpbmcgdGhlIHNhbWUgQ05BTUUgaW4gZGlmZmVyZW50IFBlZXIgQ29ubmVjdGlv bnMuICBKdXN0aW4gYWdyZWVzIHRoZSBxdWVzdGlvbiBhYm91dCBsaW5rYWJpbGl0eSBhY3Jvc3Mg UGVlciBDb25uZWN0aW9ucyBpcyBhIGdvb2Qgb25lIHRvIGNvbnNpZGVyIGhlcmUsIGFuZCBoZSB3 aWxsIHRha2UgaXQgdG8gdGhlIGxpc3QuCgpPdXRjb21lOiBNb3JlIGxpc3QgZGlzY3Vzc2lvbiBu ZWVkZWQuCgpJc3N1ZSA0OiAgU2FtZS1Qb3J0IEJ1bmRsZSBQb2xpY3kKClByb3Bvc2FsIGlzIHRv IGFkZCBuZXcgYnVuZGxlIHBvbGljeSB2YWx1ZSAoc3VjaCBhcyAiZm9yY2UtYnVuZGxlIikgdG8g YWxsb3cgaW5pdGlhbCBvZmZlciB0byB1c2UgdGhlIHNhbWUgKG5vbi16ZXJvKSBwb3J0cyB3aGVu IHN1cHBvcnQgZm9yIEJVTkRMRSBpcyBrbm93biBhIHByaW9yaSwgYWxsb3dpbmcgdGhlIHNlbmRl ciB0byBza2lwIGhhdmluZyB0byBzZW5kIGEgcmV2aXNlZCBvZmZlciB0byBjbGVhbiB1cCB0aGUg cG9ydHMgYWZ0ZXIgQlVORExFIGlzIGFjY2VwdGVkLgoKUXVlc3Rpb25zIGFyb3NlIGNvbmNlcm5p bmcgd2hhdCBoYXBwZW5zIGlmIHRoZSBhIHByaW9yaSBrbm93bGVkZ2UgaXMgd3JvbmcsIHdoZXRo ZXIgdGhpcyBpcyBhbiBJRVRGIGlzc3VlIGF0IGFsbCAoYXMgb3Bwb3NlZCB0byBhIFczQyBpc3N1 ZSksCgpKdXN0aW4gc3BsaXRzIHRoaXMgaW50byB0d28gcXVlc3Rpb25zOiAgc2hvdWxkIHdlIGFs bG93IHJ0Y3BtdXgtb25seSwgYW5kIGlzIGl0IGhlbHBmdWwgdG8gaGF2ZSBBUEkgc3VwcG9ydCB0 byBza2lwIGZpeHVwIG9mZmVyCk9uIGZpcnN0IHF1ZXN0aW9uIEp1c3RpbiB3aWxsIG1ha2UgYSBw cm9wb3NhbCBvbiB0aGUgbGlzdC4KRm9yIHRoZSBzZWNvbmQsIGNoYWlyIGh1bSBpbiBmYXZvcjog IG9ubHkgb25lLiAgQWdhaW5zdCwgYSBmZXcgbW9yZS4gIFZlcnkgbGl0dGxlIHN1cHBvcnQgZm9y IHRoaXMuCgoKRUtSIGJyb3VnaHQgdXAgYSBxdWVzdGlvbiBhYm91dCBjYW5kaWRhdGUgcG9vbGlu ZyBhbmQgdHJpY2tsZSBJQ0UuICBRdWVzdGlvbiBpcyB3aGV0aGVyIHlvdSBjYW4gZm9yY2Ugbm8g dHJpY2tsZSBJQ0UuIApKdXN0aW4gYW5zd2VycyB0aGF0IGNhbmRpZGF0ZXMgd2lsbCBhcnJpdmUg YXN5bmNocm9ub3VzbHkgYW55d2F5LgoKRXJpYyB3aWxsIGxvb2sgYXQgaW1wbGljYXRpb25zIGZv ciBGaXJlZm94IGFuZCBtYXliZSBzdWJtaXQgYSBwcm9wb3NhbC4gIEhvdyBpdCB3b3JrcyB0b2Rh eSBKdXN0aW4gd2lsbCBzZW5kIHRvIHRoZSBsaXN0LgoKQ29uc2Vuc3VzIGNhbGw6CiogQW55b25l IHNlZSB0aGUgbmVlZCBmb3IgdGhlIGZpeHVwIG9mZmVyIG9wdGltaXphdGlvbj8gKGZldyBodW1z KQoqIE5vIG5lZWQ/IChtb3JlIGh1bXMpCgoKUk1DQVQgdXBkYXRlCi0tLS0tLS0KQmVybmFyZCwg SnVzdGluLCBIYXJhbGQgYWdyZWVkIHRvIHJldmlldyBSTUNBVCBDQyByZXF1aXJlbWVudHMuCgpT ZWN1cml0eSAvIFNlY3VyaXR5IEFyY2hpdGVjdHVyZQotLS0tLS0tCkVyaWMgcHJvcG9zZXMgcHJl ZmVycmluZyAoaS5lLiwgU0hPVUxEKSBQRlMgY2lwaGVyIHN1aXRlcyBvdmVyIG5vbi1QRlMgY2lw aGVyIHN1aXRlcy4gIEFza3Mgd2hldGhlciB0aGlzIHNob3VsZCBiZSBNVVNULgoKQmVsaWVmIGlz IHRoYXQgTVRJIGNpcGhlcnMgZm9yIFdlYlJUQyB3aWxsIGluY2x1ZGUgUEZTIG9wdGlvbnMsIHNv IHRoZXkgd2lsbCBvZmZlci4KCkNvbnNlbnN1cyBjYWxsOgoqIEZvciBXZWJSVEMgaW1wbGVtZW50 YXRpb25zLCB0aGV5IE1VU1Qgb2ZmZXIvc2VsZWN0IFBGUyBvdmVyIG5vbi1QRlM/IChsYXJnZSBo dW1zKQoqIG9wcG9zZWQgKG5vbmUpCgoKCklkZW50aXR5IGNoYW5nZXMgc2xpZGVzIChNYXJ0aW4p Ci0tLQpObyBjb21tZW50cyBvbiBJc3N1ZSAxLgoKSXNzdWUgMjogIEVLUiBzYXlzIHRoaXMgbmVl ZHMgZ3VpZGFuY2UgdG8gYXBwcyBvbiB3aGF0IHRvIGRvIHdpdGggaXQuICBFaXRoZXIgcmVuZGVy ZWQgaW4gYSBzZXBhcmF0ZSB3aW5kb3cgb3IgYmUgdHJlYXRlZCBhcyBhIGNsaWNrIGZyb20gdGhl IHBlcnNwZWN0aXZlIG9mIGEgcG9wdXAgYmxvY2tlci4KCklzc3VlIDM6ICBFS1Igc2F5cyB0aGlz IGNhbiBvY2N1ciBpbiBicm93c2Vycy4gIE1hcnRpbiBwcm9wb3NlcyB3ZSBkbyBvcHRpb24gMywg aW5jbHVkaW5nIG11bHRpcGxlIGZpbmdlcnByaW50cy4gIEhlIGFsc28gcHJvcG9zZXMgdG8gbWFr ZSBhPWlkZW50aXR5IGEgc2Vzc2lvbi1sZXZlbCBhdHRyaWJ1dGUgYW5kIGhhdmUgaXQgY292ZXIg YWxsIHRoZSBmaW5nZXJwcmludHMgaW4gdXNlLgpDaGFpcnMgYXNrIGlmIGFueW9uZSB3YW50cyB0 byBzcGVhayBhZ2FpbnN0IG9wdGlvbiAzLiAgTm8gb25lIGRvZXMuCgpJc3N1ZSA0OiAgTm8gb25l IHN0b29kIHVwIHRvIG9iamVjdCB0byBoaXMgcHJvcG9zYWwsIGJ1dCBpdCB3ZW50IGJ5IHJlYWxs eSBmYXN0LgoKSXNzdWUgNTogIFByb3Bvc2VzIGJlaW5nIGFibGUgdG8gdmFsaWRhdGUgdmlhIEhU VFAgUE9TVCBvbiBzZXJ2ZXJzIHJhdGhlciB0aGFuIHJlcXVpcmluZyBicm93c2VyIHZhbGlkYXRp b24uICBUaGVyZSB3ZXJlIHF1ZXN0aW9ucywgc28gTWFydGluIHdpbGwgc2VuZCB0aGlzIHB1bGwg cmVxdWVzdCB0byB0aGUgbGlzdCBmb3IgcmV2aWV3IHRoZXJlLgoKSXNzdWUgNjogIFF1ZXN0aW9u IGlzIGFib3V0IGhvdyB0byBwcmVzZXJ2ZSBpZGVudGl0eS1iYXNlZCBzdHJlYW0gaXNvbGF0aW9u IGJleW9uZCB0aGUgbG9jYWwgYnJvd3NlciBhbmQgdGhlIHBlZXIgY29ubmVjdGlvbiBhbmQgaW50 byB0aGUgcmVjZWl2aW5nIGJyb3dzZXIgc28gdGhhdCBpdCByZW1haW5zIGlzb2xhdGVkIHRoZXJl LiAgVGhpcyBpcyBhYm91dCBwcm90ZWN0aW5nIGFnYWluc3QgdGhlIGphdmFzY3JpcHQgcnVubmlu ZyBvbiBib3RoIGVuZHMuCkEgcmVhc29uYWJsZSBudW1iZXIgb2YgcXVlc3Rpb25zIGNhbWUgdXAg aW4gZGlzY3Vzc2lvbi4gCgpXZSBhbGwgYWdyZWUgdGhpcyBuZWVkcyBtb3JlIGRpc2N1c3Npb24u CgpDSEFJUlM6IENvbnNlbnN1cyBzZWVtcyB0byBiZSBvcHRpb24gIzMgKGFzc2VydGlvbiBpbmNs dWRlcyBtdWx0aXBsZSBmaW5nZXJwcmludHMpCgoKUlRQIHVzYWdlCi0tLS0tLS0KT3BlbiBpc3N1 ZSBhYm91dCBlbmNyeXB0aW5nIGFsbCBSVFAgaGVhZGVyIGV4dGVuc2lvbnMgcmF0aGVyIHRoYW4g anVzdCBjbGllbnQtdG8tbWl4ZXIgYW5kIG1peGVyLXRvLWNsaWVudCBhdWRpbyBsZXZlbCBpbmZv cm1hdGlvbiBhcyBkZWZpbmVkIGluIFJGQyA2MDk0LgpDb2xpbidzIHByb3Bvc2FsIGlzIFNIT1VM RC4KCkN1bGxlbiB3YW50cyBjb250cm9sIGF0IHRoZSBKYXZhc2NyaXB0IGxldmVsIG9mIHRoZSBl eGlzdGluZyBhdWRpbyBsZXZlbCBoZWFkZXJzIGFuZCB0aGVuIG1pZ2h0IGNvbnNpZGVyIG90aGVy cy4KSGFyYWxkIHdhbnRzIGFuIGFiaWxpdHkgdG8gY29udHJvbCB3aGljaCBoZWFkZXJzIGFyZSAq bm90KiBlbmNyeXB0ZWQuCgoKQ0hBSVJTOiBJZiBhbnlvbmUgd2FudHMgdG8gY2hhbmdlIHRoZSBy ZWNvbW1lbmRhdGlvbiwgZG8gc28gaW4gV0dMQy4K --e89a8f2354fd12137704f510c5e1-- From nobody Thu Mar 20 16:04:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF31A077C for ; Thu, 20 Mar 2014 16:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 33rcXAu5RpSQ for ; Thu, 20 Mar 2014 16:04:22 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8F41A0930 for ; Thu, 20 Mar 2014 16:04:22 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz12so1719397veb.21 for ; Thu, 20 Mar 2014 16:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a3Dr33Ah4N9EeTgHbQnc6qJ/XsjwXkLV6SIHQAXkvE0=; b=hNKh7tn+sqMf6P7VTvoDRNpB/5gYPaLXIQOsMBVli6wEG/IaSkirxpjMMHPTr7EhEm lY0wCuy4DfnxDf6jIescXSON/HMarmk5BFEA97+Fil2Y+8QVY3rr9ZxctvCSRJFhW9SI f1zHDLwy1A3gxsPZ/Yx5T/tuq0LO3eDCQwFu9GDPCMpHbIbeZbCMEZORFth9KQd06sG2 NpkwVY/+5JqcWFZ+BxDeZS3DwBurikQpVQva0tNz4tU3nI8Hyw9ZEyt2o/mTNJiqz7oO qFPcawucapJb8iHoRvvaWOoKbTFOvOBq1fiElvxnT1vV0gYYvLzndKAayGGEfd/6a2Xs EVow== 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=a3Dr33Ah4N9EeTgHbQnc6qJ/XsjwXkLV6SIHQAXkvE0=; b=mwnieSxR8bQP+/NcUfqRLTqiCrhjgj/aQYtT5XbCMqMQt0w9+CQDTXH2L1F3Yv9SAW nxgD8zKaS9Ext244FcVL+Wiwg0Y5q9ydOXiyPkUiLujDH0QFFK1GETkIcZfnazmH5l4i eiCQM9Nm2a5GyAgZK+53sioKnlLF3J4/PsfIa+U/merEvwKqfMs58NFSWJwAdSJph0NO Uhe70oIk+ntpmCUQraRH46Z7BdSa7xcMpyEMzrfa1nQsVnSy+L1T3QeSM6xG+WXb+/xW xUPhMYg4sIkdpF9kGvp96lxYkJUESjPqpFQ9MZuVvNnlu9IzujtwFHjZgYDu915/oime Z5DQ== X-Gm-Message-State: ALoCoQnk4Zw56HWUx7PZD2+foaSkF/w77g2IuVdE1ir3oj1yrYQUduXnLLOKCFA8O/0z4kfb/wa0G1021xqLBLsI6GLWY9LvC4mCw9bUc5pOIgpvDssG7lnitPEei08PUoM83winf+/ZGngpGQSabZFuMlA76LHJ578dR2wL0Ezfn26eCPERmkgIlaMfE4n66/Mcuu1XQc6b X-Received: by 10.52.134.202 with SMTP id pm10mr1704888vdb.55.1395356652834; Thu, 20 Mar 2014 16:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 16:03:52 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> From: Justin Uberti Date: Thu, 20 Mar 2014 16:03:52 -0700 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=bcaec5299f9ba0c75404f511c90c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oBfvnQi4ZKLdzZkEUaCnOKdxfQg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 23:04:25 -0000 --bcaec5299f9ba0c75404f511c90c Content-Type: text/plain; charset=UTF-8 Your take is what I had in mind. Basically a ruleset like this: gather_ipv4_addresses(); if (has_ipv6) { if (has_temporary_addresses && temporaries_not_forbidden_by_policy) { gather_temporary_ipv6_addresses(); } else { gather_non_temporary_ipv6_addresses(); } } On Thu, Mar 20, 2014 at 1:56 PM, Ted Hardie wrote: > On Thu, Mar 20, 2014 at 10:07 AM, Dan Wing wrote: > >> >> On Mar 20, 2014, at 9:34 AM, Justin Uberti wrote: >> >> >> >> >> >> So perhaps: >>> "An RTCWEB implementation SHOULD prefer to use temporary addresses >>> [RFC4941] where host and network policy permit [RFC6724]." >>> ? >>> >> >> I think it needs to be stronger than that - something like >> "where >> host and network policy permit, RTCWEB implementations SHOULD gather IPv6 >> temporary addresses and SHOULD NOT gather non-temporary addresses". >> >> Preferring to use temporary addresses is probably not sufficient to >> prevent linkage, since you will have connectivity checks from the >> non-temporary addresses. (i.e. an eavesdropper listening over an extended >> period of time could determine calls are from the same endpoint) >> >> >> Agreed. I like your suggested wording. >> >> -d >> >> >> > So, I note that in this case where a non-temporary IPv6 address is present > and no temporary IPv6 address is present, this appears to push IPv6 out of > the gathered list completely. If I have that right, then my view as an > individual is that this is the wrong result. It will either force the use > of IPv4 addresses which are just as linkable as IPv6 non-temporary > addresses or rely on NATs to get the non-linkability (and provide us all > the other subtle joys of NAT). > > As a friendly amendment, may I suggest "Where both non-temporary and > temporary addresses are present and host and network policy permit, RTCWEB > implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT > gather non-temporary addresses"? > > I also confess to a suspicion that Harald's view is the most > sensible--having a separate policy for this application either won't happen > or doesn't make much sense. But if we have one, I'd prefer one that > doesn't shove IPv6 out the door completely if the host doesn't use > temporary addresses. > > regards, > > Ted > --bcaec5299f9ba0c75404f511c90c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Your take is what I had in mind. Basically a ruleset like = this:

=C2=A0gather_ipv4_addresses();
=C2= =A0if (has_ipv6) {
=C2=A0 if (has_temporary_addresses && = temporaries_not_forbidden_by_policy) {
=C2=A0 =C2=A0 gather_temporary_ipv6_addresses();
=C2=A0 } el= se {
=C2=A0 =C2=A0 gather_non_temporary_ipv6_addresses();
=C2=A0}
}=C2=A0


=
On Thu, Mar 20, 2014 at 1:56 PM, Ted Hardie <t= ed.ietf@gmail.com> wrote:
=
On Thu, Mar 20, 2014 at 10:07 AM, Dan Wing <dwing@cisco.com<= /a>> wrote:

On Mar 20, 2014, at 9:34 AM, Justin Uberti <juberti@google.com> wrote:





So perhaps:
=C2=A0 =C2=A0"An RTCWEB implementation= SHOULD prefer to use temporary addresses [RFC4941] where host and network = policy permit [RFC6724]."
?

I think it needs to be stronge= r than that - something like=C2=A0
"where
host an= d network policy permit, RTCWEB implementations SHOULD gather IPv6 temporar= y addresses and SHOULD NOT gather non-temporary addresses".

Preferring to use temporary addresses is probably not s= ufficient to prevent linkage, since you will have connectivity checks from = the non-temporary addresses. (i.e. an eavesdropper listening over an extend= ed period of time could determine calls are from the same endpoint)

Agreed. =C2= =A0I like your suggested wording.
<= br>
-d



So, I note that in this case where a non-temporary IPv6 address is present = and=C2=A0 no temporary IPv6 address is present, this appears to push IPv6 o= ut of the gathered list completely.=C2=A0 If I have that right, then my vie= w as an individual is that this is the wrong result.=C2=A0 It will either f= orce the use of IPv4 addresses which are just as linkable as IPv6 non-tempo= rary addresses or rely on NATs to get the non-linkability (and provide us a= ll the other subtle joys of NAT).

As a friendly amendment, may I suggest "Where both non-= temporary and temporary addresses are present and host and network policy permit, RTCWEB implementations SHOULD gather IPv6=20 temporary addresses and SHOULD NOT gather non-temporary addresses"?
I also confess to a suspicion that Harald's view is the= most sensible--having a separate policy for this application either won= 9;t happen or doesn't make much sense.=C2=A0 But if we have one, I'= d prefer one that doesn't shove IPv6 out the door completely if the hos= t doesn't use temporary addresses.

regards,

Ted

--bcaec5299f9ba0c75404f511c90c-- From nobody Thu Mar 20 16:18:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA11D1A090C for ; Thu, 20 Mar 2014 16:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejj90rGAQ1Ni for ; Thu, 20 Mar 2014 16:18:02 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id C579E1A08E7 for ; Thu, 20 Mar 2014 16:18:01 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so1096845wgg.21 for ; Thu, 20 Mar 2014 16:17:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NpAbzLRqbqudBncWltipt1Jwvf9zY0ZWoVvBsLd9VIo=; b=SbAcHeImfF9/Z2E56KVESet1h+6IgDeE3UttWyfQcnAm7gynPkhUviGO316NzV1xG5 ut29wwqq1jjKrszemLsqgIImOEyerxTt3927luhWYRJJXvXWHL6G4ezqHFQMJABLjeYf Q+Aj2uerdjdWieY3RMUOw4Ewo3aGTR+Rh10y8cfEZraknmGz0Gu30OfBMJrUmou39MVD UTrITv2g+IWBGXxblmP2510CcAKXoJfLEr2gjulnhymihv2bPSLuVlEGVmkjHR+qaBDa jSuxwrIIHxPyD3AwLyZYBJmrq/p+S5DMCLbQD0QY/9X2z2Rcr11vUTPMGwol9f8rsNYC /5VQ== X-Gm-Message-State: ALoCoQmdzeBchTdAW7PWaHbtX3fcMHpwdSqManiruai+k53QXpwn/PqP7qCepk5n50PMhUeAmGxq X-Received: by 10.181.9.65 with SMTP id dq1mr26169161wid.51.1395357472286; Thu, 20 Mar 2014 16:17:52 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx.google.com with ESMTPSA id rx9sm2628131wjb.20.2014.03.20.16.17.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 16:17:51 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hm4so1313083wib.14 for ; Thu, 20 Mar 2014 16:17:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.206.102 with SMTP id ln6mr10304281wjc.43.1395357470614; Thu, 20 Mar 2014 16:17:50 -0700 (PDT) Received: by 10.216.49.137 with HTTP; Thu, 20 Mar 2014 16:17:50 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> Date: Thu, 20 Mar 2014 19:17:50 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b874abe5eed9804f511fa5a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/divHJcZEAmMDkokSqdL28f2KMc8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 20 Mar 2014 23:18:06 -0000 --047d7b874abe5eed9804f511fa5a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti wrote: > Your take is what I had in mind. Basically a ruleset like this: > > gather_ipv4_addresses(); > if (has_ipv6) { > if (has_temporary_addresses && temporaries_not_forbidden_by_policy) { > gather_temporary_ipv6_addresses(); > } else { > gather_non_temporary_ipv6_addresses(); > } > } > > What should be done when temporary enabled only on some of the network interfaces of the device, i.e. if, for instance, WiFI interface has only non temp ipv6 address and LTE has both temp and permanent address present? _____________ Roman Shpount --047d7b874abe5eed9804f511fa5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 20, 2014 at 7:03 PM, Justin Uberti <juberti@google.com> wrote:
Your take is what I had in mind. Basicall= y a ruleset like this:

=A0gather_ipv4_addresses();
=A0if (has_ipv6) {=
=A0 if (has_temporary_addresses && temporaries_not_forbi= dden_by_policy) {
=A0 =A0 gather_temporary_ipv6_addresses();
=A0 } else {
=A0 =A0 gather_non_temporary_ipv6_addresses();
=A0}
}=A0

<= br>
What should be done when temporary enabled only on some of the network inte= rfaces of the device, i.e. if, for instance, WiFI interface has only non te= mp ipv6 address and LTE has both temp and permanent address present?
_____________
Roman Shpount
=A0
--047d7b874abe5eed9804f511fa5a-- From nobody Thu Mar 20 17:09:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAF31A077C for ; Thu, 20 Mar 2014 17:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg8kWv1Ci_zh for ; Thu, 20 Mar 2014 17:08:24 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 12DAD1A080B for ; Thu, 20 Mar 2014 17:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2591; q=dns/txt; s=iport; t=1395360491; x=1396570091; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JTWSRiYgHIzVboju2xBLFQcBFU5jReqN7zdmmeZ/Z/c=; b=kck2NRGEMyrUGnnJ39909orqHj9UxrAHeeRV3ST4f0UHVl4oDhaEinzq Sf7PotgGmlu6mpeisV0uUSAh3lwrLmnxHVszQ2/Nsedfuo00h7HQ6zSr9 rM63dSFw/icUIP5JFQIow+xJYwpAZgMeteG8b4Gq/NVVZ/emkAi0w/MA9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFALCBK1OrRDoG/2dsb2JhbABZgwbDZIETFnSCJQEBAQMBeQULCxguITYGE4dlAwkHyGENhxkXjE2BZTMHgySBFASJUo0IgW2MaIVIg00dgSwk X-IronPort-AV: E=Sophos;i="4.97,699,1389744000"; d="scan'208";a="108577786" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 21 Mar 2014 00:08:10 +0000 Received: from sjc-vpn3-1362.cisco.com (sjc-vpn3-1362.cisco.com [10.21.69.82]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2L089IX016340; Fri, 21 Mar 2014 00:08:09 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Thu, 20 Mar 2014 17:08:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80B4969D-A548-407F-98E6-C749222DA4D9@cisco.com> References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> To: Ted Hardie X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kUX5l37md5ggMyS7BwUYaaDD4i4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 00:08:32 -0000 On Mar 20, 2014, at 1:56 PM, Ted Hardie wrote: > On Thu, Mar 20, 2014 at 10:07 AM, Dan Wing wrote: >=20 > On Mar 20, 2014, at 9:34 AM, Justin Uberti wrote: >=20 >>=20 >>=20 >>=20 >>=20 >> So perhaps: >> "An RTCWEB implementation SHOULD prefer to use temporary addresses = [RFC4941] where host and network policy permit [RFC6724]." >> ? >>=20 >> I think it needs to be stronger than that - something like=20 >> "where host and network policy permit, RTCWEB implementations SHOULD = gather IPv6 temporary addresses and SHOULD NOT gather non-temporary = addresses". >>=20 >> Preferring to use temporary addresses is probably not sufficient to = prevent linkage, since you will have connectivity checks from the = non-temporary addresses. (i.e. an eavesdropper listening over an = extended period of time could determine calls are from the same = endpoint) >=20 > Agreed. I like your suggested wording. >=20 > -d >=20 >=20 >=20 > So, I note that in this case where a non-temporary IPv6 address is = present and no temporary IPv6 address is present, this appears to push = IPv6 out of the gathered list completely. If I have that right, then my = view as an individual is that this is the wrong result. It will either = force the use of IPv4 addresses which are just as linkable as IPv6 = non-temporary addresses or rely on NATs to get the non-linkability (and = provide us all the other subtle joys of NAT).=20 >=20 > As a friendly amendment, may I suggest "Where both non-temporary and = temporary addresses are present and host and network policy permit, = RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD = NOT gather non-temporary addresses"? >=20 > I also confess to a suspicion that Harald's view is the most = sensible--having a separate policy for this application either won't = happen or doesn't make much sense.=20 Ok, so preface your suggested sentence with, =93WebRTC applications are encouraged to follow IPv6 Socket API for = Source Address Selection [RFC5014] with regards to IPv6 temporary = addresses, specifically .=94 It=92s not that WebRTC is trying to do something unique here =97 we just = want this done, and not just hope an implementor stumbles into the right = IETF document explaining temporary IPv6 addresses. -d > But if we have one, I'd prefer one that doesn't shove IPv6 out the = door completely if the host doesn't use temporary addresses. >=20 > regards, >=20 > Ted From nobody Thu Mar 20 17:28:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7141A08E7 for ; Thu, 20 Mar 2014 17:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 iOUA0zP-aERU for ; Thu, 20 Mar 2014 17:28:46 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id CB79C1A0809 for ; Thu, 20 Mar 2014 17:28:45 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so1897076vcb.27 for ; Thu, 20 Mar 2014 17:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XeBUssFKF4apJ6lmHukB4fx7Of2D32hVdYe3yuofgD8=; b=apBqRW3UEKLUTted2QydeKxXYzW+SE8FPyKoEuMC6OAfplWA0EV6kSd7Mo6uJehcPh 2HOckYFT5DE1P/gGww1K786arJEkWxXPlU9O4k+M4mluViYUf8IPNfvSXqMOFMFg7Cgz tGTStYDhnRPcKLe9PrTHehekNuOybAXABwE0dj47b5rf50rY8Jr1skkUkBc6UjSSCv9e tLrrLjLChYcMCCHBbxJ3fG3xAJf8buxmkbWd930ql0I5Sm2jRTjlgW+Egf3bbYtccYzI vHpcvGJpsFbGACS/SmzWCVQQ7kV9I4L4utPOrZlzzguG896Pu0DmKZZT8MwSxU8i6XRl +hLg== 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=XeBUssFKF4apJ6lmHukB4fx7Of2D32hVdYe3yuofgD8=; b=Yfic/Ogko/KIM8l2Te9PKvYHK4mRHnasQtFGBxRpbI+PctxOtEWU/nsddQumqq+o0G wNUzzimk/5PPM1iBR5Dxb4PtTV3oUQib5sY4O9vOwGetduaGjzvOi9PAfwZwW3KIjl2T osRgzvUCKGwq4cKeOz8NrjvyHiF8OqYUQ0JAuEefhlNFA0BhPxdqwV07xXczlYASPYCA 0h7vk+R3JQkQCWPyRD2P+uEs+MMHrqJCEa6l+bumCaDUbVGYI9gvmYyEIwAz4SDLmUSl 98k0oO5kLK5I1aUATx/keun7iiDHcS0gVp8H4Hjhj8L1qlE+5iw0WEylGzr3Shro8Fgy 115Q== X-Gm-Message-State: ALoCoQmsm+1SsSrmuru/6BYwC2G/a0ub7l2vpaJWJutHdp7eCGeZx4t7kIWx/td2G4AUUa1VAYZhJvhJShEf8WXr83Kc+m0QZcencTjyEL8C3mJXB8ou4a+hXGWB2/oSclR6sDMjPmPHkGJBpENjrUkwgEklyXVf9yyQ4pjDfcv8RH8n2NSiuf/Vxa+eElb+f/lFjPvFFCR4 X-Received: by 10.52.142.10 with SMTP id rs10mr30165113vdb.3.1395361716459; Thu, 20 Mar 2014 17:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 17:28:16 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> From: Justin Uberti Date: Thu, 20 Mar 2014 17:28:16 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=bcaec51a71907179d804f512f79b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YulvfiBZTPLebeKvIQKvtpdG7b0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 00:28:48 -0000 --bcaec51a71907179d804f512f79b Content-Type: text/plain; charset=UTF-8 On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount wrote: > On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti wrote: > >> Your take is what I had in mind. Basically a ruleset like this: >> >> gather_ipv4_addresses(); >> if (has_ipv6) { >> if (has_temporary_addresses && temporaries_not_forbidden_by_policy) { >> gather_temporary_ipv6_addresses(); >> } else { >> gather_non_temporary_ipv6_addresses(); >> } >> } >> >> > What should be done when temporary enabled only on some of the network > interfaces of the device, i.e. if, for instance, WiFI interface has only > non temp ipv6 address and LTE has both temp and permanent address present? > > Is this a real-world problem? As I understand it, temporary addresses are assigned by the host, so you either support them or you don't. --bcaec51a71907179d804f512f79b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount &l= t;roman@telurix.com<= /a>> wrote:
=
On Thu, Mar 20, 2014 at 7:03 PM,= Justin Uberti <juberti@google.com> wrote:
Your take is what I had in mind. Basicall= y a ruleset like this:

=C2=A0gather_ipv4_addresses();
=C2=A0if (has_i= pv6) {
=C2=A0 if (has_temporary_addresses && temporaries_= not_forbidden_by_policy) {
=C2=A0 =C2=A0 gather_temporary_ipv6_addresses();
=C2=A0 } el= se {
=C2=A0 =C2=A0 gather_non_temporary_ipv6_addresses();
=C2=A0}
}=C2=A0


What should be done when temporary enabled only on some of the network inte= rfaces of the device, i.e. if, for instance, WiFI interface has only non te= mp ipv6 address and LTE has both temp and permanent address present?

=C2=A0
Is this a real-world = problem? As I understand it, temporary addresses are assigned by the host, = so you either support them or you don't.
--bcaec51a71907179d804f512f79b-- From nobody Thu Mar 20 19:39:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7211A085D for ; Thu, 20 Mar 2014 19:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITk-IRXaERuN for ; Thu, 20 Mar 2014 19:39:53 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 58EAB1A0864 for ; Thu, 20 Mar 2014 19:39:49 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so1195235wes.16 for ; Thu, 20 Mar 2014 19:39:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MRZRbzri4W4odbYwo+ahvSswbJpAQCco8t5AOKOeXKo=; b=LJELBEkeifmxhPYJ3AVUO7WSEssnwAGkkGZh87fkQZP7dGNvUgIOLqkGEwoJphAQtD lAXlmbZagycNODc3Ijha6TKiGeLjNRlFpffgVraaY7Mf78iCygd2xAC2cEY162KlU4p5 58N607FYlN34m0O7UUI8zgIpatTmbBh6w2QjriG2o+uZD/Cw2905wqqJt5n0qIfdUC6p ffk0ssO3+LOdkanJixQOpsWd7OWTDAg/VeotEF5W+8TblA+E+P8DQKeXRhkjPC8dSoXQ xo4JbSsZxcQinlhOLNrhZESInLuoUGuAILwoZE6s48ATLYAvU5+Ni0ayA7lBs4AqfkNi 5TpA== X-Gm-Message-State: ALoCoQmsqR+TivEV5XB51KLa7lUIiYfwMTZqJJ237wYd8TO5doRGH/tMfNW/Fawg5KH9T+apbCwe X-Received: by 10.194.192.132 with SMTP id hg4mr37257089wjc.28.1395369579536; Thu, 20 Mar 2014 19:39:39 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx.google.com with ESMTPSA id n3sm719763wix.10.2014.03.20.19.39.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 19:39:38 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so1212839wgg.14 for ; Thu, 20 Mar 2014 19:39:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr37563136wjc.9.1395369578402; Thu, 20 Mar 2014 19:39:38 -0700 (PDT) Received: by 10.216.49.137 with HTTP; Thu, 20 Mar 2014 19:39:38 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> Date: Thu, 20 Mar 2014 22:39:38 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b873a100d1ad304f514cccf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wU_6TifoX02JNKn0ZkppAJPJi4A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 02:39:56 -0000 --047d7b873a100d1ad304f514cccf Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 8:28 PM, Justin Uberti wrote: > > On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount wrote: > >> On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti wrote: >> >>> Your take is what I had in mind. Basically a ruleset like this: >>> >>> gather_ipv4_addresses(); >>> if (has_ipv6) { >>> if (has_temporary_addresses && temporaries_not_forbidden_by_policy) { >>> gather_temporary_ipv6_addresses(); >>> } else { >>> gather_non_temporary_ipv6_addresses(); >>> } >>> } >>> >>> >> What should be done when temporary enabled only on some of the network >> interfaces of the device, i.e. if, for instance, WiFI interface has only >> non temp ipv6 address and LTE has both temp and permanent address present? >> >> > Is this a real-world problem? As I understand it, temporary addresses are > assigned by the host, so you either support them or you don't. > On Linux you can enable temporary addresses per interface, so it is possible. The whole problem (with using temp or permanent addresses) is a bit imaginary since under most common client setups you only see temporary addresses. Permanent IPv6 addresses show up only on servers or if specifically configured on the host. _____________ Roman Shpount --047d7b873a100d1ad304f514cccf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 20, 2014 at 8:28 PM, Justin Uberti <juberti@google.com> wrote:

On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount <rom= an@telurix.com> wrote:
On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
Your take is what I had in mind. Basicall= y a ruleset like this:

=A0gather_ipv4_addresses();
=A0if (has_ipv6) {=
=A0 if (has_temporary_addresses && temporaries_not_forbi= dden_by_policy) {
=A0 =A0 gather_temporary_ipv6_addresses();
=A0 } else {
=A0 =A0 gather_non_temporary_ipv6_addresses();
=A0}
}=A0

<= br>
What should be done when temporary enabled only on some of the network inte= rfaces of the device, i.e. if, for instance, WiFI interface has only non te= mp ipv6 address and LTE has both temp and permanent address present?

=A0
Is this a real-world problem?= As I understand it, temporary addresses are assigned by the host, so you e= ither support them or you don't.

On Linux you can enable temporary ad= dresses per interface, so it is possible.

The whol= e problem (with using temp or permanent addresses) is a bit imaginary since= under most common client setups you only see temporary addresses. Permanen= t IPv6 addresses show up only on servers or if specifically configured on t= he host.
_____________
Roman Shpount

--047d7b873a100d1ad304f514cccf-- From nobody Thu Mar 20 21:13:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832BE1A091C for ; Thu, 20 Mar 2014 21:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 5efqbe0STcWQ for ; Thu, 20 Mar 2014 21:13:29 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 769591A07FF for ; Thu, 20 Mar 2014 21:13:29 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so2077554vcb.10 for ; Thu, 20 Mar 2014 21:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ifYdx3vBhoCPac79WsLyaLLkmiiZ9eSTHknTCmQQZhU=; b=M4dXkrBqP0TlDMPTYu2xhq+msiQu+VVzcLiSQs+mXxIuhqe1rkzON39w1mQqoG9Myg ZwK0EOsRymEdC99GBSNA+TPC0SXeMjBXFA48Ptn+qMQngjYNfjscN3FpdnW/kxAp5ekY g5Z07CXqfHeXDqwp7l7UJDWUEwDiWftomUU/ZUsv3gIje8QD3xQR+heWyEp4gvN647xu 0Og+06LH9QtXczQUPlov2+eLoe42KU93cN+wZFhe3+j8xetcBCrSE25eKPSA7tZwdVe1 mavYTVrn68xt+ItnkyNg1yk5pzt6pwGPTehwfpdIdOlyMnjj+joiLnMYv5ASSOZolgLX PKSg== 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=ifYdx3vBhoCPac79WsLyaLLkmiiZ9eSTHknTCmQQZhU=; b=JPoOJaB3kGEl19g7nwYGqf3wJvAC3XY/O58LIGc1QsFTcj446DfjeNbpDQ+a+XoOHQ 02L4ldjo00iZrKJDWYcV2Pn4+rXUVX5o0Sdc+QLwvwfgyM0LbP8ADRdCPltrW4X5W5hS Aotugbh218Xt85EwVkEmt2DUlBJBaQoEDpxnadooJuVExad360AJlj+nNADLtyeQSkND YcgLOxCmALwqGj3S0Dfz11AaYfVEajznERhwGxaB8KxJhcVlLuMPZgrqW7xaXjM6f8ea WZJDp73uOVMEwFuQ7LKbEnmwCy3CpiRpFWeIA8GPzd8iUzc8buBcj+UJaGzsF7QuyXSU kP4A== X-Gm-Message-State: ALoCoQknlQ9kginYhdBvJSkYd1PWFYFHm5N23cZyK9I8igTWOimh6xg43ZK5o5mFw5Q3gs891QLh/+Vx2RkMbs0uO44nq7bEZtpyblR0dF/dyiJx4i47Qgeq05Os6oXmN9LOTbU4XLtB5hi1fSdHqWAZIXNueLvXWi9de8Klq7Q+5laQQlj9Q9yhtpsYAu+S8uHEikH6cFfl X-Received: by 10.58.161.101 with SMTP id xr5mr5990620veb.36.1395375199900; Thu, 20 Mar 2014 21:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 21:12:59 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> From: Justin Uberti Date: Thu, 20 Mar 2014 21:12:59 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7b5d5b0a1e72c904f5161b48 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tR4kINS-lZyooxj0ESQrn_0-PU0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 04:13:31 -0000 --047d7b5d5b0a1e72c904f5161b48 Content-Type: text/plain; charset=UTF-8 OK. Perhaps the guidance should be that if an interface has a temporary and a non-temporary address, only the temporary one should be gathered. This avoids any problems if local policy chooses not to use temporary addresses. FWIW, I have seen this setup where a client has both non-temporary and temporary addresses in the wild, so this is a real-world problem. On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount wrote: > On Thu, Mar 20, 2014 at 8:28 PM, Justin Uberti wrote: > >> >> On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount wrote: >> >>> On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti wrote: >>> >>>> Your take is what I had in mind. Basically a ruleset like this: >>>> >>>> gather_ipv4_addresses(); >>>> if (has_ipv6) { >>>> if (has_temporary_addresses && temporaries_not_forbidden_by_policy) { >>>> gather_temporary_ipv6_addresses(); >>>> } else { >>>> gather_non_temporary_ipv6_addresses(); >>>> } >>>> } >>>> >>>> >>> What should be done when temporary enabled only on some of the network >>> interfaces of the device, i.e. if, for instance, WiFI interface has only >>> non temp ipv6 address and LTE has both temp and permanent address present? >>> >>> >> Is this a real-world problem? As I understand it, temporary addresses are >> assigned by the host, so you either support them or you don't. >> > > On Linux you can enable temporary addresses per interface, so it is > possible. > > The whole problem (with using temp or permanent addresses) is a bit > imaginary since under most common client setups you only see temporary > addresses. Permanent IPv6 addresses show up only on servers or if > specifically configured on the host. > _____________ > Roman Shpount > > --047d7b5d5b0a1e72c904f5161b48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK. Perhaps the guidance should be that if an interface ha= s a temporary and a non-temporary address, only the temporary one should be= gathered. This avoids any problems if local policy chooses not to use temp= orary addresses.

FWIW, I have seen this setup where a client has both non-tem= porary and temporary addresses in the wild, so this is a real-world problem= .


On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <roman@telurix.com><= /span> wrote:
On Thu, Mar 20, 2014 at 8:28 PM, Justin Uberti <jubert= i@google.com> wrote:

On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount = <roman@telurix.co= m> wrote:
On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
Your take is what I had in mind. Basicall= y a ruleset like this:

=C2=A0gather_ipv4_addresses();
=C2=A0if (has_i= pv6) {
=C2=A0 if (has_temporary_addresses && temporaries_= not_forbidden_by_policy) {
=C2=A0 =C2=A0 gather_temporary_ipv6_addresses();
=C2=A0 } el= se {
=C2=A0 =C2=A0 gather_non_temporary_ipv6_addresses();
=C2=A0}
}=C2=A0


What should be done when temporary enabled only on some of the network inte= rfaces of the device, i.e. if, for instance, WiFI interface has only non te= mp ipv6 address and LTE has both temp and permanent address present?

=C2=A0
Is this a real-world probl= em? As I understand it, temporary addresses are assigned by the host, so yo= u either support them or you don't.

On Linux you can enable = temporary addresses per interface, so it is possible.

<= div>The whole problem (with using temp or permanent addresses) is a bit ima= ginary since under most common client setups you only see temporary address= es. Permanent IPv6 addresses show up only on servers or if specifically con= figured on the host.
_____________
Roman = Shpount


--047d7b5d5b0a1e72c904f5161b48-- From nobody Thu Mar 20 23:59:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3641A0945 for ; Thu, 20 Mar 2014 23:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJZ4RCy_vJwW for ; Thu, 20 Mar 2014 23:59:37 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 76E141A0944 for ; Thu, 20 Mar 2014 23:59:36 -0700 (PDT) Received: from [192.168.40.10] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4721193C2A1; Fri, 21 Mar 2014 06:59:20 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB048804-396B-4F8B-B19D-DAA57CAEEE0F" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 21 Mar 2014 07:59:25 +0100 Message-Id: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> To: Justin Uberti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EFhhd1x6VCbubB00afLMNr91I-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 06:59:41 -0000 --Apple-Mail=_DB048804-396B-4F8B-B19D-DAA57CAEEE0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Mar 2014, at 01:28, Justin Uberti wrote: >=20 >=20 >=20 > On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount = wrote: > On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti = wrote: > Your take is what I had in mind. Basically a ruleset like this: >=20 > gather_ipv4_addresses(); > if (has_ipv6) { > if (has_temporary_addresses && temporaries_not_forbidden_by_policy) = { > gather_temporary_ipv6_addresses(); > } else { > gather_non_temporary_ipv6_addresses(); > } > }=20 >=20 >=20 > What should be done when temporary enabled only on some of the network = interfaces of the device, i.e. if, for instance, WiFI interface has only = non temp ipv6 address and LTE has both temp and permanent address = present? >=20 > =20 > Is this a real-world problem? As I understand it, temporary addresses = are assigned by the host, so you either support them or you don't. There is a way to get them from a DHCP server. http://tools.ietf.org/html/rfc3315#section-12 /O --Apple-Mail=_DB048804-396B-4F8B-B19D-DAA57CAEEE0F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 21 Mar 2014, at 01:28, Justin Uberti <juberti@google.com> wrote:




On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount <roman@telurix.com> wrote:
On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti <juberti@google.com> wrote:
Your take is what I had in mind. Basically a ruleset like this:

 gather_ipv4_addresses();
 if (has_ipv6) {
  if (has_temporary_addresses && temporaries_not_forbidden_by_policy) {
    gather_temporary_ipv6_addresses();
  } else {
    gather_non_temporary_ipv6_addresses();
 }
} 


What should be done when temporary enabled only on some of the network interfaces of the device, i.e. if, for instance, WiFI interface has only non temp ipv6 address and LTE has both temp and permanent address present?

 
Is this a real-world problem? As I understand it, temporary addresses are assigned by the host, so you either support them or you don't.

There is a way to get them from a DHCP server.

/O

--Apple-Mail=_DB048804-396B-4F8B-B19D-DAA57CAEEE0F-- From nobody Fri Mar 21 01:16:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B511A095A for ; Fri, 21 Mar 2014 01:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg1gzhr5llbM for ; Fri, 21 Mar 2014 01:16:02 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 492411A08B6 for ; Fri, 21 Mar 2014 01:16:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5DF097C4A70; Fri, 21 Mar 2014 09:15:52 +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 HePXl60VnOoF; Fri, 21 Mar 2014 09:15:50 +0100 (CET) Received: from [172.30.42.84] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id C04EA7C0CC2; Fri, 21 Mar 2014 09:15:50 +0100 (CET) Message-ID: <532BF536.2060505@alvestrand.no> Date: Fri, 21 Mar 2014 09:15:50 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dan Wing References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> In-Reply-To: <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080203040305080106000402" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yNkHymBpfIhrCq2rD1YhFxjBuEo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 08:16:08 -0000 This is a multi-part message in MIME format. --------------080203040305080106000402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/20/2014 03:52 PM, Dan Wing wrote: > > On Mar 19, 2014, at 8:21 AM, Harald Alvestrand > wrote: > >> On 03/19/2014 04:08 PM, Dan Wing wrote: >>> >>> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand >> > wrote: >>> >>>> I'd like to be silent on the issue, since which IPv6 addresses to >>>> prefer is likely to be a matter of system policy. Trying to >>>> override system policy in an application specific profile usually >>>> leads to sadness. >>> >>> The application needs to indicate if it wants a temporary address. >>> If the host's policy (or configuration or network) does not support >>> temporary addresses, the application won't get a temporary address. >>> I don't see why being silent helps? >> >> What API is it using? >> >> With a little Googling, the system policy I was thinking of was the >> policy in RFC 6724 ("Default Address Selection for IPv6"), in >> particular section 5 rule 7: "Prefer temporary addresses". >> >> I'm happy to say "it is a good idea for systems to implement the >> recommendations of RFC 6724" (or some more 2119-like language). I >> wouldn't want to claim that if a system has chosen to prefer >> non-temporary addresses, it would have to change its non-conformance >> to RFC 6724 in order to be conformant with RTCWEB specifications. > > So perhaps: > "An RTCWEB implementation SHOULD prefer to use temporary addresses > [RFC4941] where host and network policy permit [RFC6724]." > ? Or even be more explicit on what's being proposed: "When a client gathers all IPv6 addresses on a host, and both temporary addresses [RFC4941] and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before forming pairs. This is consistent with the default policy described in [RFC6724]." Pulling back a little, I am starting to wonder if this is an ICE concern rather than an RTCWEB concern. The explosion in candidate pairs as more transport / network options come on line is a real operational problem, and needs to be solved for all ICE usages. I'll stick something in -transport, but RTCWEB is not the only thing that will have this problem. > > -d > > >> >>> >>> -d >>> >>> >>>> >>>> >>>> >>>> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing >>> > wrote: >>>> >>>> >>>> On Mar 18, 2014, at 6:00 PM, Justin Uberti >>> > wrote: >>>> >>>>> https://tools.ietf.org/html/rfc4941 defines the concept of >>>>> temporary IPv6 addresses. For, example, as enumerated on my >>>>> local system: >>>>> >>>>> inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 >>>>> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf >>>>> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 >>>>> autoconf *temporary * >>>>> >>>>> As indicated in the RFC, the temporary addresses expire after >>>>> hours or days, and therefore could be used to prevent >>>>> long-term linkability of sessions. Expiration shouldn't be an >>>>> issue for WebRTC, since we can simply do ICE restart if this >>>>> occurs during a session. >>>>> >>>>> Is this something we want to recommend in the transports doc? >>>> >>>> Yes. >>>> >>>> And it should be as frequent as every new 'call', if IPv6 >>>> privacy addresses are to provide the same privacy as a NAPT44, >>>> as a NAPT44 should be assigning random ports per reasons >>>> described in RFC6056. >>>> >>>> The transport document should also recommend doing port >>>> randomization (RFC6056), as that was found pretty useful for >>>> DNS, but randomizing ports is still not popular with many OS's >>>> TCP stacks for whatever reason. >>>> >>>> -d >>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 > -- Surveillance is pervasive. Go Dark. --------------080203040305080106000402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/20/2014 03:52 PM, Dan Wing wrote:

On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

On 03/19/2014 04:08 PM, Dan Wing wrote:

On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <hta@google.com> wrote:

I'd like to be silent on the issue, since which IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness.

The application needs to indicate if it wants a temporary address. If the host's policy (or configuration or network) does not support temporary addresses, the application won't get a temporary address.  I don't see why being silent helps?

What API is it using?

With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer  temporary addresses".

I'm happy to say "it is a good idea for systems to implement the recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications.

So perhaps:
   "An RTCWEB implementation SHOULD prefer to use temporary addresses [RFC4941] where host and network policy permit [RFC6724]."
?
Or even be more explicit on what's being proposed:

"When a client gathers all IPv6 addresses on a host, and both temporary addresses [RFC4941] and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before forming pairs. This is consistent with the default policy described in [RFC6724]."


Pulling back a little, I am starting to wonder if this is an ICE concern rather than an RTCWEB concern. The explosion in candidate pairs as more transport / network options come on line is a real operational problem, and needs to be solved for all ICE usages.

I'll stick something in -transport, but RTCWEB is not the only thing that will have this problem.



-d




-d





On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <dwing@cisco.com> wrote:

On Mar 18, 2014, at 6:00 PM, Justin Uberti <juberti@google.com> wrote:

https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system:

inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf 
inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf temporary 

As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session.

Is this something we want to recommend in the transports doc?

Yes.

And it should be as frequent as every new 'call', if IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a NAPT44 should be assigning random ports per reasons described in RFC6056.

The transport document should also recommend doing port randomization (RFC6056), as that was found pretty useful for DNS, but randomizing ports is still not popular with many OS's TCP stacks for whatever reason.

-d






_______________________________________________
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



-- 
Surveillance is pervasive. Go Dark.
--------------080203040305080106000402-- From nobody Fri Mar 21 01:19:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860A81A0395 for ; Fri, 21 Mar 2014 01:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 inRowPGkAv1H for ; Fri, 21 Mar 2014 01:19:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DACED1A08AB for ; Fri, 21 Mar 2014 01:19:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f038e000005d01-5d-532bf5f414d8 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 20.C1.23809.4F5FB235; Fri, 21 Mar 2014 09:19:01 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.347.0; Fri, 21 Mar 2014 09:19:00 +0100 Message-ID: <532BF5F4.90901@ericsson.com> Date: Fri, 21 Mar 2014 09:19:00 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Justin Uberti References: <531DE104.2010908@ericsson.com> <532AC890.7000602@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RvfrV+1gg+Y2RoutU4Us1v5rZ3dg 8liwqdRjyZKfTAFMUVw2Kak5mWWpRfp2CVwZLyftYC+Yql1x+cRsxgbGB7JdjJwcEgImEgfu LmCBsMUkLtxbz9bFyMUhJHCIUWLR/onsEM5yRomJm5rAqngFNCXur/vMBGKzCKhK3H7WzgZi swlYSNz80QhmiwoESyydsxiqXlDi5MwnYLaIgJrEw1m7WEFsZgF1iTuLz7GD2MICuhLrlu9h glg2i0ni79t7YIM4BQIlzl6+AGRzAJ0nLtHTGATRqynRuv03O4QtL9G8dTYziC0koC3R0NTB OoFRaBaS1bOQtMxC0rKAkXkVI3tuYmZOernRJkZgoB7c8lt1B+OdcyKHGKU5WJTEeT+8dQ4S EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFjJdNva6Yy9fWs+g9XqX3Hmq1SCq8XDP0r+Piip OivJ7LFWeBHv7LmdFz7E3dUqvyc5t+T111uRfHG76h9mlD+Q3m4w2z3qWumC3vYGtofPl0hq 6teWi3mnf9+ZLbCrYU3BnIj/HAzXn68+XvA/2W/VQzXrVU/FzmyULtQ4FGb7d+HjVYIKa5RY ijMSDbWYi4oTAQix2JoiAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/E9ivoIZejNsOvBQ4Ua5W54RPnoc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On ptimes and maxptimes 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, 21 Mar 2014 08:19:14 -0000 On 2014-03-20 17:39, Justin Uberti wrote: > > > > On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund > > > wrote: > > On 2014-03-20 01:27, Justin Uberti wrote: > > > > > > > > On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund > > > >> > > wrote: > > > > Hi, > > > > (As individual) > > > > On 2014-03-05 17:26, Justin Uberti wrote: > > > From the session this morning, I recall this consensus: > > > > > > * We will add recommendations on the frame sizes to use for > > PCMU/A to > > > the rtcweb audio codec I-D (20, 30, 60 ms frames). > > > > The above applies to sending payloads > > > > > > Right, thanks for pointing that out. > > > > > > Yes, but that was given that a receiver will be capable of > receiving any > > valid number of frames, or samples within a reasonable > packetization, > > and I think that should be 120 ms. > > > > > * We will consider adding an a=maxptime attribute that > > represents the > > > "minimum maxptime" of all the offered codecs. That is, > if both > > Opus > > > (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a > > > maxptime=60 SHOULD be included. > > > o Since maxptime spans all codecs, this means that > some modes > > > (e.g. Opus 120ms) will be unavailable, unless only > Opus is > > offered. > > > > I think you base the assumption on maxptime based on the sending > > recommendations, not what is capable of receiving. If one is > capable of > > receiving 200 ms of a-law and Opus, then you would need to say > 120 ms as > > Opus will limit you. > > > > > > I agree that Opus' maxptime is 120, but should that prevent > sending PCMU > > with 200 ms? That is, since sending Opus with 200 ms is not legal, is > > there any point in forcing WebRTC impls to indicate this in SDP? > > What I wished we fixed this issue with maxptime a long time ago. This is > a well known problem that it really has PT scope, but are signalled on > m= line scope. > > > > > > > > > > * We will consider adding an a=ptime attribute, set to the > > receiver's > > > preferred frame size to receive. Again, this value spans all > > codecs, > > > so the specified value may not be viable for all codecs > (e.g. > > 30 ms > > > works for PCMU but not for Opus) > > > > > > After thinking about this some, I'm not sure the > maxptime/ptime values > > > will lead to any different behavior than if they were not > specified. > > > Since there is a complexity cost (especially if the values > need to > > > change based on which codecs are offered), is there a clear > upside > > here? > > > > The maxptime values may in some cases be limited downwards for > > interoperability, for example if one like to gateway AMR into a CS > > network then the gateway might indicate a maxptime that is > less, more > > like 20 or 40 ms. > > > > > > Sure - WebRTC impls need to respect any maxptime value that they > > receive, but it's not clear to me that they need to include one in the > > SDP they send. > > Ok, but then we are back to my previous argument for writing down what > receiver requirement in regards to each payload type one is required to > support in the audio draft for the ones specified there. But what about > the other codecs that aren't included in the audio draft? > > How can a peer know if there are limitations? I wouldn't attempt to > solve the general problem of the scope issue with maxptime. Simply state > that you should include this. It is going to be limited but still > provide information in many cases that is quite useful for the sender. > > > Just to be sure I understand, your position is that WebRTC impls SHOULD > include an a=maxptime attribute indicating the "minimum maximum" frame > size they can receive, across all codecs? Yes, as long as we lack payload type specific, I think that is the best we can do. > > Do you think anything needs to be included regarding a=ptime? I think it MAY be included to indicate an initial preference for packetization interval. In cases that is not common across the set of payload types for that m= section, then one should skip it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 21 04:14:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB31A0895 for ; Fri, 21 Mar 2014 04:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDlldPicKz_l for ; Fri, 21 Mar 2014 04:14:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 731A71A07B5 for ; Fri, 21 Mar 2014 04:14:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CCB1C7C4F19 for ; Fri, 21 Mar 2014 12:14:26 +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 WAEaSyppZO4Z for ; Fri, 21 Mar 2014 12:14:26 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1D0227C4F50 for ; Fri, 21 Mar 2014 12:14:26 +0100 (CET) Message-ID: <532C1F0C.3020801@alvestrand.no> Date: Fri, 21 Mar 2014 12:14:20 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5329B617.2070001@alvestrand.no> <5329BABA.6020003@viagenie.ca> In-Reply-To: <5329BABA.6020003@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SlLyzJaHmz1hMIDFi_EpPni2amE Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 11:14:40 -0000 On 03/19/2014 04:41 PM, Simon Perreault wrote: > Le 2014-03-19 11:21, Harald Alvestrand a écrit : >>> The application needs to indicate if it wants a temporary address. If >>> the host's policy (or configuration or network) does not support >>> temporary addresses, the application won't get a temporary address. I >>> don't see why being silent helps? >> What API is it using? >> >> With a little Googling, the system policy I was thinking of was the >> policy in RFC 6724 ("Default Address Selection for IPv6"), in particular >> section 5 rule 7: "Prefer temporary addresses". >> >> I'm happy to say "it is a good idea for systems to implement the >> recommendations of RFC 6724" (or some more 2119-like language). I >> wouldn't want to claim that if a system has chosen to prefer >> non-temporary addresses, it would have to change its non-conformance to >> RFC 6724 in order to be conformant with RTCWEB specifications. > IMHO it would be perfectly sensible to recommend the use of > IPV6_PREFER_SRC_TMP [RFC5014]. > > Simon Interesting: This rule was reversed from 3484 to 6724 - 3484 preferred public, 6724 prefers temporary. 5014 claims that the default is PREFER_SRC_PUBLIC, which is not 6724 conformant. And RFC 5245 (ICE) contains a pointer to RFC 3484, recommending its use in address selection. With this amount of misleading stuff in RFCs, I think it's best to say something after all. From nobody Fri Mar 21 08:27:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B49D1A0989 for ; Fri, 21 Mar 2014 08:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 C3yvZA91oQ2O for ; Fri, 21 Mar 2014 08:27:42 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 12BF11A0731 for ; Fri, 21 Mar 2014 08:27:41 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so2671690veb.23 for ; Fri, 21 Mar 2014 08:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4k4djDBRU8Yc7Jehbi4j65UZ/pYBBve7b5tM7ORgAT4=; b=DFmPPb+jvVXpCHCivkiANuVCpRSZzHdALfnHsxCpXhFNOG0slNrGnbONJz72LW6odv ZXRtpe3nJjhoFWJgVfI08fyqNcoP13B+/q9vL+N6JhYmpcqAi1ihhYktVg7r11I6c6GM W7agBwUMF65vSUOgUFTml5YV9SsOKVvPsutSHkzfEZzNfWQR7hmnve25KOEJSorHj8dz 1M1r6zoUEBSEbGNuUyuKXokLRNlCJe8l1R5+YmSeMag40G3/ApYn1fnhtlkBSGOwtjKQ Fjmq4OKUrB9bdYZ/TJM3yhIUc7oYwzj4Y7JHuWI9BcNDWdo6Knz0xcq+VaRSgQTvedQ0 /zNg== 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=4k4djDBRU8Yc7Jehbi4j65UZ/pYBBve7b5tM7ORgAT4=; b=gL/y+K4j6EEgTlfxnz3y2qMmAw3e3zU9VEBje4nRdNbq9DOyZA1eLMMzmdYd6CGxQ9 QQRaDRZBFLmG7JYylso+efQRCCpcht5Ovkt9Obs36X8zCNHo6pRFgVvCPhRj8rQ/EiBV ddVLhZBj93WPioTEAaC5RJDoa3XxapwjhwG2p6STGKfJy+EJrTjuuqUAmGhFg1Oqe6v4 awa3FxXDb4doO4RLOq/8LZEG+A2woWPjj+IjNq4xesPFqteY8l+g2qG7qQWWIBW8O+N6 wMoQoa+VdbEMcfN/LPymkE5d8bbow99FRoiYYoMWqCIuCAXx0UybFIUQed+QL4uAzdLi sanw== X-Gm-Message-State: ALoCoQnR0LLbXDgScwP+N4ikLjj11R1JKJbJHKLnNG/7A4LShRpD3T4/HA4SSAFbP8/BE+II4+gsVY8rbCyNYkqHKX6XgkJcXkRsduWPdl+6pGY3foWPozgDlHjvR/GW2nRP8NciJMsdcoz9uLBKkwdGuPEeTD6O2cZnQ92kV5S8LS9Sg4/KkHNdXCSKt/aDQpbnoLO1497s X-Received: by 10.221.74.65 with SMTP id yv1mr7880844vcb.31.1395415652512; Fri, 21 Mar 2014 08:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 21 Mar 2014 08:27:12 -0700 (PDT) In-Reply-To: <532BF536.2060505@alvestrand.no> References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <532BF536.2060505@alvestrand.no> From: Justin Uberti Date: Fri, 21 Mar 2014 08:27:12 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113656384861ad04f51f862c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kQgWLADowNKNBOFfS2-ms3_uz0A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 15:27:45 -0000 --001a113656384861ad04f51f862c Content-Type: text/plain; charset=UTF-8 On Fri, Mar 21, 2014 at 1:15 AM, Harald Alvestrand wrote: > On 03/20/2014 03:52 PM, Dan Wing wrote: > > > On Mar 19, 2014, at 8:21 AM, Harald Alvestrand > wrote: > > On 03/19/2014 04:08 PM, Dan Wing wrote: > > > On Mar 19, 2014, at 12:02 AM, Harald Alvestrand wrote: > > I'd like to be silent on the issue, since which IPv6 addresses to prefer > is likely to be a matter of system policy. Trying to override system policy > in an application specific profile usually leads to sadness. > > > The application needs to indicate if it wants a temporary address. If > the host's policy (or configuration or network) does not support temporary > addresses, the application won't get a temporary address. I don't see why > being silent helps? > > > What API is it using? > > With a little Googling, the system policy I was thinking of was the policy > in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 > rule 7: "Prefer temporary addresses". > > I'm happy to say "it is a good idea for systems to implement the > recommendations of RFC 6724" (or some more 2119-like language). I wouldn't > want to claim that if a system has chosen to prefer non-temporary > addresses, it would have to change its non-conformance to RFC 6724 in order > to be conformant with RTCWEB specifications. > > > So perhaps: > "An RTCWEB implementation SHOULD prefer to use temporary addresses > [RFC4941] where host and network policy permit [RFC6724]." > ? > > Or even be more explicit on what's being proposed: > > "When a client gathers all IPv6 addresses on a host, and both temporary > addresses [RFC4941] and permanent addresses of the same scope are present, > the client SHOULD discard the permanent addresses before forming pairs. > This is consistent with the default policy described in [RFC6724]." > The permanent addresses need to be discarded before sending them to the remote side (which happens before pairing). I would simply say that the permanent addresses should be ignored. > > > Pulling back a little, I am starting to wonder if this is an ICE concern > rather than an RTCWEB concern. The explosion in candidate pairs as more > transport / network options come on line is a real operational problem, and > needs to be solved for all ICE usages. > > I'll stick something in -transport, but RTCWEB is not the only thing that > will have this problem. > > > > > -d > > > > > -d > > > > > > On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing wrote: > >> >> On Mar 18, 2014, at 6:00 PM, Justin Uberti wrote: >> >> https://tools.ietf.org/html/rfc4941 defines the concept of temporary >> IPv6 addresses. For, example, as enumerated on my local system: >> >> inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255 >> inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf >> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf >> *temporary * >> >> As indicated in the RFC, the temporary addresses expire after hours or >> days, and therefore could be used to prevent long-term linkability of >> sessions. Expiration shouldn't be an issue for WebRTC, since we can simply >> do ICE restart if this occurs during a session. >> >> Is this something we want to recommend in the transports doc? >> >> >> Yes. >> >> And it should be as frequent as every new 'call', if IPv6 privacy >> addresses are to provide the same privacy as a NAPT44, as a NAPT44 should >> be assigning random ports per reasons described in RFC6056. >> >> The transport document should also recommend doing port randomization >> (RFC6056), as that was found pretty useful for DNS, but randomizing ports >> is still not popular with many OS's TCP stacks for whatever reason. >> >> -d >> >> >> > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113656384861ad04f51f862c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 21, 2014 at 1:15 AM, Harald Alvestrand <harald@alve= strand.no> wrote:
=20 =20 =20
On 03/20/2014 03:52 PM, Dan Wing wrote:
=20
On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

On 03/19/2014 04:08 PM, Dan Wing wrote:

On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <h= ta@google.com> wrote:

I'd like to be silent on the issue, since which IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness.

The application needs to indicate if it wants a temporary address. If the host's policy (or configuration or network) does not support temporary addresses, the application won't get a temporary address. =C2=A0I don't see why being silent helps?

What API is it using?

With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer=C2=A0= temporary addresses".

I'm happy to say "it is a good idea for systems to imp= lement the recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications.

So perhaps:
=C2=A0 =C2=A0"An RTCWEB implementation SHOULD prefer to u= se temporary addresses [RFC4941] where host and network policy permit [RFC6724]."
?
Or even be more explicit on what's being proposed:

"When a client gathers all IPv6 addresses on a host, and both temporary addresses [RFC4941] and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before forming pairs. This is consistent with the default policy described in [RFC6724]."

The permanent addresses need to be discarded before sending them to the re= mote side (which happens before pairing). I would simply say that the perma= nent addresses should be ignored.


Pulling back a little, I am starting to wonder if this is an ICE concern rather than an RTCWEB concern. The explosion in candidate pairs as more transport / network options come on line is a real operational problem, and needs to be solved for all ICE usages.

I'll stick something in -transport, but RTCWEB is not the only thin= g that will have this problem.




-d




-d





On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing=C2=A0<dwing@cisco.com>=C2=A0wrote:


https://tools.ietf.org/html/rfc49= 41=C2=A0defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system:

inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf=C2=A0<= br> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf=C2=A0temporary=C2=A0

As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session.

Is this something we want to recommend in the transports doc?

Yes.

And it should be as frequent as every new 'call', if IPv6 privacy addresses are t= o provide the same privacy as a NAPT44, as a NAPT44 should be assigning random ports per reasons described in RFC6056.

The transport document should also recommend doing port randomization (RFC6056), as that was found pretty useful for DNS, but randomizing ports is still not popular with many OS's TCP stacks for whatever reason.

-d






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

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



-=
-=20
Surveillance is pervasive. Go Dark.

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


--001a113656384861ad04f51f862c-- From nobody Fri Mar 21 09:07:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACB11A046A for ; Fri, 21 Mar 2014 09:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPk6SYj79XjN for ; Fri, 21 Mar 2014 09:07:44 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 006E51A03FD for ; Fri, 21 Mar 2014 09:07:43 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id to1so2669906ieb.14 for ; Fri, 21 Mar 2014 09:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mwVAhKtHv+kyBVu43E93tOZxCgLaFZoxR9qdY5pyqPk=; b=D85t3aTWqgANpHE+xZO8l1vLht+B0hee6ckP/YCTA/D83fMlvho8MzRgd/DwV7a7qM F3yABpSU8neURcHWx5rU7Mf8Ac7hMjgmqZ//T3KkhL5+7Rrw/jQeTUUcRukdU9YFIh7O /a5EH83JiTxbCgluJHO8SoYiOKbwvVMEvZd04UBjpPQXmR+wkniw0aG/rPjCJILB0cO6 lRCeLjqMUe6pRR8xj1Wly77UHzsFONLvluBfa1FyAaXMiiP3ZuAIi4uJg0TTp1hmPZ+r JIZZ/ReUH5zsdAoX57BGSyZOY9t1369tg+f8iO7H0jRD1BIqKmyylfcVnkU7yDHLlje3 mZug== MIME-Version: 1.0 X-Received: by 10.50.56.109 with SMTP id z13mr3525576igp.6.1395418053611; Fri, 21 Mar 2014 09:07:33 -0700 (PDT) Received: by 10.42.237.206 with HTTP; Fri, 21 Mar 2014 09:07:33 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> Date: Fri, 21 Mar 2014 09:07:33 -0700 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: multipart/alternative; boundary=089e0158aa1266176e04f520159b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nIMSbz6tTbY8tbAyzCkKwMml2uA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 16:07:46 -0000 --089e0158aa1266176e04f520159b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount wrote: > On Thu, Mar 20, 2014 at 8:28 PM, Justin Uberti wrote: > >> >> On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount wrote: >> >>> On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti wrote: >>> >>>> Your take is what I had in mind. Basically a ruleset like this: >>>> >>>> gather_ipv4_addresses(); >>>> if (has_ipv6) { >>>> if (has_temporary_addresses && temporaries_not_forbidden_by_policy) { >>>> gather_temporary_ipv6_addresses(); >>>> } else { >>>> gather_non_temporary_ipv6_addresses(); >>>> } >>>> } >>>> >>>> >>> What should be done when temporary enabled only on some of the network >>> interfaces of the device, i.e. if, for instance, WiFI interface has only >>> non temp ipv6 address and LTE has both temp and permanent address present? >>> >>> >> Is this a real-world problem? As I understand it, temporary addresses are >> assigned by the host, so you either support them or you don't. >> > > On Linux you can enable temporary addresses per interface, so it is > possible. > > The whole problem (with using temp or permanent addresses) is a bit > imaginary since under most common client setups you only see temporary > addresses. Permanent IPv6 addresses show up only on servers or if > specifically configured on the host. > It's actually not imaginary in enterprise contexts, as there are shops that disable temporary addresses to make tracking or other security activities easier. Not my favorite reasoning, personally, but there you go. Ted > _____________ > Roman Shpount > > --089e0158aa1266176e04f520159b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 20, 2014 at 7:39 PM= , Roman Shpount <roman@telurix.com> wrote:
=
On Thu, Mar 20, 2014 at 8= :28 PM, Justin Uberti <juberti@google.com> wrote:

On Thu, Mar 20, 2014 at 4:17 PM, Roman Shpount = <roman@telurix.co= m> wrote:
On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
Your take is what I had in mind. Basicall= y a ruleset like this:

=A0gather_ipv4_addresses();
=A0if (has_ipv6) {=
=A0 if (has_temporary_addresses && temporaries_not_forbi= dden_by_policy) {
=A0 =A0 gather_temporary_ipv6_addresses();
=A0 } else {
=A0 =A0 gather_non_temporary_ipv6_addresses();
=A0}
}=A0

<= br>
What should be done when temporary enabled only on some of the network inte= rfaces of the device, i.e. if, for instance, WiFI interface has only non te= mp ipv6 address and LTE has both temp and permanent address present?

=A0
Is this a real-world problem?= As I understand it, temporary addresses are assigned by the host, so you e= ither support them or you don't.

On Linux you can enable = temporary addresses per interface, so it is possible.

<= div>The whole problem (with using temp or permanent addresses) is a bit ima= ginary since under most common client setups you only see temporary address= es. Permanent IPv6 addresses show up only on servers or if specifically con= figured on the host.

It's actually not imaginary in enter= prise contexts, as there are shops that disable temporary addresses to make= tracking or other security activities easier.=A0 Not my favorite reasoning= , personally, but there you go.

Ted



=A0
_____________
Roman Shpount


--089e0158aa1266176e04f520159b-- From nobody Fri Mar 21 10:10:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5034B1A07A0 for ; Fri, 21 Mar 2014 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3txsOz4vjE1M for ; Fri, 21 Mar 2014 10:10:28 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id CBCB81A0904 for ; Fri, 21 Mar 2014 10:10:25 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so716044wiw.0 for ; Fri, 21 Mar 2014 10:10:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WlbpI0aFRYjap5GcAfZEC55KmzcDFPFYPUWW4IPtDxY=; b=Ier2bV9fqzV6x4Hxas9Pb6cOFM3e60euxA/pwF09K8BkW8GuXi54EfRrKsKwP7Q6n6 BSy98xznuONPWNMO33HnxtwXPGr6ZhCwzTc0IayeguBn+Ci7MOg+MFDD7yxesNX3ZmAI IYA09d+QQwbKw5dJaYrZrCRCFfXOnO6/OPEGsdu17LJWZZk80LXdK9MP6LvaDggqf9bj YAWle3MDhijZ3ei0nGmIMiGhch4/cuoldUMpDnoyyaiQsnOLtl5tJOhnic1VHzZACwW5 yx9BgDFgw2AkkZqsWwyx2Rj/HymIJNUox0Br4BQiNWYHvGZjkrA+7jw7L06gS8lReUFN cBDw== X-Gm-Message-State: ALoCoQmJAp7R3hnDtW7IFTEXQ+44tmy7op6YE27xOCwTZoc62WphhMOzS9yxOC9T3XpVWlVVU1Ey X-Received: by 10.180.164.106 with SMTP id yp10mr3948285wib.48.1395421815745; Fri, 21 Mar 2014 10:10:15 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx.google.com with ESMTPSA id ga20sm6837913wic.0.2014.03.21.10.10.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 10:10:14 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so722721wib.4 for ; Fri, 21 Mar 2014 10:10:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.49 with SMTP id p17mr3972378wiw.4.1395421814602; Fri, 21 Mar 2014 10:10:14 -0700 (PDT) Received: by 10.216.49.137 with HTTP; Fri, 21 Mar 2014 10:10:14 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> Date: Fri, 21 Mar 2014 13:10:14 -0400 Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=f46d043892139242de04f520f539 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ArxjB879m423Ub4c19J6MEfVvBA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 17:10:30 -0000 --f46d043892139242de04f520f539 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie wrote: > On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount wrote: > >> The whole problem (with using temp or permanent addresses) is a bit >> imaginary since under most common client setups you only see temporary >> addresses. Permanent IPv6 addresses show up only on servers or if >> specifically configured on the host. >> > > It's actually not imaginary in enterprise contexts, as there are shops > that disable temporary addresses to make tracking or other security > activities easier. Not my favorite reasoning, personally, but there you go. > What I meant is situation where you have both temp and permanent addresses on the same interface is quite unusual. In most cases it is one or the other. Getting both addresses configured usually requires some very deliberate administrative action, and unless I am mistaken, is not common. _____________ Roman Shpount --f46d043892139242de04f520f539 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie <ted.ietf@gmail.com>= wrote:
On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <roman@telurix.com><= /span> wrote:
The whole problem (with using temp or permanent addresses) is a bit imagina= ry since under most common client setups you only see temporary addresses. = Permanent IPv6 addresses show up only on servers or if specifically configu= red on the host.

It's actually not imaginary in enterprise contex= ts, as there are shops that disable temporary addresses to make tracking or= other security activities easier.=A0 Not my favorite reasoning, personally= , but there you go.

What I meant is s= ituation where you have both temp and permanent addresses on the same inter= face is quite unusual. In most cases it is one or the other. Getting both a= ddresses configured usually requires some very deliberate administrative ac= tion, and unless I am mistaken, is not common.
_____________
Roman Shpount
=A0
--f46d043892139242de04f520f539-- From nobody Fri Mar 21 10:29:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2957C1A0A07 for ; Fri, 21 Mar 2014 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5JhCqqTTHPPu for ; Fri, 21 Mar 2014 10:28:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 149621A046A for ; Fri, 21 Mar 2014 10:28:53 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 17:28:43 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.128]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.134]) with mapi id 15.00.0898.005; Fri, 21 Mar 2014 17:28:43 +0000 From: Dmitry Anipko To: Roman Shpount , Ted Hardie Thread-Topic: [rtcweb] Transports: RFC 4941 support? Thread-Index: AQHPREwi0jHh8qWwMUaGOZ51kT+Nj5rqK/aAgAAJUwCAAD+7AIAAI7UAgAAD5wCAABOuAIAAJLQAgADhu4CAABGDAIAABE3Q Date: Fri, 21 Mar 2014 17:28:42 +0000 Message-ID: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::4] x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(377454003)(189002)(199002)(4396001)(54356001)(33646001)(51856001)(85852003)(85306002)(47976001)(50986001)(54316002)(92566001)(19580395003)(76482001)(49866001)(47736001)(56776001)(53806001)(79102001)(59766001)(81342001)(77982001)(46102001)(63696002)(76796001)(81542001)(83322001)(94316002)(19580405001)(86362001)(93516002)(80976001)(95666003)(86612001)(95416001)(94946001)(76786001)(97186001)(69226001)(93136001)(65816001)(20776003)(80022001)(76576001)(77096001)(74316001)(90146001)(74876001)(16236675002)(56816005)(81816001)(83072002)(74366001)(74502001)(74662001)(31966008)(47446002)(74706001)(81686001)(2656002)(87266001)(87936001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:3CEEF5A0.C3EA7CD.77F07F34.4CE93160.20250; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_adf8e32e91564028bc97623b7dd6e938SN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2cNJRJOXl2exF9l9KXjEBZIiZ-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 17:28:59 -0000 --_000_adf8e32e91564028bc97623b7dd6e938SN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>What I meant is situation where you have both temp and permanent addresse= s on the same interface This is a default for interfaces of Windows computers, using SLAAC. ________________________________ From: rtcweb on behalf of Roman Shpount Sent: Friday, March 21, 2014 10:10 AM To: Ted Hardie Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Transports: RFC 4941 support? On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie > wrote: On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount > wrote: The whole problem (with using temp or permanent addresses) is a bit imagina= ry since under most common client setups you only see temporary addresses. = Permanent IPv6 addresses show up only on servers or if specifically configu= red on the host. It's actually not imaginary in enterprise contexts, as there are shops that= disable temporary addresses to make tracking or other security activities = easier. Not my favorite reasoning, personally, but there you go. What I meant is situation where you have both temp and permanent addresses = on the same interface is quite unusual. In most cases it is one or the othe= r. Getting both addresses configured usually requires some very deliberate = administrative action, and unless I am mistaken, is not common. _____________ Roman Shpount --_000_adf8e32e91564028bc97623b7dd6e938SN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>>What I mean= t is situation where you have both temp and permanent addresses on the same= interface 


This is a default for interfaces of Windows computers, using SLAAC.


From: rtcweb <rtcweb-b= ounces@ietf.org> on behalf of Roman Shpount <roman@telurix.com> Sent: Friday, March 21, 2014 10:10 AM
To: Ted Hardie
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Transports: RFC 4941 support?
 

On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie <ted.ietf@gmail.= com> wrote:
On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <roman@t= elurix.com> wrote:
The whole problem (with using temp or permanent = addresses) is a bit imaginary since under most common client setups you onl= y see temporary addresses. Permanent IPv6 addresses show up only on servers= or if specifically configured on the host.

It's actually not imaginary in = enterprise contexts, as there are shops that disable temporary addresses to= make tracking or other security activities easier.  Not my favorite r= easoning, personally, but there you go.

What I meant is situation where you have both temp and permanent addresses = on the same interface is quite unusual. In most cases it is one or the othe= r. Getting both addresses configured usually requires some very deliberate = administrative action, and unless I am mistaken, is not common.
_____________
Roman Shpount
 
--_000_adf8e32e91564028bc97623b7dd6e938SN2PR03MB077namprd03pro_-- From nobody Fri Mar 21 12:21:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C39B1A07C6 for ; Fri, 21 Mar 2014 12:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKil97OIuHgD for ; Fri, 21 Mar 2014 12:21:20 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6D01A0A15 for ; Fri, 21 Mar 2014 12:21:19 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so817919wib.16 for ; Fri, 21 Mar 2014 12:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o9NvoPl2EbWduyP1ZFbgow9/PIiaaW8kfrQf4ahOAMY=; b=yJCxM/vQS6jptQz4OhqBZt84Rz7NXglnwPPeeUj1Povm8LZRfnyIMhN0RzrR6zDCFW LwMx4Pf/ETCKhVyZHa25vU5SSMBNoAv1IW8g7a99KXUzM6jn8pKnj3EhzUUhEg7vNjMX 9WBBiVxcZ1a537GT4gInGV/v8o2DgSRAqeCPyiISQ9e60jSlfxCuPGs7clzX3OvSIRg8 5nUq/q0Bl3vDLpRgrPKm6dUz4YOcacXArMiKkBJc2JGtgAc35llxLr3GnDkGMv1BKI8I 0Vm1q5olYZczLwDKPZQIp/I9SbNeDVJ+/UjWvAWjrzYkS4kk35BSspZRFP9+ypV1REXW VPOw== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr4580198wib.58.1395429669892; Fri, 21 Mar 2014 12:21:09 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Fri, 21 Mar 2014 12:21:09 -0700 (PDT) In-Reply-To: References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> Date: Fri, 21 Mar 2014 12:21:09 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iEae2fAzMfhwvSPUH1zwwvR2T_s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 21 Mar 2014 19:21:21 -0000 On 21 March 2014 09:07, Ted Hardie wrote: > It's actually not imaginary in enterprise contexts, as there are shops that > disable temporary addresses to make tracking or other security activities > easier. Not my favorite reasoning, personally, but there you go. Yeah, that's what super-cookies are for. From nobody Sat Mar 22 13:23:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEBE1A07B7 for ; Sat, 22 Mar 2014 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 RLykBUwJJ8tv for ; Sat, 22 Mar 2014 13:23:22 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1002E1A07C6 for ; Sat, 22 Mar 2014 13:23:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4D3347C501B for ; Sat, 22 Mar 2014 21:23:19 +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 VT9J16aH5sns for ; Sat, 22 Mar 2014 21:23:17 +0100 (CET) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 924947C5004 for ; Sat, 22 Mar 2014 21:23:17 +0100 (CET) Message-ID: <532DF135.1090509@alvestrand.no> Date: Sat, 22 Mar 2014 21:23:17 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080606060707070906040509" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jAaMBMU-Nv8-wQUPg6kwatvnZOQ Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 22 Mar 2014 20:23:26 -0000 This is a multi-part message in MIME format. --------------080606060707070906040509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/21/2014 06:10 PM, Roman Shpount wrote: > > On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie > wrote: > > On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount > wrote: > > The whole problem (with using temp or permanent addresses) is > a bit imaginary since under most common client setups you only > see temporary addresses. Permanent IPv6 addresses show up only > on servers or if specifically configured on the host. > > > It's actually not imaginary in enterprise contexts, as there are > shops that disable temporary addresses to make tracking or other > security activities easier. Not my favorite reasoning, > personally, but there you go. > > > What I meant is situation where you have both temp and permanent > addresses on the same interface is quite unusual. In most cases it is > one or the other. Getting both addresses configured usually requires > some very deliberate administrative action, and unless I am mistaken, > is not common. I think you are mistaken..... at least, your claim does not fit with my data. This laptop, on a default-configured IPv6 home network: inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global temporary dynamic valid_lft 86356sec preferred_lft 14356sec inet6 2001:470:de0a:27:863a:4bff:fe0b:28b0/64 scope global dynamic valid_lft 86356sec preferred_lft 14356sec Some very deliberate administrative action may have been taken (this is a Google corporate device), but I suspect that it's a default Ubuntu configuration. > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------080606060707070906040509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/21/2014 06:10 PM, Roman Shpount wrote:

On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <roman@telurix.com> wrote:
The whole problem (with using temp or permanent addresses) is a bit imaginary since under most common client setups you only see temporary addresses. Permanent IPv6 addresses show up only on servers or if specifically configured on the host.

It's actually not imaginary in enterprise contexts, as there are shops that disable temporary addresses to make tracking or other security activities easier.  Not my favorite reasoning, personally, but there you go.

What I meant is situation where you have both temp and permanent addresses on the same interface is quite unusual. In most cases it is one or the other. Getting both addresses configured usually requires some very deliberate administrative action, and unless I am mistaken, is not common.

I think you are mistaken..... at least, your claim does not fit with my data.

This laptop, on a default-configured IPv6 home network:

    inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global temporary dynamic
       valid_lft 86356sec preferred_lft 14356sec
    inet6 2001:470:de0a:27:863a:4bff:fe0b:28b0/64 scope global dynamic
       valid_lft 86356sec preferred_lft 14356sec

Some very deliberate administrative action may have been taken (this is a Google corporate device), but I suspect that it's a default Ubuntu configuration.

_____________
Roman Shpount
 


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



-- 
Surveillance is pervasive. Go Dark.
--------------080606060707070906040509-- From nobody Sat Mar 22 14:07:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5D1A0A04 for ; Sat, 22 Mar 2014 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 33I4ucugcpFA for ; Sat, 22 Mar 2014 14:07:12 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id F36FF1A08DB for ; Sat, 22 Mar 2014 14:07:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 139327C5006 for ; Sat, 22 Mar 2014 22:07:11 +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 nuz+cX7PamtA for ; Sat, 22 Mar 2014 22:07:09 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:d014:dc1:dd24:4393] (unknown [IPv6:2001:470:de0a:27:d014:dc1:dd24:4393]) by mork.alvestrand.no (Postfix) with ESMTPSA id A956A7C4FC3 for ; Sat, 22 Mar 2014 22:07:09 +0100 (CET) Message-ID: <532DFB7D.5080504@alvestrand.no> Date: Sat, 22 Mar 2014 22:07:09 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> <532DF135.1090509@alvestrand.no> In-Reply-To: <532DF135.1090509@alvestrand.no> Content-Type: multipart/alternative; boundary="------------070101020007090806080504" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2saBIoLRjCBM5Zne_dmVI81w9KE Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 22 Mar 2014 21:07:17 -0000 This is a multi-part message in MIME format. --------------070101020007090806080504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/22/2014 09:23 PM, Harald Alvestrand wrote: > On 03/21/2014 06:10 PM, Roman Shpount wrote: >> >> On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie > > wrote: >> >> On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount > > wrote: >> >> The whole problem (with using temp or permanent addresses) is >> a bit imaginary since under most common client setups you >> only see temporary addresses. Permanent IPv6 addresses show >> up only on servers or if specifically configured on the host. >> >> >> It's actually not imaginary in enterprise contexts, as there are >> shops that disable temporary addresses to make tracking or other >> security activities easier. Not my favorite reasoning, >> personally, but there you go. >> >> >> What I meant is situation where you have both temp and permanent >> addresses on the same interface is quite unusual. In most cases it is >> one or the other. Getting both addresses configured usually requires >> some very deliberate administrative action, and unless I am mistaken, >> is not common. > > I think you are mistaken..... at least, your claim does not fit with > my data. > > This laptop, on a default-configured IPv6 home network: > > inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global > temporary dynamic > valid_lft 86356sec preferred_lft 14356sec > inet6 2001:470:de0a:27:863a:4bff:fe0b:28b0/64 scope global dynamic > valid_lft 86356sec preferred_lft 14356sec > > Some very deliberate administrative action may have been taken (this > is a Google corporate device), but I suspect that it's a default > Ubuntu configuration. And just to get people used to looking at stuff for themselves, here's my desktop machine, which is DEFINITELY a default Ubuntu setup: hta@liset:~$ ip addr 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 6c:3b:e5:0b:6a:b4 brd ff:ff:ff:ff:ff:ff inet 192.168.1.17/24 brd 192.168.1.255 scope global eth0 inet6 2001:470:de0a:27:d014:dc1:dd24:4393/64 scope global temporary dynamic valid_lft 86379sec preferred_lft 14379sec inet6 2001:470:de0a:27:31d8:d7fc:4af4:c17a/64 scope global temporary deprecated dynamic valid_lft 86379sec preferred_lft 0sec inet6 2001:470:de0a:27:8c26:e950:a09d:814c/64 scope global temporary deprecated dynamic valid_lft 86379sec preferred_lft 0sec inet6 2001:470:de0a:27:d883:fc90:cdcd:6b8f/64 scope global temporary deprecated dynamic valid_lft 86379sec preferred_lft 0sec inet6 2001:470:de0a:27:40c9:8eca:a92b:d0ac/64 scope global temporary deprecated dynamic valid_lft 86379sec preferred_lft 0sec inet6 2001:470:de0a:27:55e8:a88d:df95:df5d/64 scope global temporary deprecated dynamic valid_lft 86379sec preferred_lft 0sec inet6 2001:470:de0a:27:accc:2652:cc97:5b17/64 scope global temporary deprecated dynamic valid_lft 76189sec preferred_lft 0sec inet6 2001:470:de0a:27:6e3b:e5ff:fe0b:6ab4/64 scope global dynamic valid_lft 86379sec preferred_lft 14379sec inet6 fe80::6e3b:e5ff:fe0b:6ab4/64 scope link valid_lft forever preferred_lft forever Ignoring the deprecated ones, one temporary and one non-temporary. --------------070101020007090806080504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/22/2014 09:23 PM, Harald Alvestrand wrote:
On 03/21/2014 06:10 PM, Roman Shpount wrote:

On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <roman@telurix.com> wrote:
The whole problem (with using temp or permanent addresses) is a bit imaginary since under most common client setups you only see temporary addresses. Permanent IPv6 addresses show up only on servers or if specifically configured on the host.

It's actually not imaginary in enterprise contexts, as there are shops that disable temporary addresses to make tracking or other security activities easier.  Not my favorite reasoning, personally, but there you go.

What I meant is situation where you have both temp and permanent addresses on the same interface is quite unusual. In most cases it is one or the other. Getting both addresses configured usually requires some very deliberate administrative action, and unless I am mistaken, is not common.

I think you are mistaken..... at least, your claim does not fit with my data.

This laptop, on a default-configured IPv6 home network:

    inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global temporary dynamic
       valid_lft 86356sec preferred_lft 14356sec
    inet6 2001:470:de0a:27:863a:4bff:fe0b:28b0/64 scope global dynamic
       valid_lft 86356sec preferred_lft 14356sec

Some very deliberate administrative action may have been taken (this is a Google corporate device), but I suspect that it's a default Ubuntu configuration.

And just to get people used to looking at stuff for themselves, here's my desktop machine, which is DEFINITELY a default Ubuntu setup:

hta@liset:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 6c:3b:e5:0b:6a:b4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.17/24 brd 192.168.1.255 scope global eth0
    inet6 2001:470:de0a:27:d014:dc1:dd24:4393/64 scope global temporary dynamic
       valid_lft 86379sec preferred_lft 14379sec
    inet6 2001:470:de0a:27:31d8:d7fc:4af4:c17a/64 scope global temporary deprecated dynamic
       valid_lft 86379sec preferred_lft 0sec
    inet6 2001:470:de0a:27:8c26:e950:a09d:814c/64 scope global temporary deprecated dynamic
       valid_lft 86379sec preferred_lft 0sec
    inet6 2001:470:de0a:27:d883:fc90:cdcd:6b8f/64 scope global temporary deprecated dynamic
       valid_lft 86379sec preferred_lft 0sec
    inet6 2001:470:de0a:27:40c9:8eca:a92b:d0ac/64 scope global temporary deprecated dynamic
       valid_lft 86379sec preferred_lft 0sec
    inet6 2001:470:de0a:27:55e8:a88d:df95:df5d/64 scope global temporary deprecated dynamic
       valid_lft 86379sec preferred_lft 0sec
    inet6 2001:470:de0a:27:accc:2652:cc97:5b17/64 scope global temporary deprecated dynamic
       valid_lft 76189sec preferred_lft 0sec
    inet6 2001:470:de0a:27:6e3b:e5ff:fe0b:6ab4/64 scope global dynamic
       valid_lft 86379sec preferred_lft 14379sec
    inet6 fe80::6e3b:e5ff:fe0b:6ab4/64 scope link
       valid_lft forever preferred_lft forever

Ignoring the deprecated ones, one temporary and one non-temporary.

--------------070101020007090806080504-- From nobody Sat Mar 22 18:39:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9711A092A for ; Sat, 22 Mar 2014 18:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.842 X-Spam-Level: ** X-Spam-Status: No, score=2.842 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 5sfbww2YM1ox for ; Sat, 22 Mar 2014 18:39:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB321A0762 for ; Sat, 22 Mar 2014 18:39:35 -0700 (PDT) Received: from [10.21.74.45] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8EDFC22E255; Sat, 22 Mar 2014 21:39:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Cullen Jennings In-Reply-To: <532BF5F4.90901@ericsson.com> Date: Sat, 22 Mar 2014 12:39:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2ED6AAC7-5D6F-48C1-BCAE-EA161C6BC0CF@iii.ca> References: <531DE104.2010908@ericsson.com> <532AC890.7000602@ericsson.com> <532BF5F4.90901@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BHkqb3_gYAKq53kACyGL0fDin84 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On ptimes and maxptimes 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, 23 Mar 2014 01:39:37 -0000 On Mar 21, 2014, at 2:19 AM, Magnus Westerlund = wrote: > On 2014-03-20 17:39, Justin Uberti wrote: >>=20 >>=20 >>=20 >> On Thu, Mar 20, 2014 at 3:53 AM, Magnus Westerlund >> > >> wrote: >>=20 >> On 2014-03-20 01:27, Justin Uberti wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Mar 10, 2014 at 8:57 AM, Magnus Westerlund >>> > >> > >> >>> wrote: >>>=20 >>> Hi, >>>=20 >>> (As individual) >>>=20 >>> On 2014-03-05 17:26, Justin Uberti wrote: >>>> =46rom the session this morning, I recall this consensus: >>>>=20 >>>> * We will add recommendations on the frame sizes to use for >>> PCMU/A to >>>> the rtcweb audio codec I-D (20, 30, 60 ms frames). >>>=20 >>> The above applies to sending payloads >>>=20 >>>=20 >>> Right, thanks for pointing that out. >>>=20 >>>=20 >>> Yes, but that was given that a receiver will be capable of >> receiving any >>> valid number of frames, or samples within a reasonable >> packetization, >>> and I think that should be 120 ms. >>>=20 >>>> * We will consider adding an a=3Dmaxptime attribute that >>> represents the >>>> "minimum maxptime" of all the offered codecs. That is, >> if both >>> Opus >>>> (maxptime of 120ms) and PCMU (maxptime of 60) are offered, a >>>> maxptime=3D60 SHOULD be included. >>>> o Since maxptime spans all codecs, this means that >> some modes >>>> (e.g. Opus 120ms) will be unavailable, unless only >> Opus is >>> offered. >>>=20 >>> I think you base the assumption on maxptime based on the sending >>> recommendations, not what is capable of receiving. If one is >> capable of >>> receiving 200 ms of a-law and Opus, then you would need to say >> 120 ms as >>> Opus will limit you. >>>=20 >>>=20 >>> I agree that Opus' maxptime is 120, but should that prevent >> sending PCMU >>> with 200 ms? That is, since sending Opus with 200 ms is not legal, = is >>> there any point in forcing WebRTC impls to indicate this in SDP? >>=20 >> What I wished we fixed this issue with maxptime a long time ago. = This is >> a well known problem that it really has PT scope, but are = signalled on >> m=3D line scope. >>=20 >>>=20 >>>=20 >>>=20 >>>> * We will consider adding an a=3Dptime attribute, set to the >>> receiver's >>>> preferred frame size to receive. Again, this value spans all >>> codecs, >>>> so the specified value may not be viable for all codecs >> (e.g. >>> 30 ms >>>> works for PCMU but not for Opus) >>>>=20 >>>> After thinking about this some, I'm not sure the >> maxptime/ptime values >>>> will lead to any different behavior than if they were not >> specified. >>>> Since there is a complexity cost (especially if the values >> need to >>>> change based on which codecs are offered), is there a clear >> upside >>> here? >>>=20 >>> The maxptime values may in some cases be limited downwards for >>> interoperability, for example if one like to gateway AMR into a = CS >>> network then the gateway might indicate a maxptime that is >> less, more >>> like 20 or 40 ms. >>>=20 >>>=20 >>> Sure - WebRTC impls need to respect any maxptime value that they >>> receive, but it's not clear to me that they need to include one in = the >>> SDP they send. >>=20 >> Ok, but then we are back to my previous argument for writing down = what >> receiver requirement in regards to each payload type one is = required to >> support in the audio draft for the ones specified there. But what = about >> the other codecs that aren't included in the audio draft? >>=20 >> How can a peer know if there are limitations? I wouldn't attempt = to >> solve the general problem of the scope issue with maxptime. Simply = state >> that you should include this. It is going to be limited but still >> provide information in many cases that is quite useful for the = sender. >>=20 >>=20 >> Just to be sure I understand, your position is that WebRTC impls = SHOULD >> include an a=3Dmaxptime attribute indicating the "minimum maximum" = frame >> size they can receive, across all codecs? >=20 > Yes, as long as we lack payload type specific, I think that is the = best > we can do. >>=20 >> Do you think anything needs to be included regarding a=3Dptime? >=20 > I think it MAY be included to indicate an initial preference for > packetization interval. In cases that is not common across the set of > payload types for that m=3D section, then one should skip it. >=20 > Cheers >=20 > Magnus Westerlund It seems like from interoperability point of view, we also need, if a = browser receives a maxptime or prime, it MUST be able to understand = that.=20 From nobody Sat Mar 22 18:46:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4D1A08C5 for ; Sat, 22 Mar 2014 18:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 2UnMduLyXu5k for ; Sat, 22 Mar 2014 18:46:37 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0F1A0762 for ; Sat, 22 Mar 2014 18:46:37 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so2570719wes.9 for ; Sat, 22 Mar 2014 18:46:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fa/gngma2xPkACT5+VSMb1EESvuIgXbGtl1hGEdDBvY=; b=AQHlUJ0CVMpCk4hO3Uo/7ULGXncd4Nq0c/gVCnwRr7edJC8eMuXan5SxTqJVb67gJI mIue/7+3vlfgtajd9aBNQiRgNRcs+zYQNXnKRF+csFEQ/OJPsAJZ6KMKZ9w9+qSgEUeV QJquym1IhDxtZAsfHs72ijdPiOZQgMmb6NwS3/ehNjuEsEJxo+wwlrtr1inLqWIpCuHV 9XId5SAahhihXEiltYOzo0R/0qbWaJNHxdIkYfIQ81JLbUNHJbPAL/zMScqYtwW+V4co KMnj9y258Gh+Yv2vz1RodY/M03LiAjy9xXkTt/AAbF1iecUQ3SVAvw6Nj6cmJpg1v3lV WXcA== X-Gm-Message-State: ALoCoQlqFzMMAEQeqix/4RUHGJFh5uOjHvIG0qUKflwi/1BvSWhMXJ8op3hWxWWArDK0Xu8ShsVd X-Received: by 10.180.185.197 with SMTP id fe5mr6545237wic.56.1395539196600; Sat, 22 Mar 2014 18:46:36 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by mx.google.com with ESMTPSA id t5sm21535470wjw.15.2014.03.22.18.46.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Mar 2014 18:46:34 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so2512953wes.6 for ; Sat, 22 Mar 2014 18:46:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.164.107 with SMTP id yp11mr6188873wib.37.1395539194535; Sat, 22 Mar 2014 18:46:34 -0700 (PDT) Received: by 10.216.49.137 with HTTP; Sat, 22 Mar 2014 18:46:34 -0700 (PDT) In-Reply-To: <532DFB7D.5080504@alvestrand.no> References: <5329B617.2070001@alvestrand.no> <17885A74-50A3-49E3-8C54-E53C55019C73@cisco.com> <444DE75E-BF07-4C6F-91B1-CF57DC67FBA3@cisco.com> <532DF135.1090509@alvestrand.no> <532DFB7D.5080504@alvestrand.no> Date: Sat, 22 Mar 2014 21:46:34 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=90e6ba309486f5ec9e04f53c4916 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aP4Zjes4hYVQesWjy0tE55U_H68 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transports: RFC 4941 support? 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, 23 Mar 2014 01:46:41 -0000 --90e6ba309486f5ec9e04f53c4916 Content-Type: text/plain; charset=ISO-8859-1 I was incorrect. It is normal to get both temp and permanent IPv6 addresses on Windows and Ubuntu. _____________ Roman Shpount On Sat, Mar 22, 2014 at 5:07 PM, Harald Alvestrand wrote: > On 03/22/2014 09:23 PM, Harald Alvestrand wrote: > > On 03/21/2014 06:10 PM, Roman Shpount wrote: > > > On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie wrote: > >> On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount wrote: >> >>> The whole problem (with using temp or permanent addresses) is a bit >>> imaginary since under most common client setups you only see temporary >>> addresses. Permanent IPv6 addresses show up only on servers or if >>> specifically configured on the host. >>> >> >> It's actually not imaginary in enterprise contexts, as there are shops >> that disable temporary addresses to make tracking or other security >> activities easier. Not my favorite reasoning, personally, but there you go. >> > > What I meant is situation where you have both temp and permanent > addresses on the same interface is quite unusual. In most cases it is one > or the other. Getting both addresses configured usually requires some very > deliberate administrative action, and unless I am mistaken, is not common. > > > I think you are mistaken..... at least, your claim does not fit with my > data. > > This laptop, on a default-configured IPv6 home network: > > inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global temporary > dynamic > valid_lft 86356sec preferred_lft 14356sec > inet6 2001:470:de0a:27:863a:4bff:fe0b:28b0/64 scope global dynamic > valid_lft 86356sec preferred_lft 14356sec > > Some very deliberate administrative action may have been taken (this is a > Google corporate device), but I suspect that it's a default Ubuntu > configuration. > > > And just to get people used to looking at stuff for themselves, here's my > desktop machine, which is DEFINITELY a default Ubuntu setup: > > hta@liset:~$ ip addr > 1: lo: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast state > UP qlen 1000 > link/ether 6c:3b:e5:0b:6a:b4 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.17/24 brd 192.168.1.255 scope global eth0 > inet6 2001:470:de0a:27:d014:dc1:dd24:4393/64 scope global temporary > dynamic > valid_lft 86379sec preferred_lft 14379sec > inet6 2001:470:de0a:27:31d8:d7fc:4af4:c17a/64 scope global temporary > deprecated dynamic > valid_lft 86379sec preferred_lft 0sec > inet6 2001:470:de0a:27:8c26:e950:a09d:814c/64 scope global temporary > deprecated dynamic > valid_lft 86379sec preferred_lft 0sec > inet6 2001:470:de0a:27:d883:fc90:cdcd:6b8f/64 scope global temporary > deprecated dynamic > valid_lft 86379sec preferred_lft 0sec > inet6 2001:470:de0a:27:40c9:8eca:a92b:d0ac/64 scope global temporary > deprecated dynamic > valid_lft 86379sec preferred_lft 0sec > inet6 2001:470:de0a:27:55e8:a88d:df95:df5d/64 scope global temporary > deprecated dynamic > valid_lft 86379sec preferred_lft 0sec > inet6 2001:470:de0a:27:accc:2652:cc97:5b17/64 scope global temporary > deprecated dynamic > valid_lft 76189sec preferred_lft 0sec > inet6 2001:470:de0a:27:6e3b:e5ff:fe0b:6ab4/64 scope global dynamic > valid_lft 86379sec preferred_lft 14379sec > inet6 fe80::6e3b:e5ff:fe0b:6ab4/64 scope link > valid_lft forever preferred_lft forever > > Ignoring the deprecated ones, one temporary and one non-temporary. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --90e6ba309486f5ec9e04f53c4916 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was incorrect. It is normal to get both temp and permane= nt IPv6 addresses on Windows and Ubuntu.
_____________
Roman Shpount


On Sat, Mar 22, 2014 at 5:07 PM, Harald = Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 03/22/2014 09:23 PM, Harald Alvestrand wrote:
=20
On 03/21/2014 06:10 PM, Roman Shpount wrote:

On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <roman@telurix.com> wrote:
The whole problem (with using temp or permanent addresses) is a bit imaginary since under most common client setups you only see temporary addresses. Permanent IPv6 addresses show up only on servers or if specifically configured on the host.

It's actually not imaginary in enterprise contexts, as there are shops that disable temporary addresses to make tracking or other security activities easier.=A0 Not my favorite reasoning, personally, but there you go.

What I meant is situation where you have both temp and permanent addresses on the same interface is quite unusual. In most cases it is one or the other. Getting both addresses configured usually requires some very deliberate administrative action, and unless I am mistaken, is not common.

I think you are mistaken..... at least, your claim does not fit with my data.

This laptop, on a default-configured IPv6 home network:

=A0=A0=A0 inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global temporary dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86356sec preferred_lft 14356sec
=A0=A0=A0 inet6 2001:470:de0a:27:863a:4bff:fe0b:28b0/64 scope global dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86356sec preferred_lft 14356sec

Some very deliberate administrative action may have been taken (this is a Google corporate device), but I suspect that it's a default Ubuntu configuration.

And just to get people used to looking at stuff for themselves, here's my desktop machine, which is DEFINITELY a default Ubuntu setup:

hta@liset:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
=A0=A0=A0 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
=A0=A0=A0 inet 127.0.0= .1/8 scope host lo
=A0=A0=A0 inet6 ::1/128 scope host
=A0=A0=A0=A0=A0=A0 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
=A0=A0=A0 link/ether 6c:3b:e5:0b:6a:b4 brd ff:ff:ff:ff:ff:ff
=A0=A0=A0 inet 192= .168.1.17/24 brd 192.168.1.255 scope global eth0
=A0=A0=A0 inet6 2001:470:de0a:27:d014:dc1:dd24:4393/64 scope global temporary dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86379sec preferred_lft 14379sec
=A0=A0=A0 inet6 2001:470:de0a:27:31d8:d7fc:4af4:c17a/64 scope global temporary deprecated dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86379sec preferred_lft 0sec
=A0=A0=A0 inet6 2001:470:de0a:27:8c26:e950:a09d:814c/64 scope global temporary deprecated dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86379sec preferred_lft 0sec
=A0=A0=A0 inet6 2001:470:de0a:27:d883:fc90:cdcd:6b8f/64 scope global temporary deprecated dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86379sec preferred_lft 0sec
=A0=A0=A0 inet6 2001:470:de0a:27:40c9:8eca:a92b:d0ac/64 scope global temporary deprecated dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86379sec preferred_lft 0sec
=A0=A0=A0 inet6 2001:470:de0a:27:55e8:a88d:df95:df5d/64 scope global temporary deprecated dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86379sec preferred_lft 0sec
=A0=A0=A0 inet6 2001:470:de0a:27:accc:2652:cc97:5b17/64 scope global temporary deprecated dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 76189sec preferred_lft 0sec
=A0=A0=A0 inet6 2001:470:de0a:27:6e3b:e5ff:fe0b:6ab4/64 scope global dynamic
=A0=A0=A0=A0=A0=A0 valid_lft 86379sec preferred_lft 14379sec
=A0=A0=A0 inet6 fe80::6e3b:e5ff:fe0b:6ab4/64 scope link
=A0=A0=A0=A0=A0=A0 valid_lft forever preferred_lft forever

Ignoring the deprecated ones, one temporary and one non-temporary.


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


--90e6ba309486f5ec9e04f53c4916-- From nobody Sat Mar 22 23:12:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799301A6F2E for ; Sat, 22 Mar 2014 23:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 aCuMJ8Rkt_z9 for ; Sat, 22 Mar 2014 23:12:29 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 25EBA1A6F2D for ; Sat, 22 Mar 2014 23:12:28 -0700 (PDT) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1976 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WRbe0-0001Mn-EV for rtcweb@ietf.org; Sun, 23 Mar 2014 01:12:28 -0500 Message-ID: <532E7B47.8060202@jesup.org> Date: Sun, 23 Mar 2014 02:12:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <531DE104.2010908@ericsson.com> <532AC890.7000602@ericsson.com> <532BF5F4.90901@ericsson.com> <2ED6AAC7-5D6F-48C1-BCAE-EA161C6BC0CF@iii.ca> In-Reply-To: <2ED6AAC7-5D6F-48C1-BCAE-EA161C6BC0CF@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j0JeOJ6EqpaCN_6IkKiCZqMnjwQ Subject: Re: [rtcweb] On ptimes and maxptimes 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, 23 Mar 2014 06:12:31 -0000 On 3/22/2014 2:39 PM, Cullen Jennings wrote: > It seems like from interoperability point of view, we also need, if a > browser receives a maxptime or prime, it MUST be able to understand that. maxptime - yes, MUST ptime - since it's merely a preference, it's not a MUST understand. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Sun Mar 23 19:13:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8456A1A00B1; Sun, 23 Mar 2014 19:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU692pgPY0ak; Sun, 23 Mar 2014 19:13:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2751A00AA; Sun, 23 Mar 2014 19:13:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140324021345.31096.29948.idtracker@ietfa.amsl.com> Date: Sun, 23 Mar 2014 19:13:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NWtxDB0rCZ4AKloi1ZZx7tW2_Nw Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-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: Mon, 24 Mar 2014 02:13:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Filename : draft-ietf-rtcweb-stun-consent-freshness-01.txt Pages : 7 Date : 2014-03-23 Abstract: Verification of peer consent before sending traffic is necessary in WebRTC deployments to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. A related problem is session liveness. WebRTC application may want to detect connection failure and take appropriate action. This document describes how a WebRTC browser can verify peer consent to continue sending traffic and detect connection failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-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 Sun Mar 23 19:17:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4921A00B0 for ; Sun, 23 Mar 2014 19:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 9XLu3Ym4q_OC for ; Sun, 23 Mar 2014 19:17:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B23DA1A00AA for ; Sun, 23 Mar 2014 19:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2698; q=dns/txt; s=iport; t=1395627434; x=1396837034; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8IJGsSU4dl1NQlSfrDufrUyGfO+QkVusRfKG2Ejcpfg=; b=GwxdE5drfDnFrXV6aokFiYnvagmc4pKlBVz/6csTLkIVaaTJ9iDxpSTF UMA5DDkpTo4ifeCLSAlwCjHZRZJCeoWkaBAFq2XhLScPm5KJFXcL6BgAO 0QmJmNERQFeIAU5jup6EwNjYHoe5vnIF46pg7gxk4QmQlWVkUJDr/wUKE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwFADSVL1OtJXHA/2dsb2JhbABZgwY7UQaDB79qGXgWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBCAgCBBMIAYdwCAWrOaFvF4EpjSA4BoJpNYEUBJl8kH+Bb4E+gis X-IronPort-AV: E=Sophos;i="4.97,717,1389744000"; d="scan'208";a="312133678" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 24 Mar 2014 02:17:14 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2O2HDlw027674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 02:17:13 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.166]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 23 Mar 2014 21:17:13 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-ietf-rtcweb-stun-consent-freshness-01.txt Thread-Index: AQHPRwa2vIYR3llUgEyGbYR9f83oiZrvf+JA Date: Mon, 24 Mar 2014 02:17:12 +0000 Message-ID: References: <20140324021346.31096.93474.idtracker@ietfa.amsl.com> In-Reply-To: <20140324021346.31096.93474.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.49.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NwNx-_iQa6GUkLCczInmN2Rbo_Q Subject: Re: [rtcweb] New Version Notification for draft-ietf-rtcweb-stun-consent-freshness-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: Mon, 24 Mar 2014 02:17:17 -0000 VGhpcyBpcyBqdXN0IGEga2VlcGFsaXZlIHZlcnNpb24gd2hpbGUgd2UgYXJlIHdvcmtpbmcgb24g dXBkYXRpbmcgdGhlIGRyYWZ0IGJhc2VkIG9uIFdHIGRpc2N1c3Npb25zLi4NCg0KTXV0aHUNCg0K fC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQp8RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KfFNlbnQ6IE1vbmRheSwgTWFy Y2ggMjQsIDIwMTQgNzo0NCBBTQ0KfFRvOiBSYW0gTW9oYW4gUiAocm1vaGFucik7IFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSk7IERhbiBXaW5nIChkd2luZyk7IFRpcnVtYWxlc3dhciBSZWRk eQ0KfCh0aXJlZGR5KTsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk7IFJhbSBN b2hhbiBSIChybW9oYW5yKTsgRGFuIFdpbmcgKGR3aW5nKTsgTXV0aHUgQXJ1bA0KfE1vemhpIFBl cnVtYWwgKG1wZXJ1bWFsKQ0KfFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0wMS50eHQNCnwNCnwNCnxB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNo bmVzcy0wMS50eHQNCnxoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE11dGh1IEFy dWwgTW96aGkgUGVydW1hbCBhbmQgcG9zdGVkIHRvIHRoZQ0KfElFVEYgcmVwb3NpdG9yeS4NCnwN CnxOYW1lOgkJZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcw0KfFJldmlz aW9uOgkwMQ0KfFRpdGxlOgkJU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MNCnxEb2N1 bWVudCBkYXRlOgkyMDE0LTAzLTI0DQp8R3JvdXA6CQlydGN3ZWINCnxQYWdlczoJCTcNCnxVUkw6 ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0wMS50eHQNCnxTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1j b25zZW50LWZyZXNobmVzcy8NCnxIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0wMQ0KfERpZmY6 ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ0 Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTAxDQp8DQp8QWJzdHJhY3Q6DQp8ICAgVmVyaWZp Y2F0aW9uIG9mIHBlZXIgY29uc2VudCBiZWZvcmUgc2VuZGluZyB0cmFmZmljIGlzIG5lY2Vzc2Fy eSBpbg0KfCAgIFdlYlJUQyBkZXBsb3ltZW50cyB0byBlbnN1cmUgdGhhdCBhIG1hbGljaW91cyBK YXZhU2NyaXB0IGNhbm5vdCB1c2UNCnwgICB0aGUgYnJvd3NlciBhcyBhIHBsYXRmb3JtIGZvciBs YXVuY2hpbmcgYXR0YWNrcy4gIEEgcmVsYXRlZCBwcm9ibGVtDQp8ICAgaXMgc2Vzc2lvbiBsaXZl bmVzcy4gIFdlYlJUQyBhcHBsaWNhdGlvbiBtYXkgd2FudCB0byBkZXRlY3QNCnwgICBjb25uZWN0 aW9uIGZhaWx1cmUgYW5kIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9uLg0KfA0KfCAgIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGhvdyBhIFdlYlJUQyBicm93c2VyIGNhbiB2ZXJpZnkgcGVlciBjb25z ZW50DQp8ICAgdG8gY29udGludWUgc2VuZGluZyB0cmFmZmljIGFuZCBkZXRlY3QgY29ubmVjdGlv biBmYWlsdXJlLg0KfA0KfA0KfA0KfA0KfFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnx1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KfA0KfFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Mar 25 08:18:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560081A016D for ; Tue, 25 Mar 2014 08:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 GOTcb1wrbklN for ; Tue, 25 Mar 2014 08:17:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id EF95B1A00D9 for ; Tue, 25 Mar 2014 08:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=532; q=dns/txt; s=iport; t=1395760676; x=1396970276; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=w9I6kCyZ//4Tec28k5YEi443pPFc2St4eGvQac/jilY=; b=VxTGFJ9jL/kmALcr9Cey2Nkd3pPXIyXwm6qOpZuEEllMjWGLGjeIFjMm +NkTRLgtAyaVVvl+kg0op0i4KFdWCWICM4tqKFbA7nIpPw6UCZPYakASx wEsHLOYjngUvQ0YvAJj+tyQpayu3z+Jk17h8l0Uj4wEuT/poI688Zwrp0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALqdMVOtJV2b/2dsb2JhbABZgwaBEsQHFnSCLDpRAT4FPScEiAydabFdF5MtBJhNkjKBcIE+gis X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208";a="30209717" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 25 Mar 2014 15:17:55 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2PFHtY4012484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Mar 2014 15:17:55 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 10:17:55 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) Thread-Index: AQHPSD1l4RRh4jrUD02G0QWRQAr7eA== Date: Tue, 25 Mar 2014 15:17:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.39.91] Content-Type: text/plain; charset="us-ascii" Content-ID: <98EDFB73AFC93A428C5EB1324BEDA024@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ESf2maPAAGAF15j5QvPCoFyEbgw Subject: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 25 Mar 2014 15:17:58 -0000 Hi all, Certain media streams(For example audio, video) may require multiple components (RTP, RTCP) each of which has to work for the media stream as a whole to work. If consent fails for one of the component then the application(JS) may decide to cease transmission of that media stream. Is there a need to describe some text (RECOMMENDATION) on how fate-sharing connections need to be handled when consent fails for one of the components in Consent draft ? Or should this be left out of this draft ? Regards, Ram From nobody Tue Mar 25 09:25:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B058D1A01BA for ; Tue, 25 Mar 2014 09:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BNTUvgLQECZ for ; Tue, 25 Mar 2014 09:25:08 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D80121A019F for ; Tue, 25 Mar 2014 09:25:07 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so634014ier.13 for ; Tue, 25 Mar 2014 09:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UdJOH+GFqcF0o1FQq1EhwJ6NRFze0Jf1F9VMh+Gcjkc=; b=cR68KzqSuS52VEpIjJX8M/vhoEPlUM+kZNCwO2OOYOBGhlib5mg9DOm6MTEakdYDPh dKzAchZkcsSi1HFFxCQR8YTKKrlGWmNmImGSs1Iysx+Gpf4ospZ9MoWPXgdj5A8ZvSow +y/+uqPuD6+RjpZ3MYcMUkXZ6xCurGhpdHS7svp76Cif2Pnp6vxn7qSZ2TiSN1PQGo7u mauY/bRAKaXhkaSPlZ2lVXb7wpyQfmiDHnlLggtzksG7H01b2PoKHZ22vnT0vC0WxlT5 CrCsTDluHn8Rb1Mo/90zliyTTm1koxGSO05sYM18RGtOi0Sb/yDnw1F15KU/aa7CB5Ok LwOg== MIME-Version: 1.0 X-Received: by 10.50.136.168 with SMTP id qb8mr18614579igb.13.1395764706728; Tue, 25 Mar 2014 09:25:06 -0700 (PDT) Received: by 10.42.237.206 with HTTP; Tue, 25 Mar 2014 09:25:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Mar 2014 09:25:06 -0700 Message-ID: From: Ted Hardie To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=089e0149495e88e05504f570cb12 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d3ShrAY0fwrzQSfqigpD2lDphuw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 25 Mar 2014 16:25:09 -0000 --089e0149495e88e05504f570cb12 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 25, 2014 at 8:17 AM, Ram Mohan R (rmohanr) wrote: > Hi all, > > Certain media streams(For example audio, video) may require multiple > components (RTP, RTCP) each of which has to work for the media stream as a > whole to work. If consent fails for one of the component then the > application(JS) may decide to cease transmission of that media stream. > > Is there a need to describe some text (RECOMMENDATION) on how fate-sharing > connections need to be handled when consent fails for one of the > components in Consent draft ? > Or should this be left out of this draft ? > > So, it's my understanding that the application may always decide to cease transmission of a media stream even when it has consent to continue, so I'm not sure what language you are looking for here. Can you be a bit more direct on which section would need this recommendation and what it might say? Ted > Regards, > Ram > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0149495e88e05504f570cb12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 25, 2014 at 8:17 AM= , Ram Mohan R (rmohanr) <rmohanr@cisco.com> wrote:
Hi all,

Certain media streams(For example audio, video) may require multiple
components (RTP, RTCP) each of which has to work for the media stream as a<= br> whole to work. If consent fails for one of the component then the
application(JS) may decide to cease transmission of that media stream.

Is there a need to describe some text (RECOMMENDATION) on how fate-sharing<= br> connections need to be handled when consent fails for one of the
components in Consent draft ?
Or should this be left out of this draft ?


So, it's my understanding that the application may alwa= ys decide to cease transmission of a media stream even=A0 when it has conse= nt to continue, so I'm not sure what language you are looking for here.= =A0 Can you be a bit more direct on which section would need this recommend= ation and what it might say?

Ted



=A0
Regards,
Ram

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

--089e0149495e88e05504f570cb12-- From nobody Tue Mar 25 17:17:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B89A1A021E for ; Tue, 25 Mar 2014 17:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 6MTIY9cRxV8M for ; Tue, 25 Mar 2014 17:17:20 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B37B71A0010 for ; Tue, 25 Mar 2014 17:17:20 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 10so3312992ykt.4 for ; Tue, 25 Mar 2014 17:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KkQXfnz9HMDzlpXuuvFG676hJRrncNT5fFRKx1IC9l0=; b=Laz7j/pILxHZRYc/SYWJrTWdebBfiK3lQATXjOMT4SnFeYfWXHJHXgA7A4IESGGatA IfnRawPnJidw2G0TYc3/Ug41vHRcqfY2TQwuLhLSiC2gDfDm3q+DJn9nt+AIEjFGFfmk 6YOZGuaXq/E3Z7GnmCwr+xBbAtQGedtrfSwIIaSSlSLy2UDFTQV7g+cE0rOTDyqGLDqG jpk8sR4ZSxFfty7HxJwZHEkJLw6Gpg5N5hEwSzuiQIdeWHXSdUIOcjo0B+A1NX9meVBo OaSf7vf+U0XvvsTOIAsI1/tZNOmQj6IiTQVfzBzO1M2jP6djDC4U4lhnbXif8GwzZe/v cVIw== X-Received: by 10.236.84.107 with SMTP id r71mr6727709yhe.108.1395793039361; Tue, 25 Mar 2014 17:17:19 -0700 (PDT) Received: from [192.168.1.130] (c-76-108-76-219.hsd1.fl.comcast.net. [76.108.76.219]) by mx.google.com with ESMTPSA id q66sm31189092yhj.44.2014.03.25.17.17.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 17:17:17 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-74C2D763-65C8-4204-A27B-6865BB98D951 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (11D167) In-Reply-To: Date: Tue, 25 Mar 2014 20:17:16 -0400 Content-Transfer-Encoding: 7bit Message-Id: <04A50A41-B9FC-49AE-8AC4-4DD292C66B45@gmail.com> References: To: Ted Hardie Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ye6ZF4bg-ucDX4VCLJOI0HheEjw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 26 Mar 2014 00:17:22 -0000 --Apple-Mail-74C2D763-65C8-4204-A27B-6865BB98D951 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Where RTP and RTCP are multiplexed on the same port, they also share the sam= e fate with respect to ICE consent; similarly, when audio/video/data channel= are multiplexed, they also share consent fate. Where audio and video use di= fferent ports, the fates will not be shared, and it is possible that consent= might be given to one and not the other, but it is probably best left up to= the application to decide how to react. The one case which might be deservi= ng of a recommendation is where RTP and RTCP aren't multiplexed and consent i= s given to one of RTP/RTCP but not the other. > So, it's my understanding that the application may always decide to cease t= ransmission of a media stream even when it has consent to continue, so I'm n= ot sure what language you are looking for here. Can you be a bit more direc= t on which section would need this recommendation and what it might say? >=20 > Ted --Apple-Mail-74C2D763-65C8-4204-A27B-6865BB98D951 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Where RTP and RTCP are multiplexed on t= he same port, they also share the same fate with respect to ICE consent; sim= ilarly, when audio/video/data channel are multiplexed, they also share conse= nt fate. Where audio and video use different ports, the fates will not be sh= ared, and it is possible that consent might be given to one and not the othe= r, but it is probably best left up to the application to decide how to react= . The one case which might be deserving of a recommendation is where RTP and= RTCP aren't multiplexed and consent is given to one of RTP/RTCP but not the= other.


So, it's my understandin= g that the application may always decide to cease transmission of a media st= ream even  when it has consent to continue, so I'm not sure what langua= ge you are looking for here.  Can you be a bit more direct on which sec= tion would need this recommendation and what it might say?

Ted
= --Apple-Mail-74C2D763-65C8-4204-A27B-6865BB98D951-- From nobody Tue Mar 25 18:21:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57081A0012 for ; Tue, 25 Mar 2014 18:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 db8XAne6o_WE for ; Tue, 25 Mar 2014 18:20:53 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5534B1A0028 for ; Tue, 25 Mar 2014 18:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3498; q=dns/txt; s=iport; t=1395796852; x=1397006452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dqAY8n1+iNJtkdDljAksq1apQiMG2NNZjHHy+D8n4tw=; b=hMbtWOjRWTYpB2jXNTpqkOgG+GSf/A7otVNFHKAAqluThavZRRSIa0RP r2ZpLmJb3ZnZl0SgJP975Nlc92ulEnPpqXOXpY36f8I0szrt79ewUsHtp bl9aT9EeA65/KhyoZSwm4JuloBm1Zy+kie3NJ+CAlwkrhsxofKr2WRbuz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAEwqMlOtJXG//2dsb2JhbABZgwY7V4MLuDqGZFEZgQEWdIIlAQEBBAEBATE6CxACAQgRAwECAQQfCQICHwYLHQgCBA4Fh2UDEQ2RG5wPBpp6DYcdEwSBI4svghwHgmmBTwSWYIFtjGiFSoFwgT6CKw X-IronPort-AV: E=Sophos;i="4.97,732,1389744000"; d="scan'208";a="30369441" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 26 Mar 2014 01:20:52 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2Q1KpKK013263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 01:20:51 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 20:20:51 -0500 From: "Ram Mohan R (rmohanr)" To: Ted Hardie Thread-Topic: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) Thread-Index: AQHPSI8P90WltZATOUOmDZUyqJuWB5rzQiMA Date: Wed, 26 Mar 2014 01:20:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.39.91] Content-Type: text/plain; charset="euc-kr" Content-ID: <12274E00366C9E4D8276D2E69F52BA13@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fcYJDi0znyK0vkqigDYnZnHg83c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 26 Mar 2014 01:20:58 -0000 UGxlYXNlIHNlZSBpbmxpbmUNCg0KDQo+DQo+DQo+RnJvbTogIFRlZCBIYXJkaWUgPHRlZC5pZXRm QGdtYWlsLmNvbT4NCj5EYXRlOiAgVHVlc2RheSwgMjUgTWFyY2ggMjAxNCA5OjU1IHBtDQo+VG86 ICBSYW0gTW9oYW4gUmF2aW5kcmFuYXRoIDxybW9oYW5yQGNpc2NvLmNvbT4NCj5DYzogICJydGN3 ZWJAaWV0Zi5vcmciIDxydGN3ZWJAaWV0Zi5vcmc+DQo+U3ViamVjdDogIFJlOiBbcnRjd2ViXSBD b25zZW50IGZvciBmYXRlLXNoYXJpbmcgY29ubmVjdGlvbnMgKERvIHdlIG5lZWQNCj50ZXh0IGlu IGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MgPykNCj4NCj4NCj5PbiBU dWUsIE1hciAyNSwgMjAxNCBhdCA4OjE3IEFNLCBSYW0gTW9oYW4gUiAocm1vaGFucikNCj48cm1v aGFuckBjaXNjby5jb20+IHdyb3RlOg0KPg0KPkhpIGFsbCwNCj4NCj5DZXJ0YWluIG1lZGlhIHN0 cmVhbXMoRm9yIGV4YW1wbGUgYXVkaW8sIHZpZGVvKSBtYXkgcmVxdWlyZSBtdWx0aXBsZQ0KPmNv bXBvbmVudHMgKFJUUCwgUlRDUCkgZWFjaCBvZiB3aGljaCBoYXMgdG8gd29yayBmb3IgdGhlIG1l ZGlhIHN0cmVhbSBhcyBhDQo+d2hvbGUgdG8gd29yay4gSWYgY29uc2VudCBmYWlscyBmb3Igb25l IG9mIHRoZSBjb21wb25lbnQgdGhlbiB0aGUNCj5hcHBsaWNhdGlvbihKUykgbWF5IGRlY2lkZSB0 byBjZWFzZSB0cmFuc21pc3Npb24gb2YgdGhhdCBtZWRpYSBzdHJlYW0uDQo+DQo+SXMgdGhlcmUg YSBuZWVkIHRvIGRlc2NyaWJlIHNvbWUgdGV4dCAoUkVDT01NRU5EQVRJT04pIG9uIGhvdyBmYXRl LXNoYXJpbmcNCj5jb25uZWN0aW9ucyBuZWVkIHRvIGJlIGhhbmRsZWQgd2hlbiBjb25zZW50IGZh aWxzIGZvciBvbmUgb2YgdGhlDQo+Y29tcG9uZW50cyBpbiBDb25zZW50IGRyYWZ0ID8NCj5PciBz aG91bGQgdGhpcyBiZSBsZWZ0IG91dCBvZiB0aGlzIGRyYWZ0ID8NCj4NCj4NCj4NCj4NCj5Tbywg aXQncyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGFwcGxpY2F0aW9uIG1heSBhbHdheXMgZGVj aWRlIHRvIGNlYXNlDQo+dHJhbnNtaXNzaW9uIG9mIGEgbWVkaWEgc3RyZWFtIGV2ZW4gIHdoZW4g aXQgaGFzIGNvbnNlbnQgdG8gY29udGludWUsIHNvDQo+SSdtIG5vdCBzdXJlIHdoYXQgbGFuZ3Vh Z2UgeW91IGFyZSBsb29raW5nIGZvciBoZXJlLg0KPiBDYW4geW91IGJlIGEgYml0IG1vcmUgZGly ZWN0IG9uIHdoaWNoIHNlY3Rpb24gd291bGQgbmVlZCB0aGlzDQo+cmVjb21tZW5kYXRpb24gYW5k IHdoYXQgaXQgbWlnaHQgc2F5Pw0KDQpDdXJyZW50bHkgdGhlcmUgaXMgbm8gc2VjdGlvbiB0aGF0 IHRhbGtzIGFib3V0IHRoaXMuIE9uZSBvZiB0aGUgY29tbWVudHMNCmdpdmVuIGJ5IE1hZ251cyBz b21lIHRpbWUgYmFjayBvbiB0aGlzIGRyYWZ0IGFza3MgYWJvdXQgc2NvcGUgb2YgY29uc2VudC4N CldlICh0aGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLXN0dW4tY29uc2VudC1mcmVzaG5lc3MpIHdl cmUgZGlzY3Vzc2luZw0KYW1vbmcgb3Vyc2VsdmVzIG9uIHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVk IHRvIGhhdmUgYW55IHRleHQgZm9yDQpmYXRlLXNoYXJpbmcgY29ubmVjdGlvbnMuIFdlIGRvbqn2 dCBzZWUgYSByZWFsIG5lZWQgdG8gaGF2ZSBhbnkNCnJlY29tbWVuZGF0aW9uIGluIHRoaXMgZHJh ZnQgYnV0IHdhbnRlZCB0byBicmluZyB0aGlzIHRvcGljIHRvIG1haWxlciB0bw0Kc2VlIGlmIGFu eSBvbmUgZWxzZSBoYXZlIGFueSBkaWZmZXJlbnQgb3Bpbmlvbi4NCg0KQXMgeW91IHNhaWQgaXQg aXMgY29tcGxldGVseSB1cCB0byB0aGUgYXBwbGljYXRpb24gd2hhdCB0byBkbyBpZiBjb25zZW50 DQpmYWlscy4gVGhlcmUgbWF5IGJlIG1hbnkgcG9zc2liaWxpdGllcy0gRm9yIGV4YW1wbGUgZm9y IGEgc2luZ2xlIG1lZGlhDQpzdHJlYW0gd2hlbiBSVFAgYW5kIFJUQ1AgYXJlIHNlbnQgb3ZlciBk aWZmZXJlbnQgYWRkcmVzc2VzIChubyBtdXggdXNlZCksDQp0aGVuIGlmIGNvbnNlbnQgZmFpbHMg Zm9yIG9uZSBvZiB0aGUgY29tcG9uZW50cywgYW4gYXBwbGljYXRpb24gbWF5IGNob29zZQ0KdG8g Y2Vhc2UgdGhhdCBzdHJlYW0uIFRoZXJlIG1heSBiZSBhbHNvIGNhc2VzIHdoZXJlIGNvbnNlbnQg bWF5IGZhaWwgZm9yDQphdWRpbyBidXQgcGFzcyBmb3IgdmlkZW8uIEFnYWluIGl0IGlzIHVwIHRv IHRoZSBhcHBsaWNhdGlvbiAoSmF2YVNjcmlwdCkNCnRvIHRha2UgYSBkZWNpc2lvbiBvbiB3aGF0 IHRvIGRvLg0KDQpTaW5jZSBpdCBpcyBhcHBsaWNhdGlvbiB0aGF0IGFsd2F5cyBkZWNpZGUsIEkg YW0gb2sgdG8ganVzdCBsZWF2ZSBpdCBhbmQNCm5vdCBoYXZlIGFueSB0ZXh0IGluIHRoaXMgZG9j dW1lbnQNCg0KUmFtDQoNCg0KDQo+DQo+VGVkDQo+DQo+DQo+DQo+IA0KPg0KPlJlZ2FyZHMsDQo+ UmFtDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5ydGN3ZWIgbWFpbGluZyBsaXN0DQo+cnRjd2ViQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCj4NCj4NCj4NCj4NCg0K From nobody Wed Mar 26 10:21:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FF11A01CC for ; Wed, 26 Mar 2014 10:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt0neA-OTDHn for ; Wed, 26 Mar 2014 10:21:29 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 68B941A0333 for ; Wed, 26 Mar 2014 10:21:29 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id z10so2148819pdj.18 for ; Wed, 26 Mar 2014 10:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NmV8q8nf7UzyvkJjv2Ga4kOb5QkWNmHJpHkAxD/cXBY=; b=JtW6kQpEHyjff6lMoeI+zzbeu7jSc5VxsrugUopliNTrYtuquiTniyzchvC9iYhsyX FDxGeRuifd5jqpTr5iShKcwWc5dsKDzhDfoYZLGtVqaH7jMhktPTVcemlUT+9AicP/kv 33amkt0kEQ2iWkMvMJcVYN9TgELaG8bSkUlnqhhNAzYCLiYIn7+nu0U+8l4ZpUg3GCFV wd3BGf9Rym5Ec7PvhIbwQTPYXKSY5jj+keXQfBLKpypLpdZMpcn9Y87+YFj4JTdm056x HIPl32z7jpqg471rbQ3b3RYYI26dgwDnxfrSdGwi8pX6AOo33Cu0My3SgMye0mf82bNn NQ5A== MIME-Version: 1.0 X-Received: by 10.66.163.164 with SMTP id yj4mr6105403pab.91.1395854488026; Wed, 26 Mar 2014 10:21:28 -0700 (PDT) Received: by 10.68.184.161 with HTTP; Wed, 26 Mar 2014 10:21:27 -0700 (PDT) Date: Wed, 26 Mar 2014 18:21:27 +0100 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-fsdb2TBUInorytQ0PGJBltmq0g Subject: [rtcweb] Firewall/http-proxy traversal 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, 26 Mar 2014 17:21:31 -0000 During the meeting in London I think Andy was scheduled to discuss firewall and http proxy traversal (http://tools.ietf.org/agenda/89/slides/slides-89-rtcweb-8.pdf) but unfortunately we ran out of time. Is there any plan to discuss this before our next meeting? Thank you, -Victor From nobody Thu Mar 27 07:14:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAAF1A06E0 for ; Thu, 27 Mar 2014 07:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 gzekOUdmN3YO for ; Thu, 27 Mar 2014 07:14:39 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id EB8D31A032B for ; Thu, 27 Mar 2014 07:14:38 -0700 (PDT) X-AuditID: c1b4fb31-b7f888e000000826-9b-5334324c9f29 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 00.4F.02086.C4234335; Thu, 27 Mar 2014 15:14:36 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.347.0; Thu, 27 Mar 2014 15:14:35 +0100 Message-ID: <5334324C.8070004@ericsson.com> Date: Thu, 27 Mar 2014 15:14:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" , Ted Hardie References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvja6PkUmwwcdtehbLu3YwWqz9185u 0TjXzoHZY8rvjaweO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAlfGveYD7AV/RCve3WphbGC8 INjFyMkhIWAi8X7lAnYIW0ziwr31bF2MXBxCAicYJZ68PMII4SxnlGj9Mp0NpIpXQFviSM9H MJtFQFXiz5ZpYDabgIXEzR+NYLaoQLDE0jmLWSDqBSVOznwCZosIBEksf3AarIZZQF3izuJz YJuFBWokev43sUAs28ko8eDuD7AiTgF9iVuL+5m6GDmAzhOX6GkMgujVlGjd/psdwpaXaN46 mxnEFgK6raGpg3UCo9AsJKtnIWmZhaRlASPzKkbJ4tTipNx0I0O93PTcEr3Uoszk4uL8PL3i 1E2MwBA/uOW34Q7GidfsDzFKc7AoifMyTO8MEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBo ubCrW+YKv9mkx34zWc1vq/fpFT59KxzyYHte2PPlm20vxOgtmd0xocb427bNf0TkZ67W3+Im NLnf4cziZW98hbwmFGcGp3zcsSbn3PVv8ReSOszUJEyXLSprfHtsR676rju9TN+Ub8oYT9hy eXE/w1WT54cytnKKHtX6Yf/S48w8+YJtRnEcSizFGYmGWsxFxYkAYRAosD8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IkL9mF6CxdWhtqper0miAdMzHEo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 27 Mar 2014 14:14:40 -0000 On 2014-03-26 02:20, Ram Mohan R (rmohanr) wrote: > Currently there is no section that talks about this. One of the comments > given by Magnus some time back on this draft asks about scope of consent. > We (the authors of draft-ietf-stun-consent-freshness) were discussing > among ourselves on whether there is a need to have any text for > fate-sharing connections. We don¹t see a real need to have any > recommendation in this draft but wanted to bring this topic to mailer to > see if any one else have any different opinion. > > As you said it is completely up to the application what to do if consent > fails. There may be many possibilities- For example for a single media > stream when RTP and RTCP are sent over different addresses (no mux used), > then if consent fails for one of the components, an application may choose > to cease that stream. There may be also cases where consent may fail for > audio but pass for video. Again it is up to the application (JavaScript) > to take a decision on what to do. I do think RTP MUST be fate shared with its RTCP. Because revoking consent for RTCP should not be a way of turning off congestion control. Thus, no RTCP should mean no RTP either as you get no feedback on how it behaves. > > Since it is application that always decide, I am ok to just leave it and > not have any text in this document > >From a security point of view, what is important is that one can't treat consent on one transport flow (5-tuple) to mean consent to send on any other. Because then an attacker could create a session where he receives the low-bitrate audio and consent to the media there and direct the video to a target for the attack, where no consent is received. But, I am personally mostly fine with saying nothing that a failure to retain consent on one RTP session or data channel's transport flows, may or may not mean that the transmission should be killed on another RTP session or data channel, where consent has not yet failed. One question is if one doesn't fate share all transport flows within the peer connection if one should trigger a consent check when the failure happens on some other transport flow? That way one can minimize the delay of discovering revoked consent or path failure on all transport flows. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 27 07:19:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4E91A0709 for ; Thu, 27 Mar 2014 07:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 UESQbJx6sLmG for ; Thu, 27 Mar 2014 07:19:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 745461A0700 for ; Thu, 27 Mar 2014 07:19:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-19-5334336f9972 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F7.46.10875.F6334335; Thu, 27 Mar 2014 15:19:28 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.347.0; Thu, 27 Mar 2014 15:19:27 +0100 Message-ID: <5334336F.6050001@ericsson.com> Date: Thu, 27 Mar 2014 15:19:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Randell Jesup , References: <531DE104.2010908@ericsson.com> <532AC890.7000602@ericsson.com> <532BF5F4.90901@ericsson.com> <2ED6AAC7-5D6F-48C1-BCAE-EA161C6BC0CF@iii.ca> <532E7B47.8060202@jesup.org> In-Reply-To: <532E7B47.8060202@jesup.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RrfA2CTYoG86p8XZbVkWa/+1szsw eSxZ8pPJ48PydWwBTFFcNimpOZllqUX6dglcGUtefWEpaGCvuHlWu4HxGmsXIyeHhICJxMHG pYwQtpjEhXvr2boYuTiEBA4xSmz5vo8VwlnOKHHh4hE2kCpeAW2Jv0//g3WwCKhKHFlzC8xm E7CQuPmjEaxGVCBYYumcxSwQ9YISJ2c+AbNFBGwl3v3ZAFYjLKArsW75HiaIBc3MEgvuLmQH SXAKaEosfLGVuYuRA+gkcYmexiCQMLOAnsSUqy2MELa8RPPW2cwgthDQPQ1NHawTGAVnIVk3 C0nLLCQtCxiZVzGy5yZm5qSXG25iBAbkwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2Mk3V/LYktsjRtPVg85VIAm1Fi8cbdUyQXv1i9/m/R1aS9c260 ud1bnPX+5ecHu9Zc9/RT/cOg+OWlEffNnK67LyRDJ7tY6f++62Yw8Xb3R/MLQbZ1ocIBEjw1 Ug8iJe9825H+btNf4Wvhb25sj5523jJ2+upjv4wY5qgITDv3XC887WqL/tybZUosxRmJhlrM RcWJAGEkJjoWAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zyz_GKmhFAN_NEygmSVX2bu1b5w Subject: Re: [rtcweb] On ptimes and maxptimes 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, 27 Mar 2014 14:19:32 -0000 On 2014-03-23 07:12, Randell Jesup wrote: > On 3/22/2014 2:39 PM, Cullen Jennings wrote: >> It seems like from interoperability point of view, we also need, if a >> browser receives a maxptime or prime, it MUST be able to understand that. > > maxptime - yes, MUST > ptime - since it's merely a preference, it's not a MUST understand. > Yes, but I think it SHOULD be understood and followed. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 27 10:15:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529671A06F7 for ; Thu, 27 Mar 2014 10:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdB7Z74XlQck for ; Thu, 27 Mar 2014 10:15:31 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3171A0709 for ; Thu, 27 Mar 2014 10:15:31 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so2027488wes.27 for ; Thu, 27 Mar 2014 10:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b/EkVz9gS2MnVKoFaUoB2i7US7AWpAmB7EjecnOHR6U=; b=FP5L4jW6myxZKW4FjsrET3aAV4nv3PGL7fuVku5Eh+s1fh3grQjBYzGs63d8eiF0Qd tYCqli0kX6msHRfQFWPXTTrtm+mk72Ko+M9eqSesfu31eYJxwXkWucheUFZvvez2Jhc2 9D3/FyLmZ7qrpDJfG5dg+OSSX9YDulBKex//cKlF/rIpwHllg5X+hO6o+siC/KDtud49 uKYruv2HB0cFTGP6z0/afs764sqAMkP36WZjqvPvwOa+fNLk/9RWJfOo49gklN98BWpd SlAPSb69/OKrQDEL6BEYRJGtVf5A3IyoX+PZwzVRIV8C8pSumyxh1V+czvCENUrA1BHZ Z2VA== MIME-Version: 1.0 X-Received: by 10.181.13.11 with SMTP id eu11mr41316024wid.30.1395940528801; Thu, 27 Mar 2014 10:15:28 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Thu, 27 Mar 2014 10:15:28 -0700 (PDT) In-Reply-To: <5334324C.8070004@ericsson.com> References: <5334324C.8070004@ericsson.com> Date: Thu, 27 Mar 2014 10:15:28 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eOY8jQWjSSkLKXCrP4MgKxOQk6Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 27 Mar 2014 17:15:33 -0000 On 27 March 2014 07:14, Magnus Westerlund wrote: > I do think RTP MUST be fate shared with its RTCP. Because revoking > consent for RTCP should not be a way of turning off congestion control. > Thus, no RTCP should mean no RTP either as you get no feedback on how it > behaves. I would hope that a congestion control algorithm for RTP would a) use RTCP as its feedback mechanism, and b) react fairly harshly if RTCP suddenly disappeared. Such that loss of consent on RTCP would essentially cut bandwidth to zero, or close to. I remember having this issue with Lync: we were dropping RTCP and the video quality was absolutely appalling. Turns out, Lync was doing both a and b. From nobody Thu Mar 27 12:01:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC15C1A0716 for ; Thu, 27 Mar 2014 12:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufj0EEP2_NLe for ; Thu, 27 Mar 2014 12:01:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE071A0759 for ; Thu, 27 Mar 2014 12:01:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4493D7C50AE for ; Thu, 27 Mar 2014 20:01:34 +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 MDBxbO9lqJ2F for ; Thu, 27 Mar 2014 20:01:32 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:6972:f2b2:e706:3e4f] (unknown [IPv6:2001:470:de0a:27:6972:f2b2:e706:3e4f]) by mork.alvestrand.no (Postfix) with ESMTPSA id 94E027C50AD for ; Thu, 27 Mar 2014 20:01:32 +0100 (CET) Message-ID: <5334758B.9020207@alvestrand.no> Date: Thu, 27 Mar 2014 20:01:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5334324C.8070004@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iLoz9ZePp4hwBSLoGhWn2A9-x4Y Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 27 Mar 2014 19:01:40 -0000 On 03/27/2014 06:15 PM, Martin Thomson wrote: > On 27 March 2014 07:14, Magnus Westerlund > wrote: >> I do think RTP MUST be fate shared with its RTCP. Because revoking >> consent for RTCP should not be a way of turning off congestion control. >> Thus, no RTCP should mean no RTP either as you get no feedback on how it >> behaves. > I would hope that a congestion control algorithm for RTP would a) use > RTCP as its feedback mechanism, and b) react fairly harshly if RTCP > suddenly disappeared. Such that loss of consent on RTCP would > essentially cut bandwidth to zero, or close to. > > I remember having this issue with Lync: we were dropping RTCP and the > video quality was absolutely appalling. Turns out, Lync was doing > both a and b. That's one of the properties of the "circuit breaker" algorithm that Colin Perkins has been editing: Lose RTCP for 3 RTCP reporting intervals, cut transmission. draft-ietf-avtcore-rtp-circuit-breakers-03.txt And our very own rtp-usage requires that we support circuit-breaker: draft-ietf-rtcweb-rtp-usage-11.txt 7.1. Boundary Conditions and Circuit Breakers In the absence of a concrete congestion control algorithm, all WebRTC implementations MUST implement the RTP circuit breaker algorithm that is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP circuit breaker is designed to enable applications to recognise and react to situations of extreme network congestion. However, since the RTP circuit breaker might not be triggered until congestion becomes extreme, it cannot be considered a substitute for congestion control, and applications MUST also implement congestion control to allow them to adapt to changes in network capacity. Any future RTP congestion control algorithms are expected to operate within the envelope allowed by the circuit breaker. From nobody Fri Mar 28 01:11:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3361A0285 for ; Fri, 28 Mar 2014 01:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVU7Qllnz3W6 for ; Fri, 28 Mar 2014 01:11:48 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 65B3B1A0476 for ; Fri, 28 Mar 2014 01:11:47 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-b7-53352ec073cf Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 59.C9.04249.0CE25335; Fri, 28 Mar 2014 09:11:44 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.347.0; Fri, 28 Mar 2014 09:11:44 +0100 Message-ID: <53352EC0.80006@ericsson.com> Date: Fri, 28 Mar 2014 09:11:44 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , References: <5334324C.8070004@ericsson.com> <5334758B.9020207@alvestrand.no> In-Reply-To: <5334758B.9020207@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RveAnmmwwbGPxhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJufZ3CVrBMoWLDxi2sDYyNUl2MnBwSAiYS lxb3s0PYYhIX7q1n62Lk4hASOMIo8eTeHhYIZzmjxOkrK1hBqngFNCXat+4GSnBwsAioSmz8 VggSZhOwkLj5o5ENxBYVCJZYOmcxC0S5oMTJmU/AbBEBe4mLc16C2cICNRI9/5ug5u9nkmi6 uY8RZCangK7E4QYZEFNCQFyipzEIpJxZQE9iytUWRghbXqJ562xmEFtIQFuioamDdQKj4Cwk 22YhaZmFpGUBI/MqRo7i1OKk3HQjg02MwJA8uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoGxSn72IeajtT7P5/ZP/LdLOPPY1MRUp5WZa5/5zg3W3Vm0 X/VmzbLSiGRx8XXVuu93HJw4gSmqaHdWkWqL34fbE0oX2blphHYcsVlhv2rR3ELLL14TVJNu 5CXPS922dq6qn4Nm7/0jXdMiP4v/jlKeJXljYut7IYWIzM3np59Y0Xonb/vM3hkPlViKMxIN tZiLihMBD9fV9BcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eY2vStR0MS4kz58mMKLV3bjiXfU Subject: Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?) 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, 28 Mar 2014 08:11:56 -0000 On 2014-03-27 20:01, Harald Alvestrand wrote: > On 03/27/2014 06:15 PM, Martin Thomson wrote: >> On 27 March 2014 07:14, Magnus Westerlund >> wrote: >>> I do think RTP MUST be fate shared with its RTCP. Because revoking >>> consent for RTCP should not be a way of turning off congestion control. >>> Thus, no RTCP should mean no RTP either as you get no feedback on how it >>> behaves. >> I would hope that a congestion control algorithm for RTP would a) use >> RTCP as its feedback mechanism, and b) react fairly harshly if RTCP >> suddenly disappeared. Such that loss of consent on RTCP would >> essentially cut bandwidth to zero, or close to. >> >> I remember having this issue with Lync: we were dropping RTCP and the >> video quality was absolutely appalling. Turns out, Lync was doing >> both a and b. > > That's one of the properties of the "circuit breaker" algorithm that > Colin Perkins has been editing: Lose RTCP for 3 RTCP reporting > intervals, cut transmission. > > draft-ietf-avtcore-rtp-circuit-breakers-03.txt > > And our very own rtp-usage requires that we support circuit-breaker: > draft-ietf-rtcweb-rtp-usage-11.txt > > 7.1. Boundary Conditions and Circuit Breakers > > In the absence of a concrete congestion control algorithm, all WebRTC > implementations MUST implement the RTP circuit breaker algorithm that > is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP > circuit breaker is designed to enable applications to recognise and > react to situations of extreme network congestion. However, since > the RTP circuit breaker might not be triggered until congestion > becomes extreme, it cannot be considered a substitute for congestion > control, and applications MUST also implement congestion control to > allow them to adapt to changes in network capacity. Any future RTP > congestion control algorithms are expected to operate within the > envelope allowed by the circuit breaker. > Martin and Harald, (as individual) Yes, you are both correct that we have mechanisms that also is intended to react to this happening. I didn't meant to imply that these would not be present. Still, I think for the consent mechanism it needs to at least perform consent and kill on what ICE refers to as "Media Stream", i.e. where RTP and RTCP transport flows when not performing RTP/RTCP multiplexing would be different components, that failure to acquire consent on all components revoke the rights on all those components. Because, if not then you can end up in strange conditions where you still send some traffic. If we turn the issue around and consent is revoked for RTP but not RTCP. Then the RTCP stream continues to send. An application may considered this a failed case as this higher layer is likely to considered RTP and RTCP as a unit and not care about the distinction. Also, I realize that circuit breakers have an issue when it comes to protecting the network if an attacker can set the RTCP bandwidths sufficiently low on their own. As all the breakers are calculated based on reporting intervals, if one sets the RTCP RR bandwidth to 1 bps, then the reporting interval will be very long, even a two SSRC RTP session with minimal RTCP packets will get an Td= 2730,67 s, i.e. ~45 minutes. I need to think a bit more, but I think we might require that one provision RTCP with sufficient RTCP bandwidth that the minimal fixed interval of 5 seconds is going to be the largest term when using the circuit breaker. I will bring this up in AVTCORE. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Sat Mar 29 08:24:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752C51A063A for ; Sat, 29 Mar 2014 08:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLm_D3eDnuY2 for ; Sat, 29 Mar 2014 08:24:31 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 498971A05D3 for ; Sat, 29 Mar 2014 08:24:31 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id jTPD1n0010EZKEL51TQUi4; Sat, 29 Mar 2014 15:24:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id jTQU1n00N3ZTu2S3MTQUgV; Sat, 29 Mar 2014 15:24:28 +0000 Message-ID: <5336E5AC.5030809@alum.mit.edu> Date: Sat, 29 Mar 2014 11:24:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <9DFE7071-67FE-4B03-A6ED-40E24F23C4D7@lurchi.franken.de> <41B81DE9-3989-4856-B5D1-F0E2A9BD1F76@lurchi.franken.de> <53365D1A.8050501@jesup.org> In-Reply-To: <53365D1A.8050501@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396106668; bh=DvXuy4zeDhmDItmQpUWWf3J5FGAtM7bRYxq/+S/nYGI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PJmu7CU5ia+IfTNTdZJ8z7Uk3Nzq2pofiZaaScRdLKS7RQIh3lGGO6Nzh/YQKjA70 ftwzr3SBVM0ZfUHLfcaqlBpQycNTpqbX0BTIyk9nShP7493y0/a37wglAlaSV8zFZT MQch6eMK6iBaOVisBRSk0oWMUUNQTQCKaLFFMj9Iv7gkV8Jyrh4hXk2xzHomvSgEd6 zcWJFPw12F7sSnWITYS4z+Lk1huZjLuSzxs/oJ5BoZTECiGrWzTh0lqdETIpHYgkmI Db1kdDKhi4EHgFLiyzBD6KLyui1QF8SSSkDOyAUdfAkikOSJqs/4GJtCbStgOB3HmG WhbtQqATYXI4g== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/doetBUL12j1k2Zr_D3hSzArqE8M Subject: [rtcweb] Data Channel control 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: Sat, 29 Mar 2014 15:24:32 -0000 There is a thread going on public-webrtc: WebRTC and backpressure (how to stop reading?) That has gotten to the point where there is an rtcweb issue: On 3/29/14 1:41 AM, Randell Jesup wrote: >> No. You could continue to map the channel messages byte-by-byte >> on SCTP messages. But you would introduce some control message >> (also in SCTP DATA chunks) which you would send reliably and >> put in whatever information is needed. For me this looks pretty simple... > > Agreed; we have considerable latitude to define additional control > messages in DATA chunks, if we decide this is useful. > If we're careful, it may even be backwards compatible (ignored if not > supported) without have to negotiate or probe for support. But we'd > need to know exactly *why* we'd consider changing things at this late > date, and for what practical gain, given it would perhaps negatively > impact the duck-typing between WebSockets and DataChannels and cause > more delay and slow adoption. PPID 50, defined in draft-ietf-rtcweb-data-protocol, certainly has the potential to be extended with additional control messages. (It has a one byte message type field with only two values defined.) That seems the obvious place where such messages could be defined. Even if the control messages aren't to be defined now, it would be good to set the stage. For one thing, those control messages ought to be usable even for data channels that are established by means other than DCEP. Right now PPID 50 is only for DCEP. Also, as Randell implies above, it might be a good idea to define the extensibility mechanism - e.g., that messages bearing unknown message types be ignored, or that they get a specific response indicating that they are not supported. Thanks, Paul From nobody Sat Mar 29 10:49:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B601A0762 for ; Sat, 29 Mar 2014 10:49:55 -0700 (PDT) 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 tBzftNqR36_J for ; Sat, 29 Mar 2014 10:49:53 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3A1A06A5 for ; Sat, 29 Mar 2014 10:49:52 -0700 (PDT) Received: from [192.168.1.200] (p508F3C48.dip0.t-ipconnect.de [80.143.60.72]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 99F831C104301; Sat, 29 Mar 2014 18:49:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5336E5AC.5030809@alum.mit.edu> Date: Sat, 29 Mar 2014 18:49:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9DFE7071-67FE-4B03-A6ED-40E24F23C4D7@lurchi.franken.de> <41B81DE9-3989-4856-B5D1-F0E2A9BD1F76@lurchi.franken.de> <53365D1A.8050501@jesup.org> <5336E5AC.5030809@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5Xpg6JFJ6zWDuP9oX_S_0FEgWbA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channel control 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: Sat, 29 Mar 2014 17:49:55 -0000 On 29 Mar 2014, at 16:24, Paul Kyzivat wrote: > There is a thread going on public-webrtc: WebRTC and backpressure (how = to stop reading?) >=20 > That has gotten to the point where there is an rtcweb issue: >=20 > On 3/29/14 1:41 AM, Randell Jesup wrote: >=20 >>> No. You could continue to map the channel messages byte-by-byte >>> on SCTP messages. But you would introduce some control message >>> (also in SCTP DATA chunks) which you would send reliably and >>> put in whatever information is needed. For me this looks pretty = simple... >>=20 >> Agreed; we have considerable latitude to define additional control >> messages in DATA chunks, if we decide this is useful. >> If we're careful, it may even be backwards compatible (ignored if not >> supported) without have to negotiate or probe for support. But we'd >> need to know exactly *why* we'd consider changing things at this late >> date, and for what practical gain, given it would perhaps negatively >> impact the duck-typing between WebSockets and DataChannels and cause >> more delay and slow adoption. >=20 > PPID 50, defined in draft-ietf-rtcweb-data-protocol, certainly has the = potential to be extended with additional control messages. (It has a one = byte message type field with only two values defined.) That seems the = obvious place where such messages could be defined. DCEP is extensible in the way that you can add new message types. But it = is a protocol for in-band negotiation of a data channel. We should keep this focus. The discussion at W3C focussed on messages not related to the = establishment of a data channel, so I would suggest to use a different PPID. >=20 > Even if the control messages aren't to be defined now, it would be = good to set the stage. For one thing, those control messages ought to be = usable even for data channels that are established by means other than = DCEP. Right now PPID 50 is only for DCEP. Also, as Randell implies = above, it might be a good idea to define the extensibility mechanism - = e.g., that messages bearing unknown message types be ignored, or that = they get a specific response indicating that they are not supported. I think at the last IETF we agreed to reset the channel. We can change = that to ignore unknown PPIDs... Best regards Michael >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sat Mar 29 11:47:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C051A06CB for ; Sat, 29 Mar 2014 11:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tegEC4JZ8bTX for ; Sat, 29 Mar 2014 11:47:44 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E95C11A06C3 for ; Sat, 29 Mar 2014 11:47:43 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 9E37B23F046E; Sat, 29 Mar 2014 19:47:40 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.60]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 19:47:40 +0100 From: "Hutton, Andrew" To: Victor Pascual Avila , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Firewall/http-proxy traversal Thread-Index: AQHPSRfYxVXTg3eSKkSa8X1dkhHGA5r4aJlw Date: Sat, 29 Mar 2014 18:47:40 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D54DBF@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vxU8rl9y_72CKLoy6-gQTqusjcE Subject: Re: [rtcweb] Firewall/http-proxy traversal 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, 29 Mar 2014 18:47:45 -0000 Hi Victor, We can of course discuss on the mailing list(s) whenever you want. If you want to discuss how to deal with proxies then the PNTAW list was set= up to do this and probably any comments you have on draft-hutton-nat-firewa= ll-considerations should also be on the PNTAW list. But as Harald pointed out during the discussion on -transports- we do need = to decide what to say if anything there as this current has a reference to = -firewall- and discussion on this draft should I assume be on the RTCWEB li= st. The discussion on the PNTAW list stopped which I think was mostly because w= e couldn't work out how to proceed but I for one would be happy if the disc= ussion was restarted. Regards Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Victor > Pascual Avila > Sent: 26 March 2014 17:21 > To: rtcweb@ietf.org > Subject: [rtcweb] Firewall/http-proxy traversal >=20 > During the meeting in London I think Andy was scheduled to discuss > firewall and http proxy traversal > (http://tools.ietf.org/agenda/89/slides/slides-89-rtcweb-8.pdf) but > unfortunately we ran out of time. >=20 > Is there any plan to discuss this before our next meeting? >=20 > Thank you, > -Victor >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Mar 30 13:46:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CC81A08D4 for ; Sun, 30 Mar 2014 13:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnut18ZocxCu for ; Sun, 30 Mar 2014 13:46:33 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7581A07D7 for ; Sun, 30 Mar 2014 13:46:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 287FC7C502B; Sun, 30 Mar 2014 22:46:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06lXYNmXOPEx; Sun, 30 Mar 2014 22:46:26 +0200 (CEST) Received: from [192.168.2.54] (84.127.226.132.static.user.ono.com [84.127.226.132]) by mork.alvestrand.no (Postfix) with ESMTPSA id 88EA57C09CA; Sun, 30 Mar 2014 22:46:25 +0200 (CEST) Message-ID: <5338829B.3020505@alvestrand.no> Date: Sun, 30 Mar 2014 22:46:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Magnus Westerlund , "rtcweb@ietf.org" , Harald Alvestrand References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> In-Reply-To: <530C74A1.3000203@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NxbhNjVWYdztWfY9sJg2MlNIs34 Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-02 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, 30 Mar 2014 20:46:37 -0000 Reviving an old thread, since I'm getting the changes in: On 02/25/2014 11:46 AM, Magnus Westerlund wrote: > On 2014-02-19 19:47, Harald Alvestrand wrote: >> On 02/19/2014 11:08 AM, Magnus Westerlund wrote: >>> Hi, >>> >>> I have reviewed the Transports for RTCWEB >>> (draft-ietf-rtcweb-transports-02) >> Thanks! >>> and have the following comments. >>> >>> 1. Section 1. >>> >>> This document focuses on the data >>> transport protocos that are used by conforming implementations. >>> >>> Missing "l" in protocos. >> Fixed. >>> 2. Section 3.1: >>> For both protocols, IPv4 and IPv6 support is assumed; applications >>> MUST be able to utilize both IPv4 and IPv6 where available. >>> >>> What "applications" are intended in this sentence. I get a feeling that >>> "applications" here could be replaced by "WebRTC implementations" >> Javascript applications. I think I should add the word "application" to >> -overview's vocabulary; it is actually used in that meaning in that >> document (also in the forms "Web application" and "browser-based >> application". > Sorry, then I find the above requirement a bit strangely targeted. I > think we can require that IPv4 and IPv6 support for the applicable > protocol pieces in what we define. But, on the JS application level? > Also what explicit addressing information is visible on that level. If two JS applications want to communicate, and the two systems are connected with IPv4 but not connected with IPv6, communication should happen, otherwise the implementation is non-conformant. If the two systems are connected with IPv6 and not IPv4, communication should happen, otherwise the implementation is non-conformant. Communication, or the lack of it, is clearly a property that's observable at the JS application level. (the detail that the IPv* addresses are visible in the candidates and in the SDP is an implementation detail that doesn't belong here.) > > It might be that this requirement needs to be split or at least apply to > multiple levels. Or maybe rewritten to a language that we both understand. Leaving it roughly as-is for the moment. > >>> >>> 3. Section 3.1: >>> For UDP, this specification assumes the ability to set the DSCP code >>> point of the sockets opened on a per-packet basis, in order to >>> achieve the prioritizations described in >>> [I-D.dhesikan-tsvwg-rtcweb-qos] when multiple media types are >>> multiplexed. It does not assume that the DSCP codepoints will be >>> honored, and does assume that they may be zeroed or changed, since >>> this is a local configuration issue. >>> >>> I wonder if this should be moved into 3.2 section instead. At least the >>> part in 3.1 should focus on the DSCP setting part on the transport flow. >>> The implications of it working or not should be moved to 3.2. A forward >>> pointer to that second can be used instead. >> I think it fits better in 3.1 - this is about the assumptions that the >> specifcation makes about the parts of the system that it is not a >> specification for. > I am fine with the first sentence staying, it is the second part that > needs more discussion and I think it should be moved and expanded on. > Thus a forward pointer may be appropriate here. Added forward pointer, since I now have somewhere for it to point. >>> 4. Order of Section 3.2 and 3.3. >>> >>> I think the order should be swapped between 3.2. and 3.3. That way the >>> Multiplexing section can provide definitions of all the stream concepts >>> that exists in WebRTC and how they can be combined. More about this later. >>> >>> 5. Content of Section 3.2 >>> >>> This section needs to be expanded to start with a general discussion of >>> how QoS can be applied to get a benefit. But, I think one need to be >>> clear that it can't be assumed to be available in implementations or >>> WebRTC based applications. >> I want to push back on this. It seems inappropriate that the RTCWEB QoS >> specification start off with a tutorial on what QoS is and how one can >> use it to gain a benefit. That material should be available elsewhere. >> (Recommendations?) > I would like to agree with you, however we are putting together the > pieces in a way that stands some of the previous assumptions on their > heads. Thus, we don't have easy access to pointers. > > I can see this discussion going into > draft-ietf-avtcore-multiplex-guidelines when it concerns RTP. However, > you also have the data channel to consider. Thus, there exist no > references that I know that discusses this particular combination and > its implications. > >>> It needs to also discuss flow-based QoS mechanism. What are the >>> implications if that is what is available and what choices does one have >>> to address this by configuring the multiplexing different. >> I do not want to discuss material for which there are no references. >> What particular flow-based mechanisms do you have in mind, and what are >> the relevant references? > RSVP we can start with, but I think equally applicable is 3GPP QoS. But > finding the right reference here might be a bit problematic. > > I think one can cover the general property of flow based QoS in a single > sentence. However, that usage has implications for the peer connection > and its configuration. We have text in the rtp-usage that makes it clear > about the requirement to be able to send multiple RTP sessions on > different flows. But the combination with the data channel is not > covered. Thus, I think that belongs in the transports document. The > question is how much lead in material you need for that discussion? I'll add some general words about 5-tuples and 6-tuples to the QoS section. Let's see if that resolves the remaining issues below; I don't want to use too much time on this before launching a revised document to invite others' comments. > >>> I think this >>> is the logical place to take the main discussion of that, as it can >>> address both RTP streams and the data channel together. Please consider >>> pointers to appropriate discussion in Section 12.1.3 in >>> draft-ietf-rtcweb-rtp-usage. >> I do not think this document should repeat any material from rtp-usage, >> but rtp-usage does not consider any aspect of QoS marking for multiple >> streams using the same 5-tuple, nor does it say anything about >> flow-based or DPI-based mechanisms apart from noting their existence. > No, I am not talking about repeating. I am discussing the requirements > on being able to separate the data channel on transport level (UDP) from > the RTP sessions over their RTP, as well as being able to put them on > common UDP flows. > >> Agree that the multiplexing aspect should be discussed somewhere, but >> I'm not sure where. >>> I do note that writing this section appropriately is difficult until the >>> content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up. >> True. >>> 6. Content of Section 3.3: >>> >>> I think this section should focus on making clear what different types >>> of streams that exist in the WebRTC context, and what choices of >>> multiplexing that are possible. Basically ensure that the full set of >>> combinations are made clear. >> Isn't this material that really should be in >> draft-ietf-avtcore-rtp-multi-stream or > This is not appropriate place, this only discusses multiple SSRCs in the > same RTP session. > >> draft-ietf-avtcore-multiplex-guidelines? > This one definitely needs such discussion yes. > > Also draft-ietf-avtcore-multi-media-rtp-session has some parts of this, > due to the potential for different needs based on media type. > >> Again, this seems the wrong draft for having a discussion of those issues. > However, adding the data channel into this, is something WebRTC > specific, thus you are not getting away from dealing with it. > >>> A. All RTP packet streams and data channel over a single UDP flow. >>> >>> B. All RTP packet streams over one UDP flow and the data channel over >>> another UDP flow. >>> >>> C. The RTP packet streams over different UDP flows based on content type >>> and separate data channel. >>> >>> D. Each RTP packet stream over its own UDP flow (RTP session) and the >>> data channel over its own UDP flow. >>> >>> The above with the additional dimension, that each RTP sessions, RTCP >>> can be in its own UDP flow. >>> >>> There is also a question if the data channel can be aggregated with only >>> one RTP session, where there are multiple ones configured. >>> >>> The QoS related discussion of this can be moved to the QoS section to >>> keep that focused. >>> >>> However, the discussion of the pro and cons with having one or more flow >>> is good and could even be expanded to list reasons such as legacy >>> interop over a gateway. >>> >>> 7. Section 3.3: >>> RTCWEB implementations MUST support the ability to send and receive >>> multiple SSRCs on the same transport, and MUST support the ability to >>> send and receive multiple SSRCs on multiple simultaneous transports, >>> including the ability to send and receive audio and video on the same >>> transport. >>> >>> I think this sentence is restating what is already required by Section >>> 4.1 in draft-ietf-rtcweb-rtp-usage: If you want to enforce this, I >>> suggest to do that by reference to that text rather than using RFC 2119 >>> normative statements. >> Yes, rtp-usage contains these requirements. I can delete it from here. >> Thanks! >> >> However, this removes the handle on which I hung the discussion of why >> one would want to multiplex or not, which I inserted because you >> requested it. This discussion also seems to be present in rtp-usage, so >> it seems appropriate to delete that too. > As I argue above, there is a need to take a full WebRTC level discussion > of the multiplexing issues. I think the appropriate here is to try to > ensure the AVTCORE documents contains the relevant pieces so you know > what to reference and then try to put togheter a high level RTP + Data > channel multiplexing considerations in this document. > >>> >>> 8. Section 3.4: >>> ICE [RFC5245] MUST be supported. The implementation MUST be a full >>> ICE implementation, not ICE-Lite. >>> >>> In order to deal with situations where both parties are behind NATs >>> which perform endpoint-dependent mapping (as defined in [RFC5128] >>> section 2.4), TURN [RFC5766] MUST be supported. >>> >>> These paragraph implies STUN and TURN server configuration. Should that >>> configuration question be discussed with the appropriate pointers to the >>> API? >> This document has no pointers to the API at the moment, and I do not >> want to add them - it's a layering violation of sorts. We can add >> pointers to JSEP, which is kind of close to the API. >> >> But the main point seems to be that STUN and TURN servers MUST be >> configurable, both from the browser setup and from the (JS) application. >> I'm adding a sentence saying that. > That is probably sufficient. > >>> 9. Section 3.4: >>> In order to deal with firewalls that block all UDP traffic, TURN >>> using TCP between the client and the server MUST be supported, and >>> TURN using TLS between the client and the server MUST be supported. >>> See [RFC5766] section 2.1 for details. >>> >>> I think the following part: "TURN using TLS between" should be changed >>> over "TURN using TLS over TCP between" to make it clear that this is >>> using TLS/TCP rather than TLS/FOO. >> Done. >>> 10. Section 3.4: >>> TURN TCP candidates [RFC6062] SHOULD be supported; this allows >>> applications to achieve peer-to-peer communication when both parties >>> are behind UDP-blocking firewalls using a single TURN server. (In >>> this case, one can also achieve communication using two TURN servers >>> that use TCP between the server and the client, and UDP between the >>> TURN servers.) >>> >>> My understanding of RFC6062 is that it allows one to establish a vanilla >>> TCP connection on the far side of the TURN server as well as connecting >>> that one to an almost vanilla TCP connection (just a initial TURN >>> ConnectionBind request) that A establish to the TURN server, i.e. >>> WebRTC-A -(Turn/TCP)-> TURN_Server -(TCP)-> WebRTC-B. >>> >>> The end-result is that a relayed vanilla TCP connection is established >>> between the WebRTC endpoints (A and B). As the WebRTC transport so far >>> defined only works with datagrams, i.e. DTLS or RTP/RTCP packets they >>> can't be sent natively over a TCP byte stream. Thus, if this mode of >>> operation is to be supported a framing is required on this leg. >>> >>> A possibility here could be RFC 4571 if one want to go this way. >> I added a 4571 reference, and a note saying this is up for discussion. >> If we frame RTP over TCP, we also have to decide what we do about the SCTP. > Yes, I get the impression that the people arguing for the WebRTC over > IP/TCP has not thought through the implications and I definitely like a > discussion of this. > > Also, in which context are you wondering over SCTP in the above? This got cleared up in London - SCTP would go over 4571 too. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > -- Surveillance is pervasive. Go Dark. From nobody Mon Mar 31 02:41:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC5B1A098B for ; Mon, 31 Mar 2014 02:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 ICX0WtHu7-qD for ; Mon, 31 Mar 2014 02:41:55 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5451A0901 for ; Mon, 31 Mar 2014 02:41:54 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-96-5339385eb31a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9B.A3.04779.E5839335; Mon, 31 Mar 2014 11:41:50 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Mon, 31 Mar 2014 11:41:49 +0200 Message-ID: <5339385D.6070006@ericsson.com> Date: Mon, 31 Mar 2014 11:41:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , "rtcweb@ietf.org" , Harald Alvestrand References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> In-Reply-To: <5338829B.3020505@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3RjfOwjLY4PsCdYtjfV1sFidunGa2 WPuvnd2B2ePKhCusHgs2lXosWfKTKYA5issmJTUnsyy1SN8ugSvjRuNWloJtJhUbVuc1MHZr dTFyckgImEj82vaDFcIWk7hwbz1bFyMXh5DAYUaJgwebWSGc5YwSr/40soFU8QpoSxw7dwXM ZhFQlfg/6zI7iM0mYCFx8wdEjahAsMTSOYtZIOoFJU7OfAJkc3CICJRL/PknDxIWFnCUePJ6 BiPE/HZGiTtnjjGC1HAK6Eos+ZEAYkoIiEv0NAaBlDML6ElMudrCCGHLSzRvnc0MYgsBXdPQ 1ME6gVFwFpJls5C0zELSsoCReRUje25iZk56ueEmRmCAHtzyW3cH46lzIocYpTlYlMR5P7x1 DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWPOWwY/p9ZW/U7oNmTvck+42MkhMTTf+2Prh 9Z4pL958ubRKnOecQ5LkLY/VTFmzM6zv7ahZ+XSP6r6TXDIswl+sbp6Ok5tfrdu7+9OGbSdf CE9jTmywn1d3pkRn1/Z5b49Nj5Jd32PXrfaOIVO4oOPlRzFphXblYiYNtVPZwk/DPp39+L/7 ghJLcUaioRZzUXEiAKYkeQseAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Jmmepi2CtIFRo1RDaAKcO2CRKLA Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-02 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, 31 Mar 2014 09:41:57 -0000 Please see inline. On 2014-03-30 22:46, Harald Alvestrand wrote: > Reviving an old thread, since I'm getting the changes in: > > On 02/25/2014 11:46 AM, Magnus Westerlund wrote: >> On 2014-02-19 19:47, Harald Alvestrand wrote: >>> On 02/19/2014 11:08 AM, Magnus Westerlund wrote: >>>> 2. Section 3.1: >>>> For both protocols, IPv4 and IPv6 support is assumed; applications >>>> MUST be able to utilize both IPv4 and IPv6 where available. >>>> >>>> What "applications" are intended in this sentence. I get a feeling that >>>> "applications" here could be replaced by "WebRTC implementations" >>> Javascript applications. I think I should add the word "application" to >>> -overview's vocabulary; it is actually used in that meaning in that >>> document (also in the forms "Web application" and "browser-based >>> application". >> Sorry, then I find the above requirement a bit strangely targeted. I >> think we can require that IPv4 and IPv6 support for the applicable >> protocol pieces in what we define. But, on the JS application level? >> Also what explicit addressing information is visible on that level. > > If two JS applications want to communicate, and the two systems are > connected with IPv4 but not connected with IPv6, communication should > happen, otherwise the implementation is non-conformant. > > If the two systems are connected with IPv6 and not IPv4, communication > should happen, otherwise the implementation is non-conformant. > > Communication, or the lack of it, is clearly a property that's > observable at the JS application level. > > (the detail that the IPv* addresses are visible in the candidates and in > the SDP is an implementation detail that doesn't belong here.) I am not disagreeing with what you write above. However, the implementation requirement on supporting IPv6 and IPv4 is on the WebRTC endpoint, i.e. the media framework, the ICE implementation etc. A JS application should be IP version agnostic as long as it doesn't much SDP details. That is why I raised this issue about "application" rather than the WebRTC endpoint being the one that should support both IPv4 if endpoint is provisioned with them. > >> >> It might be that this requirement needs to be split or at least apply to >> multiple levels. > > Or maybe rewritten to a language that we both understand. Leaving it > roughly as-is for the moment. Yes, rewrite is likely good. > >> >>>> >>>> 3. Section 3.1: >>>> For UDP, this specification assumes the ability to set the DSCP code >>>> point of the sockets opened on a per-packet basis, in order to >>>> achieve the prioritizations described in >>>> [I-D.dhesikan-tsvwg-rtcweb-qos] when multiple media types are >>>> multiplexed. It does not assume that the DSCP codepoints will be >>>> honored, and does assume that they may be zeroed or changed, since >>>> this is a local configuration issue. >>>> >>>> I wonder if this should be moved into 3.2 section instead. At least the >>>> part in 3.1 should focus on the DSCP setting part on the transport flow. >>>> The implications of it working or not should be moved to 3.2. A forward >>>> pointer to that second can be used instead. >>> I think it fits better in 3.1 - this is about the assumptions that the >>> specifcation makes about the parts of the system that it is not a >>> specification for. >> I am fine with the first sentence staying, it is the second part that >> needs more discussion and I think it should be moved and expanded on. >> Thus a forward pointer may be appropriate here. > > Added forward pointer, since I now have somewhere for it to point. Good >>>> 5. Content of Section 3.2 >>>> >>>> This section needs to be expanded to start with a general discussion of >>>> how QoS can be applied to get a benefit. But, I think one need to be >>>> clear that it can't be assumed to be available in implementations or >>>> WebRTC based applications. >>> I want to push back on this. It seems inappropriate that the RTCWEB QoS >>> specification start off with a tutorial on what QoS is and how one can >>> use it to gain a benefit. That material should be available elsewhere. >>> (Recommendations?) >> I would like to agree with you, however we are putting together the >> pieces in a way that stands some of the previous assumptions on their >> heads. Thus, we don't have easy access to pointers. >> >> I can see this discussion going into >> draft-ietf-avtcore-multiplex-guidelines when it concerns RTP. However, >> you also have the data channel to consider. Thus, there exist no >> references that I know that discusses this particular combination and >> its implications. >> >>>> It needs to also discuss flow-based QoS mechanism. What are the >>>> implications if that is what is available and what choices does one have >>>> to address this by configuring the multiplexing different. >>> I do not want to discuss material for which there are no references. >>> What particular flow-based mechanisms do you have in mind, and what are >>> the relevant references? >> RSVP we can start with, but I think equally applicable is 3GPP QoS. But >> finding the right reference here might be a bit problematic. >> >> I think one can cover the general property of flow based QoS in a single >> sentence. However, that usage has implications for the peer connection >> and its configuration. We have text in the rtp-usage that makes it clear >> about the requirement to be able to send multiple RTP sessions on >> different flows. But the combination with the data channel is not >> covered. Thus, I think that belongs in the transports document. The >> question is how much lead in material you need for that discussion? > > I'll add some general words about 5-tuples and 6-tuples to the QoS section. > Let's see if that resolves the remaining issues below; I don't want to > use too much time on this before launching a revised document to invite > others' comments. Okay, I am fine with doing this incremental so that we can figure out the appropriate boundaries and bring other docs up to required level also. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 31 03:35:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C131A0687; Mon, 31 Mar 2014 03:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyj1z1TckjfX; Mon, 31 Mar 2014 03:35:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD41A0678; Mon, 31 Mar 2014 03:35:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331103544.17626.37822.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 03:35:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6jZM28zNUCVXJqx31j36rgkYjL8 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-03.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, 31 Mar 2014 10:35:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for RTCWEB Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-03.txt Pages : 11 Date : 2014-03-31 Abstract: This document describes the data transport protocols used by RTCWEB, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-transports-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-03 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 Mar 31 06:40:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDBD1A0A18 for ; Mon, 31 Mar 2014 06:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6-kBxXHdgRC for ; Mon, 31 Mar 2014 06:40:20 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id B61AC1A09F1 for ; Mon, 31 Mar 2014 06:40:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 34C537C50C6; Mon, 31 Mar 2014 15:40:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4v6Ok1Mu0uM; Mon, 31 Mar 2014 15:40:10 +0200 (CEST) Received: from [192.168.6.166] (62.43.192.217.static.user.ono.com [62.43.192.217]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2BB127C50BD; Mon, 31 Mar 2014 15:40:10 +0200 (CEST) Message-ID: <53397036.5050104@alvestrand.no> Date: Mon, 31 Mar 2014 15:40:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Magnus Westerlund , "rtcweb@ietf.org" , Harald Alvestrand References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> In-Reply-To: <5339385D.6070006@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/njCvqAiqK4svd3r9VOh_riVJwgI Subject: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) 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, 31 Mar 2014 13:40:25 -0000 Version -03 is now published. I hope you like it! New outstanding item: I added requirements for implementations to be able to generate both fully bundled (one 5-tuple for everything) and fully unbundled (one 5-tuple for each flow) configurations, and for implementations to be able to tolerate being hit with any combination of bundling schemes. Is there a need to specify at MUST, SHOULD or MAY levels other combinations? Harald From nobody Mon Mar 31 06:55:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E065F1A6EEC for ; Mon, 31 Mar 2014 06:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 4kkKjgMn2bp8 for ; Mon, 31 Mar 2014 06:55:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF831A6EED for ; Mon, 31 Mar 2014 06:55:01 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2VDstMY031517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 Mar 2014 13:54:55 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2VDssf7032351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 15:54:55 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 31 Mar 2014 15:54:54 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.10]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 15:54:54 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Harald Alvestrand , Magnus Westerlund , "rtcweb@ietf.org" , Harald Alvestrand Thread-Topic: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) Thread-Index: AQHPTObLjc6enSf5ykSk+8PFAd7Jw5r7NiVA Date: Mon, 31 Mar 2014 13:54:54 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> In-Reply-To: <53397036.5050104@alvestrand.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1238 X-purgate-ID: 151667::1396274095-00001564-93F5D101/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UT0LSDeokEVXsrAq-wi5yH6lhas Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) 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, 31 Mar 2014 13:55:07 -0000 Hi Harald, The decision in London to make ICE-TCP a "MUST" has not been implemented in= the -03 draft (I have noticed you have reflected the related TURN-TCP discussion already)= . What are your plans for addressing the ICE-TCP decision? Kind regards, Uwe=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald > Alvestrand > Sent: Monday, March 31, 2014 3:40 PM > To: Magnus Westerlund; rtcweb@ietf.org; Harald Alvestrand > Subject: [rtcweb] Transport -03, bundling question (Re: Comments on > draft-ietf-rtcweb-transports-02) >=20 > Version -03 is now published. I hope you like it! >=20 > New outstanding item: >=20 > I added requirements for implementations to be able to generate both > fully bundled (one 5-tuple for everything) and fully unbundled (one > 5-tuple for each flow) configurations, and for implementations to be > able to tolerate being hit with any combination of bundling schemes. >=20 > Is there a need to specify at MUST, SHOULD or MAY levels other > combinations? >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 31 08:04:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4AD1A066B for ; Mon, 31 Mar 2014 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 h9ECcAkaYfWC for ; Mon, 31 Mar 2014 08:04:11 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 18E591A0A24 for ; Mon, 31 Mar 2014 08:04:10 -0700 (PDT) X-AuditID: c1b4fb32-b7fe98e0000034f3-09-533983e7589d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BA.66.13555.7E389335; Mon, 31 Mar 2014 17:04:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.174.1; Mon, 31 Mar 2014 17:04:06 +0200 Message-ID: <533983E6.20108@ericsson.com> Date: Mon, 31 Mar 2014 17:04:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , "rtcweb@ietf.org" , Harald Alvestrand References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> In-Reply-To: <53397036.5050104@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvje7zZstgg74vPBbH+rrYLE7cOM1s sfZfO7sDs8eVCVdYPRZsKvVYsuQnUwBzFJdNSmpOZllqkb5dAlfG6rvvmQq28le8vHOVqYHx IE8XIyeHhICJxK7Wh4wQtpjEhXvr2boYuTiEBE4ySjxY2MAM4SxnlJj9sYcFpIpXQFOifftR 9i5GDg4WAVWJtVdUQcJsAhYSN380soHYogLBEkvnLIYqF5Q4OfMJC0i5iEC5xJ9/8iBhYYEM iRf7NjBCjD/BKPHzzQqwek4BXYltL0D2cgAdJC7R0xgEEmYW0JOYcrWFEcKWl2jeOpsZxBYS 0JZoaOpgncAoOAvJtllIWmYhaVnAyLyKUbI4tbg4N93IQC83PbdEL7UoM7m4OD9Przh1EyMw jA9u+W20g/HkHvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MO7hf6l6 n0VSb6Jz+HkJ5z9MfHOdJFapC6rvKnTcuep02smnnBcW5ssKXi3sFd3+mX0dV6fz2scnGuSE 1fNWeWz6t3Ot+MtZ74UvLFjBVVSvspmN6eyan5kXXh/6ebP4apLLjQkLdPRObbU9ocJw0dIr 6dBVtWniXPUZKgwvdvn+r7k3WzBXIkOJpTgj0VCLuag4EQAXWcj+MQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QSS6FgLsQwfUWlnB4JFpQ87rkRA Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) 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, 31 Mar 2014 15:04:13 -0000 On 2014-03-31 15:40, Harald Alvestrand wrote: > Version -03 is now published. I hope you like it! > > New outstanding item: > > I added requirements for implementations to be able to generate both > fully bundled (one 5-tuple for everything) and fully unbundled (one > 5-tuple for each flow) configurations, and for implementations to be > able to tolerate being hit with any combination of bundling schemes. > > Is there a need to specify at MUST, SHOULD or MAY levels other combinations? RTP Usage has in Section 4.4 requirements concerning implementations support for bundling of RTP that is: - Required to support one RTP session per media type - Required to support one RTP session for all media types We don't have a requirement regarding one MST per RTP session in the RTP usage document currently. To this open issue I would like to highlight that we might need text describing which combinations of RTP and data channel we expect to be supported. >From my individual perspective, I think being able to have data channel on an individual transport-layer flow (5-tuple) is important to be able to put QoS treatments on RTP packets within an RTP session separate from the data channel. Having everything bundled, i.e one RTP session for all media types combined with the data channel I think have strong support. This leaves what possibilities one have to combine the data channel with one out of several RTP sessions? Cheers Magnus Westerlund (As individual) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 31 08:08:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0841A6F0A for ; Mon, 31 Mar 2014 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 qxvs83xTFQTf for ; Mon, 31 Mar 2014 08:08:28 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29F1A0849 for ; Mon, 31 Mar 2014 08:08:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A318C7C50D5; Mon, 31 Mar 2014 17:08:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWwQC32g8TGZ; Mon, 31 Mar 2014 17:08:15 +0200 (CEST) Received: from [172.28.88.100] (unknown [74.125.122.49]) by mork.alvestrand.no (Postfix) with ESMTPSA id DE5837C50D4; Mon, 31 Mar 2014 17:08:14 +0200 (CEST) Message-ID: <533984DD.2020804@alvestrand.no> Date: Mon, 31 Mar 2014 17:08:13 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Rauschenbach, Uwe (NSN - DE/Munich)" , Magnus Westerlund , "rtcweb@ietf.org" , Harald Alvestrand References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040702040407090902040606" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dTpNDKOZfF_5Q67lEWzcMa92W5E Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) 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, 31 Mar 2014 15:08:33 -0000 This is a multi-part message in MIME format. --------------040702040407090902040606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/31/2014 03:54 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > Hi Harald, > > The decision in London to make ICE-TCP a "MUST" has not been implemented in the -03 draft > (I have noticed you have reflected the related TURN-TCP discussion already). > > What are your plans for addressing the ICE-TCP decision? Thanks! Checking the minutes, I find: Chairs called a hum between the alternatives: 1) TCP ICE Candidates are MUST implement 2) TCP ICE Candidates are SHOULD/MAY implement 3) TCP ICE Candidates will not be discussed in document. The hum indicated very strong support for 1). My memory was faulty; I had thought that the same conclusion had applied for TCP ICE candidates as for TURN ICE candidates. Version -04 will have this fixed. > > Kind regards, > Uwe > > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald >> Alvestrand >> Sent: Monday, March 31, 2014 3:40 PM >> To: Magnus Westerlund; rtcweb@ietf.org; Harald Alvestrand >> Subject: [rtcweb] Transport -03, bundling question (Re: Comments on >> draft-ietf-rtcweb-transports-02) >> >> Version -03 is now published. I hope you like it! >> >> New outstanding item: >> >> I added requirements for implementations to be able to generate both >> fully bundled (one 5-tuple for everything) and fully unbundled (one >> 5-tuple for each flow) configurations, and for implementations to be >> able to tolerate being hit with any combination of bundling schemes. >> >> Is there a need to specify at MUST, SHOULD or MAY levels other >> combinations? >> >> Harald >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------040702040407090902040606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/31/2014 03:54 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
Hi Harald,

The decision in London to make ICE-TCP a "MUST" has not been implemented in the -03 draft
(I have noticed you have reflected the related TURN-TCP discussion already).

What are your plans for addressing the ICE-TCP decision?

Thanks!

Checking the minutes, I find:

Chairs called a hum between the alternatives:

1) TCP ICE Candidates are MUST implement
2) TCP ICE Candidates are SHOULD/MAY implement
3) TCP ICE Candidates will not be discussed in document. 

The hum indicated very strong support for 1).

My memory was faulty; I had thought that the same conclusion had applied for TCP ICE candidates as for TURN ICE candidates. Version -04 will have this fixed.


Kind regards,
Uwe 



-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald
Alvestrand
Sent: Monday, March 31, 2014 3:40 PM
To: Magnus Westerlund; rtcweb@ietf.org; Harald Alvestrand
Subject: [rtcweb] Transport -03, bundling question (Re: Comments on
draft-ietf-rtcweb-transports-02)

Version -03 is now published. I hope you like it!

New outstanding item:

I added requirements for implementations to be able to generate both
fully bundled (one 5-tuple for everything) and fully unbundled (one
5-tuple for each flow) configurations, and for implementations to be
able to tolerate being hit with any combination of bundling schemes.

Is there a need to specify at MUST, SHOULD or MAY levels other
combinations?

Harald

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



-- 
Surveillance is pervasive. Go Dark.
--------------040702040407090902040606-- From nobody Mon Mar 31 10:09:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233E61A6F51 for ; Mon, 31 Mar 2014 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2EO3ZSuJWmd for ; Mon, 31 Mar 2014 10:09:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14A1A0897 for ; Mon, 31 Mar 2014 10:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5A5B87C50D4 for ; Mon, 31 Mar 2014 19:08:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLsfYHRxUJQn for ; Mon, 31 Mar 2014 19:08:50 +0200 (CEST) Received: from [172.28.88.100] (unknown [74.125.122.49]) by mork.alvestrand.no (Postfix) with ESMTPSA id 39DF87C50A4 for ; Mon, 31 Mar 2014 19:08:50 +0200 (CEST) Message-ID: <5339A120.3040909@alvestrand.no> Date: Mon, 31 Mar 2014 19:08:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QIUa20XHIQMfx42xxhAlDf0cci4 Subject: [rtcweb] Some language on "prioritization" 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, 31 Mar 2014 17:09:05 -0000 I see that I have promised to sugggest language for -transport- about prioritization. Here's an attempt. References and so on to be filled in later. Comments welcome - this is a first stab! -------------------------------------------- The RTCWEB prioritization model is that the application tells the RTCWEB implementation about the priority of media and data flows through an API. The priority associated with a media or data flow is classified as "normal", "below normal", "high" or "very high". There are only four priority levels at the API. The RTCWEB implementation is responsible for mapping these to protocol mechanics at the protocol interfaces, and to behave appropriately when choosing what packets to send when. [draft-dhesikan] specifies the mapping of the four levels of priority, combined with the media type, to DSCP markings. This marking SHOULD be done; the implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. The detection of these conditions is implementation dependent. (Question: Does there need to be an API knob to turn off DSCP markings?) When an RTCWEB implementation has packets to send on multiple streams that are congestion-controlled under the same congestion controller, the RTCWEB implementation SHOULD serve the streams in a weighted round-robin fashion, with each level of priority being given twice the transmission capacity of the level below; thus, when congestion occurs, a "very high" priority flow will have the ability to send 8 times as much data as a "below normal" flow if both have data to send. This prioritization is independent of the media type, but will lead to packet loss due to full send buffers occuring first on the highest volume flows at any given priority level. The details of which packet to send first are implementation defined. -- TODO: Specify a relative priority scheme that makes sense with SCTP, with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] specifies a priority policy, but it's about discarding packets, not deciding which packets to send first, and it also makes it impossible to specify time-bounded retransmission. -- -- Surveillance is pervasive. Go Dark. From nobody Mon Mar 31 10:38:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19C01A6F25 for ; Mon, 31 Mar 2014 10:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKkWssRNk9DU for ; Mon, 31 Mar 2014 10:38:12 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id DCEAB1A6F15 for ; Mon, 31 Mar 2014 10:38:11 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so2004682wiv.12 for ; Mon, 31 Mar 2014 10:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cXmB/P9Hsg/EUgDghiFKFkixomuVMfhe4JiYjLyA95w=; b=ZQRQYPsdQ9cLl2Z3rgGGaGwA5z8dnO7THntFprjj1WyB/hs8a/Y/7bapJfSYMY4qPd yNojiZUYF1N9MgAv82Je9jDGm3RLkjAG5e7gQYEuY9ZW9hrFYmrj2Q1rPOhRQl7rlQ1Z d6Xh3QeDwMkgVVhgCqPtC7sII80B1rfGTFvYTmLNm4OYKaAPRToWGl1vkFFCaaOjjabT p5mgqX+JX9e2xiz+KflK1coyJ827CE3eEV+FYiDDr5zm1oHDWwrLSDi1C75OXEFXxbom Pq20KzSR+DXcqgWCChpGI4uJc/woRE8uBnWAViFiVbLuyNolSdM8d+SI9DFARLGbKTX0 j4cA== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr13625862wiw.50.1396287488245; Mon, 31 Mar 2014 10:38:08 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 31 Mar 2014 10:38:08 -0700 (PDT) In-Reply-To: <5339A120.3040909@alvestrand.no> References: <5339A120.3040909@alvestrand.no> Date: Mon, 31 Mar 2014 10:38:08 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ylnA-2tA_L2tN1BWhCkU8buC-hY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some language on "prioritization" 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, 31 Mar 2014 17:38:13 -0000 On 31 March 2014 10:08, Harald Alvestrand wrote: > -- TODO: Specify a relative priority scheme that makes sense with SCTP, > with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] > specifies a priority policy, but it's about discarding packets, not > deciding which packets to send first, and it also makes it impossible to > specify time-bounded retransmission. -- Why would SCTP need special treatment? I can understand if there are particular time-sensitive control messages that need to be given higher priority, but this is all time-sensitive. From nobody Mon Mar 31 10:43:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF021A089D for ; Mon, 31 Mar 2014 10:43:11 -0700 (PDT) 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 mYbKPChelFyG for ; Mon, 31 Mar 2014 10:43:09 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 089D71A6F27 for ; Mon, 31 Mar 2014 10:43:08 -0700 (PDT) Received: from [192.168.1.103] (p508F0375.dip0.t-ipconnect.de [80.143.3.117]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0850B1C10467A; Mon, 31 Mar 2014 19:43:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Mon, 31 Mar 2014 19:42:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <5339A120.3040909@alvestrand.no> To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Kc--dvAuD48qHbQchaDnmuyCeXA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some language on "prioritization" 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, 31 Mar 2014 17:43:11 -0000 On 31 Mar 2014, at 19:38, Martin Thomson wrote: > On 31 March 2014 10:08, Harald Alvestrand wrote: >> -- TODO: Specify a relative priority scheme that makes sense with SCTP, >> with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] >> specifies a priority policy, but it's about discarding packets, not >> deciding which packets to send first, and it also makes it impossible to >> specify time-bounded retransmission. -- > > > Why would SCTP need special treatment? I can understand if there are > particular time-sensitive control messages that need to be given > higher priority, but this is all time-sensitive. A single transport connection (in this case an SCTP association) can only use a single DSCP. So it would be OK to use the same priority for all data channels, but things get complicated when when some data channels would have different priorities requiring different DSCP markings. Best regards Michael > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Mar 31 10:48:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38E21A6F0D for ; Mon, 31 Mar 2014 10:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ggRWsMVyXpI for ; Mon, 31 Mar 2014 10:48:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id E24C91A6F0C for ; Mon, 31 Mar 2014 10:48:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 41C237C50D5; Mon, 31 Mar 2014 19:48:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k-PGLtqvfva; Mon, 31 Mar 2014 19:48:14 +0200 (CEST) Received: from [172.28.88.100] (unknown [74.125.122.49]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7D3517C50B1; Mon, 31 Mar 2014 19:48:13 +0200 (CEST) Message-ID: <5339AA58.9070301@alvestrand.no> Date: Mon, 31 Mar 2014 19:48:08 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen , Martin Thomson References: <5339A120.3040909@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rTCL5e8HmfDUaRqEzla1VdZuD50 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some language on "prioritization" 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, 31 Mar 2014 17:48:20 -0000 On 03/31/2014 07:42 PM, Michael Tuexen wrote: > On 31 Mar 2014, at 19:38, Martin Thomson wrote: > >> On 31 March 2014 10:08, Harald Alvestrand wrote: >>> -- TODO: Specify a relative priority scheme that makes sense with SCTP, >>> with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] >>> specifies a priority policy, but it's about discarding packets, not >>> deciding which packets to send first, and it also makes it impossible to >>> specify time-bounded retransmission. -- >> >> Why would SCTP need special treatment? I can understand if there are >> particular time-sensitive control messages that need to be given >> higher priority, but this is all time-sensitive. > A single transport connection (in this case an SCTP association) can > only use a single DSCP. So it would be OK to use the same priority for > all data channels, but things get complicated when when some data channels > would have different priorities requiring different DSCP markings. The SCTP protocol machine will, at some given moment in time, have packets in its send buffers that belong to multiple data channels. Only one of them can go on the wire first. Which packet does it choose to send first, and why? That's the question I'm looking for an answer to. If the answer has an RFC number, chapter and section, I'd be very happy. If it doesn't - perhaps we have to invent one. Or say that it's "implementation dependent". From nobody Mon Mar 31 10:50:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4241A6F2A for ; Mon, 31 Mar 2014 10:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiaB5Kbv0cdY for ; Mon, 31 Mar 2014 10:50:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id E5D581A6F2C for ; Mon, 31 Mar 2014 10:50:21 -0700 (PDT) Received: from DM2PR03CA004.namprd03.prod.outlook.com (10.141.52.152) by BN1PR03MB121.namprd03.prod.outlook.com (10.255.201.16) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 31 Mar 2014 17:50:17 +0000 Received: from BY2FFO11FD048.protection.gbl (2a01:111:f400:7c0c::145) by DM2PR03CA004.outlook.office365.com (2a01:111:e400:2414::24) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Mon, 31 Mar 2014 17:50:17 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD048.mail.protection.outlook.com (10.1.15.176) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Mon, 31 Mar 2014 17:50:16 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.124]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0181.007; Mon, 31 Mar 2014 17:49:47 +0000 From: "Matthew Kaufman (SKYPE)" To: Harald Alvestrand Thread-Topic: [rtcweb] Some language on "prioritization" Thread-Index: AQHPTQQB2UV1VISa20ivIvWZybl59Jr7de0AgAABWoCAAAFxAIAAAHRf Date: Mon, 31 Mar 2014 17:49:45 +0000 Message-ID: <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> In-Reply-To: <5339AA58.9070301@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(438001)(479174003)(377454003)(51704005)(2445?= =?us-ascii?Q?4002)(199002)(189002)(95666003)(82746002)(74502001)(74662001?= =?us-ascii?Q?)(97336001)(23726002)(97756001)(84676001)(81542001)(87936001?= =?us-ascii?Q?)(31966008)(80976001)(93516002)(81342001)(54356001)(19580405?= =?us-ascii?Q?001)(94316002)(2009001)(90146001)(83322001)(2656002)(3365600?= =?us-ascii?Q?1)(92566001)(85806002)(4396001)(94946001)(97736001)(44976005?= =?us-ascii?Q?)(53806001)(93136001)(81686001)(50986001)(85306002)(50466002?= =?us-ascii?Q?)(97186001)(95416001)(51856001)(85852003)(15975445006)(49866?= =?us-ascii?Q?001)(77982001)(47976001)(20776003)(6806004)(63696002)(747060?= =?us-ascii?Q?01)(76796001)(65816001)(47736001)(87266001)(86362001)(464060?= =?us-ascii?Q?03)(59766001)(92726001)(98676001)(80022001)(76482001)(567760?= =?us-ascii?Q?01)(46102001)(54316002)(19580395003)(79102001)(77096001)(367?= =?us-ascii?Q?56003)(83716003)(74366001)(69226001)(47776003)(83072002)(748?= =?us-ascii?Q?76001)(81816001)(56816005);DIR:OUT;SFP:1101;SCL:1;SRVR:BN1PR?= =?us-ascii?Q?03MB121;H:mail.microsoft.com;FPR:FAFEF115.962B89E9.3DD79340.?= =?us-ascii?Q?9AA5D0E8.202E4;MLV:sfv;PTR:InfoDomainNonexistent;A:1;MX:1;LA?= =?us-ascii?Q?NG:en;?= X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0167DB5752 Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/guFDA7DfbO1nkrFp23y1ScRFINY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some language on "prioritization" 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, 31 Mar 2014 17:50:26 -0000 And if SCTP and RTP have packets to send, which goes first, why, and under = what circumstances? Matthew Kaufman (Sent from my iPhone) > On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" = wrote: >=20 >> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>> On 31 Mar 2014, at 19:38, Martin Thomson wro= te: >>>=20 >>>> On 31 March 2014 10:08, Harald Alvestrand wrote= : >>>> -- TODO: Specify a relative priority scheme that makes sense with SCTP= , >>>> with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] >>>> specifies a priority policy, but it's about discarding packets, not >>>> deciding which packets to send first, and it also makes it impossible = to >>>> specify time-bounded retransmission. -- >>>=20 >>> Why would SCTP need special treatment? I can understand if there are >>> particular time-sensitive control messages that need to be given >>> higher priority, but this is all time-sensitive. >> A single transport connection (in this case an SCTP association) can >> only use a single DSCP. So it would be OK to use the same priority for >> all data channels, but things get complicated when when some data channe= ls >> would have different priorities requiring different DSCP markings. >=20 > The SCTP protocol machine will, at some given moment in time, have > packets in its send buffers that belong to multiple data channels. Only > one of them can go on the wire first. >=20 > Which packet does it choose to send first, and why? >=20 > That's the question I'm looking for an answer to. >=20 > If the answer has an RFC number, chapter and section, I'd be very happy. > If it doesn't - perhaps we have to invent one. > Or say that it's "implementation dependent". >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb