From holmer@google.com Sun Jul 1 05:17:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B3621F84D2 for ; Sun, 1 Jul 2012 05:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.043 X-Spam-Level: X-Spam-Status: No, score=-101.043 tagged_above=-999 required=5 tests=[AWL=-1.933, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_56=1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWr1mgw8c12Z for ; Sun, 1 Jul 2012 05:17:46 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 31D7121F84D6 for ; Sun, 1 Jul 2012 05:17:46 -0700 (PDT) Received: by yhfq11 with SMTP id q11so4340933yhf.15 for ; Sun, 01 Jul 2012 05:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=aV7XjC/dpNJlDgVqG7+GHT8AwPCdaVxqq0KsopIvQ4k=; b=mQ+PutY0daNCEwuJK7xECOFixuoNXFOmVKoWsH5zAAPphJCzTdoTkuraiG5QVUwqh3 c490tctf719TPtTPJr4DzpuEsvjAmTFWvMYkjU6Vl9YQ0EG60qcJbB11CKOBpdrRPkH7 EKo+/dpC7AMb9pXKpuW5KE/ApnLE4feUC7cdfM0p6XnGvn1G7kQT2I2rjoJkZNCfO9c6 8UOcKy3ADuarY1m2gMu2p18sQ7PpQ7Sis0Ogy6qkIsIIS8A4g/J2sT4zr5tBBMEm550t D/zhFTx1TXlmP/q4VTfBcytFM9NHn3gglzyMobLj/I5R17d7f4h7gHzo6cf/EFYiZZUs U+LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=aV7XjC/dpNJlDgVqG7+GHT8AwPCdaVxqq0KsopIvQ4k=; b=MGYhIN8CpvyG72TJL/mFzmt+OaNz6Rkznx9oaiHRBEnCLVqQX9PZMY0CmzinaNBJpS E6ozfUYuyeiWbGJCWvUpfriNJu6lHms+6z79hilGB+Ra5eiKc5DRX4Qje3bEiZ9zrH2i 9MLsKtthYJC3m0TIsiDFf4gGuFeB2VZdOFyF4RmI1Fd31IKFU3MxZYP3u0PNiAgvL1cy pcJDaI4T+mbMmvl2lX7QIDses6R90iNnaRoMvhMHzmZCXbx3fDHUHqjFX5bVpWN5Jxiv 599WVD5CfxfgRpqLzhcVWjevxldnm5vvHLDJxCmJj+iweCUgeA4wdxrvFrf4g5b9dgfF DFSA== Received: by 10.50.168.1 with SMTP id zs1mr5162397igb.45.1341145067445; Sun, 01 Jul 2012 05:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.168.1 with SMTP id zs1mr5162390igb.45.1341145067216; Sun, 01 Jul 2012 05:17:47 -0700 (PDT) Received: by 10.50.108.103 with HTTP; Sun, 1 Jul 2012 05:17:47 -0700 (PDT) In-Reply-To: <4FEFF1B6.6050504@jesup.org> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <4FEFF1B6.6050504@jesup.org> Date: Sun, 1 Jul 2012 14:17:47 +0200 Message-ID: From: Stefan Holmer To: Randell Jesup Content-Type: multipart/alternative; boundary=e89a8f83a61352de3d04c3c3ab75 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk4YpSTU9WSWhZ0dE5NBiBsYmUX06kF9G/lC9z0IggdmoDXQPcVYel9bmHukb0mYoeBQ5fpui3JhOPeUXURP+bsoI/NFDH8BGVZ9pIdIQAPn3Kag0+wKNn0Xi8wZU/knQndbj8UvCTY9Qt7QwQ6H8y2acX0fbev9DvCmlS5+kODsUFwzxw= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Jul 2012 12:17:48 -0000 --e89a8f83a61352de3d04c3c3ab75 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 1, 2012 at 8:44 AM, Randell Jesup wrote: > On 6/29/2012 3:30 AM, Stefan Holmer wrote: > >> Doesn't this in the end boil down to what tools we have for baseline >> resilience? Retransmissions are fairly easy to implement and will in >> most cases give a much better experience than for example relying on >> periodic key frames or doing key frame requests. Also it isn't necessary >> for the decoder to support decoding streams with lost packets. >> > > "Better experience" incorporates a bunch of assumptions. > > Assuming we're talking video only: > > If you want it to be seamless, you have to be running a jitter buffer > depth of at least 1 RTT plus time-to-decide-packet-may-be-**lost plus > random-constant. The second part of that can be tricky and network-state > dependent. On corporate networks, I'd see sudden 100ms changes in base > delay over 1-3 packets; a short time-to-decide would flag each of those as > missing. This is ok (the re-xmit will get ignored as a dup), but adds > packets at an apparent bad point for the network. > > That said, small RTTs certainly happen within LANs and corporations, and > between neighbors in a single provider often. > > Note that often/normally with small RTTs you also get reasonably small > jitter, and thus the adaptive jitter buffer might run very small numbers, > so one might need to put a lower limit on the jitter buffer in these cases. > > The alternatives: > > 1) request re-xmit and freeze video queue when the jitter buffer runs dry. > If the packet comes in ASAP, freeze <= RTT+constant (modulo application > scheduling delay at the sender side). Then you can repair the broken > frame, decode it, and then decode any following frames. Typically after a > freeze you drop a frame or more; you might end up showing some of them > depending on decode speed and how long the freeze lasted. If the re-xmit > (or the request) is lost, then delays can stretch much longer, since you > need to wait RTT+bigger constant before requesting again. > Yes, this is what I would consider the simplest approach, which leads to a system which can guarantee a complete stream thus not requiring the decoder to be able to decode with errors, and at the same time having a good chance of recovering within slightly longer than one RTT. > > In some conference apps even if the mixer just forwards video packets, the > RTT is receiver<->mixer, not receiver<->mixer<->sender (this requires the > mixer to buffer packets for possible retransmission). > Yes, this is definitely an upside. > > 2) request IDR (or refresh of corrupted slice). Downside here is that you > need to wait for the next frame encode at the sender side (so 0-33ms > normally, or perhaps 0-100ms), and then the frame typically takes many > packets to send (which also may be lost, and take time to receive > especially on low-BW links), and IDR initial quality may be noticeably > lower. The receiver may freeze the video until the IDR is received or keep > decoding with errors. If there's a significant chance of the IDR losing a > packet, a freeze could be substantial time. > If the losses are related to congestion, sending an IDR is usually a bad idea. And as you are saying, if the losses are due to corruption, the chance of having a loss in an IDR is much bigger than for a P-frame. I don't think this approach is nearly as good as retransmissions, but it is a possible baseline option. > > 3) request repair. Note that #2 and #3 may be the same at the receiver > side, with the sender deciding the best available repair. In this case, > the sender would instead of an IDR use a some other set of (smaller) > packets to create an error-free up-to-date state at the receiver, such as > encoding using a long-term-reference-frame, or using some other > known-error-free frame in the receiver. Note that repair is basically just > a normal p-frame, albeit with somewhat lower quality and/or somewhat higher > bandwidth used. A big plus is that the end state is close to the same as > re-transmit, but you don't have to speed through decoding any skipped > frames. Repair also allows the receiver to use alternate recovery > mechanisms than simply freezing, including simply continuing to decode > p-frames ignoring the lost frame. This induces artifacts, but keeps motion > loss to a minimum, especially in longer-RTT links. > Yes, I agree that this is also a good approach. It may be more expensive than #1 if the long-term reference is old, but in general this would be a good baseline as well. It is possible to continue decoding p-frames, ignoring the loss, with retransmissions as well. However it's a bit more complicated and you will have to speed through some frames at the decoder when the rtx arrives, although you can skip rendering them. > > Note that #3 in particular should result in similar freeze length as #1, > perhaps 1 frame longer, if it freezes. If it plays with errors instead, > the freeze is typically 1 frame (the lost one). > > (Others?) > > My normal preference is #3. But, as discussed above, in low-RTT networks > it may be a good option and might give 0-frames of freeze. But, you still > have all the complexities about how to decide when and how to use re-xmit; > I think the 1 frame freeze is a reasonable option and a reasonable fallback > if the source doesn't re-transmit. > > Also, if retransmit is REQUIRED, and the media is gatewayed to other > sources (non-webrtc), and they don't support retransmit (likely), then the > gateway would need to buffer and act as a retransmit agent (complicating > the gateway). If it's RECOMMENDED, this is not a big deal and the gateway > can stay simpler. Sure, that's a downside, and that may be a good enough reason for RECOMMENDED. The same goes for #3, right? Non-webrtc sources may not support long-term references and therefore have to rely on IDRs. Just saying that it would be nice to have a baseline which is something better than requesting IDRs. > > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --e89a8f83a61352de3d04c3c3ab75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 1, 2012 at 8:44 AM, Randell = Jesup <randell-ietf@jesup.org> wrote:
On 6/29/2012 3:30 AM, Stefan Holmer wrote:
Doesn't this in the end boil down to what tools we have for baseline resilience? Retransmissions are fairly easy to implement and will in
most cases give a much better experience than for example relying on
periodic key frames or doing key frame requests. Also it isn't necessar= y
for the decoder to support decoding streams with lost packets.

"Better experience" incorporates a bunch of assumptions.

Assuming we're talking video only:

If you want it to be seamless, you have to be running a jitter buffer depth= of at least 1 RTT plus time-to-decide-packet-may-be-lost plus rando= m-constant. =A0The second part of that can be tricky and network-state depe= ndent. =A0On corporate networks, I'd see sudden 100ms changes in base d= elay over 1-3 packets; a short time-to-decide would flag each of those as m= issing. =A0This is ok (the re-xmit will get ignored as a dup), but adds pac= kets at an apparent bad point for the network.

That said, small RTTs certainly happen within LANs and corporations, and be= tween neighbors in a single provider often.

Note that often/normally with small RTTs you also get reasonably small jitt= er, and thus the adaptive jitter buffer might run very small numbers, so on= e might need to put a lower limit on the jitter buffer in these cases.

The alternatives:

1) request re-xmit and freeze video queue when the jitter buffer runs dry. = =A0If the packet comes in ASAP, freeze <=3D RTT+constant (modulo applica= tion scheduling delay at the sender side). =A0Then you can repair the broke= n frame, decode it, and then decode any following frames. Typically after a= freeze you drop a frame or more; you might end up showing some of them dep= ending on decode speed and how long the freeze lasted. =A0If the re-xmit (o= r the request) is lost, then delays can stretch much longer, since you need= to wait RTT+bigger constant before requesting again.

Yes, this is what I would consider the sim= plest approach, which leads to a system which can guarantee a complete stre= am thus not requiring the decoder to be able to decode with errors, and at = the same time having a good chance of recovering within slightly longer tha= n one RTT.
=A0

In some conference apps even if the mixer just forwards video packets, the = RTT is receiver<->mixer, not receiver<->mixer<->sender (t= his requires the mixer to buffer packets for possible retransmission).

Yes, this is definitely an upside.
=A0

2) request IDR (or refresh of corrupted slice). =A0Downside here is that yo= u need to wait for the next frame encode at the sender side (so 0-33ms norm= ally, or perhaps 0-100ms), and then the frame typically takes many packets = to send (which also may be lost, and take time to receive especially on low= -BW links), and IDR initial quality may be noticeably lower. =A0The receive= r may freeze the video until the IDR is received or keep decoding with erro= rs. =A0If there's a significant chance of the IDR losing a packet, a fr= eeze could be substantial time.

If the losses are related to congestion, s= ending an IDR is usually a bad idea. And as you are saying, if the losses a= re due to corruption, the chance of having a loss in an IDR is much bigger = than for a P-frame. I don't think this approach is nearly as good as re= transmissions, but it is a possible baseline option.
=A0

3) request repair. =A0Note that #2 and #3 may be the same at the receiver s= ide, with the sender deciding the best available repair. =A0In this case, t= he sender would instead of an IDR use a some other set of (smaller) packets= to create an error-free up-to-date state at the receiver, such as encoding= using a long-term-reference-frame, or using some other known-error-free fr= ame in the receiver. =A0Note that repair is basically just a normal p-frame= , albeit with somewhat lower quality and/or somewhat higher bandwidth used.= =A0A big plus is that the end state is close to the same as re-transmit, b= ut you don't have to speed through decoding any skipped frames. =A0Repa= ir also allows the receiver to use alternate recovery mechanisms than simpl= y freezing, including simply continuing to decode p-frames ignoring the los= t frame. =A0This induces artifacts, but keeps motion loss to a minimum, esp= ecially in longer-RTT links.

Yes, I agree that this is also a good appr= oach. It may be more expensive than #1 if the long-term reference is old, b= ut in general this would be a good baseline as well.

It is possible to continue decoding p-frames, ignoring the loss, with = retransmissions as well. However it's a bit more complicated and you wi= ll have to speed through some frames at the decoder when the rtx arrives, a= lthough you can skip rendering them.
=A0

Note that #3 in particular should result in similar freeze length as #1, pe= rhaps 1 frame longer, if it freezes. =A0If it plays with errors instead, th= e freeze is typically 1 frame (the lost one).

(Others?)

My normal preference is #3. But, as discussed above, in low-RTT networks it= may be a good option and might give 0-frames of freeze. =A0But, you still = have all the complexities about how to decide when and how to use re-xmit; = I think the 1 frame freeze is a reasonable option and a reasonable fallback= if the source doesn't re-transmit.

Also, if retransmit is REQUIRED, and the media is gatewayed to other source= s (non-webrtc), and they don't support retransmit (likely), then the ga= teway would need to buffer and act as a retransmit agent (complicating the = gateway). =A0If it's RECOMMENDED, this is not a big deal and the gatewa= y can stay simpler.

Sure, that's a downside, and that may be a good eno= ugh reason for RECOMMENDED. The same goes for #3, right? Non-webrtc sources= may not support long-term references and therefore have to rely on IDRs.

Just saying that it would be nice to have a baseline wh= ich is something better than requesting IDRs.
=A0

--
Randell Jesup
randell-ietf@je= sup.org


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

--e89a8f83a61352de3d04c3c3ab75-- From ron.even.tlv@gmail.com Sun Jul 1 23:01:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0D611E8161 for ; Sun, 1 Jul 2012 23:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEvrUaY0swfA for ; Sun, 1 Jul 2012 23:01:27 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA1EA11E8136 for ; Sun, 1 Jul 2012 23:01:26 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3300577wgb.13 for ; Sun, 01 Jul 2012 23:01:30 -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:x-mailer:thread-index:content-language; bh=wHx+XDW8Ba8YfIXeOTPDTjsM15hQWQec1KOa1grq31s=; b=ks/SVOciKTxLlYVwZwR4W6VPRwZDvZmcnQ26H/ik4Bsur0zSAUqFHqpD3MdEo3bVQ5 0tllpBp8aeFgjDC1/Z2WnxXjBXI/5ZYFZXC8MPMcjtWjgNuIP32paFzNmSrg60c368qa gcEp85CAhdVAdTna0TB494yCkDStDxwBkAXVLuoIknZ2BkpmRfZymAZg4aHkr3j1KtNJ HEljL5J6DfIAO5QBRI8i77jzupYGDufXPhe+bSK0HpmtuSnkRx15+WO+rUC442Huh0BV yVH06u/DD6+aB/42EaxiG+RE5cvUdyjyvBuNTcXhLnp0PZOgjfPqJnqPlm3XXROEaVQd SCeQ== Received: by 10.180.98.69 with SMTP id eg5mr14144930wib.3.1341208890148; Sun, 01 Jul 2012 23:01:30 -0700 (PDT) Received: from RoniE (bzq-109-64-198-75.red.bezeqint.net. [109.64.198.75]) by mx.google.com with ESMTPS id db7sm23093708wib.6.2012.07.01.23.01.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jul 2012 23:01:28 -0700 (PDT) From: "Roni Even" To: "'Stefan Holmer'" , "'Magnus Westerlund'" References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> In-Reply-To: Date: Mon, 2 Jul 2012 09:01:10 +0200 Message-ID: <01b601cd5820$774e4b70$65eae250$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B7_01CD5831.3AD82CE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWS+mLc/5Xu0n/e00tw8qzpIQ1cwICPz4UAh5NL4cDPUWSd5ZIuZ7Q Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 06:01:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B7_01CD5831.3AD82CE0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, You are right about the decoder, but this requires the encoder to keep = the information since it may be required later. In the case of non real-time data this is not a problem since the data is in prerecorded but here the data is not usually kept after transmission. The whole discussion here is about required or recommended. My point is = that it is recommended since it does not work without any assumption on the = RTT and the receiver behavior when using jitter buffer. Roni =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Stefan Holmer Sent: 29 June, 2012 9:31 AM To: Magnus Westerlund Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED =20 Doesn't this in the end boil down to what tools we have for baseline resilience? Retransmissions are fairly easy to implement and will in = most cases give a much better experience than for example relying on periodic = key frames or doing key frame requests. Also it isn't necessary for the = decoder to support decoding streams with lost packets.=20 =20 /Stefan =20 On Fri, Jun 29, 2012 at 8:43 AM, Magnus Westerlund wrote: On 2012-06-28 16:36, Cullen Jennings wrote: > > I think you need to separate this for audio and video and be far more > specific about what type of retransmit ion you are talking about. In > many cases the retransmit ion schemes for audio make the end suer > experience worse. I am not disagreeing unless the RTT is really low. What I am asking the WG is if RTP retransmission is a RECOMMENDED or REQUIRED feature in the toolbox that an WebRTC end-point supports. This says nothing on when you select to use it and on which media. If we want to include such recommendations we can do it. In fact the RTP usage draft has a bit on text discussing the issue with RTT. Cheers Magnus (As WG chair) > > On Jun 27, 2012, at 24:36 , Magnus Westerlund wrote: > >> WG, >> >> We had a discussion at the interim if RTP Retransmission is to be >> considered REQUIRED or RECOMMENDED to implement. I would like to >> see if we can first have some discussion on this topic before >> moving on to see if we can get a consensus here on the mailing >> list. >> >> Please provide your views on this topic. >> >> Cheers >> >> Magnus Westerlund (As Chair and document editor) >> >> >> = ---------------------------------------------------------------------- >> >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> >> Ericsson AB | Phone +46 10 7148287 =20 >> 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 > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 =20 F=E4r=F6gatan 6 | Mobile +46 73 0949079 =20 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_01B7_01CD5831.3AD82CE0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

You are right about the decoder, but this requires the encoder to = keep the information since it may be required later. In the case of non = real-time data this is not a problem since the data is in prerecorded = but here the data is not usually kept after = transmission.

The whole discussion here is about required or recommended. My point = is that it is recommended since it does not work without any assumption = on the RTT and the receiver behavior when using jitter = buffer.

Roni

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Stefan Holmer
Sent: 29 June, 2012 9:31 AM
To: = Magnus Westerlund
Cc: rtcweb@ietf.org
Subject: Re: = [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or = RECOMMENDED

 

Doesn't this = in the end boil down to what tools we have for baseline resilience? = Retransmissions are fairly easy to implement and will in most cases give = a much better experience than for example relying on periodic key frames = or doing key frame requests. Also it isn't necessary for the decoder to = support decoding streams with lost packets. 

 

/Stefan

 

On Fri, = Jun 29, 2012 at 8:43 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> = wrote:

On 2012-06-28 16:36, Cullen Jennings = wrote:
>
> I think you need to separate this for audio and = video and be far more
> specific about what type of retransmit ion = you are talking about. In
> many cases the retransmit ion schemes = for audio make the end suer
> experience = worse.

I am not disagreeing = unless the RTT is really low.

What I am asking the WG is if RTP = retransmission is a RECOMMENDED or
REQUIRED feature in the toolbox = that an WebRTC end-point supports. This
says nothing on when you = select to use it and on which media. If we want
to include such = recommendations we can do it. In fact the RTP usage
draft has a bit = on text discussing the issue with = RTT.

Cheers

Magnus
(As WG chair)


>
> On Jun = 27, 2012, at 24:36 , Magnus Westerlund wrote:
>
>> = WG,
>>
>> We had a discussion at the interim if RTP = Retransmission is to be
>> considered REQUIRED or RECOMMENDED = to implement. I would like to
>> see if we can first have some = discussion on this topic before
>> moving on to see if we can = get a consensus here on the mailing
>> = list.
>>
>> Please provide your views on this = topic.
>>
>> Cheers
>>
>> Magnus = Westerlund (As Chair and document = editor)
>>
>>
>> = ---------------------------------------------------------------------->>
>>
Multimedia Technologies, Ericsson Research = EAB/TVM
>> = ---------------------------------------------------------------------->>
>>
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
>= ;
>

--

Magnus = Westerlund


---------------------------------------------------= -------------------
Multimedia Technologies, Ericsson Research = EAB/TVM
--------------------------------------------------------------= --------
Ericsson AB               =  | Phone  +46 10 = 7148287
F=E4r=F6gatan 6             =    | Mobile +46 73 = 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson= .com
-------------------------------------------------------------= ---------



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

 

------=_NextPart_000_01B7_01CD5831.3AD82CE0-- From ron.even.tlv@gmail.com Sun Jul 1 23:02:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7E411E817A for ; Sun, 1 Jul 2012 23:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMsox5HwMhID for ; Sun, 1 Jul 2012 23:02:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87E0711E8166 for ; Sun, 1 Jul 2012 23:02:23 -0700 (PDT) Received: by werp11 with SMTP id p11so376841wer.31 for ; Sun, 01 Jul 2012 23:02:27 -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:content-transfer-encoding:x-mailer :thread-index:content-language; bh=T7EVEgVIsSNHj+6YJuncf+bGCimr1DnqAwW0P6GIWKo=; b=ppKH0bVdcywcmpwoW2UwOWFz3C4iDq4P6BPrzCrNw+1F27jexIdsS2vxKvHKADmjPX Qv2icbJ/untGF6LtorSaCjIxAa3NAIQ3U+yNnWii3Yal7jochOQVwmjk+ZJUB+Rq45Xz AthTPUL1/dRqsyJUWVLeNPt4KjeEv8zB2B7hglLasrAwnaO6ic3zGfYKh9KO7U/kSUjD 68w6fwjNX4y7M3jFddfX//4b2uIxURu7GMg3LL+3q0TAYuTOchUOTZ/2qbx8PPczEF/R hk5uIcily3XZ7Sc+aeHks5V0hsxATfUIP04DOE8mWHmxLtYwcQFP3d3iUg7HWOwUSYWt 41kg== Received: by 10.180.83.234 with SMTP id t10mr4799037wiy.0.1341208947092; Sun, 01 Jul 2012 23:02:27 -0700 (PDT) Received: from RoniE ([109.64.198.75]) by mx.google.com with ESMTPS id y2sm23091376wix.7.2012.07.01.23.02.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jul 2012 23:02:26 -0700 (PDT) From: "Roni Even" To: "'John Leslie'" , "'Magnus Westerlund'" References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <20120629142526.GB2870@verdi> In-Reply-To: <20120629142526.GB2870@verdi> Date: Mon, 2 Jul 2012 09:02:08 +0200 Message-ID: <01bb01cd5820$99f83230$cde89690$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWS+mLc/5Xu0n/e00tw8qzpIQ1cwICPz4UAh5NL4cCFdq4K5ZR9fvw Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 06:02:24 -0000 The discussion is whether it is required (MUST) or recommended (SHOULD) Roni -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of John Leslie Sent: 29 June, 2012 4:25 PM To: Magnus Westerlund Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED Magnus Westerlund wrote: > > I am not disagreeing unless the RTT is really low. Actually, there is a balancing act between RTT and jitter... > What I am asking the WG is if RTP retransmission is a RECOMMENDED or > REQUIRED feature in the toolbox that an WebRTC end-point supports. > This says nothing on when you select to use it and on which media. If > we want to include such recommendations we can do it. In fact the RTP > usage draft has a bit on text discussing the issue with RTT. I'd like to support Magnus here: I believe retransmission SHOULD be a tool available to the recipient to request. There will be cases where this is the most appropriate tool. -- John Leslie _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Mon Jul 2 00:24:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E3321F86E5 for ; Mon, 2 Jul 2012 00:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlKz7CEhJq3D for ; Mon, 2 Jul 2012 00:24:53 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B6F2A21F86E4 for ; Mon, 2 Jul 2012 00:24:52 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Slb0B-00015v-Q3 for rtcweb@ietf.org; Mon, 02 Jul 2012 02:24:55 -0500 Message-ID: <4FF14C97.4060005@jesup.org> Date: Mon, 02 Jul 2012 03:24:07 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <4FEFF1B6.6050504@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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 07:24:53 -0000 On 7/1/2012 8:17 AM, Stefan Holmer wrote: > > > On Sun, Jul 1, 2012 at 8:44 AM, Randell Jesup > wrote: > > On 6/29/2012 3:30 AM, Stefan Holmer wrote: > > Doesn't this in the end boil down to what tools we have for baseline > resilience? Retransmissions are fairly easy to implement and will in > most cases give a much better experience than for example relying on > periodic key frames or doing key frame requests. Also it isn't > necessary > for the decoder to support decoding streams with lost packets. > > > "Better experience" incorporates a bunch of assumptions. > > Assuming we're talking video only: > > If you want it to be seamless, you have to be running a jitter > buffer depth of at least 1 RTT plus > time-to-decide-packet-may-be-__lost plus random-constant. The > second part of that can be tricky and network-state dependent. On > corporate networks, I'd see sudden 100ms changes in base delay over > 1-3 packets; a short time-to-decide would flag each of those as > missing. This is ok (the re-xmit will get ignored as a dup), but > adds packets at an apparent bad point for the network. > > That said, small RTTs certainly happen within LANs and corporations, > and between neighbors in a single provider often. > > Note that often/normally with small RTTs you also get reasonably > small jitter, and thus the adaptive jitter buffer might run very > small numbers, so one might need to put a lower limit on the jitter > buffer in these cases. > > The alternatives: > > 1) request re-xmit and freeze video queue when the jitter buffer > runs dry. If the packet comes in ASAP, freeze <= RTT+constant > (modulo application scheduling delay at the sender side). Then you > can repair the broken frame, decode it, and then decode any > following frames. Typically after a freeze you drop a frame or more; > you might end up showing some of them depending on decode speed and > how long the freeze lasted. If the re-xmit (or the request) is > lost, then delays can stretch much longer, since you need to wait > RTT+bigger constant before requesting again. > > > Yes, this is what I would consider the simplest approach, which leads to > a system which can guarantee a complete stream thus not requiring the > decoder to be able to decode with errors, and at the same time having a > good chance of recovering within slightly longer than one RTT. Simple, yes. There are aspects of this I don't like: * Frozen for minimum of 1RTT+. With 100ms RTT, you're probably at a minimum of 4 frames, perhaps 5, and if you lose another packet during those frames, it will move forward but not catch up sync, which can lead to jerky, out of sync video. If you lose a re-xmit packet, you're talking minimum 2x the delay (and in reality a fair bit more because you have to decide when to ask for a re-re-xmit...). * Decoding with errors: not generally a problem. The issue is whether you prefer (or think the users prefer) a short (1 frame) freeze plus 1RTT-1frame-ish period with motion but errors, or a 1+RTT min freeze, maybe/occasionally much more. Our experience at WorldGate was that keeping motion active was preferable to freezing or worse loss of sync, even if there are errors. That conclusion is debatable, and the answer may vary according to RTT, type of call, resolution, bandwidth, type of application, and isn't something the IETF should mandate here. > 2) request IDR (or refresh of corrupted slice). Downside here is > that you need to wait for the next frame encode at the sender side > (so 0-33ms normally, or perhaps 0-100ms), and then the frame > typically takes many packets to send (which also may be lost, and > take time to receive especially on low-BW links), and IDR initial > quality may be noticeably lower. The receiver may freeze the video > until the IDR is received or keep decoding with errors. If there's > a significant chance of the IDR losing a packet, a freeze could be > substantial time. > > > If the losses are related to congestion, sending an IDR is usually a bad > idea. And as you are saying, if the losses are due to corruption, the > chance of having a loss in an IDR is much bigger than for a P-frame. I > don't think this approach is nearly as good as retransmissions, but it > is a possible baseline option. Agreed, though in practice if you're not getting hammered with high loss and you keep the quantization high on the IDR, it will usually get through. Obviously as bitrates increase the number of packets in the IDR goes up, and risk of loss in the IDR goes up. If correction is only for a slice, this risk may not be high. > 3) request repair. Note that #2 and #3 may be the same at the > receiver side, with the sender deciding the best available repair. > In this case, the sender would instead of an IDR use a some other > set of (smaller) packets to create an error-free up-to-date state at > the receiver, such as encoding using a long-term-reference-frame, or > using some other known-error-free frame in the receiver. Note that > repair is basically just a normal p-frame, albeit with somewhat > lower quality and/or somewhat higher bandwidth used. A big plus is > that the end state is close to the same as re-transmit, but you > don't have to speed through decoding any skipped frames. Repair > also allows the receiver to use alternate recovery mechanisms than > simply freezing, including simply continuing to decode p-frames > ignoring the lost frame. This induces artifacts, but keeps motion > loss to a minimum, especially in longer-RTT links. > > > Yes, I agree that this is also a good approach. It may be more expensive > than #1 if the long-term reference is old, but in general this would be > a good baseline as well. There are mechanisms in VP8 that can be leveraged here. > It is possible to continue decoding p-frames, ignoring the loss, with > retransmissions as well. However it's a bit more complicated and you > will have to speed through some frames at the decoder when the rtx > arrives, although you can skip rendering them. Yes, you'd have to clone the decoder state at the loss point in order to "rewind" and then correct. > > > Note that #3 in particular should result in similar freeze length as > #1, perhaps 1 frame longer, if it freezes. If it plays with errors > instead, the freeze is typically 1 frame (the lost one). > > (Others?) > > My normal preference is #3. But, as discussed above, in low-RTT > networks it may be a good option and might give 0-frames of freeze. > But, you still have all the complexities about how to decide when > and how to use re-xmit; I think the 1 frame freeze is a reasonable > option and a reasonable fallback if the source doesn't re-transmit. > > Also, if retransmit is REQUIRED, and the media is gatewayed to other > sources (non-webrtc), and they don't support retransmit (likely), > then the gateway would need to buffer and act as a retransmit agent > (complicating the gateway). If it's RECOMMENDED, this is not a big > deal and the gateway can stay simpler. > > > Sure, that's a downside, and that may be a good enough reason for > RECOMMENDED. The same goes for #3, right? Non-webrtc sources may not > support long-term references and therefore have to rely on IDRs. Yup, and most do today. The point is you report the loss as best you can (PLI, etc) and let the sender fix it as best it can. I do think this is a strong argument for RECOMMEND (or even something less strong). We could of course REQUIRE support but warn that even if supported, and endpoint might not agree to retransmits. It does make the position of a gateway to this clause ... interesting, but in practice it could reject re-xmits unless it knows the non-webrtc source supports them. So this doesn't mandate RECOMMEND over REQUIRE, but it is justification for RECOMMEND. > Just saying that it would be nice to have a baseline which is something > better than requesting IDRs. Yes. But I don't think this is in the purview of the spec, unless you want to tie it to congestion control issues. -- Randell Jesup randell-ietf@jesup.org From holmer@google.com Mon Jul 2 00:49:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326A721F8ABF for ; Mon, 2 Jul 2012 00:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.577 X-Spam-Level: X-Spam-Status: No, score=-100.577 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWBr1E9CzyEM for ; Mon, 2 Jul 2012 00:49:25 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 88E8121F8ABE for ; Mon, 2 Jul 2012 00:49:25 -0700 (PDT) Received: by yhfq11 with SMTP id q11so4632215yhf.15 for ; Mon, 02 Jul 2012 00:49: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:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=WHwAaYMGA6ET+eKc+fETVRq9j2ni3cdkLbg0rz6qRoo=; b=KoZbE12WBqGZzIrf7RVBjD1aE08CtbapwhoKR4+3XgXPoGU2wawtG/0AiAC+vF+J4H DNGHMDslpR67Idp8qKJWVzrQDxFK15KPed0/06CaIrQ9jQ3PoI8ixmja/PkVPNFAYeXp v7odM1Tj2h9ulZvMHjp2kSzsWjmwUrPeVNNelSBqXZ9LWuEvk3OHX7yVgZIozDcgeBon xFpq9kAUADLrQ3TxHUCdW5iyb9c64TPT0/rMgNFH9UkQZmObXqb6uWE1PxQWJGQuXUnE ul/fREgM2XrH3EKnMvp1VSKiJ7PWZC2ejYUbK2kpV3D/+gkxGAIbjTvn16O6N6KvvLFD MGgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=WHwAaYMGA6ET+eKc+fETVRq9j2ni3cdkLbg0rz6qRoo=; b=MBzGArxy35lr3AproysEXbxCCWMR+Q3P/Oq5T5PNX0h8Ad5duEWlAnejGAHYWmttzY iw93ZD9wma/YDEM6e07Mf1uoo8iSXipkiyiznWZGz21cRMT5ewKjitpAvm8q9upX20aH GJok7W1eUDmR0A/3gY2JgHxvEVRh7YjtMP9YoFxR55V/yv3Tb2Ri73pWUBWy14G4Qlz7 szN0MHmsY4GA+BOwQ1ppau1tObZe1OtJ1YfWdXmdNwIA0B4m38P94WU782zI1kcUXKP+ ewS6ExlXq5aty3Mi3viSAmk5wJrq7hSW/dgqp7QafZao8EMZwK65FeL5zhDxQpCr1z02 +aPA== Received: by 10.50.168.1 with SMTP id zs1mr6678630igb.45.1341215369127; Mon, 02 Jul 2012 00:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.168.1 with SMTP id zs1mr6678624igb.45.1341215368969; Mon, 02 Jul 2012 00:49:28 -0700 (PDT) Received: by 10.50.108.103 with HTTP; Mon, 2 Jul 2012 00:49:28 -0700 (PDT) In-Reply-To: <4FF14C97.4060005@jesup.org> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <4FEFF1B6.6050504@jesup.org> <4FF14C97.4060005@jesup.org> Date: Mon, 2 Jul 2012 09:49:28 +0200 Message-ID: From: Stefan Holmer To: Randell Jesup Content-Type: multipart/alternative; boundary=e89a8f83a613a27dde04c3d40958 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkOXQmHC/mclpjVUwQLuiGXEH7Cw4U/bM3RQvKtHrRome+ZpVPrhhjPzFjSjkt81Qtabjw2sqsqGs2nEuQGUH2svVhjibJCm9SIUffwa6ZjbXBx5ccjuWbRaA8ZSoTh5Wh63Nsq56mydlSK4gD15bVwe3XEf44xsm012W3E65zYOjTF+hg= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 07:49:27 -0000 --e89a8f83a613a27dde04c3d40958 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 2, 2012 at 9:24 AM, Randell Jesup wrote: > On 7/1/2012 8:17 AM, Stefan Holmer wrote: > >> >> >> On Sun, Jul 1, 2012 at 8:44 AM, Randell Jesup > > wrote: >> >> On 6/29/2012 3:30 AM, Stefan Holmer wrote: >> >> Doesn't this in the end boil down to what tools we have for >> baseline >> resilience? Retransmissions are fairly easy to implement and will >> in >> most cases give a much better experience than for example relying >> on >> periodic key frames or doing key frame requests. Also it isn't >> necessary >> for the decoder to support decoding streams with lost packets. >> >> >> "Better experience" incorporates a bunch of assumptions. >> >> Assuming we're talking video only: >> >> If you want it to be seamless, you have to be running a jitter >> buffer depth of at least 1 RTT plus >> time-to-decide-packet-may-be-_**_lost plus random-constant. The >> >> second part of that can be tricky and network-state dependent. On >> corporate networks, I'd see sudden 100ms changes in base delay over >> 1-3 packets; a short time-to-decide would flag each of those as >> missing. This is ok (the re-xmit will get ignored as a dup), but >> adds packets at an apparent bad point for the network. >> >> That said, small RTTs certainly happen within LANs and corporations, >> and between neighbors in a single provider often. >> >> Note that often/normally with small RTTs you also get reasonably >> small jitter, and thus the adaptive jitter buffer might run very >> small numbers, so one might need to put a lower limit on the jitter >> buffer in these cases. >> >> The alternatives: >> >> 1) request re-xmit and freeze video queue when the jitter buffer >> runs dry. If the packet comes in ASAP, freeze <= RTT+constant >> (modulo application scheduling delay at the sender side). Then you >> can repair the broken frame, decode it, and then decode any >> following frames. Typically after a freeze you drop a frame or more; >> you might end up showing some of them depending on decode speed and >> how long the freeze lasted. If the re-xmit (or the request) is >> lost, then delays can stretch much longer, since you need to wait >> RTT+bigger constant before requesting again. >> >> >> Yes, this is what I would consider the simplest approach, which leads to >> a system which can guarantee a complete stream thus not requiring the >> decoder to be able to decode with errors, and at the same time having a >> good chance of recovering within slightly longer than one RTT. >> > > Simple, yes. There are aspects of this I don't like: > > * Frozen for minimum of 1RTT+. With 100ms RTT, you're probably at a > minimum of 4 frames, perhaps 5, and if you lose another packet during those > frames, it will move forward but not catch up sync, which can lead to > jerky, out of sync video. If you lose a re-xmit packet, you're talking > minimum 2x the delay (and in reality a fair bit more because you have to > decide when to ask for a re-re-xmit...). > * Decoding with errors: not generally a problem. The issue is whether you > prefer (or think the users prefer) a short (1 frame) freeze plus > 1RTT-1frame-ish period with motion but errors, or a 1+RTT min freeze, > maybe/occasionally much more. Our experience at WorldGate was that keeping > motion active was preferable to freezing or worse loss of sync, even if > there are errors. > Yes, it doesn't solve all problems. > > That conclusion is debatable, and the answer may vary according to RTT, > type of call, resolution, bandwidth, type of application, and isn't > something the IETF should mandate here. > > > 2) request IDR (or refresh of corrupted slice). Downside here is >> that you need to wait for the next frame encode at the sender side >> (so 0-33ms normally, or perhaps 0-100ms), and then the frame >> typically takes many packets to send (which also may be lost, and >> take time to receive especially on low-BW links), and IDR initial >> quality may be noticeably lower. The receiver may freeze the video >> until the IDR is received or keep decoding with errors. If there's >> a significant chance of the IDR losing a packet, a freeze could be >> substantial time. >> >> >> If the losses are related to congestion, sending an IDR is usually a bad >> idea. And as you are saying, if the losses are due to corruption, the >> chance of having a loss in an IDR is much bigger than for a P-frame. I >> don't think this approach is nearly as good as retransmissions, but it >> is a possible baseline option. >> > > Agreed, though in practice if you're not getting hammered with high loss > and you keep the quantization high on the IDR, it will usually get through. > Obviously as bitrates increase the number of packets in the IDR goes up, > and risk of loss in the IDR goes up. If correction is only for a slice, > this risk may not be high. > > > 3) request repair. Note that #2 and #3 may be the same at the >> receiver side, with the sender deciding the best available repair. >> In this case, the sender would instead of an IDR use a some other >> set of (smaller) packets to create an error-free up-to-date state at >> the receiver, such as encoding using a long-term-reference-frame, or >> using some other known-error-free frame in the receiver. Note that >> repair is basically just a normal p-frame, albeit with somewhat >> lower quality and/or somewhat higher bandwidth used. A big plus is >> that the end state is close to the same as re-transmit, but you >> don't have to speed through decoding any skipped frames. Repair >> also allows the receiver to use alternate recovery mechanisms than >> simply freezing, including simply continuing to decode p-frames >> ignoring the lost frame. This induces artifacts, but keeps motion >> loss to a minimum, especially in longer-RTT links. >> >> >> Yes, I agree that this is also a good approach. It may be more expensive >> than #1 if the long-term reference is old, but in general this would be >> a good baseline as well. >> > > There are mechanisms in VP8 that can be leveraged here. > > Yes. > > It is possible to continue decoding p-frames, ignoring the loss, with >> retransmissions as well. However it's a bit more complicated and you >> will have to speed through some frames at the decoder when the rtx >> arrives, although you can skip rendering them. >> > > Yes, you'd have to clone the decoder state at the loss point in order to > "rewind" and then correct. > > > >> >> Note that #3 in particular should result in similar freeze length as >> #1, perhaps 1 frame longer, if it freezes. If it plays with errors >> instead, the freeze is typically 1 frame (the lost one). >> >> (Others?) >> >> My normal preference is #3. But, as discussed above, in low-RTT >> networks it may be a good option and might give 0-frames of freeze. >> But, you still have all the complexities about how to decide when >> and how to use re-xmit; I think the 1 frame freeze is a reasonable >> option and a reasonable fallback if the source doesn't re-transmit. >> >> Also, if retransmit is REQUIRED, and the media is gatewayed to other >> sources (non-webrtc), and they don't support retransmit (likely), >> then the gateway would need to buffer and act as a retransmit agent >> (complicating the gateway). If it's RECOMMENDED, this is not a big >> deal and the gateway can stay simpler. >> >> >> Sure, that's a downside, and that may be a good enough reason for >> RECOMMENDED. The same goes for #3, right? Non-webrtc sources may not >> support long-term references and therefore have to rely on IDRs. >> > > Yup, and most do today. The point is you report the loss as best you can > (PLI, etc) and let the sender fix it as best it can. > Yes, that is nice with #3, and if we can assume most endpoints will support #3 I agree that is the way to go, even though the baseline (hopefully used for a very small %) will have to be IDRs. > > I do think this is a strong argument for RECOMMEND (or even something less > strong). We could of course REQUIRE support but warn that even if > supported, and endpoint might not agree to retransmits. It does make the > position of a gateway to this clause ... interesting, but in practice it > could reject re-xmits unless it knows the non-webrtc source supports them. > So this doesn't mandate RECOMMEND over REQUIRE, but it is justification > for RECOMMEND. > > Just saying that it would be nice to have a baseline which is something >> better than requesting IDRs. >> > > Yes. But I don't think this is in the purview of the spec, unless you > want to tie it to congestion control issues. > > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --e89a8f83a613a27dde04c3d40958 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 2, 2012 at 9:24 AM, Randell = Jesup <randell-ietf@jesup.org> wrote:
On 7/1/2012 8:17 AM, Stefan Holmer wrote:


On Sun, Jul 1, 2012 at 8:44 AM, Randell Jesup <randell-ietf@jesup.org
<mailto:rand= ell-ietf@jesup.org>> wrote:

=A0 =A0 On 6/29/2012 3:30 AM, Stefan Holmer wrote:

=A0 =A0 =A0 =A0 Doesn't this in the end boil down to what tools we have= for baseline
=A0 =A0 =A0 =A0 resilience? Retransmissions are fairly easy to implement an= d will in
=A0 =A0 =A0 =A0 most cases give a much better experience than for example r= elying on
=A0 =A0 =A0 =A0 periodic key frames or doing key frame requests. Also it is= n't
=A0 =A0 =A0 =A0 necessary
=A0 =A0 =A0 =A0 for the decoder to support decoding streams with lost packe= ts.


=A0 =A0 "Better experience" incorporates a bunch of assumptions.<= br>
=A0 =A0 Assuming we're talking video only:

=A0 =A0 If you want it to be seamless, you have to be running a jitter
=A0 =A0 buffer depth of at least 1 RTT plus
=A0 =A0 time-to-decide-packet-may-be-__lost plus random-constant. = =A0The

=A0 =A0 second part of that can be tricky and network-state dependent. =A0O= n
=A0 =A0 corporate networks, I'd see sudden 100ms changes in base delay = over
=A0 =A0 1-3 packets; a short time-to-decide would flag each of those as
=A0 =A0 missing. =A0This is ok (the re-xmit will get ignored as a dup), but=
=A0 =A0 adds packets at an apparent bad point for the network.

=A0 =A0 That said, small RTTs certainly happen within LANs and corporations= ,
=A0 =A0 and between neighbors in a single provider often.

=A0 =A0 Note that often/normally with small RTTs you also get reasonably =A0 =A0 small jitter, and thus the adaptive jitter buffer might run very =A0 =A0 small numbers, so one might need to put a lower limit on the jitter=
=A0 =A0 buffer in these cases.

=A0 =A0 The alternatives:

=A0 =A0 1) request re-xmit and freeze video queue when the jitter buffer =A0 =A0 runs dry. =A0If the packet comes in ASAP, freeze <=3D RTT+consta= nt
=A0 =A0 (modulo application scheduling delay at the sender side). =A0Then y= ou
=A0 =A0 can repair the broken frame, decode it, and then decode any
=A0 =A0 following frames. Typically after a freeze you drop a frame or more= ;
=A0 =A0 you might end up showing some of them depending on decode speed and=
=A0 =A0 how long the freeze lasted. =A0If the re-xmit (or the request) is =A0 =A0 lost, then delays can stretch much longer, since you need to wait =A0 =A0 RTT+bigger constant before requesting again.


Yes, this is what I would consider the simplest approach, which leads to a system which can guarantee a complete stream thus not requiring the
decoder to be able to decode with errors, and at the same time having a
good chance of recovering within slightly longer than one RTT.

Simple, yes. =A0There are aspects of this I don't like:

* Frozen for minimum of 1RTT+. =A0With 100ms RTT, you're probably at a = minimum of 4 frames, perhaps 5, and if you lose another packet during those= frames, it will move forward but not catch up sync, which can lead to jerk= y, out of sync video. =A0If you lose a re-xmit packet, you're talking m= inimum 2x the delay (and in reality a fair bit more because you have to dec= ide when to ask for a re-re-xmit...).
* Decoding with errors: not generally a problem. =A0The issue is whether yo= u prefer (or think the users prefer) a short (1 frame) freeze plus 1RTT-1fr= ame-ish period with motion but errors, or a 1+RTT min freeze, maybe/occasio= nally much more. =A0Our experience at WorldGate was that keeping motion act= ive was preferable to freezing or worse loss of sync, even if there are err= ors.

Yes, it doesn't solve all problems.
=A0

That conclusion is debatable, and the answer may vary according to RTT, typ= e of call, resolution, bandwidth, type of application, and isn't someth= ing the IETF should mandate here.


=A0 =A0 2) request IDR (or refresh of corrupted slice). =A0Downside here is=
=A0 =A0 that you need to wait for the next frame encode at the sender side<= br> =A0 =A0 (so 0-33ms normally, or perhaps 0-100ms), and then the frame
=A0 =A0 typically takes many packets to send (which also may be lost, and =A0 =A0 take time to receive especially on low-BW links), and IDR initial =A0 =A0 quality may be noticeably lower. =A0The receiver may freeze the vid= eo
=A0 =A0 until the IDR is received or keep decoding with errors. =A0If there= 's
=A0 =A0 a significant chance of the IDR losing a packet, a freeze could be<= br> =A0 =A0 substantial time.


If the losses are related to congestion, sending an IDR is usually a bad idea. And as you are saying, if the losses are due to corruption, the
chance of having a loss in an IDR is much bigger than for a P-frame. I
don't think this approach is nearly as good as retransmissions, but it<= br> is a possible baseline option.

Agreed, though in practice if you're not getting hammered with high los= s and you keep the quantization high on the IDR, it will usually get throug= h. =A0Obviously as bitrates increase the number of packets in the IDR goes = up, and risk of loss in the IDR goes up. =A0If correction is only for a sli= ce, this risk may not be high.


=A0 =A0 3) request repair. =A0Note that #2 and #3 may be the same at the =A0 =A0 receiver side, with the sender deciding the best available repair.<= br> =A0 =A0 =A0 In this case, the sender would instead of an IDR use a some oth= er
=A0 =A0 set of (smaller) packets to create an error-free up-to-date state a= t
=A0 =A0 the receiver, such as encoding using a long-term-reference-frame, o= r
=A0 =A0 using some other known-error-free frame in the receiver. =A0Note th= at
=A0 =A0 repair is basically just a normal p-frame, albeit with somewhat
=A0 =A0 lower quality and/or somewhat higher bandwidth used. =A0A big plus = is
=A0 =A0 that the end state is close to the same as re-transmit, but you
=A0 =A0 don't have to speed through decoding any skipped frames. =A0Rep= air
=A0 =A0 also allows the receiver to use alternate recovery mechanisms than<= br> =A0 =A0 simply freezing, including simply continuing to decode p-frames
=A0 =A0 ignoring the lost frame. =A0This induces artifacts, but keeps motio= n
=A0 =A0 loss to a minimum, especially in longer-RTT links.


Yes, I agree that this is also a good approach. It may be more expensive than #1 if the long-term reference is old, but in general this would be
a good baseline as well.

There are mechanisms in VP8 that can be leveraged here.

Yes.
=A0

It is possible to continue decoding p-frames, ignoring the loss, with
retransmissions as well. However it's a bit more complicated and you will have to speed through some frames at the decoder when the rtx
arrives, although you can skip rendering them.

Yes, you'd have to clone the decoder state at the loss point in order t= o "rewind" and then correct.




=A0 =A0 Note that #3 in particular should result in similar freeze length a= s
=A0 =A0 #1, perhaps 1 frame longer, if it freezes. =A0If it plays with erro= rs
=A0 =A0 instead, the freeze is typically 1 frame (the lost one).

=A0 =A0 (Others?)

=A0 =A0 My normal preference is #3. But, as discussed above, in low-RTT
=A0 =A0 networks it may be a good option and might give 0-frames of freeze.=
=A0 =A0 =A0 But, you still have all the complexities about how to decide wh= en
=A0 =A0 and how to use re-xmit; I think the 1 frame freeze is a reasonable<= br> =A0 =A0 option and a reasonable fallback if the source doesn't re-trans= mit.

=A0 =A0 Also, if retransmit is REQUIRED, and the media is gatewayed to othe= r
=A0 =A0 sources (non-webrtc), and they don't support retransmit (likely= ),
=A0 =A0 then the gateway would need to buffer and act as a retransmit agent=
=A0 =A0 (complicating the gateway). =A0If it's RECOMMENDED, this is not= a big
=A0 =A0 deal and the gateway can stay simpler.


Sure, that's a downside, and that may be a good enough reason for
RECOMMENDED. The same goes for #3, right? Non-webrtc sources may not
support long-term references and therefore have to rely on IDRs.

Yup, and most do today. =A0The point is you report the loss as best you can= (PLI, etc) and let the sender fix it as best it can.
=
Yes, that is nice with #3, and if we can assume most endpoin= ts will support #3 I agree that is the way to go, even though the baseline = (hopefully used for a very small %) will have to be IDRs.
=A0

I do think this is a strong argument for RECOMMEND (or even something less = strong). =A0We could of course REQUIRE support but warn that even if suppor= ted, and endpoint might not agree to retransmits. =A0It does make the posit= ion of a gateway to this clause ... interesting, but in practice it could r= eject re-xmits unless it knows the non-webrtc source supports them. =A0So t= his doesn't mandate RECOMMEND over REQUIRE, but it is justification for= RECOMMEND.


Just saying that it would be nice to have a baseline which is something
better than requesting IDRs.

Yes. =A0But I don't think this is in the purview of the spec, unless yo= u want to tie it to congestion control issues.


--
Randell Jesup
randell-ietf@je= sup.org

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

--e89a8f83a613a27dde04c3d40958-- From oej@edvina.net Mon Jul 2 00:50:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEF121F8AC2 for ; Mon, 2 Jul 2012 00:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3psHr0hrvg8S for ; Mon, 2 Jul 2012 00:50:32 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4D54D21F8AB8 for ; Mon, 2 Jul 2012 00:50:31 -0700 (PDT) Received: from [192.168.40.27] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5B1D7754A8AA; Mon, 2 Jul 2012 07:50:34 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Mon, 2 Jul 2012 09:38:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 07:50:36 -0000 29 jun 2012 kl. 17:11 skrev Cullen Jennings: >=20 > Right - so on the question of it retransmission is mandatory to = implement for audio codec, I am on a definitely "No". The bulk of = systems today do not do it and work fine. Vendors can easily choose to = do if they want in an interoperable way with out it being MTI. Why we = should add a bunch of stuff in to version 1 of this that we can live = without is beyond me. This is how IPv6 got big and hard, by everyone = taking their favorite technology and attaching it to v6. I don't even = want it as RECOMMENDED for audio - I see it as OPTIONAL.=20 Agree. We need a base level of interoperability. >=20 > I probably feel differently about video.=20 Maybe. Current video have the frame update requests. ugly, but works in = most cases. I see reasons for retransmission of video, but not to make = it recommended or required. /O >=20 >=20 > On Jun 28, 2012, at 23:43 , Magnus Westerlund wrote: >=20 >> On 2012-06-28 16:36, Cullen Jennings wrote: >>>=20 >>> I think you need to separate this for audio and video and be far = more >>> specific about what type of retransmit ion you are talking about. In >>> many cases the retransmit ion schemes for audio make the end suer >>> experience worse. >>=20 >> I am not disagreeing unless the RTT is really low. >>=20 >> What I am asking the WG is if RTP retransmission is a RECOMMENDED or >> REQUIRED feature in the toolbox that an WebRTC end-point supports. = This >> says nothing on when you select to use it and on which media. If we = want >> to include such recommendations we can do it. In fact the RTP usage >> draft has a bit on text discussing the issue with RTT. >>=20 >> Cheers >>=20 >> Magnus >> (As WG chair) >>=20 >>>=20 >>> On Jun 27, 2012, at 24:36 , Magnus Westerlund wrote: >>>=20 >>>> WG, >>>>=20 >>>> We had a discussion at the interim if RTP Retransmission is to be=20= >>>> considered REQUIRED or RECOMMENDED to implement. I would like to >>>> see if we can first have some discussion on this topic before >>>> moving on to see if we can get a consensus here on the mailing >>>> list. >>>>=20 >>>> Please provide your views on this topic. >>>>=20 >>>> Cheers >>>>=20 >>>> Magnus Westerlund (As Chair and document editor) >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>>=20 >>>>=20 >> Multimedia Technologies, Ericsson Research EAB/TVM >>>> = ---------------------------------------------------------------------- >>>>=20 >>>>=20 >> 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 >>>> = ---------------------------------------------------------------------- >>>>=20 >>>>=20 >>>>=20 >>>>=20 >> _______________________________________________ >>>> rtcweb mailing list rtcweb@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>>=20 >>=20 >>=20 >> --=20 >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> 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 >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From juberti@google.com Mon Jul 2 13:00:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8790911E80DB for ; Mon, 2 Jul 2012 13:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.616 X-Spam-Level: X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw85VJ9SQyjj for ; Mon, 2 Jul 2012 13:00:34 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9BE11E80A3 for ; Mon, 2 Jul 2012 13:00:32 -0700 (PDT) Received: by qaea16 with SMTP id a16so2120998qae.10 for ; Mon, 02 Jul 2012 13:00: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:x-system-of-record; bh=xzFAIoHykDjoaTLkaiMdPyh2GQC5fh1pV72NRzUbjcM=; b=KJKrHmOmz67993zHY+IrRfqYNdkiUKtsECCfEUyM8qJ/SXSA5GL7xKTwGaDnGfCJgQ ZVXr/yT98c7qrtGPOD1mz+UYZxWuDr/rcn1hN6q9ezqtibRrhajRemzwyfNKkUQI11fp lvI0ZbwYIVX9yOaeY+SQUl69vDqd+2aQymIbSu4UnZ+n/IsMuUvyESLdo2HjYg8cnCJY pObx5ANVvG6q1EBVv5kjpzx/OJKyz8k2Fwt5LA7uDl0jroSHaNFnl7Xc6o6apLYcUDXy R5hX/otbbl/bD5kKc3IqtPot77ZGNDVL32U7yKMBCJ3n7fQxqleiFS7y7AKEvYAZczhg S0Iw== X-Google-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:x-system-of-record:x-gm-message-state; bh=xzFAIoHykDjoaTLkaiMdPyh2GQC5fh1pV72NRzUbjcM=; b=STjR2rE4TYK+Q027dGpybaj7e8U9NJlzJ2d5aetYlOwvDLxEkBNEYbShf7bNAYQPPB 4cdc5kf9PW92mZDsQ6gltYYstm3nUAaURfzo3B5rHedzHj37ZOwNZZ5DXn5aReHx0Yw1 xMbcaEe+jsu4eafWDxaO3oJ11q5+qUsT45vbNRUZT6rrSBTXlGa0kfQ5SFgYeLgP2m4Y UZHyMpbgx4NOD6xBj7W8d4Pvfds63yA/BqJOXVCqGVALk2g/cU/bXrpC5ezV9KpsMlmN 6DmXDV/HfaENWz07wYYpwsZkv0tRbFI2WCC129bZy2sMbJd3GSgAMvKtklubSRFayTgg TH8w== Received: by 10.224.220.17 with SMTP id hw17mr2246613qab.89.1341259238247; Mon, 02 Jul 2012 13:00:38 -0700 (PDT) Received: by 10.224.220.17 with SMTP id hw17mr2246604qab.89.1341259238100; Mon, 02 Jul 2012 13:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.211 with HTTP; Mon, 2 Jul 2012 13:00:17 -0700 (PDT) In-Reply-To: <4FEEF614.6090507@jesup.org> References: <4FD6D566.6060806@alvestrand.no> <4FD7A356.2010406@ericsson.com> <4FD83C21.4080701@alvestrand.no> <4FD85D78.1040103@jesup.org> <929BD935-0E8F-4985-9E51-9E213B0C6841@cisco.com> <4FE4A6B2.7020601@alvestrand.no> <8F1A4041-E7E8-49D4-A77B-EDFF1F5A617C@cisco.com> <4FEEF614.6090507@jesup.org> From: Justin Uberti Date: Mon, 2 Jul 2012 13:00:17 -0700 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=20cf3071d1c87050dc04c3de40d8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnlK3JBnvRcy+bdKhsgiUuKHgzLVdl4Ikh4AbvkmTeBw7RnqEf5psccWfssbSG+lGDTMKAhNgS3qK7gdeNrXEx0d9fL74jyCYCBWXsHTxsFxJeLSMV1hnCIEXbjie2vcHGSyjaTjJKzH5SFptVL7eOvHtn+A4he09gcb9vv5XQFrUsMrkA= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Target numbers for setup time (Re: Keeping up data channel) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 20:00:35 -0000 --20cf3071d1c87050dc04c3de40d8 Content-Type: text/plain; charset=UTF-8 We can certainly make the API allow instant creation of a data channel, but the thing I'm bringing up is the , which is currently the long pole in establishing a p2p flow. That's where 6 RTTs are coming from. Agree with Harald that this is an IETF matter though. On Sat, Jun 30, 2012 at 5:50 AM, Randell Jesup wrote: > On 6/28/2012 3:49 PM, Cullen Jennings (fluffy) wrote: > >> Agree - that's why I think this has to be done in zero RTT. I don't see >> any problem with setting up a data channel and being ready to send media >> before having the UI tell the user they are "connected and can start >> talking". >> > > I agree, and have suggested this as well, but it's really in the > application domain (though we can give examples that use it and recommend > it). There are some mild security concerns with accepting the data-only > connection before user decision, but manageable I believe. > > Roughly: call start (user) > caller-> Offer(SDP(data-only)) as "setup" -> server -> answerer > (also indicate if it's audio-only or audio+video) > (maybe offer data+audio (and video) to warm up ICE candidates) > answerer -> Answer (SDP(data-only)) as "setup" -> server -> answerer > answerer -> alert user > caller-> install Answer > > caller-> Offer(SDP(data+media)) as "call" -> answerer (over > "negotiation" channel) > ... > answerer (user) accepts > answerer-> Answer(SDP(data+media)) as "call" -> caller (over > "negotiation" channel) > answerer starts sending > caller installs Answer > caller media starts sending > > From user accepts -> media starts, it's 0 RTT for answer sending, 1 RTT > until he sees media from the caller, which is pretty much close to > theoretical minimum. (You can do better only by starting media channels > "in the background" from the caller before user accepts, perhaps with an > Answer(SDP(data+receive-only-**media)).) > > Again, I believe this is all possible in the application domain today with > the spec. > > >> Reducing from 7 RTT to 5 RTT does not help when you need to get to 0 RTT. >> >> On Jun 22, 2012, at 10:09 , Harald Alvestrand wrote: >> >> On 06/22/2012 05:58 PM, Cullen Jennings (fluffy) wrote: >>> >>>> On Jun 13, 2012, at 5:29 , Randell Jesup wrote: >>>> >>>> How far down do you think we have to drive the setup time before you >>>>>> would not call it "abysmal"? >>>>>> >>>>> I'd probably consider above 250 ms abysmal but good news I don't see >>>> any problem with getting it down around 100 ms in when both endpoints are >>>> in a single country. >>>> >>>> Coast-to-coast US is ~4800 km, so RTT (9600 km) is 32 ms (speed of >>> light is 300 km/msec). >>> >>> So, without considering processing time, 3 RTT is 100 msec, 7 RTT is >>> "abysmal". >>> >>> There are bigger countries than the US, but this will do for a >>> back-of-the-envelope. >>> >>> -- >>> Randell Jesup >>> randell-ietf@jesup.org >>> >> ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --20cf3071d1c87050dc04c3de40d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We can certainly make the API allow instant creation of a data channel, but= the thing I'm bringing up is the <N RTT of data channel setup>, = which is currently the long pole in establishing a p2p flow. That's whe= re 6 RTTs are coming from.

Agree with Harald that this is an IETF matter though.
<= div class=3D"gmail_extra">

On Sat, Jun 30= , 2012 at 5:50 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 6/28/2012 3:49 PM, Cull= en Jennings (fluffy) wrote:
Agree - that's why I think this has to be done in zero RTT. I don't= see any problem with setting up a data channel and being ready to send med= ia before having the UI tell the user they are "connected and can star= t talking".

I agree, and have suggested this as well, but it's really in the applic= ation domain (though we can give examples that use it and recommend it). = =C2=A0There are some mild security concerns with accepting the data-only co= nnection before user decision, but manageable I believe.

Roughly: call start (user)
=C2=A0 =C2=A0 =C2=A0caller-> Offer(SDP(data-only)) as "setup" = -> server -> answerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (also indicate if it's audio-= only or audio+video)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (maybe offer data+audio (and vide= o) to warm up ICE candidates)
=C2=A0 =C2=A0 =C2=A0answerer -> Answer (SDP(data-only)) as "setup&q= uot; -> server -> answerer
=C2=A0 =C2=A0 =C2=A0answerer -> alert user
=C2=A0 =C2=A0 =C2=A0caller-> install Answer
=C2=A0 =C2=A0 =C2=A0<N RTT of data channel setup setting up "negoti= ation" channel>
=C2=A0 =C2=A0 =C2=A0caller-> Offer(SDP(data+media)) as "call" = -> answerer (over "negotiation" channel)
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0answerer (user) accepts
=C2=A0 =C2=A0 =C2=A0answerer-> Answer(SDP(data+media)) as "call&quo= t; -> caller (over "negotiation" channel)
=C2=A0 =C2=A0 =C2=A0answerer starts sending
=C2=A0 =C2=A0 =C2=A0caller installs Answer
=C2=A0 =C2=A0 =C2=A0caller media starts sending

>From user accepts -> media starts, it's 0 RTT for answer sending, 1 = RTT until he sees media from the caller, which is pretty much close to theo= retical minimum. =C2=A0(You can do better only by starting media channels &= quot;in the background" from the caller before user accepts, perhaps w= ith an Answer(SDP(data+receive-only-media)).)

Again, I believe this is all possible in the application domain today with = the spec.


Reducing from 7 RTT to 5 RTT does not help when you need to get to 0 RTT.
On Jun 22, 2012, at 10:09 , Harald Alvestrand wrote:

On 06/22/2012 05:58 PM, Cullen Jennings (fluffy) wrote:
On Jun 13, 2012, at 5:29 , Randell Jesup wrote:

How far down do you think we have to drive the setup time before you
would not call it "abysmal"?
I'd probably consider above 250 ms abysmal but good news I don't se= e any problem with getting it down around 100 ms in when both endpoints are= in a single country.

Coast-to-coast US is ~4800 km, so RTT (9600 km) is 32 ms (speed of light is= 300 km/msec).

So, without considering processing time, 3 RTT is 100 msec, 7 RTT is "= abysmal".

There are bigger countries than the US, but this will do for a back-of-the-= envelope.

--
Randell Jesup
randell-ietf@je= sup.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--20cf3071d1c87050dc04c3de40d8-- From juberti@google.com Mon Jul 2 13:18:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9F511E8080 for ; Mon, 2 Jul 2012 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHPQtz7PVadE for ; Mon, 2 Jul 2012 13:18:29 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5772C11E8083 for ; Mon, 2 Jul 2012 13:18:29 -0700 (PDT) Received: by qaea16 with SMTP id a16so2129678qae.10 for ; Mon, 02 Jul 2012 13:18:34 -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:x-system-of-record; bh=xflC9RKF4DQgEFpHcpfvQKXDPtSuY3C2ApAHftm+Kd8=; b=VY5sCA7QQhEw4Xy6mKCXlxbosUZsooyCygHw4K09m8GMfD8ltMAwOrRQbXkXqZwKtx D/jNTRz7wF7dPld6l3uyQAyl9b0Yhjcd+XyLsGvGHOr1xJVfE3ZFaQwR1TsPQOp+r2tE ILqLRcyv+hf6sOgnmN6OE9UKjgyFwratEKQZ++6T9BKmsiMWTXImgp11AQCzdRQT+g16 R845HY+kwjY40/GAPk++Ilpi9iaQOM3chBSWcg9RhHGet1/BhfOKowgjKMLbE833k0lq C62VDWzqVF6TNpff/ie3XU31BXT0tWjRN1tGgEEG2kNj3X87MIxtLjLBSx4x4aPdL+99 yELw== X-Google-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:x-system-of-record:x-gm-message-state; bh=xflC9RKF4DQgEFpHcpfvQKXDPtSuY3C2ApAHftm+Kd8=; b=WGLGdn9I+WbLBYovv6f8hKHxNDcW20QemICHETJSo7v8mPZdR6ocGbpsEdx5qbLaN4 l1Z/nEe+MpuT2nRENSu4Pgdbj0v+KUxkBe1GsnumWaoywD6t/TXihi5Q4F6atM4NOCtV 98F/r68lwDBe1WvpznkZ6r4GUsuEHIOcUZlfZrhZ/tsuQBFFWrnJvJdCL2gpUTNeWWDE T0DI2DlSTCyZacL0+Q53rAnjJJ506C/2uCm7bKtYC8QmGvYHOVIAilVqmwqkbWP9c0R6 RXJpnUZEndjal9+i1GT4ta6EqUpFiGJt/rf+71DR0FsvMNSreB1CSnPPZyEQYmlcehwq Kkbg== Received: by 10.229.105.141 with SMTP id t13mr6981498qco.118.1341260314598; Mon, 02 Jul 2012 13:18:34 -0700 (PDT) Received: by 10.229.105.141 with SMTP id t13mr6981483qco.118.1341260314358; Mon, 02 Jul 2012 13:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.211 with HTTP; Mon, 2 Jul 2012 13:18:13 -0700 (PDT) In-Reply-To: References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> From: Justin Uberti Date: Mon, 2 Jul 2012 13:18:13 -0700 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=00235429cfac96b56304c3de8074 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlOaI8ij5tJLmHfNU1Ur8BwzZthYvBQGiJiArIcbPxRKL6KMgzZ/4HbDie0icBiMKS5UPfmqS0PGtaykPs3JoCeDg3HJOhAEsdDjjaXlIldeLQ/sUml0kj5YyeLtj9hEEi+Hu10lwabRg7L7C17DTuO8p1KVPq3vazxZXHVbkVCs3npbss= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 20:18:30 -0000 --00235429cfac96b56304c3de8074 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As has been pointed out in this thread before, this discussion is not about mandating the USE of retransmission in realtime scenarios. It is simply trying to decide whether retransmission should be required to be present in the 'toolbox' of tools that WebRTC apps can expect to use, primarily where the app developer and runtime developer are separate (e.g. in a browser). Several people have pointed out scenarios and applications where retransmission (of video, not audio) works very well. Our experience matches this too. Typically we can locate a media gateway very close to all participants, meaning that a lost packet between GW and user can be detected and retransmitted fast enough to not be noticeable by the user. These applications, if they do not have access to retransmission, will be forced to use cruder methods of error recovery that are more noticeable to users, among other unpleasant effects. Given that the implementation cost of retransmission is fairly negligible (basically, a packet cache plus support for parsing NACK messages), and that is really the only reason NOT to support this functionality in the toolbox, I have a hard time understanding why we would not want to make this a MUST implement for WebRTC. Again, this is about making _support_ for retransmission a requirement, not _use_. --justin On Mon, Jul 2, 2012 at 12:38 AM, Olle E. Johansson wrote: > > 29 jun 2012 kl. 17:11 skrev Cullen Jennings: > > > > > Right - so on the question of it retransmission is mandatory to > implement for audio codec, I am on a definitely "No". The bulk of systems > today do not do it and work fine. Vendors can easily choose to do if they > want in an interoperable way with out it being MTI. Why we should add a > bunch of stuff in to version 1 of this that we can live without is beyond > me. This is how IPv6 got big and hard, by everyone taking their favorite > technology and attaching it to v6. I don't even want it as RECOMMENDED fo= r > audio - I see it as OPTIONAL. > Agree. We need a base level of interoperability. > > > > I probably feel differently about video. > Maybe. Current video have the frame update requests. ugly, but works in > most cases. I see reasons for retransmission of video, but not to make it > recommended or required. > > /O > > > > > > On Jun 28, 2012, at 23:43 , Magnus Westerlund wrote: > > > >> On 2012-06-28 16:36, Cullen Jennings wrote: > >>> > >>> I think you need to separate this for audio and video and be far more > >>> specific about what type of retransmit ion you are talking about. In > >>> many cases the retransmit ion schemes for audio make the end suer > >>> experience worse. > >> > >> I am not disagreeing unless the RTT is really low. > >> > >> What I am asking the WG is if RTP retransmission is a RECOMMENDED or > >> REQUIRED feature in the toolbox that an WebRTC end-point supports. Thi= s > >> says nothing on when you select to use it and on which media. If we wa= nt > >> to include such recommendations we can do it. In fact the RTP usage > >> draft has a bit on text discussing the issue with RTT. > >> > >> Cheers > >> > >> Magnus > >> (As WG chair) > >> > >>> > >>> On Jun 27, 2012, at 24:36 , Magnus Westerlund wrote: > >>> > >>>> WG, > >>>> > >>>> We had a discussion at the interim if RTP Retransmission is to be > >>>> considered REQUIRED or RECOMMENDED to implement. I would like to > >>>> see if we can first have some discussion on this topic before > >>>> moving on to see if we can get a consensus here on the mailing > >>>> list. > >>>> > >>>> Please provide your views on this topic. > >>>> > >>>> Cheers > >>>> > >>>> Magnus Westerlund (As Chair and document editor) > >>>> > >>>> > >>>> --------------------------------------------------------------------= -- > >>>> > >>>> > >> Multimedia Technologies, Ericsson Research EAB/TVM > >>>> --------------------------------------------------------------------= -- > >>>> > >>>> > >> 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 > >>> > >>> > >> > >> > >> -- > >> > >> Magnus Westerlund > >> > >> ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> ---------------------------------------------------------------------- > >> 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 > > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00235429cfac96b56304c3de8074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As has been pointed out in this thread before, this discussion is not about= mandating the USE of retransmission in realtime scenarios. =C2=A0It is sim= ply trying to decide whether retransmission should be required to be presen= t in the 'toolbox' of tools that WebRTC apps can expect to use, pri= marily where the app developer and runtime developer are separate (e.g. in = a browser).

Several people have pointed out scenarios and applications w= here retransmission (of video, not audio) works very well. Our experience m= atches this too. Typically we can locate a media gateway very close to all = participants, meaning that a lost packet between GW and user can be detecte= d and retransmitted fast enough to not be noticeable by the user. These app= lications, if they do not have access to retransmission, will be forced to = use cruder methods of error recovery that are more noticeable to users, amo= ng other unpleasant effects.

Given that the implementation cost of retransmission is= fairly negligible (basically, a packet cache plus support for parsing NACK= messages), and that is really the only reason NOT to support this function= ality in the toolbox, I have a hard time understanding why we would not wan= t to make this a MUST implement for WebRTC.

Again, this is about making _support_ for retransmissio= n a requirement, not _use_.
--justin


On Mon, Jul 2, 2012 at 12:38 AM, Oll= e E. Johansson <oej@edvina.net> wrote:

29 jun 2012 kl. 17:11 skrev Cullen Jennings:

>
> Right - so on the question of it retransmission is mandatory to implem= ent for audio codec, I am on a definitely "No". The bulk of syste= ms today do not do it and work fine. Vendors can easily choose to do if the= y want in an interoperable way with out it being MTI. Why we should add a b= unch of stuff in to version 1 of this that we can live without is beyond me= . This is how IPv6 got big and hard, by everyone taking their favorite tech= nology and attaching it to v6. I don't even want it as RECOMMENDED for = audio - I see it as OPTIONAL.
Agree. We need a base level of interoperability.
>
> I probably feel differently about video.
Maybe. Current video have the frame update requests. ugly, but works = in most cases. I see reasons for retransmission of video, but not to make i= t recommended or required.

/O
>
>
> On Jun 28, 2012, at 23:43 , Magnus Westerlund wrote:
>
>> On 2012-06-28 16:36, Cullen Jennings wrote:
>>>
>>> I think you need to separate this for audio and video and be f= ar more
>>> specific about what type of retransmit ion you are talking abo= ut. In
>>> many cases the retransmit ion schemes for audio make the end s= uer
>>> experience worse.
>>
>> I am not disagreeing unless the RTT is really low.
>>
>> What I am asking the WG is if RTP retransmission is a RECOMMENDED = or
>> REQUIRED feature in the toolbox that an WebRTC end-point supports.= This
>> says nothing on when you select to use it and on which media. If w= e want
>> to include such recommendations we can do it. In fact the RTP usag= e
>> draft has a bit on text discussing the issue with RTT.
>>
>> Cheers
>>
>> Magnus
>> (As WG chair)
>>
>>>
>>> On Jun 27, 2012, at 24:36 , Magnus Westerlund wrote:
>>>
>>>> WG,
>>>>
>>>> We had a discussion at the interim if RTP Retransmission i= s to be
>>>> considered REQUIRED or RECOMMENDED to implement. I would l= ike to
>>>> see if we can first have some discussion on this topic bef= ore
>>>> moving on to see if we can get a consensus here on the mai= ling
>>>> list.
>>>>
>>>> Please provide your views on this topic.
>>>>
>>>> Cheers
>>>>
>>>> Magnus Westerlund (As Chair and document editor)
>>>>
>>>>
>>>> ----------------------------------------------------------= ------------
>>>>
>>>>
>> Multimedia Technologies, Ericsson Research EAB/TVM
>>>> ----------------------------------------------------------= ------------
>>>>
>>>>
>> 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 rtc= web@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>>
>> --
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ----
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ------------------------------------------------------------------= ----
>> 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

---
* Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden



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

--00235429cfac96b56304c3de8074-- From randell-ietf@jesup.org Mon Jul 2 14:52:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BD221F84C4 for ; Mon, 2 Jul 2012 14:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLL+pH7ykDdh for ; Mon, 2 Jul 2012 14:52:11 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1775E21F84C2 for ; Mon, 2 Jul 2012 14:52:10 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SloXX-0000SF-D3 for rtcweb@ietf.org; Mon, 02 Jul 2012 16:52:15 -0500 Message-ID: <4FF217DD.1060607@jesup.org> Date: Mon, 02 Jul 2012 17:51:25 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> 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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 21:52:17 -0000 On 7/2/2012 4:18 PM, Justin Uberti wrote: > As has been pointed out in this thread before, this discussion is not > about mandating the USE of retransmission in realtime scenarios. It is > simply trying to decide whether retransmission should be required to be > present in the 'toolbox' of tools that WebRTC apps can expect to use, > primarily where the app developer and runtime developer are separate > (e.g. in a browser). Do you expect to expose this choice to the application? (and all the data needed to make the choice...) Or have it be automatic? > Several people have pointed out scenarios and applications where > retransmission (of video, not audio) works very well. Our experience > matches this too. Typically we can locate a media gateway very close to > all participants, meaning that a lost packet between GW and user can be > detected and retransmitted fast enough to not be noticeable by the user. > These applications, if they do not have access to retransmission, will > be forced to use cruder methods of error recovery that are more > noticeable to users, among other unpleasant effects. Ok. This says that it's preferable to implement it, and if you have one of the situations that works well, use it. This sounds like a SHOULD to me, since other implementations (say an audio-only WebRTC<->PSTN gateway) may have little or no use for retransmission, or might reject it always. > Given that the implementation cost of retransmission is fairly > negligible (basically, a packet cache plus support for parsing NACK > messages), and that is really the only reason NOT to support this > functionality in the toolbox, I have a hard time understanding why we > would not want to make this a MUST implement for WebRTC. > > Again, this is about making _support_ for retransmission a requirement, > not _use_. If you don't mandate use, what does mandating "support" buy you? An implementation (see above about PSTN gateways) might always decline to use retransmission, so what does MUST (REQUIRE) buy you? I say SHOULD (RECOMMEND), with a statement that it's strongly recommended it be supported if video is supported, especially for non-single-purpose devices (i.e. browsers). In either case, you need to think about who decides to use re-xmit or not, what influences that, and if the app has visibility into this. Someone could as an rtx-time=0 to the SDP. Or not include one, but never actually retransmit a packet regardless of NACKs - it could just repair via IDR (or other means). So here's a real problem related to retransmission: since the request is not specific and negotiated (it's normally a generic NACK), the receiver who sent the NACK has no idea if it will get a retransmission, an IDR (or IDR slice), another form of repair (pframe/slice against known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, it doesn't know if it should freeze the video or play with errors. It has to decide if it *thinks* the sender will use retransmission, or if it doesn't, does the receiver want to freeze video until an IDR or other repair is done, which might be a while. We also need to think about when a receiver should use SLI or RPSI. PLI can also be used and should be if the other options don't negotiate (so it's important to offer it). Certainly it's more work to keep track of the contents of each packet (slices, etc), especially in things like H.264 NALU aggregation packets, than it is to just respond to an SLI. That said, my previous systems just used NACK and let the sender decide the correct repair, but I wasn't leveraging slices and wasn't using retransmission, so there was only minor complexity (looking at possible reference frames). -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Jul 2 15:07:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86A221F8613 for ; Mon, 2 Jul 2012 15:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc-NaRORf3Xk for ; Mon, 2 Jul 2012 15:07:34 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 4468921F8579 for ; Mon, 2 Jul 2012 15:07:34 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SlomS-00065Y-6Y for rtcweb@ietf.org; Mon, 02 Jul 2012 17:07:40 -0500 Message-ID: <4FF21B7B.8000102@jesup.org> Date: Mon, 02 Jul 2012 18:06:51 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD6D566.6060806@alvestrand.no> <4FD7A356.2010406@ericsson.com> <4FD83C21.4080701@alvestrand.no> <4FD85D78.1040103@jesup.org> <929BD935-0E8F-4985-9E51-9E213B0C6841@cisco.com> <4FE4A6B2.7020601@alvestrand.no> <8F1A4041-E7E8-49D4-A77B-EDFF1F5A617C@cisco.com> <4FEEF614.6090507@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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Target numbers for setup time (Re: Keeping up data channel) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 22:07:34 -0000 On 7/2/2012 4:00 PM, Justin Uberti wrote: > We can certainly make the API allow instant creation of a data channel, > but the thing I'm bringing up is the , > which is currently the long pole in establishing a p2p flow. That's > where 6 RTTs are coming from. Agreed we want to reduce N RTT wherever possible; I was showing how you could hide it for one class of applications (classic 'voip'-type telephony) and get fast media pickup on user answer. Both reducing and hiding are useful operations, though hiding is largely the purview of the application. This is also an argument for my "#3" case on the W3 webrtc list for the DataChannel DOM API, where we allow pre-defining channels (and send it in the SDP). > > Agree with Harald that this is an IETF matter though. -- Randell Jesup randell-ietf@jesup.org From g.kiranreddy4u@gmail.com Mon Jul 2 20:37:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597AC21F857A for ; Mon, 2 Jul 2012 20:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaHBWgicLvVK for ; Mon, 2 Jul 2012 20:37:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E869821F8585 for ; Mon, 2 Jul 2012 20:37:23 -0700 (PDT) Received: by yenq13 with SMTP id q13so5330408yen.31 for ; Mon, 02 Jul 2012 20:37: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:from:date:message-id:subject:to :content-type; bh=C9lX7LGSVLua6kLYo698VmtpIXpFxBu0kORVAsNCXfU=; b=dRtMJlQq8KsZA9fKNDuEIBd7cmyGmaG7MyJxBkoWw/p3pNUdTjhvH66ck3j8z4upP7 lfmUPUuPL2Zj6PoK5//w3G9nWGkaTV/xQyMBoC6UcnAFUrxfOdkpM+6l27RH3PgBNz4M rXujPehUaVygJxehm2rrFcmoaeORuqIpqcdvBlXlYcUyIZXM8iQqJe2R6GddfYap+eAA 8Xe5UGGMlEXhfIxHZKSx2uc0/coIQVH3FcgUj0kpxNN8tIu9c+p+R0QB6Q6YUUI8ARBQ 1jb+o/249EYs0KQJZ87VTkSC+RAI8qXutjqN3ikp4mTyDgfMAdkD1VCM80gbbQjgDXNt 6h9Q== Received: by 10.50.183.200 with SMTP id eo8mr7212496igc.63.1341286650086; Mon, 02 Jul 2012 20:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.47.195 with HTTP; Mon, 2 Jul 2012 20:37:09 -0700 (PDT) In-Reply-To: References: From: kiran kumar Date: Tue, 3 Jul 2012 09:07:09 +0530 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=14dae934043552044b04c3e4a219 Subject: Re: [rtcweb] rtcweb Digest, Vol 17, Issue 4 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 03:37:25 -0000 --14dae934043552044b04c3e4a219 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All, So far there are many supports and opposes for the implementation of retransmission in browser. Since according to Justin, since browser and app developers are different, apps have no control over retransmissions. IMO, can we think of to make this implemented in the browser and giving App to opt for this facility,if it requires, through peerConnection or some other API at the time of initiation. So that, facility will be prasent and its usage becomes application dependent. Thanks, Kiran. > ---------- Forwarded message ---------- > From: Justin Uberti > To: "Olle E. Johansson" > Cc: "rtcweb@ietf.org" > Date: Mon, 2 Jul 2012 13:18:13 -0700 > Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or > RECOMMENDED > As has been pointed out in this thread before, this discussion is not > about mandating the USE of retransmission in realtime scenarios. It is > simply trying to decide whether retransmission should be required to be > present in the 'toolbox' of tools that WebRTC apps can expect to use, > primarily where the app developer and runtime developer are separate (e.g= . > in a browser). > > Several people have pointed out scenarios and applications where > retransmission (of video, not audio) works very well. Our experience > matches this too. Typically we can locate a media gateway very close to a= ll > participants, meaning that a lost packet between GW and user can be > detected and retransmitted fast enough to not be noticeable by the user. > These applications, if they do not have access to retransmission, will be > forced to use cruder methods of error recovery that are more noticeable t= o > users, among other unpleasant effects. > > Given that the implementation cost of retransmission is fairly negligible > (basically, a packet cache plus support for parsing NACK messages), and > that is really the only reason NOT to support this functionality in the > toolbox, I have a hard time understanding why we would not want to make > this a MUST implement for WebRTC. > > Again, this is about making _support_ for retransmission a requirement, > not _use_. > --justin > > > On Mon, Jul 2, 2012 at 12:38 AM, Olle E. Johansson wrote= : > >> >> 29 jun 2012 kl. 17:11 skrev Cullen Jennings: >> >> > >> > Right - so on the question of it retransmission is mandatory to >> implement for audio codec, I am on a definitely "No". The bulk of system= s >> today do not do it and work fine. Vendors can easily choose to do if the= y >> want in an interoperable way with out it being MTI. Why we should add a >> bunch of stuff in to version 1 of this that we can live without is beyon= d >> me. This is how IPv6 got big and hard, by everyone taking their favorite >> technology and attaching it to v6. I don't even want it as RECOMMENDED f= or >> audio - I see it as OPTIONAL. >> Agree. We need a base level of interoperability. >> > >> > I probably feel differently about video. >> Maybe. Current video have the frame update requests. ugly, but works in >> most cases. I see reasons for retransmission of video, but not to make i= t >> recommended or required. >> >> /O >> > >> > >> > On Jun 28, 2012, at 23:43 , Magnus Westerlund wrote: >> > >> >> On 2012-06-28 16:36, Cullen Jennings wrote: >> >>> >> >>> I think you need to separate this for audio and video and be far mor= e >> >>> specific about what type of retransmit ion you are talking about. In >> >>> many cases the retransmit ion schemes for audio make the end suer >> >>> experience worse. >> >> >> >> I am not disagreeing unless the RTT is really low. >> >> >> >> What I am asking the WG is if RTP retransmission is a RECOMMENDED or >> >> REQUIRED feature in the toolbox that an WebRTC end-point supports. Th= is >> >> says nothing on when you select to use it and on which media. If we >> want >> >> to include such recommendations we can do it. In fact the RTP usage >> >> draft has a bit on text discussing the issue with RTT. >> >> >> >> Cheers >> >> >> >> Magnus >> >> (As WG chair) >> >> >> >>> >> >>> On Jun 27, 2012, at 24:36 , Magnus Westerlund wrote: >> >>> >> >>>> WG, >> >>>> >> >>>> We had a discussion at the interim if RTP Retransmission is to be >> >>>> considered REQUIRED or RECOMMENDED to implement. I would like to >> >>>> see if we can first have some discussion on this topic before >> >>>> moving on to see if we can get a consensus here on the mailing >> >>>> list. >> >>>> >> >>>> Please provide your views on this topic. >> >>>> >> >>>> Cheers >> >>>> >> >>>> Magnus Westerlund (As Chair and document editor) >> >>>> >> >>>> >> >>>> >> ---------------------------------------------------------------------- >> >>>> >> >>>> >> >> Multimedia Technologies, Ericsson Research EAB/TVM >> >>>> >> ---------------------------------------------------------------------- >> >>>> >> >>>> >> >> 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 >> >>> >> >>> >> >> >> >> >> >> -- >> >> >> >> Magnus Westerlund >> >> >> >> ---------------------------------------------------------------------= - >> >> Multimedia Technologies, Ericsson Research EAB/TVM >> >> ---------------------------------------------------------------------= - >> >> 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 >> >> --- >> * Olle E Johansson - oej@edvina.net >> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >> >> >> >> _______________________________________________ >> 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 > > --14dae934043552044b04c3e4a219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0
So far there are many supports and opposes for the implementation of r= etransmission in browser.
Since according to Justin, since browser and app developers are differ= ent, apps have no control over retransmissions.
IMO, can we think of to make this implemented in the browser and givin= g App to opt for this facility,if it requires, through peerConnection or so= me other API at the time of initiation. So that, facility will be prasent a= nd its=A0usage becomes application dependent.
=A0
Thanks,
Kiran.
---------- Forwarded message --------= --
From:=A0Justin Uberti <juber= ti@google.com>
To:=A0"Olle E. Johansson" <o= ej@edvina.net>
Cc:=A0"rtc= web@ietf.org" <rtcweb@ietf.o= rg>
Date:=A0Mon, 2 Jul 2012 13:18:13 -0700
Subject:=A0Re: [rtcweb] RTP Usage= : Is RTP Retransmission REQUIRED or RECOMMENDED
As has been pointed out = in this thread before, this discussion is not about mandating the USE of re= transmission in realtime scenarios. =A0It is simply trying to decide whethe= r retransmission should be required to be present in the 'toolbox' = of tools that WebRTC apps can expect to use, primarily where the app develo= per and runtime developer are separate (e.g. in a browser).=20

Several people have pointed out scenarios and applications where retra= nsmission (of video, not audio) works very well. Our experience matches thi= s too. Typically we can locate a media gateway very close to all participan= ts, meaning that a lost packet between GW and user can be detected and retr= ansmitted fast enough to not be noticeable by the user. These applications,= if they do not have access to retransmission, will be forced to use cruder= methods of error recovery that are more noticeable to users, among other u= npleasant effects.

Given that the implementation cost of retransmission is fairly negligi= ble (basically, a packet cache plus support for parsing NACK messages), and= that is really the only reason NOT to support this functionality in the to= olbox, I have a hard time understanding why we would not want to make this = a MUST implement for WebRTC.

Again, this is about making _support_ for retransmission a requirement= , not _use_.
--justin


On Mon, Jul 2, 2012 at 12:38 AM, Olle E. Johanss= on <oej@edvina.net> wrote:

29 jun 2012 kl. 17:11 skrev Culle= n Jennings:

>
> Right - so on the question of it retransmission is ma= ndatory to implement for audio codec, I am on a definitely "No". = The bulk of systems today do not do it and work fine. Vendors can easily ch= oose to do if they want in an interoperable way with out it being MTI. Why = we should add a bunch of stuff in to version 1 of this that we can live wit= hout is beyond me. This is how IPv6 got big and hard, by everyone taking th= eir favorite technology and attaching it to v6. I don't even want it as= RECOMMENDED for audio - I see it as OPTIONAL.
Agree. We need a base level of interoperability.
>
> I probably feel differently about video.
Maybe. = Current video have the frame update requests. ugly, but works in most cases= . I see reasons for retransmission of video, but not to make it recommended= or required.

/O
>
>
> On Jun 28, 2012, at 23:43 , Magnus Westerlund wro= te:
>
>> On 2012-06-28 16:36, Cullen Jennings wrote:
>= >>
>>> I think you need to separate this for audio and vi= deo and be far more
>>> specific about what type of retransmit ion you are talking abo= ut. In
>>> many cases the retransmit ion schemes for audio make= the end suer
>>> experience worse.
>>
>> I a= m not disagreeing unless the RTT is really low.
>>
>> What I am asking the WG is if RTP retransmission is a = RECOMMENDED or
>> REQUIRED feature in the toolbox that an WebRTC e= nd-point supports. This
>> says nothing on when you select to use = it and on which media. If we want
>> to include such recommendations we can do it. In fact the RTP usag= e
>> draft has a bit on text discussing the issue with RTT.
>= ;>
>> Cheers
>>
>> Magnus
>> (As WG = chair)
>>
>>>
>>> On Jun 27, 2012, at 24:36 , Magnus= Westerlund wrote:
>>>
>>>> WG,
>>>&= gt;
>>>> We had a discussion at the interim if RTP Retransmi= ssion is to be
>>>> considered REQUIRED or RECOMMENDED to implement. I would l= ike to
>>>> see if we can first have some discussion on this= topic before
>>>> moving on to see if we can get a consensu= s here on the mailing
>>>> list.
>>>>
>>>> Please provi= de your views on this topic.
>>>>
>>>> Cheers=
>>>>
>>>> Magnus Westerlund (As Chair and do= cument editor)
>>>>
>>>>
>>>> ------------------= ----------------------------------------------------
>>>>>>>>
>> Multimedia Technologies, Ericsson Research EA= B/TVM
>>>> ----------------------------------------------------------= ------------
>>>>
>>>>
>> Ericsson A= B =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= : magnu= s.westerlund@ericsson.com
>>>> ----------------------------------------------------------= ------------
>>>>
>>>>
>>>>>>>>
>> _____________________________________________= __
>>>> rtcweb mailing list rtcweb@ietf.org
>>>> https://www.ietf.org= /mailman/listinfo/rtcweb
>>>
>>>
>>
>>
>> --
>= >
>> Magnus Westerlund
>>
>> ----------------= ------------------------------------------------------
>> Multimed= ia Technologies, Ericsson Research EAB/TVM
>> ------------------------------------------------------------------= ----
>> 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@eri= csson.com
>> ------------------------------------------------------------------= ----
>>
>>
>>
>
> __________________= _____________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--= -
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20,= Sweden



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


--14dae934043552044b04c3e4a219-- From oej@edvina.net Tue Jul 3 00:30:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF0C21F8639 for ; Tue, 3 Jul 2012 00:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyGefzhAkEsK for ; Tue, 3 Jul 2012 00:30:39 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 554EF21F869F for ; Tue, 3 Jul 2012 00:30:38 -0700 (PDT) Received: from [192.168.40.27] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 434DE754A8AA; Tue, 3 Jul 2012 07:30:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Tue, 3 Jul 2012 09:30:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> To: Justin Uberti X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 07:30:41 -0000 2 jul 2012 kl. 22:18 skrev Justin Uberti: > As has been pointed out in this thread before, this discussion is not = about mandating the USE of retransmission in realtime scenarios. It is = simply trying to decide whether retransmission should be required to be = present in the 'toolbox' of tools that WebRTC apps can expect to use, = primarily where the app developer and runtime developer are separate = (e.g. in a browser). I fully understand this. What worries me is that my experience from = SIPits and working with SIP for many years is that there is a large gap = between IETF documents and what the implementations out there support. I = would like some base level of interoperability in the RTP layer between = webrtc and the SIP installed base. If the RTP toolset for Webrtc is far = away from any standard SIP phone, you will be forcing everyone to use = application layer gateways. I think that would be a bad scenario. I still think it has to be optional to implement. /O >=20 > Several people have pointed out scenarios and applications where = retransmission (of video, not audio) works very well. Our experience = matches this too. Typically we can locate a media gateway very close to = all participants, meaning that a lost packet between GW and user can be = detected and retransmitted fast enough to not be noticeable by the user. = These applications, if they do not have access to retransmission, will = be forced to use cruder methods of error recovery that are more = noticeable to users, among other unpleasant effects. >=20 > Given that the implementation cost of retransmission is fairly = negligible (basically, a packet cache plus support for parsing NACK = messages), and that is really the only reason NOT to support this = functionality in the toolbox, I have a hard time understanding why we = would not want to make this a MUST implement for WebRTC. >=20 > Again, this is about making _support_ for retransmission a = requirement, not _use_. > --justin >=20 >=20 > On Mon, Jul 2, 2012 at 12:38 AM, Olle E. Johansson = wrote: >=20 > 29 jun 2012 kl. 17:11 skrev Cullen Jennings: >=20 > > > > Right - so on the question of it retransmission is mandatory to = implement for audio codec, I am on a definitely "No". The bulk of = systems today do not do it and work fine. Vendors can easily choose to = do if they want in an interoperable way with out it being MTI. Why we = should add a bunch of stuff in to version 1 of this that we can live = without is beyond me. This is how IPv6 got big and hard, by everyone = taking their favorite technology and attaching it to v6. I don't even = want it as RECOMMENDED for audio - I see it as OPTIONAL. > Agree. We need a base level of interoperability. > > > > I probably feel differently about video. > Maybe. Current video have the frame update requests. ugly, but works = in most cases. I see reasons for retransmission of video, but not to = make it recommended or required. >=20 > /O > > > > > > On Jun 28, 2012, at 23:43 , Magnus Westerlund wrote: > > > >> On 2012-06-28 16:36, Cullen Jennings wrote: > >>> > >>> I think you need to separate this for audio and video and be far = more > >>> specific about what type of retransmit ion you are talking about. = In > >>> many cases the retransmit ion schemes for audio make the end suer > >>> experience worse. > >> > >> I am not disagreeing unless the RTT is really low. > >> > >> What I am asking the WG is if RTP retransmission is a RECOMMENDED = or > >> REQUIRED feature in the toolbox that an WebRTC end-point supports. = This > >> says nothing on when you select to use it and on which media. If we = want > >> to include such recommendations we can do it. In fact the RTP usage > >> draft has a bit on text discussing the issue with RTT. > >> > >> Cheers > >> > >> Magnus > >> (As WG chair) > >> > >>> > >>> On Jun 27, 2012, at 24:36 , Magnus Westerlund wrote: > >>> > >>>> WG, > >>>> > >>>> We had a discussion at the interim if RTP Retransmission is to be > >>>> considered REQUIRED or RECOMMENDED to implement. I would like to > >>>> see if we can first have some discussion on this topic before > >>>> moving on to see if we can get a consensus here on the mailing > >>>> list. > >>>> > >>>> Please provide your views on this topic. > >>>> > >>>> Cheers > >>>> > >>>> Magnus Westerlund (As Chair and document editor) > >>>> > >>>> > >>>> = ---------------------------------------------------------------------- > >>>> > >>>> > >> Multimedia Technologies, Ericsson Research EAB/TVM > >>>> = ---------------------------------------------------------------------- > >>>> > >>>> > >> 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 > >>> > >>> > >> > >> > >> -- > >> > >> Magnus Westerlund > >> > >> = ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> = ---------------------------------------------------------------------- > >> 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 >=20 > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From ibc@aliax.net Tue Jul 3 15:13:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F43111E808C for ; Tue, 3 Jul 2012 15:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAO9rYXH6b3o for ; Tue, 3 Jul 2012 15:13:37 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 958CF11E8093 for ; Tue, 3 Jul 2012 15:13:35 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so10491980lbb.31 for ; Tue, 03 Jul 2012 15:13:44 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=QVOA6MEQv7OPiZHd85AM7XRoD+9voLYmyCtVhGaf+LM=; b=SJUlmcsOGKWPgH5/xdd+3XSvFz/SgEansehA90o/zlC7aK4vBRMOfSAxRLyb43YAYj ZPipXNRYsXfpcXT/fBYB3LOABAvFSckS8zrMmWeo0tj9QBXf0AEITP6Ajr539iRbv+hj JZXMhGO/Oe8i/vUsRXTzrVeGWoMiiU6CMvSvxkO85MNNqjm4Nj536UGMS1mbl0XDFOGo xL0t3PgW4VGm0vigLKn2nJf6yLLHPvvgurNLz2JMN9pfH2rpiyilIQjU42m6IcJAj9ir M7NglCQxZ2f7U2oEBqAfIifIvYl1NGBnQPz41U3LMn0gtuI7D1lazcTf6YL1wCD3nOPo ZERg== Received: by 10.112.27.226 with SMTP id w2mr9032401lbg.57.1341353623988; Tue, 03 Jul 2012 15:13:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Tue, 3 Jul 2012 15:13:23 -0700 (PDT) In-Reply-To: <0434463FDA60A94FA978ACA44617682DFAA28B688B@EUSAACMS0702.eamcs.ericsson.se> References: <0434463FDA60A94FA978ACA44617682DFAA28B688B@EUSAACMS0702.eamcs.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 4 Jul 2012 00:13:23 +0200 Message-ID: To: Anne Raby Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkuhy00toMt6MjEmWMTiLKotHlEKvwwrgS9Q8Gl4YCQU4isbOePyAc+fLs5ulrdrasDMRml Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 22:13:37 -0000 2012/6/29 Anne Raby : > I am trying to reconcile this example with RFC3261, RFC3262 and RFC3264. = With the help of RFC 6337, I understand that if a UAC receives a SDP answer= in a reliable response, it should ignore any SDP ANSWER in a subsequent re= sponse in the same INVITE transaction. If the 2nd SDP is different then the= UAC should only consider the 1st SDP answer. Hi, that's not correct. Let me improve it: If a UAC receives a SDP answer in a reliable response (with To-tag =3D AAAA), then any subsequent provisional or final response (with SDP) within the same transaction and *same* To-tag MUST contain the same SDP. Otherwise it would be a violation of RFC 3261. But within the same INVITE transaction, the UAC could receive different provisional (and also final 2XX) responses with *different* To-tag and, therefore, with different SDP. And yes, the UAC could choose which media stream(s) to render (or render all of them in some exotic way). > If this is the case, then the SDP answer from the 200 OK should be the sa= me as in the 180. What is then the advantage of using the "pranswer" state?= I am trying to figure out in which case the "pranswer" could be used? Imagine you call a mobile number, the mobile rings for a while and you get a 183 with To-tag =3D AAAA and SDP 1. After 30 seconds the operator decides to route your call to a voicemail server which automatically answers your call and replies a 200 OK with a different To-tag =3D BBBB (since it's a different UAS) and SDP 2 (of course not the same as SDP 1). That's a simple example of SIP serial forking, but the same is tru for parallel forking (in which you could get different 18X responses at the same time, with different To-tag and SDP). Regards. --=20 I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Wed Jul 4 00:00:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816F011E812C for ; Wed, 4 Jul 2012 00:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BVrgqSRAkFH for ; Wed, 4 Jul 2012 00:00:52 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 67ABA11E8129 for ; Wed, 4 Jul 2012 00:00:51 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-0b-4ff3ea2c06c4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 95.AD.25842.C2AE3FF4; Wed, 4 Jul 2012 09:01:00 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Wed, 4 Jul 2012 09:00:59 +0200 Message-ID: <4FF3EA29.7090504@ericsson.com> Date: Wed, 4 Jul 2012 09:00:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvra7Oq8/+BpOeyVus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBW/fzEWdPFULNl/k7WB8SlnFyMnh4SAicTBp/PYIGwxiQv3 1gPZXBxCAqcYJVYe/cEI4SxjlLj56QY7SBWvgLbEgxczmEBsFgEViavProPZbAIWEjd/NIJN EhUIlpg2/R5UvaDEyZlPWEBsEQF1icsPL4DFhQVsJHqXHmeG2Cwpca99NVgvs4CexJSrLYwQ trxE89bZYDVCQHsbmjpYJzDyz0IydhaSlllIWhYwMq9iFM5NzMxJLzfXSy3KTC4uzs/TK07d xAgMtINbfhvsYNx0X+wQozQHi5I4r57qfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjEH1 vF6p5T77RZ2CrJhnnZoSrxO39NO5hjzTywbcB/kVVzRP1z6+/IC2bFJu7Q5WdsXgRXb+33Lk Ba5ceqz9LOHVehM9oVgRSfNr735dPzgn/37zC5vKqh/OulHO5S8XRlW/uCOyJmHhVOX/+js2 irVEZy3NDvgooJy+8YXMmvijpxYySZ++r8RSnJFoqMVcVJwIAPj7/8MCAgAA Subject: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 07:00:52 -0000 WG, We chairs have identified that we currently we are missing specification text for one of the key components of RTCWEB. This component is how WebRTC uses ICE and defines the datagram transport that both the DTLS/SCTP data channel uses and the RTP session. Such a specification would most likely contain the following: - How ICE is used in the WebRTC context - Inclusion of STUN, TURN, TURN-TCP - Inclusion of any defined "HTTP fallback" - Description of the data transport in general and specifically how one can separate the traffic from the data channel and RTP session. - Requirements on the signalling and API and what configuration data is needed. My personal view is that this is best served by having its own specification. Alternatives that exist is to include it either in the data channel or RTP usage specifications. Thus we chairs would appreciate feedback on at least two things: - Is specifying this in its own specification the most suitable approach - Do we have any volunteers for writing such a specification? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 oej@edvina.net Wed Jul 4 00:30:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CF821F8746 for ; Wed, 4 Jul 2012 00:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTzj722y2Y4T for ; Wed, 4 Jul 2012 00:30:31 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8921F872D for ; Wed, 4 Jul 2012 00:30:30 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1003] (unknown [IPv6:2001:16d8:cc57:1000::42:1003]) by smtp7.webway.se (Postfix) with ESMTPA id BB002754A8AC; Wed, 4 Jul 2012 07:30:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Wed, 4 Jul 2012 09:30:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0434463FDA60A94FA978ACA44617682DFAA28B688B@EUSAACMS0702.eamcs.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 07:30:32 -0000 4 jul 2012 kl. 00:13 skrev I=F1aki Baz Castillo: > 2012/6/29 Anne Raby : >> I am trying to reconcile this example with RFC3261, RFC3262 and = RFC3264. With the help of RFC 6337, I understand that if a UAC receives = a SDP answer in a reliable response, it should ignore any SDP ANSWER in = a subsequent response in the same INVITE transaction. If the 2nd SDP is = different then the UAC should only consider the 1st SDP answer. >=20 > Hi, that's not correct. Let me improve it: >=20 > If a UAC receives a SDP answer in a reliable response (with To-tag =3D > AAAA), then any subsequent provisional or final response (with SDP) > within the same transaction and *same* To-tag MUST contain the same > SDP. Otherwise it would be a violation of RFC 3261. >=20 > But within the same INVITE transaction, the UAC could receive > different provisional (and also final 2XX) responses with *different* > To-tag and, therefore, with different SDP. And yes, the UAC could > choose which media stream(s) to render (or render all of them in some > exotic way). The documentation for early media doesn't really cover this case. We = have set up tests for this during many SIPit Interoperability events and devices have done = different things with multiple early media streams and answer from a separate device. Some latched on = to early media and ignored the final answer (200 OK), some mixed (awful experience) and = some just ignored the whole issue by staying with the first answer.=20 >=20 >=20 >=20 >> If this is the case, then the SDP answer from the 200 OK should be = the same as in the 180. What is then the advantage of using the = "pranswer" state? I am trying to figure out in which case the "pranswer" = could be used? >=20 > Imagine you call a mobile number, the mobile rings for a while and you > get a 183 with To-tag =3D AAAA and SDP 1. After 30 seconds the = operator > decides to route your call to a voicemail server which automatically > answers your call and replies a 200 OK with a different To-tag =3D = BBBB > (since it's a different UAS) and SDP 2 (of course not the same as SDP > 1). That's a simple example of SIP serial forking, but the same is > tru for parallel forking (in which you could get different 18X > responses at the same time, with different To-tag and SDP). >=20 Do we really need to map the PSTN call states into webrtc? Media is = either active or onhold(inactive). Early media is just a billing issue = and a state that could be managed by the app that controls the webrtc = media. In the case of the SIP stack, the SIP stack could be aware that media is = early or complete from a SIP to PSTN call point of view - but what's the = point of this complexity in Webrtc? /O= From mperumal@cisco.com Wed Jul 4 00:36:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D1121F8799 for ; Wed, 4 Jul 2012 00:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu5zvX7IMcNx for ; Wed, 4 Jul 2012 00:36:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0512621F8795 for ; Wed, 4 Jul 2012 00:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2397; q=dns/txt; s=iport; t=1341387395; x=1342596995; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/MzGym75XYhaTPrF5V1ZaeRnJz8Vnq2BbCKKlc8LmS8=; b=XmqAJSfB7omkJCKHk+gSiisMHkSYO74XehYnL2+97c6+nburhb40ZKlg SxUp9FpS19U046+mUz6LOpUS0mu0dJ0WL0W7xMbqeATtybW3l3/bbT1sM F/o8MjSz2Se2thVjT4u3D1gdJ8op8c5O/uZq7CVc7128NMenDepSpxTOc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADHx80+tJV2c/2dsb2JhbABEtyCBB4IYAQEBBAEBAQkGAVsXAgICAQgRBAEBCx0HGwwLFAkIAgQBEggah2kLmhSgRgQEizWFV2ADiBebPYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,520,1336348800"; d="scan'208";a="98669340" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 04 Jul 2012 07:36:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q647aYJi022243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jul 2012 07:36:34 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Wed, 4 Jul 2012 02:36:34 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Where to specify ICE usage and the common transport Thread-Index: AQHNWbLSqHcZgCkhb0KVzPBA2p9XJ5cYuDMA Date: Wed, 4 Jul 2012 07:36:33 +0000 Message-ID: References: <4FF3EA29.7090504@ericsson.com> In-Reply-To: <4FF3EA29.7090504@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.69.122] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19016.003 x-tm-as-result: No--39.263100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 07:36:26 -0000 |- Is specifying this in its own specification the most suitable=20 |approach Yes, IMO. I think it would ensue we get enough focus on this key component. |- Do we have any volunteers for writing such a specification? Please count me in. I think it makes sense to merge the consent freshness s= pecification (draft-muthu-behave-consent-freshness) with the ICE usage for = WebRTC. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f Magnus Westerlund |Sent: Wednesday, July 04, 2012 12:31 PM |To: rtcweb@ietf.org |Subject: [rtcweb] Where to specify ICE usage and the common transport | |WG, | |We chairs have identified that we currently we are missing specification |text for one of the key components of RTCWEB. This component is how |WebRTC uses ICE and defines the datagram transport that both the |DTLS/SCTP data channel uses and the RTP session. | |Such a specification would most likely contain the following: | |- How ICE is used in the WebRTC context |- Inclusion of STUN, TURN, TURN-TCP |- Inclusion of any defined "HTTP fallback" |- Description of the data transport in general and specifically how one | can separate the traffic from the data channel and RTP session. |- Requirements on the signalling and API and what configuration data is | needed. | |My personal view is that this is best served by having its own |specification. Alternatives that exist is to include it either in the |data channel or RTP usage specifications. | |Thus we chairs would appreciate feedback on at least two things: | |- Is specifying this in its own specification the most suitable approach | |- Do we have any volunteers for writing such a specification? | |Cheers | |Magnus Westerlund | |---------------------------------------------------------------------- |Multimedia Technologies, Ericsson Research EAB/TVM |---------------------------------------------------------------------- |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 zhou.sujing@zte.com.cn Wed Jul 4 02:23:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F56721F87E8 for ; Wed, 4 Jul 2012 02:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.13 X-Spam-Level: X-Spam-Status: No, score=-95.13 tagged_above=-999 required=5 tests=[AWL=2.540, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn+E2WWX78y8 for ; Wed, 4 Jul 2012 02:23:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8C12021F87E2 for ; Wed, 4 Jul 2012 02:23:20 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620977368623; Wed, 4 Jul 2012 17:16:10 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 66870.977368623; Wed, 4 Jul 2012 17:23:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q649NE9u090085 for ; Wed, 4 Jul 2012 17:23:14 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: rtcweb@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 4 Jul 2012 17:23:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-04 17:23:17, Serialize complete at 2012-07-04 17:23:17 Content-Type: multipart/alternative; boundary="=_alternative 00339A0F48257A31_=" X-MAIL: mse02.zte.com.cn q649NE9u090085 Subject: [rtcweb] what kind of additional key management for SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 09:23:22 -0000 This is a multipart message in MIME format. --=_alternative 00339A0F48257A31_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIA0KIEkgd29uZGVyIHdoYXQgaXMgdGhlIG1vdGl2YXRpb24gZm9yIHRoZSB0b3BpYyANCiAi QWRkaXRpb25hbCBLZXktbWFuYWdlbWVudCBmb3IgU1JUUCIgaW4gVmFuY291dmVyPw0KIEFueSBv bmUgaXMga2luZCB0byB0ZWxsIG1lo78NClJlZ2FyZHN+fn4NCg0KLVN1amluZyBaaG91DQo= --=_alternative 00339A0F48257A31_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mz5IaSwgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mz4mbmJzcDtJIHdvbmRlciB3aGF0IGlzIHRoZSBtb3RpdmF0aW9uIGZvciB0aGUgdG9waWMN Cjxicj4NCiAmcXVvdDtBZGRpdGlvbmFsIEtleS1tYW5hZ2VtZW50IGZvciBTUlRQJnF1b3Q7IGlu IFZhbmNvdXZlcj88YnI+DQogQW55IG9uZSBpcyBraW5kIHRvIHRlbGwgbWWjvzxicj4NCjwvZm9u dD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzfn5+PGJyPg0KPGJy Pg0KLVN1amluZyBaaG91PC9mb250Pg0K --=_alternative 00339A0F48257A31_=-- From magnus.westerlund@ericsson.com Wed Jul 4 02:35:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C344421F8813 for ; Wed, 4 Jul 2012 02:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.225 X-Spam-Level: X-Spam-Status: No, score=-106.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyAPfGZaMp-t for ; Wed, 4 Jul 2012 02:35:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6997321F8783 for ; Wed, 4 Jul 2012 02:35:42 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-f1-4ff40e776f91 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 43.18.23986.77E04FF4; Wed, 4 Jul 2012 11:35:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Wed, 4 Jul 2012 11:35:50 +0200 Message-ID: <4FF40E74.8010204@ericsson.com> Date: Wed, 4 Jul 2012 11:35:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "zhou.sujing@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW453xd/g9cTdCzW/mtntzi8pp/d gcljyZKfTB5r9v1gCWCK4rJJSc3JLEst0rdL4Mo41/2fuWAWZ0XfsVmMDYyn2bsYOTkkBEwk Nk7sYYWwxSQu3FvP1sXIxSEkcIpRYt6uz6wQzjJGianrvoB18ApoS6yZtYexi5GDg0VARaLt aiVImE3AQuLmj0Y2EFtUIFhi2vR7UOWCEidnPmEBsUUETCXO7l/ICGIzC6hL3Fl8DqxGWMBN Yn7TfbBeIYEgia2bP7GCjOcEmtOwtxziNkmJe+2r2SBaNSVat/9mh7DlJZq3zmaGaNWWaGjq YJ3AKDQLyeZZSFpmIWlZwMi8ilE4NzEzJ73cSC+1KDO5uDg/T684dRMjMIAPbvmtuoPxzjmR Q4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCs3ZvYzfRZtVFdeXVJgsoJ lnDP1oLNm0VPOM2aNmMr3yvOzRMuvlomkKbdF9I/47TCyoXvPiSU6zl9PqO8++TlP1+3HPJs WCQ22aR0S8udd5eWfC1e1Gz/Plj6qlqGiv/dAJlPL6+41JR79e259fHJjxlKi/9O/303Ok7f LIarPMjSZ9sWkV8+SizFGYmGWsxFxYkAnr3IhC4CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] what kind of additional key management for SRTP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 09:35:43 -0000 On 2012-07-04 11:23, zhou.sujing@zte.com.cn wrote: > > Hi, > I wonder what is the motivation for the topic > "Additional Key-management for SRTP" in Vancouver? > Any one is kind to tell me？ The WG has agreed to require support of DTLS-SRTP. However in the discussion in Paris regarding the key-managment for RTP did not conclude regarding if additional mechanisms should also be supported in WebRTC. The two proposals on the table are regarding: - Support of security descriptions, i.e. plain text keys in the signalling messages - Support for Encrypted Key Transport (draft-ietf-avt-srtp-ekt-03) (expected update by Monday as the filename draft-ietf-avtcore-srtp-ekt-00) Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 ibc@aliax.net Wed Jul 4 04:22:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F91D21F87EE for ; Wed, 4 Jul 2012 04:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idWAhGNit-Vs for ; Wed, 4 Jul 2012 04:22:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 607BC21F87C7 for ; Wed, 4 Jul 2012 04:22:36 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so11282679lbb.31 for ; Wed, 04 Jul 2012 04:22:46 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=ZTXJYHSCh/TX9T4SXShVGWjK42scjkTcLq9KTATReyY=; b=o9pnynbkZVcGCBWcJfGWN9jlaNmPAAXDhY7zVXQe+oxclLH86MlYmL5rO25YByUX9j JtPUEDSJr4W8C5/LvdyvVG1MZbf86dbKx4lljQd1aIN0dZUVtELU08bv5lJBspv/KesW MnjeCHF45zOI0Oi5F6TfjCwBCovsHiSdurQd7C9ukapCIXcKS2cYFSKmoqdL7FgeoYdT t5leGeLubcEOoQpZ05jeDu1dJs/0+5YZLZ69el71jQoQnJB9BwPNeAZqU6S+03sIZmQ6 EGZ+IMncvvOvmjd/OI03jjGs+8nRGuqnkdg8OOeTGHGA1VwAlB7sWystrrfk+z88Ib4E q3Cw== Received: by 10.152.122.12 with SMTP id lo12mr21447425lab.3.1341400966080; Wed, 04 Jul 2012 04:22:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Wed, 4 Jul 2012 04:22:25 -0700 (PDT) In-Reply-To: References: <0434463FDA60A94FA978ACA44617682DFAA28B688B@EUSAACMS0702.eamcs.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 4 Jul 2012 13:22:25 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl77OHocwSnzBFoinSlGIvXl6+qLr19U/huCHLh9QWTpBp7RYDZ4UGgvLoa44jS1/0zdAaj Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 11:22:37 -0000 2012/7/4 Olle E. Johansson : > Do we really need to map the PSTN call states into webrtc? I don't suggest that. I was just explaining the SIP case in which different SDP are received by the UAC within the same INVITE transaction :) --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Wed Jul 4 05:27:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0421F8804 for ; Wed, 4 Jul 2012 05:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjcgnvjsWFaY for ; Wed, 4 Jul 2012 05:27:33 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 10D0A21F87FE for ; Wed, 4 Jul 2012 05:27:32 -0700 (PDT) Received: from [192.168.40.27] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 875E4754A8AA; Wed, 4 Jul 2012 12:27:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Wed, 4 Jul 2012 14:27:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0434463FDA60A94FA978ACA44617682DFAA28B688B@EUSAACMS0702.eamcs.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 12:27:33 -0000 4 jul 2012 kl. 13:22 skrev I=F1aki Baz Castillo: > 2012/7/4 Olle E. Johansson : >> Do we really need to map the PSTN call states into webrtc? >=20 > I don't suggest that. I was just explaining the SIP case in which > different SDP are received by the UAC within the same INVITE > transaction :) And you where perfectly right. An OFFER can only have one ANSWER - but = per early dialog in SIP. And one INVITE with an SDP offer can generate = multiple early dialogs with multiple SDP answers, in PRACK or in 200 OK = or somewhere else. The OFFER/ANSWER process is decoupled from the INVITE = transaction, really. /O ;-)= From anne.raby@ericsson.com Wed Jul 4 07:13:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A0C21F87FD for ; Wed, 4 Jul 2012 07:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqJmlhecMv1Y for ; Wed, 4 Jul 2012 07:13:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB87C21F85C3 for ; Wed, 4 Jul 2012 07:13:42 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q64EDkQQ030580; Wed, 4 Jul 2012 09:13:47 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 4 Jul 2012 10:13:44 -0400 From: Anne Raby To: "Olle E. Johansson" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 4 Jul 2012 10:13:43 -0400 Thread-Topic: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications Thread-Index: Ac1Z4HwgWQfOJ5sVSimomndCX+7dEQABPxxw Message-ID: <0434463FDA60A94FA978ACA44617682DFAA298D498@EUSAACMS0702.eamcs.ericsson.se> References: <0434463FDA60A94FA978ACA44617682DFAA28B688B@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:13:43 -0000 Thank you both for the clarifications. /Anne -----Original Message----- From: Olle E. Johansson [mailto:oej@edvina.net]=20 Sent: July-04-12 8:28 AM To: I=F1aki Baz Castillo Cc: Anne Raby; rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarificatio= ns 4 jul 2012 kl. 13:22 skrev I=F1aki Baz Castillo: > 2012/7/4 Olle E. Johansson : >> Do we really need to map the PSTN call states into webrtc? >=20 > I don't suggest that. I was just explaining the SIP case in which > different SDP are received by the UAC within the same INVITE > transaction :) And you where perfectly right. An OFFER can only have one ANSWER - but per = early dialog in SIP. And one INVITE with an SDP offer can generate multiple= early dialogs with multiple SDP answers, in PRACK or in 200 OK or somewher= e else. The OFFER/ANSWER process is decoupled from the INVITE transaction, = really. /O ;-) From stefan.lk.hakansson@ericsson.com Wed Jul 4 07:22:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73D621F85D2 for ; Wed, 4 Jul 2012 07:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTQK8aXxOqPz for ; Wed, 4 Jul 2012 07:22:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1416621F8585 for ; Wed, 4 Jul 2012 07:22:54 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-09-4ff451c8c4da Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9D.E4.25842.8C154FF4; Wed, 4 Jul 2012 16:23:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Wed, 4 Jul 2012 16:23:04 +0200 Message-ID: <4FF451C7.5080804@ericsson.com> Date: Wed, 4 Jul 2012 16:23:03 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <4FF217DD.1060607@jesup.org> In-Reply-To: <4FF217DD.1060607@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvre6JwC/+Bh/+m1us/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI77n9gLrqpVTNg+jaWBsVm+i5GTQ0LARGLV9DssELaYxIV7 69m6GLk4hAROMUo8/DyHESQhJLCMUWLWk6AuRg4OXgFtidbFPCBhFgEViRNHt4L1sgnYSKzt nsIEUiIqECYxfSc7SJhXQFDi5MwnYCUiAuoSlx9eYAcpERbwk5jfEAYxfDeTxIsZsiA2p4Cm xOI3N1hBbGYBW4kLc66zQNjyEtvfzmGGqNeVePf6HusERoFZSDbMQtIyC0nLAkbmVYzCuYmZ Oenl5nqpRZnJxcX5eXrFqZsYgYF3cMtvgx2Mm+6LHWKU5mBREufVU93vLySQnliSmp2aWpBa FF9UmpNafIiRiYNTqoHRyiHy+DOuUgM70b+3Hb7ZfrhSt/bm1tMVS5YuFPu/aqeR0Tr3/SUL lG79vLxeu9hOPntP1ILzdxvtkk9+YZS9H2O0zfRrUvLlvQKbFxzvzLq1QsbzBr/LuiYPZd87 v4TsKu1P3TJjPFC+6Tb38eUBO7X+tf34uvK6Rc4kQwNLxrI26yNVyQkuSizFGYmGWsxFxYkA XTz1qAoCAAA= Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:22:56 -0000 On 07/02/2012 11:51 PM, Randell Jesup wrote: > On 7/2/2012 4:18 PM, Justin Uberti wrote: >> As has been pointed out in this thread before, this discussion is not >> about mandating the USE of retransmission in realtime scenarios. It is >> simply trying to decide whether retransmission should be required to be >> present in the 'toolbox' of tools that WebRTC apps can expect to use, >> primarily where the app developer and runtime developer are separate >> (e.g. in a browser). > > Do you expect to expose this choice to the application? (and all the > data needed to make the choice...) Or have it be automatic? > >> Several people have pointed out scenarios and applications where >> retransmission (of video, not audio) works very well. Our experience >> matches this too. Typically we can locate a media gateway very close to >> all participants, meaning that a lost packet between GW and user can be >> detected and retransmitted fast enough to not be noticeable by the user. >> These applications, if they do not have access to retransmission, will >> be forced to use cruder methods of error recovery that are more >> noticeable to users, among other unpleasant effects. > > Ok. This says that it's preferable to implement it, and if you have one > of the situations that works well, use it. This sounds like a SHOULD to > me, since other implementations (say an audio-only WebRTC<->PSTN > gateway) may have little or no use for retransmission, or might reject > it always. > >> Given that the implementation cost of retransmission is fairly >> negligible (basically, a packet cache plus support for parsing NACK >> messages), and that is really the only reason NOT to support this >> functionality in the toolbox, I have a hard time understanding why we >> would not want to make this a MUST implement for WebRTC. >> >> Again, this is about making _support_ for retransmission a requirement, >> not _use_. > > If you don't mandate use, what does mandating "support" buy you? An > implementation (see above about PSTN gateways) might always decline to > use retransmission, so what does MUST (REQUIRE) buy you? I say SHOULD > (RECOMMEND), with a statement that it's strongly recommended it be > supported if video is supported, especially for non-single-purpose > devices (i.e. browsers). > > In either case, you need to think about who decides to use re-xmit or > not, what influences that, and if the app has visibility into this. > Someone could as an rtx-time=0 to the SDP. Or not include one, but > never actually retransmit a packet regardless of NACKs - it could just > repair via IDR (or other means). > > So here's a real problem related to retransmission: since the request is > not specific and negotiated (it's normally a generic NACK), the receiver > who sent the NACK has no idea if it will get a retransmission, an IDR > (or IDR slice), another form of repair (pframe/slice against > known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, it > doesn't know if it should freeze the video or play with errors. It has > to decide if it *thinks* the sender will use retransmission, or if it > doesn't, does the receiver want to freeze video until an IDR or other > repair is done, which might be a while. Isn't retransmission negotiated using "rtx", "atp" and so on? One way of removing the uncertainty would be to require that all browsers support RTP retransmission: This way, any RTP endpoint sending a NACK to a browser would know that that packet would be retransmitted (given that congestion does not prohibit, or NACK packet is lost etc.). If we have this in place, I'm confident that implementors will quickly develop strategies on how and when to _use_ retransmission in the best way. There has already been input made on its usefulness. Maybe the problem with legacy not always supporting retransmission is not that big. First of all, legacy is to a large extent audio only (e.g. PSTN), and no one is arguing for retransmission there. Secondly, I fail to see that this situation would be improved in any way if browsers are only recommended (and not required) to support RTP retransmission. So I think we should require rtcweb capable browsers to support RTP retransmission. > > We also need to think about when a receiver should use SLI or RPSI. PLI > can also be used and should be if the other options don't negotiate (so > it's important to offer it). Certainly it's more work to keep track of > the contents of each packet (slices, etc), especially in things like > H.264 NALU aggregation packets, than it is to just respond to an SLI. > > That said, my previous systems just used NACK and let the sender decide > the correct repair, but I wasn't leveraging slices and wasn't using > retransmission, so there was only minor complexity (looking at possible > reference frames). > From roman@telurix.com Wed Jul 4 08:11:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB3221F8833 for ; Wed, 4 Jul 2012 08:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIbZ8AROEa+M for ; Wed, 4 Jul 2012 08:11:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A88CF21F8768 for ; Wed, 4 Jul 2012 08:11:22 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11478401pbc.31 for ; Wed, 04 Jul 2012 08:11:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pGN+7uj72wdI2Wvnd06CDOFclEh0SZR7KaOg3xuKY7o=; b=bgcg8jFNPZse/Pq1bKNj8eiFEmvNzaKO5OEB3XNRG07V7bkU2W5L+a77cE2+65AEWX H8trLuJ/OoC+piB6HwJJd8B3Q9gt+TkUvhVyYVN2yPOoYjmNyjPooOqqo8A+DNgkbaa/ jnwPAomyoAFV5RqTmkMJOrTAaSzflLd4yEoEADNhClcs9hNcYdZTzy0LiHYXkZHL1yi8 +ilFtbRTWbFDdfwbI+1P4jg0DrGF34mTmGulR0Ki5/O2q0kxWUh8XJYMWPq/i99PM6Te CIsTxv5tfd/l1hVeYM6/kcB6bg2XOZNAE1nTtYckD0Z2cQtwWkdOSKuOE3GJzBtWY9Ug 3UJg== Received: by 10.68.190.97 with SMTP id gp1mr19859823pbc.76.1341414693341; Wed, 04 Jul 2012 08:11:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id pq5sm17873060pbb.30.2012.07.04.08.11.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 08:11:32 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11478321pbc.31 for ; Wed, 04 Jul 2012 08:11:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.233.225 with SMTP id tz1mr19977721pbc.4.1341414690001; Wed, 04 Jul 2012 08:11:30 -0700 (PDT) Received: by 10.68.194.202 with HTTP; Wed, 4 Jul 2012 08:11:29 -0700 (PDT) In-Reply-To: <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> Date: Wed, 4 Jul 2012 11:11:29 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=047d7b33cacc18141704c402728d X-Gm-Message-State: ALoCoQmrgl5FtN1bKWCXaDJAVJ12SSWhUA+p4CZYKX1AuyYhlr91kCXzKUgKcIyTK7cjWgA5wDVB Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 15:11:23 -0000 --047d7b33cacc18141704c402728d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 3:30 AM, Olle E. Johansson wrote: > > 2 jul 2012 kl. 22:18 skrev Justin Uberti: > > > As has been pointed out in this thread before, this discussion is not > about mandating the USE of retransmission in realtime scenarios. It is > simply trying to decide whether retransmission should be required to be > present in the 'toolbox' of tools that WebRTC apps can expect to use, > primarily where the app developer and runtime developer are separate (e.g. > in a browser). > > I fully understand this. What worries me is that my experience from SIPits > and working with SIP for many years is that there is a large gap between > IETF documents and what the implementations out there support. I would like > some base level of interoperability in the RTP layer between webrtc and the > SIP installed base. If the RTP toolset for Webrtc is far away from any > standard SIP phone, you will be forcing everyone to use application layer > gateways. I think that would be a bad scenario. > > I still think it has to be optional to implement. > > I think this train left the station long time ago. WebRTC is not going to interoperate with anything of significance currently deployed in SIP world. Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will need an application layer gateway. I guess the overall hope is that SIP implementations will catch up implementing features required to work with WebRTC in the future and gateways would be acceptable for current implementations. _____________ Roman Shpount --047d7b33cacc18141704c402728d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2012 at 3:30 AM= , Olle E. Johansson <oej@edvina.net> wrote:

2 jul 2012 kl. 22:18 skrev Justin Uberti:

> As has been pointed out in this thread before, this discussion is not = about mandating the USE of retransmission in realtime scenarios. =A0It is s= imply trying to decide whether retransmission should be required to be pres= ent in the 'toolbox' of tools that WebRTC apps can expect to use, p= rimarily where the app developer and runtime developer are separate (e.g. i= n a browser).

I fully understand this. What worries me is that my experience from S= IPits and working with SIP for many years is that there is a large gap betw= een IETF documents and what the implementations out there support. I would = like some base level of interoperability in the RTP layer between webrtc an= d the SIP installed base. If the RTP toolset for Webrtc is far away from an= y standard SIP phone, you will be forcing everyone to use application layer= gateways. I think that would be a bad scenario.

I still think it has to be optional to implement.


I think this train left the station long time ago= . WebRTC is not going to interoperate with anything of significance current= ly deployed in SIP world. Between DTLS-SRTP, ICE, AVPF and now RTP retransm= issions you will need an application layer gateway. I guess the overall hop= e is that SIP implementations will catch up implementing features required = to work with WebRTC in the future and gateways would be acceptable for curr= ent implementations.
_____________
Roman Shpount
--047d7b33cacc18141704c402728d-- From oej@edvina.net Wed Jul 4 08:52:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452B721F876D for ; Wed, 4 Jul 2012 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTtURi6Sjkge for ; Wed, 4 Jul 2012 08:52:01 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCC421F8757 for ; Wed, 4 Jul 2012 08:51:59 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id BC68F754A8AA; Wed, 4 Jul 2012 15:52:09 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Wed, 4 Jul 2012 17:52:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <190327B0-72B8-4F9C-8A37-D932A2871879@edvina.net> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> To: Roman Shpount X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 15:52:02 -0000 4 jul 2012 kl. 17:11 skrev Roman Shpount: >=20 > On Tue, Jul 3, 2012 at 3:30 AM, Olle E. Johansson = wrote: >=20 > 2 jul 2012 kl. 22:18 skrev Justin Uberti: >=20 > > As has been pointed out in this thread before, this discussion is = not about mandating the USE of retransmission in realtime scenarios. It = is simply trying to decide whether retransmission should be required to = be present in the 'toolbox' of tools that WebRTC apps can expect to use, = primarily where the app developer and runtime developer are separate = (e.g. in a browser). >=20 > I fully understand this. What worries me is that my experience from = SIPits and working with SIP for many years is that there is a large gap = between IETF documents and what the implementations out there support. I = would like some base level of interoperability in the RTP layer between = webrtc and the SIP installed base. If the RTP toolset for Webrtc is far = away from any standard SIP phone, you will be forcing everyone to use = application layer gateways. I think that would be a bad scenario. >=20 > I still think it has to be optional to implement. >=20 >=20 > I think this train left the station long time ago. WebRTC is not going = to interoperate with anything of significance currently deployed in SIP = world. Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will = need an application layer gateway. I guess the overall hope is that SIP = implementations will catch up implementing features required to work = with WebRTC in the future and gateways would be acceptable for current = implementations. Doesn't that mean that the IETF work on SIP over websockets will not = lead anywhere? /O From ibc@aliax.net Wed Jul 4 09:26:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F5921F876A for ; Wed, 4 Jul 2012 09:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwfYxlGzMxmD for ; Wed, 4 Jul 2012 09:26:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFA421F86B2 for ; Wed, 4 Jul 2012 09:26:01 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so11673461lbb.31 for ; Wed, 04 Jul 2012 09:26:11 -0700 (PDT) X-Google-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 :content-transfer-encoding:x-gm-message-state; bh=A5soDVmysmeokpZ1Yby0T+see/91eYWjXQS/Y33MBB0=; b=Wglwyqk8Wh6TzTx+s5xA8mSkjLU9eYLCHVjFjkakzZ1sql6D6giUaBqLuatmNZ4/7S Fvp2TrTqUnTTp3Au+DaInsR8TfilzqQkNCaWnpndEmhWGurnKYo2Lq32R2wvAjyEmS+U fxgEALC2sUfXJ/vjy69lU6jJA0v+ZbNvICn2l++BJdGtV51XQNOhkrC66N/klWUB6Agq 6fPT33g7Dyr9xv75rDUPj2F7fVUKK4tznFfyg1egKeZWyoFnHGfJQ8EFTl/4pAhTaMZP KBZVHeyVqbrkCdYe7tgrpdMSWslR8pmAMP3KxXFY5bg1e5PXieZvIybOH6FjAEWY9+vW scYA== Received: by 10.152.112.233 with SMTP id it9mr22235343lab.40.1341419171610; Wed, 04 Jul 2012 09:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Wed, 4 Jul 2012 09:25:51 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 4 Jul 2012 18:25:51 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmYjP+8CjoS2aWJQ1FszkeKn4ziBWIB6PxczG8yGj3JGFrxyWDzzkGEbJQ5oS6OIVu+LtkP Subject: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 16:26:02 -0000 Hi, let's assume I have an established audio session. Later the remote sends me a new SDP offer (let's say a SIP re-INVITE) and I want to analyze what is new in the new SDP (in order to ask the user for consent). So for example when the new SDP arrives I need to know whether it contains audio and video or whatever. With the current JSEP API I see no way. The only I can do with the new received SDP is: pc.setRemoteDescription(SDP_OFFER, REMOTE_SDP_TEXT) but this would alter my multimedia session before I can ask my user for consent. Do I miss something? And I would also like to know whether the received SDP contains dissabled streams (i.e. a video stream with port 0) before accepting it. Basically I want a mechanism for getting a diff between the existing remote SDP and the new received one. --=20 I=C3=B1aki Baz Castillo From bernard_aboba@hotmail.com Wed Jul 4 09:44:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0A521F875A for ; Wed, 4 Jul 2012 09:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1gkkaGCaMEe for ; Wed, 4 Jul 2012 09:44:09 -0700 (PDT) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by ietfa.amsl.com (Postfix) with ESMTP id A388721F8735 for ; Wed, 4 Jul 2012 09:44:09 -0700 (PDT) Received: from BLU169-W72 ([65.55.116.72]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jul 2012 09:44:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_da99b543-a791-4de7-a372-420732455c8f_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Magnus Westerlund , Date: Wed, 4 Jul 2012 09:44:19 -0700 Importance: Normal In-Reply-To: References: <4FF3EA29.7090504@ericsson.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jul 2012 16:44:19.0991 (UTC) FILETIME=[42282A70:01CD5A04] Subject: Re: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 16:44:10 -0000 --_da99b543-a791-4de7-a372-420732455c8f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reading the message below=2C it is not clear to me whether the items descri= bed fit into a single document.=20 I could see a document relating to ICE in the WebRTC context. This would i= nclude material on liveness=2C consent=2C STUN/TURN/TURN-TCP=2C and HTTP fa= llback. I would also like to see it cover a bit about flag usage=2C and pe= rhaps an analysis of some of the ICE security issues that Eric brought up a= t the Interim. =20 Overall=2C the document should retain compatibility with RFC 5245 as much a= s possible=2C not defining new (and non-backward compatible) functionality.= =20 If the material about data transport is unrelated to ICE=2C then it might b= etter belong in the data channel document.=20 Similarly with respect to API=2C signaling or configuration material. =20 > |-----Original Message----- > |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of Magnus Westerlund > |Sent: Wednesday=2C July 04=2C 2012 12:31 PM > |To: rtcweb@ietf.org > |Subject: [rtcweb] Where to specify ICE usage and the common transport > | > |WG=2C > | > |We chairs have identified that we currently we are missing specification > |text for one of the key components of RTCWEB. This component is how > |WebRTC uses ICE and defines the datagram transport that both the > |DTLS/SCTP data channel uses and the RTP session. > | > |Such a specification would most likely contain the following: > | > |- How ICE is used in the WebRTC context > |- Inclusion of STUN=2C TURN=2C TURN-TCP > |- Inclusion of any defined "HTTP fallback" > |- Description of the data transport in general and specifically how one > | can separate the traffic from the data channel and RTP session. > |- Requirements on the signalling and API and what configuration data is > | needed. > | > |My personal view is that this is best served by having its own > |specification. Alternatives that exist is to include it either in the > |data channel or RTP usage specifications. > | > |Thus we chairs would appreciate feedback on at least two things: > | > |- Is specifying this in its own specification the most suitable approach > | > |- Do we have any volunteers for writing such a specification? > | > |Cheers > | > |Magnus Westerlund > | > |---------------------------------------------------------------------- > |Multimedia Technologies=2C Ericsson Research EAB/TVM > |---------------------------------------------------------------------- > |Ericsson AB | Phone +46 10 7148287 > |F=E4r=F6gatan 6 | Mobile +46 73 0949079 > |SE-164 80 Stockholm=2C 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 = --_da99b543-a791-4de7-a372-420732455c8f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Reading the message below=2C it is not clear to me whether the items descri= bed fit into a single document.

I could see a document relating to = ICE in the WebRTC context. =3B This would include material on liveness= =2C consent=2C STUN/TURN/TURN-TCP=2C and HTTP fallback. =3B I would als= o like to see it cover a bit about flag usage=2C and perhaps an analysis of= some of the ICE security issues that Eric brought up at the Interim. = =3B

Overall=2C the document should retain compatibility with RFC 52= 45 as much as possible=2C not defining new (and non-backward compatible) fu= nctionality.

If the material about data transport is unrelated to I= CE=2C then it might better belong in the data channel document.

Sim= ilarly with respect to API=2C signaling or configuration material. =3B =


>=3B |-----Original Message-----
>=3B |From: rtcweb= -bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus West= erlund
>=3B |Sent: Wednesday=2C July 04=2C 2012 12:31 PM
>=3B |To= : rtcweb@ietf.org
>=3B |Subject: [rtcweb] Where to specify ICE usage a= nd the common transport
>=3B |
>=3B |WG=2C
>=3B |
>=3B = |We chairs have identified that we currently we are missing specification>=3B |text for one of the key components of RTCWEB. This component is h= ow
>=3B |WebRTC uses ICE and defines the datagram transport that both = the
>=3B |DTLS/SCTP data channel uses and the RTP session.
>=3B |=
>=3B |Such a specification would most likely contain the following:>=3B |
>=3B |- How ICE is used in the WebRTC context
>=3B |- = Inclusion of STUN=2C TURN=2C TURN-TCP
>=3B |- Inclusion of any defined= "HTTP fallback"
>=3B |- Description of the data transport in general = and specifically how one
>=3B | can separate the traffic from the dat= a channel and RTP session.
>=3B |- Requirements on the signalling and = API and what configuration data is
>=3B | needed.
>=3B |
>= =3B |My personal view is that this is best served by having its own
>= =3B |specification. Alternatives that exist is to include it either in the<= br>>=3B |data channel or RTP usage specifications.
>=3B |
>=3B = |Thus we chairs would appreciate feedback on at least two things:
>=3B= |
>=3B |- Is specifying this in its own specification the most suitab= le approach
>=3B |
>=3B |- Do we have any volunteers for writing = such a specification?
>=3B |
>=3B |Cheers
>=3B |
>=3B |= Magnus Westerlund
>=3B |
>=3B |----------------------------------= ------------------------------------
>=3B |Multimedia Technologies=2C = Ericsson Research EAB/TVM
>=3B |--------------------------------------= --------------------------------
>=3B |Ericsson AB | Ph= one +46 10 7148287
>=3B |F=E4r=F6gatan 6 | Mobile +46 = 73 0949079
>=3B |SE-164 80 Stockholm=2C Sweden| mailto: magnus.westerl= und@ericsson.com
>=3B |-----------------------------------------------= -----------------------
>=3B |
>=3B |
>=3B |________________= _______________________________
>=3B |rtcweb mailing list
>=3B |r= tcweb@ietf.org
>=3B |https://www.ietf.org/mailman/listinfo/rtcweb
&= gt=3B _______________________________________________
>=3B rtcweb mail= ing list
>=3B rtcweb@ietf.org
>=3B https://www.ietf.org/mailman/l= istinfo/rtcweb
= --_da99b543-a791-4de7-a372-420732455c8f_-- From andrew.hutton@siemens-enterprise.com Wed Jul 4 10:06:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39F521F86B2 for ; Wed, 4 Jul 2012 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGq-UafISXvG for ; Wed, 4 Jul 2012 10:06:40 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA2B21F870E for ; Wed, 4 Jul 2012 10:06:40 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 612441EB85FD; Wed, 4 Jul 2012 19:06:50 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Wed, 4 Jul 2012 19:06:50 +0200 From: "Hutton, Andrew" To: Stefan Hakansson LK Thread-Topic: [rtcweb] Use-case draft updated Thread-Index: AQHNVGJjS5A138f8RE2fuOSxPXLcSpcZWeyg Date: Wed, 4 Jul 2012 17:06:49 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF03603B@MCHP04MSX.global-ad.net> References: <4FEAFFBA.8020403@ericsson.com> In-Reply-To: <4FEAFFBA.8020403@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.255.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case draft updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 17:06:41 -0000 Hi Stefan, I am not sure what the consensus was regarding the changing of the wording = from "eavesdropping" to "wiretapping" but after discussion with a few peopl= e at the interim my thinking was that it would be best to remove the statem= ents from each use case regarding eavesdropping and replace it with bullets= in section 4.1 for considerations which apply to all use cases. These shou= ld state that all media streams and data channels must be integrity and con= fidentiality protected. I stated this in the following mail http://www.ietf.org/mail-archive/web/rt= cweb/current/msg04595.html. It might be best to check with the chairs and/or AD's what is the best and = acceptable wording given the RAVEN policy in RFC2804. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Stefan Hakansson LK > Sent: 27 June 2012 13:43 > To: rtcweb@ietf.org > Subject: [rtcweb] Use-case draft updated >=20 > Hi, >=20 > as already automatically announced, the use-case draft has been > updated. > Extract from the change log: >=20 > * Changed "eavesdropping" to "wiretapping" and referenced RFC2804. >=20 > * Removed informal ref webrtc_req; that document has been abandoned by > the W3C webrtc WG. >=20 > * Added use-case where one user is behind a FW that only allows http; > derived req. F37. >=20 > * Changed F24 slightly; MUST-> SHOULD, inserted "available". >=20 > * Added a clause to "Simple video communication service" saying that > the > service provider monitors the quality of service, and derived reqs F38 > and A26. >=20 > Most of the above are things that was documented in the minutes of the > Interim June 12th; I took the liberty to add some text (and reqs > A26/F38) on the service provider monitoring the QoE. >=20 > Feedback and comments are most welcome. >=20 > Also, Ekr has the task to deliver an Identity related use-case (as > discussed at the interim). >=20 > Stefan > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Wed Jul 4 12:39:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037AD21F85F6 for ; Wed, 4 Jul 2012 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9et81KYjMAB for ; Wed, 4 Jul 2012 12:39:49 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F14D021F85C4 for ; Wed, 4 Jul 2012 12:39:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11794829pbc.31 for ; Wed, 04 Jul 2012 12:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dWcj6sUhuCma+UmU73ZXgulPv60uyhHGrR9ORrd77lo=; b=oaamdkqxn/9/hr4bizcAz91RGTdUmI0ojm8nDyoZr/4zB8RY+ZhmW131VP6UMeIdxM HGmxv3c7iPFQBhrH0Q7Jky+rKAXOnqwu0zGfT69TWqshKCEqmzOBW+l5+GqZP12d39UN pUgmk7+E5pgiN8i3WnL6NdOSaAJuPXirofnQqSyOAjKZM4rttCAjxMkIM6s4+NqBsNgv aZDQXc05ZeU1OsogGXskisJOpo1Vq91P/6Ry+guIXpH1fFzUaJK3ViGijv68wU2H6WgU Wm7UYgLEUrv85ZvDtgX9mVKZxrucR4rR8f5r1xJRPXa9QGZjR7+5sOd4VWalrt5Y7aSH +gDA== Received: by 10.68.221.74 with SMTP id qc10mr21300203pbc.31.1341430792217; Wed, 04 Jul 2012 12:39:52 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id iu6sm18220720pbc.35.2012.07.04.12.39.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 12:39:51 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11794769pbc.31 for ; Wed, 04 Jul 2012 12:39:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.238.166 with SMTP id vl6mr21649081pbc.96.1341430789593; Wed, 04 Jul 2012 12:39:49 -0700 (PDT) Received: by 10.68.194.202 with HTTP; Wed, 4 Jul 2012 12:39:49 -0700 (PDT) In-Reply-To: <190327B0-72B8-4F9C-8A37-D932A2871879@edvina.net> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> <190327B0-72B8-4F9C-8A37-D932A2871879@edvina.net> Date: Wed, 4 Jul 2012 15:39:49 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=047d7b33cf62b45abf04c406315e X-Gm-Message-State: ALoCoQk7yJ9UdLcqlI/4mSIGAEOFn2MjV9uGi+4DlKQ9V7Z204W0G3QWrW64E8I4HdQjeHqsuRi4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 19:39:50 -0000 --047d7b33cf62b45abf04c406315e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 4, 2012 at 11:52 AM, Olle E. Johansson wrote: > > 4 jul 2012 kl. 17:11 skrev Roman Shpount: > > > > > I think this train left the station long time ago. WebRTC is not going > to interoperate with anything of significance currently deployed in SIP > world. Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will > need an application layer gateway. I guess the overall hope is that SIP > implementations will catch up implementing features required to work with > WebRTC in the future and gateways would be acceptable for current > implementations. > > Doesn't that mean that the IETF work on SIP over websockets will not lead > anywhere? > > Unless we have a SIP end point that supports DTLS-SRTP and ICE, understands AVPF profile, and knows how to negotiate RTP retransmissions and other RTP extensions, then I would say SIP over websockets will not help in communications between SIP and WebRTC. There are a few SIP endpoints that claim to support some of those specifications, but anything massively deployed in real life, like IP phones, PBXs, SBCs, PSTN gateways, and soft-phones, almost universally do not support or use any of those standards. SIP over websockets might be useful on its own though, for instance as a replacement for SIP-outbound, which fails to address even basic operational requirements for SIP clients behind NAT. Hopefully though, WebRTC will replace SIP on the client, and will remove the need for SIP behind NAT support altogether, making SIP over websockets completely irrelevant. _____________ Roman Shpount --047d7b33cf62b45abf04c406315e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 4, 2012 at 11:52 A= M, Olle E. Johansson <oej@edvina.net> wrote:

4 jul 2012 kl. 17:11 skrev Roman Shpount:

>
> I think this train left the station long time ago. WebRTC is not going= to interoperate with anything of significance currently deployed in SIP wo= rld. Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will need= an application layer gateway. I guess the overall hope is that SIP impleme= ntations will catch up implementing features required to work with WebRTC i= n the future and gateways would be acceptable for current implementations.<= br>
Doesn't that mean that the IETF work on SIP over websockets= will not lead anywhere?

=A0
Unless we have a SIP end point that supports DTLS-SRT= P=A0 and ICE, understands AVPF profile, and knows how to negotiate RTP retr= ansmissions and other RTP extensions, then I would say SIP over websockets = will not help in communications between SIP and WebRTC. There are a few SIP= endpoints that claim to support some of those specifications, but anything= massively deployed in real life, like IP phones, PBXs, SBCs, PSTN gateways= , and soft-phones,=A0 almost universally do not support or use any of those= standards.

SIP over websockets might be useful on its own though, for instance as = a replacement for SIP-outbound, which fails to address even basic operation= al requirements for SIP clients behind NAT. Hopefully though, WebRTC will r= eplace SIP on the client, and will remove the need for SIP behind NAT suppo= rt altogether, making SIP over websockets completely irrelevant.
_____________
Roman Shpount
--047d7b33cf62b45abf04c406315e-- From roman@telurix.com Wed Jul 4 12:46:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCD921F8618 for ; Wed, 4 Jul 2012 12:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rwK0psXbfOB for ; Wed, 4 Jul 2012 12:46:42 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCD521F8565 for ; Wed, 4 Jul 2012 12:46:42 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11802841pbc.31 for ; Wed, 04 Jul 2012 12:46:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=eO2xtArcS3H2vbFhUOUwCq637a6eSRRxjm6eud6Ls8Y=; b=M9H5nvCNhCnWYszVJs3H95GOvsS9XcLOdMxE1V4ma9iuIZfRWJIuRbxsWZuJpHU7a9 AGenJrgBf04EqxcXyA7vf5jel/Oadv/suNf7bNjyTwlKBrzBu9nOIKTsflp+Gq+FANno oUcma4y7a2sem1blD0kANvwyWaIRiM+pXH3fVlX+zTfVY59u0UYVk1WP1g3wYnHyVj33 Iw+4fKIj0H2eCbWdNkTAu9+ntyFwvdInzDvOkd63qzuSCMdRaYR3jmkA6N4llu/ryZQS 4vaVjVh+7ZzyRlGcZX1nXcROIB6FmDjh3ypn9Lq/NpSGDujF6NnnjsbGx487I662zznu WT2w== Received: by 10.68.222.40 with SMTP id qj8mr21647508pbc.139.1341431213619; Wed, 04 Jul 2012 12:46:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id wf7sm18229337pbc.34.2012.07.04.12.46.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 12:46:52 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11802757pbc.31 for ; Wed, 04 Jul 2012 12:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.103 with SMTP id ql7mr21959615pbc.68.1341431210945; Wed, 04 Jul 2012 12:46:50 -0700 (PDT) Received: by 10.68.194.202 with HTTP; Wed, 4 Jul 2012 12:46:50 -0700 (PDT) Date: Wed, 4 Jul 2012 15:46:50 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7b2ed431d1abaa04c4064a6f X-Gm-Message-State: ALoCoQnjU2+V8ldxovOGgCsYQF3Mc0AMeGzbwdXz8B8LjPO3W6FaTRzzPF7q95f3pYnjz86I8esW Subject: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 19:46:42 -0000 --047d7b2ed431d1abaa04c4064a6f Content-Type: text/plain; charset=ISO-8859-1 It looks like WebRTC-SIP interop without an application layer gateway would not be possible in the near future due to all the media transport requirements that were introduced. Given that SIP interop is no longer possible, why do we still need PRANSWER? Since an application layer gateway must be deployed, the same gateway can handle both serial and parallel forking. The WebRTC application will work with the gateway to create new streams or to create new connections, as necessary when new SIP dialogs are created and new answers are received. _____________ Roman Shpount --047d7b2ed431d1abaa04c4064a6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It looks like WebRTC-SIP interop without an application layer gateway would= not be possible in the near future due to all the media transport requirem= ents that were introduced. Given that SIP interop is no longer possible, wh= y do we still need PRANSWER? Since an application layer gateway must be dep= loyed, the same gateway can handle both serial and parallel forking. The We= bRTC application will work with the gateway to create new streams or to cre= ate new connections, as necessary when new SIP dialogs are created and new = answers are received.
_____________
Roman Shpount
--047d7b2ed431d1abaa04c4064a6f-- From lishitao@huawei.com Wed Jul 4 19:42:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741ED11E808D for ; Wed, 4 Jul 2012 19:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.879 X-Spam-Level: *** X-Spam-Status: No, score=3.879 tagged_above=-999 required=5 tests=[AWL=-2.543, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y2GVCfrL5gU for ; Wed, 4 Jul 2012 19:42:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE4211E8073 for ; Wed, 4 Jul 2012 19:42:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHL19791; Wed, 04 Jul 2012 22:42:15 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 19:40:45 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 19:40:42 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 10:40:39 +0800 From: Lishitao To: Roman Shpount , "Olle E. Johansson" Thread-Topic: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED Thread-Index: AQHNVVdzkH+KQgSjwk+Xd9991iicxZcQVB2AgACOBACABDhPgIAA1GGAgAC75ACAAhMTgIAAC1yAgAA/nICAAPfqgA== Date: Thu, 5 Jul 2012 02:40:39 +0000 Message-ID: References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> <190327B0-72B8-4F9C-8A37-D932A2871879@edvina.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.39] Content-Type: multipart/related; boundary="_004_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: [rtcweb] =?gb2312?b?tPC4tDogIFJUUCBVc2FnZTogSXMgUlRQIFJldHJhbnNt?= =?gb2312?b?aXNzaW9uIFJFUVVJUkVEIG9yCVJFQ09NTUVOREVE?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 02:42:08 -0000 --_004_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_ Content-Type: multipart/alternative; boundary="_000_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_" --_000_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBnb3Qgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhpcyBSVFAgUmV0cmFuc21pc3Npb24gc3RhZmYs IGlzIHRoZXJlIGEgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gcHJvdmlkZWQgaW4g UlRQIFJldHJhbnNtaXNzaW9uLCBsaWtlIG5lZ290aWF0ZSB0aGUgY2FwYWJpbGl0eSBpbiB0aGUg Zmlyc3Qgb2ZmZXIvYW5zd2VyIHRyYW5zaXRpb24uIChJIGRvbqGvdCBmaW5kIHRoYXQgaW4gdGhl IGRvY3VtZW50cywgb3IgaWYgSSBtaXNzIHNvbWV3aGVyZSkNCg0KDQoNCkkgYWxzbyBmaW5kICBp biBSRkMgNDU4OCwgaXQgbWVudGlvbmVkIHRoYXQgdGhlcmUgYXJlIHR3byB3YXlzIGZvciBSZXRy YW5zbWlzc2lvbiwgb25lIGlzIFNlc3Npb24tTXVsdGlwbGV4aW5nLCBhbm90aGVyIGlzIFNTUkMt TXVsdGlwbGV4aW5nLCBkb2VzIHRob3NlIHR3byBtZWNoYW5pc20gYm90aCBuZWVkIHRvIGJlIHN1 cHBvcnRlZCBmb3IgaW1wbGVtZW50YXRpb24/DQoNCg0KDQpSZWdhcmRzDQoNCnNoaXRhbw0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBI dWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KW0NvbXBhbnlfbG9nb10NCg0KUGhvbmU6DQpG YXg6DQpNb2JpbGU6DQpFbWFpbDoNCrXY1rejusnu29rK0MH6uNrH+NvgzO+7qs6qu/m12CDTyrHg o7o1MTgxMjkNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW50aWFuLCBMb25nZ2Fu ZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAuUi5DaGluYQ0KaHR0cDovL3d3dy5odWF3ZWku Y29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ksb7Tyrz+vLDG5Li9vP66rNPQ u6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX 6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fW tdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8 /qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQpUaGlzIGUtbWFp bCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZy b20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRp dHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p dGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRp c3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVu dChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBh bmQgZGVsZXRlIGl0IQ0Kt6K8/sjLOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbWFuIFNocG91bnQNCreiy83KsbzkOiAyMDEy xOo31MI1yNUgMzo0MA0KytW8/sjLOiBPbGxlIEUuIEpvaGFuc3Nvbg0Ks63LzTogcnRjd2ViQGll dGYub3JnDQrW98ziOiBSZTogW3J0Y3dlYl0gUlRQIFVzYWdlOiBJcyBSVFAgUmV0cmFuc21pc3Np b24gUkVRVUlSRUQgb3IgUkVDT01NRU5ERUQNCg0KDQpPbiBXZWQsIEp1bCA0LCAyMDEyIGF0IDEx OjUyIEFNLCBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ8bWFpbHRvOm9lakBlZHZp bmEubmV0Pj4gd3JvdGU6DQoNCjQganVsIDIwMTIga2wuIDE3OjExIHNrcmV2IFJvbWFuIFNocG91 bnQ6DQoNCj4NCj4gSSB0aGluayB0aGlzIHRyYWluIGxlZnQgdGhlIHN0YXRpb24gbG9uZyB0aW1l IGFnby4gV2ViUlRDIGlzIG5vdCBnb2luZyB0byBpbnRlcm9wZXJhdGUgd2l0aCBhbnl0aGluZyBv ZiBzaWduaWZpY2FuY2UgY3VycmVudGx5IGRlcGxveWVkIGluIFNJUCB3b3JsZC4gQmV0d2VlbiBE VExTLVNSVFAsIElDRSwgQVZQRiBhbmQgbm93IFJUUCByZXRyYW5zbWlzc2lvbnMgeW91IHdpbGwg bmVlZCBhbiBhcHBsaWNhdGlvbiBsYXllciBnYXRld2F5LiBJIGd1ZXNzIHRoZSBvdmVyYWxsIGhv cGUgaXMgdGhhdCBTSVAgaW1wbGVtZW50YXRpb25zIHdpbGwgY2F0Y2ggdXAgaW1wbGVtZW50aW5n IGZlYXR1cmVzIHJlcXVpcmVkIHRvIHdvcmsgd2l0aCBXZWJSVEMgaW4gdGhlIGZ1dHVyZSBhbmQg Z2F0ZXdheXMgd291bGQgYmUgYWNjZXB0YWJsZSBmb3IgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMu DQpEb2Vzbid0IHRoYXQgbWVhbiB0aGF0IHRoZSBJRVRGIHdvcmsgb24gU0lQIG92ZXIgd2Vic29j a2V0cyB3aWxsIG5vdCBsZWFkIGFueXdoZXJlPw0KDQpVbmxlc3Mgd2UgaGF2ZSBhIFNJUCBlbmQg cG9pbnQgdGhhdCBzdXBwb3J0cyBEVExTLVNSVFAgIGFuZCBJQ0UsIHVuZGVyc3RhbmRzIEFWUEYg cHJvZmlsZSwgYW5kIGtub3dzIGhvdyB0byBuZWdvdGlhdGUgUlRQIHJldHJhbnNtaXNzaW9ucyBh bmQgb3RoZXIgUlRQIGV4dGVuc2lvbnMsIHRoZW4gSSB3b3VsZCBzYXkgU0lQIG92ZXIgd2Vic29j a2V0cyB3aWxsIG5vdCBoZWxwIGluIGNvbW11bmljYXRpb25zIGJldHdlZW4gU0lQIGFuZCBXZWJS VEMuIFRoZXJlIGFyZSBhIGZldyBTSVAgZW5kcG9pbnRzIHRoYXQgY2xhaW0gdG8gc3VwcG9ydCBz b21lIG9mIHRob3NlIHNwZWNpZmljYXRpb25zLCBidXQgYW55dGhpbmcgbWFzc2l2ZWx5IGRlcGxv eWVkIGluIHJlYWwgbGlmZSwgbGlrZSBJUCBwaG9uZXMsIFBCWHMsIFNCQ3MsIFBTVE4gZ2F0ZXdh eXMsIGFuZCBzb2Z0LXBob25lcywgIGFsbW9zdCB1bml2ZXJzYWxseSBkbyBub3Qgc3VwcG9ydCBv ciB1c2UgYW55IG9mIHRob3NlIHN0YW5kYXJkcy4NCg0KU0lQIG92ZXIgd2Vic29ja2V0cyBtaWdo dCBiZSB1c2VmdWwgb24gaXRzIG93biB0aG91Z2gsIGZvciBpbnN0YW5jZSBhcyBhIHJlcGxhY2Vt ZW50IGZvciBTSVAtb3V0Ym91bmQsIHdoaWNoIGZhaWxzIHRvIGFkZHJlc3MgZXZlbiBiYXNpYyBv cGVyYXRpb25hbCByZXF1aXJlbWVudHMgZm9yIFNJUCBjbGllbnRzIGJlaGluZCBOQVQuIEhvcGVm dWxseSB0aG91Z2gsIFdlYlJUQyB3aWxsIHJlcGxhY2UgU0lQIG9uIHRoZSBjbGllbnQsIGFuZCB3 aWxsIHJlbW92ZSB0aGUgbmVlZCBmb3IgU0lQIGJlaGluZCBOQVQgc3VwcG9ydCBhbHRvZ2V0aGVy LCBtYWtpbmcgU0lQIG92ZXIgd2Vic29ja2V0cyBjb21wbGV0ZWx5IGlycmVsZXZhbnQuDQpfX19f X19fX19fX19fDQpSb21hbiBTaHBvdW50DQo= --_000_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable 
I got some questions about this RTP Retransmi=
ssion staff, is there a capability negotiation mechanism provided in RTP Re=
transmission, like negotiate the capability in the first offer/answer trans=
ition. (I don=A1=AFt find that in the documents, or if I miss somewhere)
 
I also find  in RFC 4588, it mentioned t=
hat there are two ways for Retransmission, one is Session-Multiplexing, another is SSRC-Multiplexing, does those two m=
echanism both need to be supported for implementation? 

 


Regards


shitao


 


 =
;










=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.

3D"Company_logo"



Phone: 

Fax: 

Mobile: 

Email: 

=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=
=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA51812=
9

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=
=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=
=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=
=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=
=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=
=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=
=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=
=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=
=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1

This e-mail and its attac=
hments contain confidential information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!




=B7=A2=BC=FE=C8=CB: rtcweb-=
bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
=B4=FA=
=B1=ED Roman Shpount

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C25=C8=D5
 3:40

=CA=D5=BC=FE=C8=CB: Olle E. Johansson

=B3=AD=CB=CD: rtcweb@ietf.org

=D6=F7=CC=E2: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED




 









On Wed, Jul 4, 2012 at 11:52 AM=
, Olle E. Johansson <oej@edvina.net> wrote:




4 jul 2012 kl. 17:11 skrev Roman Shpount:






=


>

> I think this train left the station long time ago. WebRTC is not going=
 to interoperate with anything of significance currently deployed in SIP wo=
rld. Between DTLS-SRTP, ICE, AVPF and now RTP retransmissions you will need=
 an application layer gateway. I guess
 the overall hope is that SIP implementations will catch up implementing fe=
atures required to work with WebRTC in the future and gateways would be acc=
eptable for current implementations.






=
Doesn't that mean that the IETF work on SIP over websockets will not lead a=
nywhere?




 






Unless we have a SIP end point =
that supports DTLS-SRTP  and ICE, understands AVPF profile, and knows =
how to negotiate RTP retransmissions and other RTP extensions, then I would=
 say SIP over websockets will not help in
 communications between SIP and WebRTC. There are a few SIP endpoints that =
claim to support some of those specifications, but anything massively deplo=
yed in real life, like IP phones, PBXs, SBCs, PSTN gateways, and soft-phone=
s,  almost universally do not support
 or use any of those standards. 



SIP over websockets might be useful on its own though, for instance as a re=
placement for SIP-outbound, which fails to address even basic operational r=
equirements for SIP clients behind NAT. Hopefully though, WebRTC will repla=
ce SIP on the client, and will remove
 the need for SIP behind NAT support altogether, making SIP over websockets=
 completely irrelevant.






_____________

Roman Shpount
--_000_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_-- --_004_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Thu, 05 Jul 2012 02:40:39 GMT"; modification-date="Thu, 05 Jul 2012 02:40:39 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_DA165A8A2929C6429CAB403A76B573A5146743F4szxeml534mbxchi_-- From hangzhou.chenxin@huawei.com Wed Jul 4 21:02:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235A221F846D for ; Wed, 4 Jul 2012 21:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0uJQt393Vfz for ; Wed, 4 Jul 2012 21:02:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE021F8467 for ; Wed, 4 Jul 2012 21:02:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS47544; Thu, 05 Jul 2012 00:03:02 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 21:00:17 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 21:00:22 -0700 Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.55]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 12:00:17 +0800 From: Chenxin To: Roman Shpount Thread-Topic: [rtcweb] Do we still need PRANSWER? Thread-Index: AQHNWlfUrUEiVj3t406FXZY0CSYoDpcaCNLg Date: Thu, 5 Jul 2012 04:00:15 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03972D53B002@szxeml538-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.108] Content-Type: multipart/alternative; boundary="_000_9E34D50A21D1D1489134B4D770CE03972D53B002szxeml538mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 04:02:51 -0000 --_000_9E34D50A21D1D1489134B4D770CE03972D53B002szxeml538mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 I think PRANSWER is still useful for Jingle interop especially for ICE ca= ndidate trickling. But I think we should not leave the WebRTC-SIP interop problem to the appl= ication layer gateway. I find some words in chart: 9. The group will consider options for interworking with legacy VoIP equipment. it is necessary to solve SIP interop problem in RTCWEB other than leaving i= t to implementor. BR, Xin From: Roman Shpount [mailto:roman@telurix.com] Sent: Thursday, July 05, 2012 3:47 AM To: rtcweb@ietf.org Subject: [rtcweb] Do we still need PRANSWER? It looks like WebRTC-SIP interop without an application layer gateway would= not be possible in the near future due to all the media transport requirem= ents that were introduced. Given that SIP interop is no longer possible, wh= y do we still need PRANSWER? Since an application layer gateway must be dep= loyed, the same gateway can handle both serial and parallel forking. The We= bRTC application will work with the gateway to create new streams or to cre= ate new connections, as necessary when new SIP dialogs are created and new = answers are received. _____________ Roman Shpount --_000_9E34D50A21D1D1489134B4D770CE03972D53B002szxeml538mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 I think PRANSWER is still= useful for Jingle interop especially  for ICE candidate trickling.

 

But I think we should not leave= the WebRTC-SIP interop  problem to the application layer gateway.

 

I find some words in chart:&n=
bsp;  
 9.  The group will consider options for interwor=
king with legacy VoIP

   &nbs= p;    equipment.

 = ;

it is necessary to solve SIP in= terop problem in RTCWEB other than leaving it to implementor.

 

BR,

 &nbs= p;  Xin

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Thursday, July 05, 2012 3:47 AM
To: rtcweb@ietf.org
Subject: [rtcweb] Do we still need PRANSWER?

 

It looks like WebRTC-SIP intero= p without an application layer gateway would not be possible in the near fu= ture due to all the media transport requirements that were introduced. Give= n that SIP interop is no longer possible, why do we still need PRANSWER? Since an application layer gateway must be = deployed, the same gateway can handle both serial and parallel forking. The= WebRTC application will work with the gateway to create new streams or to = create new connections, as necessary when new SIP dialogs are created and new answers are received.
_____________
Roman Shpount

--_000_9E34D50A21D1D1489134B4D770CE03972D53B002szxeml538mbxchi_-- From randell-ietf@jesup.org Wed Jul 4 22:11:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88D221F856C for ; Wed, 4 Jul 2012 22:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox6hjpWAdceR for ; Wed, 4 Jul 2012 22:11:36 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A52821F8569 for ; Wed, 4 Jul 2012 22:11:35 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SmeLz-0002WF-U0 for rtcweb@ietf.org; Thu, 05 Jul 2012 00:11:48 -0500 Message-ID: <4FF521DF.1090202@jesup.org> Date: Thu, 05 Jul 2012 01:10:55 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <4FF217DD.1060607@jesup.org> <4FF451C7.5080804@ericsson.com> In-Reply-To: <4FF451C7.5080804@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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 05:11:37 -0000 On 7/4/2012 10:23 AM, Stefan Hakansson LK wrote: > On 07/02/2012 11:51 PM, Randell Jesup wrote: >> >>> Again, this is about making _support_ for retransmission a requirement, >>> not _use_. >> >> >> If you don't mandate use, what does mandating "support" buy you? An >> implementation (see above about PSTN gateways) might always decline to >> use retransmission, so what does MUST (REQUIRE) buy you? I say SHOULD >> (RECOMMEND), with a statement that it's strongly recommended it be >> supported if video is supported, especially for non-single-purpose >> devices (i.e. browsers). >> >> In either case, you need to think about who decides to use re-xmit or >> not, what influences that, and if the app has visibility into this. >> Someone could as an rtx-time=0 to the SDP. Or not include one, but >> never actually retransmit a packet regardless of NACKs - it could just >> repair via IDR (or other means). >> >> So here's a real problem related to retransmission: since the request is >> not specific and negotiated (it's normally a generic NACK), the receiver >> who sent the NACK has no idea if it will get a retransmission, an IDR >> (or IDR slice), another form of repair (pframe/slice against >> known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, it >> doesn't know if it should freeze the video or play with errors. It has >> to decide if it *thinks* the sender will use retransmission, or if it >> doesn't, does the receiver want to freeze video until an IDR or other >> repair is done, which might be a while. > > Isn't retransmission negotiated using "rtx", "atp" and so on? Support for it is. However, negotiating support for it doesn't solve the problem of not knowing how the sender will respond to a NACK (or SLI/RPSI/etc). Generally, the sender has to make the decision, but the receiver has to guess. > > One way of removing the uncertainty would be to require that all > browsers support RTP retransmission: This way, any RTP endpoint > sending a NACK to a browser would know that that packet would be > retransmitted (given that congestion does not prohibit, or NACK packet > is lost etc.). Um, no. Just because both sides support retransmission does not mean that a NACK will generate a retransmission. Retransmission only makes sense in some instances, and there's no guarantee that retransmission will be possible (for example, the requested packet might have timed out and been thrown away). > > If we have this in place, I'm confident that implementors will quickly > develop strategies on how and when to _use_ retransmission in the best > way. There has already been input made on its usefulness. Sure, and they will anyways. RECOMMENDED or REQUIRED, it really doesn't matter to the implementation. For that matter, even if REQUIRED there's nothing that says it has to be offered or accepted. Even if that were mandated, the implementation could accept but with a 0-length rtx-time. So it's really unclear what REQUIRED buys you that RECOMMENDED doesn't. > > Maybe the problem with legacy not always supporting retransmission is > not that big. First of all, legacy is to a large extent audio only > (e.g. PSTN), and no one is arguing for retransmission there. Secondly, > I fail to see that this situation would be improved in any way if > browsers are only recommended (and not required) to support RTP > retransmission. > > So I think we should require rtcweb capable browsers to support RTP > retransmission. > >> >> We also need to think about when a receiver should use SLI or RPSI. PLI >> can also be used and should be if the other options don't negotiate (so >> it's important to offer it). Certainly it's more work to keep track of >> the contents of each packet (slices, etc), especially in things like >> H.264 NALU aggregation packets, than it is to just respond to an SLI. >> >> That said, my previous systems just used NACK and let the sender decide >> the correct repair, but I wasn't leveraging slices and wasn't using >> retransmission, so there was only minor complexity (looking at possible >> reference frames). -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Thu Jul 5 01:49:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820D621F85D3 for ; Thu, 5 Jul 2012 01:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfZAql23I5xh for ; Thu, 5 Jul 2012 01:49:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC321F84FF for ; Thu, 5 Jul 2012 01:49:01 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so12604030lbb.31 for ; Thu, 05 Jul 2012 01:49:13 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=MbG5EDuEtlEnkPx/EY/jPR/6mlACjbGlF/ShwGS3oCA=; b=VJpnNt6wskMLF3SbpqJ9WrW1Xi07d/VgDt7V1tpRnrBDmt7dAaSlWc6SjbvQidqXDF AE93vnVq3y2K0ZxunPgBXvBnTbvJFwAvaLyegyqOCrcucEBEqGyt56i/jayq1gNy1R1s bX6jcd4YZR9DshFlk6q8KY6ma4Md1ZKpgGAZ0RJzqRBS4XYo0C3044wAcmpLoCEauBil +3J5RCv38udA5OO16NPnwnhiHEKYcB6nTYb5fPP98U+MuY5fENh3w1thB9z9v76anqHK vLba9K5BBQ4NRepUyGc9EJIVrUUPk4w09rrozIEFdaNyLOz8ir8gGgygp6Wro94O+14X qkmQ== Received: by 10.112.10.198 with SMTP id k6mr11577914lbb.83.1341478153410; Thu, 05 Jul 2012 01:49:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Thu, 5 Jul 2012 01:48:53 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Jul 2012 10:48:53 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm9sUwk7MeQxgMjk/pk2dYmbAc4Og/A8SqakaRr11D7qXHZEwduqZxpzRaVDZaf6t/hHbWd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 08:49:02 -0000 2012/7/4 Roman Shpount : > It looks like WebRTC-SIP interop without an application layer gateway wou= ld > not be possible in the near future due to all the media transport > requirements that were introduced. Given that SIP interop is no longer > possible, why do we still need PRANSWER? Since an application layer gatew= ay > must be deployed, the same gateway can handle both serial and parallel > forking. No please, don't decide/mandate/impose how the signaling must be implemented. And don't assure that pure SIP signaling cannot be used in the browser neither force the usage of annoying B2BUA's or signaling-protocol-exotic-and-buggy-gateways in order to interop with SIP networks (mostly because pure SIP interop is already possible without negative elements like B2BUA's or signaling gateways). I want a pure SIP proxy and handle parallel and serial SIP forking as RFC 3261 states, without magic servers breaking things. And this *already* works [1] so it IS possible. If most of the people assume that WebRTC-SIP interop requires some amateur and limited JSON based signaling protocol between the (stupid?) browser and a magic JSON-SIP-MEDIA gateway (super-intelligent?), that's their assumption, but that should not be mandatory by specs. About the media plance interop: ok, WebRTC has added lot of stuff, but AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible to interop in the media plane without negative intermediary elements. In the other side, once WebRTC is extended I'm pretty sure that SIP designers and vendors will try to satisfy WebRTC media requirements within SIP, so let's leave the door open rather than "requiring $$$$$ B2BUA's black-death-boxes". Please, don't limit or force the network topology. > The WebRTC application will work with the gateway to create new > streams or to create new connections, as necessary when new SIP dialogs a= re > created and new answers are received. No, sorry, no. Or yes (in your specific case), but not in mine. Regards. [1] http://sip-on-the-web.aliax.net/ --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Thu Jul 5 02:12:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFF921F853C for ; Thu, 5 Jul 2012 02:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUleSi8q-VbC for ; Thu, 5 Jul 2012 02:12:49 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC0321F853B for ; Thu, 5 Jul 2012 02:12:48 -0700 (PDT) Received: from [192.168.40.89] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 57B61754A8AA; Thu, 5 Jul 2012 09:12:58 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 5 Jul 2012 11:12:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Roman Shpount X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 09:12:49 -0000 4 jul 2012 kl. 21:46 skrev Roman Shpount: > It looks like WebRTC-SIP interop without an application layer gateway = would not be possible in the near future due to all the media transport = requirements that were introduced. Given that SIP interop is no longer = possible I think that's a bad conclusion, Roman. I talked about the installed base of SIP devices and their RTP stack. It = doesn't mean that ALL SIP implementations won't be able to interop with = WebRTC and that there never will be SIP connected to webrtc, either in a = browser app or in a server implementation. I do expect that new SIP apps = will arise and that the current ones will be upgrading.=20 SIP interop is definitely possible in WebRTC regardless of the RTP = layer. I still think there's value in interop with a large installed base of = RTP-capable devices. Having media relays in the media path is known not = to improve media quality. /O= From roman@telurix.com Thu Jul 5 04:30:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22D421F85C9 for ; Thu, 5 Jul 2012 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fW4pvCWEYom for ; Thu, 5 Jul 2012 04:30:03 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B242321F85C3 for ; Thu, 5 Jul 2012 04:30:03 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so12995192pbc.31 for ; Thu, 05 Jul 2012 04:30:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+hoKTgtrikBLn46n9DH6AAfeSRDFmPVwAvuO4coFXF4=; b=l02PTpsXHEQPx/nRbOUfh62TkjOhhDkeXaZ6TyZYavaXu4D1RG9HVGNGaAWZIG8Mim Kp/0fv+co23monzRmhxNteUsDWM4VaIlqvrXbIuQlLerAdQEVy0SVHKnQaN9acM/FPRF DFtOIwFAcSJgkxOziSsqEAybAUkJvNs4/fsQ/aqH3/kNzbMCfsly5oo9MXqrw6pCpE5S B71/GikJ1RU4hrr8yb26AcL0jvrh9YG1Vg+PU3ag/8PKzRgabvMY/+uGDPWlyDbPrriw qvSx8VbVKq9GVZuC4zwiLBue6/WsQAu0j4eqNte5FFCqeQOJNDq+sTL5KUlayz9S4vog 0eLA== Received: by 10.68.217.40 with SMTP id ov8mr26816266pbc.131.1341487817010; Thu, 05 Jul 2012 04:30:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id or5sm224588pbb.44.2012.07.05.04.30.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 04:30:15 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so12995108pbc.31 for ; Thu, 05 Jul 2012 04:30:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.233.225 with SMTP id tz1mr5306461pbc.4.1341487814063; Thu, 05 Jul 2012 04:30:14 -0700 (PDT) Received: by 10.68.194.202 with HTTP; Thu, 5 Jul 2012 04:30:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jul 2012 07:30:14 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b33cacca0b56604c4137888 X-Gm-Message-State: ALoCoQmOjT+bQebl5RBabrdQIQlrvCN4Y2bhHrp76w8/q4wzeCxwVkF/w5vx9nz7eDbX6OdyoFOQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 11:30:05 -0000 --047d7b33cacca0b56604c4137888 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This was all written out of frustration mainly by the direction taken by this group on adding things that are not strictly necessary but break interoperability. It is completely incomprehensible to me why the group decided to add PRANSWER if connection cloning is just as easy to implement and would make, on one hand, interop easier, on another hand add significant new functionality. When I am saying that connection cloning is easy to implement I mean that I am willing to build a prototype based on chromium code that implements it. Getting the new API through IETF/W3C is above my skill level, since I am fairly bad at writing drafts. On Thu, Jul 5, 2012 at 4:48 AM, I=F1aki Baz Castillo wrote: > 2012/7/4 Roman Shpount : > > It looks like WebRTC-SIP interop without an application layer gateway > would > > not be possible in the near future due to all the media transport > > requirements that were introduced. Given that SIP interop is no longer > > possible, why do we still need PRANSWER? Since an application layer > gateway > > must be deployed, the same gateway can handle both serial and parallel > > forking. > > No please, don't decide/mandate/impose how the signaling must be > implemented. And don't assure that pure SIP signaling cannot be used > in the browser neither force the usage of annoying B2BUA's or > signaling-protocol-exotic-and-buggy-gateways in order to interop with > SIP networks (mostly because pure SIP interop is already possible > without negative elements like B2BUA's or signaling gateways). > > I want a pure SIP proxy and handle parallel and serial SIP forking as > RFC 3261 states, without magic servers breaking things. And this > *already* works [1] so it IS possible. > > I do not doubt that some SIP interop on the signaling level is possible. It would break, however, on a first case of parallel forking. My main concern, however, is the media level interop with any existing devices. Correct me if I am wrong, but your already working solution is using an older WebRTC implementation that supported plain RTP. If most of the people assume that WebRTC-SIP interop requires some > amateur and limited JSON based signaling protocol between the > (stupid?) browser and a magic JSON-SIP-MEDIA gateway > (super-intelligent?), that's their assumption, but that should not be > mandatory by specs. > I do not want magic gateways either, but it looks like when this group is adding features it assumes some sort of gateway would be present. > About the media plance interop: ok, WebRTC has added lot of stuff, but > AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible > to interop in the media plane without negative intermediary elements. > In the other side, once WebRTC is extended I'm pretty sure that SIP > designers and vendors will try to satisfy WebRTC media requirements > within SIP, so let's leave the door open rather than "requiring $$$$$ > B2BUA's black-death-boxes". > > SDES-SRTP support is not something that this group decided upon. If the group is honest about its security requirements (JavaScript application is not trusted), then SDES-SRTP should not be allowed. This means you need ICE+DTLS-SRTP+AVPF support in the SIP device to operate directly with WebRTC on the media plane. I curious if you can name one device that support all of those. I would actually buy one for interop alone. And from experience, I doubt that large SIP vendors would do anything meaningful for a while. Please, don't limit or force the network topology. > I do not, but I think that what the group effectively does. I got a feeling most of the major contributors only care about a limited sets of apps that do not need to concern themselves with interop. I also got a feeling that they are more concerned about marketing then security. > > The WebRTC application will work with the gateway to create new > > streams or to create new connections, as necessary when new SIP dialogs > are > > created and new answers are received. > > No, sorry, no. Or yes (in your specific case), but not in mine. > > It is, unfortunately, the only thing I can do in my case, since all the SIP end points I am dealing with (SIP Trunks in PBXs and SIP from VoIP vendors) do not support any encryption, have flaky support for SIP re-Invites, and some do parallel forking. It is the real world, and here, it is a magic box or bust. > [1] http://sip-on-the-web.aliax.net/ > > _____________ Roman Shpount --047d7b33cacca0b56604c4137888 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This was all written out of frustration mainly by the direction taken by th= is group on adding things that are not strictly necessary but break interop= erability. It is completely incomprehensible to me=A0 why the group decided= to add PRANSWER if connection cloning is just as easy to implement and wou= ld make, on one hand, interop easier, on another hand add significant new f= unctionality. When I am saying that connection cloning is easy to implement= I mean that I am willing to build a prototype based on chromium code that = implements it. Getting the new API through IETF/W3C is above my skill level= , since I am fairly bad at writing drafts.

On Thu, Jul 5, 2012 at 4:48 AM= , I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/7/4 Roman Shpount <roman@telur= ix.com>:
> It looks like WebRTC-SIP interop without an applicat= ion layer gateway would
> not be possible in the near future due to all the media transport
> requirements that were introduced. Given that SIP interop is no longer=
> possible, why do we still need PRANSWER? Since an application layer ga= teway
> must be deployed, the same gateway can handle both serial and parallel=
> forking.

No please, don't decide/mandate/impose how the signaling must be<= br> implemented. And don't assure that pure SIP signaling cannot be used in the browser neither force the usage of annoying B2BUA's or
signaling-protocol-exotic-and-buggy-gateways in order to interop with
SIP networks (mostly because pure SIP interop is already possible
without negative elements like B2BUA's or signaling gateways).

I want a pure SIP proxy and handle parallel and serial SIP forking as
RFC 3261 states, without magic servers breaking things. And this
*already* works [1] so it IS possible.


I do not doubt that some SIP interop on the signa= ling level is possible.=A0 It would break, however, on a first case of para= llel forking. My main concern, however, is the media level interop with any= existing devices.

Correct me if I am wrong, but your already working solution is using an= older WebRTC implementation that supported plain RTP.

If most of the people assume that WebRTC-SIP interop requires some
amateur and limited JSON based signaling protocol between the
(stupid?) browser and a magic JSON-SIP-MEDIA gateway
(super-intelligent?), that's their assumption, but that should not be mandatory by specs.

I do not want magic gateways either, but it looks lik= e when this group is adding features it assumes some sort of gateway would = be present.
=A0
About the media plance interop: ok, WebRTC has added lot of stuff, but
AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible
to interop in the media plane without negative intermediary elements.
In the other side, once WebRTC is extended I'm pretty sure that SIP
designers and vendors will try to satisfy WebRTC media requirements
within SIP, so let's leave the door open rather than "requiring $$= $$$
B2BUA's black-death-boxes".


SDES-SRTP support is not something that this grou= p decided upon. If the group is honest about its security requirements (Jav= aScript application is not trusted), then SDES-SRTP should not be allowed. = This means you need ICE+DTLS-SRTP+AVPF support in the SIP device to operate= directly with WebRTC on the media plane. I curious if you can name one dev= ice that support all of those. I would actually buy one for interop alone. = And from experience, I doubt that large SIP vendors would do anything meani= ngful for a while.

Please, don't limit or force the network topology.

I do not, but I think that what the group effe= ctively does. I got a feeling most of the major contributors only care abou= t a limited sets of apps that do not need to concern themselves with intero= p. I also got a feeling that they are more concerned about marketing then s= ecurity.


> The WebRTC application will work with the gateway to create new
> streams or to create new connections, as necessary when new SIP dialog= s are
> created and new answers are received.

No, sorry, no. Or yes (in your specific case), but not in mine.

It is, unfortunately, the only thing I can do in my c= ase, since all the SIP end points I am dealing with (SIP Trunks in PBXs and= SIP from VoIP vendors) do not support any encryption, have flaky support f= or SIP re-Invites, and some do parallel forking. It is the real world, and = here, it is a magic box or bust.
=A0
[1] http://s= ip-on-the-web.aliax.net/

_____________
Roman Shpount
--047d7b33cacca0b56604c4137888-- From roman@telurix.com Thu Jul 5 04:55:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F048221F855B for ; Thu, 5 Jul 2012 04:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRXS0FBEQhDr for ; Thu, 5 Jul 2012 04:54:58 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 940A321F844B for ; Thu, 5 Jul 2012 04:54:58 -0700 (PDT) Received: by ghbg16 with SMTP id g16so8092439ghb.31 for ; Thu, 05 Jul 2012 04:55:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=U7TgQ/7sisqbAYv6fU/nwnvdqbdJqKGch+IDwZgiAe8=; b=bgm0qDNJwLzQczG6UhTImo6pEmFxyeFW0rtjqK176YEcoUPGDYHIQ7Z1qq5h8IjIcX BejWHdkGa4mcIk/hP+1e/phlNQP35eNY0mujv5GbTJpyeY33+Ss33ZkuUO2BxSDFAhbc oyt/uQRvIDg9VoPyAOlMWI8451GWBiGiW+VsPa3EEFaaSB+dJ308h6FaRaBNYboZtPJj kiP994MslMmsz3SkjMnI42XY0ne+GMLex8S81GR0HvcK5jWHkds2+RYKvByWcyJNrBSM 2DZBoCP0mthswZLj76HmSQ3TYDzFJwescncouBaZn4ixgDgdMhg7oRz6bP9yAnA/J88w tXNg== Received: by 10.236.146.104 with SMTP id q68mr29382417yhj.28.1341489311645; Thu, 05 Jul 2012 04:55:11 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id a79sm11350758yhk.16.2012.07.05.04.55.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 04:55:10 -0700 (PDT) Received: by yenq13 with SMTP id q13so8067648yen.31 for ; Thu, 05 Jul 2012 04:55:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.72.163 with SMTP id e3mr15532834pav.42.1341489308408; Thu, 05 Jul 2012 04:55:08 -0700 (PDT) Received: by 10.68.194.202 with HTTP; Thu, 5 Jul 2012 04:55:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jul 2012 07:55:08 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=f46d042ef79db29c5f04c413d127 X-Gm-Message-State: ALoCoQkAkAY9XNo+K2w7S/lOShu6hteLkKwzzrkAK3OwiTJCCutCOsoTSpLK8yaw1eBYQR0NRFPH Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 11:55:00 -0000 --f46d042ef79db29c5f04c413d127 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 5, 2012 at 5:12 AM, Olle E. Johansson wrote: > > 4 jul 2012 kl. 21:46 skrev Roman Shpount: > > > It looks like WebRTC-SIP interop without an application layer gateway > would not be possible in the near future due to all the media transport > requirements that were introduced. Given that SIP interop is no longer > possible > > I think that's a bad conclusion, Roman. > > I talked about the installed base of SIP devices and their RTP stack. It > doesn't mean that ALL SIP implementations won't be able to interop with > WebRTC and that there never will be SIP connected to webrtc, either in a > browser app or in a server implementation. I do expect that new SIP apps > will arise and that the current ones will be upgrading. > > SIP interop is definitely possible in WebRTC regardless of the RTP layer. > > I still think there's value in interop with a large installed base of > RTP-capable devices. Having media relays in the media path is known not to > improve media quality. > > If we care about interop with existing devices something needs to be done about DTLS-SRTP and ICE. As far as I can see DTLS-SRTP is the major problem since it overly complex. It is probably not a problem for desktop/softphone applications that can use something like openssl or gnu-tls with DTLS-SRTP extension, but if you need to write this from scratch for an embedded platform, this protocol has too many features for no good reason. We would have been better of designing a new key negotiation mechanism that has the same qualities as DTLS-SRTP (ie uses public/private key exchange for session keys and protects from replay), but does not introduce the initial call setup delay or has so many features and options. This would, obviously, still mean that existing devices need to implement a new protocol to interop with WebRTC, but at least it would be a simpler protocol to implement and test. I know that the group still discusses the use of SDES-SRTP, but I do not think it satisfies the security requirements (ie it is not secure over HTTP, allows replay, not secure if JavaScript is compromised), so if we care about security, it should not be allowed. ICE on the other hand is an understandable requirement, but it is still something that is very badly supported by existing devices. On the positive note, it is at least claimed to be supported by some vendors, and they are typically quicker to fix bugs then to add features. The group is also talking about AVPF, RTP retransmissions and other RTP extensions, that typically break interop with existing devices. I think these extensions are fairly acceptable if some sort of media relay device is assumed, but would need to considered very carefully if legacy interop is needed. I think if the group operates under assumption that vast majority of the WebRTC calls would be between WebRTC end points, and only a small portion with communicate with legacy devices, such as SIP or Jingle, and would require a media gateway for it, then it should be spelled out. If interop is a priority, or even a hard requirement, then some of the design decisions should be different. Keep in mind, that support legacy interop will have significant negative impact on WebRTC, since it will has to be more complex (support more parameter negotiations, more RTP profiles, more key exchange mechanisms), and probably less secure. _____________ Roman Shpount --f46d042ef79db29c5f04c413d127 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 5, 2012 at 5:12 AM, Olle E. Johansso= n <oej@edvina.net> wrote:

4 jul 2012 kl. 21:46 skrev Roman Shpount:

> It looks like WebRTC-SIP interop without an application layer gateway = would not be possible in the near future due to all the media transport req= uirements that were introduced. Given that SIP interop is no longer possibl= e

I think that's a bad conclusion, Roman.

I talked about the installed base of SIP devices and their RTP stack. It do= esn't mean that ALL SIP implementations won't be able to interop wi= th WebRTC and that there never will be SIP connected to webrtc, either in a= browser app or in a server implementation. I do expect that new SIP apps w= ill arise and that the current ones will be upgrading.

SIP interop is definitely possible in WebRTC regardless of the RTP layer.
I still think there's value in interop with a large installed base of R= TP-capable devices. Having media relays in the media path is known not to i= mprove media quality.

=A0
If we car= e about interop with existing devices something needs to be done about DTLS= -SRTP and ICE.

As far as I can see DTLS-SRTP is the major problem s= ince it overly complex. It is probably not a problem for desktop/softphone = applications that can use something like openssl or gnu-tls with DTLS-SRTP = extension, but if you need to write this from scratch for an embedded platf= orm, this protocol has too many features for no good reason. We would have = been better of designing a new key negotiation mechanism that has the same = qualities as DTLS-SRTP (ie uses public/private key exchange for session key= s and protects from replay), but does not introduce the initial call setup = delay or has so many features and options. This would, obviously, still mea= n that existing devices need to implement a new protocol to interop with We= bRTC, but at least it would be a simpler protocol to implement and test.
I know that the group still discusses the use of SDES-SRTP, but I do no= t think it satisfies the security requirements (ie it is not secure over HT= TP, allows replay, not secure if JavaScript is compromised), so if we care = about security, it should not be allowed.

ICE on the other hand is an understandable requirement, but it is still= something that is very badly supported by existing devices. On the positiv= e note, it is at least claimed to be supported by some vendors, and they ar= e typically quicker to fix bugs then to add features.

The group is also talking about AVPF, RTP retransmissions and other RTP= extensions, that typically break interop with existing devices. I think th= ese extensions are fairly acceptable if some sort of media relay device is = assumed, but would need to considered very carefully if legacy interop is n= eeded.

I think if the group operates under assumption that vast majority of th= e WebRTC calls would be between WebRTC end points, and only a small portion= with communicate with legacy devices, such as SIP or Jingle, and would req= uire a media gateway for it, then it should be spelled out. If interop is a= priority, or even a hard requirement, then some of the design decisions sh= ould be different. Keep in mind, that support legacy interop will have sign= ificant negative impact on WebRTC, since it will has to be more complex (su= pport more parameter negotiations, more RTP profiles, more key exchange mec= hanisms), and probably less secure.
_____________
Roman Shpount

--f46d042ef79db29c5f04c413d127-- From remi.scavenius@wanadoo.fr Thu Jul 5 05:06:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC79121F8491 for ; Thu, 5 Jul 2012 05:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVWuN6yDWumA for ; Thu, 5 Jul 2012 05:06:05 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) by ietfa.amsl.com (Postfix) with ESMTP id 934F421F86B3 for ; Thu, 5 Jul 2012 05:06:03 -0700 (PDT) Received: from new-host.home ([90.16.170.38]) by mwinf5d32 with ME id Wc6E1j00G0q38lE03c6ElJ; Thu, 05 Jul 2012 14:06:16 +0200 From: Remi Scavenius Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-258037868 Date: Thu, 5 Jul 2012 14:06:14 +0200 In-Reply-To: To: rtcweb@ietf.org References: Message-Id: X-Mailer: Apple Mail (2.1084) Subject: Re: [rtcweb] rtcweb Digest, Vol 17, Issue 10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 12:06:08 -0000 --Apple-Mail-8-258037868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The programme of the WebRTC Conference (Paris, October 10-12) is online: http://www.uppersideconferences.com/webrtc2012/webrtc2012intro.html Regards Remi Scavenius, agenda manager. Le 5 juil. 2012 =E0 13:30, rtcweb-request@ietf.org a =E9crit : > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to=20 >=20 > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send rtcweb mailing list submissions to > rtcweb@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/rtcweb > or, via email, send a message with subject or body 'help' to > rtcweb-request@ietf.org >=20 > You can reach the person managing the list at > rtcweb-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rtcweb digest..." > Today's Topics: >=20 > 1. Re: Do we still need PRANSWER? (Chenxin) > 2. Re: RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED > (Randell Jesup) > 3. Re: Do we still need PRANSWER? (I?aki Baz Castillo) > 4. Re: Do we still need PRANSWER? (Olle E. Johansson) > 5. Re: Do we still need PRANSWER? (Roman Shpount) >=20 > De : Chenxin > Date : 5 juillet 2012 06:00:15 HAEC > =C0 : Roman Shpount > Cc : "rtcweb@ietf.org" > Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >=20 >=20 > +1 > I think PRANSWER is still useful for Jingle interop especially for = ICE candidate trickling. > =20 > But I think we should not leave the WebRTC-SIP interop problem to the = application layer gateway. > =20 > I find some words in chart: =20 > 9. The group will consider options for interworking with legacy VoIP > equipment. > =20 > it is necessary to solve SIP interop problem in RTCWEB other than = leaving it to implementor. > =20 > BR, > Xin > From: Roman Shpount [mailto:roman@telurix.com]=20 > Sent: Thursday, July 05, 2012 3:47 AM > To: rtcweb@ietf.org > Subject: [rtcweb] Do we still need PRANSWER? > =20 > It looks like WebRTC-SIP interop without an application layer gateway = would not be possible in the near future due to all the media transport = requirements that were introduced. Given that SIP interop is no longer = possible, why do we still need PRANSWER? Since an application layer = gateway must be deployed, the same gateway can handle both serial and = parallel forking. The WebRTC application will work with the gateway to = create new streams or to create new connections, as necessary when new = SIP dialogs are created and new answers are received. > _____________ > Roman Shpount >=20 >=20 >=20 > De : Randell Jesup > Date : 5 juillet 2012 07:10:55 HAEC > =C0 : rtcweb@ietf.org > Objet : R=E9p : [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or = RECOMMENDED >=20 >=20 > On 7/4/2012 10:23 AM, Stefan Hakansson LK wrote: >> On 07/02/2012 11:51 PM, Randell Jesup wrote: >>>=20 >>>> Again, this is about making _support_ for retransmission a = requirement, >>>> not _use_. >>>=20 >>>=20 >>> If you don't mandate use, what does mandating "support" buy you? An >>> implementation (see above about PSTN gateways) might always decline = to >>> use retransmission, so what does MUST (REQUIRE) buy you? I say = SHOULD >>> (RECOMMEND), with a statement that it's strongly recommended it be >>> supported if video is supported, especially for non-single-purpose >>> devices (i.e. browsers). >>>=20 >>> In either case, you need to think about who decides to use re-xmit = or >>> not, what influences that, and if the app has visibility into this. >>> Someone could as an rtx-time=3D0 to the SDP. Or not include one, = but >>> never actually retransmit a packet regardless of NACKs - it could = just >>> repair via IDR (or other means). >>>=20 >>> So here's a real problem related to retransmission: since the = request is >>> not specific and negotiated (it's normally a generic NACK), the = receiver >>> who sent the NACK has no idea if it will get a retransmission, an = IDR >>> (or IDR slice), another form of repair (pframe/slice against >>> known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, = it >>> doesn't know if it should freeze the video or play with errors. It = has >>> to decide if it *thinks* the sender will use retransmission, or if = it >>> doesn't, does the receiver want to freeze video until an IDR or = other >>> repair is done, which might be a while. >>=20 >> Isn't retransmission negotiated using "rtx", "atp" and so on? >=20 > Support for it is. However, negotiating support for it doesn't solve = the problem of not knowing how the sender will respond to a NACK (or = SLI/RPSI/etc). Generally, the sender has to make the decision, but the = receiver has to guess. >=20 >>=20 >> One way of removing the uncertainty would be to require that all = browsers support RTP retransmission: This way, any RTP endpoint sending = a NACK to a browser would know that that packet would be retransmitted = (given that congestion does not prohibit, or NACK packet is lost etc.). >=20 > Um, no. Just because both sides support retransmission does not mean = that a NACK will generate a retransmission. Retransmission only makes = sense in some instances, and there's no guarantee that retransmission = will be possible (for example, the requested packet might have timed out = and been thrown away). >=20 >>=20 >> If we have this in place, I'm confident that implementors will = quickly develop strategies on how and when to _use_ retransmission in = the best way. There has already been input made on its usefulness. >=20 > Sure, and they will anyways. RECOMMENDED or REQUIRED, it really = doesn't matter to the implementation. For that matter, even if REQUIRED = there's nothing that says it has to be offered or accepted. Even if = that were mandated, the implementation could accept but with a 0-length = rtx-time. So it's really unclear what REQUIRED buys you that = RECOMMENDED doesn't. >=20 >>=20 >> Maybe the problem with legacy not always supporting retransmission is = not that big. First of all, legacy is to a large extent audio only (e.g. = PSTN), and no one is arguing for retransmission there. Secondly, I fail = to see that this situation would be improved in any way if browsers are = only recommended (and not required) to support RTP retransmission. >>=20 >> So I think we should require rtcweb capable browsers to support RTP = retransmission. >>=20 >>>=20 >>> We also need to think about when a receiver should use SLI or RPSI. = PLI >>> can also be used and should be if the other options don't negotiate = (so >>> it's important to offer it). Certainly it's more work to keep track = of >>> the contents of each packet (slices, etc), especially in things like >>> H.264 NALU aggregation packets, than it is to just respond to an = SLI. >>>=20 >>> That said, my previous systems just used NACK and let the sender = decide >>> the correct repair, but I wasn't leveraging slices and wasn't using >>> retransmission, so there was only minor complexity (looking at = possible >>> reference frames). >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 >=20 >=20 >=20 >=20 > De : I=F1aki Baz Castillo > Date : 5 juillet 2012 10:48:53 HAEC > =C0 : Roman Shpount > Cc : rtcweb@ietf.org > Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >=20 >=20 > 2012/7/4 Roman Shpount : >> It looks like WebRTC-SIP interop without an application layer gateway = would >> not be possible in the near future due to all the media transport >> requirements that were introduced. Given that SIP interop is no = longer >> possible, why do we still need PRANSWER? Since an application layer = gateway >> must be deployed, the same gateway can handle both serial and = parallel >> forking. >=20 > No please, don't decide/mandate/impose how the signaling must be > implemented. And don't assure that pure SIP signaling cannot be used > in the browser neither force the usage of annoying B2BUA's or > signaling-protocol-exotic-and-buggy-gateways in order to interop with > SIP networks (mostly because pure SIP interop is already possible > without negative elements like B2BUA's or signaling gateways). >=20 > I want a pure SIP proxy and handle parallel and serial SIP forking as > RFC 3261 states, without magic servers breaking things. And this > *already* works [1] so it IS possible. >=20 > If most of the people assume that WebRTC-SIP interop requires some > amateur and limited JSON based signaling protocol between the > (stupid?) browser and a magic JSON-SIP-MEDIA gateway > (super-intelligent?), that's their assumption, but that should not be > mandatory by specs. >=20 > About the media plance interop: ok, WebRTC has added lot of stuff, but > AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible > to interop in the media plane without negative intermediary elements. > In the other side, once WebRTC is extended I'm pretty sure that SIP > designers and vendors will try to satisfy WebRTC media requirements > within SIP, so let's leave the door open rather than "requiring $$$$$ > B2BUA's black-death-boxes". >=20 > Please, don't limit or force the network topology. >=20 >=20 >=20 >> The WebRTC application will work with the gateway to create new >> streams or to create new connections, as necessary when new SIP = dialogs are >> created and new answers are received. >=20 > No, sorry, no. Or yes (in your specific case), but not in mine. >=20 >=20 > Regards. >=20 >=20 > [1] http://sip-on-the-web.aliax.net/ >=20 >=20 > --=20 > I=F1aki Baz Castillo > >=20 >=20 >=20 >=20 > De : "Olle E. Johansson" > Date : 5 juillet 2012 11:12:55 HAEC > =C0 : Roman Shpount > Cc : rtcweb@ietf.org > Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >=20 >=20 >=20 > 4 jul 2012 kl. 21:46 skrev Roman Shpount: >=20 >> It looks like WebRTC-SIP interop without an application layer gateway = would not be possible in the near future due to all the media transport = requirements that were introduced. Given that SIP interop is no longer = possible >=20 > I think that's a bad conclusion, Roman. >=20 > I talked about the installed base of SIP devices and their RTP stack. = It doesn't mean that ALL SIP implementations won't be able to interop = with WebRTC and that there never will be SIP connected to webrtc, either = in a browser app or in a server implementation. I do expect that new SIP = apps will arise and that the current ones will be upgrading.=20 >=20 > SIP interop is definitely possible in WebRTC regardless of the RTP = layer. >=20 > I still think there's value in interop with a large installed base of = RTP-capable devices. Having media relays in the media path is known not = to improve media quality. >=20 > /O >=20 >=20 >=20 > De : Roman Shpount > Date : 5 juillet 2012 13:30:14 HAEC > =C0 : I=F1aki Baz Castillo > Cc : rtcweb@ietf.org > Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >=20 >=20 > This was all written out of frustration mainly by the direction taken = by this group on adding things that are not strictly necessary but break = interoperability. It is completely incomprehensible to me why the group = decided to add PRANSWER if connection cloning is just as easy to = implement and would make, on one hand, interop easier, on another hand = add significant new functionality. When I am saying that connection = cloning is easy to implement I mean that I am willing to build a = prototype based on chromium code that implements it. Getting the new API = through IETF/W3C is above my skill level, since I am fairly bad at = writing drafts. >=20 > On Thu, Jul 5, 2012 at 4:48 AM, I=F1aki Baz Castillo = wrote: > 2012/7/4 Roman Shpount : > > It looks like WebRTC-SIP interop without an application layer = gateway would > > not be possible in the near future due to all the media transport > > requirements that were introduced. Given that SIP interop is no = longer > > possible, why do we still need PRANSWER? Since an application layer = gateway > > must be deployed, the same gateway can handle both serial and = parallel > > forking. >=20 > No please, don't decide/mandate/impose how the signaling must be > implemented. And don't assure that pure SIP signaling cannot be used > in the browser neither force the usage of annoying B2BUA's or > signaling-protocol-exotic-and-buggy-gateways in order to interop with > SIP networks (mostly because pure SIP interop is already possible > without negative elements like B2BUA's or signaling gateways). >=20 > I want a pure SIP proxy and handle parallel and serial SIP forking as > RFC 3261 states, without magic servers breaking things. And this > *already* works [1] so it IS possible. >=20 >=20 > I do not doubt that some SIP interop on the signaling level is = possible. It would break, however, on a first case of parallel forking. = My main concern, however, is the media level interop with any existing = devices. >=20 > Correct me if I am wrong, but your already working solution is using = an older WebRTC implementation that supported plain RTP. >=20 > If most of the people assume that WebRTC-SIP interop requires some > amateur and limited JSON based signaling protocol between the > (stupid?) browser and a magic JSON-SIP-MEDIA gateway > (super-intelligent?), that's their assumption, but that should not be > mandatory by specs. >=20 > I do not want magic gateways either, but it looks like when this group = is adding features it assumes some sort of gateway would be present. > =20 > About the media plance interop: ok, WebRTC has added lot of stuff, but > AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible > to interop in the media plane without negative intermediary elements. > In the other side, once WebRTC is extended I'm pretty sure that SIP > designers and vendors will try to satisfy WebRTC media requirements > within SIP, so let's leave the door open rather than "requiring $$$$$ > B2BUA's black-death-boxes". >=20 >=20 > SDES-SRTP support is not something that this group decided upon. If = the group is honest about its security requirements (JavaScript = application is not trusted), then SDES-SRTP should not be allowed. This = means you need ICE+DTLS-SRTP+AVPF support in the SIP device to operate = directly with WebRTC on the media plane. I curious if you can name one = device that support all of those. I would actually buy one for interop = alone. And from experience, I doubt that large SIP vendors would do = anything meaningful for a while.=20 >=20 > Please, don't limit or force the network topology. >=20 > I do not, but I think that what the group effectively does. I got a = feeling most of the major contributors only care about a limited sets of = apps that do not need to concern themselves with interop. I also got a = feeling that they are more concerned about marketing then security. >=20 >=20 > > The WebRTC application will work with the gateway to create new > > streams or to create new connections, as necessary when new SIP = dialogs are > > created and new answers are received. >=20 > No, sorry, no. Or yes (in your specific case), but not in mine. >=20 > It is, unfortunately, the only thing I can do in my case, since all = the SIP end points I am dealing with (SIP Trunks in PBXs and SIP from = VoIP vendors) do not support any encryption, have flaky support for SIP = re-Invites, and some do parallel forking. It is the real world, and = here, it is a magic box or bust. > =20 > [1] http://sip-on-the-web.aliax.net/ >=20 > _____________ > Roman Shpount >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-8-258037868 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 http://www.uppersideconferences.com/webrtc2012/webrtc2012intro.html=

Regards

Remi = Scavenius, agenda manager.

Le 5 juil. 2012 =E0 = 13:30, rtcweb-request@ietf.org a = =E9crit :

If you have received this digest without all the = individual message
attachments you will need to update your digest = options in your list
subscription.  To do so, go to

https://www.ietf.org= /mailman/listinfo/rtcweb

Click the 'Unsubscribe or edit = options' button, log in, and set "Get
MIME or Plain Text Digests?" to = MIME.  You can set this option
globally for all the list digests = you receive at this point.



Send rtcweb mailing list = submissions to
rtcweb@ietf.org

To = subscribe or unsubscribe via the World Wide Web, visit
= https://www.ietf.org/mailman/listinfo/rtcweb
or, via email, = send a message with subject or body 'help' to
= rtcweb-request@ietf.org

You can reach the person managing = the list at
= rtcweb-owner@ietf.org

When replying, please edit your = Subject line so it is more specific
than "Re: Contents of rtcweb = digest..."
Today's Topics:

  1. Re: Do we still = need PRANSWER? (Chenxin)
  2. Re: RTP Usage: Is RTP = Retransmission REQUIRED or RECOMMENDED
=      (Randell Jesup)
  3. Re: Do = we still need PRANSWER? (I?aki Baz Castillo)
  4. Re: Do = we still need PRANSWER? (Olle E. Johansson)
  5. Re: Do we = still need PRANSWER? (Roman Shpount)

De : Chenxin = <hangzhou.chenxin@huawei.com>
Date : = 5 = juillet 2012 06:00:15 HAEC
=C0 : Roman Shpount = <roman@telurix.com>
Cc : "rtcweb@ietf.org" = <rtcweb@ietf.org>
Objet : R=E9p : [rtcweb] Do we still need = PRANSWER?


+1=

 I= think PRANSWER is still useful for Jingle interop especially  for = ICE candidate trickling.

 

But I think we should not leave the WebRTC-SIP interop =  problem to the application layer gateway.

 

I =
find some words in chart:   
 9.  The group will =
consider options for interworking with legacy =
VoIP

   = ;     equipment.

 

it is necessary to solve SIP = interop problem in RTCWEB other than leaving it to = implementor.

 

BR,

    Xin

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Thursday, July 05, 2012 3:47 AM
To: rtcweb@ietf.org
Subject: [rtcweb] Do we still need = PRANSWER?

 

It looks like WebRTC-SIP interop without an application = layer gateway would not be possible in the near future due to all the = media transport requirements that were introduced. Given that SIP = interop is no longer possible, why do we still need PRANSWER? Since an application layer gateway must = be deployed, the same gateway can handle both serial and parallel = forking. The WebRTC application will work with the gateway to create new = streams or to create new connections, as necessary when new SIP dialogs are created and new answers are received.
_____________
Roman Shpount




De : Randell Jesup = <randell-ietf@jesup.org>
Date : 5 juillet 2012 07:10:55 HAEC
=C0 : = rtcweb@ietf.org
Objet : = R=E9p : [rtcweb] RTP Usage: Is RTP Retransmission = REQUIRED or RECOMMENDED


On 7/4/2012 10:23 = AM, Stefan Hakansson LK wrote:
On = 07/02/2012 11:51 PM, Randell Jesup wrote:

Again, = this is about making _support_ for retransmission a = requirement,
not = _use_.


If you don't mandate use, what = does mandating "support" buy you? =  An
implementation (see above about = PSTN gateways) might always decline = to
use retransmission, so what does MUST (REQUIRE) buy you? =  I say SHOULD
(RECOMMEND), with a statement = that it's strongly recommended it = be
supported if video is supported, especially for = non-single-purpose
devices (i.e. = browsers).

In either case, you need to = think about who decides to use re-xmit = or
not, what influences that, and if the app has visibility = into this.
Someone could as an rtx-time=3D0 = to the SDP.  Or not include one, = but
never actually retransmit a packet regardless of NACKs - = it could just
repair via IDR (or other = means).

So here's a real problem related = to retransmission: since the request = is
not specific and negotiated (it's normally a generic = NACK), the receiver
who sent the NACK has no idea if = it will get a retransmission, an = IDR
(or IDR slice), another form of repair (pframe/slice = against
known-decoded frame - rpsi/etc), or nothing at all (NACK = lost). So, it
doesn't know if it should freeze = the video or play with errors. It = has
to decide if it *thinks* the sender will use = retransmission, or if it
doesn't, does the receiver want = to freeze video until an IDR or = other
repair is done, which might be a = while.

Isn't = retransmission negotiated using "rtx", "atp" and so = on?

Support for it is.  However, negotiating = support for it doesn't solve the problem of not knowing how the sender = will respond to a NACK (or SLI/RPSI/etc).  Generally, the sender = has to make the decision, but the receiver has to = guess.


One way of removing the uncertainty would be to require = that all browsers support RTP retransmission: This way, any RTP endpoint = sending a NACK to a browser would know that that packet would be = retransmitted (given that congestion does not prohibit, or NACK packet = is lost etc.).

Um, no.  Just because both sides = support retransmission does not mean that a NACK will generate a = retransmission.  Retransmission only makes sense in some instances, = and there's no guarantee that retransmission will be possible (for = example, the requested packet might have timed out and been thrown = away).


If we have this in place, I'm confident that implementors = will quickly develop strategies on how and when to _use_ retransmission = in the best way. There has already been input made on its = usefulness.

Sure, and they will anyways. =  RECOMMENDED or REQUIRED, it really doesn't matter to the = implementation.  For that matter, even if REQUIRED there's nothing = that says it has to be offered or accepted.  Even if that were = mandated, the implementation could accept but with a 0-length rtx-time. =  So it's really unclear what REQUIRED buys you that RECOMMENDED = doesn't.


Maybe the problem with legacy not always supporting = retransmission is not that big. First of all, legacy is to a large = extent audio only (e.g. PSTN), and no one is arguing for retransmission = there. Secondly, I fail to see that this situation would be improved in = any way if browsers are only recommended (and not required) to support = RTP retransmission.

So I think we = should require rtcweb capable browsers to support RTP = retransmission.


We also need to think about when = a receiver should use SLI or RPSI. =  PLI
can also be used and should be = if the other options don't negotiate = (so
it's important to offer it).  Certainly it's more = work to keep track of
the contents of each packet = (slices, etc), especially in things = like
H.264 NALU aggregation packets, than it is to just respond = to an SLI.

That said, my previous systems = just used NACK and let the sender = decide
the correct repair, but I wasn't leveraging slices and = wasn't using
retransmission, so there was = only minor complexity (looking at = possible
reference = frames).


--
Randell = Jesup
randell-ietf@jesup.org





De : = I=F1aki Baz Castillo = <ibc@aliax.net>
Date : 5 juillet 2012 10:48:53 HAEC
=C0 : = Roman Shpount = <roman@telurix.com>
Cc : rtcweb@ietf.org
Objet : = R=E9p : [rtcweb] Do we still need = PRANSWER?


2012/7/4 Roman Shpount = <roman@telurix.com>:
It looks like = WebRTC-SIP interop without an application layer gateway = would
not be possible in the = near future due to all the media transport
requirements that were introduced. Given that SIP interop = is no longer
possible, why do = we still need PRANSWER? Since an application layer = gateway
must be deployed, the = same gateway can handle both serial and = parallel
forking.

No please, don't = decide/mandate/impose how the signaling must be
implemented. And = don't assure that pure SIP signaling cannot be used
in the browser = neither force the usage of annoying B2BUA's = or
signaling-protocol-exotic-and-buggy-gateways in order to interop = with
SIP networks (mostly because pure SIP interop is already = possible
without negative elements like B2BUA's or signaling = gateways).

I want a pure SIP proxy and handle parallel and serial = SIP forking as
RFC 3261 states, without magic servers breaking = things. And this
*already* works [1] so it IS possible.

If = most of the people assume that WebRTC-SIP interop requires = some
amateur and limited JSON based signaling protocol between = the
(stupid?) browser and a magic JSON-SIP-MEDIA = gateway
(super-intelligent?), that's their assumption, but that = should not be
mandatory by specs.

About the media plance = interop: ok, WebRTC has added lot of stuff, but
AFAIK if the SIP side = implements ICE + SDES-SRTP it should be possible
to interop in the = media plane without negative intermediary elements.
In the other = side, once WebRTC is extended I'm pretty sure that SIP
designers and = vendors will try to satisfy WebRTC media requirements
within SIP, so = let's leave the door open rather than "requiring $$$$$
B2BUA's = black-death-boxes".

Please, don't limit or force the network = topology.



The WebRTC = application will work with the gateway to create = new
streams or to create new = connections, as necessary when new SIP dialogs = are
created and new answers = are received.

No, sorry, no. Or yes (in your = specific case), but not in mine.


Regards.


[1] = http://sip-on-the-web.aliax.net/


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




De : = "Olle E. Johansson" = <oej@edvina.net>
Date : 5 juillet 2012 11:12:55 HAEC
=C0 : = Roman Shpount = <roman@telurix.com>
Cc : rtcweb@ietf.org
Objet : = R=E9p : [rtcweb] Do we still need = PRANSWER?



4 jul 2012 kl. 21:46 skrev = Roman Shpount:

It looks like WebRTC-SIP = interop without an application layer gateway would not be possible in = the near future due to all the media transport requirements that were = introduced. Given that SIP interop is no longer = possible

I think that's a bad conclusion, = Roman.

I talked about the installed base of SIP devices and their = RTP stack. It doesn't mean that ALL SIP implementations won't be able to = interop with WebRTC and that there never will be SIP connected to = webrtc, either in a browser app or in a server implementation. I do = expect that new SIP apps will arise and that the current ones will be = upgrading.

SIP interop is definitely possible in WebRTC = regardless of the RTP layer.

I still think there's value in = interop with a large installed base of RTP-capable devices. Having media = relays in the media path is known not to improve media = quality.

/O



De : Roman Shpount = <roman@telurix.com>
Date : 5 juillet 2012 13:30:14 HAEC
=C0 : = I=F1aki Baz Castillo = <ibc@aliax.net>
Cc : rtcweb@ietf.org
Objet : = R=E9p : [rtcweb] Do we still need = PRANSWER?


This was all written out of = frustration mainly by the direction taken by this group on adding things = that are not strictly necessary but break interoperability. It is = completely incomprehensible to me  why the group decided to add = PRANSWER if connection cloning is just as easy to implement and would = make, on one hand, interop easier, on another hand add significant new = functionality. When I am saying that connection cloning is easy to = implement I mean that I am willing to build a prototype based on = chromium code that implements it. Getting the new API through IETF/W3C = is above my skill level, since I am fairly bad at writing drafts.

On Thu, Jul 5, 2012 at 4:48 = AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/7/4 Roman Shpount <roman@telurix.com>:
> It looks like WebRTC-SIP interop without an = application layer gateway would
> not be possible in the near future due to all the media = transport
> requirements that were introduced. Given that SIP interop is no = longer
> possible, why do we still need PRANSWER? Since an application layer = gateway
> must be deployed, the same gateway can handle both serial and = parallel
> forking.

No please, don't decide/mandate/impose how the signaling must = be
implemented. And don't assure that pure SIP signaling cannot be used
in the browser neither force the usage of annoying B2BUA's or
signaling-protocol-exotic-and-buggy-gateways in order to interop = with
SIP networks (mostly because pure SIP interop is already possible
without negative elements like B2BUA's or signaling gateways).

I want a pure SIP proxy and handle parallel and serial SIP forking = as
RFC 3261 states, without magic servers breaking things. And this
*already* works [1] so it IS possible.


I do not doubt that some SIP interop on the = signaling level is possible.  It would break, however, on a first = case of parallel forking. My main concern, however, is the media level = interop with any existing devices.

Correct me if I am wrong, but your already working solution is using = an older WebRTC implementation that supported plain = RTP.

If most of the people assume that WebRTC-SIP interop requires some
amateur and limited JSON based signaling protocol between the
(stupid?) browser and a magic JSON-SIP-MEDIA gateway
(super-intelligent?), that's their assumption, but that should not = be
mandatory by specs.

I do not want magic gateways either, but it looks = like when this group is adding features it assumes some sort of gateway = would be present.
 
About the media plance interop: ok, WebRTC has added lot of stuff, = but
AFAIK if the SIP side implements ICE + SDES-SRTP it should be = possible
to interop in the media plane without negative intermediary = elements.
In the other side, once WebRTC is extended I'm pretty sure that SIP
designers and vendors will try to satisfy WebRTC media requirements
within SIP, so let's leave the door open rather than "requiring = $$$$$
B2BUA's black-death-boxes".


SDES-SRTP support is not something that this = group decided upon. If the group is honest about its security = requirements (JavaScript application is not trusted), then SDES-SRTP = should not be allowed. This means you need ICE+DTLS-SRTP+AVPF support in = the SIP device to operate directly with WebRTC on the media plane. I = curious if you can name one device that support all of those. I would = actually buy one for interop alone. And from experience, I doubt that = large SIP vendors would do anything meaningful for a while.

Please, don't limit or force the network topology.

I do not, but I think that what = the group effectively does. I got a feeling most of the major = contributors only care about a limited sets of apps that do not need to = concern themselves with interop. I also got a feeling that they are more = concerned about marketing then security.


> The WebRTC application will work with the gateway to create new
> streams or to create new connections, as necessary when new SIP = dialogs are
> created and new answers are received.

No, sorry, no. Or yes (in your specific case), but not in = mine.

It is, unfortunately, the only thing I can do in = my case, since all the SIP end points I am dealing with (SIP Trunks in = PBXs and SIP from VoIP vendors) do not support any encryption, have = flaky support for SIP re-Invites, and some do parallel forking. It is = the real world, and here, it is a magic box or bust.
 
[1] http://sip-on-the-web.aliax.net/

_____________
Ro= man Shpount


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

= --Apple-Mail-8-258037868-- From ibc@aliax.net Thu Jul 5 05:07:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770EF21F86B6 for ; Thu, 5 Jul 2012 05:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X0SpyxTeh3u for ; Thu, 5 Jul 2012 05:07:17 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E543D21F86B5 for ; Thu, 5 Jul 2012 05:07:16 -0700 (PDT) Received: by bkty7 with SMTP id y7so334077bkt.31 for ; Thu, 05 Jul 2012 05:07:21 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=iYF5MDs/z175QFrGJMSBUg1x6R540ZqZ247Y9EFgO/Y=; b=Fsx7eeb9FKcYGCkhoJVhDlsjOrfMqDV0UFYo0iPIKAwF1k2knXJ9F9dl8CIvvF7ze4 5ExJS94jVNXSc2oJihVvXiu5wqNF03We2H0K4BtoAyGJ7tLL1w2xl/hINMExCwyEIkHY a+6D8k4VyI20Dw6wSRYcKaMKNpsoUgta2r/j5kw60L5SrLOLPKphNWsDtuSwATPYUUST 0jEG9VPF8JO1iB+kNpsitQEsHXrUGVgbzJhd7Zq+X+MInRwxQwQ+aJEt5l2GWEUcT14R tq+H0g4USK1aIyL4UDhGbAuWXKkK6eT+ldZV7R5RpdRmd1TBbnIIE0TOeNwaIUg2mYwr jaJw== Received: by 10.152.108.144 with SMTP id hk16mr25701198lab.2.1341490041574; Thu, 05 Jul 2012 05:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Thu, 5 Jul 2012 05:07:01 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Jul 2012 14:07:01 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn4QlBQt5BzFTzldxJ80Yl1F5BA7Ie4qvYPtRpG+VVD1lMnyHemybXcdoP5wr9+poJujoia Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 12:07:18 -0000 2012/7/5 Roman Shpount : > This was all written out of frustration mainly by the direction taken by > this group on adding things that are not strictly necessary but break > interoperability. Hi Roman, I did know that you mail was more a "passionate" mail (mine also)= :) > On Thu, Jul 5, 2012 at 4:48 AM, I=C3=B1aki Baz Castillo w= rote: >> I want a pure SIP proxy and handle parallel and serial SIP forking as >> RFC 3261 states, without magic servers breaking things. And this >> *already* works [1] so it IS possible. >> > > I do not doubt that some SIP interop on the signaling level is possible. = It > would break, however, on a first case of parallel forking. I don't know way. If my SIP client (in browser JS) receives varios provisional responses with SDP I can act as so many SIP devices choosing just one of them or whatever. IMHO that's up to the implementor. > My main concern, > however, is the media level interop with any existing devices. Sure. > Correct me if I am wrong, but your already working solution is using an > older WebRTC implementation that supported plain RTP. Well, the fact is that we just test media in browser-to-browser, which means SRTP. >> If most of the people assume that WebRTC-SIP interop requires some >> amateur and limited JSON based signaling protocol between the >> (stupid?) browser and a magic JSON-SIP-MEDIA gateway >> (super-intelligent?), that's their assumption, but that should not be >> mandatory by specs. > > > I do not want magic gateways either, but it looks like when this group is > adding features it assumes some sort of gateway would be present. And it's really BAD that a IETF WG assumes that magic servers (media-gateways) are required for a new *Internet* protocol to properly interoperate with existing standard networks. And what I mean is that, in case a SIP network and devices support ICE + DTLS+SRTP it should be possible to direct interop (in the media plane) between WebRTC and that SIP/Jingle network. >> About the media plance interop: ok, WebRTC has added lot of stuff, but >> AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible >> to interop in the media plane without negative intermediary elements. >> In the other side, once WebRTC is extended I'm pretty sure that SIP >> designers and vendors will try to satisfy WebRTC media requirements >> within SIP, so let's leave the door open rather than "requiring $$$$$ >> B2BUA's black-death-boxes". >> > > SDES-SRTP support is not something that this group decided upon. My fault, I meant "DTLS-SRTP". Note that DTLS-SRTP is *already* specified for SIP (in some XXXX RFC I cannot remember now). The fact that lazy vendors don't implement it (because they are happy with their "security" based on B2BUA's and walled gardens) does not mean that real media interop is possible once SIP vendors implement what they MUST implement (or die). > If the > group is honest about its security requirements (JavaScript application i= s > not trusted), then SDES-SRTP should not be allowed. This means you need > ICE+DTLS-SRTP+AVPF support in the SIP device to operate directly with Web= RTC > on the media plane. I curious if you can name one device that support all= of > those. I would actually buy one for interop alone. And from experience, I > doubt that large SIP vendors would do anything meaningful for a while. At least I hope that SIP vendors will be interested in media interop once WebRTC is widely adopted. >> Please, don't limit or force the network topology. > > > I do not, but I think that what the group effectively does. I got a feeli= ng > most of the major contributors only care about a limited sets of apps tha= t > do not need to concern themselves with interop. I also got a feeling that > they are more concerned about marketing then security. Too much business for gateways vendors here IMHO... BAD. This is an IETF WG, not GSMA/3GPP stuff. >> > The WebRTC application will work with the gateway to create new >> > streams or to create new connections, as necessary when new SIP dialog= s >> > are >> > created and new answers are received. >> >> No, sorry, no. Or yes (in your specific case), but not in mine. >> > It is, unfortunately, the only thing I can do in my case, since all the S= IP > end points I am dealing with (SIP Trunks in PBXs and SIP from VoIP vendor= s) > do not support any encryption, have flaky support for SIP re-Invites, and > some do parallel forking. It is the real world, and here, it is a magic b= ox > or bust. Sure, 90% of existing SIP stuff could be dropped. It's the mission of SIP vendors to build nice SIP devices with proper and modern security features (as *already* specified for SIP !!). Regards. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Thu Jul 5 06:12:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD021F844C for ; Thu, 5 Jul 2012 06:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQJvpRCJKMrw for ; Thu, 5 Jul 2012 06:12:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E68A021F86AA for ; Thu, 5 Jul 2012 06:12:38 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1003] (unknown [IPv6:2001:16d8:cc57:1000::42:1003]) by smtp7.webway.se (Postfix) with ESMTPA id F10F5754A8AC; Thu, 5 Jul 2012 13:12:44 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 5 Jul 2012 15:12:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <470FC35F-B04F-4F4A-9D8A-9AD766C79F2C@edvina.net> References: To: Roman Shpount X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 13:12:45 -0000 5 jul 2012 kl. 13:30 skrev Roman Shpount: > This was all written out of frustration mainly by the direction taken = by this group on adding things that are not strictly necessary but break = interoperability. Oh. Sorry for my total misunderstanding, Roman! /O= From martin.thomson@gmail.com Thu Jul 5 08:47:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3E721F86C9 for ; Thu, 5 Jul 2012 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOmLfxnWR3B8 for ; Thu, 5 Jul 2012 08:47:50 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A35A21F862A for ; Thu, 5 Jul 2012 08:47:50 -0700 (PDT) Received: by bkty7 with SMTP id y7so579645bkt.31 for ; Thu, 05 Jul 2012 08:48:03 -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=OBIKHwbp6LgPeXdYFPV2m3qDfcYWZ3GnTcxTBSZrRY8=; b=SKR2fSnT++Mc7FJNf9hZh6BSiT05Oua29lmmB8HdhFpaBHFiQmlexWu8gacEkvaQe8 ev+INADeq/GCFiRCQtjTtnaPtuwUdbWbGal2/7vZPUndvXCGOqWR4kx4qkpA7TYh4plX oDiQxfg0TbpK7JAuBjPxUUB+PPlujHUfxHj0fvc+iaMmUkjSyT7j7MtAbGOdal1jyDeA XLwWw7AznelR9QEk4MpzrtqJA6ZqpIcWrKjtJwp7anZJ+v72Get3rcxDCJXPatAEOEmo TN6Z2kVsVC8UQV6SDU1VGhyXJs8X9RgT2cUcJmbzijrlyn9eO2a5n0lu1DeR3T3FRi0x T2Aw== MIME-Version: 1.0 Received: by 10.204.152.216 with SMTP id h24mr11015410bkw.42.1341503283239; Thu, 05 Jul 2012 08:48:03 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 5 Jul 2012 08:48:02 -0700 (PDT) In-Reply-To: References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> <190327B0-72B8-4F9C-8A37-D932A2871879@edvina.net> Date: Thu, 5 Jul 2012 08:48:02 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 15:47:51 -0000 On 4 July 2012 12:39, Roman Shpount wrote: > Unless we have a SIP end point that supports DTLS-SRTP and ICE, understands > AVPF profile, and knows how to negotiate RTP retransmissions and other RTP > extensions, [...] I think that this is a little pessimistic. SRTP with SDES is still a viable option, for this reason. The SIP endpoint can implement ICE-lite and still interoperate. AVPF senders can interoperate with AVP receivers unless you have some strange business going on at the AVP end. And RTP retransmission is easy to claim support for without actually supporting (either the NACKs or the retransmissions got lost, I don't know which, sorry). From martin.thomson@gmail.com Thu Jul 5 08:49:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2BD21F87B2 for ; Thu, 5 Jul 2012 08:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNHomLQwGrWh for ; Thu, 5 Jul 2012 08:49:48 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C39B721F87AD for ; Thu, 5 Jul 2012 08:49:47 -0700 (PDT) Received: by bkty7 with SMTP id y7so581734bkt.31 for ; Thu, 05 Jul 2012 08:50:01 -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=Lrrsz00ZmI0pGS9Yp4HniUEWSQRZRrGtDBKmm3MZpOs=; b=tXyhB4pggXbevbimnWlIS8HmoM3e/6oG71unbVokCfnLzpuXvZfxRxlRbD95HAn335 JdPQhfSlBsR+PstUgiW23a/hHvgbzS2Ky0DrSfTYVeGQWaiFh5L1tjv9tgBrxtFFGLON j3RT5I+RGyJvqdklz7j3zA3c4d8H4SldRLFJVyVgASI8OEjwp3HQWOcFshaA7OQFdzUr CsLehth58xkHiT1gSze/cHxFht+8Qh/CX0nVAD6biMKDC9W7HYC1Zk/CNIYVbTv4tAI3 ZuYytYWILwHs2102tqHyvfYMW+YQRuAASgYqsX1dYoV9ljgt6pcIydSS683qPCCAV8Ab 7Y4w== MIME-Version: 1.0 Received: by 10.205.132.6 with SMTP id hs6mr13812301bkc.26.1341503400945; Thu, 05 Jul 2012 08:50:00 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 5 Jul 2012 08:50:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jul 2012 08:50:00 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 15:49:48 -0000 On 5 July 2012 04:30, Roman Shpount wrote: > This was all written out of frustration mainly by the direction taken by > this group on adding things that are not strictly necessary but break > interoperability. It is completely incomprehensible to me why the group > decided to add PRANSWER if connection cloning is just as easy to implement > and would make, on one hand, interop easier, on another hand add significant > new functionality. When I am saying that connection cloning is easy to > implement I mean that I am willing to build a prototype based on chromium > code that implements it. Getting the new API through IETF/W3C is above my > skill level, since I am fairly bad at writing drafts. PRANSWER is purely an API construct. How does that affect interoperability other than making it harder to write the browser code that achieves it? From oej@edvina.net Thu Jul 5 09:07:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A7B21F8794 for ; Thu, 5 Jul 2012 09:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-Juowdf-1Z8 for ; Thu, 5 Jul 2012 09:07:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id DC8D921F877A for ; Thu, 5 Jul 2012 09:07:29 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1003] (unknown [IPv6:2001:16d8:cc57:1000::42:1003]) by smtp7.webway.se (Postfix) with ESMTPA id 888CA754A8AA; Thu, 5 Jul 2012 16:07:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Thu, 5 Jul 2012 18:07:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39081BA7-F02E-4991-AA70-E9423B8A8429@edvina.net> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> <190327B0-72B8-4F9C-8A37-D932A2871879@edvina.net> To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 16:07:31 -0000 5 jul 2012 kl. 17:48 skrev Martin Thomson: > On 4 July 2012 12:39, Roman Shpount wrote: >> Unless we have a SIP end point that supports DTLS-SRTP and ICE, = understands >> AVPF profile, and knows how to negotiate RTP retransmissions and = other RTP >> extensions, [...] >=20 > I think that this is a little pessimistic. SRTP with SDES is still a > viable option, for this reason. The SIP endpoint can implement > ICE-lite and still interoperate. AVPF senders can interoperate with > AVP receivers unless you have some strange business going on at the > AVP end. And RTP retransmission is easy to claim support for without > actually supporting (either the NACKs or the retransmissions got lost, > I don't know which, sorry). The discussion started with REQUIREments on developers.=20 "The development of the WebRTC framework provides an opportunity for us to review the available RTP features and extensions, and to define a common baseline feature set for all WebRTC implementations of RTP. This builds on the past 15 years development of RTP to mandate the use of extensions that have shown widespread utility, while still remaining compatible with the wide installed base of RTP implementations where possible." http://www.ietf.org/id/draft-ietf-rtcweb-rtp-usage-03.txt I really think we should be very careful to REQUIRE implementations to = implement functions that break this goal. /O= From martin.thomson@gmail.com Thu Jul 5 09:12:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59DF21F85C0 for ; Thu, 5 Jul 2012 09:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC9O6n8M1fOO for ; Thu, 5 Jul 2012 09:12:56 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20F3B21F85BB for ; Thu, 5 Jul 2012 09:12:54 -0700 (PDT) Received: by bkty7 with SMTP id y7so607679bkt.31 for ; Thu, 05 Jul 2012 09:13: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=9f/AnbPDwbMxgK3VI3AF8HpRJT3JaZsMTRLlCxMbhCs=; b=k0yxjpzRy/DhbvihjrtjUpf+psjU74/6doBOm9Gik2A+KkpVx8gNIy3XlFB8fymLqq ueAM6DVrV6eChi2Vy0PXC5qp8556sIOtj8a8CMsuRN51l1BOK1eRW04vwMbQ0wFxc8VD BAFdo2PwjD/GZ/LaWQyT4pybnDpvPca/t2YyvT2UtKtoT48v72DE2YfFHXb+63m93zsC ZKUZN+SMJgeVkoMokYuTVJihQW92Nr/+1Dj2i3dfduyxwGNod1VTK9lZR8q4g5noE5eL tqCqsmF5ypWWVObav3P1YNYbxV3DtyUbG5bM5xQaGYfKvUrabIoqLH+Ylk104pG77/6d r8UQ== MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr3299005bkw.49.1341504788281; Thu, 05 Jul 2012 09:13:08 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 5 Jul 2012 09:13:08 -0700 (PDT) In-Reply-To: <39081BA7-F02E-4991-AA70-E9423B8A8429@edvina.net> References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <208EC80D-D101-43CC-9ED7-5BA3E2F39A87@edvina.net> <190327B0-72B8-4F9C-8A37-D932A2871879@edvina.net> <39081BA7-F02E-4991-AA70-E9423B8A8429@edvina.net> Date: Thu, 5 Jul 2012 09:13:08 -0700 Message-ID: From: Martin Thomson To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 16:12:58 -0000 On 5 July 2012 09:07, Olle E. Johansson wrote: > I really think we should be very careful to REQUIRE implementations to implement > functions that break this goal. Don't get me wrong. I completely agree with this. I see retransmission as unnecessary for exactly the same reasons. I just wanted to point out that giving up on interoperability is probably going too far. From roman@telurix.com Thu Jul 5 10:35:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C803C21F85AF for ; Thu, 5 Jul 2012 10:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grMvVv+ULppF for ; Thu, 5 Jul 2012 10:35:24 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6F21F85AE for ; Thu, 5 Jul 2012 10:35:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so8521336ghb.31 for ; Thu, 05 Jul 2012 10:35:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=GYBR0s/bHIZI0Hkw3RtdWTTy9g599fS6ZJBOkh2ah3g=; b=SU7DLbKn84vLHUbMiwX9L5se8VjCMS/bC/RH0HKk7d6s4NAOGDdYSUh0laARekQ5p+ nsAoRlq14dYJQdtO+QHcriA0uh5fRpEMD//efEjJIH7EpDurhhFyQaEjQRYvvLP31CEw 1G88pOQ97NmWBkWesfQE4sv0/e+PUHJMarIs9QWLanwA85fheE9x1Eb+OsmWaDtbQxWA vg/5tNpHynKBt6SM7ZWIwdTObUm6ESoS0HpXd/uVBGoZuFGALJTX6Ae7Hd+PeKvvYbWr wSVF2VXllVZHj4KHMds/V0AibOCiUbCO0PvBswc+UKVlB1RZPCmV8C95WLEaHW9UmpWi a6SQ== Received: by 10.236.78.39 with SMTP id f27mr30160472yhe.121.1341509737978; Thu, 05 Jul 2012 10:35:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id f28sm21889936yhk.2.2012.07.05.10.35.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 10:35:37 -0700 (PDT) Received: by yenq13 with SMTP id q13so8495129yen.31 for ; Thu, 05 Jul 2012 10:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.162 with SMTP id d2mr38825327paw.59.1341509734841; Thu, 05 Jul 2012 10:35:34 -0700 (PDT) Received: by 10.68.194.202 with HTTP; Thu, 5 Jul 2012 10:35:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jul 2012 13:35:34 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d042dfd71353bbd04c4189391 X-Gm-Message-State: ALoCoQmpXMV9Y6Hreeu+8eTiy8DvhDTGUsNen8cWl+Sl/1cetLC+5yI+kJpkMuLOUnGFfllc1S7F Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we still need PRANSWER? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 17:35:24 -0000 --f46d042dfd71353bbd04c4189391 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 5, 2012 at 11:50 AM, Martin Thomson wrote: > On 5 July 2012 04:30, Roman Shpount wrote: > > This was all written out of frustration mainly by the direction taken by > > this group on adding things that are not strictly necessary but break > > interoperability. It is completely incomprehensible to me why the group > > decided to add PRANSWER if connection cloning is just as easy to > implement > > and would make, on one hand, interop easier, on another hand add > significant > > new functionality. When I am saying that connection cloning is easy to > > implement I mean that I am willing to build a prototype based on chromium > > code that implements it. Getting the new API through IETF/W3C is above my > > skill level, since I am fairly bad at writing drafts. > > PRANSWER is purely an API construct. How does that affect > interoperability other than making it harder to write the browser code > that achieves it? > PRANSWER is an API construct, but it assumes that only serial proxies are supported. This is an interop issue. _____________ Roman Shpount --f46d042dfd71353bbd04c4189391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 5, 2012 at 11:50 A= M, Martin Thomson <martin.thomson@gmail.com> wrote:
On 5 July 2012 04:30, Roman Shpount <roman@telurix.com> wrote:
> This was all written out of frustration mainly by the direction taken = by
> this group on adding things that are not strictly necessary but break<= br> > interoperability. It is completely incomprehensible to me =A0why the g= roup
> decided to add PRANSWER if connection cloning is just as easy to imple= ment
> and would make, on one hand, interop easier, on another hand add signi= ficant
> new functionality. When I am saying that connection cloning is easy to=
> implement I mean that I am willing to build a prototype based on chrom= ium
> code that implements it. Getting the new API through IETF/W3C is above= my
> skill level, since I am fairly bad at writing drafts.

PRANSWER is purely an API construct. =A0How does that affect
interoperability other than making it harder to write the browser code
that achieves it?

PRANSWER is an API construct, but it assumes that on= ly serial proxies are supported. This is an interop issue.
____________= _
Roman Shpount


--f46d042dfd71353bbd04c4189391-- From christer.holmberg@ericsson.com Thu Jul 5 10:55:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D245321F85C2 for ; Thu, 5 Jul 2012 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.918 X-Spam-Level: X-Spam-Status: No, score=-5.918 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o097wyMFwTG6 for ; Thu, 5 Jul 2012 10:55:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D19A321F86D4 for ; Thu, 5 Jul 2012 10:55:56 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-6c-4ff5d53ab3fe Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.F2.25842.A35D5FF4; Thu, 5 Jul 2012 19:56:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 5 Jul 2012 19:56:10 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Thu, 5 Jul 2012 19:54:35 +0200 Thread-Topic: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used Thread-Index: AQHNWjGlnaxSmEpWZUODzqGn4/YWUZca+hbm Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF4191@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4182@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853405AF4182@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra7V1a/+BrN2iFms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOunmtkLXvFVzP19gL2BsY2ni5GTQ0LAROLf7UssELaYxIV7 69m6GLk4hAROMUp8/dLJDuEsYJT4f/cXcxcjBwebgIVE9z9tkAYRAXWJyw8vsIPYLAIqEsum 7WAEsYUFIiV2rr/LBlETJTF/6zQo20jifPdusGW8AuES5580MIHYQkD2ksmNzCA2p0CExJtV G8BsRqCDvp9aA1bDLCAucevJfCaIQwUkluw5zwxhi0q8fPyPFaJeVOJO+3pGiHodiQW7P7FB 2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhTOTczMSS8310stykwuLs7P 0ytO3cQIjIeDW34b7GDcdF/sEKM0B4uSOK+e6n5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYxlol7RZzmmXtXbfsAjM0rpUmWXJ8fLjIe+3c+b7HrT958vmX/9fdkidgt77rnKwerO59L3 hrWW9+d+WZ7j/TRfaRK3kuwpYbGdVjorDd0jVgpEpKswh99bd6Fg3ZV3i98tydlT/9wl+6u+ muJatTWdUWe3yd0JkpB6ceuB1Re1Ww2lag7XQ5VYijMSDbWYi4oTAb0JdANVAgAA Subject: [rtcweb] FW: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 17:55:58 -0000 FYI, If you're interested in ICE and multiplexing, you may have input and commen= ts on the following issue, which I've sent to the MMUSIC list (please submi= t any input to that list). Regards, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Thursday, July 05, 2012 1:09 AM To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux= is used Hi, A question related to RTP/RTCP multiplexing with BUNDLE. BUNDLE allows the usage of identical port numbers for multiple m- lines. It= also expects a remote endpoint that does not support BUNDLE to send media associ= ated with multiple m- lines to that single port, even if the remote endpoint its= elf will use different ports for each m- line. In addition, the BUNDLE client can also multiplex RTP and RTCP, using the a= =3Drtcp-mux attribute. However, RFC 5761 says that one must be able to receive RTCP on the default= RTCP port, if the remote endpoint does not support a=3Drtcp-mux attribute. But, even if the remote endpoint does not support RTCP/RTP muxing, the ques= tion is whether the local endpoint could still use the same port for RTCP/RTP - and expect = the remote endpoint to send both RTP and RTCP to that single port (even if the remote endpoint = itself uses different ports for RTP and RTCP). In addition to the a=3Drtcp-mux attribute, the loc= al endpoint would use the a=3Drtcp attribute, containing the RTP port value. That would also, when ICE is used, prevent the local endpoint from having t= o reserve RTCP specific candidate ports. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic= From richard.ejzak@alcatel-lucent.com Thu Jul 5 12:42:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2224A21F84F2 for ; Thu, 5 Jul 2012 12:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.648 X-Spam-Level: X-Spam-Status: No, score=-9.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHEphwVb2jUC for ; Thu, 5 Jul 2012 12:42:50 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 56FD711E80AA for ; Thu, 5 Jul 2012 12:42:49 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q65Jh0Dr005580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 5 Jul 2012 21:43:00 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Jul 2012 21:43:00 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.33]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 5 Jul 2012 15:42:57 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] jsep 01 comments Thread-Index: Ac1a5lzIi/mqdqSiSf2H00RgWQKm0w== Date: Thu, 5 Jul 2012 19:42:53 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F177082F7@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F177082F7US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [rtcweb] jsep 01 comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 19:42:59 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F177082F7US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agreed to review jsep 01 during the interim. Please see my comments belo= w against version 01 of the jsep draft. In the paragraph before figure 2 in section 4.2, the text justifies the not= ion of multiple outstanding offers and answers based on RFC 3264. This is = incorrect. RFC 3264 very clearly describes (in section 4) how each offer c= annot be updated until an answer is received and that an answer is final. = This should be made clear in jsep. The actual justifications for multiple = outstanding offers and answers should be made clear and their use within th= e context of RFC 3264 needs to be made clear. Specifically within the cont= ext of SIP, there is no justification or support for multiple offers, and t= he only justification for multiple answers is to provide a limited mechanis= m for dealing with some SIP forking cases. The 2nd paragraph of section 4.5 should make clear that XMPP is an example = application supporting the capability (ICE trickling) and SIP is not. In section 4.7, it should be made clear that SIP forking is being considere= d (with clear references) and any XMPP analogs, if they exist. Obviously s= ection 4.7.2 should indicate cloning as a possible strategy to fully addres= s parallel forking that is not currently supported. The text should descri= be that in the absence of cloning ICE and DTLS may not begin until a "winni= ng" target is selected, thus potentially delaying the start of media flow, = whereas ICE and DTLS could occur in parallel were cloning supported. Section 4.8 needs updating. It is not clear from the description if a new = PeerConnection needs to be established (or how to re-establish the old one)= and how to ensure that the new PeerConnection will be compatible with the = old LocalDescription. I think the description should say that PeerConnecti= on is recreated using the old parameters and (reconstructed?) MediaStreams.= Something is also needed to describe how to ensure the continued availabi= lity of the old MediaStreams. Rehydration will require end-to-end offer/an= swer to recreate the PeerConnection anyway, and I'm not sure of the value o= f attempting to reuse the old LocalDescription since it may not make sense = to force some of the old attributes. Some discussion of how to ensure this= is needed if the concept of reusing the old LocalDescription (and MediaStr= eams) is retained. In section 5.1.1, the first paragraph describes createOffer the first time = it is invoked but not necessarily its behavior for subsequent invocations. = The last sentence of the 2nd paragraph is inconsistent with the last sente= nce of the first paragraph under some circumstances. The local description= used to populate the offer once the session is established, but may come i= n three flavors (noting that an offerer may later become an answerer for th= e same PeerConnection and vice versa): 1) the local description set by the = prior offerer before receiving a final answer (thus reflecting all supporte= d codecs and capabilities according to the constraints); 2) the local descr= iption set by the prior answerer (thus reflecting only the selected codecs = and capabilities); and 3) the local description set by the prior offerer bu= t where createOffer occurs after receiving final answer to the previous off= er (in this case the offer may include codecs and capabilities already rele= ased by the browser). The last paragraph of section 5.1.1 describes that in case 3) the offer sho= uld be modified to reflect the "current state of the system". It's not com= pletely clear if this is intended to describe the current resources allocat= ed to the PeerConnection or the potential resources that could be allocated= (i.e., the full set of available codecs and capabilities). It is similarl= y unclear for case 2) if the offer is to be changed and how. The last sentence of the second paragraph of section 5.1.1 is also inconsis= tent with the last paragraph of the section and it is not clear which one t= akes precedence. This potential inconsistency in the behavior of createOffer is problematic = to an application since the range of capabilities reflected in the SDP is s= tate dependent. The result of createOffer should not depend on whether the= browser was previously offerer or answerer and it should be possible to re= quest either current capabilities or the complete list of potential capabil= ities for each unchanged m line in the offer using the constraints paramete= r. I was asked during the interim to justify the need for a "full" offer as co= mpared to an offer that just reflects the current capabilities. There are = many examples in SIP where a node is sent an "empty re-INVITE" or a "REFER = with REPLACES" during a session to trigger the node to send a new SDP offer= to renegotiate media. This may be triggered due to an interface change, a= network server (e.g., acting as B2BUA) moving the media to another endpoin= t such as a conference server, etc. In all these cases there is no guarant= ee that the new target will support the same codecs or have the same capabi= lities, so the best way forward is to create a "full" offer to make it most= likely that an acceptable media configuration can be achieved in a single = offer/answer transaction. There are other cases where it may be acceptable= to send a "minimal" offer, but only the application can determine which on= e is needed. The 3rd paragraph of 5.1.2 says that createAnswer should also reflect the "= current state" of the system. It is very confusing to use the same words t= o describe createOffer and createAnswer since they should not mean the same= thing. The text should be clarified to distinguish between these two case= s. There is a great need for a new section (possibly a subsection of 4) that d= escribes the relationship between MediaStreams and media lines. An rtcweb = MediaStream is not the same as an RFC 3264 media stream, thus causing endle= ss potential for confusion (I admit to being one of the victims). An RFC 3= 264 media stream is more akin to a MediaStreamTrack, and even that is not c= ompletely accurate since we will allow multiple MediaStreamTracks per m lin= e. How does the browser decide how to allocate MediaStreamTracks to m line= s? The easy solution is to assign each track to a separate m line but this= is wasteful when multiple tracks carry the same media type. But not all t= racks of the same media type should be forced to use the same m line since = it may be necessary to negotiate different capabilities for these tracks. = It must somehow be made clear to the browser which tracks can be combined o= n an m line and which cannot so that it can generate an appropriate offer w= ith the proper number of m lines. In section 5.1.4, it should be pointed out that the need to support both ol= d and new local descriptions means that the PeerConnection must in some sen= se be "cloned" since there may be completely different remote candidates an= d codecs selected for use with the new description and both configurations = need to be simultaneously supported for an interim period. It is also not = explained how to remove the new configuration if the 2nd offer/answer fails= . I do not think that the state diagram supports a transition from offer s= tate or pranswer state back to stable state without processing a valid answ= er. Note this is also another implicit meaning of pranswer that should be = described for subsequent offer/answer transactions - both the old and new c= onfigurations need to be supported until receipt of final answer or failure= is indicated. Sections 5.1.6 and 5.1.7 should clarify the relationship between the local/= remote description and the actual resources allocated. One of them usually= reflects the configured resources while the other is generally a superset.= If this is not the intended semantic, then that should also be clarified. In section 5.2, I believe the RTP header extension attribute in RFC 5285 is= a=3Dextmap rather than a=3Drtphdr-ext. Richard --_000_03FBA798AC24E3498B74F47FD082A92F177082F7US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agreed to review jsep 01 during the interim.  Ple= ase see my comments below against version 01 of the jsep draft.<= /span>

 

In the paragraph before figure 2 in section 4.2, the tex= t justifies the notion of multiple outstanding offers and answers based on = RFC 3264.  This is incorrect.  RFC 3264 very clearly describes (in section 4) how each offer cannot be up= dated until an answer is received and that an answer is final.  This s= hould be made clear in jsep.  The actual justifications for multiple o= utstanding offers and answers should be made clear and their use within the context of RFC 3264 needs to be made clear.=   Specifically within the context of SIP, there is no justification or= support for multiple offers, and the only justification for multiple answe= rs is to provide a limited mechanism for dealing with some SIP forking cases.

 

The 2nd paragraph of section 4.5 should make = clear that XMPP is an example application supporting the capability (ICE tr= ickling) and SIP is not.

 

In section 4.7, it should be made clear that SIP forking= is being considered (with clear references) and any XMPP analogs, if they = exist.  Obviously section 4.7.2 should indicate cloning as a possible strategy to fully address para= llel forking that is not currently supported.  The text should describ= e that in the absence of cloning ICE and DTLS may not begin until a “= winning” target is selected, thus potentially delaying the start of media flow, whereas ICE and DTLS could occur in para= llel were cloning supported.

 

Section 4.8 needs updating.  It is not clear from t= he description if a new PeerConnection needs to be established (or how to r= e-establish the old one) and how to ensure that the new PeerConnection will be compatible with the old Loca= lDescription.  I think the description should say that PeerConnection = is recreated using the old parameters and (reconstructed?) MediaStreams.&nb= sp; Something is also needed to describe how to ensure the continued availability of the old MediaStreams.  Rehydr= ation will require end-to-end offer/answer to recreate the PeerConnection a= nyway, and I’m not sure of the value of attempting to reuse the old L= ocalDescription since it may not make sense to force some of the old attributes.  Some discussion of how to ensur= e this is needed if the concept of reusing the old LocalDescription (and Me= diaStreams) is retained.

 

In section 5.1.1, the first paragraph describes createOf= fer the first time it is invoked but not necessarily its behavior for subse= quent invocations.  The last sentence of the 2nd paragraph is inconsistent with the last sen= tence of the first paragraph under some circumstances.  The local desc= ription used to populate the offer once the session is established, but may= come in three flavors (noting that an offerer may later become an answerer for the same PeerConnection and vice = versa): 1) the local description set by the prior offerer before receiving = a final answer (thus reflecting all supported codecs and capabilities accor= ding to the constraints); 2) the local description set by the prior answerer (thus reflecting only the sele= cted codecs and capabilities); and 3) the local description set by the prio= r offerer but where createOffer occurs after receiving final answer to the = previous offer (in this case the offer may include codecs and capabilities already released by the browser)= .

 

The last paragraph of section 5.1.1 describes that in ca= se 3) the offer should be modified to reflect the “current state of t= he system”.  It’s not completely clear if this is intended to describe the current resources allocated to t= he PeerConnection or the potential resources that could be allocated (i.e.,= the full set of available codecs and capabilities).  It is similarly = unclear for case 2) if the offer is to be changed and how.

 

The last sentence of the second paragraph of section 5.1= .1 is also inconsistent with the last paragraph of the section and it is no= t clear which one takes precedence.

 

This potential inconsistency in the behavior of createOf= fer is problematic to an application since the range of capabilities reflec= ted in the SDP is state dependent.  The result of createOffer should not depend on whether the browser w= as previously offerer or answerer and it should be possible to request eith= er current capabilities or the complete list of potential capabilities for = each unchanged m line in the offer using the constraints parameter.

 

I was asked during the interim to justify the need for a= “full” offer as compared to an offer that just reflects the cu= rrent capabilities.  There are many examples in SIP where a node is sent an “empty re-INVITE” or a “R= EFER with REPLACES” during a session to trigger the node to send a ne= w SDP offer to renegotiate media.  This may be triggered due to an int= erface change, a network server (e.g., acting as B2BUA) moving the media to another endpoint such as a conference server, etc.  In a= ll these cases there is no guarantee that the new target will support the s= ame codecs or have the same capabilities, so the best way forward is to cre= ate a “full” offer to make it most likely that an acceptable media configuration can be achieved in a single offer/a= nswer transaction.  There are other cases where it may be acceptable t= o send a “minimal” offer, but only the application can determin= e which one is needed.

 

The 3rd paragraph of 5.1.2 says that createAn= swer should also reflect the “current state” of the system. &nb= sp;It is very confusing to use the same words to describe createOffer and createAnswer since they should not mean the sa= me thing.  The text should be clarified to distinguish between these t= wo cases.

 

There is a great need for a new section (possibly a subs= ection of 4) that describes the relationship between MediaStreams and media= lines.  An rtcweb MediaStream is not the same as an RFC 3264 media stream, thus causing endless potentia= l for confusion (I admit to being one of the victims).  An RFC 3264 me= dia stream is more akin to a MediaStreamTrack, and even that is not complet= ely accurate since we will allow multiple MediaStreamTracks per m line.  How does the browser decide how to all= ocate MediaStreamTracks to m lines?  The easy solution is to assign ea= ch track to a separate m line but this is wasteful when multiple tracks car= ry the same media type.  But not all tracks of the same media type should be forced to use the same m line since it ma= y be necessary to negotiate different capabilities for these tracks.  = It must somehow be made clear to the browser which tracks can be combined o= n an m line and which cannot so that it can generate an appropriate offer with the proper number of m lines.

 

In section 5.1.4, it should be pointed out that the need= to support both old and new local descriptions means that the PeerConnecti= on must in some sense be “cloned” since there may be completely different remote candidates and codecs selec= ted for use with the new description and both configurations need to be sim= ultaneously supported for an interim period.  It is also not explained= how to remove the new configuration if the 2nd offer/answer fails.  I do not think that the st= ate diagram supports a transition from offer state or pranswer state back t= o stable state without processing a valid answer.  Note this is also a= nother implicit meaning of pranswer that should be described for subsequent offer/answer transactions – both the old= and new configurations need to be supported until receipt of final answer = or failure is indicated.

 

Sections 5.1.6 and 5.1.7 should clarify the relationship= between the local/remote description and the actual resources allocated. &= nbsp;One of them usually reflects the configured resources while the other is generally a superset.  If= this is not the intended semantic, then that should also be clarified.

 

In section 5.2, I believe the RTP header extension attri= bute in RFC 5285 is a=3Dextmap rather than a=3Drtphdr-ext.=

 

Richard

--_000_03FBA798AC24E3498B74F47FD082A92F177082F7US70UWXCHMBA04z_-- From fluffy@iii.ca Thu Jul 5 14:16:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C421321F856F for ; Thu, 5 Jul 2012 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2SvWfZ-JNpL for ; Thu, 5 Jul 2012 14:16:00 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1591F21F8566 for ; Thu, 5 Jul 2012 14:15:59 -0700 (PDT) Received: from sjc-vpn5-1539.cisco.com (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 B2F6922E25D; Thu, 5 Jul 2012 17:16:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 5 Jul 2012 14:16:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <047E39EB-F92F-44EA-B44F-03ADE49E0BEC@iii.ca> References: <4FD6D566.6060806@alvestrand.no> <4FD7A356.2010406@ericsson.com> <4FD83C21.4080701@alvestrand.no> <4FD85D78.1040103@jesup.org> <929BD935-0E8F-4985-9E51-9E213B0C6841@cisco.com> <4FE4A6B2.7020601@alvestrand.no> <8F1A4041-E7E8-49D4-A77B-EDFF1F5A617C@cisco.com> <4FEEF614.6090507@jesup.org> To: Justin Uberti X-Mailer: Apple Mail (2.1278) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Target numbers for setup time (Re: Keeping up data channel) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 21:16:00 -0000 I think we are talking about different numbers here. I am concerned with = the time from when the UI indicates you can start talking, to the time = that you can start talking with a reasonable expectation that the other = side will hear it.=20 On Jul 2, 2012, at 13:00 , Justin Uberti wrote: > We can certainly make the API allow instant creation of a data = channel, but the thing I'm bringing up is the , which is currently the long pole in establishing a p2p flow. = That's where 6 RTTs are coming from. >=20 > Agree with Harald that this is an IETF matter though. >=20 >=20 > On Sat, Jun 30, 2012 at 5:50 AM, Randell Jesup = wrote: > On 6/28/2012 3:49 PM, Cullen Jennings (fluffy) wrote: > Agree - that's why I think this has to be done in zero RTT. I don't = see any problem with setting up a data channel and being ready to send = media before having the UI tell the user they are "connected and can = start talking". >=20 > I agree, and have suggested this as well, but it's really in the = application domain (though we can give examples that use it and = recommend it). There are some mild security concerns with accepting the = data-only connection before user decision, but manageable I believe. >=20 > Roughly: call start (user) > caller-> Offer(SDP(data-only)) as "setup" -> server -> answerer > (also indicate if it's audio-only or audio+video) > (maybe offer data+audio (and video) to warm up ICE = candidates) > answerer -> Answer (SDP(data-only)) as "setup" -> server -> = answerer > answerer -> alert user > caller-> install Answer > > caller-> Offer(SDP(data+media)) as "call" -> answerer (over = "negotiation" channel) > ... > answerer (user) accepts > answerer-> Answer(SDP(data+media)) as "call" -> caller (over = "negotiation" channel) > answerer starts sending > caller installs Answer > caller media starts sending >=20 > =46rom user accepts -> media starts, it's 0 RTT for answer sending, 1 = RTT until he sees media from the caller, which is pretty much close to = theoretical minimum. (You can do better only by starting media channels = "in the background" from the caller before user accepts, perhaps with an = Answer(SDP(data+receive-only-media)).) >=20 > Again, I believe this is all possible in the application domain today = with the spec. >=20 >=20 > Reducing from 7 RTT to 5 RTT does not help when you need to get to 0 = RTT. >=20 > On Jun 22, 2012, at 10:09 , Harald Alvestrand wrote: >=20 > On 06/22/2012 05:58 PM, Cullen Jennings (fluffy) wrote: > On Jun 13, 2012, at 5:29 , Randell Jesup wrote: >=20 > How far down do you think we have to drive the setup time before you > would not call it "abysmal"? > I'd probably consider above 250 ms abysmal but good news I don't see = any problem with getting it down around 100 ms in when both endpoints = are in a single country. >=20 > Coast-to-coast US is ~4800 km, so RTT (9600 km) is 32 ms (speed of = light is 300 km/msec). >=20 > So, without considering processing time, 3 RTT is 100 msec, 7 RTT is = "abysmal". >=20 > There are bigger countries than the US, but this will do for a = back-of-the-envelope. >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > 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 martin.thomson@gmail.com Thu Jul 5 14:49:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCC11E80B3 for ; Thu, 5 Jul 2012 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ftd6BsIsCRga for ; Thu, 5 Jul 2012 14:49:58 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADBE211E80AA for ; Thu, 5 Jul 2012 14:49:57 -0700 (PDT) Received: by bkty7 with SMTP id y7so848771bkt.31 for ; Thu, 05 Jul 2012 14:50:11 -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=AH0/RErQ4PeIqzCV0bmMAEEBraSmjxAzNCyPIjTcGoM=; b=mybuMhozBmJkKUZrtGA0pyLiVS+Fa2feYQ9XnBUeXXBf9GxetzYvU452KJHZfx4hwl HRbT1+dPlcREQlqAEqHGB5SSq4Nxr7AiGAxPKARlAUg8CAaAKxlywWfaih+FJVmvW+HL 3W3azs4z+9Cq6bnh856ALmTEFqUTk0eTxXFvlEI0M5JGn+gd5BJ1yVRmHpeVwVgPeBOS 613m0fhZjK2ixqsh9n4iTi+OIPTyJSLsKLErxiu5AcsG3nTG23ZSchkJXpPstu4jpen9 R6YJ7Z78mmnscxnUVSySXtLxAmsgGvWP7VPQad6L8VMEIs8ZS/xYdfyIZ9IAH+Vk5Pvv vt5Q== MIME-Version: 1.0 Received: by 10.204.152.206 with SMTP id h14mr10727222bkw.36.1341525011492; Thu, 05 Jul 2012 14:50:11 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 5 Jul 2012 14:50:11 -0700 (PDT) In-Reply-To: <047E39EB-F92F-44EA-B44F-03ADE49E0BEC@iii.ca> References: <4FD6D566.6060806@alvestrand.no> <4FD7A356.2010406@ericsson.com> <4FD83C21.4080701@alvestrand.no> <4FD85D78.1040103@jesup.org> <929BD935-0E8F-4985-9E51-9E213B0C6841@cisco.com> <4FE4A6B2.7020601@alvestrand.no> <8F1A4041-E7E8-49D4-A77B-EDFF1F5A617C@cisco.com> <4FEEF614.6090507@jesup.org> <047E39EB-F92F-44EA-B44F-03ADE49E0BEC@iii.ca> Date: Thu, 5 Jul 2012 14:50:11 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Target numbers for setup time (Re: Keeping up data channel) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 21:49:58 -0000 On 5 July 2012 14:16, Cullen Jennings wrote: > I think we are talking about different numbers here. I am concerned with the time from when the UI indicates you can start talking, to the time that you can start talking with a reasonable expectation that the other side will hear it. You assume an application that performs user alerting and requires user acceptance prior to establishing media. That is certainly an important use case, but not the only one. In some other use cases the signaling must occur after the user hits a button. --Martin From rmohanr@cisco.com Thu Jul 5 22:29:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49C821F8717 for ; Thu, 5 Jul 2012 22:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+VozpdkiwLw for ; Thu, 5 Jul 2012 22:29:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 118EB21F8710 for ; Thu, 5 Jul 2012 22:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2862; q=dns/txt; s=iport; t=1341552600; x=1342762200; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=q5ZxUzAbfdj+V6HlLPQ6D+8cJ8Y9dHFgykYLmn+syNE=; b=W3gn0GXELkkSpOMnX6KdFbGVC3I6/TKZ8eyVk5CtSnI7ILlb5O1bjdda pcl8927CdxB0xb25sk6MO9/iEkC5lrsEMi8KBUL0zsvKGUc37Ja1y56SC 47jCwOv4a7jb3k0LmDmY9S0ksmdchEfMVfAxQv60axsqu9vVz25Q9ej1e s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMl29k+tJV2b/2dsb2JhbABFtzaBB4IYAQEBAwEBAQEJBgFbEAcCBAEIEQQBASgiDAsUCQgCBAESIodkBQuaA6ARBASLNYYmA4gXjSCOHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,536,1336348800"; d="scan'208";a="99245590" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jul 2012 05:30:00 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q665Txci014642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jul 2012 05:29:59 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Fri, 6 Jul 2012 00:29:59 -0500 From: "Ram Mohan R (rmohanr)" To: "Muthu Arul Mozhi Perumal (mperumal)" , "Magnus Westerlund" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Where to specify ICE usage and the common transport Thread-Index: AQHNWzhiljMNav0oCE68YPvDkhXEpw== Date: Fri, 6 Jul 2012 05:29:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.68.31] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19022.003 x-tm-as-result: No--43.322000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9F649EEDBD6B7C4788B1FB8B2843F112@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 05:29:47 -0000 > On 04/07/12 1:06 PM, "Muthu Arul Mozhi Perumal (mperumal)" > wrote: >|- Is specifying this in its own specification the most suitable >|approach > >Yes, IMO. I think it would ensue we get enough focus on this key >component. > >|- Do we have any volunteers for writing such a specification? > >Please count me in. I think it makes sense to merge the consent freshness >specification (draft-muthu-behave-consent-freshness) with the ICE usage >for WebRTC. Please count me also in. As one of the authors of consent draft even I would also be interested in seeing a specification on ICE usage for webRTC. Regards, Ram > >Muthu > >|-----Original Message----- >|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Magnus Westerlund >|Sent: Wednesday, July 04, 2012 12:31 PM >|To: rtcweb@ietf.org >|Subject: [rtcweb] Where to specify ICE usage and the common transport >| >|WG, >| >|We chairs have identified that we currently we are missing specification >|text for one of the key components of RTCWEB. This component is how >|WebRTC uses ICE and defines the datagram transport that both the >|DTLS/SCTP data channel uses and the RTP session. >| >|Such a specification would most likely contain the following: >| >|- How ICE is used in the WebRTC context >|- Inclusion of STUN, TURN, TURN-TCP >|- Inclusion of any defined "HTTP fallback" >|- Description of the data transport in general and specifically how one >| can separate the traffic from the data channel and RTP session. >|- Requirements on the signalling and API and what configuration data is >| needed. >| >|My personal view is that this is best served by having its own >|specification. Alternatives that exist is to include it either in the >|data channel or RTP usage specifications. >| >|Thus we chairs would appreciate feedback on at least two things: >| >|- Is specifying this in its own specification the most suitable approach >| >|- Do we have any volunteers for writing such a specification? >| >|Cheers >| >|Magnus Westerlund >| >|---------------------------------------------------------------------- >|Multimedia Technologies, Ericsson Research EAB/TVM >|---------------------------------------------------------------------- >|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 >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From eric.sun@huawei.com Thu Jul 5 23:25:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B316211E8099 for ; Thu, 5 Jul 2012 23:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=4.425, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXFC4ENSBmCu for ; Thu, 5 Jul 2012 23:25:30 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A479921F876F for ; Thu, 5 Jul 2012 23:25:30 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHT32240; Fri, 06 Jul 2012 02:25:46 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Jul 2012 23:25:35 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Jul 2012 23:25:41 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 14:25:35 +0800 From: "Sunyang (Eric)" To: "Ram Mohan R (rmohanr)" , "Muthu Arul Mozhi Perumal (mperumal)" , "Magnus Westerlund" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Where to specify ICE usage and the common transport Thread-Index: AQHNWbMYfiXDSKZycE6CWrtqMEGF4JcYNfWAgAMBTYCAAJUvQA== Date: Fri, 6 Jul 2012 06:25:35 +0000 Message-ID: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] =?utf-8?b?562U5aSNOiAgV2hlcmUgdG8gc3BlY2lmeSBJQ0UgdXNh?= =?utf-8?q?ge_and_the_common_transport?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 06:25:31 -0000 RG8gd2UgcmVhbGx5IG5lZWQgdGhpcz8NCklmIHdlIHN0YXJ0IGEgbmV3IHNwZWNpZmljYXRpb24g YWJvdXQgSUNFLCBkbyB3ZSBuZWVkIGludGVncmF0ZSB0aGUgZmluYWwgcGFydCBvZiBJQ0Ugc3Bl Y2lmaWNhdGlvbiB3aXRoIEpTRVAsIHRoaXMgd2lsbCBuZWVkIGV4dHJhIHdvcmsgdG8gbWFrZSB0 aGVtIG1lZXQuDQoNCllhbmcNCkh1YXdlaQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hk u7bkuro6IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqCBSYW0gTW9oYW4gUiAocm1vaGFucikNCuWPkemAgeaXtumXtDogMjAxMuW5 tDfmnIg25pelIDEzOjMwDQrmlLbku7bkuro6IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBl cnVtYWwpOyBNYWdudXMgV2VzdGVybHVuZDsgcnRjd2ViQGlldGYub3JnDQrkuLvpopg6IFJlOiBb cnRjd2ViXSBXaGVyZSB0byBzcGVjaWZ5IElDRSB1c2FnZSBhbmQgdGhlIGNvbW1vbiB0cmFuc3Bv cnQNCg0KPiBPbiAwNC8wNy8xMiAxOjA2IFBNLCAiTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsICht cGVydW1hbCkiDQo+PG1wZXJ1bWFsQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj58LSBJcyBzcGVjaWZ5 aW5nIHRoaXMgaW4gaXRzIG93biBzcGVjaWZpY2F0aW9uIHRoZSBtb3N0IHN1aXRhYmxlDQo+fGFw cHJvYWNoDQo+DQo+WWVzLCBJTU8uIEkgdGhpbmsgaXQgd291bGQgZW5zdWUgd2UgZ2V0IGVub3Vn aCBmb2N1cyBvbiB0aGlzIGtleQ0KPmNvbXBvbmVudC4NCj4NCj58LSBEbyB3ZSBoYXZlIGFueSB2 b2x1bnRlZXJzIGZvciB3cml0aW5nIHN1Y2ggYSBzcGVjaWZpY2F0aW9uPw0KPg0KPlBsZWFzZSBj b3VudCBtZSBpbi4gSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBtZXJnZSB0aGUgY29uc2VudCBm cmVzaG5lc3MNCj5zcGVjaWZpY2F0aW9uIChkcmFmdC1tdXRodS1iZWhhdmUtY29uc2VudC1mcmVz aG5lc3MpIHdpdGggdGhlIElDRSB1c2FnZQ0KPmZvciBXZWJSVEMuDQoNCg0KUGxlYXNlIGNvdW50 IG1lIGFsc28gaW4uIEFzIG9uZSBvZiB0aGUgYXV0aG9ycyBvZiBjb25zZW50IGRyYWZ0IGV2ZW4g SQ0Kd291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIGluIHNlZWluZyBhIHNwZWNpZmljYXRpb24gb24g SUNFIHVzYWdlIGZvciB3ZWJSVEMuDQoNClJlZ2FyZHMsDQpSYW0NCg0KDQo+DQo+TXV0aHUNCj4N Cj58LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj58RnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgTWFn bnVzIFdlc3Rlcmx1bmQNCj58U2VudDogV2VkbmVzZGF5LCBKdWx5IDA0LCAyMDEyIDEyOjMxIFBN DQo+fFRvOiBydGN3ZWJAaWV0Zi5vcmcNCj58U3ViamVjdDogW3J0Y3dlYl0gV2hlcmUgdG8gc3Bl Y2lmeSBJQ0UgdXNhZ2UgYW5kIHRoZSBjb21tb24gdHJhbnNwb3J0DQo+fA0KPnxXRywNCj58DQo+ fFdlIGNoYWlycyBoYXZlIGlkZW50aWZpZWQgdGhhdCB3ZSBjdXJyZW50bHkgd2UgYXJlIG1pc3Np bmcgc3BlY2lmaWNhdGlvbg0KPnx0ZXh0IGZvciBvbmUgb2YgdGhlIGtleSBjb21wb25lbnRzIG9m IFJUQ1dFQi4gVGhpcyBjb21wb25lbnQgaXMgaG93DQo+fFdlYlJUQyB1c2VzIElDRSBhbmQgZGVm aW5lcyB0aGUgZGF0YWdyYW0gdHJhbnNwb3J0IHRoYXQgYm90aCB0aGUNCj58RFRMUy9TQ1RQIGRh dGEgY2hhbm5lbCB1c2VzIGFuZCB0aGUgUlRQIHNlc3Npb24uDQo+fA0KPnxTdWNoIGEgc3BlY2lm aWNhdGlvbiB3b3VsZCBtb3N0IGxpa2VseSBjb250YWluIHRoZSBmb2xsb3dpbmc6DQo+fA0KPnwt IEhvdyBJQ0UgaXMgdXNlZCBpbiB0aGUgV2ViUlRDIGNvbnRleHQNCj58LSBJbmNsdXNpb24gb2Yg U1RVTiwgVFVSTiwgVFVSTi1UQ1ANCj58LSBJbmNsdXNpb24gb2YgYW55IGRlZmluZWQgIkhUVFAg ZmFsbGJhY2siDQo+fC0gRGVzY3JpcHRpb24gb2YgdGhlIGRhdGEgdHJhbnNwb3J0IGluIGdlbmVy YWwgYW5kIHNwZWNpZmljYWxseSBob3cgb25lDQo+fCAgY2FuIHNlcGFyYXRlIHRoZSB0cmFmZmlj IGZyb20gdGhlIGRhdGEgY2hhbm5lbCBhbmQgUlRQIHNlc3Npb24uDQo+fC0gUmVxdWlyZW1lbnRz IG9uIHRoZSBzaWduYWxsaW5nIGFuZCBBUEkgYW5kIHdoYXQgY29uZmlndXJhdGlvbiBkYXRhIGlz DQo+fCAgbmVlZGVkLg0KPnwNCj58TXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IHRoaXMgaXMgYmVz dCBzZXJ2ZWQgYnkgaGF2aW5nIGl0cyBvd24NCj58c3BlY2lmaWNhdGlvbi4gQWx0ZXJuYXRpdmVz IHRoYXQgZXhpc3QgaXMgdG8gaW5jbHVkZSBpdCBlaXRoZXIgaW4gdGhlDQo+fGRhdGEgY2hhbm5l bCBvciBSVFAgdXNhZ2Ugc3BlY2lmaWNhdGlvbnMuDQo+fA0KPnxUaHVzIHdlIGNoYWlycyB3b3Vs ZCBhcHByZWNpYXRlIGZlZWRiYWNrIG9uIGF0IGxlYXN0IHR3byB0aGluZ3M6DQo+fA0KPnwtIElz IHNwZWNpZnlpbmcgdGhpcyBpbiBpdHMgb3duIHNwZWNpZmljYXRpb24gdGhlIG1vc3Qgc3VpdGFi bGUgYXBwcm9hY2gNCj58DQo+fC0gRG8gd2UgaGF2ZSBhbnkgdm9sdW50ZWVycyBmb3Igd3JpdGlu ZyBzdWNoIGEgc3BlY2lmaWNhdGlvbj8NCj58DQo+fENoZWVycw0KPnwNCj58TWFnbnVzIFdlc3Rl cmx1bmQNCj58DQo+fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj58TXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVy aWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCj58LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPnxFcmljc3NvbiBBQiAg ICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPnxGw6Ryw7ZnYXRhbiA2ICAg ICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+fFNFLTE2NCA4MCBTdG9ja2hv bG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj58LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPnwNCj58DQo+fF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+fHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj58cnRjd2ViQGlldGYub3JnDQo+ fGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5ydGN3ZWIgbWFpbGluZyBs aXN0DQo+cnRjd2ViQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCj4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From stefan.lk.hakansson@ericsson.com Fri Jul 6 00:08:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CEF21F8622 for ; Fri, 6 Jul 2012 00:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoPjA+fMviAt for ; Fri, 6 Jul 2012 00:08:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F085321F86AA for ; Fri, 6 Jul 2012 00:08:48 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-58-4ff68f0fb20f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.90.25842.F0F86FF4; Fri, 6 Jul 2012 09:09:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 09:09:02 +0200 Message-ID: <4FF68F0B.6090905@ericsson.com> Date: Fri, 6 Jul 2012 09:08:59 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <4FF217DD.1060607@jesup.org> <4FF451C7.5080804@ericsson.com> <4FF521DF.1090202@jesup.org> In-Reply-To: <4FF521DF.1090202@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+JvrS5//zd/g3ULVSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsV9PxkL+tQqJuxez9TAeE6ui5GTQ0LAROLcv5vsELaYxIV7 69m6GLk4hAROMUpcu7GYFSQhJLCMUeLJfCkQm1dAW2JNUw9YnEVAReLd1RtMIDabgI3E2u4p QDYHh6hAmMT0newQ5YISJ2c+YQGxRQSEJba+6gUrERbwk5jfEAZiCgn8YJKYVgxSwSmgKbH7 6zQ2EJtZwFbiwpzrLBC2vMT2t3OYIY7RlXj3+h7rBEaBWUgWzELSMgtJywJG5lWMwrmJmTnp 5eZ6qUWZycXF+Xl6xambGIGBd3DLb4MdjJvuix1ilOZgURLn1VPd7y8kkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBUe7rz/1yLydZ335sWLpPf0+4sNRdxcW/V67n0n/wUKPw0smpk+bwNG5V 5fuRZpz0+G/YsUweiyffF/Kkdj0pNuucFbdp9dTUOz4Ch5UtGVjzfupdO7Thei/H7Flz07UO Lkk6JMmZsn+Gez6vhYBzkbPrfjdP2Qv7lwkEzPuRUzbR/ka74vYXVUosxRmJhlrMRcWJAPx3 cOgKAgAA Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:08:50 -0000 On 07/05/2012 07:10 AM, Randell Jesup wrote: > On 7/4/2012 10:23 AM, Stefan Hakansson LK wrote: >> On 07/02/2012 11:51 PM, Randell Jesup wrote: >>> >>>> Again, this is about making _support_ for retransmission a requirement, >>>> not _use_. >>> >>> >>> If you don't mandate use, what does mandating "support" buy you? An >>> implementation (see above about PSTN gateways) might always decline to >>> use retransmission, so what does MUST (REQUIRE) buy you? I say SHOULD >>> (RECOMMEND), with a statement that it's strongly recommended it be >>> supported if video is supported, especially for non-single-purpose >>> devices (i.e. browsers). >>> >>> In either case, you need to think about who decides to use re-xmit or >>> not, what influences that, and if the app has visibility into this. >>> Someone could as an rtx-time=0 to the SDP. Or not include one, but >>> never actually retransmit a packet regardless of NACKs - it could just >>> repair via IDR (or other means). >>> >>> So here's a real problem related to retransmission: since the request is >>> not specific and negotiated (it's normally a generic NACK), the receiver >>> who sent the NACK has no idea if it will get a retransmission, an IDR >>> (or IDR slice), another form of repair (pframe/slice against >>> known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, it >>> doesn't know if it should freeze the video or play with errors. It has >>> to decide if it *thinks* the sender will use retransmission, or if it >>> doesn't, does the receiver want to freeze video until an IDR or other >>> repair is done, which might be a while. >> >> Isn't retransmission negotiated using "rtx", "atp" and so on? > > Support for it is. However, negotiating support for it doesn't solve > the problem of not knowing how the sender will respond to a NACK (or > SLI/RPSI/etc). Generally, the sender has to make the decision, but the > receiver has to guess. > >> >> One way of removing the uncertainty would be to require that all >> browsers support RTP retransmission: This way, any RTP endpoint >> sending a NACK to a browser would know that that packet would be >> retransmitted (given that congestion does not prohibit, or NACK packet >> is lost etc.). > > Um, no. Just because both sides support retransmission does not mean > that a NACK will generate a retransmission. Retransmission only makes > sense in some instances, and there's no guarantee that retransmission > will be possible (for example, the requested packet might have timed out > and been thrown away). All I was trying to say was that mandating support for retransmission would remove one uncertainty. But I agree that there are situations when there still would be no retransmission (and the receiver would not know why). But I guess you're also saying that mandating it would not be helpful since the sender decides, and could in principle have support for retransmission, but being set up/implemented/tuned in such a way that it (almost) never retransmits. I didn't think about that; and I don't know how big that risk is. > >> >> If we have this in place, I'm confident that implementors will quickly >> develop strategies on how and when to _use_ retransmission in the best >> way. There has already been input made on its usefulness. > > Sure, and they will anyways. RECOMMENDED or REQUIRED, it really doesn't > matter to the implementation. For that matter, even if REQUIRED there's > nothing that says it has to be offered or accepted. Even if that were > mandated, the implementation could accept but with a 0-length rtx-time. > So it's really unclear what REQUIRED buys you that RECOMMENDED doesn't. > >> >> Maybe the problem with legacy not always supporting retransmission is >> not that big. First of all, legacy is to a large extent audio only >> (e.g. PSTN), and no one is arguing for retransmission there. Secondly, >> I fail to see that this situation would be improved in any way if >> browsers are only recommended (and not required) to support RTP >> retransmission. >> >> So I think we should require rtcweb capable browsers to support RTP >> retransmission. >> >>> >>> We also need to think about when a receiver should use SLI or RPSI. PLI >>> can also be used and should be if the other options don't negotiate (so >>> it's important to offer it). Certainly it's more work to keep track of >>> the contents of each packet (slices, etc), especially in things like >>> H.264 NALU aggregation packets, than it is to just respond to an SLI. >>> >>> That said, my previous systems just used NACK and let the sender decide >>> the correct repair, but I wasn't leveraging slices and wasn't using >>> retransmission, so there was only minor complexity (looking at possible >>> reference frames). > > From stefan.lk.hakansson@ericsson.com Fri Jul 6 00:16:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CFC21F86F1 for ; Fri, 6 Jul 2012 00:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY+nauUCgt+D for ; Fri, 6 Jul 2012 00:16:04 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0321F86EB for ; Fri, 6 Jul 2012 00:16:04 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-c4-4ff690c378a4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 85.10.23986.3C096FF4; Fri, 6 Jul 2012 09:16:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 09:16:18 +0200 Message-ID: <4FF690BE.5090101@ericsson.com> Date: Fri, 6 Jul 2012 09:16:14 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <4FEAFFBA.8020403@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF03603B@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF03603B@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VvfwhG/+BpOeCVic7etit1j7r53d gcljyZKfTB43br9nDmCK4rJJSc3JLEst0rdL4Mq41n6CraBdtOJIz1HGBsa/Al2MnBwSAiYS b09MYYGwxSQu3FvP1sXIxSEkcIpRovnVfSYIZxmjxM6Gp8wgVbwC2hJdT16ydzFycLAIqEhs +JsFEmYTsJFY2z2FCSQsKhAmMX0nO0S1oMTJmU/A5osIWEt8mN8CNoVZQF3izuJzYDXCAjoS O84tZwSxhQRyJNYsv8oGYnMK+ErMWryWDaLeVuLCnOssELa8xPa3c5gh6nUl3r2+xzqBUXAW knWzkLTMQtKygJF5FaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYKAe3PJbdQfjnXMihxilOViU xHmtt+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDYl37z6Ebf2kPNHEePtqwUT0ve62TL fKD1T+7yg642P4tD8pewn2nSNr1T99CqYzb7jMr071xCFpE+ZbPDN70tzl3aPPExy63V6TMi ch+4xPUuytj37sZJk53G3p3tjQejfTZfaYs5kz1v+c5er0OtLPNrq78skHJrzbJlmKNkma99 MGnWHxYlluKMREMt5qLiRAD+1xyeIgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case draft updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:16:05 -0000 On 07/04/2012 07:06 PM, Hutton, Andrew wrote: > Hi Stefan, > > I am not sure what the consensus was regarding the changing of the > wording from "eavesdropping" to "wiretapping" but after discussion > with a few people at the interim my thinking was that it would be > best to remove the statements from each use case regarding > eavesdropping and replace it with bullets in section 4.1 for > considerations which apply to all use cases. These should state that > all media streams and data channels must be integrity and > confidentiality protected. Hi Andrew! I got the feeling that people disliked "eavesdropping", so I replaced it. I may have made a mistake and I would be glad to change again. Regarding moving this to section 4.1, I did consider that, but 4.1 right now deals exclusively with network specific capabilities, and I felt a requirement on wiretapping/eavesdropping would not fit that well there. Again, I would be happy to change. > > I stated this in the following mail > http://www.ietf.org/mail-archive/web/rtcweb/current/msg04595.html. Yes, I noted that mail. > > It might be best to check with the chairs and/or AD's what is the > best and acceptable wording given the RAVEN policy in RFC2804. Chairs, any input? > > Regards Andy > > > > > >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >> Sent: 27 June 2012 13:43 To: rtcweb@ietf.org Subject: [rtcweb] >> Use-case draft updated >> >> Hi, >> >> as already automatically announced, the use-case draft has been >> updated. Extract from the change log: >> >> * Changed "eavesdropping" to "wiretapping" and referenced RFC2804. >> >> * Removed informal ref webrtc_req; that document has been abandoned >> by the W3C webrtc WG. >> >> * Added use-case where one user is behind a FW that only allows >> http; derived req. F37. >> >> * Changed F24 slightly; MUST-> SHOULD, inserted "available". >> >> * Added a clause to "Simple video communication service" saying >> that the service provider monitors the quality of service, and >> derived reqs F38 and A26. >> >> Most of the above are things that was documented in the minutes of >> the Interim June 12th; I took the liberty to add some text (and >> reqs A26/F38) on the service provider monitoring the QoE. >> >> Feedback and comments are most welcome. >> >> Also, Ekr has the task to deliver an Identity related use-case (as >> discussed at the interim). >> >> Stefan _______________________________________________ rtcweb >> mailing list rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Fri Jul 6 00:29:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B122B21F8661 for ; Fri, 6 Jul 2012 00:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.988 X-Spam-Level: X-Spam-Status: No, score=-105.988 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng9jzGoQzSGw for ; Fri, 6 Jul 2012 00:29:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9781D21F865D for ; Fri, 6 Jul 2012 00:29:36 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-0c-4ff693efe282 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 25.12.23986.FE396FF4; Fri, 6 Jul 2012 09:29:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 09:29:50 +0200 Message-ID: <4FF693EE.8030905@ericsson.com> Date: Fri, 6 Jul 2012 09:29:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Sunyang (Eric)" References: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> In-Reply-To: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvre77yd/8DZ4tVLN48vgHu8WdT3NY LZZ37WC0WPuvnd2BxWPK742sHi1H3rJ6LFnykymAOYrLJiU1J7MstUjfLoEr4+iidSwFh0Uq vjccYG9gPCnQxcjJISFgIrHqzhkWCFtM4sK99WwgtpDAKUaJyR95uhi5gOxljBJvL04BS/AK aEvc3vWGGcRmEVCR6Nu4nxXEZhOwkLj5oxGsRlQgWGLa9HvsEPWCEidnPgFbICKgJXHmyFxW kKHMAlMZJZq/v2YESQgLtDBK/JtuDLFtJ6PEknUdYB2cAmESmzvXsEGcJylxr301mM0soCnR uv03O4QtL9G8dTYzxNnaEg1NHawTGIVmIVk+C0nLLCQtCxiZVzEK5yZm5qSXG+mlFmUmFxfn 5+kVp25iBAb5wS2/VXcw3jkncohRmoNFSZzXeusefyGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2M0/ra1uYeYhNfI73NIUlNefULxjd89z1a2pQTd9bfCNqToFI6p2//nNIGqT0bHBviGxzl Uiz4Iqe1sjXzpynGxx7sfhBQutjTVaGON+Hx7rNdZSf+/tMxOfnf/pXeHrF+/pXW0Y4+/e8W +H2fYtTL8zIsN+uEzLa5jLkRoaoH2lcsqAiZyaDEUpyRaKjFXFScCAAxljDCQAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiAgV2hlcmUgdG8gc3BlY2lmeSBJQ0UgdXNh?= =?utf-8?q?ge_and_the_common_transport?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:29:37 -0000 On 2012-07-06 08:25, Sunyang (Eric) wrote: > Do we really need this? That is part of what I am trying to determine. > If we start a new specification about ICE, do > we need integrate the final part of ICE specification with JSEP, this > will need extra work to make them meet. My personal understanding of the relations are the following The basic functionality is to establish functional datagram transport flow or flows (depending on signalling) between WebRTC peers. The established datagram transport flow is used by the RTP session(s), DTLS-SRTP key-management establishment and SCTP over DTLS. The last part points to that we have 2 or 3 (depending on how you see DTLS-SRTP) users of the datagram transport flow. As co-author of one of those documents I would like to have a single point to reference. There is also the issue of ensuring that they can all operate on the same datagram flow. This however has been reduced to be STUN, RTP and DTLS. Where DTLS must separate DTLS-SRTP messages from the regular DTLS protected data flow which contains SCTP packets. But, the first is actually well described in the DTLS-SRTP spec. When it comes to JSEP it clearly is the signalling part that enables the establishment of the datagram transport flow. It is also crucial in the maintenance of it, for example re-establishing in case of used interfaces going down etc. In this we also have the question about the ICE variant we intended to use which supports trickle candidates. There are no IETF specification for it. That appears to be needed to be created. This is not work for this WG. The appropriate home for such work is most likely MMUSIC. In addition we still have the need for someone to define what ICE and what additional tools we need. We also have certain API requirements from this. Like the configuration of STUN and TURN and any additional relay like solution we have for the HTTP fallback. It could be that JSEP spec is a good enough home for this. It might be that we would get a better separation of work and cleaner referencing if we create a separate specification. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 ibc@aliax.net Fri Jul 6 00:33:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A779521F8705 for ; Fri, 6 Jul 2012 00:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnYG+MC2K9mD for ; Fri, 6 Jul 2012 00:33:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC8E221F8702 for ; Fri, 6 Jul 2012 00:33:27 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so14065226lbb.31 for ; Fri, 06 Jul 2012 00:33:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=Sk0XDsIN6pQVrEKW1R1J0s8obj6IWsZkIpKQkyA2k9k=; b=imgyCaPxaFiPN9suesa5RZyYfMwyiPa0rZ7Sj8LrQwczSX36/KN/4wC/MfemLD0ffO Ge1niAvBiZDDTwXyJ/7KZblSeXH6nYh5upL9H0b2ZM9ltqrEaEqFWCuWyKCcD1Pb3WVX mmm8hyVJ1sX2DZxb+OZaLTNCU+TusmUme8IKcVdNLcJgPBU2N9Beu0mq7KLahs0adTJB sf5eKGqZ4bJasVZadFOYH3rYtKPmBLAWyLXLbvSgIOmp9ql+OrLfOoxs3QUq/icJtprQ qG9LO5x6Rq3wB6TvsyNeafCh0pmRMfUwedX11c1HaMMLQ9o+raRaJ8E2wfGCRZdvLExy zv5g== Received: by 10.152.144.103 with SMTP id sl7mr14256601lab.37.1341560022637; Fri, 06 Jul 2012 00:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Fri, 6 Jul 2012 00:33:22 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 6 Jul 2012 09:33:22 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmd1JtyNq1P6aityD+z9FgIGKHhltBPIiA4I66D5EoqZxLZhcP51ZzE4TD2PSjd2fhFgDPk Subject: Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:33:28 -0000 Hi, I would really appreciate some explanation about this subject. Basically the aim of my question is to imitate the behavior of existing chat+audio+video clients in which the session is initially started with just audio, and video is added later (by asking for user consent). I hope that raw parsing of the received SDP is not needed for achieving thi= s :) Regards. 2012/7/4 I=C3=B1aki Baz Castillo : > Hi, let's assume I have an established audio session. Later the remote > sends me a new SDP offer (let's say a SIP re-INVITE) and I want to > analyze what is new in the new SDP (in order to ask the user for > consent). So for example when the new SDP arrives I need to know > whether it contains audio and video or whatever. > > With the current JSEP API I see no way. The only I can do with the new > received SDP is: > > pc.setRemoteDescription(SDP_OFFER, REMOTE_SDP_TEXT) > > but this would alter my multimedia session before I can ask my user > for consent. Do I miss something? > > And I would also like to know whether the received SDP contains > dissabled streams (i.e. a video stream with port 0) before accepting > it. Basically I want a mechanism for getting a diff between the > existing remote SDP and the new received one. > > -- > I=C3=B1aki Baz Castillo > --=20 I=C3=B1aki Baz Castillo From martin.thomson@gmail.com Fri Jul 6 09:15:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A180721F86DB for ; Fri, 6 Jul 2012 09:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8fZn7v8-696 for ; Fri, 6 Jul 2012 09:15:55 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE3521F87C4 for ; Fri, 6 Jul 2012 09:15:54 -0700 (PDT) Received: by bkty7 with SMTP id y7so1440464bkt.31 for ; Fri, 06 Jul 2012 09:16:10 -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=mTCU1v1Pwk05GBY4FEXV/6RK8azMshJKRsntX3p0hKQ=; b=zLaLdmBrcQlolDD0Eyl1FJs9StZbS3W3ZUjSvbDx1KN5vqZQ/3crv3IPMsYFsNA8bz 2F3gaB18aq0qj38zCMLBFGclimWTJGLahoxcf4mB+xOqjCgzQKvpIOUl+/tj9OIPbBUd Vbg2ef6+RKywlpkNnr6V8v1AOrLJpwhGmYqOd4gTglXF4XoETpwcX/3Nnzku9hmgmXjY qh9zHE4j4X072J5aqKqXm8djJH2aLl4v/BV+e1NfDHDPpc68e8DzUI+OFlySu8sh7dQ7 N8KAhIphzTN3oHQxYz/ayS38fO8f4gfkJPVPSQANSx5UJ/Cp2cS+uosTAxXcX5juoHBt 8D9A== MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr5072888bkw.49.1341591370381; Fri, 06 Jul 2012 09:16:10 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Fri, 6 Jul 2012 09:16:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 09:16:10 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 16:15:56 -0000 On 6 July 2012 00:33, I=C3=B1aki Baz Castillo wrote: > I hope that raw parsing of the received SDP is not needed for achieving t= his :) I'm surprised that you think that. I believe that the subject is one of the open issues, though I believe that the current discussion was heading toward the conclusion that calling setDescription() on a PeerConnection was the blessed method for determining what streams are present in an offer or answer. Therefore, the process is something like... # Take existing session, look at the attached streams (and their tracks). # Take new offer, create new PeerConnection, attach the same local streams, call pc.setRemoteDescription(OFFER, sdpOffer), examine the resulting attached streams (and their tracks). # Discard the new PeerConnection. Of course, this is highly likely to fail because the resources necessary to create and configure the second PeerConnection are likely taken by the first. So your best bet is to scrounge through the SDP. But SDP is awesome, so it's OK. --Martin From fluffy@iii.ca Sat Jul 7 07:59:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F129F21F866B for ; Sat, 7 Jul 2012 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGJdyPoj1szQ for ; Sat, 7 Jul 2012 07:59:29 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EF11521F8661 for ; Sat, 7 Jul 2012 07:59:28 -0700 (PDT) Received: from sjc-vpn3-586.cisco.com (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 A826A22E257; Sat, 7 Jul 2012 10:59:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Sat, 7 Jul 2012 07:59:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87ED6FF5-3339-46C8-807C-668CE9D1C4EA@iii.ca> References: To: Remi Scavenius X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] rtcweb Digest, Vol 17, Issue 10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 14:59:33 -0000 I think we have had conversations in the past about advertising upper = side conferences on the the IETF lists. This is not an appropriate list = for posting about conferences and trade shows. The first posting with = the link I just ignored as no doubt the conference is interesting to = many participants of this list but please don't send more of these. Thanks you, Cullen =20 PS - if you want to talk about this, I'd be happy to have a phone call = about it and come up with something that works well for informing IETF = participants while at the same time not opening up a floodgate of off = topic messages.=20 =20 On Jul 5, 2012, at 5:06 , Remi Scavenius wrote: >=20 > The programme of the WebRTC Conference (Paris, October 10-12) is = online: > http://www.uppersideconferences.com/webrtc2012/webrtc2012intro.html >=20 > Regards >=20 > Remi Scavenius, agenda manager. >=20 > Le 5 juil. 2012 =E0 13:30, rtcweb-request@ietf.org a =E9crit : >=20 >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to=20 >>=20 >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >>=20 >>=20 >>=20 >> Send rtcweb mailing list submissions to >> rtcweb@ietf.org >>=20 >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/rtcweb >> or, via email, send a message with subject or body 'help' to >> rtcweb-request@ietf.org >>=20 >> You can reach the person managing the list at >> rtcweb-owner@ietf.org >>=20 >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of rtcweb digest..." >> Today's Topics: >>=20 >> 1. Re: Do we still need PRANSWER? (Chenxin) >> 2. Re: RTP Usage: Is RTP Retransmission REQUIRED or = RECOMMENDED >> (Randell Jesup) >> 3. Re: Do we still need PRANSWER? (I?aki Baz Castillo) >> 4. Re: Do we still need PRANSWER? (Olle E. Johansson) >> 5. Re: Do we still need PRANSWER? (Roman Shpount) >>=20 >> De : Chenxin >> Date : 5 juillet 2012 06:00:15 HAEC >> =C0 : Roman Shpount >> Cc : "rtcweb@ietf.org" >> Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >>=20 >>=20 >> +1 >> I think PRANSWER is still useful for Jingle interop especially for = ICE candidate trickling. >> =20 >> But I think we should not leave the WebRTC-SIP interop problem to = the application layer gateway. >> =20 >> I find some words in chart: =20 >> 9. The group will consider options for interworking with legacy = VoIP >> equipment. >> =20 >> it is necessary to solve SIP interop problem in RTCWEB other than = leaving it to implementor. >> =20 >> BR, >> Xin >> From: Roman Shpount [mailto:roman@telurix.com]=20 >> Sent: Thursday, July 05, 2012 3:47 AM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Do we still need PRANSWER? >> =20 >> It looks like WebRTC-SIP interop without an application layer gateway = would not be possible in the near future due to all the media transport = requirements that were introduced. Given that SIP interop is no longer = possible, why do we still need PRANSWER? Since an application layer = gateway must be deployed, the same gateway can handle both serial and = parallel forking. The WebRTC application will work with the gateway to = create new streams or to create new connections, as necessary when new = SIP dialogs are created and new answers are received. >> _____________ >> Roman Shpount >>=20 >>=20 >>=20 >> De : Randell Jesup >> Date : 5 juillet 2012 07:10:55 HAEC >> =C0 : rtcweb@ietf.org >> Objet : R=E9p : [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or = RECOMMENDED >>=20 >>=20 >> On 7/4/2012 10:23 AM, Stefan Hakansson LK wrote: >>> On 07/02/2012 11:51 PM, Randell Jesup wrote: >>>>=20 >>>>> Again, this is about making _support_ for retransmission a = requirement, >>>>> not _use_. >>>>=20 >>>>=20 >>>> If you don't mandate use, what does mandating "support" buy you? = An >>>> implementation (see above about PSTN gateways) might always decline = to >>>> use retransmission, so what does MUST (REQUIRE) buy you? I say = SHOULD >>>> (RECOMMEND), with a statement that it's strongly recommended it be >>>> supported if video is supported, especially for non-single-purpose >>>> devices (i.e. browsers). >>>>=20 >>>> In either case, you need to think about who decides to use re-xmit = or >>>> not, what influences that, and if the app has visibility into this. >>>> Someone could as an rtx-time=3D0 to the SDP. Or not include one, = but >>>> never actually retransmit a packet regardless of NACKs - it could = just >>>> repair via IDR (or other means). >>>>=20 >>>> So here's a real problem related to retransmission: since the = request is >>>> not specific and negotiated (it's normally a generic NACK), the = receiver >>>> who sent the NACK has no idea if it will get a retransmission, an = IDR >>>> (or IDR slice), another form of repair (pframe/slice against >>>> known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, = it >>>> doesn't know if it should freeze the video or play with errors. It = has >>>> to decide if it *thinks* the sender will use retransmission, or if = it >>>> doesn't, does the receiver want to freeze video until an IDR or = other >>>> repair is done, which might be a while. >>>=20 >>> Isn't retransmission negotiated using "rtx", "atp" and so on? >>=20 >> Support for it is. However, negotiating support for it doesn't solve = the problem of not knowing how the sender will respond to a NACK (or = SLI/RPSI/etc). Generally, the sender has to make the decision, but the = receiver has to guess. >>=20 >>>=20 >>> One way of removing the uncertainty would be to require that all = browsers support RTP retransmission: This way, any RTP endpoint sending = a NACK to a browser would know that that packet would be retransmitted = (given that congestion does not prohibit, or NACK packet is lost etc.). >>=20 >> Um, no. Just because both sides support retransmission does not mean = that a NACK will generate a retransmission. Retransmission only makes = sense in some instances, and there's no guarantee that retransmission = will be possible (for example, the requested packet might have timed out = and been thrown away). >>=20 >>>=20 >>> If we have this in place, I'm confident that implementors will = quickly develop strategies on how and when to _use_ retransmission in = the best way. There has already been input made on its usefulness. >>=20 >> Sure, and they will anyways. RECOMMENDED or REQUIRED, it really = doesn't matter to the implementation. For that matter, even if REQUIRED = there's nothing that says it has to be offered or accepted. Even if = that were mandated, the implementation could accept but with a 0-length = rtx-time. So it's really unclear what REQUIRED buys you that = RECOMMENDED doesn't. >>=20 >>>=20 >>> Maybe the problem with legacy not always supporting retransmission = is not that big. First of all, legacy is to a large extent audio only = (e.g. PSTN), and no one is arguing for retransmission there. Secondly, I = fail to see that this situation would be improved in any way if browsers = are only recommended (and not required) to support RTP retransmission. >>>=20 >>> So I think we should require rtcweb capable browsers to support RTP = retransmission. >>>=20 >>>>=20 >>>> We also need to think about when a receiver should use SLI or RPSI. = PLI >>>> can also be used and should be if the other options don't negotiate = (so >>>> it's important to offer it). Certainly it's more work to keep = track of >>>> the contents of each packet (slices, etc), especially in things = like >>>> H.264 NALU aggregation packets, than it is to just respond to an = SLI. >>>>=20 >>>> That said, my previous systems just used NACK and let the sender = decide >>>> the correct repair, but I wasn't leveraging slices and wasn't using >>>> retransmission, so there was only minor complexity (looking at = possible >>>> reference frames). >>=20 >>=20 >> --=20 >> Randell Jesup >> randell-ietf@jesup.org >>=20 >>=20 >>=20 >>=20 >>=20 >> De : I=F1aki Baz Castillo >> Date : 5 juillet 2012 10:48:53 HAEC >> =C0 : Roman Shpount >> Cc : rtcweb@ietf.org >> Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >>=20 >>=20 >> 2012/7/4 Roman Shpount : >>> It looks like WebRTC-SIP interop without an application layer = gateway would >>> not be possible in the near future due to all the media transport >>> requirements that were introduced. Given that SIP interop is no = longer >>> possible, why do we still need PRANSWER? Since an application layer = gateway >>> must be deployed, the same gateway can handle both serial and = parallel >>> forking. >>=20 >> No please, don't decide/mandate/impose how the signaling must be >> implemented. And don't assure that pure SIP signaling cannot be used >> in the browser neither force the usage of annoying B2BUA's or >> signaling-protocol-exotic-and-buggy-gateways in order to interop with >> SIP networks (mostly because pure SIP interop is already possible >> without negative elements like B2BUA's or signaling gateways). >>=20 >> I want a pure SIP proxy and handle parallel and serial SIP forking as >> RFC 3261 states, without magic servers breaking things. And this >> *already* works [1] so it IS possible. >>=20 >> If most of the people assume that WebRTC-SIP interop requires some >> amateur and limited JSON based signaling protocol between the >> (stupid?) browser and a magic JSON-SIP-MEDIA gateway >> (super-intelligent?), that's their assumption, but that should not be >> mandatory by specs. >>=20 >> About the media plance interop: ok, WebRTC has added lot of stuff, = but >> AFAIK if the SIP side implements ICE + SDES-SRTP it should be = possible >> to interop in the media plane without negative intermediary elements. >> In the other side, once WebRTC is extended I'm pretty sure that SIP >> designers and vendors will try to satisfy WebRTC media requirements >> within SIP, so let's leave the door open rather than "requiring $$$$$ >> B2BUA's black-death-boxes". >>=20 >> Please, don't limit or force the network topology. >>=20 >>=20 >>=20 >>> The WebRTC application will work with the gateway to create new >>> streams or to create new connections, as necessary when new SIP = dialogs are >>> created and new answers are received. >>=20 >> No, sorry, no. Or yes (in your specific case), but not in mine. >>=20 >>=20 >> Regards. >>=20 >>=20 >> [1] http://sip-on-the-web.aliax.net/ >>=20 >>=20 >> --=20 >> I=F1aki Baz Castillo >> >>=20 >>=20 >>=20 >>=20 >> De : "Olle E. Johansson" >> Date : 5 juillet 2012 11:12:55 HAEC >> =C0 : Roman Shpount >> Cc : rtcweb@ietf.org >> Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >>=20 >>=20 >>=20 >> 4 jul 2012 kl. 21:46 skrev Roman Shpount: >>=20 >>> It looks like WebRTC-SIP interop without an application layer = gateway would not be possible in the near future due to all the media = transport requirements that were introduced. Given that SIP interop is = no longer possible >>=20 >> I think that's a bad conclusion, Roman. >>=20 >> I talked about the installed base of SIP devices and their RTP stack. = It doesn't mean that ALL SIP implementations won't be able to interop = with WebRTC and that there never will be SIP connected to webrtc, either = in a browser app or in a server implementation. I do expect that new SIP = apps will arise and that the current ones will be upgrading.=20 >>=20 >> SIP interop is definitely possible in WebRTC regardless of the RTP = layer. >>=20 >> I still think there's value in interop with a large installed base of = RTP-capable devices. Having media relays in the media path is known not = to improve media quality. >>=20 >> /O >>=20 >>=20 >>=20 >> De : Roman Shpount >> Date : 5 juillet 2012 13:30:14 HAEC >> =C0 : I=F1aki Baz Castillo >> Cc : rtcweb@ietf.org >> Objet : R=E9p : [rtcweb] Do we still need PRANSWER? >>=20 >>=20 >> This was all written out of frustration mainly by the direction taken = by this group on adding things that are not strictly necessary but break = interoperability. It is completely incomprehensible to me why the group = decided to add PRANSWER if connection cloning is just as easy to = implement and would make, on one hand, interop easier, on another hand = add significant new functionality. When I am saying that connection = cloning is easy to implement I mean that I am willing to build a = prototype based on chromium code that implements it. Getting the new API = through IETF/W3C is above my skill level, since I am fairly bad at = writing drafts. >>=20 >> On Thu, Jul 5, 2012 at 4:48 AM, I=F1aki Baz Castillo = wrote: >> 2012/7/4 Roman Shpount : >> > It looks like WebRTC-SIP interop without an application layer = gateway would >> > not be possible in the near future due to all the media transport >> > requirements that were introduced. Given that SIP interop is no = longer >> > possible, why do we still need PRANSWER? Since an application layer = gateway >> > must be deployed, the same gateway can handle both serial and = parallel >> > forking. >>=20 >> No please, don't decide/mandate/impose how the signaling must be >> implemented. And don't assure that pure SIP signaling cannot be used >> in the browser neither force the usage of annoying B2BUA's or >> signaling-protocol-exotic-and-buggy-gateways in order to interop with >> SIP networks (mostly because pure SIP interop is already possible >> without negative elements like B2BUA's or signaling gateways). >>=20 >> I want a pure SIP proxy and handle parallel and serial SIP forking as >> RFC 3261 states, without magic servers breaking things. And this >> *already* works [1] so it IS possible. >>=20 >>=20 >> I do not doubt that some SIP interop on the signaling level is = possible. It would break, however, on a first case of parallel forking. = My main concern, however, is the media level interop with any existing = devices. >>=20 >> Correct me if I am wrong, but your already working solution is using = an older WebRTC implementation that supported plain RTP. >>=20 >> If most of the people assume that WebRTC-SIP interop requires some >> amateur and limited JSON based signaling protocol between the >> (stupid?) browser and a magic JSON-SIP-MEDIA gateway >> (super-intelligent?), that's their assumption, but that should not be >> mandatory by specs. >>=20 >> I do not want magic gateways either, but it looks like when this = group is adding features it assumes some sort of gateway would be = present. >> =20 >> About the media plance interop: ok, WebRTC has added lot of stuff, = but >> AFAIK if the SIP side implements ICE + SDES-SRTP it should be = possible >> to interop in the media plane without negative intermediary elements. >> In the other side, once WebRTC is extended I'm pretty sure that SIP >> designers and vendors will try to satisfy WebRTC media requirements >> within SIP, so let's leave the door open rather than "requiring $$$$$ >> B2BUA's black-death-boxes". >>=20 >>=20 >> SDES-SRTP support is not something that this group decided upon. If = the group is honest about its security requirements (JavaScript = application is not trusted), then SDES-SRTP should not be allowed. This = means you need ICE+DTLS-SRTP+AVPF support in the SIP device to operate = directly with WebRTC on the media plane. I curious if you can name one = device that support all of those. I would actually buy one for interop = alone. And from experience, I doubt that large SIP vendors would do = anything meaningful for a while.=20 >>=20 >> Please, don't limit or force the network topology. >>=20 >> I do not, but I think that what the group effectively does. I got a = feeling most of the major contributors only care about a limited sets of = apps that do not need to concern themselves with interop. I also got a = feeling that they are more concerned about marketing then security. >>=20 >>=20 >> > The WebRTC application will work with the gateway to create new >> > streams or to create new connections, as necessary when new SIP = dialogs are >> > created and new answers are received. >>=20 >> No, sorry, no. Or yes (in your specific case), but not in mine. >>=20 >> It is, unfortunately, the only thing I can do in my case, since all = the SIP end points I am dealing with (SIP Trunks in PBXs and SIP from = VoIP vendors) do not support any encryption, have flaky support for SIP = re-Invites, and some do parallel forking. It is the real world, and = here, it is a magic box or bust. >> =20 >> [1] http://sip-on-the-web.aliax.net/ >>=20 >> _____________ >> Roman Shpount >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Sun Jul 8 19:40:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE6921F86C6 for ; Sun, 8 Jul 2012 19:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS-F75CzG0tT for ; Sun, 8 Jul 2012 19:40:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 522F821F86A8 for ; Sun, 8 Jul 2012 19:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2161; q=dns/txt; s=iport; t=1341801677; x=1343011277; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=TJcoy4p26+K/tia9OvYcxRFPzXuiLcdFm07J5JMby0U=; b=XL6hNVtfQ8wW/rQlvFkDYSdMEEN3zYlIySx9xX6f9SWm5lSNMwkkVD0b sExRwBELW6m/5ISvbSgRyaJUPCgQkuS0zNBv/YfnHPE/83BrRLPLUeUTa Ty+ek0xKUeVKvr+50CcWOc7CxPIONC00OFl0CJcbxYmF7lTOznbJDjMVr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABhE+k+tJV2a/2dsb2JhbABFt1+BB4IgAQEBBAEBAQ8BJzQXBgEIEQQBAQsUCS4LFAcBAQUFBBMIARmHawuZLYEonnqLQIUsYAOWSIl1gxiBZoJf X-IronPort-AV: E=Sophos;i="4.77,548,1336348800"; d="scan'208";a="99868966" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 09 Jul 2012 02:41:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q692fGex019106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Jul 2012 02:41:16 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Sun, 8 Jul 2012 21:41:16 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-reddy-rtcweb-stun-auth-fw-traversal-00.txt Thread-Index: AQHNXTWPOwIigH/dEkOC+qiswqiNUpcgM59w Date: Mon, 9 Jul 2012 02:41:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.83.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19028.001 x-tm-as-result: No--24.410900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] FW: I-D Action: draft-reddy-rtcweb-stun-auth-fw-traversal-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 02:40:54 -0000 This draft discusses the issues with firewall traversal for ICE connectivit= y checks and media in WebRTC deployments and proposes an alternate model wh= erein extensions to ICE connectivity checks can be examined by the firewall= to permit outgoing UDP flows across the firewall. Comments welcome.. - Muthu/Tiru/Ram/Dan -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Sunday, July 08, 2012 11:44 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-reddy-rtcweb-stun-auth-fw-traversal-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : STUN Extensions for Authenticated Firewall Traversal Author(s) : Tirumaleswar Reddy Muthu Arul Mozhi Perumal Dan Wing Filename : draft-reddy-rtcweb-stun-auth-fw-traversal-00.txt Pages : 14 Date : 2012-07-08 Abstract: Some networks deploy firewalls configured to block UDP traffic. When SIP user agents or WebRTC endpoints are deployed behind such firewalls, media cannot be sent over UDP across the firewall, but must be sent using TCP (which causes a different user experience) or through a session border controller. This draft describes an alternate model wherein extensions to ICE connectivity checks can be examined by the firewall to permit outgoing UDP flows across the firewall. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-reddy-rtcweb-stun-auth-fw-traversal There's also a htmlized version available at: http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Markus.Isomaki@nokia.com Mon Jul 9 08:13:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593C621F86DA for ; Mon, 9 Jul 2012 08:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTXFc5nS+12A for ; Mon, 9 Jul 2012 08:13:40 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A174421F86D9 for ; Mon, 9 Jul 2012 08:13:40 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q69FE4MF019342 for ; Mon, 9 Jul 2012 18:14:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jul 2012 18:14:26 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.193]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Mon, 9 Jul 2012 17:14:02 +0200 From: To: Thread-Topic: New Version Notification for draft-isomaki-rtcweb-mobile-00.txt Thread-Index: AQHNXeHvNv5cEDVx8UK5yDeIjqmZcJchDQyA Date: Mon, 9 Jul 2012 15:14:01 +0000 Message-ID: References: <20120709144813.22696.79942.idtracker@ietfa.amsl.com> In-Reply-To: <20120709144813.22696.79942.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.17.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2012 15:14:26.0662 (UTC) FILETIME=[878C3860:01CD5DE5] X-Nokia-AV: Clean Subject: [rtcweb] FW: New Version Notification for draft-isomaki-rtcweb-mobile-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 15:13:41 -0000 SGksDQoNCkkgaGF2ZSBmb3IgdGltZSB0byB0aW1lIHJhaXNlZCBwYXJ0aWN1bGFyIGlzc3VlcyBm b3IgV2ViUlRDIHJlbGF0ZWQgdG8gbW9iaWxlIG5ldHdvcmtzLiBOb3cgSSBmb3VuZCBzb21lIHRp bWUgdG8gY29sbGVjdCBtb3N0IG9mIHRoZW0gaW50byBhIHNpbmdsZSBkb2N1bWVudC4gVGhlIGRy YWZ0IGJlbG93IGRpc2N1c3NlcyB3aGF0IGFyZSBpbiBteSBvcGluaW9uIHRoZSBtb3N0IG5vdGFi bGUgdG9waWNzIGZvciBXZWJSVEMgYWRvcHRpb24gaW4gbW9iaWxlIGRldmljZXMgYW5kIG5ldHdv cmtzIChlc3BlY2lhbGx5IGNlbGx1bGFyKS4gVGhlIC0wMCB2ZXJzaW9uIG1pc3NlcyBhbGwgcmVm ZXJlbmNlcyBhbmQgd2FzIHdyaXR0ZW4gaW4gYSBoYXN0ZSwgYnV0IEkgaG9wZSBpdCBpcyB1c2Vm dWwgdG8gbWFrZSBzdXJlIHRoZXNlIHRvcGljcyBkbyBnZXQgZW5vdWdoIGF0dGVudGlvbi4gDQoN ClRoZSBtYWluIHRvcGljcyBjb3ZlcmVkIGFyZSByZWxhdGVkIHRvIHBvd2VyIGNvbnN1bXB0aW9u IChmb3IgYm90aCAic2lnbmFsaW5nIiBhbmQgIm1lZGlhIiksIGludGVyZmFjZSBzd2l0Y2hpbmcg YW5kIGNvbmdlc3Rpb24gYXZvaWRhbmNlLg0KDQpSZWdhcmRzLA0KCU1hcmt1cyANCg0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBleHQgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPlNlbnQ6IDA5IEp1bHksIDIw MTIgMTc6NDgNCj5UbzogSXNvbWFraSBNYXJrdXMgKE5va2lhLUNJQy9Fc3BvbykNCj5TdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlzb21ha2ktcnRjd2ViLW1vYmls ZS0wMC50eHQNCj4NCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaXNvbWFraS1ydGN3 ZWItbW9iaWxlLTAwLnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFy a3VzIElzb21ha2kgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPnJlcG9zaXRvcnkuDQo+DQo+Rmls ZW5hbWU6CSBkcmFmdC1pc29tYWtpLXJ0Y3dlYi1tb2JpbGUNCj5SZXZpc2lvbjoJIDAwDQo+VGl0 bGU6CQkgUlRDd2ViIENvbnNpZGVyYXRpb25zIGZvciBNb2JpbGUgRGV2aWNlcw0KPkNyZWF0aW9u IGRhdGU6CSAyMDEyLTA3LTA5DQo+V0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+TnVt YmVyIG9mIHBhZ2VzOiAxMA0KPlVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaXNvbWFraS1ydGN3ZWItbW9iaWxlLQ0KPjAwLnR4dA0KPlN0 YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pc29t YWtpLXJ0Y3dlYi1tb2JpbGUNCj5IdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlzb21ha2ktcnRjd2ViLW1vYmlsZS0wMA0KPg0KPg0KPkFic3RyYWN0Og0K PiAgIFdlYiBSZWFsLXRpbWUgQ29tbXVuaWNhdGlvbnMgKFdlYlJUQykgYWltcyB0byBwcm92aWRl IHdlYi1iYXNlZA0KPiAgIGFwcGxpY2F0aW9ucyByZWFsLXRpbWUgYW5kIHBlZXItdG8tcGVlciBj b21tdW5pY2F0aW9uIGNhcGFiaWxpdGllcy4NCj4gICBJbiBtYW55IGNhc2VzIHRob3NlIGFwcGxp Y2F0aW9ucyBhcmUgcnVuIGluIG1vYmlsZSBkZXZpY2VzIGNvbm5lY3RlZA0KPiAgIHRvIGRpZmZl cmVudCB0eXBlcyBvZiBtb2JpbGUgbmV0d29ya3MuICBUaGlzIGRvY3VtZW50IGdpdmVzIGFuDQo+ ICAgb3ZlcnZpZXcgb2YgdGhlIGlzc3VlcyBhbmQgY2hhbGxlbmdlcyBpbiBpbXBsZW1lbnRpbmcg YW5kIGRlcGxveWluZw0KPiAgIFdlYlJUQyBpbiBtb2JpbGUgZW52aXJvbm1lbnRzLiAgSXQgYWxz byBnaXZlcyBndWlkYW5jZSBvbiBob3cgdG8NCj4gICBvdmVyY29tZSB0aG9zZSBjaGFsbGVuZ2Vz Lg0KPg0KPg0KPg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From ekr@rtfm.com Mon Jul 9 12:24:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACB911E81CE for ; Mon, 9 Jul 2012 12:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.748 X-Spam-Level: X-Spam-Status: No, score=-102.748 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSMuEErQsZUS for ; Mon, 9 Jul 2012 12:24:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4611E81C9 for ; Mon, 9 Jul 2012 12:24:47 -0700 (PDT) Received: by vcqp1 with SMTP id p1so8179308vcq.31 for ; Mon, 09 Jul 2012 12:25:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=gJ7xORnLplm+p91O1A1fnv/cu1Nh6JeD0gSLJznkVBo=; b=kms2p5K7pHAMMEtS5AML7qZm33jMnxRxXXsEvPIN/wuDEXEoBWrCBsbjb6pUzehbJW eQTNOKHNRwUDgyQN8L8QzjqRqJWpog5fu092K4vMHdOZEI89KvCr1XQrl6tBJmQalmel fB6SY2rbUNHrgM7HoXCAcjNLbiOPKsHvbjQQ48o+b/yfd5nqMbKOnYrMmgnKeeyz7JMQ 8ah1+8fuMe+WYvaeqSW373TZ4UwQLway4C1PcCnD97O50HnXefhgQ8avyi/RnGzyXs9/ u24hWpYq36McJ9hoZO0uXVrXWF9HVRr+Oo95R0ZJUt/sVAar1aO2+6LyKxhcl0ejWMsw M6bQ== Received: by 10.52.93.133 with SMTP id cu5mr16769931vdb.125.1341861912853; Mon, 09 Jul 2012 12:25:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 9 Jul 2012 12:24:32 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 9 Jul 2012 12:24:32 -0700 Message-ID: To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkPeOfFhL8uL4MNUORZ0CKyE7ulKgR/rv14uQymTN+xpWExCqVbJ/MKdcZJjuTaZUUm0Rp0 Cc: rtcweb@ietf.org Subject: [rtcweb] FYI: draft-rescorla-random-cname-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:24:48 -0000 As discussed at the RTCWEB interim: Executive summary: use a CSPRNG to generate CNAMEs. -Ekr From dwing@cisco.com Mon Jul 9 14:09:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98611E80F8 for ; Mon, 9 Jul 2012 14:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PW5cnrrQR5s for ; Mon, 9 Jul 2012 14:09:35 -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 3698511E80DB for ; Mon, 9 Jul 2012 14:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1446; q=dns/txt; s=iport; t=1341868201; x=1343077801; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=i/44pwn+b96tKDIVTeifEr5p7i+KIU93hEjmHZs6zT8=; b=faUf5iVPua+zXK6zqD9h6+QyPdSCweF/FwsRXs814mp0lGi61wTYQlJ5 K5omiSQRlqaymLsYrC6jssVfmLSAtNnhcRqGI5IwFg/f4Jpiu5pF38Bms vauKoa9SLO9mIFys0N5LT4GJpbXPGx6ws+xSrvsVcTLNfdjGaaXY1gpu9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAKdH+0+rRDoJ/2dsb2JhbABFqFSPKIEHgiABAQEECAoBFxA9DgEDAgkPAgQBASgHGSMKCAEIAgQBEgsXh2oMm2ygM4tAG4VxA4hJhQWIeo0NgWaCfw X-IronPort-AV: E=Sophos;i="4.77,555,1336348800"; d="scan'208";a="51476574" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Jul 2012 21:10:01 +0000 Received: from dwingWS (sjc-vpn5-1298.cisco.com [10.21.93.18]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q69LA0pB011111; Mon, 9 Jul 2012 21:10:00 GMT From: "Dan Wing" To: , References: <20120709144813.22696.79942.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 9 Jul 2012 14:09:59 -0700 Message-ID: <03e201cd5e17$33428a70$99c79f50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNXeHvNv5cEDVx8UK5yDeIjqmZcJchDQyAgABixsA= Content-Language: en-us Subject: Re: [rtcweb] FW: New Version Notification for draft-isomaki-rtcweb-mobile-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:09:35 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Markus.Isomaki@nokia.com > Sent: Monday, July 09, 2012 8:14 AM > To: rtcweb@ietf.org > Subject: [rtcweb] FW: New Version Notification for draft-isomaki- > rtcweb-mobile-00.txt > > Hi, > > I have for time to time raised particular issues for WebRTC related to > mobile networks. Now I found some time to collect most of them into a > single document. The draft below discusses what are in my opinion the > most notable topics for WebRTC adoption in mobile devices and networks > (especially cellular). The -00 version misses all references and was > written in a haste, but I hope it is useful to make sure these topics > do get enough attention. > > The main topics covered are related to power consumption (for both > "signaling" and "media"), interface switching and congestion avoidance. Both Section 3.1, "Persistent connectivity to the Calling Site", and Section 3.2, "Media and Data channels", discuss the problem of frequent TCP or UDP messages that are sent solely to keep firewall pinholes or NAT mappings alive. PCP (draft-ietf-pcp-base) would be useful to reduce those messages. Section 3.3, "Recovery from interface switching" discusses RTP flows (and other things). RTP and SCTP-over-UDP flows can benefit from MICE, http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility -d From martin.thomson@gmail.com Mon Jul 9 14:10:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC10E11E8212 for ; Mon, 9 Jul 2012 14:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LycI7rcUGEJ8 for ; Mon, 9 Jul 2012 14:10:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1826E11E81D4 for ; Mon, 9 Jul 2012 14:10:01 -0700 (PDT) Received: by bkty7 with SMTP id y7so3129585bkt.31 for ; Mon, 09 Jul 2012 14:10:27 -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:cc:content-type; bh=km6Wze+o0MZ2cPHwksxBezdNim4evUnpzz5fPi3QW7k=; b=gcM7f5he7J7JubXmmryyLFRPylLpenwBG05pWTcARTtb7D1dLzpMBOrLOJYzTLt3mG K5XiZSVVrBJqwwNkRJ3R2G/uvSrE/YRBsPrTHjduVGTEbk7xARnhp/ZhsEgQLPt1401Y 9HP7S0kk8mD+VNcN4I5McbMZUuG53cj88lECe6vrEfkPTXlyT6uST2y5TPZmXUbgecyn 7ZxWM8UNQMBUmEviaoAjX+nemRe7uAPrv1hksP9ofGHIVVCPFbKimSAVnxUj2FA+PFEt uh5ac4K5D76bpotY2fLwNjQQREHr6D+tXHDTk1p+GTPT/zI/lQcuSplqEJddn7hH11Tm TK/A== MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr9741762bkw.49.1341868227079; Mon, 09 Jul 2012 14:10:27 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Mon, 9 Jul 2012 14:10:27 -0700 (PDT) Date: Mon, 9 Jul 2012 14:10:27 -0700 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] API requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:10:06 -0000 We have just submitted a draft for discussion in the rtcweb working group: This draft describes the information that must pass between browser and application in order to establish real-time communications. This is not user-facing requirements (-rtcweb-use-cases-and-requirements) or an outright API specification (-jsep). The goal here is to enable the creation and consumption of streams of media packets within the security constraints. The draft describes the minimum necessary set of information only to achieve this end. In related news, Microsoft just joined the W3C Web Real-Time Communications Working Group. Once a few clerical issues are addressed, new W3C proposals that address these requirements will follow. --Martin From martin.thomson@gmail.com Mon Jul 9 14:13:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153CC11E8230 for ; Mon, 9 Jul 2012 14:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.719 X-Spam-Level: X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9jkbautFPd2 for ; Mon, 9 Jul 2012 14:12:51 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8606B11E81BA for ; Mon, 9 Jul 2012 14:12:51 -0700 (PDT) Received: by bkty7 with SMTP id y7so3131081bkt.31 for ; Mon, 09 Jul 2012 14:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FIQcw6/dCtB1yYKtP0wzqvXJy3EIfbmsAdZEE27GJhA=; b=fP3t3vtqcPWD9UVGoGO9nNsiCwt+QMebASE5RQK0El2YTHBXs0A1gSrV7bYnZtEK6w KT93hF2aWscUMWkpyvX/NCzQrKlkFy6mFbD82TD60z+7qsx18j38PEjOq+Iq8TLjR696 3bfsumUvFKlxVY+LpBzaxVmRxj91IJpyWGFGAGPxHInYLsg+1uLMWGIckZHjiws6BThH 1BFcnZSanU54MmN2HgvTYlgz2D0uyhx2M3FgE4qg9vm0ppZcs1P3abOGqFuwj52yYgse sB2/TWOkr4jpLR+kbo8zwRjwhlRqalxmY59C1TukoDUVblZoFXRLhbtrQ8up5l1xhzjy v77g== MIME-Version: 1.0 Received: by 10.204.152.195 with SMTP id h3mr21020846bkw.119.1341868396601; Mon, 09 Jul 2012 14:13:16 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Mon, 9 Jul 2012 14:13:16 -0700 (PDT) In-Reply-To: <03e201cd5e17$33428a70$99c79f50$@com> References: <20120709144813.22696.79942.idtracker@ietfa.amsl.com> <03e201cd5e17$33428a70$99c79f50$@com> Date: Mon, 9 Jul 2012 14:13:16 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-isomaki-rtcweb-mobile-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:13:00 -0000 On 9 July 2012 14:09, Dan Wing wrote: > [...] RTP and SCTP-over-UDP flows can benefit from > MICE, http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility That draft is light on detail in the critical section. I assume that the conclusion is that there is no need to do anything special, just to do something right (i.e., ICE). From dwing@cisco.com Mon Jul 9 14:17:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8B11E821D for ; Mon, 9 Jul 2012 14:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnuBOnpBtQrN for ; Mon, 9 Jul 2012 14:17:46 -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 C9D8E11E81D5 for ; Mon, 9 Jul 2012 14:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1315; q=dns/txt; s=iport; t=1341868692; x=1343078292; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=0IvcAme0GHGTR0zJNMDNHvbXA5TojViFeTmR0VbA4rU=; b=Lt2idypatewoi6r4TEc1Hu6rsVT8rS4shh7IfUp4e8bhFaTbaFT33YXe NA46JPgKlAZBI9mBYz2kcEDK5odjOgzzXl5Sd4ISmDaYBYw+Jc5js/eq4 iN8Rh7aL9MuiYtlxTWsTG+48Ml+TcMTuWZaON8B5zMNahAng15lDFsMat A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAA5K+0+rRDoJ/2dsb2JhbABFhWaibo8ogQeCIAEBAQMBCAoBEAdNAgUHAQMCCQ8CBAEBAQICIwMCAhkIGwoIAQgBAQQTCxeHXAMGBQybb40ZiUANiU6BIIk6ZoR6gRIDiEmFBYh6iXKDG4Fmgn8 X-IronPort-AV: E=Sophos;i="4.77,555,1336348800"; d="scan'208";a="48363875" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 09 Jul 2012 21:18:10 +0000 Received: from dwingWS (sjc-vpn5-1298.cisco.com [10.21.93.18]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q69LIASt017523; Mon, 9 Jul 2012 21:18:10 GMT From: "Dan Wing" To: "'Martin Thomson'" References: <20120709144813.22696.79942.idtracker@ietfa.amsl.com> <03e201cd5e17$33428a70$99c79f50$@com> In-Reply-To: Date: Mon, 9 Jul 2012 14:18:10 -0700 Message-ID: <03e601cd5e18$57a83580$06f8a080$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1eF6/ISPz3fDYYTuKWBvJ+/9PxeAAAB2/g Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-isomaki-rtcweb-mobile-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:17:47 -0000 > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, July 09, 2012 2:13 PM > To: Dan Wing > Cc: Markus.Isomaki@nokia.com; rtcweb@ietf.org > Subject: Re: [rtcweb] FW: New Version Notification for draft-isomaki- > rtcweb-mobile-00.txt > > On 9 July 2012 14:09, Dan Wing wrote: > > [...] RTP and SCTP-over-UDP flows can benefit from > > MICE, http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility > > That draft is light on detail in the critical section. Yes, we wrote the TURN section first and it has the most detail. We will add detail for ICE in -01. Our apologies. > I assume that > the conclusion is that there is no need to do anything special, just > to do something right (i.e., ICE). Correct. ICE already allows the endpoints to have SDP m=/c=/a=candidate lines that disagree regarding their IP addresses and ports. ICE allows that because some network topologies cause the endpoint to be unaware of how packets are forwarded and the location of NATs corresponding to location of STUN servers (or however else the endpoint learns public mappings, e.g., UPnP IGD, PCP, or proprietary mechanisms). So, "just do that" is what the ICE section of draft-wing-mmusic-ice-mobility will say. -d From ekr@rtfm.com Mon Jul 9 14:57:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEB311E811B for ; Mon, 9 Jul 2012 14:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2dPIDMCpgcl for ; Mon, 9 Jul 2012 14:57:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B65111E8118 for ; Mon, 9 Jul 2012 14:57:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so8277659vbb.31 for ; Mon, 09 Jul 2012 14:57:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=zpDhK8dPp8asZqQTgTEQaTR8mkbzRfwNJZKb5jlIW1I=; b=Kq/avGNwUIfp0T1vkuQYNVMtCJboZwz9EteAn6+PVoCwMts0Ir5FKOOn79v4xDoMt4 2G8lUnGFUW/Fo+TsPewdS5CMBjDvtjDdsGmKZPZig9sziOa4g4K/7n5jOPoYvSPuPm64 9oKdcz3G34ejD/4nLyMpiK1FuFHJJBA+vXl8QccmRz7W2eUOw3kWxPwLmCG6CoblnKUt q7K8KBBhaES5qldcr3Hn5NMIEp5Mp94OcpZTp4lnhyxxyxjg0z3xUsEGaV8bcDFOKFVt r4xrakQWx0H7i17W6mNUhXjvS2QPW2fE3fGqQvi8cA7abh82Xoe2P6WRespqPxymH+S/ gucQ== Received: by 10.52.100.229 with SMTP id fb5mr16950250vdb.102.1341871059665; Mon, 09 Jul 2012 14:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 9 Jul 2012 14:56:59 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Mon, 9 Jul 2012 14:56:59 -0700 Message-ID: To: Kevin Gross Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkJzmIz8bD7oN8b3gBpWJOl4WQrCDl3WcgcRSejjoMvTKKuCwpIymqrKSbuGA+MZAYKLLOh Cc: rtcweb@ietf.org, avt@ietf.org Subject: Re: [rtcweb] [AVTCORE] FYI: draft-rescorla-random-cname-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:57:15 -0000 On Mon, Jul 9, 2012 at 2:51 PM, Kevin Gross wrote: > Good start. > > Please consider referencing to RFC 4086. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org > > > On Mon, Jul 9, 2012 at 1:24 PM, Eric Rescorla wrote: >> >> As discussed at the RTCWEB interim: >> >> >> Executive summary: use a CSPRNG to generate CNAMEs. >> >> -Ekr >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > I meant to. Turns out that RFC 4096 and RFC 4086 are not the same thing. Doh! -Ekr From tterriberry@mozilla.com Mon Jul 9 15:29:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C298011E80EC for ; Mon, 9 Jul 2012 15:29:27 -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=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEhJ9lD-xYzo for ; Mon, 9 Jul 2012 15:29:27 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4425311E80EB for ; Mon, 9 Jul 2012 15:29:27 -0700 (PDT) Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D90CAF2632 for ; Mon, 9 Jul 2012 15:29:52 -0700 (PDT) Message-ID: <4FFB5B60.7020607@mozilla.com> Date: Mon, 09 Jul 2012 15:29:52 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] API requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 22:29:27 -0000 Martin Thomson wrote: > In related news, Microsoft just joined the W3C Web Real-Time > Communications Working Group. Once a few clerical issues are > addressed, new W3C proposals that address these requirements will > follow. This is excellent news. Welcome aboard! From ekr@rtfm.com Mon Jul 9 16:02:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CA211E8134 for ; Mon, 9 Jul 2012 16:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAvM-54eGyNI for ; Mon, 9 Jul 2012 16:02:57 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8716411E8133 for ; Mon, 9 Jul 2012 16:02:57 -0700 (PDT) Received: by vcqp1 with SMTP id p1so8295669vcq.31 for ; Mon, 09 Jul 2012 16:03:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=TJlvyquYhiQtvNPgUasofkRSpCc1wZRhuhpFWNG3V1s=; b=UbRLm5o5HT9oSxWpmMHJXoZE1kWb5Q4WiWU/wsj4ODxTPCpg5ovUiM7IH/n7uJVpZQ kYIsdaspZhSFLnHGjBueF3FDwt1TI2KAGZFtTml1uPlmf/XqFIuif6jjg78TVuxes8Y7 f+QyGvPTUiimpv0OWM6f/J7lvv7mdYRhNSHABXwZPwtWLxKwWPZMLyQ8DhiJTHDQFMh3 eTMtznM9fc8FMbRMXbp8C9s/C9jnI2gM+BXIFyIUU6cm6jPuHRV2U6YFMnQhyhkFO05q fbFH4ZAUMCd6uCeNZUrC+nDidCWWgNLyJyv0V5AVHrgynKaWBY6Um3hX0vTIRR1msSon hG7Q== Received: by 10.220.224.77 with SMTP id in13mr20162961vcb.9.1341875003269; Mon, 09 Jul 2012 16:03:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 9 Jul 2012 16:02:42 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FF693EE.8030905@ericsson.com> References: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> <4FF693EE.8030905@ericsson.com> From: Eric Rescorla Date: Mon, 9 Jul 2012 16:02:42 -0700 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQny7eBQg+4+vbSbN+SemnpGlrJnkAdLg4ups7gcDXHOVS63epw3bC+ihcbTiQEkMxwN6cVj Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiBXaGVyZSB0byBzcGVjaWZ5IElDRSB1c2Fn?= =?utf-8?q?e_and_the_common_transport?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 23:02:58 -0000 On Fri, Jul 6, 2012 at 12:29 AM, Magnus Westerlund wrote: > On 2012-07-06 08:25, Sunyang (Eric) wrote: >> Do we really need this? > > That is part of what I am trying to determine. > >> If we start a new specification about ICE, do >> we need integrate the final part of ICE specification with JSEP, this >> will need extra work to make them meet. > > My personal understanding of the relations are the following > > The basic functionality is to establish functional datagram transport > flow or flows (depending on signalling) between WebRTC peers. The > established datagram transport flow is used by the RTP session(s), > DTLS-SRTP key-management establishment and SCTP over DTLS. > > The last part points to that we have 2 or 3 (depending on how you see > DTLS-SRTP) users of the datagram transport flow. As co-author of one of > those documents I would like to have a single point to reference. > > There is also the issue of ensuring that they can all operate on the > same datagram flow. This however has been reduced to be STUN, RTP and > DTLS. Where DTLS must separate DTLS-SRTP messages from the regular DTLS > protected data flow which contains SCTP packets. But, the first is > actually well described in the DTLS-SRTP spec. > > When it comes to JSEP it clearly is the signalling part that enables the > establishment of the datagram transport flow. It is also crucial in the > maintenance of it, for example re-establishing in case of used > interfaces going down etc. > > In this we also have the question about the ICE variant we intended to > use which supports trickle candidates. There are no IETF specification > for it. That appears to be needed to be created. This is not work for > this WG. The appropriate home for such work is most likely MMUSIC. I fear that this is the case... I don't think we actually need a new specification that defines the consent testing, since AFAICT these are just configurable parameters in the ICE spec. That said, we do need to write a profile of that somewhere? Maybe we could turn draft-mutha into that? > In addition we still have the need for someone to define what ICE and > what additional tools we need. We also have certain API requirements > from this. Like the configuration of STUN and TURN and any additional > relay like solution we have for the HTTP fallback. Right. The API obviously has some support for the first two of these, but any thoughts about how we would define the second from a spec perspective? Is there a doc for it? -Ekr From denglingli@chinamobile.com Mon Jul 9 18:26:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9C021F861C for ; Mon, 9 Jul 2012 18:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.962 X-Spam-Level: *** X-Spam-Status: No, score=3.962 tagged_above=-999 required=5 tests=[AWL=4.039, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llCEM6l-jtAC for ; Mon, 9 Jul 2012 18:26:43 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3027D21F8618 for ; Mon, 9 Jul 2012 18:26:43 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 6B8EFE83B for ; Tue, 10 Jul 2012 09:26:52 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 64485E836 for ; Tue, 10 Jul 2012 09:26:52 +0800 (CST) Received: from cmccPC ([10.2.43.200]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071009264988-21614 ; Tue, 10 Jul 2012 09:26:49 +0800 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Tue, 10 Jul 2012 09:26:47 +0800 Message-ID: <002701cd5e3b$1317a310$3946e930$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1eCRcqLyJlA60SSYOnZ+2pN+RHnwAMFOUg X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-10 09:26:49, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-10 09:26:51, Serialize complete at 2012-07-10 09:26:51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19030.002 X-TM-AS-Result: No--8.275-7.0-31-10 X-imss-scan-details: No--8.275-7.0-31-10;No--8.275-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [rtcweb] FW: New Version Notification for draft-deng-rtcweb-svccontrol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 01:26:43 -0000 Hi, all This draft proposes to utilize the local status detection on the = sender's side to further reduce bandwidth consumption with SVC codec in = multiparty video conferencing use-cases. A couple of both functionality and API requirements for the browser are = also discussed. Your comments are welcome. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B47=E6=9C=8810=E6=97=A5 = 3:28 =E6=94=B6=E4=BB=B6=E4=BA=BA: denglingli@chinamobile.com =E6=8A=84=E9=80=81: pengjin@chinamobile.com =E4=B8=BB=E9=A2=98: New Version Notification for = draft-deng-rtcweb-svccontrol-00.txt A new version of I-D, draft-deng-rtcweb-svccontrol-00.txt has been successfully submitted by Lingli Deng and posted to the IETF repository. Filename: draft-deng-rtcweb-svccontrol Revision: 00 Title: Sender Media Control based on Local Status Detection Creation date: 2012-07-08 WG ID: Individual Submission Number of pages: 14 URL: = http://www.ietf.org/internet-drafts/draft-deng-rtcweb-svccontrol-00.txt Status: = http://datatracker.ietf.org/doc/draft-deng-rtcweb-svccontrol Htmlized: = http://tools.ietf.org/html/draft-deng-rtcweb-svccontrol-00 Abstract: This document proposes to add sender media control based on local status detection by the browser, to further reduce multiparty = video conferencing's media bandwidth consumption with SVC codec for = RTCWEB use-cases. = =20 The IETF Secretariat From richard.ejzak@alcatel-lucent.com Mon Jul 9 20:17:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C18511E810A; Mon, 9 Jul 2012 20:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.819 X-Spam-Level: X-Spam-Status: No, score=-9.819 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zWMfyd9HPi4; Mon, 9 Jul 2012 20:17:25 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2041911E80F1; Mon, 9 Jul 2012 20:17:24 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6A3HnHq029685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Jul 2012 05:17:49 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 10 Jul 2012 05:17:49 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.33]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 9 Jul 2012 23:17:46 -0400 From: "Ejzak, Richard P (Richard)" To: "avt@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [AVTCORE][rtcweb] FYI: draft-ejzak-avtcore-rtp-subsessions-01 Thread-Index: Ac1eSpM99L5ReD5oSv+kGr/LQPeceQ== Date: Tue, 10 Jul 2012 03:17:46 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F17708794@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [rtcweb] [AVTCORE] FYI: draft-ejzak-avtcore-rtp-subsessions-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 03:17:26 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please note that I submitted an 01 version of the RTP subsessions draft. T= his draft is revised extensively from 00 to focus on how it can enhance BUN= DLE to enable a network to identify multiplexed flows for differential trea= tment and how it can be used in relay topologies. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 09, 2012 10:09 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 1.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-01.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 01 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-07-10 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ejzak-avtcore-rt= p-subsessions-01.txt Status: http://datatracker.ietf.org/doc/draft-ejzak-avtcore-rtp-su= bsessions Htmlized: http://tools.ietf.org/html/draft-ejzak-avtcore-rtp-subsess= ions-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ejzak-avtcore-r= tp-subsessions-01 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and a means of representing this multiplexing option in SDP so that network nodes can easily identify groups of RTP streams and their associated RTCP packets for differential treatment as necessary. This mechanism can be used to complement the BUNDLE multiplexing scheme, which uses the grouping framework to identify all media lines associated with a single transport connection, but provides no means for network nodes to group RTP streams and their RTCP packets for differential treatment. RTP subsessions is an alternative to the SHIM multiplexing proposal; it clearly partitions packets associated with different media lines without changing the format of individual RTP and RTCP packets, but it does not maintain a completely independent SSRC space for each media line, as does SHIM. RTP subsessions avoid SSRC conflicts by construction and can be used in all RTP topologies in which all systems implement RTP subsessions, although SSRC mapping might be needed when forwarding RTP streams from an unpartitioned RTP session into an RTP subsession. The IETF Secretariat --_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please note that I submitted an 01 version of the RTP subsessions d= raft.  This draft is revised extensively from 00 to focus on how it ca= n enhance BUNDLE to enable a network to identify multiplexed flows for differential treatment and how i= t can be used in relay topologies.

 

Richard

 

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 09, 2012 10:09 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 1.txt

 

 

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-01.txt

has been successfully submitted by Richard Ejzak and posted to the<= o:p>

IETF repository.

 

Filename:   draft-ejzak-avtcore-rtp-subsessions

Revision:   01

Title:          &= nbsp; Media multiplexing with Real-time Transport Protocol (RTP) subsession= s

Creation date:    2012-07-10

WG ID:          &= nbsp; Individual Submission

Number of pages: 14

URL:          &nb= sp;  http://www.ietf.org/internet-drafts/draft-ejzak-avtcore-rtp-subse= ssions-01.txt

Status:          http:= //datatracker.ietf.org/doc/draft-ejzak-avtcore-rtp-subsessions

Htmlized:        http://tools.ie= tf.org/html/draft-ejzak-avtcore-rtp-subsessions-01=

Diff:          &n= bsp; http://tools.ietf.org/rfcdiff?url2=3Ddraft-ejzak-avtcore-rtp-subsessio= ns-01

 

Abstract:

   This document describes a means of multiplexing RTP st= reams having

   different media types within a single transport connec= tion and a

   means of representing this multiplexing option in SDP = so that network

   nodes can easily identify groups of RTP streams and th= eir associated

   RTCP packets for differential treatment as necessary.&= nbsp; This mechanism

   can be used to complement the BUNDLE multiplexing sche= me, which uses

   the grouping framework to identify all media lines ass= ociated with a

   single transport connection, but provides no means for= network nodes

   to group RTP streams and their RTCP packets for differ= ential

   treatment.  RTP subsessions is an alternative to = the SHIM

   multiplexing proposal; it clearly partitions packets a= ssociated with

   different media lines without changing the format of i= ndividual RTP

   and RTCP packets, but it does not maintain a completel= y independent

   SSRC space for each media line, as does SHIM.  RT= P subsessions avoid

   SSRC conflicts by construction and can be used in all = RTP topologies

   in which all systems implement RTP subsessions, althou= gh SSRC mapping

   might be needed when forwarding RTP streams from an un= partitioned RTP

   session into an RTP subsession.

 

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       

 

 

The IETF Secretariat

 

--_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_-- From lishitao@huawei.com Tue Jul 10 00:28:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1C421F8668 for ; Tue, 10 Jul 2012 00:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=4.604, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+s2No51wFsl for ; Tue, 10 Jul 2012 00:28:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 18ABF21F8661 for ; Tue, 10 Jul 2012 00:28:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHP83926; Tue, 10 Jul 2012 03:28:36 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 00:25:35 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 00:25:34 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 15:25:27 +0800 From: Lishitao To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-li-rtcweb-ice-page-reload-00.txt Thread-Index: AQHNWxrtVDL8FUnIUk+wHn064szvTZciIj/Q Date: Tue, 10 Jul 2012 07:25:26 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] FW: New Version Notification for draft-li-rtcweb-ice-page-reload-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 07:28:09 -0000 SGkgYWxsDQogDQpUaGUgSlNFUCBkcmFmdCBtZW50aW9uZWQgdGhlIHJlaHlkcmF0aW9uIHNjZW5h cmlvLCBidXQgb25seSB1c2luZyBJQ0UgcmVzdGFydCB0byByZWVzdGFibGlzaCB0aGUgc2Vzc2lv biwgYmFzZWQgb24gcHJldmlvdXMgZGlzY3Vzc2lvbiwgdXNpbmcgYW4gZXhpc3RpbmcgSUNFIGNh bmRpZGF0ZSB0byByZXN1bWUgdHJhbnNtaXNzaW9uIGFmdGVyIHBhZ2UgcmVsb2FkIHNob3VsZCBi ZSBjb25zaWRlcmVkIGFzIG9uZSBvZiB0aGUgcG9zc2liaWxpdGllcy4gU28sIHRoaXMgZHJhZnQg dHJpZXMgdG8gYW5hbHl6ZSB0aGUgcG9zc2liaWxpdHkgdG8gcmV1c2UgdGhlIHByZXZpb3VzIElD RSBjYW5kaWRhdGUgdG8gcmVlc3RhYmxpc2ggdGhlIHNlc3Npb24gYWZ0ZXIgYSBwYWdlIHJlbG9h ZC4NCg0KIA0KUmVnYXJkcw0Kc2hpdGFvDQoNCg0KDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bp l7Q6IDIwMTLlubQ35pyINuaXpSA5OjU5DQrmlLbku7bkuro6IExpc2hpdGFvDQrkuLvpopg6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktcnRjd2ViLWljZS1wYWdlLXJlbG9h ZC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktcnRjd2ViLWljZS1w YWdlLXJlbG9hZC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2hp dGFvIExpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkg ZHJhZnQtbGktcnRjd2ViLWljZS1wYWdlLXJlbG9hZA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkg SUNFIG5lZ290aWF0aW9uIHdoZW4gcGFnZSByZWxvYWQgaW4gcnRjd2ViDQpDcmVhdGlvbiBkYXRl OgkgMjAxMi0wNy0wNg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtbGktcnRjd2ViLWljZS1wYWdlLXJlbG9hZC0wMC50eHQNClN0YXR1czogICAg ICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1ydGN3ZWItaWNl LXBhZ2UtcmVsb2FkDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWxpLXJ0Y3dlYi1pY2UtcGFnZS1yZWxvYWQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIElu dGVyYWN0aXZpdHkgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElDRSkgaGFzIGJlZW4gY2hv c2VuIGluDQogICBydGN3ZWIgZm9yIE5BVCB0cmFuc2Zlci4gIFRoaXMgbWVtbyBwcm92aWRlcyBz b21lIGFuYWx5c2lzIGFuZA0KICAgc3VnZ2VzdGlvbnMgYWJvdXQgSUNFIHJlLW5lZ290aWF0aW9u IHdoZW4gYSBwYWdlIHJlbG9hZCBoYXBwZW5lZC4NCg0KTm90ZQ0KDQogICBEaXNjdXNzaW9uIGFu ZCBzdWdnZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnQgYXJlIHJlcXVlc3RlZCwgYW5kIHNob3VsZA0K ICAgYmUgc2VudCB0byBydGN3ZWJAaWV0Zi5vcmcuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From stefan.lk.hakansson@ericsson.com Tue Jul 10 01:11:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8721F85C9 for ; Tue, 10 Jul 2012 01:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96o3EUjrnJ37 for ; Tue, 10 Jul 2012 01:11:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9085E21F8615 for ; Tue, 10 Jul 2012 01:11:27 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-20-4ffbe3c9a3a2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 55.87.15286.9C3EBFF4; Tue, 10 Jul 2012 10:11:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 10 Jul 2012 10:11:53 +0200 Message-ID: <4FFBE3C9.7050302@ericsson.com> Date: Tue, 10 Jul 2012 10:11:53 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre6px7/9DSbNY7NY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGX8er2IseCVQcWzKJ+YGxg28XYycHBICJhIPPrYxQdhiEhfu rWcDsYUETjFKdP2t6mLkArKXM0qcu7eSGSTBK6AtcXfhI3YQm0VAVeLsxyeMIDabgI3E2u4p QIM4OEQFwiSm72SHKBeUODnzCQuILSIgLLH1VS9YibBAuUTTOhOI8VMZJdYcmwA2nlMgUOLR q+NgNzALWEgsfnOQHcKWl2jeOpsZ4jZdiXev77FOYBSYhWTFLCQts5C0LGBkXsUonJuYmZNe bqSXWpSZXFycn6dXnLqJERh8B7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwav0tYZM875bz2bREJSdqcof3Q4uIjB26wjoy5vMFeyR/GpjnrIs4nqr/ NU771OMS1nNqSvOj83dzhnbyM7HofpbMvSyauUC/SOOIZK2U5LKAKnmNi0ucgqrKI6aZHc2J LRZb5iiZcXeV7cFVm3ZNebRpi7nBmwctM1zCF3ifmVPo+bX54RwlluKMREMt5qLiRAA+rqK/ DAIAAA== Subject: Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:11:31 -0000 On 07/06/2012 09:33 AM, Iñaki Baz Castillo wrote: > Hi, I would really appreciate some explanation about this subject. > Basically the aim of my question is to imitate the behavior of > existing chat+audio+video clients in which the session is initially > started with just audio, and video is added later (by asking for user > consent). > > I hope that raw parsing of the received SDP is not needed for achieving this :) The API is designed around MediaStreams and MediaStream tracks. So, for the app receiving a MediaStream that travels from another app using a PeerConnection, any change would (if you do not do SDP parsing!) be shown by events such as "addstream"/"removestream" (for PeerConnection) "addtrack"/"removetrack" (for a MediaStream) and "mute"/"unmute" (for a MediaStream track). Could not these events be used to trigger change at the receiving app (e.g. if the incoming video track changes to "unmute" the outgoing one is enabled in response)? In addition, the app's can signal anything they would like to using proprietary signaling ("I would like to enable video, OK?"). Br, Stefan > > Regards. > > > 2012/7/4 Iñaki Baz Castillo : >> Hi, let's assume I have an established audio session. Later the remote >> sends me a new SDP offer (let's say a SIP re-INVITE) and I want to >> analyze what is new in the new SDP (in order to ask the user for >> consent). So for example when the new SDP arrives I need to know >> whether it contains audio and video or whatever. >> >> With the current JSEP API I see no way. The only I can do with the new >> received SDP is: >> >> pc.setRemoteDescription(SDP_OFFER, REMOTE_SDP_TEXT) >> >> but this would alter my multimedia session before I can ask my user >> for consent. Do I miss something? >> >> And I would also like to know whether the received SDP contains >> dissabled streams (i.e. a video stream with port 0) before accepting >> it. Basically I want a mechanism for getting a diff between the >> existing remote SDP and the new received one. >> >> -- >> Iñaki Baz Castillo >> > > > From ibc@aliax.net Tue Jul 10 03:07:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB1E11E808E for ; Tue, 10 Jul 2012 03:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A00ossT2I6yW for ; Tue, 10 Jul 2012 03:07:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E773C21F8710 for ; Tue, 10 Jul 2012 03:07:10 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so55542lbb.31 for ; Tue, 10 Jul 2012 03:07:37 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=/NfPlJHrD7r8aSdt+U4NSUidJH8PqDPBnLIwzLJhXUA=; b=XDkB+iGAVqzUz6mwxUEipUkfcKn3PJKNpthPSPyQioCzk6X2kYCtXHVHkl6eslPPNc h5q4JeaThT02LnVOjL6WmDecTUT4xEWVOpjHFVuSqwKanhINqZrNJt605HAl7Sg+/6vH eQ+bFBlCVDnZ+T4A8qEQ1rAdg5d8uxtOsYSZ/eWxZ3jH55LhbYu7tkE4f9Zrl/+pLOZx gwbL2nAYHN/wYAYCcehED0sCS3hfll8KKtqY/Nhjziw59O6m0yH2KjkvZdNksQFLYvyO 3P/YQYGkq9ffitks0Js5H4CiirxoU+AKlqn8zM83lFcZUqTqwtYSXNoc5eofvYKWqK96 2GIw== Received: by 10.112.27.226 with SMTP id w2mr20082872lbg.57.1341914857346; Tue, 10 Jul 2012 03:07:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Tue, 10 Jul 2012 03:07:17 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 10 Jul 2012 12:07:17 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnREVIIvx+4Ms4nE6v6RVrhFSy5EDM8S0mpiQ+4khKcxCd7zWmrxoISr3zEtttnppAxEoKt Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:07:12 -0000 2012/7/6 Martin Thomson : > On 6 July 2012 00:33, I=C3=B1aki Baz Castillo wrote: >> I hope that raw parsing of the received SDP is not needed for achieving = this :) > > I'm surprised that you think that. > > I believe that the subject is one of the open issues, though I believe > that the current discussion was heading toward the conclusion that > calling setDescription() on a PeerConnection was the blessed method > for determining what streams are present in an offer or answer. > > Therefore, the process is something like... > > # Take existing session, look at the attached streams (and their tracks). > # Take new offer, create new PeerConnection, attach the same local > streams, call pc.setRemoteDescription(OFFER, sdpOffer), examine the > resulting attached streams (and their tracks). > # Discard the new PeerConnection. > > Of course, this is highly likely to fail because the resources > necessary to create and configure the second PeerConnection are likely > taken by the first. So your best bet is to scrounge through the SDP. > But SDP is awesome, so it's OK. I strongly hope WebRTC API will provide something much better for a simple and usual task like adding video to an audio session with previous user consent. --=20 I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Tue Jul 10 05:11:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4687621F860B for ; Tue, 10 Jul 2012 05:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be9Bgyzeg3S2 for ; Tue, 10 Jul 2012 05:11:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3258E21F85AA for ; Tue, 10 Jul 2012 05:11:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-49-4ffc1c1aca92 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E3.DC.03067.A1C1CFF4; Tue, 10 Jul 2012 14:12:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Tue, 10 Jul 2012 14:12:07 +0200 Message-ID: <4FFC1C17.8090006@ericsson.com> Date: Tue, 10 Jul 2012 14:12:07 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvra6UzB9/g/sdGhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9XqbcwFJ7kr7v5cy97AuIOzi5GTQ0LARGL2nwtsELaYxIV7 64FsLg4hgVOMEgfOXGeCcJYzSnT37AGr4hXQluia3coCYrMIqEr8Wf4QLM4mYCOxtnsKUAMH h6hAmMT0newQ5YISJ2c+ASsXERCW2PqqF6xEWKBcommdCcT4+UwSf77cYwGJcwoEStz9aAJS zixgIbH4zUF2CFteonnrbGYQW0hAV+Ld63usExgFZiHZMAtJyywkLQsYmVcxCucmZuakl5vr pRZlJhcX5+fpFaduYgQG38Etvw12MG66L3aIUZqDRUmcV091v7+QQHpiSWp2ampBalF8UWlO avEhRiYOTqkGRv1Ts7bP3r8qUUrRwuYZk9bp5QnHnnxp/7s0XIsx9rHl9rbuM8s2Hai7pc/J 1mFof6Yn36A9/DprzNYPBScX7xSwPcHjoSWf/EzVvVV6XliP4Z8NR9uKUp8rLK2o+eJaWuPI Gh/LZmx6WHyFRcnR7J9vY544nlN133aU7d7mpBC+k2u1psmvUmIpzkg01GIuKk4EAAgfVucM AgAA Subject: Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 12:11:45 -0000 On 07/10/2012 12:07 PM, Iñaki Baz Castillo wrote: > 2012/7/6 Martin Thomson : >> On 6 July 2012 00:33, Iñaki Baz Castillo wrote: >>> I hope that raw parsing of the received SDP is not needed for achieving this :) >> >> I'm surprised that you think that. >> >> I believe that the subject is one of the open issues, though I believe >> that the current discussion was heading toward the conclusion that >> calling setDescription() on a PeerConnection was the blessed method >> for determining what streams are present in an offer or answer. >> >> Therefore, the process is something like... >> >> # Take existing session, look at the attached streams (and their tracks). >> # Take new offer, create new PeerConnection, attach the same local >> streams, call pc.setRemoteDescription(OFFER, sdpOffer), examine the >> resulting attached streams (and their tracks). >> # Discard the new PeerConnection. >> >> Of course, this is highly likely to fail because the resources >> necessary to create and configure the second PeerConnection are likely >> taken by the first. So your best bet is to scrounge through the SDP. >> But SDP is awesome, so it's OK. > > I strongly hope WebRTC API will provide something much better for a > simple and usual task like adding video to an audio session with > previous user consent. Note my answer at http://www.ietf.org/mail-archive/web/rtcweb/current/msg04859.html > From ekr@rtfm.com Tue Jul 10 05:56:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD4921F86CA for ; Tue, 10 Jul 2012 05:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6mtUIuP17X9 for ; Tue, 10 Jul 2012 05:56:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0971621F86C7 for ; Tue, 10 Jul 2012 05:56:47 -0700 (PDT) Received: by vcqp1 with SMTP id p1so8671208vcq.31 for ; Tue, 10 Jul 2012 05:57:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=97MVO/ZlpM5EARXq/aTWOmX0ghbz3EZrn3aIKqFq1+k=; b=oiTMiZf6H+Hj4WVKorkYR9uKBcXOh9y8H+8Bu1f7RDVE35ejSRgeEGWD9w8P53nlTF Z3odWNOQYJMsrDw+TKFq0UI0z8C2fhEP0I9HyK1vgU7/lJ6tbY4JNnL5nuiPAImMWKPu L5Lv54Yv8C90LLF14bXPC3IGIgqiGAQ50dGB/IF8iZnO+MBAOM/YaxFWGMb7ETlvTXlj rsGvX/+VYZdNvkZTYFyXSi5M54V1WH7pRDyXFAjF8xKZjrQM0GFdUGnB/Hrc86tqZ/Sn DbBw+rKdIejKpaigcq4VXd4tv/SCvisCd9tcvx5l15fJM/1tscY/D/apjjDO9EBfR9E6 bbqg== Received: by 10.52.99.227 with SMTP id et3mr17438675vdb.110.1341925035217; Tue, 10 Jul 2012 05:57:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 10 Jul 2012 05:56:35 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: References: From: Eric Rescorla Date: Tue, 10 Jul 2012 05:56:35 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk76zPaouvJJU2GJY1U34bSgxCKy1/HSoyhQ+XyZlGHDLOEb7pma1XgFBmKqY/rdM2nSG8l Cc: rtcweb@ietf.org Subject: Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 12:56:49 -0000 On Tue, Jul 10, 2012 at 3:07 AM, I=F1aki Baz Castillo wrote= : > 2012/7/6 Martin Thomson : >> On 6 July 2012 00:33, I=F1aki Baz Castillo wrote: >>> I hope that raw parsing of the received SDP is not needed for achieving= this :) >> >> I'm surprised that you think that. >> >> I believe that the subject is one of the open issues, though I believe >> that the current discussion was heading toward the conclusion that >> calling setDescription() on a PeerConnection was the blessed method >> for determining what streams are present in an offer or answer. >> >> Therefore, the process is something like... >> >> # Take existing session, look at the attached streams (and their tracks)= . >> # Take new offer, create new PeerConnection, attach the same local >> streams, call pc.setRemoteDescription(OFFER, sdpOffer), examine the >> resulting attached streams (and their tracks). >> # Discard the new PeerConnection. >> >> Of course, this is highly likely to fail because the resources >> necessary to create and configure the second PeerConnection are likely >> taken by the first. So your best bet is to scrounge through the SDP. >> But SDP is awesome, so it's OK. > > I strongly hope WebRTC API will provide something much better for a > simple and usual task like adding video to an audio session with > previous user consent. Yes. PeerConnection.AddStream() From ted.ietf@gmail.com Tue Jul 10 12:54:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FB411E810F for ; Tue, 10 Jul 2012 12:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v66hzKpjzoun for ; Tue, 10 Jul 2012 12:54:22 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC02111E80FB for ; Tue, 10 Jul 2012 12:54:21 -0700 (PDT) Received: by vcqp1 with SMTP id p1so269458vcq.31 for ; Tue, 10 Jul 2012 12:54:50 -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=Sae+I6KKl80L81ThVp4KFUxQjD++FkN3abqeLDm9oLA=; b=LTiX+nCcWi4oCUTSY0II1p9GgS6bdLw5vDZaxu2U/pTaGCSrJyU3agE5DWxyWpZbT4 4Mn38r4uRKeznBc5PBQcIdGWkNeXA6W/CAbZXduazc/Wdj/2cclbjiWbL2c2B4NSRizw 69rNRlNyYkZnY6kgsR6KxtN47q9nm5SG1rmU+lcXZi9gLe+IqTI3QWbVhUdFLiK2LNdm 9Cblijp24EJ4SOC7YeDWOiBAqU0o7MvDH8lGQZ/WZA0qt3GgJaiDzKi7/H9z9UwN9FbC X1nrxzqs0hhRMRja0pD2gKqIlFyu/+7h4h16NRd5pSamdy9APjFwXOvtw/SwY68wwluq 1gcg== MIME-Version: 1.0 Received: by 10.52.73.42 with SMTP id i10mr18340404vdv.116.1341950090023; Tue, 10 Jul 2012 12:54:50 -0700 (PDT) Received: by 10.52.74.101 with HTTP; Tue, 10 Jul 2012 12:54:49 -0700 (PDT) In-Reply-To: <4FF690BE.5090101@ericsson.com> References: <4FEAFFBA.8020403@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF03603B@MCHP04MSX.global-ad.net> <4FF690BE.5090101@ericsson.com> Date: Tue, 10 Jul 2012 12:54:49 -0700 Message-ID: From: Ted Hardie To: Stefan Hakansson LK Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use-case draft updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:54:26 -0000 On Fri, Jul 6, 2012 at 12:16 AM, Stefan Hakansson LK wrote: >> It might be best to check with the chairs and/or AD's what is the >> best and acceptable wording given the RAVEN policy in RFC2804. > > > Chairs, any input? > > Speaking personally, rather than as chair, I think re-using the language in the RAVEN documents is more effective. It's a known quantity in the IETF. If you feel this needs a chair decision, rather than further discussion in the working group, though, I'll raised the issue with Cullen and Magnus at our meeting this Thursday. Ted From mary.ietf.barnes@gmail.com Tue Jul 10 16:37:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C79011E80A4; Tue, 10 Jul 2012 16:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCt17g5Apjgr; Tue, 10 Jul 2012 16:37:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5811E8087; Tue, 10 Jul 2012 16:37:23 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so649964obb.31 for ; Tue, 10 Jul 2012 16:37:52 -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=2eZAFEs9bEjwxfu6kVYXdKTRFE+RHAuVSMy079j8b/w=; b=kPwEeMxJX5zc/+6mwEa0OZ6umUlKlKFrLLET4PVA0CRANJZuy8fJcjSZmEy+DffeKP 2dmxv7ikOrIi7BA2MLnMNesyr1efQOfW67LqU0EVRQti51Agg27o4xOkvZeGFuGM6Jqi /BKPgmjssuQR5SCKqK4eyxhzW6qCs5V70MCcmU/qJSJkRIHAmAfVaRypb7H6kPpXyLJr AW6UerabPJw+sdKkIa71uqxer8wl4BkaUMjoHlu3/VdsXcvOr5MxsMUwjVJRVpXWUJuo 3LEOe7kmWKHbBRRR60eA/yFKQfhf3Abslm2szVLAlHp/GSo5jOVaKwGfov4Pr/8rPqZi 30lA== MIME-Version: 1.0 Received: by 10.182.14.101 with SMTP id o5mr1569393obc.1.1341963472177; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) Received: by 10.182.147.1 with HTTP; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) Date: Tue, 10 Jul 2012 18:37:52 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org, mmusic@ietf.org, avt@ietf.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=14dae9399bad0f88a204c482380a Subject: [rtcweb] Reminder: "Telepresence Tutorial" @ IETF-84 (Please RSVP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:37:34 -0000 --14dae9399bad0f88a204c482380a Content-Type: text/plain; charset=ISO-8859-1 Hi all, Apologies to the many of you that are receiving this multiple times. Unfortunately, the RAI list is not a superset of participants in WGs that might be interested in this. Folks that aren't on the RAI list might want to subscribe here: https://www.ietf.org/mailman/listinfo/rai Please note the important update below with regards to (no) lunch. We are planning a lunchtime tutorial on Monday, July 30th. The primary objective is to provide more background on telepresence as well as an update of the work in CLUE to the broader RAI and IETF community. This will hopefully facilitate the process of completing the CLUE protocol work as it gets broader community review. Here's the proposed outline: 1) Introduction to telepresence 2) Example telepresence scenarios 3) Introduction to the CLUE work 4) High level introduction of framework 5) One or two use cases as examples of how the CLUE framework is realized - showing how existing protocols (e.g., SDP, RTP) are integral to the solution along with additional signaling for CLUE. We have reserved a room for around 50 and attendance will be FCFS, so please RSVP by Friday, July 13th, 2012 (5pm Pacific) http://www.doodle.com/mzu3nmdeehkxkiys **Important update*: * Please note that we do not have a sponsor for lunch, thus folks will have to grab something before the tutorial (sorry, I tried). However, we will have some cookies and veggies/fruit available so folks will have something to munch. Please send any questions/comments to me (or to the CLUE WG mailing list) rather than reply all. Regards, Mary CLUE WG co-chair --14dae9399bad0f88a204c482380a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Apologies to the many of you that are receiving this multiple times.
Unfortunately, the RAI list is not a superset of participants in WGs
that might be interested in this. =A0Folks that aren't on the RAI list<= br> might want to subscribe here:
htt= ps://www.ietf.org/mailman/listinfo/rai
=
Please note the important update below= with regards to (no) lunch.=A0

We are planning a lunchtime tutorial on Monday, July 30th. =A0The
primary objective is to provide more background on telepresence as
well as an update of the work in CLUE to the broader RAI and IETF
community. =A0This will hopefully facilitate the process of completing
the CLUE protocol work as it gets broader community review.

Here's the proposed outline:
1) Introduction to telepresence
2) Example telepresence scenarios
3) Introduction to the CLUE work
4) High level introduction of framework
5) One or two use cases as examples of how the CLUE framework is
realized - showing how existing protocols (e.g., SDP, RTP) are
integral to the solution along
with additional signaling for CLUE.

We have reserved a room for around 50 and attendance will be FCFS, so =A0pl= ease RSVP by=A0Friday, July 13th, 2012 (5pm Pacific)
http:/= /www.doodle.com/mzu3nmdeehkxkiys

*Important update*: =A0Please note that we do not have = a sponsor for lunch, thus folks will have to grab something before the tuto= rial (sorry, I tried). =A0However, we will have some cookies and veggies/fr= uit available so folks will have something to munch.=A0

Please send any questions/comments to me (or to the CLUE WG mai= ling=A0list) =A0rather than reply all.

Regards,
Mary
CLUE WG co-chair

--14dae9399bad0f88a204c482380a-- From g.kiranreddy4u@gmail.com Tue Jul 10 20:49:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C552421F854E for ; Tue, 10 Jul 2012 20:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpj4w3qmQ68e for ; Tue, 10 Jul 2012 20:49:51 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id EACC521F853E for ; Tue, 10 Jul 2012 20:49:50 -0700 (PDT) Received: by yhfs35 with SMTP id s35so1075537yhf.27 for ; Tue, 10 Jul 2012 20:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R7JwrVar/PVWgO22zf3xoupEep5LPylLgj7C1qZMcIU=; b=GNGycJhWB2WkTpHNmTwNNNLbuzNuD8Dgtb45OmmJHD11GBB7ee67BmreUH9FKcMWwf AAKgALlQpCFRrDtD5ePh6tWA15wL7SJpuQasNHS/s1yq1alx6SLi9fHkA0Yamb5mUEZQ 5mNQSb8nUtCh9NIhO6TmNf+zYI0QYmVa61Qxb11IaB69IrvyZQidbRD6q79aTYbDFDSb WVKiJ2EjQ9hU1V5I7uXNhzIWsM7rCDhOj3PcEW9eTfYRC7M4bQiVZOTbgKB3Uzf+7k/S sXKBn4XC6lqNqtVby+0fgfJCpqVbJlun4CFsYu22TiQ31HS0qHJ8iUS7Kdz+W0JKdfLK pyww== Received: by 10.50.183.200 with SMTP id eo8mr13453813igc.63.1341978619967; Tue, 10 Jul 2012 20:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.47.195 with HTTP; Tue, 10 Jul 2012 20:49:59 -0700 (PDT) In-Reply-To: References: From: kiran kumar Date: Wed, 11 Jul 2012 09:19:59 +0530 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=14dae9340435f07a7404c485be87 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] rtcweb Digest, Vol 17, Issue 21 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 03:49:51 -0000 --14dae9340435f07a7404c485be87 Content-Type: text/plain; charset=ISO-8859-1 Hi Castillo, PeerConnection.AdStream() is for appending the media streams. Then from where the user permission is requested? IMO this scenario should be implemented in two steps, where 1) The browser has to check for the required resources. 2) If the resources are prasent, then it has to invoke a request to the user for permission. Also if the the user has opted for that upgradation (prior to recieving the offer, through some UI of check box) that information will be stored in the App or backing store. In this scenario message box for requesting permission is not required. In order to implement this, addStream() should call a callBack() to the application on finding the resources availability. If the same function is able to return the "allowedPermission" state for adding the extra streams, then it can add those streams, otherwise application can send the corresponding error response regarding the resource unavailability or user permission denied. Thanks, Kiran. >>> I hope that raw parsing of the received SDP is not needed for achieving this :) >> >> I'm surprised that you think that. >> >> I believe that the subject is one of the open issues, though I believe >> that the current discussion was heading toward the conclusion that >> calling setDescription() on a PeerConnection was the blessed method >> for determining what streams are present in an offer or answer. >> >> Therefore, the process is something like... >> >> # Take existing session, look at the attached streams (and their tracks). >> # Take new offer, create new PeerConnection, attach the same local >> streams, call pc.setRemoteDescription(OFFER, sdpOffer), examine the >> resulting attached streams (and their tracks). >> # Discard the new PeerConnection. >> >> Of course, this is highly likely to fail because the resources >> necessary to create and configure the second PeerConnection are likely >> taken by the first. So your best bet is to scrounge through the SDP. >> But SDP is awesome, so it's OK. > > I strongly hope WebRTC API will provide something much better for a > simple and usual task like adding video to an audio session with > previous user consent. Yes. PeerConnection.AddStream() _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --14dae9340435f07a7404c485be87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Castillo,
=A0
PeerConnection.AdStream() is for appending the media streams.
Then from where the user permission is requested?
=A0
IMO this scenario should be implemented in two steps, where
1) The browser has to check for the required resources.
2) If the resources are prasent, then it has to invoke a request to th= e user for permission.
=A0
Also if the the user has opted for that upgradation (prior to recievin= g the offer, through some UI of check box) that information will be stored = in the App or backing store. In this scenario message box for requesting pe= rmission is not required.
=A0
In order to implement this, addStream() should=A0call a callBack() to = the application on finding the resources availability. If the same function= is able to return the "allowedPermission" state for adding the e= xtra streams, then it can add those streams, otherwise application can send= the corresponding error response regarding the resource unavailability or = user permission denied.
=A0
Thanks,
Kiran.

>>> I hope that raw parsing of the received SDP is not ne= eded for achieving this :)
>>
>> I'm surprised that y= ou think that.
>>
>> I believe that the subject is one of= the open issues, though I believe
>> that the current discussion was heading toward the conclusion that=
>> calling set<X>Description() on a PeerConnection was the = blessed method
>> for determining what streams are present in an o= ffer or answer.
>>
>> Therefore, the process is something like...
>>= ;
>> # Take existing session, look at the attached streams (and th= eir tracks).
>> # Take new offer, create new PeerConnection, attac= h the same local
>> streams, call pc.setRemoteDescription(OFFER, sdpOffer), examine th= e
>> resulting attached streams (and their tracks).
>> # = Discard the new PeerConnection.
>>
>> Of course, this is = highly likely to fail because the resources
>> necessary to create and configure the second PeerConnection are li= kely
>> taken by the first. =A0So your best bet is to scrounge thr= ough the SDP.
>> But SDP is awesome, so it's OK.
>
> I strongly hope WebRTC API will provide something much better for a> simple and usual task like adding video to an audio session with
&= gt; previous user consent.

Yes. PeerConnection.AddStream()


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


--14dae9340435f07a7404c485be87-- From kevin.gross@avanw.com Mon Jul 9 14:51:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9FF11E8115 for ; Mon, 9 Jul 2012 14:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHAIf9iB6cSj for ; Mon, 9 Jul 2012 14:51:01 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 9B4AF11E80D1 for ; Mon, 9 Jul 2012 14:51:01 -0700 (PDT) Received: (qmail 2613 invoked by uid 0); 9 Jul 2012 21:51:27 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 9 Jul 2012 21:51:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=bZ+tpgDLD/3QAUfrIeWlIcK0F+AhjY6Cyz0uvlCG4N4=; b=ckVbRLFVDTcIeYB9GNcbPJHwbgyZo+mNiqx2G84d1AuYnvl8XPZC9PvGZ0cVt4juas2XvTE7J2F/XWj887308JzS0fmAQSi0x7v2L7OI6o4c6hpFMc0pHUlaz1ATqKWz; Received: from [74.125.82.172] (port=42749 helo=mail-we0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SoLrb-0006Wm-5K; Mon, 09 Jul 2012 15:51:27 -0600 Received: by were53 with SMTP id e53so2497190wer.31 for ; Mon, 09 Jul 2012 14:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.100.133 with SMTP id ey5mr32835834wib.4.1341870684551; Mon, 09 Jul 2012 14:51:24 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Mon, 9 Jul 2012 14:51:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jul 2012 15:51:24 -0600 Message-ID: From: Kevin Gross To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d0444ee277cbb5304c46c9d73 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} X-Mailman-Approved-At: Wed, 11 Jul 2012 00:01:39 -0700 Cc: rtcweb@ietf.org, avt@ietf.org Subject: Re: [rtcweb] [AVTCORE] FYI: draft-rescorla-random-cname-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:51:02 -0000 --f46d0444ee277cbb5304c46c9d73 Content-Type: text/plain; charset=ISO-8859-1 Good start. Please consider referencing to RFC 4086. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, Jul 9, 2012 at 1:24 PM, Eric Rescorla wrote: > As discussed at the RTCWEB interim: > > > Executive summary: use a CSPRNG to generate CNAMEs. > > -Ekr > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --f46d0444ee277cbb5304c46c9d73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good start.

Please consider referencing to RFC 4086.
Kevin Gross
+1-303-447-0517
Media Netw= ork Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Mon, Jul 9, 2012 at 1:24 PM, Eric Res= corla <ekr@rtfm.com> wrote:
As discussed at the RTCWEB interim:


Executive summary: use a CSPRNG to generate CNAMEs.

-Ekr
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--f46d0444ee277cbb5304c46c9d73-- From bernard_aboba@hotmail.com Wed Jul 11 09:13:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9511E8088 for ; Wed, 11 Jul 2012 09:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM4Q8-OULOxJ for ; Wed, 11 Jul 2012 09:13:48 -0700 (PDT) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1F93721F8503 for ; Wed, 11 Jul 2012 09:13:48 -0700 (PDT) Received: from BLU169-W125 ([65.55.116.73]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 09:14:18 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_390684a3-c381-4f60-8b5a-d0f6dd555758_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Date: Wed, 11 Jul 2012 09:14:17 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jul 2012 16:14:18.0045 (UTC) FILETIME=[390146D0:01CD5F80] Subject: [rtcweb] IAB/IRTF Congestion Control Workshop Papers Posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:13:48 -0000 --_390684a3-c381-4f60-8b5a-d0f6dd555758_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The papers submitted to the IAB/IRTF Workshop on =93Congestion Control for Interactive Real-Time Communication=94 have been posted and are =20 available for download here. = --_390684a3-c381-4f60-8b5a-d0f6dd555758_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The papers submitted to the IAB/IRTF Workshop on =93Congestion Control for Interactive Real-Time Communication=94 have been posted and are =3B=20 available for download here. =
= --_390684a3-c381-4f60-8b5a-d0f6dd555758_-- From ted.ietf@gmail.com Wed Jul 11 14:45:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D127121F862A for ; Wed, 11 Jul 2012 14:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2At2NCVP-qd for ; Wed, 11 Jul 2012 14:45:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4721F854E for ; Wed, 11 Jul 2012 14:45:06 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1163140vcq.31 for ; Wed, 11 Jul 2012 14:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=waXIsowVbBpFAT8iuxQMgvmlnMI9l8anrUm054Z/VyM=; b=P5orKRUG6ChPCx92pE3q2nuH3ukw7MXODCPj8y4budTe0EmyxSdt7+/G8hcKs4TLuy iSOHMF1FCnEErd/X7LvLdLqupGJVmNNErktg79EPYlHuFGxjXujmjMQPNfcsipAHSfBd gLLNwq+Xe9bpie3cSocrnLIIYBB8jz8WqnGPXoqm/2q6MeEzw7EkXUC05wKnySZuDw78 aT3thuF9ga7fMyKO/9MdnAc4v86WThHpvS/8Y5PbxjrxW59hkh/mwJDM20eYLnhqX1pj dnwjVjZSaFCNF84g1d5aReJohpTN/JObdNSIxnhP1DgP9kNju+dA9Il7zu6UWHgzJi8s E61A== MIME-Version: 1.0 Received: by 10.220.107.198 with SMTP id c6mr24159640vcp.54.1342043137922; Wed, 11 Jul 2012 14:45:37 -0700 (PDT) Received: by 10.52.74.101 with HTTP; Wed, 11 Jul 2012 14:45:37 -0700 (PDT) In-Reply-To: <20120706211533.3449.10225.idtracker@ietfa.amsl.com> References: <20120706211533.3449.10225.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 14:45:37 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Fwd: NomCom 2012-13 Call for Volunteers X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 21:45:08 -0000 If you are eligible to serve on the Nomcom, please consider responding to this call for volunteers. regards, Ted ---------- Forwarded message ---------- From: NomCom Chair Date: Fri, Jul 6, 2012 at 2:15 PM Subject: NomCom 2012-13 Call for Volunteers To: IETF Announcement List The IETF nominating committee process for 2012-13 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The list of people whose terms end with the March 2013 IETF meeting, and thus the positions for which the nominating committee is responsible for filling, are as follows: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (General Area) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you, Matthew Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org From fluffy@iii.ca Wed Jul 11 21:31:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987F611E80DE for ; Wed, 11 Jul 2012 21:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGsd6ev+IH4D for ; Wed, 11 Jul 2012 21:31:11 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AFE5811E80A4 for ; Wed, 11 Jul 2012 21:31:11 -0700 (PDT) Received: from sjc-vpn7-950.cisco.com (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 A3DEF22E257; Thu, 12 Jul 2012 00:31:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4FF693EE.8030905@ericsson.com> Date: Wed, 11 Jul 2012 21:31:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DACB02C-1828-40E9-9500-2D528B0E2BFB@iii.ca> References: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> <4FF693EE.8030905@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 04:31:12 -0000 On Jul 6, 2012, at 24:29 , Magnus Westerlund wrote: > The last part points to that we have 2 or 3 (depending on how you see > DTLS-SRTP) users of the datagram transport flow. As co-author of one = of > those documents I would like to have a single point to reference. Why does your document need a reference to something that says if we = have a UDP over HTTP mechanism or not? I'm worried that we are creating = some ugly interdependencies in the layering that are not needed.=20 I agree work is needed in MMUSIC for trickle ICE, but I'm still not = seeing the rest of this.=20 Obviously doing a UDP over HTTP or doing a TURN that looks like HTTP = thing would need a spec. That will be highly controversial at IETF given = it is fundamentally about doing something through a firewall that = directly go against the wishes of the firewall administrator.=20 From christer.holmberg@ericsson.com Thu Jul 12 01:37:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196921F8782 for ; Thu, 12 Jul 2012 01:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5hCy4hIM3wB for ; Thu, 12 Jul 2012 01:37:51 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 08D7B21F8780 for ; Thu, 12 Jul 2012 01:37:50 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-3d-4ffe8cfe5199 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A4.E7.03067.EFC8EFF4; Thu, 12 Jul 2012 10:38:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.100]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 12 Jul 2012 10:38:22 +0200 From: Christer Holmberg To: Cullen Jennings , Magnus Westerlund Date: Thu, 12 Jul 2012 10:36:54 +0200 Thread-Topic: [rtcweb] Where to specify ICE usage and the common transport Thread-Index: Ac1f50DBCFytgzVzRSq5Ltjy2qI3dQAIj2Ds Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340711681C@ESESSCMS0356.eemea.ericsson.se> References: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> <4FF693EE.8030905@ericsson.com>, <4DACB02C-1828-40E9-9500-2D528B0E2BFB@iii.ca> In-Reply-To: <4DACB02C-1828-40E9-9500-2D528B0E2BFB@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre6/nn/+Br8mGFh8WP+D0WLtv3Z2 ByaPJUt+MnlcPv+RMYApissmJTUnsyy1SN8ugSvjwt9djAVt3BVTl59lb2D8w9HFyMkhIWAi sef6enYIW0ziwr31bF2MXBxCAqcYJS4+u8UK4SxklHi46Q9zFyMHB5uAhUT3P22QBhGBSImv S+awgdjMAuoSdxafAxvEIqAq0bDnBROILSzgKTF3/zF2iHovidNnbzOBjBERMJLoWqMCEuYV CJeYuvgCO8SqXiaJi4c+gs3kFLCS+Lz+ACuIzQh03PdTa5ggdolL3HoynwniaAGJJXvOM0PY ohIvH/+DqheVuNO+nhGiXkdiwe5PUHdqSyxb+JoZYrGgxMmZT1gmMIrNQjJ2FpKWWUhaZiFp WcDIsopRODcxMye93FwvtSgzubg4P0+vOHUTIzB2Dm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwNmgryyia2UlOMrvx7efVT5Hpi2ekHj6V0yp260Sq dmKsQ9qKVYb60nPNlPPXLuFy1ogwjnuWrb6b+0v9C55gxyUP535w/dawbYUx98scjkRpFq/+ I47vRdb0ZTVeerJNqnurf+2OqtP7VzoesNyubVLOqK838aqta2r8ek8Xrinztlwr0gtVYinO SDTUYi4qTgQAWeIh2GsCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 08:37:52 -0000 Hi, BUNDLE is going to contain some ICE text, related to multiplexing. Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Cullen= Jennings [fluffy@iii.ca] Sent: Thursday, July 12, 2012 7:31 AM To: Magnus Westerlund Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Where to specify ICE usage and the common transport On Jul 6, 2012, at 24:29 , Magnus Westerlund wrote: > The last part points to that we have 2 or 3 (depending on how you see > DTLS-SRTP) users of the datagram transport flow. As co-author of one of > those documents I would like to have a single point to reference. Why does your document need a reference to something that says if we have a= UDP over HTTP mechanism or not? I'm worried that we are creating some ugly= interdependencies in the layering that are not needed. I agree work is needed in MMUSIC for trickle ICE, but I'm still not seeing = the rest of this. Obviously doing a UDP over HTTP or doing a TURN that looks like HTTP thing = would need a spec. That will be highly controversial at IETF given it is fu= ndamentally about doing something through a firewall that directly go again= st the wishes of the firewall administrator. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From lorenzo@meetecho.com Thu Jul 12 02:22:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B428721F875A for ; Thu, 12 Jul 2012 02:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzRC5hdILd2U for ; Thu, 12 Jul 2012 02:22:19 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out2.aruba.it [62.149.158.22]) by ietfa.amsl.com (Postfix) with SMTP id 837D321F87C9 for ; Thu, 12 Jul 2012 02:22:18 -0700 (PDT) Received: (qmail 3607 invoked by uid 89); 12 Jul 2012 09:22:48 -0000 Received: from unknown (HELO smtp6.aruba.it) (62.149.158.226) by smtplq04.aruba.it with SMTP; 12 Jul 2012 09:22:48 -0000 Received: (qmail 15233 invoked by uid 89); 12 Jul 2012 09:22:48 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp6.ad.aruba.it with SMTP; 12 Jul 2012 09:22:48 -0000 Date: Thu, 12 Jul 2012 11:22:39 +0200 From: Lorenzo Miniero To: Cullen Jennings Message-ID: <20120712112239.7a4aba26@lminiero-acer> In-Reply-To: <4DACB02C-1828-40E9-9500-2D528B0E2BFB@iii.ca> References: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> <4FF693EE.8030905@ericsson.com> <4DACB02C-1828-40E9-9500-2D528B0E2BFB@iii.ca> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp6.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 09:22:19 -0000 Il giorno Wed, 11 Jul 2012 21:31:32 -0700 Cullen Jennings ha scritto: > > On Jul 6, 2012, at 24:29 , Magnus Westerlund wrote: > > > The last part points to that we have 2 or 3 (depending on how you > > see DTLS-SRTP) users of the datagram transport flow. As co-author > > of one of those documents I would like to have a single point to > > reference. > > Why does your document need a reference to something that says if we > have a UDP over HTTP mechanism or not? I'm worried that we are > creating some ugly interdependencies in the layering that are not > needed. > > I agree work is needed in MMUSIC for trickle ICE, but I'm still not > seeing the rest of this. > > Obviously doing a UDP over HTTP or doing a TURN that looks like HTTP > thing would need a spec. That will be highly controversial at IETF > given it is fundamentally about doing something through a firewall > that directly go against the wishes of the firewall administrator. > Not necessarily: the spec may involve some stuff to allow network/firewall administrators to tell if that's RTP over HTTP or not. It doesn't have to be sneaky. L. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From magnus.westerlund@ericsson.com Thu Jul 12 03:01:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B737921F87CF for ; Thu, 12 Jul 2012 03:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmgzpNUi+3Za for ; Thu, 12 Jul 2012 03:01:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA721F87CB for ; Thu, 12 Jul 2012 03:01:51 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-69-4ffea0af6797 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.F5.15286.FA0AEFF4; Thu, 12 Jul 2012 12:02:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Thu, 12 Jul 2012 12:02:22 +0200 Message-ID: <4FFEA0AD.2070906@ericsson.com> Date: Thu, 12 Jul 2012 12:02:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Cullen Jennings References: <9254B5E6361B1648AFC00BA447E6E8C32AEB70A0@szxeml545-mbx.china.huawei.com> <4FF693EE.8030905@ericsson.com> <4DACB02C-1828-40E9-9500-2D528B0E2BFB@iii.ca> In-Reply-To: <4DACB02C-1828-40E9-9500-2D528B0E2BFB@iii.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvre76Bf/8Ddb9E7d48vgHu8WH9T8Y Ldb+a2d3YPZoOfKW1WPJkp9MHpfPf2QMYI7isklJzcksSy3St0vgynjR0sFWsJy34t+7V2wN jA+5uhg5OCQETCR6eiK6GDmBTDGJC/fWs3UxcnEICZxilHi/cDYLhLOcUWL7/1+MIFW8AtoS C+edZAOxWQRUJRoXHwWLswlYSNz80QgWFxUIlpg2/R47RL2gxMmZT1hAbBEBZYlzO+4ygyxm FgiSOLjMt4uRnUNYwEvivRfEpnYmiecvToB1cgpYSXxef4AV4jZJiXvtq8GmMwvoSUy52sII YctLNG+dzQxiCwFd1tDUwTqBUWgWksWzkLTMQtKygJF5FaNwbmJmTnq5kV5qUWZycXF+nl5x 6iZGYEgf3PJbdQfjnXMihxilOViUxHmtt+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAo te/Mld2XE9P2Ofb8+JRcVRu9fhq/wrFMhf5VB179PCd1d0rle+duGWnpRdu3vDzDxGS96dSn kmRO/kNsDbcta5wLtu1TPnA5szupbd6SWT8b7iqLvl5y3jxn098pc0qKXxhV3o2WneFhfDPg e2jjz/77u+sEM5g7fnJbLTYJUFzv5jC/ovGcEktxRqKhFnNRcSIAXIxUkTcCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Where to specify ICE usage and the common transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 10:01:54 -0000 On 2012-07-12 06:31, Cullen Jennings wrote: > > On Jul 6, 2012, at 24:29 , Magnus Westerlund wrote: > >> The last part points to that we have 2 or 3 (depending on how you >> see DTLS-SRTP) users of the datagram transport flow. As co-author >> of one of those documents I would like to have a single point to >> reference. > > Why does your document need a reference to something that says if we > have a UDP over HTTP mechanism or not? I'm worried that we are > creating some ugly interdependencies in the layering that are not > needed. I want to have something to reference that defines the datagram transport the RTP uses. Independently if the actual datagrams are direct ICE establish path or over any variety or combination of relays over HTTP or not. I personally think we do need something that sufficiently describing and normatively specifying the datagram transport that both RTP and DTLS/SCTP uses. This is after all usage of ICE, likely variant. The requirement to support STUN and some TURN version. The requirement to handle a varaint of the demultiplexing that DTLS-SRTP discusses due to the simultanous occurrance of STUN, RTP and DTLS packets at the same level in the stack. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 jmce.ietf@rogers.com Thu Jul 12 12:57:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D50921F86A5 for ; Thu, 12 Jul 2012 12:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ8hA1jVbzeR for ; Thu, 12 Jul 2012 12:57:10 -0700 (PDT) Received: from nm33-vm5.bullet.mail.bf1.yahoo.com (nm33-vm5.bullet.mail.bf1.yahoo.com [72.30.239.205]) by ietfa.amsl.com (Postfix) with SMTP id E8EA821F86A4 for ; Thu, 12 Jul 2012 12:57:09 -0700 (PDT) Received: from [98.139.215.141] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2012 19:57:43 -0000 Received: from [209.191.108.96] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2012 19:57:43 -0000 Received: from [66.94.237.120] by t3.bullet.mud.yahoo.com with NNFMP; 12 Jul 2012 19:57:43 -0000 Received: from [127.0.0.1] by omp1025.access.mail.mud.yahoo.com with NNFMP; 12 Jul 2012 19:57:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 294035.99118.bm@omp1025.access.mail.mud.yahoo.com Received: (qmail 4917 invoked by uid 60001); 12 Jul 2012 19:57:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1342123062; bh=Spew0hKAGcjT+BBR7F7YX06M2xSdTS27jFTjpdgE42s=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XBDB4M5NLo/Nk2TjvVKCYT4PUeEfZ7HMIdXXzljRo7yRGdunh4V7yxkz/Ww4p4LGAppommv18iUautA6maxlivPJhWFEuPfMq2X75fdO5Jrz4/uKHs9Rb7yP0z1eO3pCmjS+cGhjNq9tu2VqOVWaV19ce2ef45jiUd+W6Y0xy9M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pdSXEKVMgPAfXsQ+GgyHbHYMordU2Ii6+G9JMdIQr33a7qwsxN95bA9pxYFf9QiWWgX9dfwBgF7Cm3toZcWvNwAnzH49I8dbYRM4So1yRqFXsDYoVgdgFHLkm4S/GiLT+cF9mhyd8FQCUgx2wTQgmrcoUBI0fz8m7mj/yo3dbE4=; X-YMail-OSG: 4DwsVhcVM1nPHU9U_8kDOsRgAHtN6CphOebUdA.NlNs.LZO tkTBXwn0BkBDYdnOfzy923F1vpr7FwAvuckCyjmLNaOC30fKFq81fNShOYS0 vljMDldsU3OZ5THV3XYADJUf4Gxle2dm6wg31XsDWI95bBPorzjaSuN4kONz 9BfbwMGWNh5nn3jGvct9m_CMf0K18XAKiTA3VFqA0Yy6B406qENtR.OMsdcR 8UMWTNMLQznuO1LOC27Fc3M8h05yYhlvePk.1EfKsenoL.Ft71oCwTbv4xrO MHdk7x9V8D6BuNnoRc6TtVGob57LeENa17oOC_sEGeS.X.O.lKIME80jaYwD T_Z4E7WKstEGbNPBSSp8vaTLoUwQkBk7oi2fDtnjapv3mm2XjdqKPDvxXbe9 yhEYtPqn8NhGYdUCZfG0i.FHnE70HSoEH5U83nGadaI1R0E.nF_Yocg-- Received: from [99.240.70.9] by web88602.mail.bf1.yahoo.com via HTTP; Thu, 12 Jul 2012 12:57:42 PDT X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1342123062.4892.YahooMailNeo@web88602.mail.bf1.yahoo.com> Date: Thu, 12 Jul 2012 12:57:42 -0700 (PDT) From: Jim McEachern To: "rtcweb@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [rtcweb] Detailed Review of draft-ietf-rtcweb-security-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jim McEachern List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:57:11 -0000 I agreed to provide a detailed review of the security drafts before Vancouv= er. Here are my comments on draft-ietf-rtcweb-security-03.=0A=0ASection=0A3= : the browser threat model. One of the key concepts that I took from the di= scussion on the mailing list was the idea that in the standard Web threat m= odel, when you download malicious code you mainly hurt yourself. I know thi= s is not completely true, but with WebRTC, malicious code can do significan= tly more harm to others by sending real time media to them. Some requiremen= ts, like user consent, follow explicitly from this.=C2=A0 This idea does no= t seem to be discussed at all in the threat model, though later sections (e= .g. section 4.2) discuss the requirements that follow from this. If you agr= ee that it would be worth articulating this idea explicitly, I am willing t= o propose draft text for this section - let me know.=0A=C2=A0=0ASection=0A3= .0: says "Thus, when analyzing HTTP connections, we must assume that=0Atraf= fic is going to the attacker.". Should this be "... going to /=0Acoming fro= m the attacker"? =0A=C2=A0=0ASection=0A4.1: says "without some access restr= ictions on local devices,=0A...". This makes it sound like the restrictions= are being applied to the=0Alocal devices rather than restrictions being ap= plied to the ability of the=0AWS/JS to access resources on the local device= s.=0A=C2=A0=0A=C2=A0Section 4.1 final paragraph.=C2=A0 Says: "By contrast, = consent to send=0Anetwork traffic is about preventing the user=E2=80=99s=0A= browser from being used to attack its local network."=0AWhy the mention of = "its local network". Don't we want to stop all attacks?=0A=0A=C2=A0=0ASecti= on=0A4.1.2 starts: " Now that we have seen another use case, ...". Might=0A= make more sense to start with "The use cases outlined in section 4.1.1 allo= w us to start reasoning about security requirements." =0A=C2=A0=0ANit: Sect= ion=0A4.1.2 second paragraph - instead of "this creates" use=0A"this would = create"=0A=C2=A0=0ASection=0A4.1.2:"Individual=0AConsent-=C2=A0 Ask the use= r for permission for each=0Acall."=0A=C2=A0=0AThe word=0A"individual" has m= ultiple meanings - e.g. the individual person, rather than the individual c= all. It might be less ambiguous to=0Acall this category "per-use" or "per-c= all" consent.=0A=C2=A0=0ASection=0A4.1.2: second last paragraph has the fol= lowing sentence:=0A"Callee-oriented=0Aconsent provided by the calling site = notwork well because a malicious site can claim=0Athat the user is callinga= ny user of his choice."=0A=C2=A0=0AThis=0Asentence need a word before "not"= - perhaps "does" not or=0A"will" not.=0A=C2=A0=0ASection=0A4.2: is it wort= h stating explicitly that it is the browser that must enforce the=0Arequire= ment to not send traffic, other than the consent handshake, until the=0Atar= get has explicitly consented?=0A=C2=A0=0A4.2.1.=0AICE=0AThe first=0Aparagra= ph uses the term "site" for most of the paragraph, but near the=0Aend refer= s to the "Web application". I believe that using the term=0A"Web applicatio= n" throughout the paragraph (instead of "site) would make the meaning=0Amuc= h clearer.=C2=A0 If you agree, then the change will also have to be applied= to some of the following paragraphs.=0A=0A=C2=A0=0AThe next=0Aparagraph sa= ys " Obviously, some ICE-based mechanism will work here, but=0Ait has been = observed that because ICE keepalives are indications, they will not=0Awork = here, so some other mechanism is needed."=C2=A0 This seems to be saying tha= t ICE will work,=0Abut it won't work...=C2=A0 Perhaps this could=0Abe rewor= ded to get something like this: =0A"Obviously,=0AICE-based mechanisms could= be used to indicate a degree of continuing consent,=0Abut it has been obse= rved that because ICE keepalives are indications, they will=0Anot provide t= he necessary level of explicit consent required here, so some=0Aother mecha= nism is needed."=0A=C2=A0=0ASection=0A4.2.3 Backward Compatibility: the fir= st paragraph includes this sentence...=0A"The=0Amessage/reply pair must be = generated in such a way that an=0A=C2=A0=C2=A0 attacker who controls the We= b application=0Acannot forge them,=0A=C2=A0=C2=A0 generally by having the m= essage contain some=0Asecret value that must=0A=C2=A0=C2=A0 be incorporated= ..."=0A=C2=A0=0AThe=0Aintent would be clearer if this read "... some secret= value, known only to=0Athe browsers, that must be incorporated..."=0A=C2= =A0=0ANit: Second=0Abullet is:=0A- Use or=0ARTCP as an implicit reachabilit= y check.=0AShould=0Athis be "Use of RTCP..." - i.e. change "or" to "of".=0A= =0A=C2=A0=0AThird=0Aparagraph, describing the STUN approach, is confusing, = although the next=0Aparagraph mostly clarifies. It might be clearer if you = deleted the last two=0Asentences of the third paragraph, and merged it with= the fourth.=C2=A0 This would give you:=0A=C2=A0=0AIn the=0ASTUN approach, = the RTC-Web endpoint is able to verify that the=0A=C2=A0=C2=A0 recipient is= running some kind of STUN=0Aendpoint but unless the STUN=0A=C2=A0=C2=A0 re= sponder is integrated with the ICE=0Ausername/password establishment=0A=C2= =A0=C2=A0 system, the RTC-Web endpoint cannot verify=0Athat the recipient= =0A=C2=A0=C2=A0 consents to this particular call. If the=0Asystems are tigh= tly integrated (i.e., the STUN endpoint=0A=C2=A0=C2=A0 responds with respon= ses authenticated with=0AICE credentials) then this=0A=C2=A0=C2=A0 issue do= es not exist.=C2=A0 However, such a design is very close to an=0A=C2=A0=C2= =A0 ICE-Lite implementation (indeed, arguably is=0Aone).=C2=A0 An intermedi= ate=0A=C2=A0=C2=A0 approach would be to have a STUN extension=0Athat indica= ted that one=0A=C2=A0=C2=A0 was responding to RTC-Web checks but not=0Acomp= uting integrity checks=0A=C2=A0=C2=A0 based on the ICE credentials.=C2=A0 T= his would allow the use of standalone STUN=0Aservers without the risk of co= nfusing them with legacy STUN=0A=C2=A0=C2=A0 servers.=C2=A0 If a non-ICE le= gacy solution is needed, then this is=0A=C2=A0=C2=A0 probably the best choi= ce.=0A=C2=A0=0AFinal=0Aparagraph says "...where two people briefly share an= IP..." I think=0Asomething is missing after IP. An IP connection? An IP se= ssion? =0A=C2=A0=0ASection=0A4.2.4 Location Privacy: includes the following= sentence: =0A"In=0Aorder to avoid tracking, implementations may wish to=0A= =C2=A0=C2=A0 suppress the start of ICE negotiation until=0Athe callee has a= nswered."=0A=C2=A0=0AThis will=0Anot "avoid tracking", it only prevents peo= ple from being able to=0Adetermine the IP address before the callee answers= . The meaning could be clarified by changing "avoid tracking" to "prevent c= allers from=0Alearning a callees IP address even if the callee does not ans= wer the call".=C2=A0 Alternatively you could elaborate somewhat by=0Aexpand= ing "tracking" to say "silently tracking a person by=0Ainitiating calls, bu= t disconnecting as soon as you receive the IP address from=0AICE, but befor= e the callee is alerted"=0A=C2=A0=0ANit: 4.3=0ACommunications Security.=C2= =A0 =0AFirst=0Aparagraph contains the following: "However, we must examine = this=0Atechnology to the RTC-Web context, where the threat model is somewha= t=0Adifferent." =0AShould=0Aread "... Examine this technology in the RTC-We= b context..."=0A=C2=A0=0ANit: Fifth paragraph: "Retrospective compromise of= calling service.=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The calling service is i= s non-malicious=0Aduring a call but=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 subseq= uently is compromised and wishes to=0Aattack an older call."=0ARepeat of=0A= the word "is" in the sentence.=0A=0AJim From victor.pascual.avila@gmail.com Sun Jul 15 07:06:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0592221F8639 for ; Sun, 15 Jul 2012 07:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXl3hxwM+O5C for ; Sun, 15 Jul 2012 07:05:45 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09D1F21F8619 for ; Sun, 15 Jul 2012 07:05:44 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so137845wgb.13 for ; Sun, 15 Jul 2012 07:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=mgChqxbmhn29vPg4mkkAlPQla4PTt0KSHWqH4oWT2Dg=; b=dKDXirsdNoQUyhrGgYahvtYuSwJP41tcqPmYveoK9dU9ueVVLwuAFc9h9UA8oTM2lM vFdBUkBZKCVwq67FTKSkrT91UXipHEwCp/ppto5fWXg5fDroix4c4WlJLPDxYb4B8NJA v9XZKnIfx2AuTTPCn9t8XdD6VHUyS97J7hDyjViR6nPeOmgE8zJZgEB7+PpBYVluVGRu f5Ufzthx/nfmPTESPdAo451bLeBPmOmuki8JenyMBQ/+fu+SAgOTAVPmiYMu28dT1+3F oD1Ntwm0ANFqzqrs8D7JhtVm14w/VWRquL4yHnRKPRug58oc5JUihv3ZP39GPS1yD+c3 09ng== Received: by 10.180.98.200 with SMTP id ek8mr11305035wib.0.1342361185950; Sun, 15 Jul 2012 07:06:25 -0700 (PDT) Received: from [192.168.0.11] (119.85-86-169.dynamic.clientes.euskaltel.es. [85.86.169.119]) by mx.google.com with ESMTPS id ex20sm17688970wid.7.2012.07.15.07.06.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jul 2012 07:06:24 -0700 (PDT) References: <9C57A449-4416-41ED-A66B-4E6C3C2539AE@edvina.net> From: Victor Pascual Content-Type: multipart/alternative; boundary=Apple-Mail-A13C47B8-BB82-4E6B-B327-26CC9006C90B X-Mailer: iPhone Mail (9B206) Message-Id: Date: Sun, 15 Jul 2012 16:06:20 +0200 To: "rtcweb@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: [rtcweb] Fwd: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Jul 2012 14:06:00 -0000 --Apple-Mail-A13C47B8-BB82-4E6B-B327-26CC9006C90B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If you're implementing this (or planning to implement) your feedback is much= appreciated -- please use the sipcore mailing list Thanks! -Victor Begin forwarded message: > From: "Olle E. Johansson" > Date: July 13, 2012 4:41:48 PM GMT+02:00 > To: Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-01.txt= >=20 >=20 > 13 jul 2012 kl. 16:37 skrev Paul Kyzivat: >=20 >> [as co-chair] >>=20 >> The wg agreed to adopt this draft back in May, and expressed considerable= interest in it. I=C3=B1aki provided a wg version of it on June 27. There ha= s been no discussion of this since May. >>=20 >> Is there still interest? Have people simply been busy on holiday since th= e wg version came out? Or do people simply think its *done* and ready for WG= LC. >>=20 >> Please let us know what you think. > Paul, >=20 > There has been a lot of work on implementations. Apart from I=C3=B1aki's f= irst implementation, Asterisk.org Open Source PBX and Kamailio SIP server bo= th has implemented web socket support. =46rom following the mailing lists of= both I haven't seen anyone badmouthing the draft, but I think the tests are= still happening and we can see what will come out of them soon. >=20 > http://www.kamailio.org/w/2012/07/websockets/ > https://reviewboard.asterisk.org/r/2008/ >=20 > /O >>=20 >> Thanks, >> Paul >>=20 >>=20 >> On 7/13/12 4:47 AM, Victor Pascual Avila wrote: >>> Any feedback/advice would be greatly appreciated! >>>=20 >>> Thanks, >>> -Victor >>>=20 >>> On Wed, Jun 27, 2012 at 11:48 AM, I=C3=B1aki Baz Castillo= wrote: >>>> 2012/6/27: >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>>> This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-01 >>>>=20 >>>>=20 >>>> Hi, the changelog from the previous version >>>> draft-ietf-sipcore-sip-websocket-00 is the following: >>>>=20 >>>>=20 >>>> - Section 5.2.3. "Sending Responses" (within section 5.2. "Updates to >>>> RFC 3261") has been removed. As Salvatore Loreto pointed out, the >>>> existing text "is tautological saying that a WebSocket Client can act >>>> only as a client, however in theory a UA (outside a Browser sandbox) >>>> could act as both a WebSocket client and WebSocket server". >>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg04940.html >>>>=20 >>>> - Example 1 includes the WebSocket handshake flow and some typos have >>>> been fixed (thanks to Nataraju A. B.). >>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg04768.html >>>>=20 >>>>=20 >>>> As always your comments are welcome. >>>> Thanks a lot. >>>>=20 >>>> -- >>>> I=C3=B1aki Baz Castillo >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-A13C47B8-BB82-4E6B-B327-26CC9006C90B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
If you're implementing thi= s (or planning to implement) your feedback is much appreciated -- pleas= e use the sipcore mailing list

Thanks!
-Victor=

Begin forwarded message:

From: "Olle E. Johansson" <oej@edvina.net>
Date: July 13, 2012 4:41:48 PM GM= T+02:00
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action:= draft-ietf-sipcore-sip-websocket-01.txt

=

13 jul 2012 kl. 1= 6:37 skrev Paul Kyzivat:

[as co-chair]

The wg agreed to ad= opt this draft back in May, and expressed considerable interest in it. I=C3=B1= aki provided a wg version of it on June 27. There has been no discussion of t= his since May.

Is there still interest? H= ave people simply been busy on holiday since the wg version came out? Or do p= eople simply think its *done* and ready for WGLC.

Please let us know what you think.
Pau= l,

There has been a lot of work on implemen= tations. Apart from I=C3=B1aki's first implementation, Asterisk.org Open Source PBX and Kamailio SIP server both has= implemented web socket support. =46rom following the mailing lists of both I= haven't seen anyone badmouthing the draft, but I think the tests are still h= appening and we can see what will come out of them soon.

http= ://www.kamailio.org/w/2012/07/websockets/
https://reviewboard.asterisk.org/r/20= 08/

/O

  &n= bsp;Thanks,
  &= nbsp;Paul

=

On 7/13/12 4:47 AM, Victor Pascual Avila wrote:
Any feedback/advice would be greatly appreciated!
<= /blockquote>

Thanks,
-Victor

=
On Wed, Jun 27, 2012 at 11:48 AM, I=C3=B1aki Baz Castillo<ibc@aliax.net>  wrote:
2012/6/27<internet-drafts@ietf.org>:

<= /blockquote>
A New= Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Prot= ocol Core Working Group of the IETF.
<= blockquote type=3D"cite">

The IETF datatracker status page for this draft is:
= https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket=

=
There's also a htmlized version available a= t:
http://tools.ietf.org/html/draft-ietf-sipcore-sip-webs= ocket-01
<= blockquote type=3D"cite">


=
Hi, the changelog from the pr= evious version
draft= -ietf-sipcore-sip-websocket-00 is the following:


- Sect= ion 5.2.3. "Sending Responses" (within section 5.2. "Updates to
RFC 3261") has been removed. As= Salvatore Loreto pointed out, the
existing text "is tautological saying that a WebSocket Clien= t can act
only as a c= lient, however in theory a UA (outside a Browser sandbox)
could act as both a WebSocket client a= nd WebSocket server".
 http://www.ietf.org/mail-archive/web/sipcore/current/msg04940.h= tml

=
- Example 1 includes the WebS= ocket handshake flow and some typos have
been fixed (thanks to Nataraju A. B.).
 http://www.ietf.org/mail= -archive/web/sipcore/current/msg04768.html


As alway= s your comments are welcome.
Thanks a lot.
<= span>
--
=
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
__________= _____________________________________
sipcore mailing list=
sipcore@ietf.org<= /span>
= https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________=
sipcore mailing list=
sipcore@ietf.org
https://w= ww.ietf.org/mailman/listinfo/sipcore

---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, O= ffice +46 8 96 40 20, Sweden



_______________________________________________sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
= --Apple-Mail-A13C47B8-BB82-4E6B-B327-26CC9006C90B-- From tireddy@cisco.com Sun Jul 15 23:59:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6682611E8079 for ; Sun, 15 Jul 2012 23:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsnMWWnJuRLB for ; Sun, 15 Jul 2012 23:59:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7715321F8498 for ; Sun, 15 Jul 2012 23:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=1930; q=dns/txt; s=iport; t=1342422009; x=1343631609; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nCt/kd7Lh3XlLXlX83s3jc1xIET/d6RotFchvss6gxM=; b=UVfzNwD85bSmwzM4CJfNlBriIMH6j86cr6JvWjIqcD5ESOiRL6zL7wFc pFxTyb29I9Vakn9PHLzVXJ1ByowhUGTIZALpmqIdHUqkg+e7hLroJCJS5 Hvns9qBbD9GHOBVr/Jl+rNde7nkwMkN40+2DZt0R5HHSoJv1M9T+v6Sed g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB+7A1CtJXG9/2dsb2JhbABFuD2BB4IgAQEBBAEBAQkGAVsLDAICAgEIEQQBAQsdBxsMCxQJCAIEAQ0FCBMHh2sLm02fDAQEizyFZ2ADiBabRYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,592,1336348800"; d="scan'208";a="102126698" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jul 2012 07:00:09 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6G7098E019698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jul 2012 07:00:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 02:00:08 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Propose Vancouver Agenda Topics Thread-Index: AQHNVC/eZJ8mmdo6mUWmXKkus7rmYJcrkYCQ Date: Mon, 16 Jul 2012 07:00:07 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A052D3357@xmb-rcd-x10.cisco.com> References: <4FEAAB0A.2060106@ericsson.com> In-Reply-To: <4FEAAB0A.2060106@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.004 x-tm-as-result: No--39.028600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Propose Vancouver Agenda Topics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 06:59:26 -0000 We'd like to present the following draft: Name of the draft: draft-reddy-rtcweb-stun-auth-fw-traversal-00 Relevance to the rtcweb WG charter: This draft provides a way for firewalls to authenticate attempts to initiat= e UDP flows from within an enterprise. This is the initial version, to exp= lain the problem and show a simple solution.=20 Amount of time needed: 10 minutes Thanks, Tiru. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Wednesday, June 27, 2012 12:11 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Propose Vancouver Agenda Topics >=20 > WG, >=20 > The WG chairs solicit topics that you think needs to be discussed in > Vancouver. Both authors/editors of documents that have topics they > think > requires face to face discussion to reach consensus and WG participants > that think a particular topic should be discussed are of interest. >=20 > Two topics that is clear they need further discussion and was not taken > at the interim meeting are > - Additional Key-management for SRTP > - Selection of Mandatory to implement Media Codecs >=20 > Please add to the list or comment on the suitability to have these > topics. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From internet-drafts@ietf.org Mon Jul 16 09:52:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2C21F86E5; Mon, 16 Jul 2012 09:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp8Wu7ly-Sv6; Mon, 16 Jul 2012 09:52:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046A211E8142; Mon, 16 Jul 2012 09:52:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716165238.8043.5831.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 09:52:38 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:52:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-04.txt Pages : 60 Date : 2012-07-16 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmce.ietf@rogers.com Mon Jul 16 10:53:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4D711E825C for ; Mon, 16 Jul 2012 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 241f4Fl3h2n2 for ; Mon, 16 Jul 2012 10:53:36 -0700 (PDT) Received: from nm13-vm0.bullet.mail.ac4.yahoo.com (nm13-vm0.bullet.mail.ac4.yahoo.com [98.139.52.232]) by ietfa.amsl.com (Postfix) with SMTP id A7F8C11E824E for ; Mon, 16 Jul 2012 10:53:36 -0700 (PDT) Received: from [98.139.52.195] by nm13.bullet.mail.ac4.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000 Received: from [209.191.108.97] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000 Received: from [66.94.237.100] by t4.bullet.mud.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000 Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 444415.52080.bm@omp1005.access.mail.mud.yahoo.com Received: (qmail 4776 invoked by uid 60001); 16 Jul 2012 17:54:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1342461257; bh=LNW2h8PTj1N8bqmzRiqsMPXTiaxiH0cnpZNuFUA0qR4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rFG7lpdKPzXHCf+2GwY3S3H6QpLwKe//VIVrtlvGyL1bHvjMxph77UxlHURJq7gnNCHc/dLNMAL+PBbwj5sZcFlv7MG1A2pUnfYhVICUF7tjAht9v1z0Ob2e8E8nFnFNxD8/ls0gcbHbe+Dg2wO1iR9u7RRHgHeR035W3JNRqic= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pewuk6aU1uMuW3IH0cXnGM5TJt0cs8zWNX/oCkORjJ7pGeULPRVnW9TaPff4Fek9eyYNr5wDHJ5n2NwqUy2Tz58FjpxQpkWEorNZTnO9Wfue/5gJZRhkdV+GFAGkFbRFtOz5icBRHBjfZq9aDzYcScgxqKG2ea9uvI1W0rvzjAM=; X-YMail-OSG: 66PjcOMVM1lQgtpOYoGla6YwvUive5zEjtH8BqelbiZI.Tr VNHPP5kD0qd8jVlOACLS7Uv7P_RvyW0_O0rISht5iP8uIh7qkipWBPR2NFsW AnmNkqg5yU7ldFoDW.GG6WPMsal3w.SNxyjwq4EEw4homNz8FNcI1dRguH6Q niTjayA_1PTQ.XBv_JoqJofmy_UFeBaAH8b0VrnvbJHS1JZ5ZyXGjBkJ8NyX yabWB.AhX9c1a9DQdjunNsBpBw9.mPUvomZgrXNjUKMASSDSRb22FBDwWRKf _nckw9GLeZGlhT_zF.dpuTcljdC7XYFC04F9G3K48b5BJcbmfdq2tAwlbHeD QQf1TX8qh5u90PPhn1VcaPKm0nA51nTsBJpj.KfPAF6kHtdEdvop5HZYOrFM vkk4gD.JHcYqzLr960PMPZLf5klkt.l4Os7zCEfJi18qOSY69MvQoywTPIUm q Received: from [99.240.70.9] by web88620.mail.bf1.yahoo.com via HTTP; Mon, 16 Jul 2012 10:54:14 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <1342123062.4892.YahooMailNeo@web88602.mail.bf1.yahoo.com> Message-ID: <1342461254.1994.YahooMailNeo@web88620.mail.bf1.yahoo.com> Date: Mon, 16 Jul 2012 10:54:14 -0700 (PDT) From: Jim McEachern To: "rtcweb@ietf.org" In-Reply-To: <1342123062.4892.YahooMailNeo@web88602.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [rtcweb] Detailed Review of draft-ietf-rtcweb-security-arch-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jim McEachern List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:53:37 -0000 I have completed a thorough review of RTCWEB=0ASecurity Architecturedraft-i= etf-rtcweb-security-arch-02, and have the following comments.=0A=0A=C2=A0= =0ASection=0A3.1 Authenticated Entities contains the following description:= =0A"Calling=0Aservices:=C2=A0 Web sites whose origin we can=0Averify (optim= allyvia HTTPS)."=0AQuestion.=0AIs there any practical way to verify the ori= gin of the web site other than via=0AHTTPS?=C2=A0 If not, then the word "op= timally" could be removed.=0A=0A=C2=A0=0ANit:=0A"...camera an microphone" = =3D> "...camera and microphone".=0A=C2=A0=0ASection=0A4.1 The sixth paragra= ph has the following sentence, starting at the bottom of=0Apage 8 and conti= nuing onto page 9:=0A"In=0Athis case, Alice has provided an identity assert= ion andso Bob=E2=80=99s browser contacts Alice=E2=80=99s identity provider = (again, this isdone in a generic way so the browser has no=0Aspecific knowl= edge of the IdP) to verity the assertion."=0A=C2=A0=0AThis=0Ashould read ..= . to "verify" the assertion.=0A=C2=A0=0ASection 4.4. Communications and Con= sent Freshness, the second paragraph reads:=0A"The=0Aone remaining security= property we need to establish is "consent=0A=C2=A0=C2=A0 freshness", i.e.,= allowing Alice to=0Averify that Bob is still prepared=0A=C2=A0=C2=A0 to re= ceive her communications.=C2=A0 ICE specifies periodic STUN=0A=C2=A0=C2=A0 = keepalizes but only if media is not=0Aflowing.=C2=A0 Because the consent=0A= =C2=A0=C2=A0 issue is more difficult here, we require=0ARTCWeb implementati= ons to=0A=C2=A0=C2=A0 periodically send keepalives.=C2=A0 If a keepalive fa= ils and no new ICE=0A=C2=A0=C2=A0 channels can be established, then the=0As= ession is terminated."=0A=C2=A0=0AHowever,=0Adraft-ietf-rtcweb-security-03,= section 4.2.1 states:=0A"There=0Aalso needs to be some mechanism for the b= rowser to verify that=0A=C2=A0=C2=A0 the target of the traffic continues to= wish=0Ato receive it.=0A=C2=A0=C2=A0 Obviously, some ICE-based mechanism w= ill=0Awork here, but it has been=0A=C2=A0=C2=A0 observed that because ICE k= eepalives are=0Aindications, they will not=0A=C2=A0=C2=A0 work here, so som= e other mechanism is=0Aneeded."=0A=C2=A0=0ASo unless=0AI am missing somethi= ng, the current text in draft-ietf-rtcweb-security-arch-02 proposes to use = the=0Asolution that=C2=A0 draft-ietf-rtcweb-security-03=0Asaid would not wo= rk.=C2=A0 Section=0A5.3 also states the problem with ICE keepalives is that= they are one-way, (while draft-ietf-rtcweb-security-03, section 4.2.1 stat= es that it is because they are "indications") and=0Athat we therefore must = use the consent freshness mechanism [I-D.muthu-behave-consent-freshness].= =0AConsistent language and requirements in these various sections would be= =0Ahelpful.=0AThe following proposals may address this: =0A=0A- in draft-ie= tf-rtcweb-security-03, section 4.2.1 change "indications" to "one-way indic= ations".=0A- in Section 4.4. Communications and Consent Freshness, the seco= nd paragraph, add a sentence between the second last sentence, and the last= sentence. The end of this paragraph would then read: "Because the consenti= ssue is more difficult here, we require=0ARTCWeb implementations toperiodic= ally send keepalives.These keepalives MUST be based on the consent freshnes= s mechanism specified in [I-D.muthu-behave-consent-freshness].=C2=A0 If a k= eepalive fails and no new ICEchannels can be established, then the=0Asessio= n is terminated."=0A=C2=A0=0ASection=0A5.2 Device Permissions Model, bottom= of page 11, the first API requirement=0Astates:=0A"API=0ARequirement:=C2= =A0 The API MUST provide a=0Amechanism for the requesting=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 JS to indicate which of these forms of=0Apermissions it is= =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 requesting.=C2=A0 This allows the client = to know what sort of=0Auser=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interface expe= rience to provide. "=0A=C2=A0=0AComment: I guess=0Ait is implied by this, b= ut it might be worth explicitly stating that one of the motivations behind = the "user interface=0Aexperience"is allowing the browser to know=0Awhat per= missions to ask the user for, and what permissions to enforce later.=0A=C2= =A0=0A5.3.=C2=A0 Communications Consent, bottom of page 12=0Asays:=0A=C2=A0= =C2=A0 "Browser client implementations of=0ARTCWEB MUST implement ICE.=C2= =A0 Server=0A=C2=A0=C2=A0 gateway implementations which operate only=0Aat p= ublic IP addresses may=0A=C2=A0=C2=A0 implement ICE-Lite...."=0A=C2=A0=0AQu= estion: What is=0Athe intent here for server gateway implementations? Do we= mean that server=0Agateway implementations ... may implement ICE-Lite inst= ead of full ICE, but=0AMUST implement one of them? I assume that is the int= ent, but I think the=0Acurrent wording does not technically say that. I thi= nk the current wording=0Acould reasonably be interpreted as saying that ser= ver gateway implementations=0Atechnically don't have to implement either.= =0A=C2=A0=0A5.4.=C2=A0 IP Location Privacy=0AThe=0Asecond API requirement m= ight be clearer if it was split into two separate=0Arequirements, the first= dealing with the requirement to be able to force TURN-only candidates, and= the second providing=0Aan ability to reconfigure to add non-turn candidate= s.=0A=C2=A0=0AIn addition, the=0Aexplanation in the second requirement seem= s incomplete, as it only discusses=0Asome of the benefits. It could be expa= nded, and put as a separate paragraph after the requirements.=C2=A0 Here is= =0Atext that you might consider for this paragraph, building on what is=0Aa= lready there:=0AProposed expanded text: "Taken=0Atogether, these requiremen= ts allow ICE negotiation to start immediately on=0Aincoming call notificati= on, thus reducing post-dial delay, but also to avoid=0Adisclosing the user= =E2=80=99s IP address until they have=0Adecided to answer. They also allow = users to completely hide their IP address=0Afor the duration of the call. F= inally, they allow a mechanism for the user to=0Aoptimize performance by re= configuring to allow non-turn candidates during an active call if=0Athe use= r decides they no longer need to hide their IP address." =0A=C2=A0=0AThe=0A= second API requirement in section 5.5 on page 14 is a repeat of the first= =0Arequirement, and should be deleted.=C2=A0 Specifically:=0A"API=0ARequire= ment:=C2=A0 The API MUST provide a=0Amechanism to indicate that a=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 fresh DTLS key pair is to be generated=0Afor a spe= cific call.=C2=A0 This=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is intended to allo= w for=0Aunlinkability."=0A=C2=A0=0AIn=0Asection 5.5, in the list of propert= ies that are likely to require drill-down, at the top of page 15,=0Athe fir= st bullet is not listed in the format of a requirement, while the others ar= e. It currently is:=0A"*=0AThe cryptographic algorithms in use (For example= :=C2=A0 "AES-CBC" or=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Nu= ll Cipher".)"=0AThis=0Acould be changed to:=0A=C2=A0"*=C2=A0 The=0A"securit= y characteristics" MUST indicate the cryptographic algorithms=0Ain use (For= example:=C2=A0 "AES-CBC"=0Aor "Null Cipher".)"=0A=C2=A0=0ANit:=0A5.6.=C2= =A0 Web-Based Peer Authentication,=0Asecond paragraph has mis-placed bracke= ts.=0A=C2=A0 (i.e., HTTP/HTTPS identity provider), should=0Abe (i.e., HTTP/= HTTPS) identity provider...=0A=C2=A0=0A6.1.=C2=A0 Communications Security, = end of second=0Aparagraph, at the bottom of page 16, has the following sent= ence:=0A"Users=0Awho wish to assure=0A=C2=A0=C2=A0 themselves of security a= gainst a malicious=0Aidentity provider MUST=0A=C2=A0=C2=A0 verify peer cred= entials directly, e.g., by=0Achecking the peer=E2=80=99s=0A=C2=A0=C2=A0 fin= gerprint against a value delivered out of=0Aband."=0AQuestion:=0Aare we rea= lly putting MUST requirements on the user? Would it be more accurate=0Ato c= hange "MUST verify" to "can only do so by=0Averifying..."?=0A=0AJim=0A=0A= =0A=0A=0A=0AJim =0A From martin.thomson@gmail.com Mon Jul 16 11:38:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2215421F879F for ; Mon, 16 Jul 2012 11:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YrQg7qBqD4p for ; Mon, 16 Jul 2012 11:38:15 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28A8021F8773 for ; Mon, 16 Jul 2012 11:38:14 -0700 (PDT) Received: by bkty7 with SMTP id y7so4560706bkt.31 for ; Mon, 16 Jul 2012 11:38:59 -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=RFm/Mw2riITEDYMOEvN5bnEwqE/tnjmV7HTRlFu98LU=; b=UZ54ZB+rM7BtMMHBXvTjNSRB+rWlVtl8YtHqdIlwohBca+imyJklsw+tqI87IfoR/v +qx2dxgsdymMmKUOlmHB8kIHOuiUuLxfkoJnue5utN6EM3u7a8AOGcUPbGWhfuOSEOxD pE4Dzdu0/ivwjluBcSWo1KJ2KlYWUOsFgKKzmu7qJGxy5fnemjqNTklFnd/Vdo8KnRqC JTFXCIaQN/59FsqN1veFl59QEA1PbwXPbiQljIWsjHfXiwre/HtIcABduulkajupfB0Y hU3KxiA7vRBNpDAba4NiHjx+xIrDEJ4IVsc7KuqWnEdGxxhEatIjZ/a9Y1SD/cn9/aFG nsuQ== MIME-Version: 1.0 Received: by 10.204.130.216 with SMTP id u24mr5415392bks.119.1342463939133; Mon, 16 Jul 2012 11:38:59 -0700 (PDT) Received: by 10.204.66.17 with HTTP; Mon, 16 Jul 2012 11:38:59 -0700 (PDT) Date: Mon, 16 Jul 2012 11:38:59 -0700 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] RTP usage: requirement levels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:38:16 -0000 The RTP usage draft current uses MUST, SHOULD, MAY to indicate two levels of compliance. This is not a particularly good division for this sort of draft. Firstly, it's unclear what meaningful distinction there is between SHOULD and MAY. Then there is the distinction between MUST implement and MUST use. The following classifications are more relevant to this sort of draft. mandatory to USE - all implementations MUST always use this feature - there is no reason to signal support for the feature - there is no reason to provide a means to disable it - no API requirements need to be derived for features that are mandatory to use mandatory to IMPLEMENT - all implementations MUST include support for the feature - implementations MUST provide a means to enable and disable the feature (API requirement) - there is no API requirement for indicating support of the feature mandatory to DISABLE - implementations MAY include support for the feature - implementations MUST provide a means to signal support for the feature (API requirement) - implementations that support the feature MUST provide a means to enable and disable the feature (optional API requirement) From internet-drafts@ietf.org Mon Jul 16 15:12:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB621F8559; Mon, 16 Jul 2012 15:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37N6yCJwy7S7; Mon, 16 Jul 2012 15:12:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6721F85C6; Mon, 16 Jul 2012 15:12:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716221246.7208.84314.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:12:46 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:12:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWEB Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-03.txt Pages : 36 Date : 2012-07-16 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (e.g JavaScript). The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf-rtcweb- security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-arch-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bernard_aboba@hotmail.com Mon Jul 16 15:14:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA20111E813C for ; Mon, 16 Jul 2012 15:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvj9-2MNTOl3 for ; Mon, 16 Jul 2012 15:14:39 -0700 (PDT) Received: from blu0-omc4-s4.blu0.hotmail.com (blu0-omc4-s4.blu0.hotmail.com [65.55.111.143]) by ietfa.amsl.com (Postfix) with ESMTP id EEA9711E8123 for ; Mon, 16 Jul 2012 15:14:38 -0700 (PDT) Received: from BLU169-W123 ([65.55.111.137]) by blu0-omc4-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 15:15:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8871a758-4a76-42ba-8a01-57e44fc61794_" X-Originating-IP: [64.134.128.30] From: Bernard Aboba To: , Date: Mon, 16 Jul 2012 15:15:21 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2012 22:15:21.0602 (UTC) FILETIME=[7D8E7E20:01CD63A0] Subject: Re: [rtcweb] RTP usage: requirement levels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:14:40 -0000 --_8871a758-4a76-42ba-8a01-57e44fc61794_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good questions. Some comments below.=20 > Date: Mon=2C 16 Jul 2012 11:38:59 -0700 > From: martin.thomson@gmail.com > To: rtcweb@ietf.org > Subject: [rtcweb] RTP usage: requirement levels >=20 > The RTP usage draft current uses MUST=2C SHOULD=2C MAY to indicate two > levels of compliance. This is not a particularly good division for > this sort of draft. >=20 > Firstly=2C it's unclear what meaningful distinction there is between > SHOULD and MAY. Then there is the distinction between MUST implement > and MUST use. >=20 > The following classifications are more relevant to this sort of draft. >=20 > mandatory to USE > - all implementations MUST always use this feature > - there is no reason to signal support for the feature [BA] Overall=2C I think we need a cleaner understanding of the meaning of t= he term "signal" in this document.=20 The RTP usage document does not update any SDP standards=2C so if an SDP RF= C describes how to do something=2C that still applies to SDP transmitted on= the wire.=20 On the other hand=2C if we are talking about whether an JSEP API implementa= tion has to handle SDP that omits a mandatory to use feature (e.g.=2C offer= ing RTP/AVP with no key management functionality)=2C I'd say "not a require= ment=2C but an appropriate error message is still needed".=20 > - there is no reason to provide a means to disable it [BA] If this is referring to the API=2C I would agree. If we are referring= to SDP=2C I'd say that the usual rules apply. An endpoint (which after al= l could be legacy communicating via a gateway) can send a valid SDP answer = that might not result in a session being established. Being able to clearl= y indicate why the session could not be established is better than an undia= gnosable failure.=20 > - no API requirements need to be derived for features that are mandatory= to use >=20 > mandatory to IMPLEMENT > - all implementations MUST include support for the feature > - implementations MUST provide a means to enable and disable the > feature (API requirement) > - there is no API requirement for indicating support of the feature [BA] Even if something is "mandatory to implement" there could still be a = need to for the feature to be included in an SDP blob output by createOffer= ()=2C no? Or to have a constraint relating to the feature? > mandatory to DISABLE > - implementations MAY include support for the feature > - implementations MUST provide a means to signal support for the > feature (API requirement) > - implementations that support the feature MUST provide a means to > enable and disable the feature (optional API requirement) = --_8871a758-4a76-42ba-8a01-57e44fc61794_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good questions. =3B Some comments below.

>=3B Date: Mon=2C 16 Jul 2012 11:38:59 -0700
>= =3B From: martin.thomson@gmail.com
>=3B To: rtcweb@ietf.org
>=3B = Subject: [rtcweb] RTP usage: requirement levels
>=3B
>=3B The RT= P usage draft current uses MUST=2C SHOULD=2C MAY to indicate two
>=3B = levels of compliance. This is not a particularly good division for
>= =3B this sort of draft.
>=3B
>=3B Firstly=2C it's unclear what m= eaningful distinction there is between
>=3B SHOULD and MAY. Then ther= e is the distinction between MUST implement
>=3B and MUST use.
>= =3B
>=3B The following classifications are more relevant to this sort= of draft.
>=3B
>=3B mandatory to USE
>=3B - all implement= ations MUST always use this feature
>=3B - there is no reason to sign= al support for the feature

[BA] Overall=2C I think we need a cleaner= understanding of the meaning of the term "signal" in this document.
The RTP usage document does not update any SDP standards=2C so if an SDP = RFC describes how to do something=2C that still applies to SDP transmitted = on the wire.

On the other hand=2C if we are talking about whether a= n JSEP API implementation has to handle SDP that omits a mandatory to use f= eature (e.g.=2C offering RTP/AVP with no key management functionality)=2C I= 'd say "not a requirement=2C but an appropriate error message is still need= ed".

>=3B - there is no reason to provide a means to disable it<= br>
[BA] If this is referring to the API=2C I would agree. =3B If we= are referring to SDP=2C I'd say that the usual rules apply. =3B An end= point (which after all could be legacy communicating via a gateway) can sen= d a valid SDP answer that might not result in a session being established.&= nbsp=3B Being able to clearly indicate why the session could not be establi= shed is better than an undiagnosable failure.

>=3B - no API requ= irements need to be derived for features that are mandatory to use
>= =3B
>=3B mandatory to IMPLEMENT
>=3B - all implementations MUST= include support for the feature
>=3B - implementations MUST provide = a means to enable and disable the
>=3B feature (API requirement)
&g= t=3B - there is no API requirement for indicating support of the feature
[BA] =3B Even if something is "mandatory to implement" there coul= d still be a need to for the feature to be included in an SDP blob output b= y createOffer()=2C no? =3B Or to have a constraint relating to the feat= ure?

>=3B mandatory to DISABLE
>=3B - implementations MAY in= clude support for the feature
>=3B - implementations MUST provide a m= eans to signal support for the
>=3B feature (API requirement)
>= =3B - implementations that support the feature MUST provide a means to
= >=3B enable and disable the feature (optional API requirement)

= --_8871a758-4a76-42ba-8a01-57e44fc61794_-- From martin.thomson@gmail.com Mon Jul 16 15:22:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3E711E82F3 for ; Mon, 16 Jul 2012 15:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsYiJDPsE4Al for ; Mon, 16 Jul 2012 15:22:55 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7411E82BB for ; Mon, 16 Jul 2012 15:22:55 -0700 (PDT) Received: by bkty7 with SMTP id y7so4705874bkt.31 for ; Mon, 16 Jul 2012 15:23:40 -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=0LCH5anlzjXrGph1XSGSavUzCeN3sojBbc6ddT2T8ts=; b=xC9N7/cuaDQOup0YrPm+KEUGrg1xKt7NvoNtk2rmqFNfTUDFvTf5o3lGVdmC2IxXBz 7fRyeifgQ5kCt683fisS4y2QINEpSMTOKfvJV7tP9AkIkI1YexE2766wC72+viq/a8qI cxzy7dgcWADAMTVvMkhnQVrT1kswbACAlqeSTnzaXc2GrV99Co2XSB/P7IOfRzDjh67n ObHOYmXvWrwIIxmKLBS6uSZZX13+KjxQMu+Ox5/9g/tOnZZ57AVCcGA1aDaq/EAyKgGD CnmnGzQAvkInYv5XLjgUPosGmW6BMRPfEkIWNKhQxaGiGB6kv8rI8nZsVgbnlxpWQKpo oivQ== MIME-Version: 1.0 Received: by 10.205.123.134 with SMTP id gk6mr56764bkc.3.1342477420144; Mon, 16 Jul 2012 15:23:40 -0700 (PDT) Received: by 10.204.66.17 with HTTP; Mon, 16 Jul 2012 15:23:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jul 2012 15:23:40 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP usage: requirement levels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:22:56 -0000 On 16 July 2012 15:15, Bernard Aboba wrote: > [BA] Overall, I think we need a cleaner understanding of the meaning of the > term "signal" in this document. Ah yes, that was an unfortunate choice of words. To be absolutely clear, I am talking about the nature of the information that is required to pass between browser and javascript, not some sort of signaling protocol. SDP is a signaling protocol. That said, if you need to use SDP, then you need to follow the rules established by SDP. That means that you might have to include some things that are optional in SDP but not rtcweb, and you might feel inclined to reject SDP that would be otherwise valid. From dwing@cisco.com Mon Jul 16 15:25:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7D11E82BB for ; Mon, 16 Jul 2012 15:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5jxkmImYLNs for ; Mon, 16 Jul 2012 15:25:37 -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 481CF11E8301 for ; Mon, 16 Jul 2012 15:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=250; q=dns/txt; s=iport; t=1342477583; x=1343687183; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Mi/s/FDpeIOVx7cx/cfvh12bHwZA5OOC7E/WlfpL+KE=; b=Mmnq+pMJTiYOqDeM4xpycmKvO6VhXTlFhihMbHyNVWhp8eJE/QOr1JQH +GJ6kYIzlskPpxfyGXwCatqR44hLAmOTWi3NpFhQHsptiUeq5DwbrRzO9 cwowneZxXlyhnvzkHcH00tSYITOYLd0Z8SaMhhobUhQPHtA4Xp7RPQyUz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0KAL6UBFCrRDoJ/2dsb2JhbABFhWmkLI4LBAOBKYEHgiABAQEECAoBEAUCTQINAwIJDwsCJgICGSMSCQEBBB4Xh2oMnBaNGZMAgSCPVYESA4hLhQWIfY0OgWaCfw X-IronPort-AV: E=Sophos;i="4.77,597,1336348800"; d="scan'208";a="49531428" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2012 22:26:22 +0000 Received: from dwingWS (sjc-vpn6-1639.cisco.com [10.21.126.103]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6GMQMW4017803; Mon, 16 Jul 2012 22:26:22 GMT From: "Dan Wing" To: "'Martin Thomson'" References: <20120709144813.22696.79942.idtracker@ietfa.amsl.com> <03e201cd5e17$33428a70$99c79f50$@com> In-Reply-To: Date: Mon, 16 Jul 2012 15:26:22 -0700 Message-ID: <00ff01cd63a2$07a07360$16e15a20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1eF6/ISPz3fDYYTuKWBvJ+/9PxeAAAB2/gAWJzdQA= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-isomaki-rtcweb-mobile-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:25:38 -0000 ... > So, "just do that" is what the ICE section of > draft-wing-mmusic-ice-mobility will say. We just submitted = http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-01 which has a = more detailed Section 3 on mobility with ICE. -d From richard.ejzak@alcatel-lucent.com Mon Jul 16 18:12:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1660D11E8088 for ; Mon, 16 Jul 2012 18:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.033 X-Spam-Level: X-Spam-Status: No, score=-10.033 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-96Z9tW2McW for ; Mon, 16 Jul 2012 18:12:11 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1387D11E8087 for ; Mon, 16 Jul 2012 18:12:10 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6H1CsCG017260 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 17 Jul 2012 03:12:54 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 17 Jul 2012 03:12:54 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.33]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 16 Jul 2012 21:12:52 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] consent freshness and ICE-lite Thread-Index: Ac1juUkxXazx0L/8TeuPdppctANNtw== Date: Tue, 17 Jul 2012 01:12:52 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F17709B1B@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F17709B1BUS70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [rtcweb] consent freshness and ICE-lite X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:12:12 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F17709B1BUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sections 4.2, 4.4 and 5.3 of draft-ietf-rtcweb-security-arch-03.txt have te= xt that seems to be contradictory. In particular, 5.3 requires support of = ICE-lite at server gateways but each endpoint is described as sending ICE b= inding requests for ICE consent verification in 4.2 (which is it?). 4.4 al= so requires RTCWeb implementations to perform periodic binding requests to = verify consent freshness. Is a server gateway an RTCWeb implementation sub= ject to this requirement? I thought that one of the reasons the WG decided= to use binding requests instead of binding indications to allow bilateral = consent initiated by a single endpoint (in particular, so that an RTCWeb br= owser could interoperate with either a server gateway implementing ICE-lite= or a non-RTCWeb endpoint not implementing the RTCWeb consent freshness pro= cedures in such a way that only the RTCWeb browser needed to send periodic = binding requests to maintain bilateral consent freshness). Does a binding request provide unilateral or bilateral consent verification= /freshness? Is a server gateway implementing ICE-lite required to send ICE binding requ= ests anyway for consent verification and/or consent freshness, or is it suf= ficient for such an implementation to indicate its own consent by just resp= onding to received binding requests? Do we care about compatibility with ICE compliant endpoints that do not use= binding requests for consent freshness? Does a browser treat a response to a binding request the same as a received= binding request for consent freshness? It would be helpful to have clear answers to these questions in the securit= y architecture document. Thanks, Richard Ejzak --_000_03FBA798AC24E3498B74F47FD082A92F17709B1BUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Sections 4.2, 4.4 and 5.3 of draft-ietf-rtcweb-security-arch-03.txt have t=
ext that seems to be contradictory.  In particular, 5.3 requires suppo=
rt of ICE-lite at server gateways but each endpoint is described as sending=
 ICE binding requests for ICE consent verification in 4.2 (which is it?). &=
nbsp;4.4 also requires RTCWeb implementations to perform periodic binding r=
equests to verify consent freshness.  Is a server gateway an RTCWeb im=
plementation subject to this requirement?  I thought that one of the r=
easons the WG decided to use binding requests instead of binding indication=
s to allow bilateral consent initiated by a single endpoint (in particular,=
 so that an RTCWeb browser could interoperate with either a server gateway =
implementing ICE-lite or a non-RTCWeb endpoint not implementing the RTCWeb =
consent freshness procedures in such a way that only the RTCWeb browser nee=
ded to send periodic binding requests to maintain bilateral consent freshne=
ss).
 
Does a binding request provide unilateral or bilateral consent verificatio=
n/freshness?
 
Is a server gateway implementing ICE-lite required to send ICE binding req=
uests anyway for consent verification and/or consent freshness, or is it su=
fficient for such an implementation to indicate its own consent by just res=
ponding to received binding requests?
 
Do we care about compatibility with ICE compliant endpoints that do not us=
e binding requests for consent freshness?
 
Does a browser treat a response to a binding request the same as a receive=
d binding request for consent freshness?
 
It would be helpful to have clear answers to these questions in the securi=
ty architecture document.
 
Thanks,
Richard Ejzak
 
 

 

--_000_03FBA798AC24E3498B74F47FD082A92F17709B1BUS70UWXCHMBA04z_-- From bernard_aboba@hotmail.com Mon Jul 16 20:27:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8411E8086 for ; Mon, 16 Jul 2012 20:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.754 X-Spam-Level: X-Spam-Status: No, score=-101.754 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA+j1cydhtIh for ; Mon, 16 Jul 2012 20:27:36 -0700 (PDT) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5411E8073 for ; Mon, 16 Jul 2012 20:27:36 -0700 (PDT) Received: from BLU401-EAS266 ([65.55.116.74]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 20:28:22 -0700 X-Originating-IP: [24.16.96.166] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_7b04b397-5532-45b3-916b-c7d7bdd7cc58_" References: <03FBA798AC24E3498B74F47FD082A92F17709B1B@US70UWXCHMBA04.zam.alcatel-lucent.com> From: Bernard Aboba In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F17709B1B@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Mon, 16 Jul 2012 20:32:37 -0700 To: "Ejzak, Richard P (Richard)" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 17 Jul 2012 03:28:22.0764 (UTC) FILETIME=[380062C0:01CD63CC] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness and ICE-lite X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 03:27:37 -0000 --_7b04b397-5532-45b3-916b-c7d7bdd7cc58_ Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="Apple-Mail-AF453377-B413-491E-9AC3-CF67FD0E1FB3" --Apple-Mail-AF453377-B413-491E-9AC3-CF67FD0E1FB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Consent freshness and liveness is used to assure a browser that the recipien= t has authorized it to=20 send media and that it is still there. So if a gateway wants to receive, ans= wer Binding Requests=20 sent to it. =20 If a gateway is on the public Internet, supports ICE lite and does not send a= Binding Request=20 to a browser, but does implement RFC 6263, then NAT bindings can be kept ali= ve and media=20 should still flow. So I think this is viable. On Jul 16, 2012, at 18:13, "Ejzak, Richard P (Richard)" wrote: > Sections 4.2, 4.4 and 5.3 of draft-ietf-rtcweb-security-arch-03.txt have t= ext that seems to be contradictory. In particular, 5.3 requires support of I= CE-lite at server gateways but each endpoint is described as sending ICE bin= ding requests for ICE consent verification in 4.2 (which is it?). 4.4 also r= equires RTCWeb implementations to perform periodic binding requests to verif= y consent freshness. Is a server gateway an RTCWeb implementation subject t= o this requirement? I thought that one of the reasons the WG decided to use= binding requests instead of binding indications to allow bilateral consent i= nitiated by a single endpoint (in particular, so that an RTCWeb browser coul= d interoperate with either a server gateway implementing ICE-lite or a non-R= TCWeb endpoint not implementing the RTCWeb consent freshness procedures in s= uch a way that only the RTCWeb browser needed to send periodic binding reque= sts to maintain bilateral consent freshness). > =20 > Does a binding request provide unilateral or bilateral consent verificatio= n/freshness? > =20 > Is a server gateway implementing ICE-lite required to send ICE binding req= uests anyway for consent verification and/or consent freshness, or is it suf= ficient for such an implementation to indicate its own consent by just respo= nding to received binding requests? > =20 > Do we care about compatibility with ICE compliant endpoints that do not us= e binding requests for consent freshness? > =20 > Does a browser treat a response to a binding request the same as a receive= d binding request for consent freshness? > =20 > It would be helpful to have clear answers to these questions in the securi= ty architecture document. > =20 > Thanks, > Richard Ejzak > =20 > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-AF453377-B413-491E-9AC3-CF67FD0E1FB3 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+Q29uc2VudCBm cmVzaG5lc3MgYW5kIGxpdmVuZXNzIGlzIHVzZWQgdG8gYXNzdXJlIGEgYnJvd3NlciB0aGF0IHRo ZSByZWNpcGllbnQgaGFzIGF1dGhvcml6ZWQgaXQgdG8mbmJzcDs8L2Rpdj48ZGl2PnNlbmQgbWVk aWEgYW5kIHRoYXQgaXQgaXMgc3RpbGwgdGhlcmUuJm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLXN0 eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2 LCAyNiwgMC4yOTY4NzUpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1 LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiBy Z2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPlNvIGlmIGEgZ2F0ZXdheSB3YW50cyB0byBy ZWNlaXZlLCA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Vi a2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTI5NjkpOyAtd2Vi a2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0Njkp OyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4y MzA0NjkpOyAiPmFuc3dlciA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTI5 NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIyNywg MC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgs IDE4MCwgMC4yMzA0NjkpOyAiPkJpbmRpbmcgUmVxdWVzdHMmbmJzcDs8L3NwYW4+PC9kaXY+PGRp dj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hs aWdodC1jb2xvcjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5Mjk2OSk7IC13ZWJraXQtY29tcG9zaXRp b24tZmlsbC1jb2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29t cG9zaXRpb24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+c2Vu dCB0byBpdC4gJm5ic3A7PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxl LXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAy NiwgMC4yOTY4NzUpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAx OTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2Jh KDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xv cjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5Njg3NSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmlsbC1j b2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRpb24t ZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+SWYgYSBnYXRld2F5 IGlzIG9uIHRoZSBwdWJsaWMgSW50ZXJuZXQsIHN1cHBvcnRzIElDRSBsaXRlIGFuZCBkb2VzIG5v dCBzZW5kIGEgQmluZGluZyBSZXF1ZXN0Jm5ic3A7PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6 IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTY4NzUpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29s b3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZy YW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPnRvIGEgYnJvd3Nlciwg YnV0IGRvZXMgaW1wbGVtZW50IFJGQyA2MjYzLCZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBw bGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xvcjogcmdiYSgy NiwgMjYsIDI2LCAwLjI5Mjk2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmlsbC1jb2xvcjogcmdi YSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZnJhbWUtY29s b3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+dGhlbiBOQVQgYmluZGluZ3MgY2Fu IGJlIGtlcHQgYWxpdmUgYW5kIG1lZGlhJm5ic3A7PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6 IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTI5NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29s b3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZy YW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPnNob3VsZCBzdGlsbCBm bG93LiAmbmJzcDtTbyBJIHRoaW5rIHRoaXMgaXMgdmlhYmxlLjwvc3Bhbj48L2Rpdj48ZGl2Pjxi cj48YnI+PC9kaXY+PGRpdj48YnI+T24gSnVsIDE2LCAyMDEyLCBhdCAxODoxMywgIkVqemFrLCBS aWNoYXJkIFAgKFJpY2hhcmQpIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhcmQuZWp6YWtAYWxj YXRlbC1sdWNlbnQuY29tIj5yaWNoYXJkLmVqemFrQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 ZGl2Pg0KDQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD11cy1hc2NpaSI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0NCiAvKiBG b250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpCYXRhbmc7DQoJ cGFub3NlLTE6MiAzIDYgMCAwIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJGdXR1cmFBIEJrIEJUIjsNCglwYW5vc2UtMToyIDExIDUgMiAyIDIgNCAyIDMgMzt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQEJhdGFuZyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAg MCAwIDAgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkZ1dHVyYUEgQmsgQlQiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtj b2xvcjojNjA2NDIwOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2lu OjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlv bjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQog IDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCg0KDQo8ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8cHJlPjxmb250IHNp emU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ U2VjdGlvbnMgNC4yLCA0LjQgYW5kIDUuMyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1h cmNoLTAzLnR4dCBoYXZlIHRleHQgdGhhdCBzZWVtcyB0byBiZSBjb250cmFkaWN0b3J5LiAmbmJz cDtJbiBwYXJ0aWN1bGFyLCA1LjMgcmVxdWlyZXMgc3VwcG9ydCBvZiBJQ0UtbGl0ZSBhdCBzZXJ2 ZXIgZ2F0ZXdheXMgYnV0IGVhY2ggZW5kcG9pbnQgaXMgZGVzY3JpYmVkIGFzIHNlbmRpbmcgSUNF IGJpbmRpbmcgcmVxdWVzdHMgZm9yIElDRSBjb25zZW50IHZlcmlmaWNhdGlvbiBpbiA0LjIgKHdo aWNoIGlzIGl0PykuICZuYnNwOzQuNCBhbHNvIHJlcXVpcmVzIFJUQ1dlYiBpbXBsZW1lbnRhdGlv bnMgdG8gcGVyZm9ybSBwZXJpb2RpYyBiaW5kaW5nIHJlcXVlc3RzIHRvIHZlcmlmeSBjb25zZW50 IGZyZXNobmVzcy4gJm5ic3A7SXMgYSBzZXJ2ZXIgZ2F0ZXdheSBhbiBSVENXZWIgaW1wbGVtZW50 YXRpb24gc3ViamVjdCB0byB0aGlzIHJlcXVpcmVtZW50PyAmbmJzcDtJIHRob3VnaHQgdGhhdCBv bmUgb2YgdGhlIHJlYXNvbnMgdGhlIFdHIGRlY2lkZWQgdG8gdXNlIGJpbmRpbmcgcmVxdWVzdHMg aW5zdGVhZCBvZiBiaW5kaW5nIGluZGljYXRpb25zIHRvIGFsbG93IGJpbGF0ZXJhbCBjb25zZW50 IGluaXRpYXRlZCBieSBhIHNpbmdsZSBlbmRwb2ludCAoaW4gcGFydGljdWxhciwgc28gdGhhdCBh biBSVENXZWIgYnJvd3NlciBjb3VsZCBpbnRlcm9wZXJhdGUgd2l0aCBlaXRoZXIgYSBzZXJ2ZXIg Z2F0ZXdheSBpbXBsZW1lbnRpbmcgSUNFLWxpdGUgb3IgYSBub24tUlRDV2ViIGVuZHBvaW50IG5v dCBpbXBsZW1lbnRpbmcgdGhlIFJUQ1dlYiBjb25zZW50IGZyZXNobmVzcyBwcm9jZWR1cmVzIGlu IHN1Y2ggYSB3YXkgdGhhdCBvbmx5IHRoZSBSVENXZWIgYnJvd3NlciBuZWVkZWQgdG8gc2VuZCBw ZXJpb2RpYyBiaW5kaW5nIHJlcXVlc3RzIHRvIG1haW50YWluIGJpbGF0ZXJhbCBjb25zZW50IGZy ZXNobmVzcykuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXpl PSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Eb2VzIGEg YmluZGluZyByZXF1ZXN0IHByb3ZpZGUgdW5pbGF0ZXJhbCBvciBiaWxhdGVyYWwgY29uc2VudCB2 ZXJpZmljYXRpb24vZnJlc2huZXNzPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxw cmU+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm b250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+SXMgYSBzZXJ2ZXIgZ2F0ZXdheSBpbXBsZW1lbnRpbmcgSUNFLWxpdGUgcmVxdWlyZWQg dG8gc2VuZCBJQ0UgYmluZGluZyByZXF1ZXN0cyBhbnl3YXkgZm9yIGNvbnNlbnQgdmVyaWZpY2F0 aW9uIGFuZC9vciBjb25zZW50IGZyZXNobmVzcywgb3IgaXMgaXQgc3VmZmljaWVudCBmb3Igc3Vj aCBhbiBpbXBsZW1lbnRhdGlvbiB0byBpbmRpY2F0ZSBpdHMgb3duIGNvbnNlbnQgYnkganVzdCBy ZXNwb25kaW5nIHRvIHJlY2VpdmVkIGJpbmRpbmcgcmVxdWVzdHM/PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5EbyB3ZSBjYXJlIGFib3V0IGNvbXBhdGliaWxpdHkgd2l0 aCBJQ0UgY29tcGxpYW50IGVuZHBvaW50cyB0aGF0IGRvIG5vdCB1c2UgYmluZGluZyByZXF1ZXN0 cyBmb3IgY29uc2VudCBmcmVzaG5lc3M/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0K PHByZT48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5Eb2VzIGEgYnJvd3NlciB0cmVhdCBhIHJlc3BvbnNlIHRvIGEgYmluZGluZyByZXF1 ZXN0IHRoZSBzYW1lIGFzIGEgcmVjZWl2ZWQgYmluZGluZyByZXF1ZXN0IGZvciBjb25zZW50IGZy ZXNobmVzcz88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9 IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkl0IHdvdWxk IGJlIGhlbHBmdWwgdG8gaGF2ZSBjbGVhciBhbnN3ZXJzIHRvIHRoZXNlIHF1ZXN0aW9ucyBpbiB0 aGUgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w cmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4N CjxwcmU+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5SaWNoYXJkIEVqemFrPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl Pg0KPHByZT48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxw cmU+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5ydGN3ZWIgbWFpbGluZyBsaXN0PC9zcGFu Pjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5v cmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWI8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-AF453377-B413-491E-9AC3-CF67FD0E1FB3-- --_7b04b397-5532-45b3-916b-c7d7bdd7cc58_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_7b04b397-5532-45b3-916b-c7d7bdd7cc58_-- From randell-ietf@jesup.org Mon Jul 16 20:27:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889EC11E80BD for ; Mon, 16 Jul 2012 20:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bmTcqdfyQEb for ; Mon, 16 Jul 2012 20:27:47 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A5F8B11E80AA for ; Mon, 16 Jul 2012 20:27:47 -0700 (PDT) Received: from 24.152.231.158.res-cmts.mtp2.ptd.net ([24.152.231.158] helo=[192.168.2.16]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SqySf-0006ii-BB for rtcweb@ietf.org; Mon, 16 Jul 2012 22:28:33 -0500 Message-ID: <5004DBE5.1070707@jesup.org> Date: Mon, 16 Jul 2012 23:28:37 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120711 Thunderbird/14.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20120716202858.6451.85244.idtracker@ietfa.amsl.com> In-Reply-To: <20120716202858.6451.85244.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120716202858.6451.85244.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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-Source: X-Source-Args: X-Source-Dir: Subject: [rtcweb] Fwd: New Version Notification for draft-jesup-rtcweb-data-protocol-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 03:27:48 -0000 This is a minor update, mostly adding discussion of signaling. -------- Original Message -------- Subject: New Version Notification for draft-jesup-rtcweb-data-protocol-02.txt Date: Mon, 16 Jul 2012 13:28:58 -0700 From: internet-drafts@ietf.org To: randell-ietf@jesup.org CC: salvatore.loreto@ericsson.com, tuexen@fh-muenster.de A new version of I-D, draft-jesup-rtcweb-data-protocol-02.txt has been successfully submitted by Randell Jesup and posted to the IETF repository. Filename: draft-jesup-rtcweb-data-protocol Revision: 02 Title: WebRTC Data Channel Protocol Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-jesup-rtcweb-data-protocol-02.txt Status: http://datatracker.ietf.org/doc/draft-jesup-rtcweb-data-protocol Htmlized: http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-02 Diff: http://tools.ietf.org/rfcdiff?url2=draft-jesup-rtcweb-data-protocol-02 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies an actual (minor) protocol for how the JS-layer dataChannel objects provide the data channels between the peers. The IETF Secretariat From jmillan@aliax.net Mon Jul 16 22:34:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86221F8608 for ; Mon, 16 Jul 2012 22:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J84c3hA3xGOd for ; Mon, 16 Jul 2012 22:34:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD73F21F8602 for ; Mon, 16 Jul 2012 22:34:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so18704yhq.31 for ; Mon, 16 Jul 2012 22:35:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=dm1boQrvCQ9qzMc2Y0vXejtb4BrIUo/3ZajBGeRvMNs=; b=glIVe+m/dlmuALxmFG5ELRsaCLTNXgCXm2jvurRdvg1gewPNBtsub5E9d65dyvJ9Oh VBdnuAGCzIIKL5vcZRxj8eX2QffF4AY0YkKtSt119ZgOMz+LU1Gol0Lk0B479U0Wcpkj 52/pUNHJINH3VbwKdtQvCFShSK5vko8Al36/wt1wm5QKKteOA6IY+Wfevd0MxyZBQKVJ Mqh8O+9bU/dzDoXqG0+ayM/5PZlImg9OeXPVZpJfBIobeut6QTBOaL42P0T7kNdzNnxg 0iVsyOsUyzPGtZMS/VxR+c9TazAX9bKEn29qtYeUG3UV49HbLjn3wyMbzgVe96ZVBh/P 3n7g== MIME-Version: 1.0 Received: by 10.43.134.134 with SMTP id ic6mr566863icc.26.1342503307002; Mon, 16 Jul 2012 22:35:07 -0700 (PDT) Received: by 10.64.23.74 with HTTP; Mon, 16 Jul 2012 22:35:06 -0700 (PDT) Date: Tue, 17 Jul 2012 07:35:06 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmHpwRuRFFjMgD6Td/yEoywAlZi5l9auttxEeuVcb0KN1R5IKPYkAS61f4nz7JsEAGnIlVZ Subject: [rtcweb] Terminate or Reject streams by setting port to zero in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 05:34:27 -0000 Hi, Offer/Answer Model with Session Description Protocol states that a stream can be terminated or rejected by setting the port to zero in the Offer/Answer SDP respectively. How can this be achieved with PeerConnection? Thanks in advance. From mperumal@cisco.com Mon Jul 16 22:42:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D2E11E809C for ; Mon, 16 Jul 2012 22:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qds-I1grBAi2 for ; Mon, 16 Jul 2012 22:42:35 -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 9813C21F85F7 for ; Mon, 16 Jul 2012 22:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=16794; q=dns/txt; s=iport; t=1342503801; x=1343713401; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ql/b0W/PenLFtW1mZ63uC0BtEUCUXAcQDZH4bcxb2z0=; b=FmE8j4OaX0D39yaFyQZVlkO6ssuFthDc8nfeak0M1tGuT2GV4V9sKeVI W8rSu1TRv4zm3bLpiivlSpXqHl2AT5sl6BxF9XiwG8nEo/RRHDs57L9lD DhwG7WXOiOBo05nIjZ5RkrO1oHd1Jd/CnWpi9av6YYi0RbTEB9oQI/0mW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGX6BFCtJXHB/2dsb2JhbABFgkqDILJWgRuBB4IgAQEBBAEBAQ8BEApBCxACAQgRAQMBAQsdAwICAiULFAMGCAIEDgUIGodrC5wtjRmSfwSLPoU1MmADo1uBZoJfgVYHGg X-IronPort-AV: E=Sophos;i="4.77,599,1336348800"; d="scan'208,217";a="102468646" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2012 05:43:20 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6H5hKoU028495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 05:43:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 00:43:19 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Bernard Aboba , "Ejzak, Richard P (Richard)" Thread-Topic: [rtcweb] consent freshness and ICE-lite Thread-Index: AQHNY8w9W2cZs2lHjUu9YW6rsDo7W5cs7BwA Date: Tue, 17 Jul 2012 05:43:18 +0000 Message-ID: References: <03FBA798AC24E3498B74F47FD082A92F17709B1B@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.155] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--45.772200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D4DFExmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness and ICE-lite X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 05:42:36 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D4DFExmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQsIGNvbnNlbnQgaXMgcmVxdWVzdGVkIGJ5IHRoZSBzZW5kZXIgYW5kIGdyYW50ZWQgYnkg dGhlIHJlY2VpdmVyLiBXaGlsZSBvbmUgc2lkZSBoYXMgZ3JhbnRlZCBjb25zZW50IGZvciByZWNl aXZpbmcgb24gYSBjYW5kaWRhdGUgcGFpciwgdGhlIG90aGVyIHNpZGUgY291bGQgaGF2ZSByZXZv a2VkIGl0LiBTbyBjb25zZW50IHZlcmlmaWNhdGlvbi9mcmVzaG5lc3MgaXMgdW5pbGF0ZXJhbC4N Cg0KQSBnYXRld2F5L2Jyb3dzZXIgaW1wbGVtZW50aW5nIElDRS1saXRlIHdpbGwgb25seSBiZSBh YmxlIHRvIGdyYW50IGNvbnNlbnQgdG8gc2VuZCwgYnV0IHdpbGwgbm90IGJlIGFibGUgdG8gcmVx dWVzdCBjb25zZW50LiBTbywgYSBtYWxpY2lvdXMgYXBwbGljYXRpb24gY2FuIHVzZSBpdCBmb3Ig c2VuZGluZyB1bndhbnRlZCB0cmFmZmljLg0KDQpMaXZlbmVzcyBkZXRlcm1pbmVzIGNvbnRpbnVl ZCBjb25uZWN0aXZpdHkgb24gYSBjYW5kaWRhdGUgcGFpci4gU2luY2UgdGhlIG5ldHdvcmtzIHBh dGhzIGNhbiBiZSBhc3ltbWV0cmljLCBib3RoIGVuZHMgbmVlZCB0byBwZXJmb3JtIHRoZSBsaXZl bmVzcyB0ZXN0Lg0KDQpNdXRodQ0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVybmFyZCBBYm9iYQ0K U2VudDogVHVlc2RheSwgSnVseSAxNywgMjAxMiA5OjAzIEFNDQpUbzogRWp6YWssIFJpY2hhcmQg UCAoUmljaGFyZCkNCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBj b25zZW50IGZyZXNobmVzcyBhbmQgSUNFLWxpdGUNCg0KQ29uc2VudCBmcmVzaG5lc3MgYW5kIGxp dmVuZXNzIGlzIHVzZWQgdG8gYXNzdXJlIGEgYnJvd3NlciB0aGF0IHRoZSByZWNpcGllbnQgaGFz IGF1dGhvcml6ZWQgaXQgdG8NCnNlbmQgbWVkaWEgYW5kIHRoYXQgaXQgaXMgc3RpbGwgdGhlcmUu IFNvIGlmIGEgZ2F0ZXdheSB3YW50cyB0byByZWNlaXZlLCBhbnN3ZXIgQmluZGluZyBSZXF1ZXN0 cw0Kc2VudCB0byBpdC4NCg0KDQpJZiBhIGdhdGV3YXkgaXMgb24gdGhlIHB1YmxpYyBJbnRlcm5l dCwgc3VwcG9ydHMgSUNFIGxpdGUgYW5kIGRvZXMgbm90IHNlbmQgYSBCaW5kaW5nIFJlcXVlc3QN CnRvIGEgYnJvd3NlciwgYnV0IGRvZXMgaW1wbGVtZW50IFJGQyA2MjYzLCB0aGVuIE5BVCBiaW5k aW5ncyBjYW4gYmUga2VwdCBhbGl2ZSBhbmQgbWVkaWENCnNob3VsZCBzdGlsbCBmbG93LiAgU28g SSB0aGluayB0aGlzIGlzIHZpYWJsZS4NCg0KDQpPbiBKdWwgMTYsIDIwMTIsIGF0IDE4OjEzLCAi RWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCkiIDxyaWNoYXJkLmVqemFrQGFsY2F0ZWwtbHVjZW50 LmNvbTxtYWlsdG86cmljaGFyZC5lanpha0BhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCg0K U2VjdGlvbnMgNC4yLCA0LjQgYW5kIDUuMyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1h cmNoLTAzLnR4dCBoYXZlIHRleHQgdGhhdCBzZWVtcyB0byBiZSBjb250cmFkaWN0b3J5LiAgSW4g cGFydGljdWxhciwgNS4zIHJlcXVpcmVzIHN1cHBvcnQgb2YgSUNFLWxpdGUgYXQgc2VydmVyIGdh dGV3YXlzIGJ1dCBlYWNoIGVuZHBvaW50IGlzIGRlc2NyaWJlZCBhcyBzZW5kaW5nIElDRSBiaW5k aW5nIHJlcXVlc3RzIGZvciBJQ0UgY29uc2VudCB2ZXJpZmljYXRpb24gaW4gNC4yICh3aGljaCBp cyBpdD8pLiAgNC40IGFsc28gcmVxdWlyZXMgUlRDV2ViIGltcGxlbWVudGF0aW9ucyB0byBwZXJm b3JtIHBlcmlvZGljIGJpbmRpbmcgcmVxdWVzdHMgdG8gdmVyaWZ5IGNvbnNlbnQgZnJlc2huZXNz LiAgSXMgYSBzZXJ2ZXIgZ2F0ZXdheSBhbiBSVENXZWIgaW1wbGVtZW50YXRpb24gc3ViamVjdCB0 byB0aGlzIHJlcXVpcmVtZW50PyAgSSB0aG91Z2h0IHRoYXQgb25lIG9mIHRoZSByZWFzb25zIHRo ZSBXRyBkZWNpZGVkIHRvIHVzZSBiaW5kaW5nIHJlcXVlc3RzIGluc3RlYWQgb2YgYmluZGluZyBp bmRpY2F0aW9ucyB0byBhbGxvdyBiaWxhdGVyYWwgY29uc2VudCBpbml0aWF0ZWQgYnkgYSBzaW5n bGUgZW5kcG9pbnQgKGluIHBhcnRpY3VsYXIsIHNvIHRoYXQgYW4gUlRDV2ViIGJyb3dzZXIgY291 bGQgaW50ZXJvcGVyYXRlIHdpdGggZWl0aGVyIGEgc2VydmVyIGdhdGV3YXkgaW1wbGVtZW50aW5n IElDRS1saXRlIG9yIGEgbm9uLVJUQ1dlYiBlbmRwb2ludCBub3QgaW1wbGVtZW50aW5nIHRoZSBS VENXZWIgY29uc2VudCBmcmVzaG5lc3MgcHJvY2VkdXJlcyBpbiBzdWNoIGEgd2F5IHRoYXQgb25s eSB0aGUgUlRDV2ViIGJyb3dzZXIgbmVlZGVkIHRvIHNlbmQgcGVyaW9kaWMgYmluZGluZyByZXF1 ZXN0cyB0byBtYWludGFpbiBiaWxhdGVyYWwgY29uc2VudCBmcmVzaG5lc3MpLg0KDQoNCg0KRG9l cyBhIGJpbmRpbmcgcmVxdWVzdCBwcm92aWRlIHVuaWxhdGVyYWwgb3IgYmlsYXRlcmFsIGNvbnNl bnQgdmVyaWZpY2F0aW9uL2ZyZXNobmVzcz8NCg0KDQoNCklzIGEgc2VydmVyIGdhdGV3YXkgaW1w bGVtZW50aW5nIElDRS1saXRlIHJlcXVpcmVkIHRvIHNlbmQgSUNFIGJpbmRpbmcgcmVxdWVzdHMg YW55d2F5IGZvciBjb25zZW50IHZlcmlmaWNhdGlvbiBhbmQvb3IgY29uc2VudCBmcmVzaG5lc3Ms IG9yIGlzIGl0IHN1ZmZpY2llbnQgZm9yIHN1Y2ggYW4gaW1wbGVtZW50YXRpb24gdG8gaW5kaWNh dGUgaXRzIG93biBjb25zZW50IGJ5IGp1c3QgcmVzcG9uZGluZyB0byByZWNlaXZlZCBiaW5kaW5n IHJlcXVlc3RzPw0KDQoNCg0KRG8gd2UgY2FyZSBhYm91dCBjb21wYXRpYmlsaXR5IHdpdGggSUNF IGNvbXBsaWFudCBlbmRwb2ludHMgdGhhdCBkbyBub3QgdXNlIGJpbmRpbmcgcmVxdWVzdHMgZm9y IGNvbnNlbnQgZnJlc2huZXNzPw0KDQoNCg0KRG9lcyBhIGJyb3dzZXIgdHJlYXQgYSByZXNwb25z ZSB0byBhIGJpbmRpbmcgcmVxdWVzdCB0aGUgc2FtZSBhcyBhIHJlY2VpdmVkIGJpbmRpbmcgcmVx dWVzdCBmb3IgY29uc2VudCBmcmVzaG5lc3M/DQoNCg0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsIHRv IGhhdmUgY2xlYXIgYW5zd2VycyB0byB0aGVzZSBxdWVzdGlvbnMgaW4gdGhlIHNlY3VyaXR5IGFy Y2hpdGVjdHVyZSBkb2N1bWVudC4NCg0KDQoNClRoYW5rcywNCg0KUmljaGFyZCBFanphaw0KDQoN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpy dGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D4DFExmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJGdXR1cmFBIEJrIEJUIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJGdXR1cmFBIEJr IEJUIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojNjA2NDIwOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEu OXB0Ow0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzYwNjQyMCI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJpZ2h0LCBj b25zZW50IGlzIHJlcXVlc3RlZCBieSB0aGUgc2VuZGVyIGFuZCBncmFudGVkIGJ5IHRoZSByZWNl aXZlci4gV2hpbGUgb25lIHNpZGUgaGFzIGdyYW50ZWQgY29uc2VudCBmb3IgcmVjZWl2aW5nIG9u IGEgY2FuZGlkYXRlIHBhaXIsIHRoZSBvdGhlciBzaWRlIGNvdWxkIGhhdmUgcmV2b2tlZCBpdC4N CiBTbyBjb25zZW50IHZlcmlmaWNhdGlvbi9mcmVzaG5lc3MgaXMgdW5pbGF0ZXJhbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkEgZ2F0 ZXdheS9icm93c2VyIGltcGxlbWVudGluZyBJQ0UtbGl0ZSB3aWxsIG9ubHkgYmUgYWJsZSB0byBn cmFudCBjb25zZW50IHRvIHNlbmQsIGJ1dCB3aWxsIG5vdCBiZSBhYmxlIHRvIHJlcXVlc3QgY29u c2VudC4gU28sIGEgbWFsaWNpb3VzIGFwcGxpY2F0aW9uIGNhbiB1c2UgaXQgZm9yIHNlbmRpbmcg dW53YW50ZWQNCiB0cmFmZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+TGl2ZW5lc3MgZGV0ZXJtaW5lcyBjb250aW51ZWQgY29ubmVj dGl2aXR5IG9uIGEgY2FuZGlkYXRlIHBhaXIuIFNpbmNlIHRoZSBuZXR3b3JrcyBwYXRocyBjYW4g YmUgYXN5bW1ldHJpYywgYm90aCBlbmRzIG5lZWQgdG8gcGVyZm9ybSB0aGUgbGl2ZW5lc3MgdGVz dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPk11dGh1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlcm5hcmQgQWJvYmE8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywgMjAxMiA5OjAzIEFNPGJyPg0KPGI+ VG86PC9iPiBFanphaywgUmljaGFyZCBQIChSaWNoYXJkKTxicj4NCjxiPkNjOjwvYj4gcnRjd2Vi QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBjb25zZW50IGZyZXNo bmVzcyBhbmQgSUNFLWxpdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Q29uc2VudCBmcmVzaG5lc3MgYW5kIGxpdmVuZXNzIGlzIHVzZWQgdG8g YXNzdXJlIGEgYnJvd3NlciB0aGF0IHRoZSByZWNpcGllbnQgaGFzIGF1dGhvcml6ZWQgaXQgdG8m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnNlbmQgbWVkaWEgYW5kIHRoYXQgaXQgaXMgc3RpbGwgdGhlcmUuJm5ic3A7PHNwYW4gY2xhc3M9 ImFwcGxlLXN0eWxlLXNwYW4iPlNvIGlmIGEgZ2F0ZXdheSB3YW50cyB0byByZWNlaXZlLCBhbnN3 ZXIgQmluZGluZyBSZXF1ZXN0cyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFu Ij5zZW50IHRvIGl0LiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj5JZiBhIGdhdGV3YXkgaXMgb24gdGhlIHB1YmxpYyBJbnRlcm5ldCwgc3VwcG9ydHMgSUNF IGxpdGUgYW5kIGRvZXMgbm90IHNlbmQgYSBCaW5kaW5nIFJlcXVlc3QmbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+dG8gYSBicm93c2VyLCBidXQgZG9lcyBpbXBsZW1lbnQg UkZDIDYyNjMsJm5ic3A7dGhlbiBOQVQgYmluZGluZ3MgY2FuIGJlIGtlcHQgYWxpdmUgYW5kIG1l ZGlhJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPnNob3VsZCBzdGlsbCBm bG93LiAmbmJzcDtTbyBJIHRoaW5rIHRoaXMgaXMgdmlhYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAx NiwgMjAxMiwgYXQgMTg6MTMsICZxdW90O0VqemFrLCBSaWNoYXJkIFAgKFJpY2hhcmQpJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFyZC5lanpha0BhbGNhdGVsLWx1Y2VudC5jb20iPnJp Y2hhcmQuZWp6YWtAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwcmU+U2VjdGlvbnMgNC4yLCA0LjQgYW5kIDUuMyBvZiBk cmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTAzLnR4dCBoYXZlIHRleHQgdGhhdCBzZWVt cyB0byBiZSBjb250cmFkaWN0b3J5LiAmbmJzcDtJbiBwYXJ0aWN1bGFyLCA1LjMgcmVxdWlyZXMg c3VwcG9ydCBvZiBJQ0UtbGl0ZSBhdCBzZXJ2ZXIgZ2F0ZXdheXMgYnV0IGVhY2ggZW5kcG9pbnQg aXMgZGVzY3JpYmVkIGFzIHNlbmRpbmcgSUNFIGJpbmRpbmcgcmVxdWVzdHMgZm9yIElDRSBjb25z ZW50IHZlcmlmaWNhdGlvbiBpbiA0LjIgKHdoaWNoIGlzIGl0PykuICZuYnNwOzQuNCBhbHNvIHJl cXVpcmVzIFJUQ1dlYiBpbXBsZW1lbnRhdGlvbnMgdG8gcGVyZm9ybSBwZXJpb2RpYyBiaW5kaW5n IHJlcXVlc3RzIHRvIHZlcmlmeSBjb25zZW50IGZyZXNobmVzcy4gJm5ic3A7SXMgYSBzZXJ2ZXIg Z2F0ZXdheSBhbiBSVENXZWIgaW1wbGVtZW50YXRpb24gc3ViamVjdCB0byB0aGlzIHJlcXVpcmVt ZW50PyAmbmJzcDtJIHRob3VnaHQgdGhhdCBvbmUgb2YgdGhlIHJlYXNvbnMgdGhlIFdHIGRlY2lk ZWQgdG8gdXNlIGJpbmRpbmcgcmVxdWVzdHMgaW5zdGVhZCBvZiBiaW5kaW5nIGluZGljYXRpb25z IHRvIGFsbG93IGJpbGF0ZXJhbCBjb25zZW50IGluaXRpYXRlZCBieSBhIHNpbmdsZSBlbmRwb2lu dCAoaW4gcGFydGljdWxhciwgc28gdGhhdCBhbiBSVENXZWIgYnJvd3NlciBjb3VsZCBpbnRlcm9w ZXJhdGUgd2l0aCBlaXRoZXIgYSBzZXJ2ZXIgZ2F0ZXdheSBpbXBsZW1lbnRpbmcgSUNFLWxpdGUg b3IgYSBub24tUlRDV2ViIGVuZHBvaW50IG5vdCBpbXBsZW1lbnRpbmcgdGhlIFJUQ1dlYiBjb25z ZW50IGZyZXNobmVzcyBwcm9jZWR1cmVzIGluIHN1Y2ggYSB3YXkgdGhhdCBvbmx5IHRoZSBSVENX ZWIgYnJvd3NlciBuZWVkZWQgdG8gc2VuZCBwZXJpb2RpYyBiaW5kaW5nIHJlcXVlc3RzIHRvIG1h aW50YWluIGJpbGF0ZXJhbCBjb25zZW50IGZyZXNobmVzcykuPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+RG9lcyBhIGJpbmRpbmcgcmVxdWVzdCBw cm92aWRlIHVuaWxhdGVyYWwgb3IgYmlsYXRlcmFsIGNvbnNlbnQgdmVyaWZpY2F0aW9uL2ZyZXNo bmVzcz88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5JcyBhIHNlcnZlciBnYXRld2F5IGltcGxlbWVudGluZyBJQ0UtbGl0ZSByZXF1aXJlZCB0byBz ZW5kIElDRSBiaW5kaW5nIHJlcXVlc3RzIGFueXdheSBmb3IgY29uc2VudCB2ZXJpZmljYXRpb24g YW5kL29yIGNvbnNlbnQgZnJlc2huZXNzLCBvciBpcyBpdCBzdWZmaWNpZW50IGZvciBzdWNoIGFu IGltcGxlbWVudGF0aW9uIHRvIGluZGljYXRlIGl0cyBvd24gY29uc2VudCBieSBqdXN0IHJlc3Bv bmRpbmcgdG8gcmVjZWl2ZWQgYmluZGluZyByZXF1ZXN0cz88bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EbyB3ZSBjYXJlIGFib3V0IGNvbXBhdGli aWxpdHkgd2l0aCBJQ0UgY29tcGxpYW50IGVuZHBvaW50cyB0aGF0IGRvIG5vdCB1c2UgYmluZGlu ZyByZXF1ZXN0cyBmb3IgY29uc2VudCBmcmVzaG5lc3M/PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+RG9lcyBhIGJyb3dzZXIgdHJlYXQgYSByZXNw b25zZSB0byBhIGJpbmRpbmcgcmVxdWVzdCB0aGUgc2FtZSBhcyBhIHJlY2VpdmVkIGJpbmRpbmcg cmVxdWVzdCBmb3IgY29uc2VudCBmcmVzaG5lc3M/PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SXQgd291bGQgYmUgaGVscGZ1bCB0byBoYXZlIGNs ZWFyIGFuc3dlcnMgdG8gdGhlc2UgcXVlc3Rpb25zIGluIHRoZSBzZWN1cml0eSBhcmNoaXRlY3R1 cmUgZG9jdW1lbnQuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+VGhhbmtzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJpY2hhcmQgRWp6YWs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D4DFExmbrcdx02ciscoc_-- From bernard_aboba@hotmail.com Mon Jul 16 23:11:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41E911E80BD for ; Mon, 16 Jul 2012 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.727 X-Spam-Level: X-Spam-Status: No, score=-101.727 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVqAaBhmJO9S for ; Mon, 16 Jul 2012 23:11:44 -0700 (PDT) Received: from blu0-omc1-s17.blu0.hotmail.com (blu0-omc1-s17.blu0.hotmail.com [65.55.116.28]) by ietfa.amsl.com (Postfix) with ESMTP id C9E5811E80B7 for ; Mon, 16 Jul 2012 23:11:43 -0700 (PDT) Received: from BLU401-EAS427 ([65.55.116.7]) by blu0-omc1-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 23:12:30 -0700 X-Originating-IP: [24.16.96.166] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <03FBA798AC24E3498B74F47FD082A92F17709B1B@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Transfer-Encoding: 7bit From: Bernard Aboba Content-Type: multipart/alternative; boundary="Apple-Mail-EAD7C932-A9AD-4FBD-925F-35942A13A7E0" In-Reply-To: Date: Mon, 16 Jul 2012 23:16:44 -0700 To: "Muthu Arul Mozhi Perumal (mperumal)" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 17 Jul 2012 06:12:30.0331 (UTC) FILETIME=[259BDCB0:01CD63E3] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness and ICE-lite X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 06:11:45 -0000 --Apple-Mail-EAD7C932-A9AD-4FBD-925F-35942A13A7E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Since it's a gateway not a browser, presumably it doesn't support JavaScript= . So there is no "application" an attacker can run on the gateway, there i= s just (static) gateway code. On Jul 16, 2012, at 22:43, "Muthu Arul Mozhi Perumal (mperumal)" wrote: > Right, consent is requested by the sender and granted by the receiver. Whi= le one side has granted consent for receiving on a candidate pair, the other= side could have revoked it. So consent verification/freshness is unilateral= . > =20 > A gateway/browser implementing ICE-lite will only be able to grant consent= to send, but will not be able to request consent. So, a malicious applicati= on can use it for sending unwanted traffic. > =20 > Liveness determines continued connectivity on a candidate pair. Since the n= etworks paths can be asymmetric, both ends need to perform the liveness test= . > =20 > Muthu > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f Bernard Aboba > Sent: Tuesday, July 17, 2012 9:03 AM > To: Ejzak, Richard P (Richard) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] consent freshness and ICE-lite > =20 > Consent freshness and liveness is used to assure a browser that the recipi= ent has authorized it to=20 > send media and that it is still there. So if a gateway wants to receive, a= nswer Binding Requests=20 > sent to it. =20 >=20 >=20 > If a gateway is on the public Internet, supports ICE lite and does not sen= d a Binding Request=20 > to a browser, but does implement RFC 6263, then NAT bindings can be kept a= live and media=20 > should still flow. So I think this is viable. > =20 >=20 >=20 > On Jul 16, 2012, at 18:13, "Ejzak, Richard P (Richard)" wrote: >=20 > Sections 4.2, 4.4 and 5.3 of draft-ietf-rtcweb-security-arch-03.txt have t= ext that seems to be contradictory. In particular, 5.3 requires support of I= CE-lite at server gateways but each endpoint is described as sending ICE bin= ding requests for ICE consent verification in 4.2 (which is it?). 4.4 also r= equires RTCWeb implementations to perform periodic binding requests to verif= y consent freshness. Is a server gateway an RTCWeb implementation subject t= o this requirement? I thought that one of the reasons the WG decided to use= binding requests instead of binding indications to allow bilateral consent i= nitiated by a single endpoint (in particular, so that an RTCWeb browser coul= d interoperate with either a server gateway implementing ICE-lite or a non-R= TCWeb endpoint not implementing the RTCWeb consent freshness procedures in s= uch a way that only the RTCWeb browser needed to send periodic binding reque= sts to maintain bilateral consent freshness). > =20 > Does a binding request provide unilateral or bilateral consent verificatio= n/freshness? > =20 > Is a server gateway implementing ICE-lite required to send ICE binding req= uests anyway for consent verification and/or consent freshness, or is it suf= ficient for such an implementation to indicate its own consent by just respo= nding to received binding requests? > =20 > Do we care about compatibility with ICE compliant endpoints that do not us= e binding requests for consent freshness? > =20 > Does a browser treat a response to a binding request the same as a receive= d binding request for consent freshness? > =20 > It would be helpful to have clear answers to these questions in the securi= ty architecture document. > =20 > Thanks, > Richard Ejzak > =20 > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-EAD7C932-A9AD-4FBD-925F-35942A13A7E0 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+U2luY2UgaXQn cyBhIGdhdGV3YXkgbm90IGEgYnJvd3NlciwgcHJlc3VtYWJseSBpdCBkb2Vzbid0IHN1cHBvcnQg SmF2YVNjcmlwdC4gJm5ic3A7U28gdGhlcmUgaXMgbm8gImFwcGxpY2F0aW9uIiZuYnNwOzxzcGFu IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNv bG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjk2ODc1KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxs LWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlv bi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgIj4mbmJzcDthbiBh dHRhY2tlciBjYW4gcnVuIG9uIHRoZSBnYXRld2F5LCB0aGVyZSBpcyBqdXN0IChzdGF0aWMpIGdh dGV3YXkgY29kZS48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5PbiBKdWwgMTYsIDIw MTIsIGF0IDIyOjQzLCAiTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkiICZsdDs8 YSBocmVmPSJtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tIj5tcGVydW1hbEBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGRpdj4NCg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkZ1dHVyYUEgQmsg QlQiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkZ1dHVyYUEgQmsgQlQiO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM2MDY0MjA7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2lu OjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQoNCg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SaWdodCwgY29uc2VudCBpcyByZXF1ZXN0ZWQgYnkgdGhl IHNlbmRlciBhbmQgZ3JhbnRlZCBieSB0aGUgcmVjZWl2ZXIuIFdoaWxlIG9uZSBzaWRlIGhhcyBn cmFudGVkIGNvbnNlbnQgZm9yIHJlY2VpdmluZyBvbiBhIGNhbmRpZGF0ZSBwYWlyLCB0aGUgb3Ro ZXIgc2lkZSBjb3VsZCBoYXZlIHJldm9rZWQgaXQuDQogU28gY29uc2VudCB2ZXJpZmljYXRpb24v ZnJlc2huZXNzIGlzIHVuaWxhdGVyYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BIGdhdGV3YXkvYnJvd3NlciBpbXBsZW1lbnRpbmcg SUNFLWxpdGUgd2lsbCBvbmx5IGJlIGFibGUgdG8gZ3JhbnQgY29uc2VudCB0byBzZW5kLCBidXQg d2lsbCBub3QgYmUgYWJsZSB0byByZXF1ZXN0IGNvbnNlbnQuIFNvLCBhIG1hbGljaW91cyBhcHBs aWNhdGlvbiBjYW4gdXNlIGl0IGZvciBzZW5kaW5nIHVud2FudGVkDQogdHJhZmZpYy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkxpdmVu ZXNzIGRldGVybWluZXMgY29udGludWVkIGNvbm5lY3Rpdml0eSBvbiBhIGNhbmRpZGF0ZSBwYWly LiBTaW5jZSB0aGUgbmV0d29ya3MgcGF0aHMgY2FuIGJlIGFzeW1tZXRyaWMsIGJvdGggZW5kcyBu ZWVkIHRvIHBlcmZvcm0gdGhlIGxpdmVuZXNzIHRlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NdXRodTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA8YSBo cmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPnJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnPC9hPiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5CZXJuYXJkIEFib2JhPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTcsIDIw MTIgOTowMyBBTTxicj4NCjxiPlRvOjwvYj4gRWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCk8YnI+ DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIGNvbnNlbnQgZnJlc2hu ZXNzIGFuZCBJQ0UtbGl0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Db25zZW50IGZyZXNobmVzcyBhbmQgbGl2ZW5lc3MgaXMgdXNlZCB0byBh c3N1cmUgYSBicm93c2VyIHRoYXQgdGhlIHJlY2lwaWVudCBoYXMgYXV0aG9yaXplZCBpdCB0byZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ c2VuZCBtZWRpYSBhbmQgdGhhdCBpdCBpcyBzdGlsbCB0aGVyZS4mbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+U28gaWYgYSBnYXRld2F5IHdhbnRzIHRvIHJlY2VpdmUsIGFuc3dl ciBCaW5kaW5nIFJlcXVlc3RzJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4i PnNlbnQgdG8gaXQuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNw YW4iPklmIGEgZ2F0ZXdheSBpcyBvbiB0aGUgcHVibGljIEludGVybmV0LCBzdXBwb3J0cyBJQ0Ug bGl0ZSBhbmQgZG9lcyBub3Qgc2VuZCBhIEJpbmRpbmcgUmVxdWVzdCZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS1zdHlsZS1zcGFuIj50byBhIGJyb3dzZXIsIGJ1dCBkb2VzIGltcGxlbWVudCBS RkMgNjI2MywmbmJzcDt0aGVuIE5BVCBiaW5kaW5ncyBjYW4gYmUga2VwdCBhbGl2ZSBhbmQgbWVk aWEmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+c2hvdWxkIHN0aWxsIGZs b3cuICZuYnNwO1NvIEkgdGhpbmsgdGhpcyBpcyB2aWFibGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDE2 LCAyMDEyLCBhdCAxODoxMywgIkVqemFrLCBSaWNoYXJkIFAgKFJpY2hhcmQpIiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJpY2hhcmQuZWp6YWtAYWxjYXRlbC1sdWNlbnQuY29tIj5yaWNoYXJkLmVqemFr QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cHJlPlNlY3Rpb25zIDQuMiwgNC40IGFuZCA1LjMgb2YgZHJhZnQtaWV0Zi1y dGN3ZWItc2VjdXJpdHktYXJjaC0wMy50eHQgaGF2ZSB0ZXh0IHRoYXQgc2VlbXMgdG8gYmUgY29u dHJhZGljdG9yeS4gJm5ic3A7SW4gcGFydGljdWxhciwgNS4zIHJlcXVpcmVzIHN1cHBvcnQgb2Yg SUNFLWxpdGUgYXQgc2VydmVyIGdhdGV3YXlzIGJ1dCBlYWNoIGVuZHBvaW50IGlzIGRlc2NyaWJl ZCBhcyBzZW5kaW5nIElDRSBiaW5kaW5nIHJlcXVlc3RzIGZvciBJQ0UgY29uc2VudCB2ZXJpZmlj YXRpb24gaW4gNC4yICh3aGljaCBpcyBpdD8pLiAmbmJzcDs0LjQgYWxzbyByZXF1aXJlcyBSVENX ZWIgaW1wbGVtZW50YXRpb25zIHRvIHBlcmZvcm0gcGVyaW9kaWMgYmluZGluZyByZXF1ZXN0cyB0 byB2ZXJpZnkgY29uc2VudCBmcmVzaG5lc3MuICZuYnNwO0lzIGEgc2VydmVyIGdhdGV3YXkgYW4g UlRDV2ViIGltcGxlbWVudGF0aW9uIHN1YmplY3QgdG8gdGhpcyByZXF1aXJlbWVudD8gJm5ic3A7 SSB0aG91Z2h0IHRoYXQgb25lIG9mIHRoZSByZWFzb25zIHRoZSBXRyBkZWNpZGVkIHRvIHVzZSBi aW5kaW5nIHJlcXVlc3RzIGluc3RlYWQgb2YgYmluZGluZyBpbmRpY2F0aW9ucyB0byBhbGxvdyBi aWxhdGVyYWwgY29uc2VudCBpbml0aWF0ZWQgYnkgYSBzaW5nbGUgZW5kcG9pbnQgKGluIHBhcnRp Y3VsYXIsIHNvIHRoYXQgYW4gUlRDV2ViIGJyb3dzZXIgY291bGQgaW50ZXJvcGVyYXRlIHdpdGgg ZWl0aGVyIGEgc2VydmVyIGdhdGV3YXkgaW1wbGVtZW50aW5nIElDRS1saXRlIG9yIGEgbm9uLVJU Q1dlYiBlbmRwb2ludCBub3QgaW1wbGVtZW50aW5nIHRoZSBSVENXZWIgY29uc2VudCBmcmVzaG5l c3MgcHJvY2VkdXJlcyBpbiBzdWNoIGEgd2F5IHRoYXQgb25seSB0aGUgUlRDV2ViIGJyb3dzZXIg bmVlZGVkIHRvIHNlbmQgcGVyaW9kaWMgYmluZGluZyByZXF1ZXN0cyB0byBtYWludGFpbiBiaWxh dGVyYWwgY29uc2VudCBmcmVzaG5lc3MpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRvZXMgYSBiaW5kaW5nIHJlcXVlc3QgcHJvdmlkZSB1bmls YXRlcmFsIG9yIGJpbGF0ZXJhbCBjb25zZW50IHZlcmlmaWNhdGlvbi9mcmVzaG5lc3M/PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SXMgYSBzZXJ2 ZXIgZ2F0ZXdheSBpbXBsZW1lbnRpbmcgSUNFLWxpdGUgcmVxdWlyZWQgdG8gc2VuZCBJQ0UgYmlu ZGluZyByZXF1ZXN0cyBhbnl3YXkgZm9yIGNvbnNlbnQgdmVyaWZpY2F0aW9uIGFuZC9vciBjb25z ZW50IGZyZXNobmVzcywgb3IgaXMgaXQgc3VmZmljaWVudCBmb3Igc3VjaCBhbiBpbXBsZW1lbnRh dGlvbiB0byBpbmRpY2F0ZSBpdHMgb3duIGNvbnNlbnQgYnkganVzdCByZXNwb25kaW5nIHRvIHJl Y2VpdmVkIGJpbmRpbmcgcmVxdWVzdHM/PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmU+RG8gd2UgY2FyZSBhYm91dCBjb21wYXRpYmlsaXR5IHdpdGgg SUNFIGNvbXBsaWFudCBlbmRwb2ludHMgdGhhdCBkbyBub3QgdXNlIGJpbmRpbmcgcmVxdWVzdHMg Zm9yIGNvbnNlbnQgZnJlc2huZXNzPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkRvZXMgYSBicm93c2VyIHRyZWF0IGEgcmVzcG9uc2UgdG8gYSBi aW5kaW5nIHJlcXVlc3QgdGhlIHNhbWUgYXMgYSByZWNlaXZlZCBiaW5kaW5nIHJlcXVlc3QgZm9y IGNvbnNlbnQgZnJlc2huZXNzPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSBjbGVhciBhbnN3ZXJz IHRvIHRoZXNlIHF1ZXN0aW9ucyBpbiB0aGUgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlIGRvY3VtZW50 LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRo YW5rcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SaWNoYXJkIEVqemFrPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dl YiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3 ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-EAD7C932-A9AD-4FBD-925F-35942A13A7E0-- From mperumal@cisco.com Tue Jul 17 00:37:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B122F21F85C5 for ; Tue, 17 Jul 2012 00:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXm7f0R5YxqX for ; Tue, 17 Jul 2012 00:37:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3313521F85AF for ; Tue, 17 Jul 2012 00:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3344; q=dns/txt; s=iport; t=1342510675; x=1343720275; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+hBQMxvEYDau1IKk+qB/EXSau4MCwFgkfWDs9h00BUs=; b=V9foBG4Deqjz8vf7i8+ws4mVeg6bDiIRQddL3i71Osi3Ou2MMtm+n/Fb JqjYmWrT4EJ00vf4LaYKF0/9yjVy+PsyjzO52X5eJcdSZ1yK5lueZNo/m Q5/tvimE91jUX+bAiWcV/YhTn+3hHnFMLtuLxNA77ZOn/9YDk4+kxEb+D 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEYVBVCtJV2a/2dsb2JhbABFuWCBB4IgAQEBBAEBAQ8BJzQXBgEIEQQBAQsUCS4LFAcBAQUFBBMIARIHh2sLmwSBKKApiz6FZ2ADlk2JdYMZgWaCXw X-IronPort-AV: E=Sophos;i="4.77,599,1336348800"; d="scan'208";a="102528707" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2012 07:37:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6H7bs6C019001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Jul 2012 07:37:54 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 02:37:54 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-muthu-behave-consent-freshness-01.txt Thread-Index: AQHNY211pZ5zmVz19UG3CqD7N+7epZcs+oNw Date: Tue, 17 Jul 2012 07:37:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.155] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--47.762200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 07:37:09 -0000 The draft has been updated based on the mailing list discussions and Eric's= security presentation at the RTCWEB interim meeting. The sections that hav= e been updated/added: 1. Abstract Adds session liveness 2. Introduction=20 Adds session liveness 3. Definitions Defines session liveness 4. Solution Overview Discusses the combined consent freshness and session liveness=20 test (slide "Combined Consent/Liveness Proposal II" from the=20 RTCWEB interim). 5. Design Considerations Discusses the pros and cons of reusing the STUN Binding request/response 6. Open Items Lists the current open issues. While we have been discussing on a separate ICE spec/profile for RTCWEB, I = would like to close on the smaller problem of our next steps for this draft= . Issues we need consensus on to move forward: 1. Should we reuse the STUN Binding request/response for consent freshness = and session liveness, considering interoperability with existing ICE and IC= E-lite implementations even at the incurred cost of the SHA-1 computation f= or the message integrity on gateways? Seems to be a "yes" from the mailing = list discussions so far. Any concerns? 2. Where does this draft really belong to? Considering that the use-case is= relevant to WebRTC and we many not significantly change any BEHAVE protoco= l, should it be resubmitted to RTCWEB? Muthu -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 16, 2012 9:39 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-muthu-behave-consent-freshness-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : STUN Usage for Consent Freshness and Session Liveness Author(s) : Muthu Arul Mozhi Perumal Dan Wing Hadriel Kaplan Filename : draft-muthu-behave-consent-freshness-01.txt Pages : 9 Date : 2012-07-16 Abstract: Verification of peer consent 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 applications may want to detect connection failure and take appropriate actions. This document describes a STUN usage that enables a WebRTC browser to perform the following on a candidate pair ICE is using for a media component after session establishment: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness There's also a htmlized version available at: http://tools.ietf.org/html/draft-muthu-behave-consent-freshness-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-muthu-behave-consent-freshness-0= 1 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From csp@csperkins.org Tue Jul 17 02:31:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2496C21F86A2 for ; Tue, 17 Jul 2012 02:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keBvyq-vmOwo for ; Tue, 17 Jul 2012 02:31:53 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2D21F8698 for ; Tue, 17 Jul 2012 02:31:53 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Sr491-000410-bE; Tue, 17 Jul 2012 09:32:39 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Tue, 17 Jul 2012 10:32:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4702C2-49DD-47C8-9F9E-DF93103CF640@csperkins.org> References: To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP usage: requirement levels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 09:31:54 -0000 Martin, If you have suggestions for specific changes where the recommendations = in the draft are unclear, we'd be happy to receive them. The = classifications you suggest below are not appropriate for all the = normative statements in the draft, so it's not clear exactly what you = think needs to change. Colin On 16 Jul 2012, at 19:38, Martin Thomson wrote: > The RTP usage draft current uses MUST, SHOULD, MAY to indicate two > levels of compliance. This is not a particularly good division for > this sort of draft. >=20 > Firstly, it's unclear what meaningful distinction there is between > SHOULD and MAY. Then there is the distinction between MUST implement > and MUST use. >=20 > The following classifications are more relevant to this sort of draft. >=20 > mandatory to USE > - all implementations MUST always use this feature > - there is no reason to signal support for the feature > - there is no reason to provide a means to disable it > - no API requirements need to be derived for features that are = mandatory to use >=20 > mandatory to IMPLEMENT > - all implementations MUST include support for the feature > - implementations MUST provide a means to enable and disable the > feature (API requirement) > - there is no API requirement for indicating support of the feature >=20 > mandatory to DISABLE > - implementations MAY include support for the feature > - implementations MUST provide a means to signal support for the > feature (API requirement) > - implementations that support the feature MUST provide a means to > enable and disable the feature (optional API requirement) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From mperumal@cisco.com Tue Jul 17 02:43:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8E421F8528 for ; Tue, 17 Jul 2012 02:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk07gFwtThoN for ; Tue, 17 Jul 2012 02:43:24 -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 A35E821F8541 for ; Tue, 17 Jul 2012 02:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=21964; q=dns/txt; s=iport; t=1342518251; x=1343727851; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ScMAdxSJpDyzJ+8caNTEduzBLRaMAD8+KsGyJy/JyCs=; b=T6o9rv9M4eIMhWjBwxnhB4mnZre3BPaa9d8W7POaK1Fbw13x48GfKLGv 1Q5ccgUhEpBpjU4kttJMFnyrrY78uAy6iRLZBra7JoNx4JOZ16BfynPEL sEAhGBgwy7+/7qKSdpJ4l2SDlV110+VCwqozV0QU3j1b/gq/YeWQ/nr2G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIAzBVCtJV2d/2dsb2JhbABFgkqDIKJdj3CBFoEHgiABAQEEAQEBDwEQCkELEAIBCBEBAwEBCx0DAgICJQsUAwYIAgQOBQgah1wDDAucQI0Zkw0EiltlhTUyYAOgQ4McgWaCX4FWBxo X-IronPort-AV: E=Sophos;i="4.77,601,1336348800"; d="scan'208,217";a="102551497" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jul 2012 09:44:10 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6H9iAlu003241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 09:44:10 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 04:44:09 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Bernard Aboba Thread-Topic: [rtcweb] consent freshness and ICE-lite Thread-Index: AQHNY8w9W2cZs2lHjUu9YW6rsDo7W5cs7BwAgABnlgD//9wgYA== Date: Tue, 17 Jul 2012 09:44:09 +0000 Message-ID: References: <03FBA798AC24E3498B74F47FD082A92F17709B1B@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.84.166] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--51.995600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D5574xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness and ICE-lite X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 09:43:27 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D5574xmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGdhdGV3YXlzIHRoYXQgcnVuIGFwcGxpY2F0aW9ucyBsaWtlIFRDTCBhbmQgWE1M IHNjcmlwdHMgd3JpdHRlbiBieSB1c2Vycy4gVGhleSBhcmUgdHlwaWNhbGx5IGRlcGxveWVkIGlu IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyBydW5uaW5nIHRydXN0ZWQgc2NyaXB0cywgc28gZ2Vu ZXJhbGx5IG5vdCBhbiBpc3N1ZS4gVGhhdCBkb2Vzbid0IGhvd2V2ZXIgcHJlY2x1ZGUgYSBkZXBs b3ltZW50IHdoZXJlIHRoZSBnYXRld2F5IHJ1bnMgdW50cnVzdGVkIHNjcmlwdHMgb3IgYSBicm93 c2VyIC06KQ0KDQpXaGlsZSBwZXJmb3JtaW5nIGNvbnNlbnQgZnJlc2huZXNzIGFuZCBsaXZlbmVz cyB0ZXN0cyBhcmUgbWFuZGF0b3J5IGZvciBhIFdlYlJUQyBicm93c2VyLCBpdCBpcyBvcHRpb25h bCBmb3IgYSBnYXRld2F5LCBJIGJlbGlldmUuDQoNCk11dGh1DQoNCkZyb206IEJlcm5hcmQgQWJv YmEgW21haWx0bzpiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tXQ0KU2VudDogVHVlc2RheSwgSnVs eSAxNywgMjAxMiAxMTo0NyBBTQ0KVG86IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVt YWwpDQpDYzogRWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCk7IHJ0Y3dlYkBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtydGN3ZWJdIGNvbnNlbnQgZnJlc2huZXNzIGFuZCBJQ0UtbGl0ZQ0KDQpTaW5j ZSBpdCdzIGEgZ2F0ZXdheSBub3QgYSBicm93c2VyLCBwcmVzdW1hYmx5IGl0IGRvZXNuJ3Qgc3Vw cG9ydCBKYXZhU2NyaXB0LiAgU28gdGhlcmUgaXMgbm8gImFwcGxpY2F0aW9uIiAgYW4gYXR0YWNr ZXIgY2FuIHJ1biBvbiB0aGUgZ2F0ZXdheSwgdGhlcmUgaXMganVzdCAoc3RhdGljKSBnYXRld2F5 IGNvZGUuDQoNCk9uIEp1bCAxNiwgMjAxMiwgYXQgMjI6NDMsICJNdXRodSBBcnVsIE1vemhpIFBl cnVtYWwgKG1wZXJ1bWFsKSIgPG1wZXJ1bWFsQGNpc2NvLmNvbTxtYWlsdG86bXBlcnVtYWxAY2lz Y28uY29tPj4gd3JvdGU6DQpSaWdodCwgY29uc2VudCBpcyByZXF1ZXN0ZWQgYnkgdGhlIHNlbmRl ciBhbmQgZ3JhbnRlZCBieSB0aGUgcmVjZWl2ZXIuIFdoaWxlIG9uZSBzaWRlIGhhcyBncmFudGVk IGNvbnNlbnQgZm9yIHJlY2VpdmluZyBvbiBhIGNhbmRpZGF0ZSBwYWlyLCB0aGUgb3RoZXIgc2lk ZSBjb3VsZCBoYXZlIHJldm9rZWQgaXQuIFNvIGNvbnNlbnQgdmVyaWZpY2F0aW9uL2ZyZXNobmVz cyBpcyB1bmlsYXRlcmFsLg0KDQpBIGdhdGV3YXkvYnJvd3NlciBpbXBsZW1lbnRpbmcgSUNFLWxp dGUgd2lsbCBvbmx5IGJlIGFibGUgdG8gZ3JhbnQgY29uc2VudCB0byBzZW5kLCBidXQgd2lsbCBu b3QgYmUgYWJsZSB0byByZXF1ZXN0IGNvbnNlbnQuIFNvLCBhIG1hbGljaW91cyBhcHBsaWNhdGlv biBjYW4gdXNlIGl0IGZvciBzZW5kaW5nIHVud2FudGVkIHRyYWZmaWMuDQoNCkxpdmVuZXNzIGRl dGVybWluZXMgY29udGludWVkIGNvbm5lY3Rpdml0eSBvbiBhIGNhbmRpZGF0ZSBwYWlyLiBTaW5j ZSB0aGUgbmV0d29ya3MgcGF0aHMgY2FuIGJlIGFzeW1tZXRyaWMsIGJvdGggZW5kcyBuZWVkIHRv IHBlcmZvcm0gdGhlIGxpdmVuZXNzIHRlc3QuDQoNCk11dGh1DQoNCkZyb206IHJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5hcmQgQWJvYmENClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMTcsIDIwMTIgOTowMyBBTQ0KVG86IEVqemFrLCBSaWNoYXJkIFAgKFJpY2hh cmQpDQpDYzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gY29uc2VudCBmcmVzaG5lc3MgYW5kIElDRS1saXRlDQoNCkNvbnNlbnQg ZnJlc2huZXNzIGFuZCBsaXZlbmVzcyBpcyB1c2VkIHRvIGFzc3VyZSBhIGJyb3dzZXIgdGhhdCB0 aGUgcmVjaXBpZW50IGhhcyBhdXRob3JpemVkIGl0IHRvDQpzZW5kIG1lZGlhIGFuZCB0aGF0IGl0 IGlzIHN0aWxsIHRoZXJlLiBTbyBpZiBhIGdhdGV3YXkgd2FudHMgdG8gcmVjZWl2ZSwgYW5zd2Vy IEJpbmRpbmcgUmVxdWVzdHMNCnNlbnQgdG8gaXQuDQoNCg0KDQpJZiBhIGdhdGV3YXkgaXMgb24g dGhlIHB1YmxpYyBJbnRlcm5ldCwgc3VwcG9ydHMgSUNFIGxpdGUgYW5kIGRvZXMgbm90IHNlbmQg YSBCaW5kaW5nIFJlcXVlc3QNCnRvIGEgYnJvd3NlciwgYnV0IGRvZXMgaW1wbGVtZW50IFJGQyA2 MjYzLCB0aGVuIE5BVCBiaW5kaW5ncyBjYW4gYmUga2VwdCBhbGl2ZSBhbmQgbWVkaWENCnNob3Vs ZCBzdGlsbCBmbG93LiAgU28gSSB0aGluayB0aGlzIGlzIHZpYWJsZS4NCg0KDQpPbiBKdWwgMTYs IDIwMTIsIGF0IDE4OjEzLCAiRWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCkiIDxyaWNoYXJkLmVq emFrQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86cmljaGFyZC5lanpha0BhbGNhdGVsLWx1Y2Vu dC5jb20+PiB3cm90ZToNCg0KU2VjdGlvbnMgNC4yLCA0LjQgYW5kIDUuMyBvZiBkcmFmdC1pZXRm LXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTAzLnR4dCBoYXZlIHRleHQgdGhhdCBzZWVtcyB0byBiZSBj b250cmFkaWN0b3J5LiAgSW4gcGFydGljdWxhciwgNS4zIHJlcXVpcmVzIHN1cHBvcnQgb2YgSUNF LWxpdGUgYXQgc2VydmVyIGdhdGV3YXlzIGJ1dCBlYWNoIGVuZHBvaW50IGlzIGRlc2NyaWJlZCBh cyBzZW5kaW5nIElDRSBiaW5kaW5nIHJlcXVlc3RzIGZvciBJQ0UgY29uc2VudCB2ZXJpZmljYXRp b24gaW4gNC4yICh3aGljaCBpcyBpdD8pLiAgNC40IGFsc28gcmVxdWlyZXMgUlRDV2ViIGltcGxl bWVudGF0aW9ucyB0byBwZXJmb3JtIHBlcmlvZGljIGJpbmRpbmcgcmVxdWVzdHMgdG8gdmVyaWZ5 IGNvbnNlbnQgZnJlc2huZXNzLiAgSXMgYSBzZXJ2ZXIgZ2F0ZXdheSBhbiBSVENXZWIgaW1wbGVt ZW50YXRpb24gc3ViamVjdCB0byB0aGlzIHJlcXVpcmVtZW50PyAgSSB0aG91Z2h0IHRoYXQgb25l IG9mIHRoZSByZWFzb25zIHRoZSBXRyBkZWNpZGVkIHRvIHVzZSBiaW5kaW5nIHJlcXVlc3RzIGlu c3RlYWQgb2YgYmluZGluZyBpbmRpY2F0aW9ucyB0byBhbGxvdyBiaWxhdGVyYWwgY29uc2VudCBp bml0aWF0ZWQgYnkgYSBzaW5nbGUgZW5kcG9pbnQgKGluIHBhcnRpY3VsYXIsIHNvIHRoYXQgYW4g UlRDV2ViIGJyb3dzZXIgY291bGQgaW50ZXJvcGVyYXRlIHdpdGggZWl0aGVyIGEgc2VydmVyIGdh dGV3YXkgaW1wbGVtZW50aW5nIElDRS1saXRlIG9yIGEgbm9uLVJUQ1dlYiBlbmRwb2ludCBub3Qg aW1wbGVtZW50aW5nIHRoZSBSVENXZWIgY29uc2VudCBmcmVzaG5lc3MgcHJvY2VkdXJlcyBpbiBz dWNoIGEgd2F5IHRoYXQgb25seSB0aGUgUlRDV2ViIGJyb3dzZXIgbmVlZGVkIHRvIHNlbmQgcGVy aW9kaWMgYmluZGluZyByZXF1ZXN0cyB0byBtYWludGFpbiBiaWxhdGVyYWwgY29uc2VudCBmcmVz aG5lc3MpLg0KDQoNCg0KRG9lcyBhIGJpbmRpbmcgcmVxdWVzdCBwcm92aWRlIHVuaWxhdGVyYWwg b3IgYmlsYXRlcmFsIGNvbnNlbnQgdmVyaWZpY2F0aW9uL2ZyZXNobmVzcz8NCg0KDQoNCklzIGEg c2VydmVyIGdhdGV3YXkgaW1wbGVtZW50aW5nIElDRS1saXRlIHJlcXVpcmVkIHRvIHNlbmQgSUNF IGJpbmRpbmcgcmVxdWVzdHMgYW55d2F5IGZvciBjb25zZW50IHZlcmlmaWNhdGlvbiBhbmQvb3Ig Y29uc2VudCBmcmVzaG5lc3MsIG9yIGlzIGl0IHN1ZmZpY2llbnQgZm9yIHN1Y2ggYW4gaW1wbGVt ZW50YXRpb24gdG8gaW5kaWNhdGUgaXRzIG93biBjb25zZW50IGJ5IGp1c3QgcmVzcG9uZGluZyB0 byByZWNlaXZlZCBiaW5kaW5nIHJlcXVlc3RzPw0KDQoNCg0KRG8gd2UgY2FyZSBhYm91dCBjb21w YXRpYmlsaXR5IHdpdGggSUNFIGNvbXBsaWFudCBlbmRwb2ludHMgdGhhdCBkbyBub3QgdXNlIGJp bmRpbmcgcmVxdWVzdHMgZm9yIGNvbnNlbnQgZnJlc2huZXNzPw0KDQoNCg0KRG9lcyBhIGJyb3dz ZXIgdHJlYXQgYSByZXNwb25zZSB0byBhIGJpbmRpbmcgcmVxdWVzdCB0aGUgc2FtZSBhcyBhIHJl Y2VpdmVkIGJpbmRpbmcgcmVxdWVzdCBmb3IgY29uc2VudCBmcmVzaG5lc3M/DQoNCg0KDQpJdCB3 b3VsZCBiZSBoZWxwZnVsIHRvIGhhdmUgY2xlYXIgYW5zd2VycyB0byB0aGVzZSBxdWVzdGlvbnMg aW4gdGhlIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBkb2N1bWVudC4NCg0KDQoNClRoYW5rcywNCg0K UmljaGFyZCBFanphaw0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViDQo= --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D5574xmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJGdXR1cmFBIEJrIEJUIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJGdXR1cmFBIEJr IEJUIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojNjA2NDIwOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46MS4w aW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9IiM2MDY0MjAiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGVyZSBhcmUgZ2F0ZXdheXMgdGhhdCBy dW4gYXBwbGljYXRpb25zIGxpa2UgVENMIGFuZCBYTUwgc2NyaXB0cyB3cml0dGVuIGJ5IHVzZXJz LiBUaGV5IGFyZSB0eXBpY2FsbHkgZGVwbG95ZWQgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRz IHJ1bm5pbmcgdHJ1c3RlZCBzY3JpcHRzLCBzbyBnZW5lcmFsbHkgbm90DQogYW4gaXNzdWUuIFRo YXQgZG9lc24ndCBob3dldmVyIHByZWNsdWRlIGEgZGVwbG95bWVudCB3aGVyZSB0aGUgZ2F0ZXdh eSBydW5zIHVudHJ1c3RlZCBzY3JpcHRzIG9yIGEgYnJvd3NlciAtOik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoaWxlIHBlcmZvcm1p bmcgY29uc2VudCBmcmVzaG5lc3MgYW5kIGxpdmVuZXNzIHRlc3RzIGFyZSBtYW5kYXRvcnkgZm9y IGEgV2ViUlRDIGJyb3dzZXIsIGl0IGlzIG9wdGlvbmFsIGZvciBhIGdhdGV3YXksIEkgYmVsaWV2 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPk11dGh1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkX2Fib2Jh QGhvdG1haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTIg MTE6NDcgQU08YnI+DQo8Yj5Ubzo8L2I+IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVt YWwpPGJyPg0KPGI+Q2M6PC9iPiBFanphaywgUmljaGFyZCBQIChSaWNoYXJkKTsgcnRjd2ViQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBjb25zZW50IGZyZXNobmVz cyBhbmQgSUNFLWxpdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2luY2UgaXQncyBhIGdhdGV3YXkgbm90IGEgYnJvd3NlciwgcHJlc3VtYWJs eSBpdCBkb2Vzbid0IHN1cHBvcnQgSmF2YVNjcmlwdC4gJm5ic3A7U28gdGhlcmUgaXMgbm8gJnF1 b3Q7YXBwbGljYXRpb24mcXVvdDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+ Jm5ic3A7YW4gYXR0YWNrZXIgY2FuIHJ1biBvbiB0aGUgZ2F0ZXdheSwgdGhlcmUgaXMganVzdCAo c3RhdGljKSBnYXRld2F5IGNvZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9u IEp1bCAxNiwgMjAxMiwgYXQgMjI6NDMsICZxdW90O011dGh1IEFydWwgTW96aGkgUGVydW1hbCAo bXBlcnVtYWwpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tIj5t cGVydW1hbEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJpZ2h0LCBjb25zZW50IGlz IHJlcXVlc3RlZCBieSB0aGUgc2VuZGVyIGFuZCBncmFudGVkIGJ5IHRoZSByZWNlaXZlci4gV2hp bGUgb25lIHNpZGUgaGFzIGdyYW50ZWQgY29uc2VudCBmb3IgcmVjZWl2aW5nIG9uIGEgY2FuZGlk YXRlIHBhaXIsIHRoZSBvdGhlciBzaWRlIGNvdWxkIGhhdmUgcmV2b2tlZCBpdC4NCiBTbyBjb25z ZW50IHZlcmlmaWNhdGlvbi9mcmVzaG5lc3MgaXMgdW5pbGF0ZXJhbC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkEgZ2F0ZXdheS9icm93 c2VyIGltcGxlbWVudGluZyBJQ0UtbGl0ZSB3aWxsIG9ubHkgYmUgYWJsZSB0byBncmFudCBjb25z ZW50IHRvIHNlbmQsIGJ1dCB3aWxsIG5vdCBiZSBhYmxlIHRvIHJlcXVlc3QgY29uc2VudC4gU28s IGEgbWFsaWNpb3VzIGFwcGxpY2F0aW9uIGNhbiB1c2UgaXQgZm9yIHNlbmRpbmcgdW53YW50ZWQN CiB0cmFmZmljLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+TGl2ZW5lc3MgZGV0ZXJtaW5lcyBjb250aW51ZWQgY29ubmVjdGl2aXR5IG9u IGEgY2FuZGlkYXRlIHBhaXIuIFNpbmNlIHRoZSBuZXR3b3JrcyBwYXRocyBjYW4gYmUgYXN5bW1l dHJpYywgYm90aCBlbmRzIG5lZWQgdG8gcGVyZm9ybSB0aGUgbGl2ZW5lc3MgdGVzdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk11dGh1 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuYXJkIEFib2JhPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEp1bHkgMTcsIDIwMTIgOTowMyBBTTxicj4NCjxiPlRvOjwvYj4gRWp6YWssIFJpY2hh cmQgUCAoUmljaGFyZCk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3 ZWJdIGNvbnNlbnQgZnJlc2huZXNzIGFuZCBJQ0UtbGl0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25zZW50IGZyZXNobmVzcyBhbmQgbGl2 ZW5lc3MgaXMgdXNlZCB0byBhc3N1cmUgYSBicm93c2VyIHRoYXQgdGhlIHJlY2lwaWVudCBoYXMg YXV0aG9yaXplZCBpdCB0byZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+c2VuZCBtZWRpYSBhbmQgdGhhdCBpdCBpcyBzdGlsbCB0aGVyZS4m bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+U28gaWYgYSBnYXRld2F5IHdhbnRz IHRvIHJlY2VpdmUsIGFuc3dlciBCaW5kaW5nIFJlcXVlc3RzJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXN0eWxlLXNwYW4iPnNlbnQgdG8gaXQuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPklmIGEgZ2F0ZXdheSBpcyBvbiB0aGUgcHVibGlj IEludGVybmV0LCBzdXBwb3J0cyBJQ0UgbGl0ZSBhbmQgZG9lcyBub3Qgc2VuZCBhIEJpbmRpbmcg UmVxdWVzdCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj50byBhIGJyb3dz ZXIsIGJ1dCBkb2VzIGltcGxlbWVudCBSRkMgNjI2MywmbmJzcDt0aGVuIE5BVCBiaW5kaW5ncyBj YW4gYmUga2VwdCBhbGl2ZSBhbmQgbWVkaWEmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+c2hvdWxkIHN0aWxsIGZsb3cuICZuYnNwO1NvIEkgdGhpbmsgdGhpcyBpcyB2aWFi bGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KT24gSnVsIDE2LCAyMDEyLCBhdCAxODoxMywgJnF1b3Q7RWp6YWssIFJp Y2hhcmQgUCAoUmljaGFyZCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYXJkLmVqemFr QGFsY2F0ZWwtbHVjZW50LmNvbSI+cmljaGFyZC5lanpha0BhbGNhdGVsLWx1Y2VudC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHByZT5TZWN0aW9u cyA0LjIsIDQuNCBhbmQgNS4zIG9mIGRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMDMu dHh0IGhhdmUgdGV4dCB0aGF0IHNlZW1zIHRvIGJlIGNvbnRyYWRpY3RvcnkuICZuYnNwO0luIHBh cnRpY3VsYXIsIDUuMyByZXF1aXJlcyBzdXBwb3J0IG9mIElDRS1saXRlIGF0IHNlcnZlciBnYXRl d2F5cyBidXQgZWFjaCBlbmRwb2ludCBpcyBkZXNjcmliZWQgYXMgc2VuZGluZyBJQ0UgYmluZGlu ZyByZXF1ZXN0cyBmb3IgSUNFIGNvbnNlbnQgdmVyaWZpY2F0aW9uIGluIDQuMiAod2hpY2ggaXMg aXQ/KS4gJm5ic3A7NC40IGFsc28gcmVxdWlyZXMgUlRDV2ViIGltcGxlbWVudGF0aW9ucyB0byBw ZXJmb3JtIHBlcmlvZGljIGJpbmRpbmcgcmVxdWVzdHMgdG8gdmVyaWZ5IGNvbnNlbnQgZnJlc2hu ZXNzLiAmbmJzcDtJcyBhIHNlcnZlciBnYXRld2F5IGFuIFJUQ1dlYiBpbXBsZW1lbnRhdGlvbiBz dWJqZWN0IHRvIHRoaXMgcmVxdWlyZW1lbnQ/ICZuYnNwO0kgdGhvdWdodCB0aGF0IG9uZSBvZiB0 aGUgcmVhc29ucyB0aGUgV0cgZGVjaWRlZCB0byB1c2UgYmluZGluZyByZXF1ZXN0cyBpbnN0ZWFk IG9mIGJpbmRpbmcgaW5kaWNhdGlvbnMgdG8gYWxsb3cgYmlsYXRlcmFsIGNvbnNlbnQgaW5pdGlh dGVkIGJ5IGEgc2luZ2xlIGVuZHBvaW50IChpbiBwYXJ0aWN1bGFyLCBzbyB0aGF0IGFuIFJUQ1dl YiBicm93c2VyIGNvdWxkIGludGVyb3BlcmF0ZSB3aXRoIGVpdGhlciBhIHNlcnZlciBnYXRld2F5 IGltcGxlbWVudGluZyBJQ0UtbGl0ZSBvciBhIG5vbi1SVENXZWIgZW5kcG9pbnQgbm90IGltcGxl bWVudGluZyB0aGUgUlRDV2ViIGNvbnNlbnQgZnJlc2huZXNzIHByb2NlZHVyZXMgaW4gc3VjaCBh IHdheSB0aGF0IG9ubHkgdGhlIFJUQ1dlYiBicm93c2VyIG5lZWRlZCB0byBzZW5kIHBlcmlvZGlj IGJpbmRpbmcgcmVxdWVzdHMgdG8gbWFpbnRhaW4gYmlsYXRlcmFsIGNvbnNlbnQgZnJlc2huZXNz KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5E b2VzIGEgYmluZGluZyByZXF1ZXN0IHByb3ZpZGUgdW5pbGF0ZXJhbCBvciBiaWxhdGVyYWwgY29u c2VudCB2ZXJpZmljYXRpb24vZnJlc2huZXNzPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklzIGEgc2VydmVyIGdhdGV3YXkgaW1wbGVtZW50aW5n IElDRS1saXRlIHJlcXVpcmVkIHRvIHNlbmQgSUNFIGJpbmRpbmcgcmVxdWVzdHMgYW55d2F5IGZv ciBjb25zZW50IHZlcmlmaWNhdGlvbiBhbmQvb3IgY29uc2VudCBmcmVzaG5lc3MsIG9yIGlzIGl0 IHN1ZmZpY2llbnQgZm9yIHN1Y2ggYW4gaW1wbGVtZW50YXRpb24gdG8gaW5kaWNhdGUgaXRzIG93 biBjb25zZW50IGJ5IGp1c3QgcmVzcG9uZGluZyB0byByZWNlaXZlZCBiaW5kaW5nIHJlcXVlc3Rz PzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRv IHdlIGNhcmUgYWJvdXQgY29tcGF0aWJpbGl0eSB3aXRoIElDRSBjb21wbGlhbnQgZW5kcG9pbnRz IHRoYXQgZG8gbm90IHVzZSBiaW5kaW5nIHJlcXVlc3RzIGZvciBjb25zZW50IGZyZXNobmVzcz88 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Eb2Vz IGEgYnJvd3NlciB0cmVhdCBhIHJlc3BvbnNlIHRvIGEgYmluZGluZyByZXF1ZXN0IHRoZSBzYW1l IGFzIGEgcmVjZWl2ZWQgYmluZGluZyByZXF1ZXN0IGZvciBjb25zZW50IGZyZXNobmVzcz88bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JdCB3b3Vs ZCBiZSBoZWxwZnVsIHRvIGhhdmUgY2xlYXIgYW5zd2VycyB0byB0aGVzZSBxdWVzdGlvbnMgaW4g dGhlIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFua3MsPG86cD48L286cD48L3ByZT4N CjxwcmU+UmljaGFyZCBFanphazxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D5574xmbrcdx02ciscoc_-- From magnus.westerlund@ericsson.com Tue Jul 17 04:13:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA73A21F860E for ; Tue, 17 Jul 2012 04:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76HmBhQSTSBZ for ; Tue, 17 Jul 2012 04:13:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A24521F852D for ; Tue, 17 Jul 2012 04:13:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-3e-5005491ccfa7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F6.13.07365.C1945005; Tue, 17 Jul 2012 13:14:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 17 Jul 2012 13:14:36 +0200 Message-ID: <50054918.2070008@ericsson.com> Date: Tue, 17 Jul 2012 13:14:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FEAAB0A.2060106@ericsson.com> In-Reply-To: <4FEAAB0A.2060106@ericsson.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3VlfGkzXA4OItIYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcajXr6CFv+LgsedMDYzTeLoYOTkkBEwkHt3bwA5hi0lcuLee rYuRi0NI4BSjRHPbLkYIZzmjxNlr65lBqngFtCWWXdnFCmKzCKhKXFrxESzOJmAhcfNHIxuI LSoQLDFt+j12iHpBiZMzn7CA2CICwhJbX/UygdjCAqYSj6b8BZsjBDTzy5QzYHFOAR2J8yf/ Q10kKXGvfTXYTGYBPYkpV1sYIWx5ieats5lhehuaOlgnMArOQrJuFpKWWUhaFjAyr2IUzk3M zEkvN9RLLcpMLi7Oz9MrTt3ECAzLg1t+6+5gPHVO5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2M/j6XPRe3tx98pe+9cuPiM5mFPPZy/PkBDf5Hc1//M+/wP576OO9q oKvy6XkmVyR2uS117HwZs/GUxZvUoE1blxitPsFUOMP5tlAOg7e2qq577JbeR95ib+dp6Mkc XGF74/G2jhLH1Sd33b82zdx1V/jr3cumGrgenTyttNAt4mbx/EgVh4ORSizFGYmGWsxFxYkA ISOa+RkCAAA= Subject: Re: [rtcweb] Propose Vancouver Agenda Topics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 11:13:50 -0000 WG, If you have any additional topics please send that to the chairs today. We need to make available a draft agenda tomorrow. Cheers Magnus On 2012-06-27 08:41, Magnus Westerlund wrote: > WG, > > The WG chairs solicit topics that you think needs to be discussed in > Vancouver. Both authors/editors of documents that have topics they think > requires face to face discussion to reach consensus and WG participants > that think a particular topic should be discussed are of interest. > > Two topics that is clear they need further discussion and was not taken > at the interim meeting are > - Additional Key-management for SRTP > - Selection of Mandatory to implement Media Codecs > > Please add to the list or comment on the suitability to have these topics. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 martin.thomson@gmail.com Tue Jul 17 09:38:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5683E21F855A for ; Tue, 17 Jul 2012 09:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.74 X-Spam-Level: X-Spam-Status: No, score=-3.74 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ9JSxweLXbB for ; Tue, 17 Jul 2012 09:38:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09FE321F84FF for ; Tue, 17 Jul 2012 09:38:00 -0700 (PDT) Received: by bkty7 with SMTP id y7so575986bkt.31 for ; Tue, 17 Jul 2012 09:38:48 -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=MlLiBvtFuxHaby1IRpfpMtKn/6pDgJnXeUzr917RMpU=; b=f+P3GvqmobjZ8QVgKWfYPF83fUC3OhczuoV5UVf/ty81bqerzuJYAFyae7kBjuKQug hRc8j9agEySAvWEM99fMCe5YkOyBtxt7UCBzUQNc/aGicSbHHKPupXc5fYk0qx24DwWl KCXX/fzSxsVtzehKgUkzwopVdH5ir05YLY9Z99ZnV7T5Z7Gz77b0ELsq8xTSQUMRUPIQ P+Hgs01r5O7JFTUQAa+uZPBlagpIvfDFau0BDbWd1bKRn9IK+eAMIa5yX1gtemG2zurY kcWqtPUuI1mzJmoHMJ9WjHxh7T2watKESjmusxSEVOAyB7xBcgAxwpaUSzDoRUyue93w Cxcw== MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr1683196bkw.49.1342543128153; Tue, 17 Jul 2012 09:38:48 -0700 (PDT) Received: by 10.204.66.17 with HTTP; Tue, 17 Jul 2012 09:38:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Jul 2012 09:38:48 -0700 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:38:02 -0000 On 17 July 2012 00:37, Muthu Arul Mozhi Perumal (mperumal) wrote: > 4. Solution Overview > Discusses the combined consent freshness and session liveness > test (slide "Combined Consent/Liveness Proposal II" from the > RTCWEB interim). This looks like a reasonable start. I'm not sure why there are so many other sections in the document. It was pretty clear to me that consensus was reached around the use of Binding requests. I'd suggest that you trim the document down to just this section if you intend for it to be adopted. There needs to be more detail about the nature of the consent/liveness test with respect to the observed round trip time and packet loss. Based on the discussions at the interim, it was clear that the complete 60+ second check time was unnecessary for consent/liveness refresh. > 6. Open Items > Lists the current open issues. I can see how you might reach the conclusion that consent is not needed for RTCP flows, but I don't see the benefit of creating a special case for it. From martin.thomson@gmail.com Tue Jul 17 10:16:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F13311E8087 for ; Tue, 17 Jul 2012 10:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.736 X-Spam-Level: X-Spam-Status: No, score=-3.736 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwG3ucBdJhhm for ; Tue, 17 Jul 2012 10:16:36 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A75A11E807F for ; Tue, 17 Jul 2012 10:16:36 -0700 (PDT) Received: by bkty7 with SMTP id y7so616179bkt.31 for ; Tue, 17 Jul 2012 10:17: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:content-transfer-encoding; bh=842IF4UGxKj6Qm1Ikk7OKBcgdg55hwMID6pi2rQ8Vj4=; b=QbBqkXcfLp1vb2YVBnYQmclGCil8q7GzanKQWtPyCeR/K5BPtFEnIfdkSdNrGIe3nB RRPdjtsaDYXAhR9MZzQ56VK9QzjbKVhbxHhvX9KjPrvOKoJhzUNnRl96lfYS9iElTYYK WRWaaOxcOaPKf4XKxANdst7aSEfVSoRwIofaxS8+JVi99IYbZpe4oP0Nf14lgPJM6p/q +Hp0dKLNvn68TCdxY3ihYvqHFcQWdcDwv3tG14zuax6Ev6+O9NNH8zaffsGmWueFPKsC p73DyvZYoOf7yeBTfotMomq9zgGJBI8b7GUSASOeW4ekQHd+2g4/1ciQY2zx8nflAzwh Y31w== MIME-Version: 1.0 Received: by 10.205.132.6 with SMTP id hs6mr1739353bkc.26.1342545443507; Tue, 17 Jul 2012 10:17:23 -0700 (PDT) Received: by 10.204.66.17 with HTTP; Tue, 17 Jul 2012 10:17:23 -0700 (PDT) In-Reply-To: <2E4702C2-49DD-47C8-9F9E-DF93103CF640@csperkins.org> References: <2E4702C2-49DD-47C8-9F9E-DF93103CF640@csperkins.org> Date: Tue, 17 Jul 2012 10:17:23 -0700 Message-ID: From: Martin Thomson To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP usage: requirement levels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 17:16:37 -0000 On 17 July 2012 02:32, Colin Perkins wrote: > If you have suggestions for specific changes where the recommendations in= the draft are unclear, we'd be happy to receive them. The classifications = you suggest below are not appropriate for all the normative statements in t= he draft, so it's not clear exactly what you think needs to change. I thought that I was being specific. I would like to see an end to the shoehorning of 2119 language into classifications that are inappropriate for 2119 language. As a profile, a normative statement that doesn't directly pertain to whether a feature is implemented or not would be out of place. Much of the 2119 language that is left over is simply reiteration of requirements made in the referenced specifications. For instance, [...] The use of header extensions is OPTIONAL in the WebRTC context, but if they are used, they MUST be formatted and signalled following the general mechanism for RTP header extensions defined in [RFC5285], In this case, the first "OPTIONAL" implies that an implementation can implement this, but if they do, they must provide a) a way to disable the feature, and b) a way to indicate support for the feature. A clear classification that included this information would be useful. Of course, the second "MUST" is a reiteration of language in 5285. (To be clear, reiteration of this sort is harmless, except where the language overlaps with the core purpose of the document.) Specific problems: "RECOMMENDED" is used a lot in the document. It could be clearer if the admonitions made in Section 3 regarding "MAY" also apply to these. The distinction between these two requirement levels is toothless. "MUST...unless" is a far less ambiguous construct, unless a feature really is optional. CNAME generation is currently "RECOMMENDED", but the text then goes on to say that it doesn't meet the bar for privacy. I would argue for MUST on draft-rescorla-random-cname, but we probably need more discussion on that. Section 5.1 says "These RECOMMENDED topologies are expected to be supported by all WebRTC end-points " which is a non-requirement. Here's a good example: Senders are REQUIRED to understand the Generic NACK message defined in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback [.= ..] Receivers MAY send NACKs for missing RTP packets This seems clear, but who decides to ignore the feedback? Can you negotiate the use of the generic NACK? That is, is this MUST implement or MUST use ? A clearer way to describe this would be to describe a feature (in this case, two features: NACK and retx) and then indicate whether each is MUST implement, MUST use or whatever. From lorenzo@meetecho.com Wed Jul 18 02:45:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0087921F86E4 for ; Wed, 18 Jul 2012 02:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fyHrYvPnX90 for ; Wed, 18 Jul 2012 02:45:27 -0700 (PDT) Received: from smtplq01.aruba.it (unknown [62.149.158.23]) by ietfa.amsl.com (Postfix) with SMTP id EE8F921F8663 for ; Wed, 18 Jul 2012 02:45:26 -0700 (PDT) Received: (qmail 18750 invoked by uid 89); 18 Jul 2012 09:46:09 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq01.aruba.it with SMTP; 18 Jul 2012 09:46:09 -0000 Received: (qmail 10552 invoked by uid 89); 18 Jul 2012 09:46:09 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp8.ad.aruba.it with SMTP; 18 Jul 2012 09:46:08 -0000 Date: Wed, 18 Jul 2012 11:45:58 +0200 From: Lorenzo Miniero To: rtcweb@ietf.org Message-ID: <20120718114558.14b4aa35@lminiero-acer> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] WebRTC/RTCWEB demo available X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:45:28 -0000 Dear all, just a quick post to inform you we just made a public WebRTC/RTCWEB demo available: https://groups.google.com/forum/?fromgroups#!topic/discuss-webrtc/B3iDAJ2XtVI We hope it will be useful as a real world use case for RTCWEB, especially since we're planning to make this RTCWEB access available for the remote participation sessions in Vancouver. Feel free to play with it and provide us with any feedback or suggestion you might have for us! Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From harald@alvestrand.no Wed Jul 18 03:20:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962B721F8691 for ; Wed, 18 Jul 2012 03:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AWLYIKamCUz for ; Wed, 18 Jul 2012 03:20:15 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59B21F8650 for ; Wed, 18 Jul 2012 03:20:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0141A39E16F; Wed, 18 Jul 2012 12:21:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3IL-QdXAc+C; Wed, 18 Jul 2012 12:21:02 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E3C4139E07C; Wed, 18 Jul 2012 12:21:02 +0200 (CEST) Message-ID: <50068E0E.6080501@alvestrand.no> Date: Wed, 18 Jul 2012 12:21:02 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Magnus Westerlund References: <4FEAAB0A.2060106@ericsson.com> In-Reply-To: <4FEAAB0A.2060106@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Propose Vancouver Agenda Topics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 10:20:21 -0000 I believe we should try to settle the question of resolution negotiation. In particular, whether SDP (draft-alvestrand-rtcweb-resolution) or COP (draft-westerlund-rtcweb-codec-control) should be a mandatory-to-implement function for changing resolution during a call. (Both drafts suggest that "a=imageattr" is an appropriate mechanism for specifying the boundaries of image size during the setup phase of the call, so I take that as a a given.) Harald On 06/27/2012 08:41 AM, Magnus Westerlund wrote: > WG, > > The WG chairs solicit topics that you think needs to be discussed in > Vancouver. Both authors/editors of documents that have topics they think > requires face to face discussion to reach consensus and WG participants > that think a particular topic should be discussed are of interest. > > Two topics that is clear they need further discussion and was not taken > at the interim meeting are > - Additional Key-management for SRTP > - Selection of Mandatory to implement Media Codecs > > Please add to the list or comment on the suitability to have these topics. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 From csp@csperkins.org Wed Jul 18 07:42:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BCD21F87B0 for ; Wed, 18 Jul 2012 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6eEcI-l+BWV for ; Wed, 18 Jul 2012 07:42:14 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3843021F87AE for ; Wed, 18 Jul 2012 07:42:14 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SrVSx-0000LZ-io; Wed, 18 Jul 2012 14:43:03 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 18 Jul 2012 15:43:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6310B022-FE3B-403F-9759-AA63EBDB9967@csperkins.org> References: <2E4702C2-49DD-47C8-9F9E-DF93103CF640@csperkins.org> To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTP usage: requirement levels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:42:15 -0000 On 17 Jul 2012, at 18:17, Martin Thomson wrote: > On 17 July 2012 02:32, Colin Perkins wrote: >> If you have suggestions for specific changes where the = recommendations in the draft are unclear, we'd be happy to receive them. = The classifications you suggest below are not appropriate for all the = normative statements in the draft, so it's not clear exactly what you = think needs to change. >=20 > I thought that I was being specific. I would like to see an end to > the shoehorning of 2119 language into classifications that are = inappropriate for 2119 language. I disagree that these are inappropriate uses of the RFC 2119 language. > As a profile, a normative statement that doesn't directly pertain to > whether a feature is implemented or not would be out of place. Much > of the 2119 language that is left over is simply reiteration of > requirements made in the referenced specifications. For instance, > [...] The use of header > extensions is OPTIONAL in the WebRTC context, but if they are used, > they MUST be formatted and signalled following the general mechanism > for RTP header extensions defined in [RFC5285], >=20 > In this case, the first "OPTIONAL" implies that an implementation can > implement this, but if they do, they must provide a) a way to disable > the feature, and b) a way to indicate support for the feature. A > clear classification that included this information would be useful. > Of course, the second "MUST" is a reiteration of language in 5285. > (To be clear, reiteration of this sort is harmless, except where the > language overlaps with the core purpose of the document.) The 2nd MUST is a statement that the RFC5285 mechanism is to be used, = not a reiteration of the requirements in RFC5285. Your first points are = implied by OPTIONAL, as you note. > Specific problems: >=20 > "RECOMMENDED" is used a lot in the document. It could be clearer if > the admonitions made in Section 3 regarding "MAY" also apply to these. > The distinction between these two requirement levels is toothless. > "MUST...unless" is a far less ambiguous construct, unless a feature > really is optional. I disagree. The RFC 2119 terms are well defined, and have clear meaning.=20= > CNAME generation is currently "RECOMMENDED", but the text then goes on > to say that it doesn't meet the bar for privacy. I would argue for > MUST on draft-rescorla-random-cname, but we probably need more > discussion on that. As I've previously stated, if AVTCORE adopts EKR's random CNAME draft, = the reference can be changed.=20 > Section 5.1 says "These RECOMMENDED topologies are expected to be > supported by all WebRTC end-points " which is a non-requirement. Agree. That should be clarified. > Here's a good example: >=20 > Senders are REQUIRED to understand the Generic NACK message defined > in Section 6.2.1 of [RFC4585], but MAY choose to ignore this = feedback [...] > Receivers MAY send NACKs for missing RTP packets >=20 > This seems clear, but who decides to ignore the feedback? =20 The sender may choose to ignore the feedback. The text seems clear to = me. > Can you negotiate the use of the generic NACK? That is, is this MUST > implement or MUST use ? Neither; this is why the current phrasing is used. > A clearer way to describe this would be to describe a feature (in this > case, two features: NACK and retx) and then indicate whether each is > MUST implement, MUST use or whatever. I disagree. --=20 Colin Perkins http://csperkins.org/ From mperumal@cisco.com Wed Jul 18 08:32:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A10A21F8778 for ; Wed, 18 Jul 2012 08:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ7WD76e72Sb for ; Wed, 18 Jul 2012 08:32:26 -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 3A5F121F8713 for ; Wed, 18 Jul 2012 08:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3778; q=dns/txt; s=iport; t=1342625597; x=1343835197; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vW/4WE6yNUm+nA7kJMjJ2jLeTwJiiFE7nB0GvmtjOXE=; b=EwRPciX9Pq9QY/DkjQ+T9MfEMlHvlKOu8eQRq+DRwV/GH1yDNPFISopj oGgGD4nD/YUGJ8Jppk8WB4e8eu8qnAKUxPBwOwM2T2Q7MGhgrgPTB/C5S duNEqZCBmVnZ+Kt2c0F7evKnzB5jcbiYF1XeELMINSQnWNBxHxGQSUjs8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMfWBlCtJV2c/2dsb2JhbABFhWqyMIEZgQeCIAEBAQQSARARRQwEAgEIEQQBAQMCBh0DAgICHxEUAQcBCAIEDgUIEweHXAMMnXqNGYkqDYlOgSCJO2UUhSkyYAOgS4McgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208";a="103052452" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jul 2012 15:33:16 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6IFXGr5022181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 15:33:16 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 10:33:16 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson Thread-Topic: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-01.txt Thread-Index: AQHNY211pZ5zmVz19UG3CqD7N+7epZcs+oNwgAEHuwCAARjbcA== Date: Wed, 18 Jul 2012 15:33:14 +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: [10.65.68.229] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--49.588600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:32:27 -0000 fFRoaXMgbG9va3MgbGlrZSBhIHJlYXNvbmFibGUgc3RhcnQuICBJJ20gbm90IHN1cmUgd2h5IHRo ZXJlIGFyZSANCnxzbyBtYW55IG90aGVyIHNlY3Rpb25zIGluIHRoZSBkb2N1bWVudC4gIEl0IHdh cyBwcmV0dHkgY2xlYXIgdG8gDQp8bWUgdGhhdCBjb25zZW5zdXMgd2FzIHJlYWNoZWQgYXJvdW5k IHRoZSB1c2Ugb2YgQmluZGluZyByZXF1ZXN0cy4gDQp8SSdkIHN1Z2dlc3QgdGhhdCB5b3UgdHJp bSB0aGUgZG9jdW1lbnQgZG93biB0byBqdXN0IHRoaXMgc2VjdGlvbiANCnxpZiB5b3UgaW50ZW5k IGZvciBpdCB0byBiZSBhZG9wdGVkLg0KDQpUaGVzZSBzZWN0aW9ucyBkZWZpbmUgYSBuZXcgU1RV TiBDb25zZW50IG1ldGhvZC4gVGhlIGRvY3VtZW50IHdpbGwgYmUgdHJpbW1lZCBpZiB3ZSBkZWNs YXJlIGNvbnNlbnN1cyB0byByZXVzZSB0aGUgU1RVTiBCaW5kaW5nIG1ldGhvZCAoaG9wZWZ1bGx5 IGFmdGVyIElFVEYtODQsIG9uZSB3YXkgb3Igb3RoZXIpLg0KDQp8VGhlcmUgbmVlZHMgdG8gYmUg bW9yZSBkZXRhaWwgYWJvdXQgdGhlIG5hdHVyZSBvZiB0aGUgY29uc2VudC9saXZlbmVzcw0KfHRl c3Qgd2l0aCByZXNwZWN0IHRvIHRoZSBvYnNlcnZlZCByb3VuZCB0cmlwIHRpbWUgYW5kIHBhY2tl dCBsb3NzLg0KDQpBZ3JlZS4gV2Ugd2lsbCBhZGQgdGhlbSBpbiB0aGUgbmV4dCByZXZpc2lvbi4N Cg0KfEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBhdCB0aGUgaW50ZXJpbSwgaXQgd2FzIGNsZWFy IHRoYXQgdGhlDQp8Y29tcGxldGUgNjArIHNlY29uZCBjaGVjayB0aW1lIHdhcyB1bm5lY2Vzc2Fy eSBmb3IgY29uc2VudC9saXZlbmVzcw0KfHJlZnJlc2guDQoNClNUVU4gcmVxdWVzdHMgYXJlIHJl dHJhbnNtaXR0ZWQgNyB0aW1lcyBieSBkZWZhdWx0LiBXaXRoIGFuIFJUTyBvZiA1MDAgbXMgdGhl IHRyYW5zYWN0aW9uIHdvdWxkIGZhaWwgYWZ0ZXIgMzkuNSBtcyBpZiB0aGVyZSBpcyBubyByZXNw b25zZS4gT3VyIGN1cnJlbnQgdGhpbmtpbmcgaXMgdGhpcyBjb3VsZCBiZSBsaW1pdGVkIHRvIDUg cmV0cmFuc21pc3Npb25zIGZvciBjb25zZW50IGZyZXNobmVzcywgc28gdGhhdCB0aGUgdHJhbnNh Y3Rpb24gZmFpbHMgYWZ0ZXIgMTUuNSBzZWMuIERvZXMgaXQgc291bmQgcmVhc29uYWJsZT8NCg0K fEkgY2FuIHNlZSBob3cgeW91IG1pZ2h0IHJlYWNoIHRoZSBjb25jbHVzaW9uIHRoYXQgY29uc2Vu dCBpcyBub3QNCnxuZWVkZWQgZm9yIFJUQ1AgZmxvd3MsIGJ1dCBJIGRvbid0IHNlZSB0aGUgYmVu ZWZpdCBvZiBjcmVhdGluZyBhDQp8c3BlY2lhbCBjYXNlIGZvciBpdC4NCg0KWWVzLCB0aGUgb25s eSBiZW5lZml0IEkgY2FuIHRoaW5rIG9mIGlzLCBpdCByZWR1Y2VzIHNvbWUgbmV0d29yayB0cmFm ZmljLiANCg0KTXV0aHUNCg0KfC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQp8RnJvbTogTWFy dGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQp8U2VudDogVHVl c2RheSwgSnVseSAxNywgMjAxMiAxMDowOSBQTQ0KfFRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVt YWwgKG1wZXJ1bWFsKQ0KfENjOiBydGN3ZWJAaWV0Zi5vcmcNCnxTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gRlc6IEktRCBBY3Rpb246IGRyYWZ0LW11dGh1LWJlaGF2ZS1jb25zZW50LWZyZXNobmVzcy0w MS50eHQNCnwNCnxPbiAxNyBKdWx5IDIwMTIgMDA6MzcsIE11dGh1IEFydWwgTW96aGkgUGVydW1h bCAobXBlcnVtYWwpDQp8PG1wZXJ1bWFsQGNpc2NvLmNvbT4gd3JvdGU6DQp8PiA0LiBTb2x1dGlv biBPdmVydmlldw0KfD4gICAgRGlzY3Vzc2VzIHRoZSBjb21iaW5lZCBjb25zZW50IGZyZXNobmVz cyBhbmQgc2Vzc2lvbiBsaXZlbmVzcw0KfD4gICAgdGVzdCAoc2xpZGUgIkNvbWJpbmVkIENvbnNl bnQvTGl2ZW5lc3MgUHJvcG9zYWwgSUkiIGZyb20gdGhlDQp8PiAgICBSVENXRUIgaW50ZXJpbSku DQp8DQp8VGhpcyBsb29rcyBsaWtlIGEgcmVhc29uYWJsZSBzdGFydC4gIEknbSBub3Qgc3VyZSB3 aHkgdGhlcmUgYXJlIHNvDQp8bWFueSBvdGhlciBzZWN0aW9ucyBpbiB0aGUgZG9jdW1lbnQuICBJ dCB3YXMgcHJldHR5IGNsZWFyIHRvIG1lIHRoYXQNCnxjb25zZW5zdXMgd2FzIHJlYWNoZWQgYXJv dW5kIHRoZSB1c2Ugb2YgQmluZGluZyByZXF1ZXN0cy4gIEknZCBzdWdnZXN0DQp8dGhhdCB5b3Ug dHJpbSB0aGUgZG9jdW1lbnQgZG93biB0byBqdXN0IHRoaXMgc2VjdGlvbiBpZiB5b3UgaW50ZW5k IGZvcg0KfGl0IHRvIGJlIGFkb3B0ZWQuDQp8DQp8VGhlcmUgbmVlZHMgdG8gYmUgbW9yZSBkZXRh aWwgYWJvdXQgdGhlIG5hdHVyZSBvZiB0aGUgY29uc2VudC9saXZlbmVzcw0KfHRlc3Qgd2l0aCBy ZXNwZWN0IHRvIHRoZSBvYnNlcnZlZCByb3VuZCB0cmlwIHRpbWUgYW5kIHBhY2tldCBsb3NzLg0K fEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBhdCB0aGUgaW50ZXJpbSwgaXQgd2FzIGNsZWFyIHRo YXQgdGhlDQp8Y29tcGxldGUgNjArIHNlY29uZCBjaGVjayB0aW1lIHdhcyB1bm5lY2Vzc2FyeSBm b3IgY29uc2VudC9saXZlbmVzcw0KfHJlZnJlc2guDQp8DQp8PiA2LiBPcGVuIEl0ZW1zDQp8PiAg ICBMaXN0cyB0aGUgY3VycmVudCBvcGVuIGlzc3Vlcy4NCnwNCnxJIGNhbiBzZWUgaG93IHlvdSBt aWdodCByZWFjaCB0aGUgY29uY2x1c2lvbiB0aGF0IGNvbnNlbnQgaXMgbm90DQp8bmVlZGVkIGZv ciBSVENQIGZsb3dzLCBidXQgSSBkb24ndCBzZWUgdGhlIGJlbmVmaXQgb2YgY3JlYXRpbmcgYQ0K fHNwZWNpYWwgY2FzZSBmb3IgaXQuDQo= From martin.thomson@gmail.com Wed Jul 18 09:55:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE911E80AA for ; Wed, 18 Jul 2012 09:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.964 X-Spam-Level: X-Spam-Status: No, score=-3.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8XlxM2q9Hov for ; Wed, 18 Jul 2012 09:55:10 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 205B211E80D9 for ; Wed, 18 Jul 2012 09:55:09 -0700 (PDT) Received: by bkty7 with SMTP id y7so1587140bkt.31 for ; Wed, 18 Jul 2012 09:56:00 -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=HMy4vaoKag/AIypnXL1BSCK3n4pUWtT5fabTzi29f90=; b=vQzzwVODBQhfpicZIUYetYTHkZeQqNtPRTl3hGohfjeWwI6GlW2OIlqYn0opR7VAow aJIrN9XSZS0lbxO23MyHkS0u/7W4zzmR0P3KyH+UWxd2KZojo5RoLR3I7GMeHEcPB8hp etP9WIEQQGTLHEyyvHEJ/7A6qwAbNkdHlWtSWi6D9QhKykTpXHWb85pg78uaSMmub/UG t3M92CzAq2rMr6IgNV9cnrtnsBcgghYylsHjZNqgKVdnJhPMEFyu13sbpjQZE8YER9WD OMsHhgUpmgpsmYMV/iWOXnwh5KTzoEybXB+81eep8u4bgfh9clVeq+SE87t5Xs4geYdS oawA== MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr2169320bkw.49.1342630560028; Wed, 18 Jul 2012 09:56:00 -0700 (PDT) Received: by 10.204.66.17 with HTTP; Wed, 18 Jul 2012 09:55:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jul 2012 09:55:59 -0700 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:55:11 -0000 On 18 July 2012 08:33, Muthu Arul Mozhi Perumal (mperumal) wrote: > STUN requests are retransmitted 7 times by default. With an RTO of 500 ms= the transaction would fail after 39.5 ms if there is no response. Our curr= ent thinking is this could be limited to 5 retransmissions for consent fres= hness, so that the transaction fails after 15.5 sec. Does it sound reasonab= le? Not really. You have a liveness timer that triggers this at (as low as) 500ms. Are you suggesting that I wait at least 16s to determine that a peer is not sending anything? Can the liveness timer trip again during this process? These aren't hard questions to resolve, but they do need some resolution (in this model). I have another model in mind. --Martin From ted.ietf@gmail.com Wed Jul 18 12:08:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823F611E8182 for ; Wed, 18 Jul 2012 12:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erR9R3DTybOC for ; Wed, 18 Jul 2012 12:08:01 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C982011E817F for ; Wed, 18 Jul 2012 12:08:00 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1503269vcb.31 for ; Wed, 18 Jul 2012 12:08:51 -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=00D/pfGYAUPz7wAmOVLGJAWAtXVU+LHpd5CLgvZIxoM=; b=TJ65PGHOlDxqLWWbYTyTq1FsWs6VmrLHOPLbOq+lO8Xikg9kT99xQs4z7GXaxPq2NU K0frMw3zhuYkrCb2d2xdgeG3CnY+NmZJ3odHDxKjnh8iwZ8pNd79pdzfZZoZKPIi6JZn tUtYhvN07pXDACc3Fus2pQgJ1Jm4Fw45IrQ8rVFcUQdWZ/GCd3jOeAuGx9PBw7lc/5Yh rfyx6FqlAF3lxJXFRY3KaChnqNDv2e7lIDy1eH3z51J8lRjEh0Qo48+KDYhuH+PfnefO 4CwJz93CWcej43GzmVRewhSud4Y3kuNnhxbaqNTbbmVf9eu1rzXjWNuZg0j5ZTfDnIjS bvbQ== MIME-Version: 1.0 Received: by 10.52.73.42 with SMTP id i10mr1258995vdv.116.1342638531167; Wed, 18 Jul 2012 12:08:51 -0700 (PDT) Received: by 10.52.170.68 with HTTP; Wed, 18 Jul 2012 12:08:51 -0700 (PDT) Date: Wed, 18 Jul 2012 12:08:51 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, Robert Sparks , Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Proposed new milestones for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:08:01 -0000 As folks know, we are behind on our milestones. The following milestones represent a proposal from me and Magnus, based on some text from Cullen. Please review in light of our deliverable list: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security and privacy goals and specifies the security protocol mechanisms necessary to achieve those goals. 3. Define the solution - protocols and API requirements - for firewall and NAT traversal. 4. Define which media functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non media data is transported between clients in a secure and congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. 9. The group will consider options for interworking with legacy VoIP equipment. Timeline: Sep 2012 - Send Use Cases document to IESG for publication as Informational Sep 2012 - Complete Overview (and hold for dependency resolution) Sep 2012 - Send Security and Privacy Problem Statement to IESG for publication as Informational Jan 2013 - Send Signalling Negotiation and NAT Traversal to IESG for publication as Proposed Standard Jan 2013 - Send Security Solution to IESG for publication as Proposed Standard Jan 2013 - Send Media Transport, Media Processing, and Codecs to IESG for publication as Proposed Standard May 2013 - Send Data Stream Transport for non-media data to IESG for publication as Proposed Standard Comments, please! Ted From ted.ietf@gmail.com Wed Jul 18 12:47:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA16011E8166 for ; Wed, 18 Jul 2012 12:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yytY9KnwWm7I for ; Wed, 18 Jul 2012 12:47:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A184C11E809B for ; Wed, 18 Jul 2012 12:47:55 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1529883vcb.31 for ; Wed, 18 Jul 2012 12:48:44 -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:cc:content-type; bh=8g8RMk/84Fx16I0Iec3k6aokaUMMnpiYH2UzS7LmQoU=; b=NysuYtxsXvGBiK53PAAzI4gBp34VRbXunmd2sWbyXeKZqS6YQ08+oIQw2dbU2iYlPm qm5CHz/ao4dsbHkZPd6H4dbF9VsZ9fwkxs4gTvA0o4xMO4p363BW6urSfnJqiBOevWyB Yui11j6jYxhfhMQqhnek5sWvtePtxN6jfiQCzidapIsLnMa/cTpPluGQaWEn6eBj71Yo QfuU5adDCOPJmXLUMg4eFwfoguGm+JwDOSM2biL7fiGtytzvViK52Pyq0bcIb0en61HZ sU1TlBApeceP3OcyuIbRFmxMkpw4DGmPgEl4kaUAF5NufdjfHrjFIgX2OQVj7ewMu3tB 81MA== MIME-Version: 1.0 Received: by 10.52.73.42 with SMTP id i10mr1325214vdv.116.1342640923788; Wed, 18 Jul 2012 12:48:43 -0700 (PDT) Received: by 10.52.170.68 with HTTP; Wed, 18 Jul 2012 12:48:43 -0700 (PDT) Date: Wed, 18 Jul 2012 12:48:43 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, Robert Sparks , Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings Subject: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:47:57 -0000 A draft agenda has been posted at: http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb Edits and adjustments still possible; comments to the list. Ted From igor.faynberg@alcatel-lucent.com Wed Jul 18 13:48:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E0421F86F9 for ; Wed, 18 Jul 2012 13:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlgynOALMZ7F for ; Wed, 18 Jul 2012 13:48:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B229B21F864B for ; Wed, 18 Jul 2012 13:48:16 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q6IKn7UT017759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Jul 2012 15:49:07 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6IKn6kj018977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 18 Jul 2012 15:49:07 -0500 Received: from [135.222.232.88] (USMUYN0L055118.mh.lucent.com [135.222.232.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6IKn6n5008208; Wed, 18 Jul 2012 15:49:06 -0500 (CDT) Message-ID: <50072142.8000208@alcatel-lucent.com> Date: Wed, 18 Jul 2012 16:49:06 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 20:48:17 -0000 Ted, I notice a conflict of the second session (which covers security) with OAuth. Is it possible to change the schedule? OAuth seems to be applicable to RTCWeb authorization. It might be impossible to reschedule, but would you consider swapping the content of the slots so that security is covered in the first session? With thanks, Igor On 7/18/2012 3:48 PM, Ted Hardie wrote: > A draft agenda has been posted at: > http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb > > Edits and adjustments still possible; comments to the list. > > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From domenico.colella@ctiplanet.it Thu Jul 19 00:42:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DEC21F867D for ; Thu, 19 Jul 2012 00:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyLB9ywqXDNL for ; Thu, 19 Jul 2012 00:42:01 -0700 (PDT) Received: from hostingsmtp.register.it (hostingsmtp02.register.it [81.88.50.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8A721F862F for ; Thu, 19 Jul 2012 00:41:59 -0700 (PDT) Received: (qmail 29687 invoked from network); 19 Jul 2012 07:42:47 -0000 Received: from unknown (HELO vivaldi29.register.it) by hostingsmtp.register.it with ESMTP; 19 Jul 2012 07:42:47 -0000 Received: (from popuser@localhost) by vivaldi29.register.it (8.13.8/8.12.11/Submit) id q6J7glf6008744; Thu, 19 Jul 2012 09:42:47 +0200 Message-Id: <201207190742.q6J7glf6008744@vivaldi29.register.it> From: "Domenico Colella" To: rtcweb@ietf.org Date: Thu, 19 Jul 2012 09:42:47 +0200 X-RID: dDsndCNuJSjsO3RjQCUoKCMoK2MnK2M7biNtK2Q=|dDsndCNuJSjsO3Rj|+eBeJ+Bd4CcsXeAnPT3g|TElBTUJFVw== MIME-Version: 1.0 X-Priority: 3 X-Mailer: Webmail Client v1.5 Content-Type: text/plain; charset="iso-8859-1" Cc: daniele.filippi@ctiplanet.it Subject: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Domenico Colella List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 07:42:01 -0000 In RTCWEB Security Architecture (draft-ietf-rtcweb-security-arch-03) I noticed an open issue regarding SDES support: if browser implementations MUST or MAY support it. I got quite scared when I saw the word MAY. I support the MUST option, because RTCWEB can be used not only for peer-to-peer communication (i.e. Alice calling Bob), but also to access services provided by the "calling service" (i.e.customer support, customer attendant, voicemail ... or any service delivering also RT audio/video that can be accessed through a website). In the latter case, the user usually is already logged-in the "calling service" using a secure connection (X.509 certificate have already be used to verify calling service party) and the other endpoint usually is a server/phone in company DMZ/intranet: communication is end-to-end secured and each party trusts the other. At the moment SDES has a good support and it is not that difficult to be implemented, on the contrary DTLS-SRTP it is almost unknown. Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and compatible with their legacy devices ?) or translators in order to support RTCWeb instead of a SRTMP server/gateway (i.e. open-source free products as Red5) and use FLASH ? At the moment FLASH is supported by a considerably larger number of devices, and uses codecs "more compliant" to legacy devices (iLBC is not that supported by phone equipments). Furthermore, in this scenario, the customer using i.e. the bank website knows for sure he is communicating "privately" to his bank and trusts the webserver. Why then setup a DTLS session or check identities ? If the customer is sending passwords, credit card numbers,... using webserver connection why do not "trust" such connection to exchange RTP keys as well ? The word MUST is really important, because it grants that "every" browser in the near future will support it and grants system integrators, software developers and companies investing in building RT services that SDES support will be mantained. Regards, Domenico Colella From harald@alvestrand.no Thu Jul 19 02:55:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7B21F87A5 for ; Thu, 19 Jul 2012 02:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0eg0tZMkmqa for ; Thu, 19 Jul 2012 02:55:14 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EDE1D21F8783 for ; Thu, 19 Jul 2012 02:55:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4253039E16F for ; Thu, 19 Jul 2012 11:56:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmqryNroD5+K for ; Thu, 19 Jul 2012 11:56:04 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4166139E062 for ; Thu, 19 Jul 2012 11:56:04 +0200 (CEST) Message-ID: <5007D9B4.6020008@alvestrand.no> Date: Thu, 19 Jul 2012 11:56:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] API requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 09:55:15 -0000 On 07/09/2012 11:10 PM, Martin Thomson wrote: > We have just submitted a draft for discussion in the rtcweb working group: > > > > This draft describes the information that must pass between browser > and application in order to establish real-time communications. This > is not user-facing requirements (-rtcweb-use-cases-and-requirements) > or an outright API specification (-jsep). > > The goal here is to enable the creation and consumption of streams of > media packets within the security constraints. The draft describes > the minimum necessary set of information only to achieve this end. Thanks for submitting this! I must admit to being quite confused by the actual requirements in the draft - I have no idea what use case they're intending to enable, and thus I have no idea why the authors have chosen MUST rather than SHOULD or MAY as the requirement levels. For instance. ICE-5 The application MUST be able to add STUN attributes to the STUN messages that are sent for connectivity checks. What application does this enable? What are the security implications? MED-1 The application MUST be able to select the UDP flow that an RTP stream uses. MED-2 The application MUST be able select the UDP flow that RTCP for a given RTP stream uses. What application does this enable, compared to mechanisms that assign RTP and RTCP to a given UDP flow and report the results back? MED-7 The application MUST be able to specify the RTP packet type that is used to identify codecs in RTP streams, both inbound and outbound. Again, what application does this enable, compared to mechanisms that assign a packet type and inform the application of which one was chosen? > > In related news, Microsoft just joined the W3C Web Real-Time > Communications Working Group. Once a few clerical issues are > addressed, new W3C proposals that address these requirements will > follow. Looking forward to seeing the proposals, and seeing your proposals for how they can be pursued without impacting the progress of the present specifications and implementations! > > --Martin > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Jul 19 03:06:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72AC21F87B2 for ; Thu, 19 Jul 2012 03:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzr0oTtpRO3P for ; Thu, 19 Jul 2012 03:06:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 76CE621F87B4 for ; Thu, 19 Jul 2012 03:06:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69AB339E16F for ; Thu, 19 Jul 2012 12:07:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gkv74Wzn5P0 for ; Thu, 19 Jul 2012 12:07:23 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9F93339E062 for ; Thu, 19 Jul 2012 12:07:23 +0200 (CEST) Message-ID: <5007DC5B.8070108@alvestrand.no> Date: Thu, 19 Jul 2012 12:07:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FEAB80A.7040207@ericsson.com> <4FEAB948.4070302@infosecurity.ch> <4FEB71F8.2000403@infosecurity.ch> <4FEB7701.8050209@infosecurity.ch> In-Reply-To: <4FEB7701.8050209@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 10:06:42 -0000 Branching off a discussion because we seem to have two people saying contradictory things about something that may actually have a clear answer: When sending an UDP packet over a random port pair across an LTE network, is it transferred in acknowledged mode (with L2-level retransmissions) or in unacknowledged mode (without retransmissions)? The possible answers seem to be (if I understand the statements correctly): - Acknowledged (Cameron) - Unacknowledged (Fabio) - "It depends" Unlike some other arguments in the parent thread, this one seems to be amenable to source citations. On 06/27/2012 11:11 PM, Fabio Pietrosanti (naif) wrote: > On 6/27/12 10:54 PM, Cameron Byrne wrote: >>> You are saying that in EDGE, UMTS, HSDPA when an IP stack send an UDP >>> packet, it will handled from L2 like in the old age of GSM CSD and be >>> automatically retransmitted? >>> >> Yes. LTE too. > I read (by googling cause i don't have LTE access) that also LTE uses > for IPTV and all other IP streaming applications the UM_RLC > (unacknowledged mode). > > So also LTE should not do retransmission, unless being set in AM_RLC > (acknowledged mode). > > Fabio > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From csp@csperkins.org Thu Jul 19 03:15:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8630521F877D for ; Thu, 19 Jul 2012 03:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFUrvFB6WOfm for ; Thu, 19 Jul 2012 03:15:26 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id C8E1321F876A for ; Thu, 19 Jul 2012 03:15:26 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SrnmL-00056o-cT; Thu, 19 Jul 2012 10:16:17 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Thu, 19 Jul 2012 11:16:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ted Hardie X-Mailer: Apple Mail (2.1278) Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 10:15:27 -0000 On 18 Jul 2012, at 20:48, Ted Hardie wrote: > A draft agenda has been posted at: > http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb >=20 > Edits and adjustments still possible; comments to the list. Is there anything people want to discuss around rtp-usage that needs = agenda time? There are a few open issues noted in the draft, but they = almost all depend on the results of other discussions that will happen = at the meeting (i.e., the keying and codec discussions). Otherwise, = feedback on details would be useful, but that's probably better done of = the list. --=20 Colin Perkins http://csperkins.org/ From goran.ap.eriksson@ericsson.com Thu Jul 19 04:40:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A6521F8702 for ; Thu, 19 Jul 2012 04:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.566 X-Spam-Level: X-Spam-Status: No, score=-5.566 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpqvOixCkf0q for ; Thu, 19 Jul 2012 04:40:19 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7042B21F8701 for ; Thu, 19 Jul 2012 04:40:18 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-7b-5007f256bcce Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FE.77.15286.652F7005; Thu, 19 Jul 2012 13:41:10 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.218]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 19 Jul 2012 13:41:09 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 19 Jul 2012 13:41:08 +0200 Thread-Topic: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP? Thread-Index: Ac1lllO0YFVkfjxoQbqThQmBOpj/XgACXBes Message-ID: References: <4FEAB80A.7040207@ericsson.com> <4FEAB948.4070302@infosecurity.ch> <4FEB71F8.2000403@infosecurity.ch> <4FEB7701.8050209@infosecurity.ch>,<5007DC5B.8070108@alvestrand.no> In-Reply-To: <5007DC5B.8070108@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW7YJ/YAg4990hbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJmX77AXnBfuGLyiZcsDYz/+LsYOTkkBEwk 3q+dzAphi0lcuLeerYuRi0NI4BSjxJMfM6GcuYwSz96eZgKpYhPwlpi24ixYh4hAsETv8/eM IDaLgKrEqflngWo4OIQF7CRuX/aEKLGX+HvjIBOEbSRxY90vMJtXIFziwfNlbCC2kMBxZolP p8VBbE4BXYmXt6+BjWcUkJW4//0eC4jNLCAu8XnuAyaIQwUkluw5zwxhi0q8fPwPql5G4tSi /6wQ9XoSN6ZOYYOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKJybmJmT Xm6kl1qUmVxcnJ+nV5y6iREYIwe3/FbdwXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MMYonile5Z6sldP38eP+A0mOFufTNqXPbDz34QzbDRG9+vVCypEeDdM+ +ndm9ESzPXaf8UD7n8m7T7m/J4nqN795076w90PP+nAxN82nrB+kw/zeKatukppSJ2ue3+lq esVGzPntF79/lVvMfSftb+2tnVp3+aZT1p1/sc9tl7YEL5rKZK59UYmlOCPRUIu5qDgRAJg2 MU1fAgAA Subject: Re: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 11:40:19 -0000 ________________________________________ Fr=E5n: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] för Harald A= lvestrand [harald@alvestrand.no] Skickat: den 19 juli 2012 12:07 Till: rtcweb@ietf.org =C4mne: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP? Branching off a discussion because we seem to have two people saying contradictory things about something that may actually have a clear answer: When sending an UDP packet over a random port pair across an LTE network, is it transferred in acknowledged mode (with L2-level retransmissions) or in unacknowledged mode (without retransmissions)? The possible answers seem to be (if I understand the statements correctly): - Acknowledged (Cameron) - Unacknowledged (Fabio) - "It depends" As far as I know, both AM and UM can be used in a "radio bearer" in LTE= . Whether to use AM/UM when realizing/configuring a "radio bearer" depends partly on the requirements on delay, packet l= oss, etc for the "radio bearer". AM introduces delay but how much differs of course from 2G, 3G, LTE (4G)= . For this reason UM has been preferred. With LTE however- since the retransmission- things may be different and = AM *may* be useful even for RTC radio bearers. I guess it also depends on the characteristics of the specific radio net= work in question. In the end, I am not sure exactly how it is of relevance for this WG but = that may in itself be worth while discussing and both Cullens DSCP draft and Markus Mobile draft is a first step. Unlike some other arguments in the parent thread, this one seems to be amenable to source citations. On 06/27/2012 11:11 PM, Fabio Pietrosanti (naif) wrote: > On 6/27/12 10:54 PM, Cameron Byrne wrote: >>> You are saying that in EDGE, UMTS, HSDPA when an IP stack send an UDP >>> packet, it will handled from L2 like in the old age of GSM CSD and be >>> automatically retransmitted? >>> >> Yes. LTE too. > I read (by googling cause i don't have LTE access) that also LTE uses > for IPTV and all other IP streaming applications the UM_RLC > (unacknowledged mode). > > So also LTE should not do retransmission, unless being set in AM_RLC > (acknowledged mode). > > Fabio > _______________________________________________ > 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 stefan.lk.hakansson@ericsson.com Thu Jul 19 04:58:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ADF21F871E for ; Thu, 19 Jul 2012 04:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAhn-MCiWtPB for ; Thu, 19 Jul 2012 04:58:49 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF621F871C for ; Thu, 19 Jul 2012 04:58:48 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-02-5007f6ac42ed Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E9.B0.07365.CA6F7005; Thu, 19 Jul 2012 13:59:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Thu, 19 Jul 2012 13:59:40 +0200 Message-ID: <5007F6AB.5000705@ericsson.com> Date: Thu, 19 Jul 2012 13:59:39 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre7ab+wBBmtnsVus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMMTD7IXLBCtuLrwKmMD43/+LkZODgkBE4lnO24xQ9hiEhfu rWfrYuTiEBI4xShxfsF6FghnOaPE4TVb2UGqeAW0Je5tXcQEYrMIqEpMWXmFDcRmE7CRWNs9 BSwuKhAisebbFEaIekGJkzOfsIDYIgLCEltf9YLVCAtYSDS+/gpmCwkESMx4PgXoCg4OToFA iUcvJEHCzAK2EhfmXGeBsOUltr+dwwxRrivx7vU91gmMArOQbJiFpGUWkpYFjMyrGIVzEzNz 0ssN9VKLMpOLi/Pz9IpTNzECw+/glt+6OxhPnRM5xCjNwaIkzsuVtN9fSCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA2PYFK6tP1yrp0k8WLKMMWrx6/8n9fVOnWr71+acfZ9hr/+d9Ldm/M3H q/dfCPsxwefdgcOLN27cMTPfPcht9WFjqzufKo1bPqf4XJq/WPRQhRRbdsp3rTX7fHW/B9w4 t+9aOU9hgPm/h/4/F3EqnVw5YX3i8+9bzz0rYUqenfJPYgb3zBNHj2yfpcRSnJFoqMVcVJwI ANxtv/cNAgAA Subject: Re: [rtcweb] Proposed new milestones for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 11:58:50 -0000 This looks reasonable to me. The possible exception would be: I think the data parts could be earlier (given that the media stuff can be delivered as proposed - 4 months extra for the data seems a bit much). Stefan On 07/18/2012 09:08 PM, Ted Hardie wrote: > As folks know, we are behind on our milestones. The following > milestones represent a proposal from me and Magnus, based on some text > from Cullen. Please review in light of our deliverable list: > > 1. Define the communication model in detail, including how session > management is to occur within the model. > > 2. Define a security model that describes the security and privacy > goals and specifies the security protocol mechanisms necessary > to achieve those goals. > > 3. Define the solution - protocols and API requirements - for > firewall and NAT traversal. > > 4. Define which media functions and extensions shall be supported in > the client and their usage for real-time media, including media > adaptation to ensure congestion safe usage. > > 5. Define what functionalities in the solution, such as media codecs, > security algorithms, etc., can be extended and how the > extensibility mechanisms works. > > 6. Define a set of media formats that must or should be supported by > a client to improve interoperability. > > 7. Define how non media data is transported between clients in a > secure and congestion safe way. > > 8. Provide W3C input for the APIs that comes from the communication > model and the selected components and protocols that are part of > the solution. > > 9. The group will consider options for interworking with legacy VoIP > equipment. > > Timeline: > > Sep 2012 - Send Use Cases document to IESG for publication as Informational > Sep 2012 - Complete Overview (and hold for dependency resolution) > Sep 2012 - Send Security and Privacy Problem Statement to IESG for > publication as Informational > > Jan 2013 - Send Signalling Negotiation and NAT Traversal to IESG for > publication as Proposed Standard > Jan 2013 - Send Security Solution to IESG for publication as Proposed Standard > Jan 2013 - Send Media Transport, Media Processing, and Codecs to > IESG for publication as Proposed Standard > > May 2013 - Send Data Stream Transport for non-media data to IESG for > publication as Proposed Standard > > Comments, please! > > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From cb.list6@gmail.com Thu Jul 19 05:09:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1167521F8769 for ; Thu, 19 Jul 2012 05:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrdWZmc-J-zd for ; Thu, 19 Jul 2012 05:09:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0638521F8759 for ; Thu, 19 Jul 2012 05:09:43 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4456965pbc.31 for ; Thu, 19 Jul 2012 05:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xxnPmuuplse2MlYPnT9n8s79js1DbJs9lGaUc9foKNs=; b=vhINH+LDXKv6ABTcaOldsEdFpPAYlTn+cjCLRm8JOsmPgxzNAwfbHilx/jgAc2qmkf p54GYifaJWm9mLHZlgDwMWtO+20jZdJBoTsFSSObbq0NFs7pTa9g87OdOkwihVmZ1jlq wbxl4JkYtOXSpYU1uNWMqGNq0WYTTBVu74W5Tq5zTHpEBZV/LnwO3ja6BBxnI8ifA5n1 Qz2mq1RozUEeirTPo3qesuR8vNmBCS1zCIdgpMRB+h9jRqYmi/2tPKicFpm/9AF6eGdJ zB+RHcA7GeGnIKJYOOeUbaWg/t3Cu/tltyRVt0+hqfDdT6vorg2hVa2PpqCyPDqdkQjk v71Q== MIME-Version: 1.0 Received: by 10.68.213.67 with SMTP id nq3mr4765438pbc.142.1342699836872; Thu, 19 Jul 2012 05:10:36 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Thu, 19 Jul 2012 05:10:36 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Thu, 19 Jul 2012 05:10:36 -0700 (PDT) In-Reply-To: References: <4FEAB80A.7040207@ericsson.com> <4FEAB948.4070302@infosecurity.ch> <4FEB71F8.2000403@infosecurity.ch> <4FEB7701.8050209@infosecurity.ch> <5007DC5B.8070108@alvestrand.no> Date: Thu, 19 Jul 2012 05:10:36 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?G=F6ran_Eriksson_AP?= Content-Type: multipart/alternative; boundary=e89a8ff24e9dd118ed04c52daa62 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 12:09:45 -0000 --e89a8ff24e9dd118ed04c52daa62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Jul 19, 2012 4:41 AM, "G=F6ran Eriksson AP" wrote: > > > ________________________________________ > Fr=E5n: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] för Harald Alvestrand [harald@alvestrand.no] > Skickat: den 19 juli 2012 12:07 > Till: rtcweb@ietf.org > =C4mne: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP? > > Branching off a discussion because we seem to have two people saying > contradictory things about something that may actually have a clear answer: > > When sending an UDP packet over a random port pair across an LTE > network, is it transferred in acknowledged mode (with L2-level > retransmissions) or in unacknowledged mode (without retransmissions)? > > The possible answers seem to be (if I understand the statements correctly): > > - Acknowledged (Cameron) Works in mobile network > - Unacknowledged (Fabio) > - "It depends" > > As far as I know, both AM and UM can be used in a "radio bearer" in LTE. Whether to use AM/UM when realizing/configuring > a "radio bearer" depends partly on the requirements on delay, packet loss, etc for the "radio bearer". > It is a radio bearer parameter controlled by the qos profile on a per bearer basis. It has nothing to do with dscp, udp, or the application you are using.... It has do more with the user profile and apn in use.... More like layer 1 setup than layer markings or layer 7 apps > AM introduces delay but how much differs of course from 2G, 3G, LTE (4G). For this reason UM has been preferred. > With LTE however- since the retransmission- things may be different and AM *may* be useful even for RTC radio bearers. > All theoretically correct so far, i am not sure how much UM exists in the real world > I guess it also depends on the characteristics of the specific radio network in question. > Actually, it depends on implementation. UM is generally not implemented afaik. A MAJOR radio manufacturer confirmed they have no support for UM in practical LTE deployments, only AM. At the network i work at, there is no plan for UM support in any scenario, which is pretty much the default setting and radio vendor recommentation. I tried to push UM on them after our discussion on list, but no luck. CB > In the end, I am not sure exactly how it is of relevance for this WG but that may in itself be worth while discussing and both > Cullens DSCP draft and Markus Mobile draft is a first step. > > > Unlike some other arguments in the parent thread, this one seems to be > amenable to source citations. > > On 06/27/2012 11:11 PM, Fabio Pietrosanti (naif) wrote: > > On 6/27/12 10:54 PM, Cameron Byrne wrote: > >>> You are saying that in EDGE, UMTS, HSDPA when an IP stack send an UDP > >>> packet, it will handled from L2 like in the old age of GSM CSD and be > >>> automatically retransmitted? > >>> > >> Yes. LTE too. > > I read (by googling cause i don't have LTE access) that also LTE uses > > for IPTV and all other IP streaming applications the UM_RLC > > (unacknowledged mode). > > > > So also LTE should not do retransmission, unless being set in AM_RLC > > (acknowledged mode). > > > > Fabio > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --e89a8ff24e9dd118ed04c52daa62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Jul 19, 2012 4:41 AM, "G=F6ran Eriksson AP" <goran.ap.eriksson@ericsson.com&g= t; wrote:
>
>
> ________________________________________
> Fr=E5n: rtcweb-bounces@ietf= .org [rtcweb-bounces@ietf.or= g] f&#246;r Harald Alvestrand [harald@alvestrand.no]
> Skickat: den 19 juli 2012 12:07
> Till: rtcweb@ietf.org
> =C4mne: [rtcweb] LTE using AM_RLC or UM_RLC mode for UDP?
>
> Branching off a discussion because we seem to have two people saying > contradictory things about something that may actually have a clear an= swer:
>
> When sending an UDP packet over a random port pair across an LTE
> network, is it transferred in acknowledged mode (with L2-level
> retransmissions) or in unacknowledged mode (without retransmissions)?<= br> >
> The possible answers seem to be (if I understand the statements correc= tly):
>
> - Acknowledged (Cameron)

Works in mobile network

> - Unacknowledged (Fabio)
> - "It depends"
>
> =A0 =A0 As far as I know, both AM and UM can be used in a "radio = bearer" in LTE. Whether to use AM/UM when realizing/configuring
> =A0 =A0 a "radio bearer" =A0depends partly on the requiremen= ts on delay, packet loss, etc for the "radio bearer".
>

It is a radio bearer parameter controlled by the qos profile on a per be= arer basis. It has nothing to do with dscp, udp, or the application you are= using.... It has do more with the user profile and apn in use.... More lik= e layer 1 setup than layer markings or layer 7 apps

> =A0 =A0AM introduces delay but how much differs of course from 2G, = 3G, LTE (4G). For this reason UM has been preferred.
> =A0 =A0With LTE however- since the retransmission- things may be diffe= rent and AM *may* be useful even for RTC radio bearers.
>

All theoretically correct so far, i am not sure how much UM exists in th= e real world

> =A0 =A0I guess it also depends on the characteristics of the specif= ic radio network in question.
>

Actually, it depends on implementation. UM is generally not implemented = afaik. A MAJOR radio manufacturer confirmed they have no support for UM in = practical LTE deployments, only AM.=A0 At the network i work at, there is n= o plan for UM support in any scenario, which is pretty much the default set= ting and radio vendor recommentation. I tried to push UM on them after our = discussion on list, but no luck.

CB
> =A0 In the end, I am not sure exactly how it is of relevance for this = WG but that may in itself be worth while discussing and both
> =A0 Cullens DSCP draft and Markus Mobile draft is a first step.
>
>
> Unlike some other arguments in the parent thread, this one seems to be=
> amenable to source citations.
>
> On 06/27/2012 11:11 PM, Fabio Pietrosanti (naif) wrote:
> > On 6/27/12 10:54 PM, Cameron Byrne wrote:
> >>> You are saying that in EDGE, UMTS, HSDPA when an IP stack= send an UDP
> >>> packet, it will handled from L2 like in the old age of GS= M CSD and be
> >>> automatically retransmitted?
> >>>
> >> Yes. LTE too.
> > I read (by googling cause i don't have LTE access) that also = LTE uses
> > for IPTV and all other IP streaming applications the UM_RLC
> > (unacknowledged mode).
> >
> > So also LTE should not do retransmission, unless being set in AM_= RLC
> > (acknowledged mode).
> >
> > Fabio
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--e89a8ff24e9dd118ed04c52daa62-- From igor.faynberg@alcatel-lucent.com Thu Jul 19 09:24:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29621F860B for ; Thu, 19 Jul 2012 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.742 X-Spam-Level: X-Spam-Status: No, score=-7.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kknB2tFw+Byc for ; Thu, 19 Jul 2012 09:24:48 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 551DA21F85E3 for ; Thu, 19 Jul 2012 09:24:46 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q6JGPatX007238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 19 Jul 2012 11:25:36 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6JGPZRU028304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Jul 2012 11:25:35 -0500 Received: from [135.222.232.88] (USMUYN0L055118.mh.lucent.com [135.222.232.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6JGPYQO015127; Thu, 19 Jul 2012 11:25:35 -0500 (CDT) Message-ID: <500834FE.5040809@alcatel-lucent.com> Date: Thu, 19 Jul 2012 12:25:34 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201207190742.q6J7glf6008744@vivaldi29.register.it> In-Reply-To: <201207190742.q6J7glf6008744@vivaldi29.register.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:24:49 -0000 On 7/19/2012 3:42 AM, Domenico Colella wrote: > ... > Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and compatible with their legacy devices ?) or translators in order to support RTCWeb instead of a SRTMP server/gateway (i.e. open-source free products as Red5) and use FLASH ?.. Why is a "DTLS-SRTP gateway" needed--expensive or cheap? DTLS-SRTP is end-to-end. Igor From richard.ejzak@alcatel-lucent.com Thu Jul 19 09:25:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FF921F85E3 for ; Thu, 19 Jul 2012 09:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.105 X-Spam-Level: X-Spam-Status: No, score=-8.105 tagged_above=-999 required=5 tests=[AWL=-1.857, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpPgJcXDkH5C for ; Thu, 19 Jul 2012 09:25:35 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id BBEBE21F860B for ; Thu, 19 Jul 2012 09:25:34 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6JGPwcq010238 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 19 Jul 2012 18:26:26 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jul 2012 18:26:07 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.33]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 19 Jul 2012 12:26:04 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] data channel protocol comments and potential agenda topic Thread-Index: Ac1lyy6PQOhDXDGkSAC+0BA2iG8yWw== Date: Thu, 19 Jul 2012 16:26:04 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F1770A313US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:25:37 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F1770A313US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have concerns about the data channel protocol as defined in draft-jesup-r= tcweb-data-protocol-02.txt and suggest that this could be a worthwhile topic for di= scussion in Vancouver: 1. It requires many messages to be exchanged before any actual user data= is sent. 2. It is used to set up bidirectional channels whereas a simpler convent= ion might serve the same purpose without need of messaging (e.g., use of th= e same stream identifier in both directions). 3. No mechanism has been defined to allow the application to specify the= purpose of a data channel. In particular, no mechanism is defined to allo= w the application to specify the payload protocol id (other than ascii/bina= ry). 4. Data channel characteristics must be specified in advance for all dat= a carried on a data channel, whereas SCTP allows these characteristics to b= e controlled dynamically per chunk of transmitted data. So new channels ne= ed to be unnecessarily created and destroyed dynamically to accommodate dif= ferent characteristics. 5. Data channels emulate websockets and are limited by the websockets mo= del rather than leveraging the capabilities of SCTP and specifying function= ality useful for data channels. Why do we need any data channel protocol at all? It is just a redundant ex= change of information about SCTP protocol options that can be communicated = by SCTP itself with each block of data, i.e., let's turn this into an API i= ssue and not a protocol issue. Why don't we instead specify the API to allow the application to select the= SCTP transmission characteristics (including stream id, ppid, ordered, rel= iable, etc.) needed per data block to be transmitted. Alternately, the API= could specify and then allow changes to these characteristics for a channe= l to influence the SCTP protocol options selected without initiating a data= channel protocol negotiation or requiring release of the channel. Either approach would allow new ppid's to be assigned as needed for applica= tions to indicate the purpose of each data chunk (or sequence of data chunk= s) to be transmitted. The application will be able to send data with the d= esired reliability characteristics immediately without waiting to exchange = setup messages. And each data channel can be repurposed dynamically withou= t requiring signaling to release and renegotiate channel characteristics. Richard --_000_03FBA798AC24E3498B74F47FD082A92F1770A313US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have concerns about the data= channel protocol as defined in draft-jesup-rtcweb-data-protocol-02.= txt and suggest that this could be a worthwhile topic for discussion in Vancouver:

 

  1. It requires many messages to be exchanged before any actua= l user data is sent.
  2. It is used to set up bidirectional channels whereas= a simpler convention might serve the same purpose without need of messaging (e.g., use of the same stream identifier in both directi= ons).
  3. No mechanism has been defined to allow the applicat= ion to specify the purpose of a data channel.  In particular, no mechanism is defined to allow the application to specify the payload pr= otocol id (other than ascii/binary).
  4. Data channel characteristics must be specified in a= dvance for all data carried on a data channel, whereas SCTP allows these characteristics to be controlled dynamically per chunk of tra= nsmitted data.  So new channels need to be unnecessarily created and d= estroyed dynamically to accommodate different characteristics.
  5. Data channels emulate websockets and are limited by= the websockets model rather than leveraging the capabilities of SCTP and specifying functionality useful for data channels.<= /span>

 

Why do we need any data channe= l protocol at all?  It is just a redundant exchange of information abo= ut SCTP protocol options that can be communicated by SCTP itself with each block of data, i.e., let’s turn this into a= n API issue and not a protocol issue.

 

Why don’t we instead spe= cify the API to allow the application to select the SCTP transmission chara= cteristics (including stream id, ppid, ordered, reliable, etc.) needed per data block to be transmitted.  Alternately= , the API could specify and then allow changes to these characteristics for= a channel to influence the SCTP protocol options selected without initiati= ng a data channel protocol negotiation or requiring release of the channel.

 

Either approach would allow ne= w ppid’s to be assigned as needed for applications to indicate the pu= rpose of each data chunk (or sequence of data chunks) to be transmitted.  The application will be able to send data= with the desired reliability characteristics immediately without waiting t= o exchange setup messages.  And each data channel can be repurposed dy= namically without requiring signaling to release and renegotiate channel characteristics.

 

Richard

 

--_000_03FBA798AC24E3498B74F47FD082A92F1770A313US70UWXCHMBA04z_-- From lists@infosecurity.ch Thu Jul 19 09:28:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4A921F8559 for ; Thu, 19 Jul 2012 09:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX+1aSTzv-jx for ; Thu, 19 Jul 2012 09:28:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE021F8575 for ; Thu, 19 Jul 2012 09:28:31 -0700 (PDT) Received: by weyu54 with SMTP id u54so2192850wey.31 for ; Thu, 19 Jul 2012 09:29:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=GDk/yWkGlngB6ASio+VaIaa5pXCAuGstQJB5ARlbFJI=; b=QYyl7xeuxWOZl4zE85b6iu+t2guuMyCW516iMVySyWtsDSBTCJC01uODg4JJ+P1LMQ LsM8L4KovGyJInkcj6ZroJ/ob2tNRqMyT2HVVi9oadwXSNXC0NlcinENi5V6JiNfaxvO in0q4KCpwEugKtenHzWXOIvUtBVv9C8nygEYxzkQdt2u2TMsXyiXPW63vcpzRmTx/ZJ1 sr+fqBHzs6yHI++Z7Yl7VXvcHXjqoS8CFY7uPCpfqSZ5GQfJJiQbQGUQCIxXxP1kshVN 9NLC/5QYmGup4xIjEVSewsoN4RdI6Sjhus8R6+eW+Sb1OSBFiWbGucHJD9ybxsx9DIOd mSpg== Received: by 10.180.100.131 with SMTP id ey3mr6233569wib.15.1342715364613; Thu, 19 Jul 2012 09:29:24 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id fb20sm7203107wid.1.2012.07.19.09.29.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 09:29:23 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <500835E1.2070502@infosecurity.ch> Date: Thu, 19 Jul 2012 18:29:21 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> In-Reply-To: <500834FE.5040809@alcatel-lucent.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmSIFlleAtqZta+jZ3KBvnDzMo1XSuP3FmZhcn/lVm4STchPMfTyOQKI782agLMNl493gdl Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:28:32 -0000 On 7/19/12 6:25 PM, Igor Faynberg wrote: > > On 7/19/2012 3:42 AM, Domenico Colella wrote: >> ... >> Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and >> compatible with their legacy devices ?) or translators in order to >> support RTCWeb instead of a SRTMP server/gateway (i.e. open-source >> free products as Red5) and use FLASH ?.. > > Why is a "DTLS-SRTP gateway" needed--expensive or cheap? DTLS-SRTP is > end-to-end. DTLS-SRTP does not provide end-to-end security in the WebRTC model, as already discussed in this mailing list. DTLS-SRTP does provide end-to-end encryption WITHOUT end-to-end security. Fabio From igor.faynberg@alcatel-lucent.com Thu Jul 19 10:41:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0714721F8803 for ; Thu, 19 Jul 2012 10:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfZCOhde7TWh for ; Thu, 19 Jul 2012 10:41:55 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD0E21F87E0 for ; Thu, 19 Jul 2012 10:41:55 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q6JHgmA5000350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 19 Jul 2012 12:42:48 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6JHgmsm014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Jul 2012 12:42:48 -0500 Received: from [135.222.232.88] (USMUYN0L055118.mh.lucent.com [135.222.232.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6JHgl8H015618; Thu, 19 Jul 2012 12:42:47 -0500 (CDT) Message-ID: <50084717.7060301@alcatel-lucent.com> Date: Thu, 19 Jul 2012 13:42:47 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> In-Reply-To: <500835E1.2070502@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 17:41:56 -0000 If both parties have certificates, DTLS will provide end-to-end security. (I have not yet heard a convincing argument why the certificates--I mean not self-signed ones--cannot be used.) And if the parties share a key, DTLS will work, too. Igor On 7/19/2012 12:29 PM, Fabio Pietrosanti (naif) wrote: > On 7/19/12 6:25 PM, Igor Faynberg wrote: >> On 7/19/2012 3:42 AM, Domenico Colella wrote: >>> ... >>> Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and >>> compatible with their legacy devices ?) or translators in order to >>> support RTCWeb instead of a SRTMP server/gateway (i.e. open-source >>> free products as Red5) and use FLASH ?.. >> Why is a "DTLS-SRTP gateway" needed--expensive or cheap? DTLS-SRTP is >> end-to-end. > DTLS-SRTP does not provide end-to-end security in the WebRTC model, as > already discussed in this mailing list. > > DTLS-SRTP does provide end-to-end encryption WITHOUT end-to-end security. > > Fabio > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Thu Jul 19 11:03:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFB921F8631 for ; Thu, 19 Jul 2012 11:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.491 X-Spam-Level: X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMRwaQBm1HC5 for ; Thu, 19 Jul 2012 11:02:59 -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 7629F21F862A for ; Thu, 19 Jul 2012 11:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4349; q=dns/txt; s=iport; t=1342721033; x=1343930633; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=u1f6xyEqVSRh2Xu85MK1OduEWBKjVgwxFLoDrtQmf1A=; b=bZVxOXJshJNwO8sW69jsiW197/NIvoKIlV1f93SUSzpz4nOiGxrX2j3F zLZMJ7v+neGoWtv/WQgvFR5oH4QeBVE/tNR3oqfGiw8BJpGnBU4hP4MHJ MQA+RSa4HuEFX6/twHA0Jz1GlVa+ITMosBqLdL6tTqD1GCwiYcKfk1sPI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAOJKCFCrRDoI/2dsb2JhbAAvDQmqEo8xgQeCIAEBAQIBAQEBAQUKARcHCS4GCwUHAQMCCQ8CAQMBARQUBxkOFQoDBggBAQQBCQcCCQIXh2UFDJ5JjyqQXYtMAw6GfwOITYULiH+NEIFmgn8e X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="52429290" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 19 Jul 2012 18:03:53 +0000 Received: from dwingWS (sjc-vpn4-1264.cisco.com [10.21.84.239]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6JI3qTu007156; Thu, 19 Jul 2012 18:03:52 GMT From: "Dan Wing" To: "'Domenico Colella'" , References: <201207190742.q6J7glf6008744@vivaldi29.register.it> In-Reply-To: <201207190742.q6J7glf6008744@vivaldi29.register.it> Date: Thu, 19 Jul 2012 11:03:52 -0700 Message-ID: <075201cd65d8$db37a210$91a6e630$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1lghz7xeTwP6kLRJ69/SMFWVSq0gAVAgpQ Content-Language: en-us Cc: daniele.filippi@ctiplanet.it Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:03:00 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Domenico Colella > Sent: Thursday, July 19, 2012 12:43 AM > To: rtcweb@ietf.org > Cc: daniele.filippi@ctiplanet.it > Subject: [rtcweb] Security Architecture: SDES support is a MUST > > In RTCWEB Security Architecture (draft-ietf-rtcweb-security-arch-03) I > noticed an open issue regarding SDES support: if browser > implementations MUST or MAY support it. > I got quite scared when I saw the word MAY. > I support the MUST option, because RTCWEB can be used not only for > peer-to-peer communication (i.e. Alice calling Bob), but also to access > services provided by the "calling service" (i.e.customer support, > customer attendant, voicemail ... or any service delivering also RT > audio/video that can be accessed through a website). In the latter > case, the user usually is already logged-in the "calling service" using > a secure connection (X.509 certificate have already be used to verify > calling service party) and the other endpoint usually is a server/phone > in company DMZ/intranet: communication is end-to-end secured and each > party trusts the other. At the moment SDES has a good support and it is > not that difficult to be implemented, on the contrary DTLS-SRTP it is > almost unknown. Doing SDES in RTCWEB means that SDES will persist in RTCWEB forever. SDESC combined with DTLS-SRTP complicates call transfers, three party calls (such as when a credit card issuer might conference a merchant and the cardholder into the same call), and SDES cannot provide 3rd party identity like can be done with DTLS-SRTP's handshake. There are more reasons; those are off the top of my head. > Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and > compatible with their legacy devices ?) or translators in order to > support RTCWeb instead of a SRTMP server/gateway (i.e. open-source free > products as Red5) and use FLASH ? At the moment FLASH is supported by > a considerably larger number of devices, and uses codecs "more > compliant" to legacy devices (iLBC is not that supported by phone > equipments). As I explained at IETF83 in Paris at the RTCWEB, interworking between DTLS-SRTP keying and SDESC keying can be done without expensive CPU operations. Reference http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt And, as I explained at IETF83 in Paris, some sort of gateway to 'legacy' equipment is going to be necessary for other reasons. Codec incompatibility (as you note) and responding to 'consent' checks (to reduce the impact of RTCWEB as an attack vector) will both be necessary on the media path for a lot of 'legacy' equipment. > Furthermore, in this scenario, the customer using i.e. the bank website > knows for sure he is communicating "privately" to his bank and trusts > the webserver. Why then setup a DTLS session or check identities ? Call transfers and three way calls are when SDES and real identity are important. I want RTCWEB to evolve beyond simple, point-to-point calls. > If > the customer is sending passwords, credit card numbers,... using > webserver connection why do not "trust" such connection to exchange RTP > keys as well ? > The word MUST is really important, because it grants that "every" > browser in the near future will support it and grants system > integrators, software developers and companies investing in building RT > services that SDES support will be mantained. The corollary is also true: allowing SDESC in WEBRTC means that SDESC will persist in _every element_ of WEBRTC, forever. This means every element of WEBRTC will incur the costs of interworking with DTLS-SRTP, call transfers, and 3 way calls. I would rather that effort be constrained to the edge of those 'legacy' networks that are using SDESC. As those atrophy or as those 'legacy' network endpoints add DTLS-SRTP support, Consent support, and codec support, the gateway functions will be reduced and eventually eliminated. -d > Regards, > Domenico Colella > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Thu Jul 19 13:18:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBBF21F85D2 for ; Thu, 19 Jul 2012 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jav0f0dDKRa for ; Thu, 19 Jul 2012 13:18:14 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 003B021F8652 for ; Thu, 19 Jul 2012 13:18:13 -0700 (PDT) Received: by yhq56 with SMTP id 56so3554645yhq.31 for ; Thu, 19 Jul 2012 13:19:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=wUjuFe9ipKjHAjs2K2RC8XXeQFwnmCzKaPm6oY1aC2M=; b=d33vbKZRDF8u3q/o7drs9pzFCL1YYdbR7Bfs5B29uYDz3oVjvm03mOQ9YbZwaka0ob 2k9W1+AEb3J6wY/Injsm3aE2dtGrsl8gk70Jw6ZJWGlm6fAlPO5azzHyk+xj2vST/+fq Fx71Q+VziAZ9VysjwicbQ89jLR7C5HScPT9RMuSP9ssjFBTnaDlcH7jk2SqBGHQWa66j 5GbK2LEQphK/lgm+EsIBIeerFypfPuN2ahWaISUn2ThBzMmuVoOWuaLu3u1RUbf3Nxb8 uJF7Ugl5pU1Vwq7Krw9U2zdHQ+qMwaxdEz4L8c224UOcqgDwYbkGfYekpKLTeeC0oDPq 2xiA== Received: by 10.236.200.167 with SMTP id z27mr3085305yhn.131.1342729147757; Thu, 19 Jul 2012 13:19:07 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id x4sm5540429yhh.2.2012.07.19.13.19.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 13:19:06 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3551191ggn.31 for ; Thu, 19 Jul 2012 13:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.70 with SMTP id qc6mr8103463pbc.92.1342729144392; Thu, 19 Jul 2012 13:19:04 -0700 (PDT) Received: by 10.68.194.202 with HTTP; Thu, 19 Jul 2012 13:19:04 -0700 (PDT) In-Reply-To: <075201cd65d8$db37a210$91a6e630$@com> References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <075201cd65d8$db37a210$91a6e630$@com> Date: Thu, 19 Jul 2012 16:19:04 -0400 Message-ID: From: Roman Shpount To: Dan Wing Content-Type: multipart/alternative; boundary=047d7b2edb81ae5a2d04c5347d63 X-Gm-Message-State: ALoCoQmkkftxqF/VZv2L1OIjE3i1sO/cD4bYdNBvFUVl6Zkri2n3OqxF6S2+6ob2QcGblRFk07r+ Cc: daniele.filippi@ctiplanet.it, rtcweb@ietf.org Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:18:14 -0000 --047d7b2edb81ae5a2d04c5347d63 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing wrote: > > As I explained at IETF83 in Paris at the RTCWEB, interworking > between DTLS-SRTP keying and SDESC keying can be done without > expensive CPU operations. Reference > http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf > http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt > > Even though I understand how you can bridge DTLS-SRTP with SRTP-EKV without re-encryption, I do not think it is possible to bridge SDES-SRTP with DTLS-SRTP the same way. Bridging DTLS-SRTP with SRTP-EKV is completely useless for legacy interop since old equipment is more likely to support DTLS-SRTP then EKV, which is not even standardized yet. This being said, I am strongly against supporting SDES-SRTP. Re-encoding is cheap and you can do nearly 10GB/s of AES encoding on a fairly modest modern server. Having more protocols to test and support is a much higher cost. _____________ Roman Shpount --047d7b2edb81ae5a2d04c5347d63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing <dwing@cisco.com= > wrote:

As I explained at IETF83 in Paris at the RTCWEB, interworking
between DTLS-SRTP keying and SDESC keying can be done without
expensive CPU operations. =A0Reference
http://www.ietf.org/proceedings/83/slides/slides-83-rtc= web-3.pdf
http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt


Even though I understand how you can b= ridge DTLS-SRTP with SRTP-EKV without re-encryption, I do not think it is p= ossible to bridge SDES-SRTP with DTLS-SRTP the same way. Bridging=A0DTLS-SR= TP with SRTP-EKV is completely useless for legacy interop since old equipme= nt is more likely to support DTLS-SRTP then EKV, which is not even standard= ized yet.

This being said, I am strongly against supporting SDES-= SRTP. Re-encoding is cheap and you can do nearly 10GB/s of AES encoding on = a fairly modest modern server. Having more protocols to test and support is= a much higher cost.
_____________
Roman Shpount
=A0
--047d7b2edb81ae5a2d04c5347d63-- From bernard_aboba@hotmail.com Thu Jul 19 13:40:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1021A11E8086 for ; Thu, 19 Jul 2012 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2vcmGP8t7dv for ; Thu, 19 Jul 2012 13:40:02 -0700 (PDT) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by ietfa.amsl.com (Postfix) with ESMTP id 420FC21F8634 for ; Thu, 19 Jul 2012 13:40:02 -0700 (PDT) Received: from BLU169-DS14 ([65.55.111.73]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jul 2012 13:40:56 -0700 X-Originating-IP: [131.107.0.87] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: , References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> In-Reply-To: <50084717.7060301@alcatel-lucent.com> Date: Thu, 19 Jul 2012 13:40:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXSOwIWv2p57H8l8mK12N1m7gdrwHW/w4JAX8XnSgA5ExXypZ7d3Xg Content-Language: en-us X-OriginalArrivalTime: 19 Jul 2012 20:40:56.0068 (UTC) FILETIME=[CBDFDC40:01CD65EE] Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:40:03 -0000 Self-signed certificates are only appropriate for a subset of scenarios. Do we expect IdP to be widely deployed in high security scenarios for government, financial or medical applications? I do not. Do we expect a call center to utilize IdP with a self-signed certificate? More likely is that they will utilize a certificate chaining to a trust anchor. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Igor Faynberg Sent: Thursday, July 19, 2012 10:43 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST If both parties have certificates, DTLS will provide end-to-end security. (I have not yet heard a convincing argument why the certificates--I mean not self-signed ones--cannot be used.) And if the parties share a key, DTLS will work, too. Igor From dwing@cisco.com Thu Jul 19 15:20:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5921F86C6 for ; Thu, 19 Jul 2012 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2c7m+9GDEtj for ; Thu, 19 Jul 2012 15:19:59 -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 6EF8A21F86BA for ; Thu, 19 Jul 2012 15:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3367; q=dns/txt; s=iport; t=1342736453; x=1343946053; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Q47Br357Gs+yPx+eOy7JjatAlURoTZNVs1pTOevaGdw=; b=HJGzawC+J0WAUCAZFAYPqzunKcARCsCux9hE9v+rWPWfAadtVr2vlyew kXacbFX1GELKK0GzHnahU7CmJXxeaQKEBzJCQQOkzkBtpWB/zJ1LbpM+t 7zEM2CgkdjDSTXg8NeGPends10ytNHxVThWOdqSJIBZYjXxo1nGI5j0Dx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIuHCFCrRDoG/2dsb2JhbABFqhiPMoEHgiABAQECAQEICgEXED8FBwEDAgkPAgEDAQEBJwcZIwoDBggBAQQTCQIXh2UFDJ5VoBSLTIZgA4hNhQuIf40QgWaCfw X-IronPort-AV: E=Sophos;i="4.77,617,1336348800"; d="scan'208";a="49335821" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 19 Jul 2012 22:20:53 +0000 Received: from dwingWS (sjc-vpn4-1264.cisco.com [10.21.84.239]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6JMKqFH010045; Thu, 19 Jul 2012 22:20:53 GMT From: "Dan Wing" To: "'Roman Shpount'" References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <075201cd65d8$db37a210$91a6e630$@com> In-Reply-To: Date: Thu, 19 Jul 2012 15:20:52 -0700 Message-ID: <081e01cd65fc$c29e2340$47da69c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1l65OAzIr202rMRWa25tknkIfWxgABzJ4A Content-Language: en-us Cc: daniele.filippi@ctiplanet.it, rtcweb@ietf.org Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 22:20:01 -0000 > -----Original Message----- > From: Roman Shpount [mailto:roman@telurix.com] > Sent: Thursday, July 19, 2012 1:19 PM > To: Dan Wing > Cc: Domenico Colella; rtcweb@ietf.org; daniele.filippi@ctiplanet.it > Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST > > > On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing wrote: > > > > As I explained at IETF83 in Paris at the RTCWEB, interworking > between DTLS-SRTP keying and SDESC keying can be done without > expensive CPU operations. Reference > http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf > http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt > > > > > Even though I understand how you can bridge DTLS-SRTP with SRTP-EKV > without re-encryption, I do not think it is possible to bridge SDES- > SRTP with DTLS-SRTP the same way. Short answer: you are right, the WEBRTC network needs DTLS-SRTP and EKT. Without EKT, it is possible to interwork in one direction without re-keying each SRTP packet, specifically the packets going from the DTLS-SRTP network to the SDESC network can be forwarded without re-keying. However, in the the other direction (from SDESC network to DTLS-SRTP network), those SRTP packets would need to be rekeyed. This is depicted in slide 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf where the media gateway is on fire (it is doing lots of CPU processing to rekey those SRTP packets in the 'red' direction). To avoid that rekeying in that direction, we add EKT on the DTLS-SRTP network. With EKT, there is no longer a need to rekey SRTP in either direction. This is depicted in slide 33 of the same presentation as above. EKT has other advantages for group video conferencing, which allow video switching devices to avoid re-keying -- which reduces costs (and saves energy, everybody is about saving energy!). It was those advantages which led to the design of EKT in 2006 as draft-mcgrew-srtp-ekt-00, and the implementation in Cisco's telepresence systems. > Bridging DTLS-SRTP with SRTP-EKV is > completely useless for legacy interop since old equipment is more > likely to support DTLS-SRTP then EKV, which is not even standardized > yet. The majority of legacy systems seem to use SDESC keying, not DTLS-SRTP keying. And we don't need to change those legacy systems for this interworking. There were no DTLS-SRTP implementations brought to SIPit 29, https://www.sipit.net/SIPit29_summary, and 80% that had SRTP support used SDESC keying. Assuming that SIPit is a more-or-less accurate representation of the market, the 'legacy' market uses SDESC keying if it supports SRTP at all. Of course, there is also a lot of 'legacy' equipment only supports RTP. That is yet another reason for an interworking gateway in front of that RTP-only equipment. > This being said, I am strongly against supporting SDES-SRTP. Re- > encoding is cheap and you can do nearly 10GB/s of AES encoding on a > fairly modest modern server. Having more protocols to test and support > is a much higher cost. Some objected to that cost, and after Magnus and Jonathan Lennox suggested EKT be changed slightly to allow each packet to be self- describing, we now have a very efficient way to interwork the SRTP packets. -d From harald@alvestrand.no Thu Jul 19 22:33:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5139221F84EE for ; Thu, 19 Jul 2012 22:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.084 X-Spam-Level: X-Spam-Status: No, score=-110.084 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nLeaxmW1zfX for ; Thu, 19 Jul 2012 22:33:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B493721F84EC for ; Thu, 19 Jul 2012 22:33:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D17D039E179 for ; Fri, 20 Jul 2012 07:34:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2l-LYmPnVRb for ; Fri, 20 Jul 2012 07:34:15 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7E92339E091 for ; Fri, 20 Jul 2012 07:34:15 +0200 (CEST) Message-ID: <5008EDD7.60801@alvestrand.no> Date: Fri, 20 Jul 2012 07:34:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------050904020408070303070608" Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 05:33:27 -0000 This is a multi-part message in MIME format. --------------050904020408070303070608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One particular thread about this, the idea of "purpose": I believe that standardizing a semantic for "purpose", and trying to encode that into a short integer field such as PPID, is an architectural mistake in protocols where the set of possible purposes is unlimited. The protocol needs to make sure the two ends can agree on the identity of a channel, and that the characteristics of the channel (for instance unreliable/reliable, binary-transparent/non-binary-transparent, priority, capacity....) are known, as far as they can be. We should not try to encode "purpose". Without a defined semantic for "purpose", any such field is just a strange encoding of more data bytes, and is better carried as part of the application-dependent payload. I have opinions about the other points too, but I would like to get rid of the notion of encoding "purpose" in the data channel protocol. On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote: > > I have concerns about the data channel protocol as defined in > draft-jesup-rtcweb-data-protocol-02.txt > > and suggest that this could be a worthwhile topic for discussion in > Vancouver: > > 1. It requires many messages to be exchanged before any actual user > data is sent. > 2. It is used to set up bidirectional channels whereas a simpler > convention might serve the same purpose without need of messaging > (e.g., use of the same stream identifier in both directions). > 3. No mechanism has been defined to allow the application to specify > the purpose of a data channel. In particular, no mechanism is > defined to allow the application to specify the payload protocol > id (other than ascii/binary). > 4. Data channel characteristics must be specified in advance for all > data carried on a data channel, whereas SCTP allows these > characteristics to be controlled dynamically per chunk of > transmitted data. So new channels need to be unnecessarily > created and destroyed dynamically to accommodate different > characteristics. > 5. Data channels emulate websockets and are limited by the websockets > model rather than leveraging the capabilities of SCTP and > specifying functionality useful for data channels. > > Why do we need any data channel protocol at all? It is just a > redundant exchange of information about SCTP protocol options that can > be communicated by SCTP itself with each block of data, i.e., let's > turn this into an API issue and not a protocol issue. > > Why don't we instead specify the API to allow the application to > select the SCTP transmission characteristics (including stream id, > ppid, ordered, reliable, etc.) needed per data block to be > transmitted. Alternately, the API could specify and then allow > changes to these characteristics for a channel to influence the SCTP > protocol options selected without initiating a data channel protocol > negotiation or requiring release of the channel. > > Either approach would allow new ppid's to be assigned as needed for > applications to indicate the purpose of each data chunk (or sequence > of data chunks) to be transmitted. The application will be able to > send data with the desired reliability characteristics immediately > without waiting to exchange setup messages. And each data channel can > be repurposed dynamically without requiring signaling to release and > renegotiate channel characteristics. > > Richard > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050904020408070303070608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
One particular thread about this, the idea of "purpose":

I believe that standardizing a semantic for "purpose", and trying to encode that into a short integer field such as PPID, is an architectural mistake in protocols where the set of possible purposes is unlimited.

The protocol needs to make sure the two ends can agree on the identity of a channel, and that the characteristics of the channel (for instance unreliable/reliable, binary-transparent/non-binary-transparent, priority, capacity....) are known, as far as they can be. We should not try to encode "purpose".

Without a defined semantic for "purpose", any such field is just a strange encoding of more data bytes, and is better carried as part of the application-dependent payload.

I have opinions about the other points too, but I would like to get rid of the notion of encoding "purpose" in the data channel protocol.

On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote:

I have concerns about the data channel protocol as defined in draft-jesup-rtcweb-data-protocol-02.txt and suggest that this could be a worthwhile topic for discussion in Vancouver:

 

  1. It requires many messages to be exchanged before any actual user data is sent.
  2. It is used to set up bidirectional channels whereas a simpler convention might serve the same purpose without need of messaging (e.g., use of the same stream identifier in both directions).
  3. No mechanism has been defined to allow the application to specify the purpose of a data channel.  In particular, no mechanism is defined to allow the application to specify the payload protocol id (other than ascii/binary).
  4. Data channel characteristics must be specified in advance for all data carried on a data channel, whereas SCTP allows these characteristics to be controlled dynamically per chunk of transmitted data.  So new channels need to be unnecessarily created and destroyed dynamically to accommodate different characteristics.
  5. Data channels emulate websockets and are limited by the websockets model rather than leveraging the capabilities of SCTP and specifying functionality useful for data channels.

 

Why do we need any data channel protocol at all?  It is just a redundant exchange of information about SCTP protocol options that can be communicated by SCTP itself with each block of data, i.e., let’s turn this into an API issue and not a protocol issue.

 

Why don’t we instead specify the API to allow the application to select the SCTP transmission characteristics (including stream id, ppid, ordered, reliable, etc.) needed per data block to be transmitted.  Alternately, the API could specify and then allow changes to these characteristics for a channel to influence the SCTP protocol options selected without initiating a data channel protocol negotiation or requiring release of the channel.

 

Either approach would allow new ppid’s to be assigned as needed for applications to indicate the purpose of each data chunk (or sequence of data chunks) to be transmitted.  The application will be able to send data with the desired reliability characteristics immediately without waiting to exchange setup messages.  And each data channel can be repurposed dynamically without requiring signaling to release and renegotiate channel characteristics.

 

Richard

 



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


--------------050904020408070303070608-- From harald@alvestrand.no Thu Jul 19 22:38:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C285021F84EE for ; Thu, 19 Jul 2012 22:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.141 X-Spam-Level: X-Spam-Status: No, score=-110.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UufjKCNXudn for ; Thu, 19 Jul 2012 22:38:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 124E221F848B for ; Thu, 19 Jul 2012 22:38:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6146E39E179 for ; Fri, 20 Jul 2012 07:39:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ghpk+iT1syh for ; Fri, 20 Jul 2012 07:39:21 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 58FC239E091 for ; Fri, 20 Jul 2012 07:39:21 +0200 (CEST) Message-ID: <5008EF08.6080803@alvestrand.no> Date: Fri, 20 Jul 2012 07:39:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Terminate or Reject streams by setting port to zero in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 05:38:29 -0000 On 07/17/2012 07:35 AM, José Luis Millán wrote: > Hi, > > Offer/Answer Model with Session Description Protocol states that a > stream can be terminated or rejected by setting the port to zero in > the Offer/Answer SDP respectively. > > How can this be achieved with PeerConnection? Terminating a stream: Remove all references to the stream in the SDP "msid" attributes. draft-alvestrand-rtcweb-msid-02 section 4. Rejecting a stream: draft-westerlund-avtext-rtp-stream-pause-02 suggests one way to do this (I have not reviewed it). Note: An m-line (the entity in SDP that carries the port number) does NOT correspond to a WebRTC MediaStream. > > Thanks in advance. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lists@infosecurity.ch Thu Jul 19 23:15:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBD121F85D0 for ; Thu, 19 Jul 2012 23:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWRljqpHwDzl for ; Thu, 19 Jul 2012 23:15:38 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65C8B21F8589 for ; Thu, 19 Jul 2012 23:15:37 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2295147wgb.13 for ; Thu, 19 Jul 2012 23:16:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=pPZB5SQeyWUsRo664cmG+pC5Mz1ysFbRBqT3zo1YqT4=; b=Sg5gOcx/ZASDBei266g9M7NPP/FE+0cvUhkvsJJ1+JUCDB4WjeQ1O1eXDz4veEHNhv UeWFXxqTpCNN1Tobk6XfStCU7JlcsgR/5Vvej4dgw4V9FHYBhHAx6GGjj9vz1CKvFKCS c2aXqkGc8brmTBXLgFw40j0EVDl/ieo97gYNsyPy6STK2LYWt+v1XRg8BHEYg4cvVafk hdJ+gTm8zmPaeOZ+UCneI/8h68AHKi7QK94GRE3xnY1l5wLV9P3oPWUJcJjKjNWc5zJQ Dkvsn5Xz8A8r8lynuomPggdDCAbByWJWpkPZ2lLhNzKoWaWboNTAq+TFz7gIl85i1oOq uO9w== Received: by 10.216.61.8 with SMTP id v8mr2987992wec.156.1342764987917; Thu, 19 Jul 2012 23:16:27 -0700 (PDT) Received: from sonyvaiop13.local (93-32-169-160.ip34.fastwebnet.it. [93.32.169.160]) by mx.google.com with ESMTPS id w7sm42738720wiz.0.2012.07.19.23.16.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 23:16:26 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <5008F7B9.7020804@infosecurity.ch> Date: Fri, 20 Jul 2012 08:16:25 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnQgOEh27+Amjo/yiFWUuzr/5YzZQst8jT3KnyX5WJE5Oa/sx2RSAnT01DZTMCnnUsoCDl3 Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 06:15:39 -0000 On 7/19/12 10:40 PM, Bernard Aboba wrote: > Self-signed certificates are only appropriate for a subset of scenarios. Do > we expect IdP to be widely deployed in high security scenarios for > government, financial or medical applications? I do not. > > Do we expect a call center to utilize IdP with a self-signed certificate? > More likely is that they will utilize a certificate chaining to a trust > anchor. Until WebRTC does not employ an end-to-end authentication mechanism (like ZRTP's SAS applied to DTLS-SRTP), WebRTC is not going to provide end-to-end security. It's not a matter of considering just the encryption, but considering the "trust model" . Current security definition of WebRTC does not support end-to-end security. Fabio p.s. we have wrote tons of thread about it in past months explaining why and how From harald@alvestrand.no Fri Jul 20 06:05:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293E821F8659 for ; Fri, 20 Jul 2012 06:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIf1WMoH3VpQ for ; Fri, 20 Jul 2012 06:05:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 59B9E21F8652 for ; Fri, 20 Jul 2012 06:05:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A68E39E179 for ; Fri, 20 Jul 2012 15:06:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jN7AhPIWqex for ; Fri, 20 Jul 2012 15:06:42 +0200 (CEST) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C95A239E091 for ; Fri, 20 Jul 2012 15:06:42 +0200 (CEST) Message-ID: <500957ED.90807@alvestrand.no> Date: Fri, 20 Jul 2012 15:06:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> <5008F7B9.7020804@infosecurity.ch> In-Reply-To: <5008F7B9.7020804@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 13:05:49 -0000 On 07/20/2012 08:16 AM, Fabio Pietrosanti (naif) wrote: > On 7/19/12 10:40 PM, Bernard Aboba wrote: >> Self-signed certificates are only appropriate for a subset of scenarios. Do >> we expect IdP to be widely deployed in high security scenarios for >> government, financial or medical applications? I do not. >> >> Do we expect a call center to utilize IdP with a self-signed certificate? >> More likely is that they will utilize a certificate chaining to a trust >> anchor. > Until WebRTC does not employ an end-to-end authentication mechanism > (like ZRTP's SAS applied to DTLS-SRTP), WebRTC is not going to provide > end-to-end security. > > It's not a matter of considering just the encryption, but considering > the "trust model" . > > Current security definition of WebRTC does not support end-to-end security. The current security definition of WebRTC (with DTLS) provides fingerprints. If the application is able to verify those fingerprints, security is end to end; if it isn't - it isn't. One specification does not solve all problems. > > Fabio > > p.s. we have wrote tons of thread about it in past months explaining why > and how > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lists@infosecurity.ch Fri Jul 20 06:17:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE79221F860B for ; Fri, 20 Jul 2012 06:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI+uwJd4IUf9 for ; Fri, 20 Jul 2012 06:17:44 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D50521F85EA for ; Fri, 20 Jul 2012 06:17:43 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2569354wgb.13 for ; Fri, 20 Jul 2012 06:18:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=c2Bw49yUEE/wtd13xm3/7PRhtfnXDKlV28CXYHXdDV8=; b=NPZGy2DtH8d9tyjo/FLGGZjR5ZFgxnkWeu/E/+aYMcFKIS0GahOaWufRM3k0lvmjH7 cvqU3B3pUm86qKf18LgVk5tzeecsbx6UUmtg1NS90JblYEauSYrj4RC4uISwG14i6CtR K0FjETZO4sg3D5bLOLAqu3Drzy4IlL0KnS2nVgqhh9UneHRObKPSmlQurkBK//WAmjeT zsotYKRK0QvXb0rhtWwzYivjCwSpRgmpih8h2lYeuk1ZQyKvMZQhUpYkabtGZeGlnLFu 0045E9FDyv6Sfdw37NhODuoOhqeZS/KZXKM1/ZMmWYAub8KF4U0oHv9FHf36IMWX/027 pMMQ== Received: by 10.216.123.135 with SMTP id v7mr4036701weh.47.1342790319105; Fri, 20 Jul 2012 06:18:39 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id y5sm44646953wiw.9.2012.07.20.06.18.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jul 2012 06:18:38 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <50095AAC.7030104@infosecurity.ch> Date: Fri, 20 Jul 2012 15:18:36 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> <5008F7B9.7020804@infosecurity.ch> <500957ED.90807@alvestrand.no> In-Reply-To: <500957ED.90807@alvestrand.no> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnigwvNXSMLWgsGP5nUWIhIuuJeeds9LJjy/Wac1pRZNhfHGO6XokRPlF3ZVYhcMVZNdXRn Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 13:17:45 -0000 On 7/20/12 3:06 PM, Harald Alvestrand wrote: >> Current security definition of WebRTC does not support end-to-end >> security. > The current security definition of WebRTC (with DTLS) provides > fingerprints. > If the application is able to verify those fingerprints, security is end > to end; if it isn't - it isn't. The security specification already does specify how the fingerprint must be checked, against a third party system that must be trusted (unless there is some recent update i didn't still checked). The way the specification describe fingerprint must be checked, does not enforce end-to-end security but always rely on trusted third party, being IdP (identity providers). The only way to achieve end-to-end security is not to have any kind of trusted third party, as has been already discussed on http://www.ietf.org/mail-archive/web/rtcweb/current/msg04043.html . Until WebRTC security architecture specification does not clearly define a peer-to-peer fingerprint verification system that does not rely on trusted third party it cannot be considered to provide end-to-end security. Fabio From harald@alvestrand.no Fri Jul 20 06:27:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11D221F85A4 for ; Fri, 20 Jul 2012 06:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDVuEWkqPNus for ; Fri, 20 Jul 2012 06:27:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 39C6F21F8596 for ; Fri, 20 Jul 2012 06:27:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C84939E179 for ; Fri, 20 Jul 2012 15:27:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO2b2KoBy-5m for ; Fri, 20 Jul 2012 15:27:56 +0200 (CEST) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3AC0939E091 for ; Fri, 20 Jul 2012 15:27:56 +0200 (CEST) Message-ID: <50095CE7.6030202@alvestrand.no> Date: Fri, 20 Jul 2012 15:28:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> <5008F7B9.7020804@infosecurity.ch> <500957ED.90807@alvestrand.no> <50095AAC.7030104@infosecurity.ch> In-Reply-To: <50095AAC.7030104@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 13:27:02 -0000 On 07/20/2012 03:18 PM, Fabio Pietrosanti (naif) wrote: > On 7/20/12 3:06 PM, Harald Alvestrand wrote: >>> Current security definition of WebRTC does not support end-to-end >>> security. >> The current security definition of WebRTC (with DTLS) provides >> fingerprints. >> If the application is able to verify those fingerprints, security is end >> to end; if it isn't - it isn't. > The security specification already does specify how the fingerprint must > be checked, against a third party system that must be trusted (unless > there is some recent update i didn't still checked). > > The way the specification describe fingerprint must be checked, does not > enforce end-to-end security but always rely on trusted third party, > being IdP (identity providers). > > The only way to achieve end-to-end security is not to have any kind of > trusted third party, as has been already discussed on > http://www.ietf.org/mail-archive/web/rtcweb/current/msg04043.html . That link is your request to have SAS considered mandatory. I believe you got some support for that proposal, or at least some kind of availability of digest information that can be verified independently, but I do not believe that you got any support for having SAS be the one and only definition of "end to end security". Thus, you may get support for your real request, but not for the language you use to describe it. > > Until WebRTC security architecture specification does not clearly define > a peer-to-peer fingerprint verification system that does not rely on > trusted third party it cannot be considered to provide end-to-end security. > > Fabio > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Fri Jul 20 06:50:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9F521F85F0 for ; Fri, 20 Jul 2012 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.843 X-Spam-Level: X-Spam-Status: No, score=-102.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AZ158CXUDNW for ; Fri, 20 Jul 2012 06:50:12 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7558521F85EA for ; Fri, 20 Jul 2012 06:50:12 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3220121vcb.31 for ; Fri, 20 Jul 2012 06:51:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=7eFx1JeM3EDcUHz/qIbFizUtN1VpxiQP4PKK6EK7v5s=; b=PGgutAfZv8/c2ckneTqcPWXAf9w/EzBqMoOVfUmLsiz4wHxV9DZm81lMurYUod7RJg us/dBQEhm+ytOHN4GK7tjP7JBfAMnm7DIon9zQ+zugXO0GpRBh1WGk+CoiyUHJ+yH5Tg wb9jqNdp+NWeV+TvGDMjQ+ywICqXH/P6vrIYi7CNXnpVdBNC3yYyyTIdrliJ9IKlisuH KVqQwph/wO8aP9Xih1l4giIUcJzyZW7VCJoUJt4YAypl+nOOYb0bfkApLEwOIXxm0tyz 3x3cIBm82JCzRlRl9UekWxkMqVnZKAJfihZZeQaJvhRT7dAe7O/QsGsVkxKH29BIT9md hD0Q== Received: by 10.52.88.170 with SMTP id bh10mr3916046vdb.11.1342792268163; Fri, 20 Jul 2012 06:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 20 Jul 2012 06:50:28 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <50095CE7.6030202@alvestrand.no> References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> <5008F7B9.7020804@infosecurity.ch> <500957ED.90807@alvestrand.no> <50095AAC.7030104@infosecurity.ch> <50095CE7.6030202@alvestrand.no> From: Eric Rescorla Date: Fri, 20 Jul 2012 06:50:28 -0700 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl+p67FKT5mOHMDnuTq/sqYEvLLF8w3qUD4SqDiup/AXfPQyUWu6gNv7keukB+Q3tgBS8NA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 13:50:13 -0000 The draft currently states: * The "security characteristics" MUST include some mechanism to allow an out-of-band verification of the peer, such as a certificate fingerprint or an SAS. I'd be happy to have us specify a particular fingerprint algorithm (presumably SHA-256, potentially truncated) but I haven't seen any evidence that users savvy enough to inspect the fingerprint at all can't navigate more than one hash. For example, Chrome's SSL/TLS inspector currently displays MD5 and SHA-1. So I'm not sure something needs to be standardized here. -Ekr On Fri, Jul 20, 2012 at 6:28 AM, Harald Alvestrand wrote: > On 07/20/2012 03:18 PM, Fabio Pietrosanti (naif) wrote: >> >> On 7/20/12 3:06 PM, Harald Alvestrand wrote: >>>> >>>> Current security definition of WebRTC does not support end-to-end >>>> security. >>> >>> The current security definition of WebRTC (with DTLS) provides >>> fingerprints. >>> If the application is able to verify those fingerprints, security is end >>> to end; if it isn't - it isn't. >> >> The security specification already does specify how the fingerprint must >> be checked, against a third party system that must be trusted (unless >> there is some recent update i didn't still checked). >> >> The way the specification describe fingerprint must be checked, does not >> enforce end-to-end security but always rely on trusted third party, >> being IdP (identity providers). >> >> The only way to achieve end-to-end security is not to have any kind of >> trusted third party, as has been already discussed on >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04043.html . > > That link is your request to have SAS considered mandatory. > > I believe you got some support for that proposal, or at least some kind of > availability of digest information that can be verified independently, but I > do not believe that you got any support for having SAS be the one and only > definition of "end to end security". > > Thus, you may get support for your real request, but not for the language > you use to describe it. > >> >> Until WebRTC security architecture specification does not clearly define >> a peer-to-peer fingerprint verification system that does not rely on >> trusted third party it cannot be considered to provide end-to-end >> security. >> >> Fabio >> _______________________________________________ >> 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 richard.ejzak@alcatel-lucent.com Fri Jul 20 09:09:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61421F85A4 for ; Fri, 20 Jul 2012 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.641 X-Spam-Level: X-Spam-Status: No, score=-9.641 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0qvPr8Cko26 for ; Fri, 20 Jul 2012 09:09:33 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2B97321F85D3 for ; Fri, 20 Jul 2012 09:09:28 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6KGA1wK015830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 20 Jul 2012 18:10:22 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 20 Jul 2012 18:10:07 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.33]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 20 Jul 2012 12:10:04 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] data channel protocol comments and potential agenda topic Thread-Index: Ac1lyy6PQOhDXDGkSAC+0BA2iG8yWwAj6U+AAAoNErA= Date: Fri, 20 Jul 2012 16:10:03 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1770A52C@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> <5008EDD7.60801@alvestrand.no> In-Reply-To: <5008EDD7.60801@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F1770A52CUS70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 16:09:35 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F1770A52CUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see any conflict between our positions, Harald. You are arguing th= at we need a generic data transfer capability that can be used by any appli= cation for any purpose, which can be achieved by specifying raw data transf= er, and I fully support this. I am arguing that it would be advantageous t= o be able to have the option to specify an underlying protocol on a data ch= annel so that we can develop interoperable applications. These capabilitie= s are not mutually exclusive. An example might be MSRP. If we would like to use MSRP between endpoints t= hen we could specify that browsers need to support MSRP natively and specif= y a new API to access it. Or we could allow an application to send MSRP ov= er a data channel without impacting the browser. This would potentially al= low browsers running different communications applications to use MSRP in a= ddition to audio and video media for communication, even if other applicati= on specific uses of data channel are not interoperable. I'm not arguing that we should standardize MSRP over data channel - just th= at this approach gives us the potential to define interoperable data channe= l applications in the future. It would also be a good idea to reserve a range of ppid values for propriet= ary use. Then when two browsers are communicating with the same applicatio= n, the application can signal the purpose behind a new block of data with t= he choice of proprietary ppid value. An application might use one value to= signal gaming control information and another value to signal display info= rmation. This approach would save a typical application from exchanging si= gnaling just to set up channels so that it can begin to use them. --_000_03FBA798AC24E3498B74F47FD082A92F1770A52CUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t see any conflict between= our positions, Harald.  You are arguing that we need a generic data t= ransfer capability that can be used by any application for any purpose, which can be achieved by specifyi= ng raw data transfer, and I fully support this.  I am arguing that it = would be advantageous to be able to have the option to specify an underlyin= g protocol on a data channel so that we can develop interoperable applications.  These capabilities are no= t mutually exclusive.

 

An example might be MSRP.  If we = would like to use MSRP between endpoints then we could specify that browser= s need to support MSRP natively and specify a new API to access it.  Or we could allow an application= to send MSRP over a data channel without impacting the browser.  This= would potentially allow browsers running different communications applicat= ions to use MSRP in addition to audio and video media for communication, even if other application specific uses of = data channel are not interoperable.

 

I’m not arguing that we should s= tandardize MSRP over data channel – just that this approach gives us = the potential to define interoperable data channel applications in the future.

 

It would also be a good idea to reserv= e a range of ppid values for proprietary use.  Then when two browsers = are communicating with the same application, the application can signal the purpose behind a new bloc= k of data with the choice of proprietary ppid value.  An application m= ight use one value to signal gaming control information and another value t= o signal display information.  This approach would save a typical application from exchanging signaling just to set up = channels so that it can begin to use them.

 

--_000_03FBA798AC24E3498B74F47FD082A92F1770A52CUS70UWXCHMBA04z_-- From martin.thomson@gmail.com Fri Jul 20 09:39:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68C21F8555 for ; Fri, 20 Jul 2012 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip8FdMdmbnKP for ; Fri, 20 Jul 2012 09:39:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20D7D21F8554 for ; Fri, 20 Jul 2012 09:39:14 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5773227lbb.31 for ; Fri, 20 Jul 2012 09:40:10 -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=6HJ2DuriKTVQ/R7AEPD8VPUXXy/oGyLzgKNQ8cRspSw=; b=gpjlxTBwWaRc4gEL3D+16IYriKWPMMOsKiooNDyr0fUSNTv+ZF+UC33V86Ix7drhP1 s66fpv3nx1v9hJ8fH5GUqVwSY8aJekgEdF37UrD0bLahk4vnDqydtn1qTj+0PCpNiHmu 0aq9p/ha+QcXwDWZ/ytplDimbL5kXt+DQQwtlUNMWRKenooduSIMWB0zCOjthG0iHRPM oLxx1nownciS1qqA6JY6P4urGj9s6G47dnnInoy9PZPdTXHaO52zGLSD6kk+F76S7BTG USBDentaYn+/q47yb5JTCTUAFuVQh89IO78+RZqkTShaLfkg9/u7PRHjCxx3I4D3C1WW aMHg== MIME-Version: 1.0 Received: by 10.152.146.169 with SMTP id td9mr6948607lab.42.1342802410532; Fri, 20 Jul 2012 09:40:10 -0700 (PDT) Received: by 10.112.95.40 with HTTP; Fri, 20 Jul 2012 09:40:10 -0700 (PDT) In-Reply-To: <5007D9B4.6020008@alvestrand.no> References: <5007D9B4.6020008@alvestrand.no> Date: Fri, 20 Jul 2012 09:40:10 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] API requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 16:39:16 -0000 On 19 July 2012 02:56, Harald Alvestrand wrote: > I must admit to being quite confused by the actual requirements in the draft > - I have no idea what use case they're intending to enable, and thus I have > no idea why the authors have chosen MUST rather than SHOULD or MAY as the > requirement levels. The point was to describe the minimal set of information that needs to pass between application and browser in order to accomplish the tasks described in (draft-rtcweb-use-cases-...) using the protocols and security mechanisms described in (-rtp-usage and -security-*). This aims to be more specific than Section 10 of -rtp-usage and to cover the other features. It's a -00 draft. We acknowledge that the rationale is a little light (read: not there). > ICE-5 The application MUST be able to add STUN attributes to the > STUN messages that are sent for connectivity checks. > > What application does this enable? This would enable proprietary STUN extensions that include session identification, authorization, bandwidth negotiation, data transfer, and other purposes. Primarily, this is associated with the "connectivity check" made to a STUN server. > What are the security implications? I'm sure you can invent some if you think about it hard enough. As I understand it, the application is in complete control over the username fragment, so this adds no greater advantage to an application than is already present. This is just added flexibility that will enable greater interoperability. As long as the browser ensures that the STUN packet fits within the defined size limit, there are none. > MED-1 The application MUST be able to select the UDP flow that an > RTP stream uses. > > MED-2 The application MUST be able select the UDP flow that RTCP > for a given RTP stream uses. > > What application does this enable, compared to mechanisms that assign RTP > and RTCP to a given UDP flow and report the results back? This is another interoperability requirement. What you say is only true if both peers perform compatible allocations. You will note that by moving candidates between m= lines, JSEP already offers this capability. Assuming of course that the browsers implement that. > MED-7 The application MUST be able to specify the RTP packet type > that is used to identify codecs in RTP streams, both inbound > and outbound. > > Again, what application does this enable, compared to mechanisms that assign > a packet type and inform the application of which one was chosen? Same reason as above. >> In related news, Microsoft just joined the W3C Web Real-Time >> Communications Working Group. Once a few clerical issues are >> addressed, new W3C proposals that address these requirements will >> follow. > > Looking forward to seeing the proposals, and seeing your proposals for how > they can be pursued without impacting the progress of the present > specifications and implementations! I'm still working on this. Don't expect the impossible though. From dwing@cisco.com Fri Jul 20 10:29:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF2A21F85D2 for ; Fri, 20 Jul 2012 10:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGPr9DIwPlBU for ; Fri, 20 Jul 2012 10:29:09 -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 D628121F85D1 for ; Fri, 20 Jul 2012 10:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3672; q=dns/txt; s=iport; t=1342805405; x=1344015005; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=E+nnyeTHoW148Wg/z3tw5JQJ9s/RCvZmGHJPj46UMqE=; b=SATejClrOxthbb0nD2SH6E/OfnDTMBcggvU3+BmCqtA0ePP7WpC/+NVY /AQFNPCtja2irvvQe17w3KQ7LbKr0mq1L2prWRcNGvM6Fy8EWrNIQPLNv 8jip3cGn23KDo2neC0fwAPcZPTQU/q4LaaHqnjwtvOy4+tiRT3AK57ffX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFCUCVCrRDoG/2dsb2JhbAA8CaoWjy6BB4IgAQEBBAEBAQUKARcQNAsMAQMCCQ8CAQMBAQEnBxkOFQoDBggBAQQTCQIXh2oMnl+gJItOEQmGRgOITYUMlhCBZoJ/gTgHHA X-IronPort-AV: E=Sophos;i="4.77,623,1336348800"; d="scan'208";a="49956106" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Jul 2012 17:30:03 +0000 Received: from dwingWS (sjc-vpn4-1264.cisco.com [10.21.84.239]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6KHU3xd010131; Fri, 20 Jul 2012 17:30:03 GMT From: "Dan Wing" To: References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> <5008F7B9.7020804@infosecurity.ch> <500957ED.90807@alvestrand.no> <50095AAC.7030104@infosecurity.ch> <50095CE7.6030202@alvestrand.no> In-Reply-To: Date: Fri, 20 Jul 2012 10:30:03 -0700 Message-ID: <0ad001cd669d$4c5fae50$e51f0af0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1mfrye1ldynRh+RnCrVrbT1B9vCAAHhlaw Content-Language: en-us Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 17:29:09 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Friday, July 20, 2012 6:50 AM > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST > > The draft currently states: > > * The "security characteristics" MUST include some mechanism to > allow an out-of-band verification of the peer, such as a > certificate fingerprint or an SAS. > > I'd be happy to have us specify a particular fingerprint algorithm > (presumably > SHA-256, potentially truncated) but I haven't seen any evidence that > users savvy enough to inspect the fingerprint at all can't navigate > more > than one hash. For example, Chrome's SSL/TLS inspector currently > displays > MD5 and SHA-1. So I'm not sure something needs to be standardized here. Users are unreliable to do this. I would look at TLS key pinning or similar techniques. That is what ZRTP is doing to avoid speaking a SAS for every phone call. Again (for the group), DTLS-SRTP allows us to build identity validation such as key pinning or a SAS or third-party IdP, but SDESC does not allow us to build identity validation. -d > -Ekr > > > On Fri, Jul 20, 2012 at 6:28 AM, Harald Alvestrand > wrote: > > On 07/20/2012 03:18 PM, Fabio Pietrosanti (naif) wrote: > >> > >> On 7/20/12 3:06 PM, Harald Alvestrand wrote: > >>>> > >>>> Current security definition of WebRTC does not support end-to-end > >>>> security. > >>> > >>> The current security definition of WebRTC (with DTLS) provides > >>> fingerprints. > >>> If the application is able to verify those fingerprints, security > is end > >>> to end; if it isn't - it isn't. > >> > >> The security specification already does specify how the fingerprint > must > >> be checked, against a third party system that must be trusted > (unless > >> there is some recent update i didn't still checked). > >> > >> The way the specification describe fingerprint must be checked, does > not > >> enforce end-to-end security but always rely on trusted third party, > >> being IdP (identity providers). > >> > >> The only way to achieve end-to-end security is not to have any kind > of > >> trusted third party, as has been already discussed on > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04043.html . > > > > That link is your request to have SAS considered mandatory. > > > > I believe you got some support for that proposal, or at least some > kind of > > availability of digest information that can be verified > independently, but I > > do not believe that you got any support for having SAS be the one and > only > > definition of "end to end security". > > > > Thus, you may get support for your real request, but not for the > language > > you use to describe it. > > > >> > >> Until WebRTC security architecture specification does not clearly > define > >> a peer-to-peer fingerprint verification system that does not rely on > >> trusted third party it cannot be considered to provide end-to-end > >> security. > >> > >> Fabio > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From alan.b.johnston@gmail.com Fri Jul 20 11:19:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49C711E80CB for ; Fri, 20 Jul 2012 11:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfqqpsFqzOI5 for ; Fri, 20 Jul 2012 11:19:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E015211E80D5 for ; Fri, 20 Jul 2012 11:19:48 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5882930lbb.31 for ; Fri, 20 Jul 2012 11:20:42 -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=HK6nT6HFxqvTYVlSnbGSfTBnDAmD/xACA91mBGpae10=; b=UWce+nk1sijh38QKlewhE0tzPHp+2uvIc9kbDk/3P0ZWNQUQCRliOMjhjPoHfefMZW ZzyyPLbhjtTtps1pKZZyOgJgJz9HMSqEtJY1EtltHdmCadaF1NPOVuvwBP2hsIol8UiR VWVFnZtNfk2XbTivxDIBYevpAsk7XQN/+wp3qTgRCRPg/ZwdLDl8ifWKYHJo94LLnwP2 Zx8EYfEjicvsapyfcb5AGz1WJWJFBcKAZy7E55Ta3utwRhirGr3mbeuEjYLJXQFOJAr0 TbehxHjDthycGUD+QQl7Xf2vW0p0K2XMeqlMCnrhLnQJD4LfJWujysXYtJaawQFJ3QCX B1aw== MIME-Version: 1.0 Received: by 10.152.148.1 with SMTP id to1mr7255160lab.34.1342808442355; Fri, 20 Jul 2012 11:20:42 -0700 (PDT) Received: by 10.112.133.130 with HTTP; Fri, 20 Jul 2012 11:20:42 -0700 (PDT) In-Reply-To: References: <201207190742.q6J7glf6008744@vivaldi29.register.it> <500834FE.5040809@alcatel-lucent.com> <500835E1.2070502@infosecurity.ch> <50084717.7060301@alcatel-lucent.com> <5008F7B9.7020804@infosecurity.ch> <500957ED.90807@alvestrand.no> <50095AAC.7030104@infosecurity.ch> <50095CE7.6030202@alvestrand.no> Date: Fri, 20 Jul 2012 13:20:42 -0500 Message-ID: From: Alan Johnston To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Jul 2012 18:19:50 -0000 If we want to have usable end-to-end or human-to-human authentication, then just displaying a 128 bit fingerprint isn't going to work. ZRTP ( RFC 6189) uses a hash commitment to reduce this to an 8 bit fingerprint, and has human friendly ways to exchange this, such as base 256: http://en.wikipedia.org/wiki/PGP_word_list There have been claims over the years that DTLS-SRTP could do this as well, but I have never seen a specification or a description of how would be done. - Alan - On Fri, Jul 20, 2012 at 8:50 AM, Eric Rescorla wrote: > The draft currently states: > > * The "security characteristics" MUST include some mechanism to > allow an out-of-band verification of the peer, such as a > certificate fingerprint or an SAS. > > I'd be happy to have us specify a particular fingerprint algorithm (presumably > SHA-256, potentially truncated) but I haven't seen any evidence that > users savvy enough to inspect the fingerprint at all can't navigate more > than one hash. For example, Chrome's SSL/TLS inspector currently displays > MD5 and SHA-1. So I'm not sure something needs to be standardized here. > > -Ekr > > > On Fri, Jul 20, 2012 at 6:28 AM, Harald Alvestrand wrote: >> On 07/20/2012 03:18 PM, Fabio Pietrosanti (naif) wrote: >>> >>> On 7/20/12 3:06 PM, Harald Alvestrand wrote: >>>>> >>>>> Current security definition of WebRTC does not support end-to-end >>>>> security. >>>> >>>> The current security definition of WebRTC (with DTLS) provides >>>> fingerprints. >>>> If the application is able to verify those fingerprints, security is end >>>> to end; if it isn't - it isn't. >>> >>> The security specification already does specify how the fingerprint must >>> be checked, against a third party system that must be trusted (unless >>> there is some recent update i didn't still checked). >>> >>> The way the specification describe fingerprint must be checked, does not >>> enforce end-to-end security but always rely on trusted third party, >>> being IdP (identity providers). >>> >>> The only way to achieve end-to-end security is not to have any kind of >>> trusted third party, as has been already discussed on >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04043.html . >> >> That link is your request to have SAS considered mandatory. >> >> I believe you got some support for that proposal, or at least some kind of >> availability of digest information that can be verified independently, but I >> do not believe that you got any support for having SAS be the one and only >> definition of "end to end security". >> >> Thus, you may get support for your real request, but not for the language >> you use to describe it. >> >>> >>> Until WebRTC security architecture specification does not clearly define >>> a peer-to-peer fingerprint verification system that does not rely on >>> trusted third party it cannot be considered to provide end-to-end >>> security. >>> >>> Fabio >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Sat Jul 21 05:02:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB88821F865C for ; Sat, 21 Jul 2012 05:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HBCJWryvOIA for ; Sat, 21 Jul 2012 05:02:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C94FB21F864B for ; Sat, 21 Jul 2012 05:02:10 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-51-500a9a7c81cd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DB.37.15286.C7A9A005; Sat, 21 Jul 2012 14:03:08 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Sat, 21 Jul 2012 14:03:08 +0200 Message-ID: <500A9A7B.8050400@ericsson.com> Date: Sat, 21 Jul 2012 14:03:07 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+JvrW7NLK4AgxPPlC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvo5a1kLFrJVnF5+jb2BsZu1i5GTQ0LAROLG9kssELaYxIV7 69m6GLk4hAROMUo827+KGcJZzihx48hONpAqXgFtifMH34J1swioSnzpv80IYrMJ2Eis7Z7C BGKLCoRIrPk2hRGiXlDi5MwnYBtEBIQltr7qBasRFgiU2H32GTOILSQQI/F67hOwek6BWIlX H9qBbA4OZgF7iQdby0DCzALyEs1bZ0OV60q8e32PdQKjwCwkG2YhdMxC0rGAkXkVo3BuYmZO ermRXmpRZnJxcX6eXnHqJkZg8B3c8lt1B+OdcyKHGKU5WJTEea237vEXEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwCjxabaI+fLkQ8vPPXENVBR4dITvq8HXFT5q+0WTBX7sSjtlV/BY2D/Z nG95/pZj+f8tkp69XfCqWXL3lMSzbFPVPkepyLYoVFVMOTa7y//Yfb0d5Y+sHr4O9n4Uw2b0 98bzAG0u79Pq09+bnk8QO7rthNSxTZrPp082uLOxbFvur5fiv9SWcm1QYinOSDTUYi4qTgQA LxanRAwCAAA= Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2012 12:02:11 -0000 On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote: ... > > Why don’t we instead specify the API to allow the application to select > the SCTP transmission characteristics (including stream id, ppid, > ordered, reliable, etc.) needed per data block to be transmitted. > Alternately, the API could specify and then allow changes to these > characteristics for a channel to influence the SCTP protocol options > selected without initiating a data channel protocol negotiation or > requiring release of the channel. The current API proposal is aligned to the WebSocket API. This API is state-of-art for web developers, is gaining momentum, and designing something very different would be a mistake IMO. Anyway, the API discussion and design belongs in the webrtc WG. Stefan From stefan.lk.hakansson@ericsson.com Sat Jul 21 05:24:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CC821F859F for ; Sat, 21 Jul 2012 05:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds9oYnSpym5F for ; Sat, 21 Jul 2012 05:24:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 43BD721F8594 for ; Sat, 21 Jul 2012 05:24:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-a8-500a9fc87ce5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E0.6C.07365.8CF9A005; Sat, 21 Jul 2012 14:25:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Sat, 21 Jul 2012 14:25:44 +0200 Message-ID: <500A9FC7.2000802@ericsson.com> Date: Sat, 21 Jul 2012 14:25:43 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5008EF08.6080803@alvestrand.no> In-Reply-To: <5008EF08.6080803@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre7J+VwBBgcn8lms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBkXX7IWXOKr+HtzP2sDYxNPFyMnh4SAicTrnzvYIWwxiQv3 1rN1MXJxCAmcYpTYtGMnI4SznFHi0eITLCBVvALaEueWPASzWQRUJWb+/wvWzSZgI7G2ewoT iC0qECKx5tsURoh6QYmTM5+A1YsICEtsfdULVMPBISwQJPH2vQBIWEigUGL/yVvMIDangK7E 8zePWEFsZgFbiQtzrrNA2PISzVtnM0PU60q8e32PdQKjwCwkG2YhaZmFpGUBI/MqRuHcxMyc 9HJDvdSizOTi4vw8veLUTYzA8Du45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwNiS+k/6x7nwzTb14s4sQY17PSpZprqcSA4UT7MvWPow9tZpx8cWTCyL hWI9F7l/iOO6wM986Mu2bTv8e6cfL9u4QPO3zeKIo/1HDV57f39/ddWRqJoPmxOup9yqzZ6+ Zf+dlM2Wwo7ZHGJ9TkvS5ygK1adrZe0NmP0rsXnii2czF+2XWZNtkq/EUpyRaKjFXFScCAA2 TJ8xDQIAAA== Subject: Re: [rtcweb] Terminate or Reject streams by setting port to zero in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Jul 2012 12:24:48 -0000 On 07/20/2012 07:39 AM, Harald Alvestrand wrote: > On 07/17/2012 07:35 AM, José Luis Millán wrote: >> Hi, >> >> Offer/Answer Model with Session Description Protocol states that a >> stream can be terminated or rejected by setting the port to zero in >> the Offer/Answer SDP respectively. >> >> How can this be achieved with PeerConnection? > Terminating a stream: Remove all references to the stream in the SDP > "msid" attributes. > > draft-alvestrand-rtcweb-msid-02 section 4. Agree to that part. > > Rejecting a stream: draft-westerlund-avtext-rtp-stream-pause-02 suggests > one way to do this (I have not reviewed it). I don't think that draft covers rejecting a stream. It is more related to pause/resume (which correlates to enable/disable and mute/unmute in API terminology). Which leads to the question: If we use a solution like described in draft-alvestrand-rtcweb-msid-02 to signal the mapping between MediaStream's and MediaStreamTracks and ssrcs (RTP) (which makes sense to me), how should rejection be signaled? And should the receiver be able to accept certain added ssrc's in a new offer while rejecting others, or should the entire offer be rejected (and the presumable the current state of the session be maintained)? In 3264 it is said "The means for rejecting an offer are dependent on the higher layer protocol.", but that does not seem appropriate in this case. > > Note: An m-line (the entity in SDP that carries the port number) does > NOT correspond to a WebRTC MediaStream. > >> >> Thanks in advance. >> _______________________________________________ >> 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 richard.ejzak@alcatel-lucent.com Sun Jul 22 08:07:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96421F8666 for ; Sun, 22 Jul 2012 08:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.763 X-Spam-Level: X-Spam-Status: No, score=-9.763 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2ZwaebVX88r for ; Sun, 22 Jul 2012 08:07:27 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10921F8659 for ; Sun, 22 Jul 2012 08:07:26 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6MF8Rdv015628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 22 Jul 2012 17:08:27 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 22 Jul 2012 17:08:27 +0200 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.16]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Sun, 22 Jul 2012 11:08:25 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] data channel protocol comments and potential agenda topic Thread-Index: Ac1lyy6PQOhDXDGkSAC+0BA2iG8yWwBjyKaAAC96dJA= Date: Sun, 22 Jul 2012 15:08:24 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1771C06D@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> <500A9A7B.8050400@ericsson.com> In-Reply-To: <500A9A7B.8050400@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 15:07:28 -0000 I grant you that the API discussion belongs in W3C. I don't propose to ign= ore the websocket API, but surely some adaptations could be considered (in = W3C) if they have potential to bring advantages. But several other points I made are unrelated to the design of the API and = do belong in rtcweb. In particular, it should be possible to create a data= channel (once the SCTP association is established) without the use of a da= ta channel control protocol and without requiring it to be pre-specified in= SDP. This is my main suggestion. My next suggestion is to allow the appl= ication to specify the ppid value (with raw ascii or binary as options) ass= ociated with a data channel (or for each data chunk transmitted on a data c= hannel) for the reasons I described earlier. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Stefan Hakansson LK > Sent: Saturday, July 21, 2012 7:03 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] data channel protocol comments and potential agenda > topic >=20 > On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote: > ... > > > > Why don't we instead specify the API to allow the application to select > > the SCTP transmission characteristics (including stream id, ppid, > > ordered, reliable, etc.) needed per data block to be transmitted. > > Alternately, the API could specify and then allow changes to these > > characteristics for a channel to influence the SCTP protocol options > > selected without initiating a data channel protocol negotiation or > > requiring release of the channel. >=20 > The current API proposal is aligned to the WebSocket API. This API is > state-of-art for web developers, is gaining momentum, and designing > something very different would be a mistake IMO. Anyway, the API > discussion and design belongs in the webrtc WG. >=20 > Stefan >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Sun Jul 22 09:14:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D2221F8663 for ; Sun, 22 Jul 2012 09:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h86NSxFpegyf for ; Sun, 22 Jul 2012 09:14:06 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3615021F8648 for ; Sun, 22 Jul 2012 09:14:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-5b-500c270a74c0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E5.A5.03067.A072C005; Sun, 22 Jul 2012 18:15:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Sun, 22 Jul 2012 18:15:06 +0200 Message-ID: <500C2708.6040704@ericsson.com> Date: Sun, 22 Jul 2012 18:15:04 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> <500A9A7B.8050400@ericsson.com> <03FBA798AC24E3498B74F47FD082A92F1771C06D@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1771C06D@US70TWXCHMBA12.zam.alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDJMWRmVeSWpSXmKPExsUyM+JvrS6XOk+Awd+NhhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr43zPM9aCWcIVMw5cYWtgfM3fxcjJISFgIvGhbRk7hC0mceHe erYuRi4OIYFTjBJtN9axQDjLGSUa2n6AVfEKaEvcefiAGcRmEVCVWHn8JpjNJmAjsbZ7ChOI LSoQIrHm2xRGiHpBiZMzn7CA2CICwhJbX/WC1QgLBErsPvuMGWLBWUaJm/MusoIkOAViJT61 3wArYhawlbgw5zoLhC0vsf3tHLBlQgK6Eu9e32OdwCgwC8mOWUhaZiFpWcDIvIpRODcxMye9 3FwvtSgzubg4P0+vOHUTIzAED275bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwsq3riRBd4GVktkL34J1j8/bKtLQ2fXaJ+ho2+UHyDc4HEaExazIX9E2p LXOfcmpfQsf5N6q5cjdyf78J2cbb9O966q35OxVmfd7AEtG3/uun1oRlZye9lr2p3xSQYWF8 mknnX+iSR08ZIpeFzhVoCdQu7nG1XuAbLOj5wEpHi0G3ytF2Z8ROJZbijERDLeai4kQAx5V/ Xg8CAAA= Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 16:14:08 -0000 On 07/22/2012 05:08 PM, Ejzak, Richard P (Richard) wrote: > I grant you that the API discussion belongs in W3C. I don't propose > to ignore the websocket API, but surely some adaptations could be > considered (in W3C) if they have potential to bring advantages. > > But several other points I made are unrelated to the design of the > API and do belong in rtcweb. In particular, it should be possible to > create a data channel (once the SCTP association is established) > without the use of a data channel control protocol and without > requiring it to be pre-specified in SDP. This is my main suggestion. I think, if doable, that is a good idea. However, I think the authors determined that the data channel control protocol was needed (but Randell/Salvatore/Michael know the details). > My next suggestion is to allow the application to specify the ppid > value (with raw ascii or binary as options) associated with a data > channel (or for each data chunk transmitted on a data channel) for > the reasons I described earlier. > >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >> Sent: Saturday, July 21, 2012 7:03 AM To: rtcweb@ietf.org Subject: >> Re: [rtcweb] data channel protocol comments and potential agenda >> topic >> >> On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote: ... >>> >>> Why don't we instead specify the API to allow the application to >>> select the SCTP transmission characteristics (including stream >>> id, ppid, ordered, reliable, etc.) needed per data block to be >>> transmitted. Alternately, the API could specify and then allow >>> changes to these characteristics for a channel to influence the >>> SCTP protocol options selected without initiating a data channel >>> protocol negotiation or requiring release of the channel. >> >> The current API proposal is aligned to the WebSocket API. This API >> is state-of-art for web developers, is gaining momentum, and >> designing something very different would be a mistake IMO. Anyway, >> the API discussion and design belongs in the webrtc WG. >> >> Stefan >> >> _______________________________________________ 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 Michael.Tuexen@lurchi.franken.de Sun Jul 22 12:53:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641CB21F8665 for ; Sun, 22 Jul 2012 12:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB0fCVZoPnBX for ; Sun, 22 Jul 2012 12:53:46 -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 0E27321F8615 for ; Sun, 22 Jul 2012 12:53:46 -0700 (PDT) Received: from [192.168.1.200] (p5481B8CA.dip.t-dialin.net [84.129.184.202]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7ECE51C0C0BCE; Sun, 22 Jul 2012 21:54:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <500C2708.6040704@ericsson.com> Date: Sun, 22 Jul 2012 21:54:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82DE409C-7669-49B9-AC2C-8834F626C39A@lurchi.franken.de> References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> <500A9A7B.8050400@ericsson.com> <03FBA798AC24E3498B74F47FD082A92F1771C06D@US70TWXCHMBA12.zam.alcatel-lucent.com> <500C2708.6040704@ericsson.com> To: Stefan Hakansson LK X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 19:53:47 -0000 On Jul 22, 2012, at 6:15 PM, Stefan Hakansson LK wrote: > On 07/22/2012 05:08 PM, Ejzak, Richard P (Richard) wrote: >> I grant you that the API discussion belongs in W3C. I don't propose >> to ignore the websocket API, but surely some adaptations could be >> considered (in W3C) if they have potential to bring advantages. >>=20 >> But several other points I made are unrelated to the design of the >> API and do belong in rtcweb. In particular, it should be possible to >> create a data channel (once the SCTP association is established) >> without the use of a data channel control protocol and without >> requiring it to be pre-specified in SDP. This is my main suggestion. >=20 > I think, if doable, that is a good idea. However, I think the authors = determined that the data channel control protocol was needed (but = Randell/Salvatore/Michael know the details). The data channel protocol is required, because: * a channel is bi-directional and we need a mechanism to handle = collisions. * a channel has symmetric properties (like partial reliability policy, partial reliability parameter, priority, ordered/unordered. These need to be communicated. If channels are unidirectional, things get much simpler... Please note, that the data channel protocol is not that complex (it is basically a three-way handshake), and it is not required that the initiator delays sending user messages until the handshake is completed. You can actually send the first user message right after the first message of the handshake. They could even get bundled on the wire. However, this requires that the JS API allow this and I think the W3C voted against this. >=20 >> My next suggestion is to allow the application to specify the ppid >> value (with raw ascii or binary as options) associated with a data >> channel (or for each data chunk transmitted on a data channel) for >> the reasons I described earlier. I'm not sure if I understand the suggestion completely, but it sounds like proving most of the send/recv API from the SCTP socket API. But again: This is an API question and needs to be handled by W3C. Best regards Michael >=20 >>=20 >>> -----Original Message----- From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >>> Sent: Saturday, July 21, 2012 7:03 AM To: rtcweb@ietf.org Subject: >>> Re: [rtcweb] data channel protocol comments and potential agenda >>> topic >>>=20 >>> On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote: ... >>>>=20 >>>> Why don't we instead specify the API to allow the application to >>>> select the SCTP transmission characteristics (including stream >>>> id, ppid, ordered, reliable, etc.) needed per data block to be >>>> transmitted. Alternately, the API could specify and then allow >>>> changes to these characteristics for a channel to influence the >>>> SCTP protocol options selected without initiating a data channel >>>> protocol negotiation or requiring release of the channel. >>>=20 >>> The current API proposal is aligned to the WebSocket API. This API >>> is state-of-art for web developers, is gaining momentum, and >>> designing something very different would be a mistake IMO. Anyway, >>> the API discussion and design belongs in the webrtc WG. >>>=20 >>> Stefan >>>=20 >>> _______________________________________________ rtcweb mailing >>> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ rtcweb mailing list >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From randell-ietf@jesup.org Sun Jul 22 23:53:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6286121F84A0 for ; Sun, 22 Jul 2012 23:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKPtIJ9TjfCI for ; Sun, 22 Jul 2012 23:53:19 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9724F21F849D for ; Sun, 22 Jul 2012 23:53:16 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1StCW3-0001sN-0D for rtcweb@ietf.org; Mon, 23 Jul 2012 01:53:15 -0500 Message-ID: <500CF488.1070306@jesup.org> Date: Mon, 23 Jul 2012 02:51:52 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> <500A9A7B.8050400@ericsson.com> <03FBA798AC24E3498B74F47FD082A92F1771C06D@US70TWXCHMBA12.zam.alcatel-lucent.com> <500C2708.6040704@ericsson.com> <82DE409C-7669-49B9-AC2C-8834F626C39A@lurchi.franken.de> In-Reply-To: <82DE409C-7669-49B9-AC2C-8834F626C39A@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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 06:53:20 -0000 On 7/22/2012 3:54 PM, Michael Tuexen wrote: > On Jul 22, 2012, at 6:15 PM, Stefan Hakansson LK wrote: > >> On 07/22/2012 05:08 PM, Ejzak, Richard P (Richard) wrote: >>> I grant you that the API discussion belongs in W3C. I don't propose >>> to ignore the websocket API, but surely some adaptations could be >>> considered (in W3C) if they have potential to bring advantages. >>> >>> But several other points I made are unrelated to the design of the >>> API and do belong in rtcweb. In particular, it should be possible to >>> create a data channel (once the SCTP association is established) >>> without the use of a data channel control protocol and without >>> requiring it to be pre-specified in SDP. This is my main suggestion. >> I think, if doable, that is a good idea. However, I think the authors determined that the data channel control protocol was needed (but Randell/Salvatore/Michael know the details). > The data channel protocol is required, because: > * a channel is bi-directional and we need a mechanism to handle collisions. > * a channel has symmetric properties (like partial reliability > policy, partial reliability parameter, priority, ordered/unordered. > These need to be communicated. > If channels are unidirectional, things get much simpler... Correct. My initial proposal was a much thinner layer around unidirectional SCTP streams, but people clearly preferred bidirectional channels, and in particular ones that echo the API (at the W3 level) of WebSockets, and I see the appeal and usefulness of that, including the "wait until onopen" characteristic - it makes it easy to substitute DataChannels for WebSockets and vice-versa (so long as the DataChannel doesn't *need* unreliability, and can function with a reliable channel). It's an API that Web authors are comfortable with. > Please note, that the data channel protocol is not that complex > (it is basically a three-way handshake), and it is not required > that the initiator delays sending user messages until the > handshake is completed. You can actually send the first user message > right after the first message of the handshake. They could even > get bundled on the wire. However, this requires that the JS API > allow this and I think the W3C voted against this. Correct. The protocol is *very* simple. I'll note that my current draft indicates signaling for DataChannels that would at least be extendable (at the IETF/SDP level) to allowing other/alternate SCTP associations on the same DTLS channel, running other protocols, though for W3 WebRTC there would be a single one running the DataChannel protocol. -- Randell Jesup randell-ietf@jesup.org From domenico.colella@ctiplanet.it Mon Jul 23 00:15:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8844311E8080 for ; Mon, 23 Jul 2012 00:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_72=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy2wItTRnv3D for ; Mon, 23 Jul 2012 00:15:48 -0700 (PDT) Received: from hostingsmtp.register.it (hostingsmtp04.register.it [81.88.50.245]) by ietfa.amsl.com (Postfix) with ESMTP id D8C3A21F8532 for ; Mon, 23 Jul 2012 00:15:46 -0700 (PDT) Received: (qmail 3574 invoked from network); 23 Jul 2012 07:15:44 -0000 Received: from unknown (HELO localhost) by hostingsmtp.register.it with ESMTP; 23 Jul 2012 07:15:44 -0000 MIME-Version: 1.0 X-Mailer: AtMail PHP 5.1 Message-ID: <1278.1343027744@ctiplanet.it> X-RID: dDsndCNuJSjsO3RjQCUoKCMoK2MnK2M7biNtK2Q=|dDsndCNuJSjsO3Rj|+eBeJ+Bd4CcsXeAnPT3g|T1JQTElBTUJFVw== To: Content-Type: text/plain; charset="utf-8" X-Origin: 188.135.131.216 Date: Mon, 23 Jul 2012 09:15:44 +0200 From: domenico.colella@ctiplanet.it Content-Transfer-Encoding: quoted-printable Cc: daniele.filippi@ctiplanet.it Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: domenico.colella@ctiplanet.it List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 07:15:49 -0000 Help! I'm getting confused: last JSEP draft (http://tools.ietf.org/html/dra= ft-ietf-rtcweb-jsep-01#section-5.2) states a list of SDP=20 parameter that can be controlled by "signaling" application. Among the othe= rs, the following attribute dealing with security are=20 present: - remove or reorder SRTP crypto-suites (a=3Dcrypto) - change SRTP parameters or keys (a=3Dcrypto) What does it mean ? SDES MUST be supported if the "signaling" application deals with it and thr= ough JSEP API sets appropriate keys ?=20 SDES MAY be supported as an "out of the box" security feature (i.e. "signal= ing" application does not care about RTP security and just=20 proxies SDP)? Thanks, Domenico On Fri 20/07/12 00:20 , 'Dan Wing' sent: > > -----Original Message----- > > From: Roman Shpount [roman@telur > ix.com]> Sent: Thursday, July 19, 2012 1:19 PM > > To: Dan Wing > > Cc: Domenico Colella; rtcweb@ietf.o > rg;=20 > daniele.filippi@ctiplanet.it> Subject: Re: [rtcweb] Security Architecture= : SDES > support is a MUST>=20 > >=20 > > On Thu, Jul 19, 2012 at 2:03 PM, Dan Wing dwing@cisco.c > om> wrote:>=20 > >=20 > >=20 > > As I explained at IETF83 in Paris at the RTCWEB, > interworking> between DTLS-SRTP keying and SDESC keying can be done > without> expensive CPU operations. Reference > > http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pd > f> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt>=20 > >=20 > >=20 > >=20 > > Even though I understand how you can bridge DTLS-SRTP > with SRTP-EKV> without re-encryption, I do not think it is possible to > bridge SDES-> SRTP with DTLS-SRTP the same way. >=20 > Short answer: you are right, the WEBRTC network needs DTLS-SRTP=20 > and EKT. >=20 >=20 > Without EKT, it is possible to interwork in one direction without re-keyi= ng > each SRTP packet, specifically the packets going from the DTLS-SRTP > network to the SDESC network can be forwarded without re-keying.=20 > However,in the the other direction (from SDESC network to DTLS-SRTP netwo= rk), > thoseSRTP packets would need to be rekeyed. This is depicted in slide > 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pd > fwhere the media gateway is on fire (it is doing lots of CPU processing > to rekey those SRTP packets in the 'red' direction). >=20 >=20 > To avoid that rekeying in that direction, we add EKT on the DTLS-SRTP > network. With EKT, there is no longer a need to rekey SRTP in either > direction. This is depicted in slide 33 of the same presentation as > above. >=20 > EKT has other advantages for group video conferencing, which allow > video switching devices to avoid re-keying -- which reduces costs > (and saves energy, everybody is about saving energy!). It was those > advantages which led to the design of EKT in 2006 as=20 > draft-mcgrew-srtp-ekt-00, and the implementation in Cisco's=20 > telepresence systems. >=20 > > Bridging DTLS-SRTP with SRTP-EKV is > > completely useless for legacy interop since old > equipment is more> likely to support DTLS-SRTP then EKV, which is not eve= n > standardized> yet. >=20 > The majority of legacy systems seem to use SDESC keying, not=20 > DTLS-SRTP keying. And we don't need to change those legacy systems=20 > for this interworking. >=20 > There were no DTLS-SRTP implementations brought to SIPit 29, >=20 > https://www.sipit.net/SIPit29_summary, and 80% > that had SRTP supportused SDESC keying. Assuming that SIPit is a more-or= -less accurate=20 > representation of the market, the 'legacy' market uses SDESC keying > if it supports SRTP at all. >=20 > Of course, there is also a lot of 'legacy' equipment only supports > RTP. That is yet another reason for an interworking gateway in=20 > front of that RTP-only equipment. >=20 > > This being said, I am strongly against supporting > SDES-SRTP. Re-> encoding is cheap and you can do nearly 10GB/s of AES > encoding on a> fairly modest modern server. Having more protocols to > test and support> is a much higher cost. >=20 > Some objected to that cost, and after Magnus and Jonathan Lennox > suggested EKT be changed slightly to allow each packet to be self- > describing, we now have a very efficient way to interwork the > SRTP packets. >=20 > -d >=20 >=20 >=20 >=20 >=20 From richard.ejzak@alcatel-lucent.com Mon Jul 23 06:16:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55F21F86C2 for ; Mon, 23 Jul 2012 06:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.844 X-Spam-Level: X-Spam-Status: No, score=-9.844 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKWH8iAs+Yz1 for ; Mon, 23 Jul 2012 06:16:57 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id AC66121F8699 for ; Mon, 23 Jul 2012 06:16:55 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6NDDPGF006111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 23 Jul 2012 15:16:53 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 23 Jul 2012 15:16:18 +0200 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.16]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 23 Jul 2012 09:16:16 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] data channel protocol comments and potential agenda topic Thread-Index: AQHNaJ/kd4zo5CuRTk+Se+350bJd3Jc21oSA Date: Mon, 23 Jul 2012 13:16:14 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1771E0E7@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> <500A9A7B.8050400@ericsson.com> <03FBA798AC24E3498B74F47FD082A92F1771C06D@US70TWXCHMBA12.zam.alcatel-lucent.com> <500C2708.6040704@ericsson.com> <82DE409C-7669-49B9-AC2C-8834F626C39A@lurchi.franken.de> <500CF488.1070306@jesup.org> In-Reply-To: <500CF488.1070306@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 13:16:57 -0000 On July 23, Randell Jesup wrote: > Correct. The protocol is *very* simple. I'll note that my current > draft indicates signaling for DataChannels that would at least be > extendable (at the IETF/SDP level) to allowing other/alternate SCTP > associations on the same DTLS channel, running other protocols, though > for W3 WebRTC there would be a single one running the DataChannel protoco= l. While this may be true from a protocol perspective, it would still require = a new API to access other protocols, so they are effectively unavailable to= JS. From martin.thomson@gmail.com Mon Jul 23 11:57:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B620F11E80CF for ; Mon, 23 Jul 2012 11:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.926 X-Spam-Level: X-Spam-Status: No, score=-3.926 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVYvgA6LhQ9i for ; Mon, 23 Jul 2012 11:57:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E348011E8093 for ; Mon, 23 Jul 2012 11:57:21 -0700 (PDT) Received: by lagv3 with SMTP id v3so205094lag.31 for ; Mon, 23 Jul 2012 11:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ui0bBcBUxLxJKJNxxVlyAGU8MlxbQXvIoYynZ7EQ3Ks=; b=UCl82NQ+7dqLpH82o8Um1N5EZf7auvvz1tFYvrroIlt/3If5C4bNKLYKnF7cViGb+0 7lziaGmJ6mz/L39HSkXqUX1JlGfa4YagebubKVsSk+2Ke+3CNU2IvwIzgeRYE7tW+F25 YxhgUhnY6edmy3ELU/E0ltnmRjlCdyzEnGUPYWcCcMpab1DlcHALlAnB/qYhaCA7OdzJ JvQ9HIbLmyljGQd5cIKzm0mGZDzzdoxy8BCfueGy7DJA+LWntdaiZSPTs13b3Np3MEZ8 WfztrXdYfxoIwB0qGaO3xDeMD9mX5vlSQ1kypY7uXBBY1+h2beHzLlPdFNuqTaJhRkHl AFvQ== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr18029601lab.51.1343069840879; Mon, 23 Jul 2012 11:57:20 -0700 (PDT) Received: by 10.112.95.40 with HTTP; Mon, 23 Jul 2012 11:57:20 -0700 (PDT) In-Reply-To: <500A9FC7.2000802@ericsson.com> References: <5008EF08.6080803@alvestrand.no> <500A9FC7.2000802@ericsson.com> Date: Mon, 23 Jul 2012 11:57:20 -0700 Message-ID: From: Martin Thomson To: Stefan Hakansson LK Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Terminate or Reject streams by setting port to zero in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 18:57:22 -0000 On 21 July 2012 05:25, Stefan Hakansson LK wrote: > In 3264 it is said "The means for rejecting an offer are dependent on the > higher layer protocol.", but that does not seem appropriate in this case. Doesn't that mean that you need a way to reject an offer? Imagine that you call createOffer and that is incompatible with the state on the other peer in some way. Given that you have already setLocalDescription, what do you do to back out an offer that has been rejected? It seems that the only action available is to create another offer. --Martin From bo.burman@ericsson.com Tue Jul 24 02:42:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1A21F8643 for ; Tue, 24 Jul 2012 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiEZFj9sdG6l for ; Tue, 24 Jul 2012 02:42:19 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD2D21F864B for ; Tue, 24 Jul 2012 02:42:19 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-86-500e6dfaa14b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 38.7C.03067.AFD6E005; Tue, 24 Jul 2012 11:42:18 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.109]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 24 Jul 2012 11:42:13 +0200 From: Bo Burman To: "rtcweb@ietf.org" Date: Tue, 24 Jul 2012 11:42:12 +0200 Thread-Topic: Ericsson's position on codecs Thread-Index: Ac1pgJnvVo+eDslsSZO3tDyeasoaZg== Message-ID: <05F760EF51FA6A4F804F9759C239313A45E750C845@ESESSCMS0361.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvre6vXL4Ag4f/RC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs+nk5kL3gpXvFk5mb2BsUmgi5GDQ0LARGLhOrcuRk4gU0zi wr31bCC2kMApRolrs9i7GLmA7IWMEptXvWUGSbAJaEjM33GXEcQWEVCXuPzwAjuIzSKgKnHu yU1WEFtYQE3iz9O/LBA12hL3l71jgrD1JCYdvwU2h1cgXKLh5n2wGkYBWYn73++B2cwC4hK3 nsxngjhIQGLJnvPMELaoxMvH/1gh6mUkTi36zwpRrydxY+oUNghbW2LZwtdQ8wUlTs58wjKB UXgWkrGzkLTMQtIyC0nLAkaWVYzCuYmZOenl5nqpRZnJxcX5eXrFqZsYgcF9cMtvgx2Mm+6L HWKU5mBREufVU93vLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRnz3sc3S5wOEUbp/ebb2S vRFB1rJ9ZXn57xI6C/xLcs0+PL26xrSATW/uZLNdusXtSR8nu0uu8P68+HyqN5MF/6b60FS7 zGMHfrd6BmlKXmj/sGv7ouIg6yfVx2fN2XZg2yoGHoHwhbVZXLnfjeSDllorqj08aXEmWiX/ kZTKrvX33W59TVBiKc5INNRiLipOBADWDcT4PAIAAA== Subject: [rtcweb] Ericsson's position on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 09:42:20 -0000 Hi, The question of which codecs that should be supported in WebRTC [RTCWEB WG]= has been discussed a long time with good opinions from different viewpoint= s. It will again be a subject in the Vancouver meeting and therefore we fee= l a need to recap Ericsson's position. We believe that H.264 video codec should be a mandatory codec (at least one= of what may be several): it is a good video codec, backed by a large vendo= r community and with a considerable footprint in end points. The patent lan= dscape and the licensing situation is well known by now, which is nice in i= tself. Also, H.264 support is a requirement in some regulatory frameworks, = such as emergency services, and we feel it would be preferable if WebRTC me= dia framework can step-by-step consider such requirements, starting with th= e video codec. Looking into the future a bit, we see H.265/HEVC video codec as a strong ca= ndidate to include in the default set, but we think it is too early to mand= ate it at this point.=20 For audio, the situation is that we believe G.719 has a role for high quali= ty audio in areas with no bandwidth restrictions or limited/no risk of bloc= king (packet loss or dropped connection). AMR narrow-band is playing a key = role in mobile telephony and has a huge footprint. This makes it a candidat= e for being a default codec (one of them) for audio streams in mobile WebRT= C implementations. There is also a need for a high quality voice codec for situations with var= ying bandwidth, and we recognize that Opus is a candidate. We would however= for the future also like to recommend that IETF include AMR-WB and EVS, si= nce we expect them to be available in mobile chipsets. This is written in absence of my colleagues who are more close to the codec= technologies and who, had they been available and not on vacation, surely = would have written the above in a better way. However, we hope it serves th= e intended purpose, namely to clarify Ericsson's position in the IETF WebRT= C codec selection discussion. Best Regards Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Tue Jul 24 03:50:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB4021F8668 for ; Tue, 24 Jul 2012 03:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GDL81eBW2Od for ; Tue, 24 Jul 2012 03:50:59 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7452421F866A for ; Tue, 24 Jul 2012 03:50:58 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-de-500e7e11b53f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2E.18.15286.11E7E005; Tue, 24 Jul 2012 12:50:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 24 Jul 2012 12:50:57 +0200 From: Christer Holmberg To: Bo Burman , "rtcweb@ietf.org" Date: Tue, 24 Jul 2012 12:47:27 +0200 Thread-Topic: Ericsson's position on codecs Thread-Index: Ac1pgJnvVo+eDslsSZO3tDyeasoaZgACR3Vn Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340868355E@ESESSCMS0356.eemea.ericsson.se> References: <05F760EF51FA6A4F804F9759C239313A45E750C845@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <05F760EF51FA6A4F804F9759C239313A45E750C845@ESESSCMS0361.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvra5gHV+AQfczFYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XjHY8aCCVIVb48HNjBOE+1i5OCQEDCR6G2J62LkBDLFJC7c W88GYgsJnGKU2PfKoIuRC8hewChxbcd1VpB6NgELie5/2iA1IgLeEpPnXWQEsVkEVCVeTn/D DmILC2hJHF19kxWiRlvi/rJ3TBC2kcTOzo1gcV6BcInz//4wgYwUArI/Xk8GCXMKREh8+fEN bCQj0DnfT60Ba2UWEJe49WQ+E8SZAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvZ7EjalT2CBs bYllC18zQ6wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxCucmZuaklxvppRZlJhcX5+fp FaduYgTGwcEtv1V3MN45J3KIUZqDRUmc13rrHn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jJkhBcZ/NAu6+RXvXuHbLRi8IP22t2S5T4z+ork67f/DQi6wZlad2Gtg5+DEtnb/g3uzOrmL rfPy9t73FnnlUsHxkHmh/0smuVOFc2wezLOcJvhh04k3f559mToh+WHulD3xy/+2i0gYOzp4 XH/K+uy4WMZK5j9N+7wL10Rv8tp3SCl30WG2WUosxRmJhlrMRcWJAJhHSO1RAgAA Subject: Re: [rtcweb] Ericsson's position on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 10:50:59 -0000 Hi, Regarding the video codec, do we have a "plan B"? For example: - "No mandatory video codec" - "VP8 ONLY as mandatory" - "VP8 AND H264 as mandatory" - ... The reason I ask is because, at this moment, I don't think making only H.26= 4 mandatory will fly. At least I have not seen any new input which would ra= ise the odds for being able to agree on such way forward. Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Bo Bur= man [bo.burman@ericsson.com] Sent: Tuesday, July 24, 2012 12:42 PM To: rtcweb@ietf.org Subject: [rtcweb] Ericsson's position on codecs Hi, The question of which codecs that should be supported in WebRTC [RTCWEB WG]= has been discussed a long time with good opinions from different viewpoint= s. It will again be a subject in the Vancouver meeting and therefore we fee= l a need to recap Ericsson's position. We believe that H.264 video codec should be a mandatory codec (at least one= of what may be several): it is a good video codec, backed by a large vendo= r community and with a considerable footprint in end points. The patent lan= dscape and the licensing situation is well known by now, which is nice in i= tself. Also, H.264 support is a requirement in some regulatory frameworks, = such as emergency services, and we feel it would be preferable if WebRTC me= dia framework can step-by-step consider such requirements, starting with th= e video codec. Looking into the future a bit, we see H.265/HEVC video codec as a strong ca= ndidate to include in the default set, but we think it is too early to mand= ate it at this point. For audio, the situation is that we believe G.719 has a role for high quali= ty audio in areas with no bandwidth restrictions or limited/no risk of bloc= king (packet loss or dropped connection). AMR narrow-band is playing a key = role in mobile telephony and has a huge footprint. This makes it a candidat= e for being a default codec (one of them) for audio streams in mobile WebRT= C implementations. There is also a need for a high quality voice codec for situations with var= ying bandwidth, and we recognize that Opus is a candidate. We would however= for the future also like to recommend that IETF include AMR-WB and EVS, si= nce we expect them to be available in mobile chipsets. This is written in absence of my colleagues who are more close to the codec= technologies and who, had they been available and not on vacation, surely = would have written the above in a better way. However, we hope it serves th= e intended purpose, namely to clarify Ericsson's position in the IETF WebRT= C codec selection discussion. Best Regards Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From roman@telurix.com Tue Jul 24 05:40:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D769621F863B for ; Tue, 24 Jul 2012 05:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXb8j9W38QyI for ; Tue, 24 Jul 2012 05:40:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96F0E21F8602 for ; Tue, 24 Jul 2012 05:40:34 -0700 (PDT) Received: by yenq13 with SMTP id q13so7211295yen.31 for ; Tue, 24 Jul 2012 05:40:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7skG1WzGeqrsYyOoA6m0wzD8GYNpmrBSMqFjwDo3t4g=; b=L41yM2X8pkDIWAE40U/UXTcW7/0kXpDgmXJoOnxBBjTFSgPYYIgfkqPWFSVelHPnnZ mc9Xa8HMx5GkI0k3cXRXPG/h5n7Mrm0K+GpkdLFm7n9hKzbolUhvvz8B3z0WE6p9IA1t A8uuY4mJdiampy3Bqm6AwOmR7cuiDhgSA8OL1HQUeR7C8QTxdq+ZHaEHpOyZk/9y8kOx iCKdCL9GZW3R8CAMBciIQQhO/30vmus6J2t8E9NhfiLwhgb2vZjjOyl+BaWMZun/8Pou EFDkMAK3aGyBfYc7GtKUokyCANAniuHJx0jBKKuy9c/RLApWPlnaHI5OfaRC4dvk+p6F FMqw== Received: by 10.236.165.102 with SMTP id d66mr18523816yhl.54.1343133634060; Tue, 24 Jul 2012 05:40:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id v9sm15175391anj.14.2012.07.24.05.40.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jul 2012 05:40:32 -0700 (PDT) Received: by yhq56 with SMTP id 56so7201258yhq.31 for ; Tue, 24 Jul 2012 05:40:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.82.228 with SMTP id l4mr4459228pay.41.1343133630713; Tue, 24 Jul 2012 05:40:30 -0700 (PDT) Received: by 10.68.28.72 with HTTP; Tue, 24 Jul 2012 05:40:30 -0700 (PDT) In-Reply-To: <05F760EF51FA6A4F804F9759C239313A45E750C845@ESESSCMS0361.eemea.ericsson.se> References: <05F760EF51FA6A4F804F9759C239313A45E750C845@ESESSCMS0361.eemea.ericsson.se> Date: Tue, 24 Jul 2012 08:40:30 -0400 Message-ID: From: Roman Shpount To: Bo Burman Content-Type: multipart/alternative; boundary=f46d042ef589f1cf1804c592aa22 X-Gm-Message-State: ALoCoQnd9ArBtEmXKguK+qt/BGZ16E/OROX+ExqXXoHqOoAWobNypS9cUl/pIv6qSaBBqUp9uRqO Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Ericsson's position on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 12:40:36 -0000 --f46d042ef589f1cf1804c592aa22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to note that AMR, EVS, and AMR-WB would require royalty payments for their use. G.719 has a license agreement that is not always acceptable for open source projects. I am not sure that either would provide better quality then OPUS at similar bandwidths. Because of this I would sincerely hope that none of those codecs are required. _____________ Roman Shpount On Tue, Jul 24, 2012 at 5:42 AM, Bo Burman wrote: > Hi, > > The question of which codecs that should be supported in WebRTC [RTCWEB > WG] has been discussed a long time with good opinions from different > viewpoints. It will again be a subject in the Vancouver meeting and > therefore we feel a need to recap Ericsson's position. > > We believe that H.264 video codec should be a mandatory codec (at least > one of what may be several): it is a good video codec, backed by a large > vendor community and with a considerable footprint in end points. The > patent landscape and the licensing situation is well known by now, which = is > nice in itself. Also, H.264 support is a requirement in some regulatory > frameworks, such as emergency services, and we feel it would be preferabl= e > if WebRTC media framework can step-by-step consider such requirements, > starting with the video codec. > > Looking into the future a bit, we see H.265/HEVC video codec as a strong > candidate to include in the default set, but we think it is too early to > mandate it at this point. > > For audio, the situation is that we believe G.719 has a role for high > quality audio in areas with no bandwidth restrictions or limited/no risk = of > blocking (packet loss or dropped connection). AMR narrow-band is playing = a > key role in mobile telephony and has a huge footprint. This makes it a > candidate for being a default codec (one of them) for audio streams in > mobile WebRTC implementations. > > There is also a need for a high quality voice codec for situations with > varying bandwidth, and we recognize that Opus is a candidate. We would > however for the future also like to recommend that IETF include AMR-WB an= d > EVS, since we expect them to be available in mobile chipsets. > > This is written in absence of my colleagues who are more close to the > codec technologies and who, had they been available and not on vacation, > surely would have written the above in a better way. However, we hope it > serves the intended purpose, namely to clarify Ericsson's position in the > IETF WebRTC codec selection discussion. > > Best Regards > > Bo Burman > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7141311 > F=E4r=F6gatan 6 | Mobile +46 73 0949021 > SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d042ef589f1cf1804c592aa22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to note that AMR, EVS, and AMR-WB would require royalty paymen= ts for their use. G.719 has a license agreement that is not always acceptab= le for open source projects. I am not sure that either would provide better= quality then OPUS at similar bandwidths. Because of this I would sincerely= hope that none of those codecs are required.
_____________
Roman Shpount


On Tue, Jul 24, 2012 at 5:42 AM, Bo Burm= an <bo.burman@ericsson.com> wrote:
Hi,

The question of which codecs that should be supported in WebRTC [RTCWEB WG]= has been discussed a long time with good opinions from different viewpoint= s. It will again be a subject in the Vancouver meeting and therefore we fee= l a need to recap Ericsson's position.

We believe that H.264 video codec should be a mandatory codec (at least one= of what may be several): it is a good video codec, backed by a large vendo= r community and with a considerable footprint in end points. The patent lan= dscape and the licensing situation is well known by now, which is nice in i= tself. Also, H.264 support is a requirement in some regulatory frameworks, = such as emergency services, and we feel it would be preferable if WebRTC me= dia framework can step-by-step consider such requirements, starting with th= e video codec.

Looking into the future a bit, we see H.265/HEVC video codec as a strong ca= ndidate to include in the default set, but we think it is too early to mand= ate it at this point.

For audio, the situation is that we believe G.719 has a role for high quali= ty audio in areas with no bandwidth restrictions or limited/no risk of bloc= king (packet loss or dropped connection). AMR narrow-band is playing a key = role in mobile telephony and has a huge footprint. This makes it a candidat= e for being a default codec (one of them) for audio streams in mobile WebRT= C implementations.

There is also a need for a high quality voice codec for situations with var= ying bandwidth, and we recognize that Opus is a candidate. We would however= for the future also like to recommend that IETF include AMR-WB and EVS, si= nce we expect them to be available in mobile chipsets.

This is written in absence of my colleagues who are more close to the codec= technologies and who, had they been available and not on vacation, surely = would have written the above in a better way. However, we hope it serves th= e intended purpose, namely to clarify Ericsson's position in the IETF W= ebRTC codec selection discussion.

Best Regards

Bo Burman

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 7141311
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com
----------------------------------------------------------------------
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d042ef589f1cf1804c592aa22-- From ted.ietf@gmail.com Tue Jul 24 08:31:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09B21F8613 for ; Tue, 24 Jul 2012 08:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.132 X-Spam-Level: X-Spam-Status: No, score=-4.132 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad2gvH+pPn41 for ; Tue, 24 Jul 2012 08:31:40 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A38521F84A0 for ; Tue, 24 Jul 2012 08:31:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6357243vbb.31 for ; Tue, 24 Jul 2012 08:31: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=KeWoY0kgMZY30Y8++etzn09JThOS/mehi9Nk8GjK4fs=; b=iYRQwf8CFxwNOdHtb1UAki1hoTxGF2iTd1i1IrpULCclyr6wNR3IMVaDnl1qo1Dfh/ d/KNRrEdnQtPZDxJKzZxxxN3IucXFRhWYE+E0f6eP8nbOVtkvdgqh6etzSV0eK2RcdVk S5R7/7R1giAlag2Wnj1wOFuuOSlsOgOs6X95lBuZVdOLhhG2R09o67QmUs7ussyENbb8 W+tjMB7KoMq1A6NEfS9YxIb0MeTfXDJgHkJYRfZ8las1GGQIiclr1G7jS8gXZkFYM6oj OwItk3R1thk8Frt0DvGpxh1zcQyFLxH5jxddSwccvXeWDS8zVEPtMg+s/q/G8UrDqTNL qOeQ== MIME-Version: 1.0 Received: by 10.220.107.198 with SMTP id c6mr15901363vcp.54.1343143899385; Tue, 24 Jul 2012 08:31:39 -0700 (PDT) Received: by 10.52.170.68 with HTTP; Tue, 24 Jul 2012 08:31:39 -0700 (PDT) In-Reply-To: <50072142.8000208@alcatel-lucent.com> References: <50072142.8000208@alcatel-lucent.com> Date: Tue, 24 Jul 2012 08:31:39 -0700 Message-ID: From: Ted Hardie To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 15:31:41 -0000 Hi Igor, Thanks for pointing out the potential conflict. The chairs had a quick discussion of this issue this morning and, unfortunately, we probably are not going to be able to make this change. There are always some conflicts, unfortunately, and we're sorry for any inconvenience. regards, Ted On Wed, Jul 18, 2012 at 1:49 PM, Igor Faynberg wrote: > Ted, > > I notice a conflict of the second session (which covers security) with > OAuth. Is it possible to change the schedule? OAuth seems to be applicable > to RTCWeb authorization. > > It might be impossible to reschedule, but would you consider swapping the > content of the slots so that security is covered in the first session? > > With thanks, > > Igor > > > On 7/18/2012 3:48 PM, Ted Hardie wrote: >> >> A draft agenda has been posted at: >> http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb >> >> Edits and adjustments still possible; comments to the list. >> >> Ted >> _______________________________________________ >> 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 igor.faynberg@alcatel-lucent.com Tue Jul 24 08:57:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DB921F85A5 for ; Tue, 24 Jul 2012 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.976 X-Spam-Level: X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjH3BUsrvdBz for ; Tue, 24 Jul 2012 08:57:22 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3876321F858D for ; Tue, 24 Jul 2012 08:57:22 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q6OFvKes001992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Jul 2012 10:57:20 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6OFvKus001210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jul 2012 10:57:20 -0500 Received: from [135.244.0.81] (faynberg.lra.lucent.com [135.244.0.81]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6OFvJxk023328; Tue, 24 Jul 2012 10:57:20 -0500 (CDT) Message-ID: <500EC5DF.7020408@alcatel-lucent.com> Date: Tue, 24 Jul 2012 11:57:19 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ted Hardie References: <50072142.8000208@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 15:57:23 -0000 Ted, Thanks for the consideration and for the effort. I understand the scheduling problem very well (been there, done that...), and I know that it can become unmanageable, what with presenters being in other sessions or arriving late, or... Needless to say, If there is any chance that at least some security discussions--in which I would very much want to participate,--could take place om the first session, I would very much appreciate it! With thanks, again, Igor On 7/24/2012 11:31 AM, Ted Hardie wrote: > Hi Igor, > > Thanks for pointing out the potential conflict. The chairs had a > quick discussion of this issue this morning and, unfortunately, we > probably are not going to be able to make this change. There are > always some conflicts, unfortunately, and we're sorry for any > inconvenience. > > regards, > > Ted > > On Wed, Jul 18, 2012 at 1:49 PM, Igor Faynberg > wrote: >> Ted, >> >> I notice a conflict of the second session (which covers security) with >> OAuth. Is it possible to change the schedule? OAuth seems to be applicable >> to RTCWeb authorization. >> >> It might be impossible to reschedule, but would you consider swapping the >> content of the slots so that security is covered in the first session? >> >> With thanks, >> >> Igor >> >> >> On 7/18/2012 3:48 PM, Ted Hardie wrote: >>> A draft agenda has been posted at: >>> http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb >>> >>> Edits and adjustments still possible; comments to the list. >>> >>> Ted >>> _______________________________________________ >>> 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 mdr@reavy.org Tue Jul 24 10:35:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E12C21F8598 for ; Tue, 24 Jul 2012 10:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiS6igeyCxKl for ; Tue, 24 Jul 2012 10:35:10 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 775F721F84F7 for ; Tue, 24 Jul 2012 10:35:04 -0700 (PDT) Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.4]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Stj0h-0000JW-6v for rtcweb@ietf.org; Tue, 24 Jul 2012 12:35:03 -0500 Message-ID: <500EDCC9.1040805@reavy.org> Date: Tue, 24 Jul 2012 13:35:05 -0400 From: Maire Reavy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <05F760EF51FA6A4F804F9759C239313A45E750C845@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080903030605000605000001" 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 - reavy.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Ericsson's position on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:35:12 -0000 This is a multi-part message in MIME format. --------------080903030605000605000001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 7/24/2012 8:40 AM, Roman Shpount wrote: > I would like to note that AMR, EVS, and AMR-WB would require royalty > payments for their use. G.719 has a license agreement that is not > always acceptable for open source projects. I am not sure that either > would provide better quality then OPUS at similar bandwidths. Because > of this I would sincerely hope that none of those codecs are required. +1. OPUS is a better solution and the only one I hope we mandate (other than G.711). Regarding video: H.264 requires royalty payments and agreements as well, and so mandating H.264 is *extremely* problematic for open-source groups and distributions (not just open-source browsers). It makes open-source use of WebRTC virtually impossible without violating the spec (by not implementing a mandatory codec). -Maire > > > On Tue, Jul 24, 2012 at 5:42 AM, Bo Burman > wrote: > > Hi, > > The question of which codecs that should be supported in WebRTC > [RTCWEB WG] has been discussed a long time with good opinions from > different viewpoints. It will again be a subject in the Vancouver > meeting and therefore we feel a need to recap Ericsson's position. > > We believe that H.264 video codec should be a mandatory codec (at > least one of what may be several): it is a good video codec, > backed by a large vendor community and with a considerable > footprint in end points. The patent landscape and the licensing > situation is well known by now, which is nice in itself. Also, > H.264 support is a requirement in some regulatory frameworks, such > as emergency services, and we feel it would be preferable if > WebRTC media framework can step-by-step consider such > requirements, starting with the video codec. > > Looking into the future a bit, we see H.265/HEVC video codec as a > strong candidate to include in the default set, but we think it is > too early to mandate it at this point. > > For audio, the situation is that we believe G.719 has a role for > high quality audio in areas with no bandwidth restrictions or > limited/no risk of blocking (packet loss or dropped connection). > AMR narrow-band is playing a key role in mobile telephony and has > a huge footprint. This makes it a candidate for being a default > codec (one of them) for audio streams in mobile WebRTC > implementations. > > There is also a need for a high quality voice codec for situations > with varying bandwidth, and we recognize that Opus is a candidate. > We would however for the future also like to recommend that IETF > include AMR-WB and EVS, since we expect them to be available in > mobile chipsets. > > This is written in absence of my colleagues who are more close to > the codec technologies and who, had they been available and not on > vacation, surely would have written the above in a better way. > However, we hope it serves the intended purpose, namely to clarify > Ericsson's position in the IETF WebRTC codec selection discussion. > > Best Regards > > Bo Burman > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7141311 > > Färögatan 6 | Mobile +46 73 0949021 > > SE-164 80 Stockholm, Sweden | mailto: bo.burman@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 -- Maire Reavy, Sr Product Manager, Media Mozilla --------------080903030605000605000001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/24/2012 8:40 AM, Roman Shpount wrote:
I would like to note that AMR, EVS, and AMR-WB would require royalty payments for their use. G.719 has a license agreement that is not always acceptable for open source projects. I am not sure that either would provide better quality then OPUS at similar bandwidths. Because of this I would sincerely hope that none of those codecs are required.
+1.  OPUS is a better solution and the only one I hope we mandate (other than G.711).

Regarding video: H.264 requires royalty payments and agreements as well, and so mandating H.264 is *extremely* problematic for open-source groups and distributions (not just open-source browsers).  It makes open-source use of WebRTC virtually impossible without violating the spec (by not implementing a mandatory codec).

-Maire



On Tue, Jul 24, 2012 at 5:42 AM, Bo Burman <bo.burman@ericsson.com> wrote:
Hi,

The question of which codecs that should be supported in WebRTC [RTCWEB WG] has been discussed a long time with good opinions from different viewpoints. It will again be a subject in the Vancouver meeting and therefore we feel a need to recap Ericsson's position.

We believe that H.264 video codec should be a mandatory codec (at least one of what may be several): it is a good video codec, backed by a large vendor community and with a considerable footprint in end points. The patent landscape and the licensing situation is well known by now, which is nice in itself. Also, H.264 support is a requirement in some regulatory frameworks, such as emergency services, and we feel it would be preferable if WebRTC media framework can step-by-step consider such requirements, starting with the video codec.

Looking into the future a bit, we see H.265/HEVC video codec as a strong candidate to include in the default set, but we think it is too early to mandate it at this point.

For audio, the situation is that we believe G.719 has a role for high quality audio in areas with no bandwidth restrictions or limited/no risk of blocking (packet loss or dropped connection). AMR narrow-band is playing a key role in mobile telephony and has a huge footprint. This makes it a candidate for being a default codec (one of them) for audio streams in mobile WebRTC implementations.

There is also a need for a high quality voice codec for situations with varying bandwidth, and we recognize that Opus is a candidate. We would however for the future also like to recommend that IETF include AMR-WB and EVS, since we expect them to be available in mobile chipsets.

This is written in absence of my colleagues who are more close to the codec technologies and who, had they been available and not on vacation, surely would have written the above in a better way. However, we hope it serves the intended purpose, namely to clarify Ericsson's position in the IETF WebRTC codec selection discussion.

Best Regards

Bo Burman

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7141311
Färögatan 6                 | Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden | mailto: bo.burman@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


-- 
Maire Reavy <mreavy@mozilla.com>, <mdr@reavy.org>
Sr Product Manager, Media
Mozilla

--------------080903030605000605000001-- From harald@alvestrand.no Wed Jul 25 08:26:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C46621F8622 for ; Wed, 25 Jul 2012 08:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezm3TdJGteyk for ; Wed, 25 Jul 2012 08:26:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 519C621F846A for ; Wed, 25 Jul 2012 08:26:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05C8439E1BB for ; Wed, 25 Jul 2012 17:26:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWMoU2NMoeix for ; Wed, 25 Jul 2012 17:26:36 +0200 (CEST) Received: from [192.168.16.101] (unknown [206.191.100.2]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6829039E056 for ; Wed, 25 Jul 2012 17:26:35 +0200 (CEST) Message-ID: <50101034.3080807@alvestrand.no> Date: Wed, 25 Jul 2012 08:26:44 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F1770A313@US70UWXCHMBA04.zam.alcatel-lucent.com> <5008EDD7.60801@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F1770A52C@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1770A52C@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------070609000107000204040700" Subject: Re: [rtcweb] data channel protocol comments and potential agenda topic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:26:42 -0000 This is a multi-part message in MIME format. --------------070609000107000204040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/20/2012 09:10 AM, Ejzak, Richard P (Richard) wrote: > > I don't see any conflict between our positions, Harald. You are > arguing that we need a generic data transfer capability that can be > used by any application for any purpose, which can be achieved by > specifying raw data transfer, and I fully support this. I am arguing > that it would be advantageous to be able to have the option to specify > an underlying protocol on a data channel so that we can develop > interoperable applications. These capabilities are not mutually > exclusive. > > An example might be MSRP. If we would like to use MSRP between > endpoints then we could specify that browsers need to support MSRP > natively and specify a new API to access it. Or we could allow an > application to send MSRP over a data channel without impacting the > browser. This would potentially allow browsers running different > communications applications to use MSRP in addition to audio and video > media for communication, even if other application specific uses of > data channel are not interoperable. > Noted - we may not be in disagreement, only arguing terminology. In my terminology, MSRP is not a purpose, it's a protocol. It's clear to me that if applications need to standardize a way to use MSRP over the data channel, they need to be able to signal that this is what they're going to do, and have reasonable assurcance that nothing else is going to interfere with that purpose. There are many ways to achieve this purpose through signalling ("I want to do MSRP over the data channel named "msrp""; "OK with using "msrp"") is a typical signalling sequence that would accomplish the purpose), API extensions that can access the setup protocol in ways that the current API cannot, or other ways. The discussion of that belongs, I think, in the discussion of standardizing MSRP over data channel, not in the discussion of the data channel itself. > I'm not arguing that we should standardize MSRP over data channel -- > just that this approach gives us the potential to define interoperable > data channel applications in the future. > > It would also be a good idea to reserve a range of ppid values for > proprietary use. Then when two browsers are communicating with the > same application, the application can signal the purpose behind a new > block of data with the choice of proprietary ppid value. An > application might use one value to signal gaming control information > and another value to signal display information. This approach would > save a typical application from exchanging signaling just to set up > channels so that it can begin to use them. > My personal opinion is that this is not a good use of PPID. But if I understand correctly, PPID values are IANA registered. Feel free to make the proposal. http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xml#sctp-parameters-25 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------070609000107000204040700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/20/2012 09:10 AM, Ejzak, Richard P (Richard) wrote:

I don’t see any conflict between our positions, Harald.  You are arguing that we need a generic data transfer capability that can be used by any application for any purpose, which can be achieved by specifying raw data transfer, and I fully support this.  I am arguing that it would be advantageous to be able to have the option to specify an underlying protocol on a data channel so that we can develop interoperable applications.  These capabilities are not mutually exclusive.

 

An example might be MSRP.  If we would like to use MSRP between endpoints then we could specify that browsers need to support MSRP natively and specify a new API to access it.  Or we could allow an application to send MSRP over a data channel without impacting the browser.  This would potentially allow browsers running different communications applications to use MSRP in addition to audio and video media for communication, even if other application specific uses of data channel are not interoperable.

Noted - we may not be in disagreement, only arguing terminology.

In my terminology, MSRP is not a purpose, it's a protocol.
It's clear to me that if applications need to standardize a way to use MSRP over the data channel, they need to be able to signal that this is what they're going to do, and have reasonable assurcance that nothing else is going to interfere with that purpose. There are many ways to achieve this purpose through signalling ("I want to do MSRP over the data channel named "msrp""; "OK with using "msrp"") is a typical signalling sequence that would accomplish the purpose), API extensions that can access the setup protocol in ways that the current API cannot, or other ways.

The discussion of that belongs, I think, in the discussion of standardizing MSRP over data channel, not in the discussion of the data channel itself.

 

I’m not arguing that we should standardize MSRP over data channel – just that this approach gives us the potential to define interoperable data channel applications in the future.

 

It would also be a good idea to reserve a range of ppid values for proprietary use.  Then when two browsers are communicating with the same application, the application can signal the purpose behind a new block of data with the choice of proprietary ppid value.  An application might use one value to signal gaming control information and another value to signal display information.  This approach would save a typical application from exchanging signaling just to set up channels so that it can begin to use them.

My personal opinion is that this is not a good use of PPID.

But if I understand correctly, PPID values are IANA registered. Feel free to make the proposal.

http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xml#sctp-parameters-25




 



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


--------------070609000107000204040700-- From magnus.westerlund@ericsson.com Thu Jul 26 06:12:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C55E21F8760 for ; Thu, 26 Jul 2012 06:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5ECiVLIDyyf for ; Thu, 26 Jul 2012 06:12:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6F21F875E for ; Thu, 26 Jul 2012 06:12:39 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-65-501142450118 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 75.20.15286.54241105; Thu, 26 Jul 2012 15:12:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Thu, 26 Jul 2012 15:12:37 +0200 Message-ID: <50114244.8070600@ericsson.com> Date: Thu, 26 Jul 2012 15:12:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "public-webrtc@w3.org" , "rtcweb@ietf.org" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvra6rk2CAQe9/dYvej0sYLdb+a2d3 YPJYsuQnk8fReftZA5iiuGxSUnMyy1KL9O0SuDKm3T7HVNAuXDH70GLWBsbr/F2MnBwSAiYS N2Z1MkLYYhIX7q1n62Lk4hASOMUosbu3nR3CWc4osW7lWlaQKl4BbYnJ//8yg9gsAqoSOxtv s4DYbAIWEjd/NLKB2KICgRLfth6HqheUODnzCViNiECkRMfC/2C9wgJaEouuLgWq5wDaLClx +0AKSJhZQE9iytUWRghbXqJ562ywciGgtQ1NHawTGPlnIZk6C0nLLCQtCxiZVzEK5yZm5qSX G+mlFmUmFxfn5+kVp25iBIbewS2/VXcw3jkncohRmoNFSZzXeusefyGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MfqZfr3ypW/n7RBjf76y8GL31p5ewxyZ738o2W+v+PT8jw6Hp4USBxc8U 72eqT/ofoKrlsLDBxj4qk+PhVvOuTZvrw/vnbuEoS1ohuuxYhKbb3QvnVh960u+olhOyw2DL qwl3Myr3lN5suHrbgOHSzZY1p8VfHY7c753/ULnP6aisVefGWdPjlFiKMxINtZiLihMBFj4P XQsCAAA= Subject: [rtcweb] Using PAUSED to trigger API event X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 13:12:40 -0000 Hi, (as individual) Bo and I have a proposal in AVTEXT for an RTCP based mechanism for RTP Media stream pause and resume. https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/ This will be discussed in the AVTEXT session on Thursday 17.30 in Regency E. The reason I am bring this up for WebRTC is that we think it can actually resolve one potential issue between the media transport protocol and the API. A media sender in RTP can stop sending a media stream at any point in time. This may be the result of a sender side Disable on the media stream track using the API. In the case of centralized media servers it could be that server that stops distributing that media stream based on lack of input or adaptation control. What I believe to be a potential issue is that the media receiving browser will not get any explicit indication that the discontinued transmission happened at the source and was intentional. The reason a receiver isn't receiving a media stream could be that the packets get lost en-route. Thus a question arise in how the receiving browser knows when to trigger the event indicating that mediaStream track has stopped. It can clearly be timer-based but that timer needs to be sufficiently robust to rarely misclassifying transport interruptions from an actual intentional media delivery stop. Thus I propose that this could be improved significantly by having media senders use the PAUSED indication from draft-westerlund-avtext-rtp-stream-pause to indicate to the media receiver that yes, this was an intentional halt in media delivery. Thus enabling a triggering of the event immediately when the last media is being processed/displayed rather than later after some timeout has occurred. Thus greatly improving the applications possibility to remove blank video displays, reconfigure the GUI etc based on the current availability of media streams. Comments and views? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 juberti@google.com Thu Jul 26 17:08:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBFF21F85F2 for ; Thu, 26 Jul 2012 17:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+O0s9lPXuzT for ; Thu, 26 Jul 2012 17:08:00 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id F03DA21F85F1 for ; Thu, 26 Jul 2012 17:07:59 -0700 (PDT) Received: by qaea16 with SMTP id a16so1562508qae.10 for ; Thu, 26 Jul 2012 17:07:59 -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:x-system-of-record; bh=ZKAccs3pff6WosHhNSaqosxNqdeZOtG388lYQKPdZFc=; b=HCl9zrRdonvu2/7liL+Vs3D+7dIq2pHQUK/zyegY1nPRR7zYp148csTFJIiLuSh0l7 cHUdDYMMu58/UeKtZ66LozZvBX1M2cVYnqUWtyN+CNzxE5mmT8VnaHAewqenf3ALK7jA bZy/l6v8mldOzVGTOAN9ckp/xkkQvHI6FUa3bg57X7gdKm4XTeg17Z7hb4N8X+TnKxgL OL/DyyPOppwclE3lOkeSOGht/W/TdJIu3mIj8oZdWKyw34TnkL7LhAkrECM0G4ze/HAA J6oFZCUqqDItJt8Ttgxxq7x3+LL9vowaiec6P0+b40xgp38rVqVdPj/vnfeH3Tm1tPiA 7iHA== X-Google-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:x-system-of-record:x-gm-message-state; bh=ZKAccs3pff6WosHhNSaqosxNqdeZOtG388lYQKPdZFc=; b=OUiUh9zdOCpZll5xkllOJZTDH0teZ2I+3IKqJelLqop/a9P5d6br0ESOaEfpVBy+4I dz0MO0L6f7dmhSMpJt69m3UgwrRaaSIlunfvRpWEM+btkZbeA1sxI7YfWAwzXwn+3Wmj lJ7hInLWxzu8BJ94JVeRNdE3XmNjCQgAWw8oeXv6oTf+dxjmSatZeAHeHrWvqy7e7vXh 7xwvf5rLHIFuzFEvC2tWdNEGOwifHOy4rgBz3pav7Pg4CVog5dKmDG/9XEdbZv5Js2Om GL1MA5Zeem5oPdsNGCJGECXLPWI0SEbtPk/v8UUFnuH+aG7KJ5lru5/ZsVnzq6v6aj9u tGfA== Received: by 10.229.134.202 with SMTP id k10mr291621qct.71.1343347679183; Thu, 26 Jul 2012 17:07:59 -0700 (PDT) Received: by 10.229.134.202 with SMTP id k10mr291616qct.71.1343347679034; Thu, 26 Jul 2012 17:07:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.59.66 with HTTP; Thu, 26 Jul 2012 17:07:38 -0700 (PDT) In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F177082F7@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F177082F7@US70UWXCHMBA04.zam.alcatel-lucent.com> From: Justin Uberti Date: Thu, 26 Jul 2012 17:07:38 -0700 Message-ID: To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=00248c71181537fe6004c5c481f9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmL6Zrdla7ywvvfOT7yvqZZXfj/YEWnPMR96Ojum2CjNhDlO28iHsF0u4kwvTAr/k0qGIfwNFJgNQp8itqwotk45fz+PQOx+Ccg+TCGVvQG2Cp+vAJ+1tMEN4ekIHgSI69ye5IC3ev1I5Q39F8KHL0aLbEPA0fHP52krieuM4oDBlaljfo= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] jsep 01 comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 00:08:01 -0000 --00248c71181537fe6004c5c481f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Richard, Thanks for your detailed review. I've been preoccupied with vacation and relocation, but we'll work on addressing these comments shortly. On Thu, Jul 5, 2012 at 12:42 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > I agreed to review jsep 01 during the interim. Please see my comments > below against version 01 of the jsep draft.**** > > ** ** > > In the paragraph before figure 2 in section 4.2, the text justifies the > notion of multiple outstanding offers and answers based on RFC 3264. Thi= s > is incorrect. RFC 3264 very clearly describes (in section 4) how each > offer cannot be updated until an answer is received and that an answer is > final. This should be made clear in jsep. The actual justifications for > multiple outstanding offers and answers should be made clear and their us= e > within the context of RFC 3264 needs to be made clear. Specifically with= in > the context of SIP, there is no justification or support for multiple > offers, and the only justification for multiple answers is to provide a > limited mechanism for dealing with some SIP forking cases.**** > > ** ** > > The 2nd paragraph of section 4.5 should make clear that XMPP is an > example application supporting the capability (ICE trickling) and SIP is > not.**** > > ** ** > > In section 4.7, it should be made clear that SIP forking is being > considered (with clear references) and any XMPP analogs, if they exist. > Obviously section 4.7.2 should indicate cloning as a possible strategy to > fully address parallel forking that is not currently supported. The text > should describe that in the absence of cloning ICE and DTLS may not begin > until a =E2=80=9Cwinning=E2=80=9D target is selected, thus potentially de= laying the start > of media flow, whereas ICE and DTLS could occur in parallel were cloning > supported.**** > > ** ** > > Section 4.8 needs updating. It is not clear from the description if a ne= w > PeerConnection needs to be established (or how to re-establish the old on= e) > and how to ensure that the new PeerConnection will be compatible with the > old LocalDescription. I think the description should say that > PeerConnection is recreated using the old parameters and (reconstructed?) > MediaStreams. Something is also needed to describe how to ensure the > continued availability of the old MediaStreams. Rehydration will require > end-to-end offer/answer to recreate the PeerConnection anyway, and I=E2= =80=99m not > sure of the value of attempting to reuse the old LocalDescription since i= t > may not make sense to force some of the old attributes. Some discussion = of > how to ensure this is needed if the concept of reusing the old > LocalDescription (and MediaStreams) is retained.**** > > ** ** > > In section 5.1.1, the first paragraph describes createOffer the first tim= e > it is invoked but not necessarily its behavior for subsequent invocations= . > The last sentence of the 2nd paragraph is inconsistent with the last > sentence of the first paragraph under some circumstances. The local > description used to populate the offer once the session is established, b= ut > may come in three flavors (noting that an offerer may later become an > answerer for the same PeerConnection and vice versa): 1) the local > description set by the prior offerer before receiving a final answer (thu= s > reflecting all supported codecs and capabilities according to the > constraints); 2) the local description set by the prior answerer (thus > reflecting only the selected codecs and capabilities); and 3) the local > description set by the prior offerer but where createOffer occurs after > receiving final answer to the previous offer (in this case the offer may > include codecs and capabilities already released by the browser).**** > > ** ** > > The last paragraph of section 5.1.1 describes that in case 3) the offer > should be modified to reflect the =E2=80=9Ccurrent state of the system=E2= =80=9D. It=E2=80=99s not > completely clear if this is intended to describe the current resources > allocated to the PeerConnection or the potential resources that could be > allocated (i.e., the full set of available codecs and capabilities). It = is > similarly unclear for case 2) if the offer is to be changed and how.**** > > ** ** > > The last sentence of the second paragraph of section 5.1.1 is also > inconsistent with the last paragraph of the section and it is not clear > which one takes precedence.**** > > ** ** > > This potential inconsistency in the behavior of createOffer is problemati= c > to an application since the range of capabilities reflected in the SDP is > state dependent. The result of createOffer should not depend on whether > the browser was previously offerer or answerer and it should be possible = to > request either current capabilities or the complete list of potential > capabilities for each unchanged m line in the offer using the constraints > parameter.**** > > ** ** > > I was asked during the interim to justify the need for a =E2=80=9Cfull=E2= =80=9D offer as > compared to an offer that just reflects the current capabilities. There > are many examples in SIP where a node is sent an =E2=80=9Cempty re-INVITE= =E2=80=9D or a > =E2=80=9CREFER with REPLACES=E2=80=9D during a session to trigger the nod= e to send a new > SDP offer to renegotiate media. This may be triggered due to an interfac= e > change, a network server (e.g., acting as B2BUA) moving the media to > another endpoint such as a conference server, etc. In all these cases > there is no guarantee that the new target will support the same codecs or > have the same capabilities, so the best way forward is to create a =E2=80= =9Cfull=E2=80=9D > offer to make it most likely that an acceptable media configuration can b= e > achieved in a single offer/answer transaction. There are other cases whe= re > it may be acceptable to send a =E2=80=9Cminimal=E2=80=9D offer, but only = the application > can determine which one is needed.**** > > ** ** > > The 3rd paragraph of 5.1.2 says that createAnswer should also reflect the > =E2=80=9Ccurrent state=E2=80=9D of the system. It is very confusing to u= se the same words > to describe createOffer and createAnswer since they should not mean the > same thing. The text should be clarified to distinguish between these tw= o > cases.**** > > ** ** > > There is a great need for a new section (possibly a subsection of 4) that > describes the relationship between MediaStreams and media lines. An rtcw= eb > MediaStream is not the same as an RFC 3264 media stream, thus causing > endless potential for confusion (I admit to being one of the victims). A= n > RFC 3264 media stream is more akin to a MediaStreamTrack, and even that i= s > not completely accurate since we will allow multiple MediaStreamTracks pe= r > m line. How does the browser decide how to allocate MediaStreamTracks to= m > lines? The easy solution is to assign each track to a separate m line bu= t > this is wasteful when multiple tracks carry the same media type. But not > all tracks of the same media type should be forced to use the same m line > since it may be necessary to negotiate different capabilities for these > tracks. It must somehow be made clear to the browser which tracks can be > combined on an m line and which cannot so that it can generate an > appropriate offer with the proper number of m lines.**** > > ** ** > > In section 5.1.4, it should be pointed out that the need to support both > old and new local descriptions means that the PeerConnection must in some > sense be =E2=80=9Ccloned=E2=80=9D since there may be completely different= remote candidates > and codecs selected for use with the new description and both > configurations need to be simultaneously supported for an interim period. > It is also not explained how to remove the new configuration if the 2ndo= ffer/answer fails. I do not think that the state diagram supports a > transition from offer state or pranswer state back to stable state withou= t > processing a valid answer. Note this is also another implicit meaning of > pranswer that should be described for subsequent offer/answer transaction= s > =E2=80=93 both the old and new configurations need to be supported until = receipt of > final answer or failure is indicated.**** > > ** ** > > Sections 5.1.6 and 5.1.7 should clarify the relationship between the > local/remote description and the actual resources allocated. One of them > usually reflects the configured resources while the other is generally a > superset. If this is not the intended semantic, then that should also be > clarified.**** > > ** ** > > In section 5.2, I believe the RTP header extension attribute in RFC 5285 > is a=3Dextmap rather than a=3Drtphdr-ext.**** > > ** ** > > Richard**** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --00248c71181537fe6004c5c481f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Richard,

Thanks for your detailed review. I've been = preoccupied with vacation and relocation, but we'll work on addressing = these comments shortly.


On Thu, Jul 5, 2012 at 12:42 PM, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com> wrote:

I agreed to review jsep 01 during the interim. =C2=A0Pl= ease see my comments below against version 01 of the jsep draft.<= /u>

=C2=A0

In the paragraph before figure 2 in section 4.2, the te= xt justifies the notion of multiple outstanding offers and answers based on= RFC 3264. =C2=A0This is incorrect.=C2=A0 RFC 3264 very clearly describes (in section 4) how each offer cannot be up= dated until an answer is received and that an answer is final. =C2=A0This s= hould be made clear in jsep.=C2=A0 The actual justifications for multiple o= utstanding offers and answers should be made clear and their use within the context of RFC 3264 needs to be made clear.= =C2=A0 Specifically within the context of SIP, there is no justification or= support for multiple offers, and the only justification for multiple answe= rs is to provide a limited mechanism for dealing with some SIP forking cases.

=C2=A0

The 2nd paragraph of section 4.5 should make= clear that XMPP is an example application supporting the capability (ICE t= rickling) and SIP is not.

=C2=A0

In section 4.7, it should be made clear that SIP forkin= g is being considered (with clear references) and any XMPP analogs, if they= exist.=C2=A0 Obviously section 4.7.2 should indicate cloning as a possible strategy to fully address para= llel forking that is not currently supported. =C2=A0The text should describ= e that in the absence of cloning ICE and DTLS may not begin until a =E2=80= =9Cwinning=E2=80=9D target is selected, thus potentially delaying the start of media flow, whereas ICE and DTLS could occur in para= llel were cloning supported.

=C2=A0

Section 4.8 needs updating.=C2=A0 It is not clear from = the description if a new PeerConnection needs to be established (or how to = re-establish the old one) and how to ensure that the new PeerConnection will be compatible with the old Loca= lDescription. =C2=A0I think the description should say that PeerConnection = is recreated using the old parameters and (reconstructed?) MediaStreams.=C2= =A0 Something is also needed to describe how to ensure the continued availability of the old MediaStreams. =C2=A0Rehydr= ation will require end-to-end offer/answer to recreate the PeerConnection a= nyway, and I=E2=80=99m not sure of the value of attempting to reuse the old= LocalDescription since it may not make sense to force some of the old attributes. =C2=A0Some discussion of how to ensur= e this is needed if the concept of reusing the old LocalDescription (and Me= diaStreams) is retained.

=C2=A0

In section 5.1.1, the first paragraph describes createO= ffer the first time it is invoked but not necessarily its behavior for subs= equent invocations. =C2=A0The last sentence of the 2nd paragraph is inconsistent with the last sen= tence of the first paragraph under some circumstances. =C2=A0The local desc= ription used to populate the offer once the session is established, but may= come in three flavors (noting that an offerer may later become an answerer for the same PeerConnection and vice = versa): 1) the local description set by the prior offerer before receiving = a final answer (thus reflecting all supported codecs and capabilities accor= ding to the constraints); 2) the local description set by the prior answerer (thus reflecting only the sele= cted codecs and capabilities); and 3) the local description set by the prio= r offerer but where createOffer occurs after receiving final answer to the = previous offer (in this case the offer may include codecs and capabilities already released by the browser)= .

=C2=A0

The last paragraph of section 5.1.1 describes that in c= ase 3) the offer should be modified to reflect the =E2=80=9Ccurrent state o= f the system=E2=80=9D. =C2=A0It=E2=80=99s not completely clear if this is intended to describe the current resources allocated to t= he PeerConnection or the potential resources that could be allocated (i.e.,= the full set of available codecs and capabilities).=C2=A0 It is similarly = unclear for case 2) if the offer is to be changed and how.

=C2=A0

The last sentence of the second paragraph of section 5.= 1.1 is also inconsistent with the last paragraph of the section and it is n= ot clear which one takes precedence.

=C2=A0

This potential inconsistency in the behavior of createO= ffer is problematic to an application since the range of capabilities refle= cted in the SDP is state dependent. =C2=A0The result of createOffer should not depend on whether the browser w= as previously offerer or answerer and it should be possible to request eith= er current capabilities or the complete list of potential capabilities for = each unchanged m line in the offer using the constraints parameter.

=C2=A0

I was asked during the interim to justify the need for = a =E2=80=9Cfull=E2=80=9D offer as compared to an offer that just reflects t= he current capabilities. =C2=A0There are many examples in SIP where a node is sent an =E2=80=9Cempty re-INVITE=E2=80=9D or a =E2= =80=9CREFER with REPLACES=E2=80=9D during a session to trigger the node to = send a new SDP offer to renegotiate media. =C2=A0This may be triggered due = to an interface change, a network server (e.g., acting as B2BUA) moving the media to another endpoint such as a conference server, etc. =C2=A0In a= ll these cases there is no guarantee that the new target will support the s= ame codecs or have the same capabilities, so the best way forward is to cre= ate a =E2=80=9Cfull=E2=80=9D offer to make it most likely that an acceptable media configuration can be achieved in a single offer/a= nswer transaction. =C2=A0There are other cases where it may be acceptable t= o send a =E2=80=9Cminimal=E2=80=9D offer, but only the application can dete= rmine which one is needed.

=C2=A0

The 3rd paragraph of 5.1.2 says that createA= nswer should also reflect the =E2=80=9Ccurrent state=E2=80=9D of the system= . =C2=A0It is very confusing to use the same words to describe createOffer and createAnswer since they should not mean the sa= me thing. =C2=A0The text should be clarified to distinguish between these t= wo cases.

=C2=A0

There is a great need for a new section (possibly a sub= section of 4) that describes the relationship between MediaStreams and medi= a lines. =C2=A0An rtcweb MediaStream is not the same as an RFC 3264 media stream, thus causing endless potentia= l for confusion (I admit to being one of the victims). =C2=A0An RFC 3264 me= dia stream is more akin to a MediaStreamTrack, and even that is not complet= ely accurate since we will allow multiple MediaStreamTracks per m line. =C2=A0How does the browser decide how to all= ocate MediaStreamTracks to m lines? =C2=A0The easy solution is to assign ea= ch track to a separate m line but this is wasteful when multiple tracks car= ry the same media type. =C2=A0But not all tracks of the same media type should be forced to use the same m line since it ma= y be necessary to negotiate different capabilities for these tracks.=C2=A0 = It must somehow be made clear to the browser which tracks can be combined o= n an m line and which cannot so that it can generate an appropriate offer with the proper number of m lines.=

=C2=A0

In section 5.1.4, it should be pointed out that the nee= d to support both old and new local descriptions means that the PeerConnect= ion must in some sense be =E2=80=9Ccloned=E2=80=9D since there may be completely different remote candidates and codecs selec= ted for use with the new description and both configurations need to be sim= ultaneously supported for an interim period. =C2=A0It is also not explained= how to remove the new configuration if the 2nd offer/answer fails. =C2=A0I do not think that the st= ate diagram supports a transition from offer state or pranswer state back t= o stable state without processing a valid answer.=C2=A0 Note this is also a= nother implicit meaning of pranswer that should be described for subsequent offer/answer transactions =E2=80=93 both the o= ld and new configurations need to be supported until receipt of final answe= r or failure is indicated.

=C2=A0

Sections 5.1.6 and 5.1.7 should clarify the relationshi= p between the local/remote description and the actual resources allocated. = =C2=A0One of them usually reflects the configured resources while the other is generally a superset.=C2=A0 If= this is not the intended semantic, then that should also be clarified.<= /u>

=C2=A0

In section 5.2, I believe the RTP header extension attr= ibute in RFC 5285 is a=3Dextmap rather than a=3Drtphdr-ext.=

=C2=A0

Richard


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


--00248c71181537fe6004c5c481f9-- From salvatore.loreto@ericsson.com Fri Jul 27 06:20:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6C321F85DB for ; Fri, 27 Jul 2012 06:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEwGg5isj1eF for ; Fri, 27 Jul 2012 06:20:01 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E62421F841D for ; Fri, 27 Jul 2012 06:20:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-a3-5012957f1df3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 32.DB.07365.F7592105; Fri, 27 Jul 2012 15:19:59 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Fri, 27 Jul 2012 15:19:59 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2401D2478 for ; Fri, 27 Jul 2012 16:19:59 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A382B533E4 for ; Fri, 27 Jul 2012 16:19:59 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5BD8F533D8 for ; Fri, 27 Jul 2012 16:19:59 +0300 (EEST) Message-ID: <5012957E.2060405@ericsson.com> Date: Fri, 27 Jul 2012 16:19:58 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5007F6AB.5000705@ericsson.com> In-Reply-To: <5007F6AB.5000705@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvrW79VKEAg10XNS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp5VM1kLZkpUrJw+kamBcb1QFyMnh4SAicT7huNsELaYxIV7 64FsLg4hgVOMEjvnz2eCcDYwSnzrvMkK4VxklHi35gIrSIuQwBFGiZUznSDss4wSR94pgNi8 AtoSP7/vZO5i5OBgEVCV2HlLHCTMJmAm8fzhFrCwqECyxN//6RDVghInZz5hAbFFBIQltr7q ZQKxhQUsJBpff2WCmF4gMe/GGbAaTgEdiUnzL4LZzAK2EhfmXIey5SW2v53DDPGMmsTVc5uY IXq1JHrPdjJNYBSZhWTdLCTts5C0L2BkXsUonJuYmZNebqiXWpSZXFycn6dXnLqJERjeB7f8 1t3BeOqcyCFGaQ4WJXFerqT9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYJ9/4U1YkZKCo Ju1buW9xy0Gj1TwbvV6dXqquWFr5surYHYObJ/VDN3KHNc9mag96w/RT71zMt8rb+9cv7LV8 O+ub0f7AhS/WpJ41DTWS/1GQduiH9ftN2nr22jGvmJUENH4Kmq87ZqZU02K1Zq8Ji1vy2/6q L55bfH9OT06JqI7Qem3Ecj5TiaU4I9FQi7moOBEAqg954T0CAAA= Subject: Re: [rtcweb] Proposed new milestones for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:20:02 -0000 I agree with Stefan, I would suggest March 2013 or even earlier as timeline for the Data On 7/19/12 2:59 PM, Stefan Hakansson LK wrote: > This looks reasonable to me. The possible exception would be: I think > the data parts could be earlier (given that the media stuff can be > delivered as proposed - 4 months extra for the data seems a bit much). > > Stefan > > On 07/18/2012 09:08 PM, Ted Hardie wrote: >> As folks know, we are behind on our milestones. The following >> milestones represent a proposal from me and Magnus, based on some text >> from Cullen. Please review in light of our deliverable list: >> >> 1. Define the communication model in detail, including how session >> management is to occur within the model. >> >> 2. Define a security model that describes the security and privacy >> goals and specifies the security protocol mechanisms necessary >> to achieve those goals. >> >> 3. Define the solution - protocols and API requirements - for >> firewall and NAT traversal. >> >> 4. Define which media functions and extensions shall be supported in >> the client and their usage for real-time media, including media >> adaptation to ensure congestion safe usage. >> >> 5. Define what functionalities in the solution, such as media codecs, >> security algorithms, etc., can be extended and how the >> extensibility mechanisms works. >> >> 6. Define a set of media formats that must or should be supported by >> a client to improve interoperability. >> >> 7. Define how non media data is transported between clients in a >> secure and congestion safe way. >> >> 8. Provide W3C input for the APIs that comes from the communication >> model and the selected components and protocols that are part of >> the solution. >> >> 9. The group will consider options for interworking with legacy VoIP >> equipment. >> >> Timeline: >> >> Sep 2012 - Send Use Cases document to IESG for publication as Informational >> Sep 2012 - Complete Overview (and hold for dependency resolution) >> Sep 2012 - Send Security and Privacy Problem Statement to IESG for >> publication as Informational >> >> Jan 2013 - Send Signalling Negotiation and NAT Traversal to IESG for >> publication as Proposed Standard >> Jan 2013 - Send Security Solution to IESG for publication as Proposed Standard >> Jan 2013 - Send Media Transport, Media Processing, and Codecs to >> IESG for publication as Proposed Standard >> >> May 2013 - Send Data Stream Transport for non-media data to IESG for >> publication as Proposed Standard >> >> Comments, please! >> >> Ted >> _______________________________________________ >> 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 martin.thomson@gmail.com Fri Jul 27 16:40:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2BD21F866C for ; Fri, 27 Jul 2012 16:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRzmdQheG6zT for ; Fri, 27 Jul 2012 16:40:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEE5D21F866A for ; Fri, 27 Jul 2012 16:40:49 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2630923lbb.31 for ; Fri, 27 Jul 2012 16:40:48 -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=jRblj/Oz3UucmjI+mxc81mG+t/RuMc4fEicbyo6pr4E=; b=gJaHaXuIPj4PAbsbFWUIO3Jv95+qQld/8kAGC8p8CplRj5rpKgYrlLDurNNbFI7jFl MlXrmFkqJ912c0QS13rySZTmxGPKPLpq9KtWTvzmi99FH1uCRUaRz+pqTliP454NcxUj TdwBPDtlCFHAwTLVGIHXwR5yb6CAVHXj99rZnBjS5mPYd+96wkdx4EWIm6E8PsNbwnSq RjRGA78bOriDrgoSAjtGn6KrOv7uU+fOLtSvXABGJXMwN9O1WBRBhdUmVk6f4djJfQaY D1BKkstKIOJ/eAcfWJkH8fifvCCT13Va+OTbE3cwKG7vte49B8UWun0VduzxhGtXm1WU TYaw== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr4205417lab.29.1343432448831; Fri, 27 Jul 2012 16:40:48 -0700 (PDT) Received: by 10.112.82.1 with HTTP; Fri, 27 Jul 2012 16:40:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Jul 2012 16:40:48 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 23:40:50 -0000 On 18 July 2012 12:48, Ted Hardie wrote: > A draft agenda has been posted at: > http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb > > Edits and adjustments still possible; comments to the list. 5 minutes explaining http://tools.ietf.org/html/draft-thomson-rtcweb-api-reqs-00 would go a long way. From ted.ietf@gmail.com Sat Jul 28 09:00:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645B121F8623 for ; Sat, 28 Jul 2012 09:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7cN3Xmhz-rt for ; Sat, 28 Jul 2012 09:00:39 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAA721F85F2 for ; Sat, 28 Jul 2012 09:00:39 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2451800wgb.13 for ; Sat, 28 Jul 2012 09:00: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=3+0p6tiqX0xjPjnUgJj/l2/LJS8xhsKeRoW3v57c9mU=; b=jkk/COwcPbotK5r2ujZ/lKUjaG+MQJKWc9VVurIAe4xFVtE2vAx3aRMj0Wxvx5bHE9 gI+tfPyY5R8kDBOZxcE7C/LCsnQdx4LZdiyIeOAMki6uweHCMaOIpT/yXGxu7xCVnBk6 cSZX80ya6xWrk3nFaQAlRZ3M4mm9RnH0x7rx6+B6/6CjfWCJMii+7OBUDSxkw078t+bP 4QS+onWAtLo5BW/w7rOrvvOlvETyY6d1BnDMXzAwOVtqIh/PvUlEDj2C4uRvL64SUtsh ZqPo1/0rlj62OoTJFAJwfR5rm4AMb8Yzamk2soFrmAY3yoL5RHi2tHpSwcCSZBZ490zb JdgA== MIME-Version: 1.0 Received: by 10.180.79.69 with SMTP id h5mr14257917wix.6.1343491233228; Sat, 28 Jul 2012 09:00:33 -0700 (PDT) Received: by 10.216.90.134 with HTTP; Sat, 28 Jul 2012 09:00:33 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Jul 2012 09:00:33 -0700 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 16:00:40 -0000 Hi Martin, The last exchange I saw between you and Magnus about this seemed to result in agreement that this was primarily about the W3C end of the spectrum, essentially arguing that it start work on a low-layer API (unless I miss which bit of our architecture "application" in your draft is meant to cover). Did I miss a set of exchanges between you and Magnus that came to a different conclusion? regards, Ted On Fri, Jul 27, 2012 at 4:40 PM, Martin Thomson wrote: > On 18 July 2012 12:48, Ted Hardie wrote: >> A draft agenda has been posted at: >> http://www.ietf.org/proceedings/84/agenda/agenda-84-rtcweb >> >> Edits and adjustments still possible; comments to the list. > > 5 minutes explaining > http://tools.ietf.org/html/draft-thomson-rtcweb-api-reqs-00 would go a > long way. From martin.thomson@gmail.com Sat Jul 28 09:44:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E88121F865D for ; Sat, 28 Jul 2012 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wIoocjMMWOf for ; Sat, 28 Jul 2012 09:44:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1B21F865C for ; Sat, 28 Jul 2012 09:44:40 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2916178lbb.31 for ; Sat, 28 Jul 2012 09:44: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=8LQ/+8r7fIKUKdzPR2773tKgr8MDL/ZtlLwxSnGsOOY=; b=YWs01xwpzDyL7Rn5QfcvoQ6jbwXxR7wkLIv3NWFJ1jnG0+TK+gUysqeiY2XsAJKMpK bdykqk5WJVR6ohuQmXGwk7EQGIM6eizYcPnDPZKzWZBRi/7iPGlh2NyT7xdkKBQXa/Vn Y9c+KSJqU7dPKxaBMfMepW7iiH1k5Fcr7nwY3fns1aYpaFLrAWTGroIk9IZyVCXVSPv3 fBl+Q91Og3ZdNQYIF4Q4zP51e78keDgkhrdZZYU1L2X9sKdhYfnhPaVhJ3lSMWjSqdM+ hdDtmn6TDIP2gN9qH2G1jcIHoaYu+GEdpY2h2UwLaLjQxqg32XEDTr/8s7utMWsJldtQ E2Og== MIME-Version: 1.0 Received: by 10.112.49.227 with SMTP id x3mr3020134lbn.73.1343493879327; Sat, 28 Jul 2012 09:44:39 -0700 (PDT) Received: by 10.112.82.1 with HTTP; Sat, 28 Jul 2012 09:44:39 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Jul 2012 09:44:39 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 16:44:41 -0000 On 28 July 2012 09:00, Ted Hardie wrote: > The last exchange I saw between you and Magnus about this seemed to > result in agreement that this was primarily about the W3C end of the > spectrum, essentially arguing that it start work on a low-layer API That was Magnus' inference, yes. But not the intent of the draft. There is no argument for a "low-layer API" in the document, regardless of what anyone might infer. This is just an alternative description of the communication model developed in this working group. 5 minutes to explain would probably go a long way to deal with these concerns. From harald@alvestrand.no Sat Jul 28 10:49:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BB921F8655 for ; Sat, 28 Jul 2012 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.282 X-Spam-Level: X-Spam-Status: No, score=-110.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9jZ1WpBWug2 for ; Sat, 28 Jul 2012 10:49:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 635B521F865F for ; Sat, 28 Jul 2012 10:49:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A78CD39E115 for ; Sat, 28 Jul 2012 19:49:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktQ0BpvozZoF for ; Sat, 28 Jul 2012 19:49:42 +0200 (CEST) Received: from [IPv6:2001:df8:0:80:221:6aff:fe8f:cf14] (unknown [IPv6:2001:df8:0:80:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DA1AD39E062 for ; Sat, 28 Jul 2012 19:49:41 +0200 (CEST) Message-ID: <50142641.8020208@alvestrand.no> Date: Sat, 28 Jul 2012 10:49:53 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 17:49:48 -0000 On 07/28/2012 09:44 AM, Martin Thomson wrote: > On 28 July 2012 09:00, Ted Hardie wrote: >> The last exchange I saw between you and Magnus about this seemed to >> result in agreement that this was primarily about the W3C end of the >> spectrum, essentially arguing that it start work on a low-layer API > That was Magnus' inference, yes. But not the intent of the draft. > There is no argument for a "low-layer API" in the document, regardless > of what anyone might infer. This is just an alternative description > of the communication model developed in this working group. Martin, if there is an alternative description of the communication model developed by RTCWeb in the document, I missed it. The description (page 2 and 3) seems to me to be totally isomorphic to the current -overview document, and most of the document (page 4 to 9) is API requirements, which don't describe any model. > > 5 minutes to explain would probably go a long way to deal with these concerns. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Sat Jul 28 19:45:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44F21F86DB for ; Sat, 28 Jul 2012 19:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIPa1ZxpaVeu for ; Sat, 28 Jul 2012 19:45:17 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF33321F86D4 for ; Sat, 28 Jul 2012 19:45:16 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2610686wgb.13 for ; Sat, 28 Jul 2012 19:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7bNPU/5l+5dIlqSSKcCkPSjPVPIH9fl89/m3evYyThE=; b=F/NFUskeiF92e1aYCAfYkxg/MJf4CiLQ+2M6OeSn52dU/YVqbU+qWE3X/lkX9Gn+Th 9GkywTaNuc3AC5Pe6P+vgUiOGJm5gyaOgkjcDvAWIkwuxu0i9JrI+8FiEwOA78tqS9oW S7j0LYasbifHNAC33Q4Vyyw9/KP5WUHals3PRoYoBINnx6emlqzWVijkuOEX5GWpdh4t ubiJ8htbGwnR9NlzUFfEocBQZUNVgr5DjURwcGfbSOn/XiAEALmzq9Oa5xDMsJSV+dad w5OGQwNp4wVb/cnH8aJv880IZlRRs6C0GjH/71kNbVNcYZ+XAR3qyAz9arA7BXxLoNzx ATvw== MIME-Version: 1.0 Received: by 10.216.144.234 with SMTP id n84mr3603956wej.78.1343529916075; Sat, 28 Jul 2012 19:45:16 -0700 (PDT) Received: by 10.180.98.37 with HTTP; Sat, 28 Jul 2012 19:45:15 -0700 (PDT) In-Reply-To: <50142641.8020208@alvestrand.no> References: <50142641.8020208@alvestrand.no> Date: Sat, 28 Jul 2012 19:45:15 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 02:45:18 -0000 On 28 July 2012 10:49, Harald Alvestrand wrote: > Martin, if there is an alternative description of the communication model > developed by RTCWeb in the document, I missed it. The description (page 2 > and 3) seems to me to be totally isomorphic to the current -overview > document, and most of the document (page 4 to 9) is API requirements, which > don't describe any model. Sorry, I should have said that this is our conclusions on the requirements that arise from this model. From juberti@google.com Sun Jul 29 17:14:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A978111E8072 for ; Sun, 29 Jul 2012 17:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOQTUIKAbvJI for ; Sun, 29 Jul 2012 17:14:52 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C579821F85D0 for ; Sun, 29 Jul 2012 17:14:51 -0700 (PDT) Received: by qaea16 with SMTP id a16so606766qae.10 for ; Sun, 29 Jul 2012 17:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=s4nnOVi2p76LETB36ya/Jvm7Z/X2xGlWeDdU8ibtnGA=; b=DG/ZtL//8JEzeB2/OkyRILie9O3Hz4sLF9XW4qnFgLyBX/l2P5CRAfC7bBZT4LXUz6 EXfQhMWN+6runOLMa7lPb2mgdpXF8reBMx8Eau9thFOdgncwlzBSGvBP4+VK86C3UHBn MemtHJm/X0Hbu1QdN14/Hs2bIt2sFPx2u7hjDusrK3JnWtzFP/D26OMbJnGl86JETd5E +EzS6Xix1gMYebyUvyDw2llFgO2eCn3FjdkO/OAaN6j56jZu11Mio/rAvE87QDPZ5n4V W6O218TV8GROkJp7RNPrefp0Ap9Hq17k/c2tNSvJDdgv9T1cNgjsgpLDcYxc7/JO5EZe LysQ== X-Google-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 :x-system-of-record:x-gm-message-state; bh=s4nnOVi2p76LETB36ya/Jvm7Z/X2xGlWeDdU8ibtnGA=; b=N4LCGllaZhSyMmHPOL1D1Vf9Lykt7p4KZhLzTmwRBJSrrKhi0B5G2NQ+CjO6Aq1en6 aHLan4TKtysvS3cLl5mYFXkEx0Ebas/GR34MA9yxeIecY7xFMMJIjRdkrKP20rKEswAW IMGhH3inEgrF4ZdMdvY/KdjIjKgvGCVQ/Ek3ET58iw8oIu/W5lmnzmrNuSVp2dCu2oRl sURUO4Ner+9Lc8H4IyM/pzCUGU/iuh2mI10k/ivzg99SvWXt9z/anQkyOe1B13GnXQ8u 5e3JPHcqSJtRoPK+t3nJnXEQARQxSb3ymzOwQFDZRdgIs4wEjlrEAGDhJmVGofjOEIGI Kong== Received: by 10.224.178.73 with SMTP id bl9mr20383619qab.89.1343607291030; Sun, 29 Jul 2012 17:14:51 -0700 (PDT) Received: by 10.224.178.73 with SMTP id bl9mr20383604qab.89.1343607290828; Sun, 29 Jul 2012 17:14:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.59.66 with HTTP; Sun, 29 Jul 2012 17:14:30 -0700 (PDT) From: Justin Uberti Date: Sun, 29 Jul 2012 17:14:30 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf302ef79c4998b004c600f377 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkz4SlFRvs6uzK7wD7IM90lOtEunmyR9laRC/fL3HcpL9BbZ+lngfx1o7jNYESjKhDcTvhCdG8LV3GnYoICYEI7LyeaNnwTq63vxisiWHyp6NFiLEE+IL6KGp2b+wzdhI4Oc1Awf0mIWePBWEvZi77rCwOzUvmVvVhXeOyPvu6ekDI+ST4= Cc: Harald Alvestrand Subject: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 00:14:52 -0000 --20cf302ef79c4998b004c600f377 Content-Type: text/plain; charset=UTF-8 We believe that the WebRTC effort represents an unprecedented opportunity to establish a new real-time communications platform. Like the web platform, it is built on freely available components, providing state-of-the-art quality to all developers, big or small, with no need for technology licensing. This approach has worked wonders for the web, and we hope for the same result with WebRTC. Therefore, we believe the sole mandatory-to-implement video codec in WebRTC should be VP8, the only viable royalty-free option. We believe it provides superior quality, which is why we are increasingly using it in our own products. We are also strongly committed to the future of VP8; we continue to invest heavily in its development, and we have a clear record of vigorously defending our technology. On the audio side, we believe that Opus should be the default mandatory-to-implement audio codec, assuming the remaining licensing issues can be resolved. Opus delivers excellent quality, from narrowband to fullband, for streaming and realtime, making it an ideal choice for a baseline codec. We also recommend that G.711 be mandatory, for compatibility with the vast universe of PSTN equipment. Given the ability to deliver a royalty-free platform with no compromises on quality, we see no reason to include mandatory royalty-bearing codecs. --20cf302ef79c4998b004c600f377 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We believe that the WebRTC effort represents an unprecedented opportu= nity to establish a new real-time communications platform. Like the web pla= tform, it is built on freely available components, providing state-of-the-a= rt quality to all developers, big or small, with no need for technology lic= ensing. This approach has worked wonders for the web, and we hope for the s= ame result with WebRTC.

=
Therefore, = we believe the sole mandatory-to-implement video codec in WebRTC should be = VP8, the only viable royalty-free option. We believe it provides superior q= uality, which is why we are increasingly using it in our own products. We a= re also strongly committed to the future of VP8; we continue to invest heav= ily in its development, and we have a clear record of vigorously defending = our technology.

On the audio side, we believe that Opus should be= the default mandatory-to-implement audio codec, assuming the remaining lic= ensing issues can be resolved. Opus delivers excellent quality, =C2=A0from = narrowband to fullband, for streaming and realtime, making it an ideal choi= ce for a baseline codec. We also recommend that G.711 be mandatory, for com= patibility with the vast universe of PSTN equipment.

=
Given the abilit= y to deliver a royalty-free platform with no compromises on quality, we see= no reason to include mandatory royalty-bearing codecs.

--20cf302ef79c4998b004c600f377-- From tterriberry@mozilla.com Sun Jul 29 17:27:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A2711E80DC for ; Sun, 29 Jul 2012 17:27:53 -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=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjwD1rLQdclR for ; Sun, 29 Jul 2012 17:27:52 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id B66FC11E8072 for ; Sun, 29 Jul 2012 17:27:52 -0700 (PDT) Received: from [10.244.29.142] (unknown [64.213.70.194]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9D0B0F2CD4 for ; Sun, 29 Jul 2012 17:27:50 -0700 (PDT) Message-ID: <5015D506.5010201@mozilla.com> Date: Sun, 29 Jul 2012 17:27:50 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 00:27:53 -0000 Justin Uberti wrote: > Given the ability to deliver a royalty-free platform with no compromises > on quality, we see no reason to include mandatory royalty-bearing codecs. +1 As Brendan Eich, Mozilla's CTO, outlined in his article https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ back in March, we believe very strongly in keeping WebRTC unencumbered. From lorenzo@meetecho.com Sun Jul 29 18:34:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBADA21F8608 for ; Sun, 29 Jul 2012 18:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iY3jcO9FGs+P for ; Sun, 29 Jul 2012 18:34:50 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out18.aruba.it [62.149.158.58]) by ietfa.amsl.com (Postfix) with SMTP id 71A2421F8607 for ; Sun, 29 Jul 2012 18:34:49 -0700 (PDT) Received: (qmail 1614 invoked by uid 89); 30 Jul 2012 01:34:44 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq04.aruba.it with SMTP; 30 Jul 2012 01:34:44 -0000 Received: (qmail 11738 invoked by uid 89); 30 Jul 2012 01:34:44 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@130.129.23.208) by smtp3.ad.aruba.it with SMTP; 30 Jul 2012 01:34:44 -0000 Date: Mon, 30 Jul 2012 03:34:30 +0200 From: Lorenzo Miniero To: "Timothy B. Terriberry" Message-ID: <20120730033430.4880aa35@lminiero-acer> In-Reply-To: <5015D506.5010201@mozilla.com> References: <5015D506.5010201@mozilla.com> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 01:34:50 -0000 Il giorno Sun, 29 Jul 2012 17:27:50 -0700 "Timothy B. Terriberry" ha scritto: > Justin Uberti wrote: > > Given the ability to deliver a royalty-free platform with no > > compromises on quality, we see no reason to include mandatory > > royalty-bearing codecs. > > +1 > > As Brendan Eich, Mozilla's CTO, outlined in his article > https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ back > in March, we believe very strongly in keeping WebRTC unencumbered. +1 Lorenzo > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From mdr@reavy.org Sun Jul 29 18:44:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D393111E80F9 for ; Sun, 29 Jul 2012 18:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRvhiYEsTz4p for ; Sun, 29 Jul 2012 18:44:33 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2C03511E80F6 for ; Sun, 29 Jul 2012 18:44:33 -0700 (PDT) Received: from static-68-179-67-73.ptr.terago.net ([68.179.67.73] helo=[10.244.29.137]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Svf29-0005Ux-3M for rtcweb@ietf.org; Sun, 29 Jul 2012 20:44:33 -0500 Message-ID: <5015E6FF.2000804@reavy.org> Date: Sun, 29 Jul 2012 18:44:31 -0700 From: Maire Reavy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5015D506.5010201@mozilla.com> In-Reply-To: <5015D506.5010201@mozilla.com> Content-Type: multipart/alternative; boundary="------------050101040509030506060201" 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 - reavy.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 01:44:33 -0000 This is a multi-part message in MIME format. --------------050101040509030506060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/29/2012 5:27 PM, Timothy B. Terriberry wrote: > Justin Uberti wrote: >> Given the ability to deliver a royalty-free platform with no compromises >> on quality, we see no reason to include mandatory royalty-bearing >> codecs. > > +1 > > As Brendan Eich, Mozilla's CTO, outlined in his article > https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ back > in March, we believe very strongly in keeping WebRTC unencumbered. Absolutely! And that stance hasn't changed. Mandating encumbered codecswould force open-source projects to violate the spec (by not implementing a mandatory codec). For this reason and the reasons Justin cites, we believe Opus, G.711 and VP8 are the best mandatory-to-implement choices for the spec. -- Maire Reavy , _ _ Mozilla --------------050101040509030506060201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/29/2012 5:27 PM, Timothy B. Terriberry wrote:
Justin Uberti wrote:
Given the ability to deliver a royalty-free platform with no compromises
on quality, we see no reason to include mandatory royalty-bearing codecs.

+1

As Brendan Eich, Mozilla's CTO, outlined in his article https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ back in March, we believe very strongly in keeping WebRTC unencumbered.

Absolutely!  And that stance hasn't changed.

Mandating encumbered codecs would force open-source projects to violate the spec (by not implementing a mandatory codec).  For this reason and the reasons Justin cites, we believe Opus, G.711 and VP8 are the best mandatory-to-implement choices for the spec.

-- 
Maire Reavy <mreavy@mozilla.com>, <mdr@reavy.org> 
Mozilla

--------------050101040509030506060201-- From giles@thaumas.net Sun Jul 29 20:13:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD9C11E80CC for ; Sun, 29 Jul 2012 20:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35nPWg-X3iiH for ; Sun, 29 Jul 2012 20:13:46 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0B1211E8088 for ; Sun, 29 Jul 2012 20:13:45 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so9013869pbc.31 for ; Sun, 29 Jul 2012 20:13:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=qL41/0gLhgcddA/mHEx4xaZ2A3nmfw/QBPnfXRXNo+k=; b=XxmHhUqWbojQzILYGkXhDlzF13NsxaFJnN5Hvr1SOWOMlUPDQ0nOkM2jnT8Sv/ojed f0R6RH+jjeB8R3XClF2ORClHWc0RdWkGaO26DdoFyDkaFARtPoPG9peHuFHZam5E9coa Mz8hVnm2EOA9aWY5pXZY4RGQlXqnfpRgEnnCRtxpIRIY/uEUtrefG2kV9KRmQMwB9oGz M0WnwZo3FjPCqhF52nqJMzt7GCu+KqbhuhP3rW022olVQq/rDEixDNk1E4CbmEzb+V7V nVSnoj49K9uyedwrSKKdWShdgaiTEM2JZz4bss3qFZDvLp3MUIM6wQqTnKligtNYQWpz KxMA== Received: by 10.68.218.162 with SMTP id ph2mr31388917pbc.114.1343618025760; Sun, 29 Jul 2012 20:13:45 -0700 (PDT) Received: from glaucomys.lan ([207.6.217.65]) by mx.google.com with ESMTPS id ql3sm6945603pbc.72.2012.07.29.20.13.44 (version=SSLv3 cipher=OTHER); Sun, 29 Jul 2012 20:13:44 -0700 (PDT) Message-ID: <5015FBE7.9060809@thaumas.net> Date: Sun, 29 Jul 2012 20:13:43 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> In-Reply-To: <5015E6FF.2000804@reavy.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkM/I2NdNp+bediTehRxxXJa+xWfwcW8pmzA53MKcwgKs/AW67TYAj4gKmEsl0rnPxR5bQu Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 03:13:46 -0000 On 12-07-29 6:44 PM, Maire Reavy wrote: > Mandating encumbered codecswould force open-source projects to violate > the spec (by not implementing a mandatory codec). For this reason and > the reasons Justin cites, we believe Opus, G.711 and VP8 are the best > mandatory-to-implement choices for the spec. +1 -r From cb.list6@gmail.com Sun Jul 29 20:14:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882B111E8088 for ; Sun, 29 Jul 2012 20:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OGI3rIWUHlB for ; Sun, 29 Jul 2012 20:14:42 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F07911E8104 for ; Sun, 29 Jul 2012 20:14:42 -0700 (PDT) Received: by lagv3 with SMTP id v3so3257000lag.31 for ; Sun, 29 Jul 2012 20:14: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:date:message-id:subject:from:to :cc:content-type; bh=LfU1VH4/L3c3arCPJMrstZ/wLFYastyB1SJJC7M7o+Y=; b=K4wGMXxFIBk0G/+/jxDSlCyBnzTZiPua0r+lcVBj1qKpGkLP5zwmeadOLaAw0c9TDp L81pmNlwtxm7UJAx5LBUbKyb4H/lixOyEP3uu+FM/JG5DRclhlX4JQ90nK3693aaFDyc XdHLy38HM3fRKGxHg1OxXEpn1V7b6oSI+f9f2LrpArLXRY5Xg/QBYRUlRO7auguWT6k/ 21U9xiFVN0TQ4GfQsDRxz1Gy5QzV+34gPpqy3c8qjWgB/5egDEI/YLCjrXkMh6ddqQyV gOzSynRZfgHaePpiaqpVdaiHicZQKHsicz/XSP30df6jUysDU/dziC02FJ527KtntatA fR7Q== MIME-Version: 1.0 Received: by 10.112.42.34 with SMTP id k2mr4692483lbl.0.1343618081426; Sun, 29 Jul 2012 20:14:41 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Sun, 29 Jul 2012 20:14:41 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Sun, 29 Jul 2012 20:14:41 -0700 (PDT) In-Reply-To: <5015FBE7.9060809@thaumas.net> References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> <5015FBE7.9060809@thaumas.net> Date: Sun, 29 Jul 2012 20:14:41 -0700 Message-ID: From: Cameron Byrne To: Ralph Giles Content-Type: multipart/alternative; boundary=485b390f7dae750e7e04c60376f8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 03:14:43 -0000 --485b390f7dae750e7e04c60376f8 Content-Type: text/plain; charset=ISO-8859-1 On Jul 29, 2012 8:13 PM, "Ralph Giles" wrote: > > On 12-07-29 6:44 PM, Maire Reavy wrote: > > > Mandating encumbered codecswould force open-source projects to violate > > the spec (by not implementing a mandatory codec). For this reason and > > the reasons Justin cites, we believe Opus, G.711 and VP8 are the best > > mandatory-to-implement choices for the spec. > > +1 > > -r > +1 CB > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --485b390f7dae750e7e04c60376f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 29, 2012 8:13 PM, "Ralph Giles" <giles@thaumas.net> wrote:
>
> On 12-07-29 6:44 PM, Maire Reavy wrote:
>
> > Mandating encumbered codecswould force open-source projects to vi= olate
> > the spec (by not implementing a mandatory codec). =A0For this rea= son and
> > the reasons Justin cites, we believe Opus, G.711 and VP8 are the = best
> > mandatory-to-implement choices for the spec.
>
> +1
>
> =A0-r
>

+1

CB

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

--485b390f7dae750e7e04c60376f8-- From randell-ietf@jesup.org Mon Jul 30 01:08:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB0A21F84C4 for ; Mon, 30 Jul 2012 01:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioyttroyC4Ff for ; Mon, 30 Jul 2012 01:08:02 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id DCFDA21F84C2 for ; Mon, 30 Jul 2012 01:08:02 -0700 (PDT) Received: from 216-19-183-223.dyn.novuscom.net ([216.19.183.223] helo=[192.168.0.101]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Svl1G-0001Ou-DI for rtcweb@ietf.org; Mon, 30 Jul 2012 03:08:02 -0500 Message-ID: <501640E3.1000009@jesup.org> Date: Mon, 30 Jul 2012 01:08:03 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120711 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> <5015FBE7.9060809@thaumas.net> In-Reply-To: <5015FBE7.9060809@thaumas.net> 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-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 08:08:03 -0000 On 7/29/2012 8:13 PM, Ralph Giles wrote: > On 12-07-29 6:44 PM, Maire Reavy wrote: > >> Mandating encumbered codecswould force open-source projects to violate >> the spec (by not implementing a mandatory codec). For this reason and >> the reasons Justin cites, we believe Opus, G.711 and VP8 are the best >> mandatory-to-implement choices for the spec. > +1 Not that anyone will be surprised, as I'm tech lead for WebRTC at Mozilla and point person on much of the IETF stuff for it, but +1 from me as well. Non-free MTI codecs would be a massive problem for Linux/BSD distros and other open source projects, as well as Mozilla. -- Randell Jesup randell-ietf@jesup.org From sergel@google.com Mon Jul 30 02:13:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B0721F871E for ; Mon, 30 Jul 2012 02:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.71 X-Spam-Level: X-Spam-Status: No, score=-100.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWg3GGGBOjbF for ; Mon, 30 Jul 2012 02:13:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA97E21F871C for ; Mon, 30 Jul 2012 02:13:38 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9975803obb.31 for ; Mon, 30 Jul 2012 02:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-system-of-record; bh=bG1z0O/Ztgm1Mw6lIcvtC4ecGUzh9Hwrw0NM9RXDC7c=; b=gruqyl4O+GGUZl/YmyFdQ+wUtrobRbSPT7+UAVYpLYpP+oS0h4F6Ggzk95m6jvmhz9 ZYIMUKfk0XUdQXUnsIlYOb+nThNAqtjDWgVPbIXvnjcw5lfgM0PWjMZ0QjXY7wBvtUQF jfDO0GdiqnEtMGDa98i0BXhwBoRY0ruD4jyYa0SewYUV8u7fqgKjyuwnqIid5e4B5nrj y6IwywJt32NYAGZ+XKvoEbwYaJVsqE2KkSws5gmNlERLqNHllf+uejkWDqPTiE56KqkX K3W0LAgzGHlNYeAu2pEe1x8SNdohL47o26IGIvZrDskE+wHkE5u74L571TUWqrYOd178 7yBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=bG1z0O/Ztgm1Mw6lIcvtC4ecGUzh9Hwrw0NM9RXDC7c=; b=MKF2/uHsoNArQ1ehs40QOozr1iEI6xXA0bQEAsLLsAiSIhn41oYfnLyK7C2xVyK5od 3zpXk2yF352GQExXzovpKWz8j9YGXk1G2Pxdp078ChhgXticL3v3s/w68NO0s0bg63G8 G1w1V2svpObFbtxpC9wLOey8ZVtc7OVoBJpkRse6LmGbB/P/IkPgVo5Edrgl8XcneiBl EsIWyECD5327LTOXA8BDaxSQiznXg/hGJ30TfvXmybaGRIPOCjVAQfoUQdvW3tLH/xiE 1XWHecxA2z4y8jcS/e9Rf21Jp3ooJT4PTVl7bVb2G4NizYVeJA70xko5x034b6x461Gh 9D9Q== Received: by 10.182.95.142 with SMTP id dk14mr16421186obb.2.1343639618363; Mon, 30 Jul 2012 02:13:38 -0700 (PDT) Received: by 10.182.95.142 with SMTP id dk14mr16421157obb.2.1343639618075; Mon, 30 Jul 2012 02:13:38 -0700 (PDT) MIME-Version: 1.0 Sender: sergel@google.com Received: by 10.182.80.37 with HTTP; Mon, 30 Jul 2012 02:13:06 -0700 (PDT) In-Reply-To: <501640E3.1000009@jesup.org> References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> <5015FBE7.9060809@thaumas.net> <501640E3.1000009@jesup.org> From: Serge Lachapelle Date: Mon, 30 Jul 2012 11:13:06 +0200 X-Google-Sender-Auth: D_o3nSBpWasP62hygt_SJJfCcnU Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=14dae93b5d2a243e1e04c6087a31 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmrEi6ePxWbZOSpZEfZUx8izuiywFjSreBR+SQuj4uMPCBUL2COiAYzoqL0hVqYaZDsD2wXpnfFIxZrTTw60YF7OwlIGdFHe9yNHYDlN/i99gAU+qQikA1NC2zveW/maJ8je/1KOkBWGRaFa2WomJlkw7JKGprAOlfQPy7mQLOnQ/CYr88= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 09:13:47 -0000 --14dae93b5d2a243e1e04c6087a31 Content-Type: text/plain; charset=ISO-8859-1 As the Product Manager for Chrome's WebRTC project and one of the instigators of the whole WebRTC concept (I even named it WebRTC because webrtc.org was available), I whole heartedly support Justin's statement. His statement reflects our whole team's commitment to a thriving communication platform, open for everyone. /Serge On Mon, Jul 30, 2012 at 10:08 AM, Randell Jesup wrote: > On 7/29/2012 8:13 PM, Ralph Giles wrote: > >> On 12-07-29 6:44 PM, Maire Reavy wrote: >> >> Mandating encumbered codecswould force open-source projects to violate >>> the spec (by not implementing a mandatory codec). For this reason and >>> the reasons Justin cites, we believe Opus, G.711 and VP8 are the best >>> mandatory-to-implement choices for the spec. >>> >> +1 >> > > Not that anyone will be surprised, as I'm tech lead for WebRTC at Mozilla > and point person on much of the IETF stuff for it, but +1 from me as well. > Non-free MTI codecs would be a massive problem for Linux/BSD distros and > other open source projects, as well as Mozilla. > > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > -- Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32 Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880 Apparently, this footer is required in Europe. Apologies. This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else,please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks. --14dae93b5d2a243e1e04c6087a31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As the Product Manager for Chrome's WebRTC project and one of the insti= gators of the whole WebRTC concept (I even named it WebRTC because webrtc.org was available), I whole heartedly sup= port Justin's statement.=A0

His statement reflects our whole team's commitment to a = thriving communication platform, open for everyone.

/Serge




--
=
Serge = Lachapelle=A0|=A0Product Manager=A0|=A0sergel@google.com=A0|=A0+46 732 01 22 32
Google = Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880=A0

App= arently, this footer is required in Europe. Apologies. This email may be co= nfidential or privileged. =A0If you received this communication by mistake,= please don't forward it to anyone else,please erase all copies and att= achments, and please let me know that it went to the wrong person. =A0Thank= s.
On Mon, Jul 30, 2012 at 10:08 AM= , Randell Jesup <randell-ietf@jesup.org> wrote:
On 7/29/2012 8:13 PM, Ralp= h Giles wrote:
On 12-07-29 6:44 PM, Maire Reavy wrote:

Mandating encumbered codecswould force open-source projects to violate
the spec (by not implementing a mandatory codec). =A0For this reason and the reasons Justin cites, we believe Opus, G.711 and VP8 are the best
mandatory-to-implement choices for the spec.
+1

Not that anyone will be surprised, as I'm tech lead for WebRTC at Mozil= la and point person on much of the IETF stuff for it, but +1 from me as wel= l. =A0Non-free MTI codecs would be a massive problem for Linux/BSD distros = and other open source projects, as well as Mozilla.<= font color=3D"#888888">

--
Randell Jesup
randell-ietf@je= sup.org


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
--14dae93b5d2a243e1e04c6087a31-- From lists@infosecurity.ch Mon Jul 30 02:15:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B52421F84B9 for ; Mon, 30 Jul 2012 02:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqbOid+ogM7E for ; Mon, 30 Jul 2012 02:15:33 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B710821F849B for ; Mon, 30 Jul 2012 02:15:32 -0700 (PDT) Received: by bkty7 with SMTP id y7so2765101bkt.31 for ; Mon, 30 Jul 2012 02:15:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=4/w7Ltd89d1wGtJXeMTv8cbYpINd6Zc/yxnJlt9x2Jg=; b=ZD+qlRGV+Rr4Fm513SjERolqB0DDsl2a3icgG8lhCeis86/ZH/+PvsSNHkaEr3mSRR wPGuEe4NRbJaFsTcDZYNUzO5lmoPrTBHy9/KJV4/TcpgSNWfNwEa1u1gesXTSxAZ+0lC GBRukQYDLxwtHq2Ro5EEUIwd4Hc+MEmOdwQux3eEbH3ywgLjbLJk6aFR5YBfbsavsE4g S4HYTYquLjct53IIWPvJrznGkGCi849JRNebFRQljhP1j24xZ+FhEziXIVFRWsBWFXlP crR4j7grMwuxstXVe7fLRd1+COyXFSncZPGlMgsiwR/JxYem14X4aMdkN+ARxbtoBgRf YAmQ== Received: by 10.204.152.27 with SMTP id e27mr3684320bkw.56.1343639731587; Mon, 30 Jul 2012 02:15:31 -0700 (PDT) Received: from sonyvaiop13.local (93-32-181-214.ip34.fastwebnet.it. [93.32.181.214]) by mx.google.com with ESMTPS id 14sm3293633bkq.12.2012.07.30.02.15.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 02:15:30 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <501650B0.6060308@infosecurity.ch> Date: Mon, 30 Jul 2012 11:15:28 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> <5015FBE7.9060809@thaumas.net> <501640E3.1000009@jesup.org> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmaU70hea9y1fbjNcSZt+a5k34oalTf0YyW3mJMiBjMxQyxuEjIi7iV1X8QnAYU+gDeCSRL Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 09:15:33 -0000 What's the Microsoft position on WebRTC in general? Are they going to dump/skip/sabotage-it or are they going to participate? If they will participate, will they try to leverage skype/msn codecs compatibility? Fabio On 7/30/12 11:13 AM, Serge Lachapelle wrote: > As the Product Manager for Chrome's WebRTC project and one of the > instigators of the whole WebRTC concept (I even named it WebRTC because > webrtc.org was available), I whole heartedly support > Justin's statement. > > His statement reflects our whole team's commitment to a thriving > communication platform, open for everyone. > > /Serge From likepeng@huawei.com Mon Jul 30 02:24:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3291321F8723 for ; Mon, 30 Jul 2012 02:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKOfHpvoSe+V for ; Mon, 30 Jul 2012 02:24:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 246A121F8738 for ; Mon, 30 Jul 2012 02:24:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIL67990; Mon, 30 Jul 2012 05:24:05 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 02:20:54 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 02:20:56 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 17:20:49 +0800 From: Likepeng To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-li-rtcweb-jsep-xmpp-mapping-00.txt Thread-Index: AQHNbiTIl1A6XHCWTUGcMhcvyZeTZ5dBi+Bw Date: Mon, 30 Jul 2012 09:20:48 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F207BD4A03@szxeml525-mbx.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.70.110.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] Fw: New Version Notification for draft-li-rtcweb-jsep-xmpp-mapping-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 09:24:07 -0000 V2VsY29tZSB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgZHJhZnQuDQoNCkhhdmUgYSBuaWNlIG1lZXRp bmcgaW4gVmFuY291dmVyIQ0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0N+aciDMw5pelIDE1 OjI3DQrmlLbku7bkuro6IExpa2VwZW5nDQrmioTpgIE6IExpa2VwZW5nDQrkuLvpopg6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5n LTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktcnRjd2ViLWpzZXAteG1w cC1tYXBwaW5nLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXBl bmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFm dC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmcNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFJU Q1dlYiBKU0VQIFhNUFAvSmluZ2xlIE1hcHBpbmcNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTMw DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTANClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt bGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAtbWFw cGluZw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s aS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDANCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3Vt ZW50IHByb3Bvc2VzIG1hcHBpbmcgbWVzc2FnZSByZXByZXNlbnRhdGlvbnMgYmV0d2VlbiBSVENX ZWINCiAgIEphdmFzY3JpcHQgU2Vzc2lvbiBFc3RhYmxpc2htZW50IFByb3RvY29sKEpTRVApIHNj aGVtZSBhbmQgWE1QUC8NCiAgIEppbmdsZSBbWEVQLTAxNjZdIG1lc3NhZ2luZyBzY2hlbWUuICBT dWNoIGEgc2lnbmFsaW5nIG1hcHBpbmcgaXMNCiAgIGludGVuZGVkIHRvIGVuYWJsZSBKYXZhc2Ny aXB0IHRvIHVzZSBYTVBQL0ppbmdsZSB0byBlc3RhYmxpc2ggYQ0KICAgc2Vzc2lvbiBiZXR3ZWVu IHR3byBSVENXZWIgZW5hYmxlZCBicm93c2Vycy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From bernard_aboba@hotmail.com Mon Jul 30 06:57:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0219B21F8741 for ; Mon, 30 Jul 2012 06:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP-gVhqAuycQ for ; Mon, 30 Jul 2012 06:57:50 -0700 (PDT) Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by ietfa.amsl.com (Postfix) with ESMTP id BF7E321F873C for ; Mon, 30 Jul 2012 06:57:49 -0700 (PDT) Received: from BLU401-EAS256 ([65.55.116.73]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 06:57:49 -0700 X-Originating-IP: [130.129.68.169] X-EIP: [K0NqQSwyWtbyDpfcLZkbgCnCWnty5HUB] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Mon, 30 Jul 2012 06:57:46 -0700 From: Bernard Aboba To: rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 30 Jul 2012 13:57:49.0479 (UTC) FILETIME=[4E168370:01CD6E5B] Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 13:57:52 -0000 VGhlcmUgYXJlIHNldmVyYWwgcmVhc29ucyB3aHkgaXQgd291bGQgYmUgaW1wcnVkZW50IHRvIHNl cmlvdXNseSBjb25zaWRlciBhIG5vbi1zdGFuZGFyZCBjb2RlYyBhcyBtYW5kYXRvcnktdG8taW1w bGVtZW50OgoKQS4gQ2hhbmdlIGNvbnRyb2wuIE5vcm1hdGl2ZWx5IHJlZmVyZW5jaW5nIGEgZG9j dW1lbnQgbm90IHVuZGVyIElFVEYgY2hhbmdlIGNvbnRyb2wgYXMgbWFuZGF0b3J5LXRvLWltcGxl bWVudCBtZWFucyB0aGF0IGEgY29yZSBhc3BlY3Qgb2YgdGhlIHN0YW5kYXJkIHdvdWxkIGJlIHN1 YmplY3QgdG8gY2hhbmdlIHdpdGhvdXQgSUVURiByZXZpZXcuCgpCLiBGUkFORCBzdGF0dXMuIFNE TyBJUFIgcG9saWNpZXMgKGFuZCBsZWdhbCBwcmVjZWRlbnRzKSBjb25mZXIgaW1wb3J0YW50IGJl bmVmaXRzIHRvIGRvY3VtZW50cyB0aGF0IGhhdmUgZ29uZSB0aHJvdWdoIGEgc3RhbmRhcmRzIHBy b2Nlc3MuIFdpdGhvdXQgdGhpcywgcG90ZW50aWFsIElQUiBjbGFpbXMgaGF2ZSBubyB1cHBlciBi b3VuZC4g From harald@alvestrand.no Mon Jul 30 08:05:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67221F8512 for ; Mon, 30 Jul 2012 08:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xNxkgtQdP4r for ; Mon, 30 Jul 2012 08:05:16 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 217B521F842B for ; Mon, 30 Jul 2012 08:05:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B658639E13F for ; Mon, 30 Jul 2012 17:05:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq-+73eIzeNB for ; Mon, 30 Jul 2012 17:05:14 +0200 (CEST) Received: from [192.168.16.104] (dhcp-442d.meeting.ietf.org [130.129.68.45]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C0FA039E058 for ; Mon, 30 Jul 2012 17:05:13 +0200 (CEST) Message-ID: <5016A2BA.9020505@alvestrand.no> Date: Mon, 30 Jul 2012 08:05:30 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 15:05:17 -0000 On 07/30/2012 06:57 AM, Bernard Aboba wrote: > There are several reasons why it would be imprudent to seriously consider a non-standard codec as mandatory-to-implement: > > A. Change control. Normatively referencing a document not under IETF change control as mandatory-to-implement means that a core aspect of the standard would be subject to change without IETF review. The last point is also true for any standard maintained by another standards body, but we tend to trust that those will not change arbitrarily. > > B. FRAND status. SDO IPR policies (and legal precedents) confer important benefits to documents that have gone through a standards process. Without this, potential IPR claims have no upper bound. To be precise, the SDO IPR policies confer important benefits in relation to the companies or individuals that were part of that SDO at the time of the standardization procedure. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From keith.drage@alcatel-lucent.com Mon Jul 30 08:08:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C599321F8809 for ; Mon, 30 Jul 2012 08:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.78 X-Spam-Level: X-Spam-Status: No, score=-109.78 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vykowj0LRCR4 for ; Mon, 30 Jul 2012 08:08:14 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id AA3A321F8687 for ; Mon, 30 Jul 2012 08:08:13 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6UF869c005645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Jul 2012 17:08:07 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 30 Jul 2012 17:07:46 +0200 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , "rtcweb@ietf.org" Date: Mon, 30 Jul 2012 17:07:45 +0200 Thread-Topic: [rtcweb] non-standard codecs Thread-Index: Ac1uW1Vw123CV0UiSYKQEgCIqES9EgABp4ww Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 15:08:14 -0000 There are several things here in this mail that many other standards organi= zations would find objectionable, if the statement "not under IETF change c= ontrol" is meant to apply to anything not produced by IETF.=20 There is nothing special about an RFC or indeed IETF in this respect. 1) The drafting rules for all standards organizations I know of make provis= ion for references to be of two types, of a reference to a specific version= or publication date, or of a reference to a more generic standard number. = As a result of this, prior versions of standards continue to be available, = sometimes with a better history of preservation that some of the earlier IE= TF RFCs. Therefore if IETF makes a reference to one of these specific versions, they= have complete control over change. They can either decide to update the re= ference at some point in the future or decide not to. It is the reference t= hat provides the change control, not the referenced document. This is exactly the same process they will have to go through if a referenc= ed RFC gets updated with improvements or corrections. The later version of = an RFC does not automatically apply. 2) While the IPR disclosure rules for IETF may be worded differently, they = are in general no different to any other standards organizations. IETF rule= s do not guarantee FRAND availability, nor do those of any other standards = organizations. IETF in making the reference needs to identity any known IPR and decide whe= ther that is a barrier to progressing the RFC with that reference or not. I= t has to do that whether it is an IETF reference or a reference elsewhere. Regards Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Bernard Aboba > Sent: 30 July 2012 14:58 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] non-standard codecs >=20 > There are several reasons why it would be imprudent to seriously consider > a non-standard codec as mandatory-to-implement: >=20 > A. Change control. Normatively referencing a document not under IETF > change control as mandatory-to-implement means that a core aspect of the > standard would be subject to change without IETF review. >=20 > B. FRAND status. SDO IPR policies (and legal precedents) confer important > benefits to documents that have gone through a standards process. Without > this, potential IPR claims have no upper bound. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From mary.ietf.barnes@gmail.com Mon Jul 30 09:01:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE611E80A2; Mon, 30 Jul 2012 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZMb63bC+WGJ; Mon, 30 Jul 2012 09:01:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD51811E8091; Mon, 30 Jul 2012 09:01:38 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3756685lbb.31 for ; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PId8U94hGEYbu5smaElfkBUjb1gvpuDGTWoqh9zUkwE=; b=r9iy1q1yXoxn/VCdB6qwt8oVHTTwJuEfMOnfn4NFb96x0Xm8VQuHv90LzQq2CWoBmM 9k4w2x7MY7UoUUJWbzqsQxXvmd86aEizyY4aOBW0pyNDL/ooaemoU4Qs740s29AOjC7+ tINCt5vkaa3b2G34PeCsVSK+yiXSpsuCXyq9C+5DBpvbZZN1YdaYyVHRi9cF6EZiyBk0 pEI1qTMeoLSXrZk7OcLlwTwb4SqXcjZ2N/XqfP3zYawE8Y7zhm3cQ3MxEqsXvoHS/kDj Eky7RYNfG++5LxD1a98Qyt71Ut7vFiBubdxE2MwoOMMHDXCH/JyOJ3ILFtpInokJgOQy z/0Q== MIME-Version: 1.0 Received: by 10.152.135.200 with SMTP id pu8mr11865796lab.8.1343664097632; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 11:01:37 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org, mmusic@ietf.org, avt@ietf.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d043745473ca27b04c60e2ddb Subject: Re: [rtcweb] Reminder: "Telepresence Tutorial" @ IETF-84 (Please RSVP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:01:52 -0000 --f46d043745473ca27b04c60e2ddb Content-Type: text/plain; charset=ISO-8859-1 Tutorial is in Georgia A. On Tue, Jul 10, 2012 at 6:37 PM, Mary Barnes wrote: > Hi all, > > Apologies to the many of you that are receiving this multiple times. > Unfortunately, the RAI list is not a superset of participants in WGs > that might be interested in this. Folks that aren't on the RAI list > might want to subscribe here: > https://www.ietf.org/mailman/listinfo/rai > > Please note the important update below with regards to (no) lunch. > > We are planning a lunchtime tutorial on Monday, July 30th. The > primary objective is to provide more background on telepresence as > well as an update of the work in CLUE to the broader RAI and IETF > community. This will hopefully facilitate the process of completing > the CLUE protocol work as it gets broader community review. > > Here's the proposed outline: > 1) Introduction to telepresence > 2) Example telepresence scenarios > 3) Introduction to the CLUE work > 4) High level introduction of framework > 5) One or two use cases as examples of how the CLUE framework is > realized - showing how existing protocols (e.g., SDP, RTP) are > integral to the solution along > with additional signaling for CLUE. > > We have reserved a room for around 50 and attendance will be FCFS, so > please RSVP by Friday, July 13th, 2012 (5pm Pacific) > http://www.doodle.com/mzu3nmdeehkxkiys > > **Important update*: * Please note that we do not have a sponsor for > lunch, thus folks will have to grab something before the tutorial (sorry, I > tried). However, we will have some cookies and veggies/fruit available so > folks will have something to munch. > > Please send any questions/comments to me (or to the CLUE WG mailing list) > rather than reply all. > > Regards, > Mary > CLUE WG co-chair > > --f46d043745473ca27b04c60e2ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tutorial is in Georgia A.=A0

On Tue, Jul = 10, 2012 at 6:37 PM, Mary Barnes <mary.ietf.barnes@gmail.com&= gt; wrote:
Hi all,

Apologies to the many of you that are receiving this multiple times.
Unfortunately, the RAI list is not a superset of participants in WGs
that might be interested in this. =A0Folks that aren't on the RAI list<= br> might want to subscribe here:
htt= ps://www.ietf.org/mailman/listinfo/rai
=
Please note the important update below= with regards to (no) lunch.=A0

We are planning a lunchtime tutorial on Monday, July 30th. =A0The
primary objective is to provide more background on telepresence as
well as an update of the work in CLUE to the broader RAI and IETF
community. =A0This will hopefully facilitate the process of completing
the CLUE protocol work as it gets broader community review.

Here's the proposed outline:
1) Introduction to telepresence
2) Example telepresence scenarios
3) Introduction to the CLUE work
4) High level introduction of framework
5) One or two use cases as examples of how the CLUE framework is
realized - showing how existing protocols (e.g., SDP, RTP) are
integral to the solution along
with additional signaling for CLUE.

We have reserved a room for around 50 and attendance will be FCFS, so =A0pl= ease RSVP by=A0Friday, July 13th, 2012 (5pm Pacific)
http:/= /www.doodle.com/mzu3nmdeehkxkiys

*Important= update*: =A0Please note that we do not have a sponsor for lunch, thus = folks will have to grab something before the tutorial (sorry, I tried). =A0= However, we will have some cookies and veggies/fruit available so folks wil= l have something to munch.=A0

Please send any questions/comments to me (or to the CLUE WG mai= ling=A0list) =A0rather than reply all.

Regards,
Mary
CLUE WG co-chair


--f46d043745473ca27b04c60e2ddb-- From stewe@stewe.org Mon Jul 30 09:27:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB2A21F858E for ; Mon, 30 Jul 2012 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR53vRsjpxBH for ; Mon, 30 Jul 2012 09:27:57 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id A8DFF21F857D for ; Mon, 30 Jul 2012 09:27:56 -0700 (PDT) Received: from mail25-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jul 2012 16:27:55 +0000 Received: from mail25-ch1 (localhost [127.0.0.1]) by mail25-ch1-R.bigfish.com (Postfix) with ESMTP id DEB1112013F; Mon, 30 Jul 2012 16:27:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI1432Izz1202h1082kzz1033IL8275dhz2fh2a8h668h839h944he5bhf0ah107ah) Received-SPF: pass (mail25-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail25-ch1 (localhost.localdomain [127.0.0.1]) by mail25-ch1 (MessageSwitch) id 1343665671978440_5050; Mon, 30 Jul 2012 16:27:51 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail25-ch1.bigfish.com (Postfix) with ESMTP id ECF503A00B4; Mon, 30 Jul 2012 16:27:51 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jul 2012 16:27:51 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.193]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0175.005; Mon, 30 Jul 2012 16:27:50 +0000 From: Stephan Wenger To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] non-standard codecs Thread-Index: AQHNbltVnEEltQX51kaUa/L9MQch/JdB7M4A//+howA= Date: Mon, 30 Jul 2012 16:27:49 +0000 Message-ID: In-Reply-To: <5016A2BA.9020505@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <327FCA50A00419439E3378C75A2C0EA4@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:27:57 -0000 Hi Harald, On 7.30.2012 08:05 , "Harald Alvestrand" wrote: >> >> B. FRAND status. SDO IPR policies (and legal precedents) confer >>important benefits to documents that have gone through a standards >>process. Without this, potential IPR claims have no upper bound. >To be precise, the SDO IPR policies confer important benefits in >relation to the companies or individuals that were part of that SDO at >the time of the standardization procedure. I would go even further: most SDO IPR policies confer important benefits in relation to patents and patent applications under control of a member of the SDO at the time of the standardization procedure. (It's, I believe, generally assumed now that FRAND commitments travel with the patent, just like a license. Meaning that a troll cannot expect non-FRAND licensing terms for a patent that, at some point in time, was owned by a legit SDO member. Many SDOs have updated their policy documents to ensure this, and there is also case law addressing this issue.) It's also worth noting that in video coding, most major industry players are actively involved in the FRAND-bearing standardization effort. That doesn't mean that there can't be any non-FRAND pledged patents reading on a video coding standard, but the likelihood is low compared to other areas of technology. All that doesn't help the open source industry, but it helps the rest of us. Stephan =20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From ted.ietf@gmail.com Mon Jul 30 09:50:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E68F11E811B for ; Mon, 30 Jul 2012 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTU1BRAi0+Pl for ; Mon, 30 Jul 2012 09:50:31 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04BE811E80E1 for ; Mon, 30 Jul 2012 09:50:30 -0700 (PDT) Received: by weyu54 with SMTP id u54so4186480wey.31 for ; Mon, 30 Jul 2012 09:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RIpUrph6yvw+39GDxakJkoFmrpdb2S9zUlEvRSdTqrc=; b=Whx1xzbSEAeatW+R4nOSCJHi8fvKp2VUXMEuZYF/j+rnOiYBvunkOq0FO1PPr0wJuC WkM7RHPtXTH8t9ZZfkMBBL/twQT9S/1w/0P2jXHXvkBNyWmZhP6x0Ap9XhumbwF7fdze XWw80NrkprYpukm0bSUu8olruGVu2Lfjaz89JJ/YFRrkn+WCupp5muqCA/rBe3FRRqTd N3iiP0YXYHgsynW5+bG46+I2tNpiDYfCxFoufhL8xrtUYs+7AZcXRGKQlGxXFGuNrcoG z0DZTfaM9O8jr12rKM5O5v1Ue6JVY11GMAOm6ajAkccWR36YamiDZ1UXUuhZjghCBW9l F83w== MIME-Version: 1.0 Received: by 10.216.138.13 with SMTP id z13mr5814752wei.65.1343667027706; Mon, 30 Jul 2012 09:50:27 -0700 (PDT) Received: by 10.216.90.134 with HTTP; Mon, 30 Jul 2012 09:50:27 -0700 (PDT) In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 09:50:27 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Fwd: Need volunteers for the NomCom X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:50:32 -0000 A reminder that the NomCom is still looking for volunteers for this very important IETF process. Ted ---------- Forwarded message ---------- From: NomCom Chair Date: Sun, Jul 29, 2012 at 8:22 PM Subject: Need volunteers for the NomCom To: Working Group Chairs We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participants in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org From dbenham@cisco.com Mon Jul 30 09:58:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B3C11E814E for ; Mon, 30 Jul 2012 09:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx+wjgiBUHq8 for ; Mon, 30 Jul 2012 09:58:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19211E8149 for ; Mon, 30 Jul 2012 09:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dbenham@cisco.com; l=12080; q=dns/txt; s=iport; t=1343667482; x=1344877082; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XvOO0azCvm2mhISrKV4L2ZrEdCJU/kkyBNnILlLZjMk=; b=iF7LwlniA6vCzunR33AlTSV5QpLV3/TjYxqZqUI+l21RdN+oj2rZWjtp FT5eYUYl3CRDG/zb2iF5UWIexi4Lv5jnw43bwMoghAygg6fNMaIs76Kxb tSRLjVoaBuyf572Ha54YNhmN/yH2vukp4UiNzbJ1oplufQqiie1D415Nl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJu8FlCtJXG9/2dsb2JhbABFgkqDKbJneYEHgiABAQEEEgEQCj4OEAIBCA4DBAEBCx0DAgICMBQJCAIEAQ0FCBqHa5pujRmSXYtQhXcyYAOjcIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208,217";a="106709708" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2012 16:57:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6UGvHJW029397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 16:57:17 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.159]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 11:57:15 -0500 From: "David Benham (dbenham)" To: Justin Uberti , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Google statement on codecs Thread-Index: AQHNbjOlh40BzaTvwkOUJzUEZ2l1MJdCC2/Q Date: Mon, 30 Jul 2012 16:57:14 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC5057D37@xmb-aln-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.93.12] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19070.006 x-tm-as-result: No--25.731200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_0683D6CB32AC424D8AF52C0F660E5DC5057D37xmbalnx10ciscocom_" MIME-Version: 1.0 Cc: Harald Alvestrand Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:58:06 -0000 --_000_0683D6CB32AC424D8AF52C0F660E5DC5057D37xmbalnx10ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluDQoNCldoZW4gb25lIHJlY2VpdmVzL3NpZ25zIHRoZSBNUEVHLUxBIGxpY2Vuc2UgZm9y IHRoZSBIMjY0IEFWQyBwb29sLCBhbGwgb2YgdGhlIHBhdGVudHMgKGFib3V0IDggcGFnZXMgd29y dGgpIGFyZSBsaXN0ZWQgc28gdGhhdCB0aGUgbGljZW5zZWUga25vd3Mgd2hhdCB0aGV5IGFyZSBj b3ZlcmVkIGZvciBhbmQgd2hhdCB0aGV5IGFyZSBub3QuDQoNCg0KDQpIb3dldmVyLCBhbSBub3Qg YWJsZSB0byBmaW5kIGEgbGlzdCBvZiBwYXRlbnRzIGN1cnJlbnRseSBsaWNlbnNhYmxlL293bmVk IGJ5IEdvb2dsZSB0aGF0IGFyZSBpbmNsdWRlZCBpbiB0aGUgcm95YWx0eSBmcmVlIFZQOCBiaXRz dHJlYW0gc3BlYyBvciBpbXBsZW1lbnRhdGlvbiBsaWNlbnNlIGZyb20gR29vZ2xlLiAgICBDYW4g b3IgaGFzIEdvb2dsZSBwdWJsaXNoZWQgdGhlIGxpc3Qgb2YgcGF0ZW50cyBtaW5pbWFsbHkgY292 ZXJlZCBieSB5b3VyIFZQOCBsaWNlbnNlcz8NCg0KDQoNCldpdGggdGhhdCBpbmZvLCBnaXZlbiBh ZG9wdGVy4oCZcyBleHBlcnRzIGNvdWxkIG1ha2UgYSByaXNrIGFzc2Vzc21lbnQgYXMgdG8gd2hh dCBtaWdodCBleGlzdCBidXQgKm5vdCogYmUgY292ZXJlZCBieSB0aGUgVlA4IGxpY2Vuc2UgZnJv bSBHb29nbGUuDQoNCg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29n bGUuY29tXQ0KU2VudDogU3VuZGF5LCBKdWx5IDI5LCAyMDEyIDU6MTUgUE0NClRvOiBydGN3ZWJA aWV0Zi5vcmcNCkNjOiBIYXJhbGQgQWx2ZXN0cmFuZA0KU3ViamVjdDogW3J0Y3dlYl0gR29vZ2xl IHN0YXRlbWVudCBvbiBjb2RlY3MNCg0KV2UgYmVsaWV2ZSB0aGF0IHRoZSBXZWJSVEMgZWZmb3J0 IHJlcHJlc2VudHMgYW4gdW5wcmVjZWRlbnRlZCBvcHBvcnR1bml0eSB0byBlc3RhYmxpc2ggYSBu ZXcgcmVhbC10aW1lIGNvbW11bmljYXRpb25zIHBsYXRmb3JtLiBMaWtlIHRoZSB3ZWIgcGxhdGZv cm0sIGl0IGlzIGJ1aWx0IG9uIGZyZWVseSBhdmFpbGFibGUgY29tcG9uZW50cywgcHJvdmlkaW5n IHN0YXRlLW9mLXRoZS1hcnQgcXVhbGl0eSB0byBhbGwgZGV2ZWxvcGVycywgYmlnIG9yIHNtYWxs LCB3aXRoIG5vIG5lZWQgZm9yIHRlY2hub2xvZ3kgbGljZW5zaW5nLiBUaGlzIGFwcHJvYWNoIGhh cyB3b3JrZWQgd29uZGVycyBmb3IgdGhlIHdlYiwgYW5kIHdlIGhvcGUgZm9yIHRoZSBzYW1lIHJl c3VsdCB3aXRoIFdlYlJUQy4NCg0KVGhlcmVmb3JlLCB3ZSBiZWxpZXZlIHRoZSBzb2xlIG1hbmRh dG9yeS10by1pbXBsZW1lbnQgdmlkZW8gY29kZWMgaW4gV2ViUlRDIHNob3VsZCBiZSBWUDgsIHRo ZSBvbmx5IHZpYWJsZSByb3lhbHR5LWZyZWUgb3B0aW9uLiBXZSBiZWxpZXZlIGl0IHByb3ZpZGVz IHN1cGVyaW9yIHF1YWxpdHksIHdoaWNoIGlzIHdoeSB3ZSBhcmUgaW5jcmVhc2luZ2x5IHVzaW5n IGl0IGluIG91ciBvd24gcHJvZHVjdHMuIFdlIGFyZSBhbHNvIHN0cm9uZ2x5IGNvbW1pdHRlZCB0 byB0aGUgZnV0dXJlIG9mIFZQODsgd2UgY29udGludWUgdG8gaW52ZXN0IGhlYXZpbHkgaW4gaXRz IGRldmVsb3BtZW50LCBhbmQgd2UgaGF2ZSBhIGNsZWFyIHJlY29yZCBvZiB2aWdvcm91c2x5IGRl ZmVuZGluZyBvdXIgdGVjaG5vbG9neS4NCg0KT24gdGhlIGF1ZGlvIHNpZGUsIHdlIGJlbGlldmUg dGhhdCBPcHVzIHNob3VsZCBiZSB0aGUgZGVmYXVsdCBtYW5kYXRvcnktdG8taW1wbGVtZW50IGF1 ZGlvIGNvZGVjLCBhc3N1bWluZyB0aGUgcmVtYWluaW5nIGxpY2Vuc2luZyBpc3N1ZXMgY2FuIGJl IHJlc29sdmVkLiBPcHVzIGRlbGl2ZXJzIGV4Y2VsbGVudCBxdWFsaXR5LCAgZnJvbSBuYXJyb3di YW5kIHRvIGZ1bGxiYW5kLCBmb3Igc3RyZWFtaW5nIGFuZCByZWFsdGltZSwgbWFraW5nIGl0IGFu IGlkZWFsIGNob2ljZSBmb3IgYSBiYXNlbGluZSBjb2RlYy4gV2UgYWxzbyByZWNvbW1lbmQgdGhh dCBHLjcxMSBiZSBtYW5kYXRvcnksIGZvciBjb21wYXRpYmlsaXR5IHdpdGggdGhlIHZhc3QgdW5p dmVyc2Ugb2YgUFNUTiBlcXVpcG1lbnQuDQoNCkdpdmVuIHRoZSBhYmlsaXR5IHRvIGRlbGl2ZXIg YSByb3lhbHR5LWZyZWUgcGxhdGZvcm0gd2l0aCBubyBjb21wcm9taXNlcyBvbiBxdWFsaXR5LCB3 ZSBzZWUgbm8gcmVhc29uIHRvIGluY2x1ZGUgbWFuZGF0b3J5IHJveWFsdHktYmVhcmluZyBjb2Rl Y3MuDQoNCg== --_000_0683D6CB32AC424D8AF52C0F660E5DC5057D37xmbalnx10ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv UGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2hlbiBv bmUgcmVjZWl2ZXMvc2lnbnMgdGhlIE1QRUctTEEgbGljZW5zZSBmb3IgdGhlIEgyNjQgQVZDIHBv b2wsIGFsbCBvZiB0aGUgcGF0ZW50cyAoYWJvdXQgOCBwYWdlcyB3b3J0aCkgYXJlIGxpc3RlZCBz byB0aGF0IHRoZSBsaWNlbnNlZSBrbm93cyB3aGF0IHRoZXkgYXJlIGNvdmVyZWQgZm9yIGFuZCB3 aGF0IHRoZXkgYXJlIG5vdC4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkhvd2V2ZXIsIGFtIG5vdCBhYmxlIHRvIGZpbmQgYSBsaXN0IG9mIHBh dGVudHMgY3VycmVudGx5IGxpY2Vuc2FibGUvb3duZWQgYnkgR29vZ2xlIHRoYXQgYXJlIGluY2x1 ZGVkIGluIHRoZSByb3lhbHR5IGZyZWUgVlA4IGJpdHN0cmVhbSBzcGVjIG9yIGltcGxlbWVudGF0 aW9uIGxpY2Vuc2UgZnJvbSBHb29nbGUuJm5ic3A7ICZuYnNwOyZuYnNwO0NhbiBvciBoYXMgR29v Z2xlIHB1Ymxpc2hlZCB0aGUgbGlzdCBvZiBwYXRlbnRzIG1pbmltYWxseQ0KIGNvdmVyZWQgYnkg eW91ciBWUDggbGljZW5zZXM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XaXRoIHRoYXQgaW5mbywgZ2l2ZW4gYWRvcHRl cuKAmXMgZXhwZXJ0cyBjb3VsZCBtYWtlIGEgcmlzayBhc3Nlc3NtZW50IGFzIHRvIHdoYXQgbWln aHQgZXhpc3QgYnV0ICpub3QqIGJlIGNvdmVyZWQgYnkgdGhlIFZQOCBsaWNlbnNlIGZyb20gR29v Z2xlLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFtt YWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVs eSAyOSwgMjAxMiA1OjE1IFBNPGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8 Yj5DYzo8L2I+IEhhcmFsZCBBbHZlc3RyYW5kPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3ZWJd IEdvb2dsZSBzdGF0ZW1lbnQgb24gY29kZWNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlIGJl bGlldmUgdGhhdCB0aGUgV2ViUlRDIGVmZm9ydCByZXByZXNlbnRzIGFuIHVucHJlY2VkZW50ZWQg b3Bwb3J0dW5pdHkgdG8gZXN0YWJsaXNoIGEgbmV3IHJlYWwtdGltZSBjb21tdW5pY2F0aW9ucyBw bGF0Zm9ybS4gTGlrZSB0aGUgd2ViIHBsYXRmb3JtLCBpdCBpcyBidWlsdCBvbiBmcmVlbHkNCiBh dmFpbGFibGUgY29tcG9uZW50cywgcHJvdmlkaW5nIHN0YXRlLW9mLXRoZS1hcnQgcXVhbGl0eSB0 byBhbGwgZGV2ZWxvcGVycywgYmlnIG9yIHNtYWxsLCB3aXRoIG5vIG5lZWQgZm9yIHRlY2hub2xv Z3kgbGljZW5zaW5nLiBUaGlzIGFwcHJvYWNoIGhhcyB3b3JrZWQgd29uZGVycyBmb3IgdGhlIHdl YiwgYW5kIHdlIGhvcGUgZm9yIHRoZSBzYW1lIHJlc3VsdCB3aXRoIFdlYlJUQy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VGhlcmVmb3JlLCB3ZSBiZWxpZXZlIHRoZSBzb2xlIG1hbmRhdG9yeS10by1pbXBsZW1l bnQgdmlkZW8gY29kZWMgaW4gV2ViUlRDIHNob3VsZCBiZSBWUDgsIHRoZSBvbmx5IHZpYWJsZSBy b3lhbHR5LWZyZWUgb3B0aW9uLiBXZSBiZWxpZXZlIGl0IHByb3ZpZGVzIHN1cGVyaW9yIHF1YWxp dHksIHdoaWNoDQogaXMgd2h5IHdlIGFyZSBpbmNyZWFzaW5nbHkgdXNpbmcgaXQgaW4gb3VyIG93 biBwcm9kdWN0cy4gV2UgYXJlIGFsc28gc3Ryb25nbHkgY29tbWl0dGVkIHRvIHRoZSBmdXR1cmUg b2YgVlA4OyB3ZSBjb250aW51ZSB0byBpbnZlc3QgaGVhdmlseSBpbiBpdHMgZGV2ZWxvcG1lbnQs IGFuZCB3ZSBoYXZlIGEgY2xlYXIgcmVjb3JkIG9mIHZpZ29yb3VzbHkgZGVmZW5kaW5nIG91ciB0 ZWNobm9sb2d5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPk9uIHRoZSBhdWRpbyBzaWRlLCB3ZSBiZWxpZXZlIHRoYXQgT3B1 cyBzaG91bGQgYmUgdGhlIGRlZmF1bHQgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBhdWRpbyBjb2Rl YywgYXNzdW1pbmcgdGhlIHJlbWFpbmluZyBsaWNlbnNpbmcgaXNzdWVzIGNhbiBiZSByZXNvbHZl ZC4gT3B1cyBkZWxpdmVycyBleGNlbGxlbnQNCiBxdWFsaXR5LCAmbmJzcDtmcm9tIG5hcnJvd2Jh bmQgdG8gZnVsbGJhbmQsIGZvciBzdHJlYW1pbmcgYW5kIHJlYWx0aW1lLCBtYWtpbmcgaXQgYW4g aWRlYWwgY2hvaWNlIGZvciBhIGJhc2VsaW5lIGNvZGVjLiBXZSBhbHNvIHJlY29tbWVuZCB0aGF0 IEcuNzExIGJlIG1hbmRhdG9yeSwgZm9yIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgdmFzdCB1bml2 ZXJzZSBvZiBQU1ROIGVxdWlwbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkdpdmVuIHRoZSBhYmlsaXR5 IHRvIGRlbGl2ZXIgYSByb3lhbHR5LWZyZWUgcGxhdGZvcm0gd2l0aCBubyBjb21wcm9taXNlcyBv biBxdWFsaXR5LCB3ZSBzZWUgbm8gcmVhc29uIHRvIGluY2x1ZGUgbWFuZGF0b3J5IHJveWFsdHkt YmVhcmluZyBjb2RlY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_0683D6CB32AC424D8AF52C0F660E5DC5057D37xmbalnx10ciscocom_-- From roman@telurix.com Mon Jul 30 10:22:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181D811E8137 for ; Mon, 30 Jul 2012 10:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozpdVzC+tYCe for ; Mon, 30 Jul 2012 10:22:01 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A99511E812F for ; Mon, 30 Jul 2012 10:22:01 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5486383ggn.31 for ; Mon, 30 Jul 2012 10:22:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=nfAJo/ggPcOWW0u/9mT45N53hXgwIYBDjPZrPYrsIoU=; b=OecG4Um9Vy+FYpZKLcfVoLBSzeE16006q3jWo0F+nxV0tHj3poiUON8EwvNI/JDl/j 3ZFwiQXiUOJWYf0r/LBptYPpO6GLGPNvVLTClMlBJQbeOUMm1dyzVUkKw8CKRvtThngo swUQO88C7l2z/Kz2isdUZ0SHPf33a5SSyR/LfybTUHh6c5dT0Ps6aCFprWwcogUSaJv0 mImQ6hatN7cgoPXevkYY3xJJTkdbGxnmtH1VeW9IOv+kBXzjqJ4qfF1rd1a9G0oVS8IR WkTKL8dLq5RIoEJs2pfaCLeEGvY1u7bGcmiYYOK+FVIf18xmSbWNzPkOaFnaWqf+MUln B6JQ== Received: by 10.68.232.170 with SMTP id tp10mr37271650pbc.59.1343668920574; Mon, 30 Jul 2012 10:22:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id oa5sm8285452pbb.14.2012.07.30.10.21.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 10:21:59 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10107811pbc.31 for ; Mon, 30 Jul 2012 10:21:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.38 with SMTP id rp6mr36667741pbc.90.1343668918934; Mon, 30 Jul 2012 10:21:58 -0700 (PDT) Received: by 10.68.28.72 with HTTP; Mon, 30 Jul 2012 10:21:58 -0700 (PDT) Date: Mon, 30 Jul 2012 13:21:58 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff253bc9bdd5704c60f4cf5 X-Gm-Message-State: ALoCoQlxwUxL4e+CGyRuY5LmQq+BLBWiTojiUFs2DedpabyioykgoKFB4kc/EWvrERH4bg6VaZyJ Subject: [rtcweb] Should we also make G.722 a mandatory to implement codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 17:22:02 -0000 --e89a8ff253bc9bdd5704c60f4cf5 Content-Type: text/plain; charset=ISO-8859-1 Should we consider adding G.722 as a mandatory to implement audio codec? It is low complexity and carries no royalty or license restrictions, it is very good quality for voice audio communications at the same bandwidths as G.711, and it is very widely implemented by the desktop IP phones. _____________ Roman Shpount On Sun, Jul 29, 2012 at 11:14 PM, Cameron Byrne wrote: > > On Jul 29, 2012 8:13 PM, "Ralph Giles" wrote: > > > > On 12-07-29 6:44 PM, Maire Reavy wrote: > > > > > Mandating encumbered codecswould force open-source projects to violate > > > the spec (by not implementing a mandatory codec). For this reason and > > > the reasons Justin cites, we believe Opus, G.711 and VP8 are the best > > > mandatory-to-implement choices for the spec. > > > > +1 > > > > -r > > > > +1 > > CB > > > > > _______________________________________________ > > 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 > > --e89a8ff253bc9bdd5704c60f4cf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Should we consider adding G.722 as a mandatory to implement audio codec? It= is low complexity and carries no royalty or license=A0restrictions, it is = very good quality for voice audio communications at the same=A0bandwidths= =A0as G.711, and it is very widely implemented by the desktop IP phones. _____________
Roman Shpount


On Sun, Jul 29, 2012 at 11:14 PM, Camero= n Byrne <cb.list6@gmail.com> wrote:


On Jul 29, 2012 8:13 PM, "Ralph Giles" <giles@thaumas.net> wrote:
>
> On 12-07-29 6:44 PM, Maire Reavy wrote:
>
> > Mandating encumbered codecswould force open-source projects to vi= olate
> > the spec (by not implementing a mandatory codec). =A0For this rea= son and
> > the reasons Justin cites, we believe Opus, G.711 and VP8 are the = best
> > mandatory-to-implement choices for the spec.
>
> +1
>
> =A0-r
>

+1

CB

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


--e89a8ff253bc9bdd5704c60f4cf5-- From juberti@google.com Mon Jul 30 10:22:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EE711E8141 for ; Mon, 30 Jul 2012 10:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKmEXyNp9-en for ; Mon, 30 Jul 2012 10:22:26 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 753CD11E8143 for ; Mon, 30 Jul 2012 10:22:26 -0700 (PDT) Received: by qadz3 with SMTP id z3so1116544qad.10 for ; Mon, 30 Jul 2012 10:22: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:x-system-of-record; bh=LDbVUknKytyB1Zsxg48SI1NbK8RHFTBA/oT5ZDPiLrk=; b=ANeG/jjcInxTDIYC/OI1i3fkqjsGluIfV0mogzymLJm4uJQqasqzkR0yoXfHTJk7j2 FSZcAF+GYLAFtyaLzXJswio7KR7HZo4sHLP619DUlDYTwKT5te1OGH+0WHJWHFIXu6KT 5VIry/UNGJaWN0qKLxaaX35C04wOrTfSLD80YdfxI9+yug5D8WeR72QndFd7vq8o4x26 87N91bIbnaz+BrgBv1O+Wr+qmjyID9dOsisKIy9bcOqtkok6qKI1C/kK0S6yTnAdg8ZY ju4wsZXbpZ6sOabb7WRZo0Uzps8CFL5LJSauU3utLvbDiLMbYrNZBpsYB9FBmAWdwjaA Dn+w== X-Google-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:x-system-of-record:x-gm-message-state; bh=LDbVUknKytyB1Zsxg48SI1NbK8RHFTBA/oT5ZDPiLrk=; b=XTsnk7kSmq3Aa75EoWp+TV17hu5YtO2MHav1gJb5No2zSkuzNykHKSB39dRteXwKbW r9TJGg2d2q4ez6J7mc8zUy1QqbX7WEESoEyznJqbLN/6gMs0y/j2uo5KxGI6AohYa2e1 Pqxz8vOz4lQZ0QSly6yC7yyOKI9A1SUY3XrYaWWIwCs5CTQC6rVz4/cXuj4vM23DQM0L 7mvy/bchbKzO4t3yszUikKPK2sKmZCksulrb5Xs3/NY/S1ys+nYGPX2MGP4FenzNlEy0 t5PrPKyAZBYFdM39wpW7XsJR3L+iibKdW88R/1dEAYdSEVMvnmwsgERlzH89Zwsre1fY Yv/g== Received: by 10.224.186.20 with SMTP id cq20mr24408877qab.32.1343668945988; Mon, 30 Jul 2012 10:22:25 -0700 (PDT) Received: by 10.224.186.20 with SMTP id cq20mr24408856qab.32.1343668945839; Mon, 30 Jul 2012 10:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.59.66 with HTTP; Mon, 30 Jul 2012 10:22:05 -0700 (PDT) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F207BD4A03@szxeml525-mbx.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F207BD4A03@szxeml525-mbx.china.huawei.com> From: Justin Uberti Date: Mon, 30 Jul 2012 10:22:05 -0700 Message-ID: To: Likepeng Content-Type: multipart/alternative; boundary=485b397dcddd36667504c60f4ee4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlQyauqMob0BhviP51s5PFXdvNTc2HcXLx7iF8HavnzJztUp82eoB86isVBewFEbqKIHbD00HMMdzNTF31XAWE53BvKzWhg2fx7QObLhDzfsHdMcdROObwUstBED4o0YS3JFKL9aSBfwl9oTYE9jVcBBdoRdKG6+WtIrGkUCY8RpLh16ow= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fw: New Version Notification for draft-li-rtcweb-jsep-xmpp-mapping-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 17:22:27 -0000 --485b397dcddd36667504c60f4ee4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Likepeng, This draft shows how JS clients could use the Jingle protocol to establish a session, but I didn't see a section where it explains how to map the Jingle messages to the JSEP API, or the payloads of these messages to SDP (as required by the API). I think this could be easily added - for example, a received session-initiate will map to a setRemoteDescription - but in order for a developer to implement an Jingle client in JS, these mappings need to be clearly defined. On Mon, Jul 30, 2012 at 2:20 AM, Likepeng wrote: > Welcome your comments to this draft. > > Have a nice meeting in Vancouver! > > Kind Regards > Kepeng > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-dr= afts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B47=E6=9C=8830=E6=97=A5 = 15:27 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng > =E6=8A=84=E9=80=81: Likepeng > =E4=B8=BB=E9=A2=98: New Version Notification for draft-li-rtcweb-jsep-xmp= p-mapping-00.txt > > A new version of I-D, draft-li-rtcweb-jsep-xmpp-mapping-00.txt > has been successfully submitted by Kepeng and posted to the > IETF repository. > > Filename: draft-li-rtcweb-jsep-xmpp-mapping > Revision: 00 > Title: RTCWeb JSEP XMPP/Jingle Mapping > Creation date: 2012-07-30 > WG ID: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-li-rtcweb-jsep-xmpp-mapping-00.= txt > Status: > http://datatracker.ietf.org/doc/draft-li-rtcweb-jsep-xmpp-mapping > Htmlized: > http://tools.ietf.org/html/draft-li-rtcweb-jsep-xmpp-mapping-00 > > Abstract: > This document proposes mapping message representations between RTCWeb > Javascript Session Establishment Protocol(JSEP) scheme and XMPP/ > Jingle [XEP-0166] messaging scheme. Such a signaling mapping is > intended to enable Javascript to use XMPP/Jingle to establish a > session between two RTCWeb enabled browsers. > > The IETF Secretariat > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --485b397dcddd36667504c60f4ee4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Likepeng,

This draft shows how JS clients could use the = Jingle protocol to establish a session, but I didn't see a section wher= e it explains how to map the Jingle messages to the JSEP API, or the payloa= ds of these messages to SDP (as required by the API).

I think this could be easily added - for example, a rec= eived session-initiate will map to a setRemoteDescription - but in order fo= r a developer to implement an Jingle client in JS, these mappings need to b= e clearly defined.


On Mon, Jul 3= 0, 2012 at 2:20 AM, Likepeng <likepeng@huawei.com> wrote:<= br>
Welcome your comments to this draft.

Have a nice meeting in Vancouver!

Kind Regards
Kepeng
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: in= ternet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B47=E6=9C=8830=E6=97=A5 15= :27
=E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng
=E6=8A=84=E9=80=81: Likepeng
=E4=B8=BB=E9=A2=98: New Version Notification for draft-li-rtcweb-jsep-xmpp-= mapping-00.txt

A new version of I-D, draft-li-rtcweb-jsep-xmpp-mapping-00.txt
has been successfully submitted by Kepeng and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-li-rtcweb-jsep-xmpp-mapping
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RTCWeb JSEP XMPP/Jingle Mapping Creation date: =C2=A0 2012-07-30
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 10
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-li-rtcweb-jsep-xmpp-mapping-0= 0.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datat= racker.ietf.org/doc/draft-li-rtcweb-jsep-xmpp-mapping
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.o= rg/html/draft-li-rtcweb-jsep-xmpp-mapping-00

Abstract:
=C2=A0 =C2=A0This document proposes mapping message representations between= RTCWeb
=C2=A0 =C2=A0Javascript Session Establishment Protocol(JSEP) scheme and XMP= P/
=C2=A0 =C2=A0Jingle [XEP-0166] messaging scheme. =C2=A0Such a signaling map= ping is
=C2=A0 =C2=A0intended to enable Javascript to use XMPP/Jingle to establish = a
=C2=A0 =C2=A0session between two RTCWeb enabled browsers.

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

--485b397dcddd36667504c60f4ee4-- From lorenzo@meetecho.com Mon Jul 30 11:01:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AB511E80D5 for ; Mon, 30 Jul 2012 11:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSO0GauXdDnW for ; Mon, 30 Jul 2012 11:01:54 -0700 (PDT) Received: from smtplq01.aruba.it (smtplq-out5.aruba.it [62.149.158.25]) by ietfa.amsl.com (Postfix) with SMTP id CCBE221F8565 for ; Mon, 30 Jul 2012 11:01:53 -0700 (PDT) Received: (qmail 31346 invoked by uid 89); 30 Jul 2012 18:01:38 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq01.aruba.it with SMTP; 30 Jul 2012 18:01:38 -0000 Received: (qmail 7245 invoked by uid 89); 30 Jul 2012 18:01:38 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@130.129.23.208) by smtp4.ad.aruba.it with SMTP; 30 Jul 2012 18:01:37 -0000 Date: Mon, 30 Jul 2012 20:01:24 +0200 From: Lorenzo Miniero To: rtcweb@ietf.org Message-ID: <20120730200124.2b1fdeb2@lminiero-acer> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Subject: [rtcweb] Meetecho support for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:01:55 -0000 Dear all, as I anticipated a few days ago, as usual we'll provide remote participation support for both the RTCWEB meeting sessions here in Vancouver. Access to the on-line session will be available at: http://www.meetecho.com/ietf84/rtcweb Only for the brave (!), besides the usual integrated view of the official IETF jabber room, the current slides and the audio/video feed, this time we'll also make available a WebRTC point of entry to the audio/video feed from the room: if you already tried the open demo I published a few days ago, you'll know what I'm talking about. At the moment it only works on Chrome Canary, but we're working on adding support for other browser implementations as well: make sure you have the PeerConnection enabled in chrome://flags to get it working. Let me know if you encounter any problem using it: I'll be in the room (both physically and virtually) so feel free to contact me at any time. Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From kpfleming@digium.com Mon Jul 30 11:49:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7D11E8132 for ; Mon, 30 Jul 2012 11:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGwvMWbIwHGS for ; Mon, 30 Jul 2012 11:49:04 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id DADC611E8111 for ; Mon, 30 Jul 2012 11:49:04 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Svv1b-0004Va-9l for rtcweb@ietf.org; Mon, 30 Jul 2012 13:49:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 48143D887D for ; Mon, 30 Jul 2012 13:49:03 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adQJprBM4UVT for ; Mon, 30 Jul 2012 13:49:03 -0500 (CDT) Received: from [10.24.19.142] (sligo.digium.internal [10.24.19.142]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 00C93D887A for ; Mon, 30 Jul 2012 13:49:02 -0500 (CDT) Message-ID: <5016D714.4030908@digium.com> Date: Mon, 30 Jul 2012 13:48:52 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Should we also make G.722 a mandatory to implement codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:49:05 -0000 On 07/30/2012 12:21 PM, Roman Shpount wrote: > Should we consider adding G.722 as a mandatory to implement audio codec? > It is low complexity and carries no royalty or license restrictions, it > is very good quality for voice audio communications at the > same bandwidths as G.711, and it is very widely implemented by the > desktop IP phones. I would certainly support making G.722 mandatory to implement. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From kpfleming@digium.com Mon Jul 30 11:51:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A8711E8151 for ; Mon, 30 Jul 2012 11:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.266 X-Spam-Level: X-Spam-Status: No, score=-109.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALUH0eYeRE7k for ; Mon, 30 Jul 2012 11:51:17 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADF511E813F for ; Mon, 30 Jul 2012 11:51:17 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Svv3k-0004Xo-Ud for rtcweb@ietf.org; Mon, 30 Jul 2012 13:51:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E5363D887D for ; Mon, 30 Jul 2012 13:51:16 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ocF6Q6VBsM5 for ; Mon, 30 Jul 2012 13:51:16 -0500 (CDT) Received: from [10.24.19.142] (sligo.digium.internal [10.24.19.142]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 71F88D887A for ; Mon, 30 Jul 2012 13:51:16 -0500 (CDT) Message-ID: <5016D79A.1050902@digium.com> Date: Mon, 30 Jul 2012 13:51:06 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> <5015FBE7.9060809@thaumas.net> <501640E3.1000009@jesup.org> <501650B0.6060308@infosecurity.ch> In-Reply-To: <501650B0.6060308@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:51:18 -0000 On 07/30/2012 04:15 AM, Fabio Pietrosanti (naif) wrote: > What's the Microsoft position on WebRTC in general? > > Are they going to dump/skip/sabotage-it or are they going to participate? > > If they will participate, will they try to leverage skype/msn codecs > compatibility? At least one of the Skype codecs (SILK) has already been integrated into Opus and we're hoping it will be part of the WebRTC codecs list. If I remember the discussions from the CODEC working group properly, the version of it in Opus is even better than SILK itself was, so there's really no reason for SILK to be used in new applications. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From dbenham@cisco.com Mon Jul 30 12:45:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CFE11E81D4 for ; Mon, 30 Jul 2012 12:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrOTV8N-pSzA for ; Mon, 30 Jul 2012 12:45:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1F11E81C7 for ; Mon, 30 Jul 2012 12:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dbenham@cisco.com; l=2559; q=dns/txt; s=iport; t=1343677555; x=1344887155; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AHxPKs6YwDHErFuRclzbnGE6vBRloo3TJG+WkhVrtlQ=; b=HMm2v8tHGWdnJjlYiUyEgfoIpZ/3rUYRWrd9+9cH50PgmQ7vAXZvX1Im Y6vnlUMyJtxqZNsRQvsYJb6FBm5Eq/oJGvNSdXs1xn9S2ZqqRJb1bP0Rm IpOG7wyQz4QLMWG7NRxbfg3ZaaaoBIOFrK6gsaTCrYJAxDU1TdPgL/ggr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPXiFlCtJXG+/2dsb2JhbABFuVOBB4IgAQEBBBIBJzgZAQgYChRCJgEEChEah2uZQ4EooA2LUIYpYAOWXY0TgWaCXw X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208";a="106731353" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jul 2012 19:45:55 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6UJjs8W017178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Jul 2012 19:45:54 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Mon, 30 Jul 2012 14:45:54 -0500 From: "David Benham (dbenham)" To: "rtcweb@ietf.org" Thread-Topic: Re: [rtcweb] non-standard codecs Thread-Index: Ac1ui7Gvhxj2sIruSWaI0RPHqY7OBg== Date: Mon, 30 Jul 2012 19:45:53 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC5057FA8@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.118.22] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.001 x-tm-as-result: No--33.362900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 19:45:56 -0000 >(It's, I believe, generally assumed now that FRAND commitments travel with > the patent, just like a license. Meaning that a troll cannot expect > non-FRAND licensing terms for a patent that, at some point in time, was > owned by a legit SDO member. Many SDOs have updated their policy > documents to ensure this, and there is also case law addressing this issu= e.) To confirm Stephen's point, SDOs that have built in FRAND also have a "surv= ivability" clause where even if the member leaves the SDO, the obligation/p= romise to license (FRAND, etc) essential patents for the spec developed up = to the date of the member leaving 'survives' the termination of their membe= rship. This extra clause should never be left out because without it, mem= bers might be eager to get their IPR in a SDO's spec so they can later leav= e and subsequently try to extract a pound of flesh from the rest of the SDO= spec's adopters. Further, such an ex-member worth their salt would tran= sfer that obligation along with that IPR if transferring to another company= (via a sale, etc). On 7.30.2012 08:05 , "Harald Alvestrand" wrote: >> B. FRAND status. SDO IPR policies (and legal precedents) confer >>important benefits to documents that have gone through a standards >>process. Without this, potential IPR claims have no upper bound. >To be precise, the SDO IPR policies confer important benefits in >relation to the companies or individuals that were part of that SDO at >the time of the standardization procedure. I would go even further: most SDO IPR policies confer important benefits in relation to patents and patent applications under control of a member of the SDO at the time of the standardization procedure. (It's, I believe, generally assumed now that FRAND commitments travel with the patent, just like a license. Meaning that a troll cannot expect non-FRAND licensing terms for a patent that, at some point in time, was owned by a legit SDO member. Many SDOs have updated their policy documents to ensure this, and there is also case law addressing this issue.= ) It's also worth noting that in video coding, most major industry players are actively involved in the FRAND-bearing standardization effort. That doesn't mean that there can't be any non-FRAND pledged patents reading on a video coding standard, but the likelihood is low compared to other areas of technology. All that doesn't help the open source industry, but it helps the rest of us= . Stephan From silviapfeiffer1@gmail.com Mon Jul 30 14:54:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC911E81C9 for ; Mon, 30 Jul 2012 14:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8sxiRkHKsTD for ; Mon, 30 Jul 2012 14:54:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 119A611E81C4 for ; Mon, 30 Jul 2012 14:54:26 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5486173vbb.31 for ; Mon, 30 Jul 2012 14:54:26 -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=5LGqcO/eCfzWIf792CYlZG1z0vJyFlcnMPRlr8hhSG0=; b=sslQ8TdRad/JvCz3FDits+uTA9fxHd2kRa5iImnccUaZq1uk1g6ZYyiVIgA/1vV5zt eEQekv4f//2gI8FjRILP8LrmvPsDtGtCQRtou5/wXXErpEyK1CvkTKZlldwFzgv1h5ih B3AgRJ3LtIi/h+pFcmK0Ij8N8VIpcQczQVUKFH64+hcFWXVYMGaM26l0gqufS9Jbm67y sRxCPaRBlhQKhIn7oEQ1R1WcCdMnXr4/bS0XcbCm9pUIe7+cJjy/E0L+K2iw7LGqliUG GV+Q2DxPr9LQlHiZpsN3Ug0P4OjWzT2xxwTPgtVSN7Eciwn6i/tlCG3iTEe+QrFHmFCJ WmmQ== Received: by 10.52.24.227 with SMTP id x3mr10908341vdf.68.1343685266466; Mon, 30 Jul 2012 14:54:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.9 with HTTP; Mon, 30 Jul 2012 14:54:06 -0700 (PDT) In-Reply-To: References: From: Silvia Pfeiffer Date: Tue, 31 Jul 2012 07:54:06 +1000 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:54:28 -0000 I assume this is a discussion about VP8. :-) On Mon, Jul 30, 2012 at 11:57 PM, Bernard Aboba wrote: > There are several reasons why it would be imprudent to seriously consider a non-standard codec as mandatory-to-implement: > > A. Change control. Normatively referencing a document not under IETF change control as mandatory-to-implement means that a core aspect of the standard would be subject to change without IETF review. How about this one? http://tools.ietf.org/html/rfc6386 It's an IETF document and therefore not subject to change without IETF review. > B. FRAND status. SDO IPR policies (and legal precedents) confer important benefits to documents that have gone through a standards process. Without this, potential IPR claims have no upper bound. MPEG-LA has been working on its patent pool for VP8 for more than 18 months now [1] - does anyone know when this will conclude? [1] http://www.mpegla.com/main/pid/vp8/default.aspx Regards, Silvia. From stewe@stewe.org Mon Jul 30 15:08:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5968111E81F7 for ; Mon, 30 Jul 2012 15:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E76hfaVN1k9T for ; Mon, 30 Jul 2012 15:08:17 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9002B11E81EC for ; Mon, 30 Jul 2012 15:08:17 -0700 (PDT) Received: from mail51-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jul 2012 22:08:16 +0000 Received: from mail51-ch1 (localhost [127.0.0.1]) by mail51-ch1-R.bigfish.com (Postfix) with ESMTP id 93A831C0498; Mon, 30 Jul 2012 22:08:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz98dIc430I1432Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944he5bhf0ah107ah) Received-SPF: pass (mail51-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail51-ch1 (localhost.localdomain [127.0.0.1]) by mail51-ch1 (MessageSwitch) id 1343686094211916_20957; Mon, 30 Jul 2012 22:08:14 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail51-ch1.bigfish.com (Postfix) with ESMTP id 31DB7460049; Mon, 30 Jul 2012 22:08:14 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jul 2012 22:08:13 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.193]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0175.005; Mon, 30 Jul 2012 22:08:13 +0000 From: Stephan Wenger To: Silvia Pfeiffer , Bernard Aboba Thread-Topic: [rtcweb] non-standard codecs Thread-Index: AQHNbltVnEEltQX51kaUa/L9MQch/JdCXvcA//+OlIA= Date: Mon, 30 Jul 2012 22:08:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <5173A275343A1A409AB328C86DCDF155@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:08:18 -0000 Hi Silvia, On 7.30.2012 14:54 , "Silvia Pfeiffer" wrote: >> >> A. Change control. Normatively referencing a document not under IETF >>change control as mandatory-to-implement means that a core aspect of the >>standard would be subject to change without IETF review. > >How about this one? http://tools.ietf.org/html/rfc6386 > >It's an IETF document and therefore not subject to change without IETF >review. While an RFC is static, this RFC is NOT an IETF document. It's the end result of an independent submission to the RFC editor. It's not an IETF product, and it's not under IETF "change control". Btw., wikipedia got that doc status wrong as well; you are not alone :-) > > >> B. FRAND status. SDO IPR policies (and legal precedents) confer >>important benefits to documents that have gone through a standards >>process. Without this, potential IPR claims have no upper bound. > >MPEG-LA has been working on its patent pool for VP8 for more than 18 >months now [1] - does anyone know when this will conclude? > >[1] http://www.mpegla.com/main/pid/vp8/default.aspx Those who know are not allow to talk about it. Regards, Stephan > >Regards, >Silvia. >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From silviapfeiffer1@gmail.com Mon Jul 30 15:19:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B423911E820E for ; Mon, 30 Jul 2012 15:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrhplN2wScac for ; Mon, 30 Jul 2012 15:19:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF22D11E81EB for ; Mon, 30 Jul 2012 15:19:12 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5505467vbb.31 for ; Mon, 30 Jul 2012 15:19:12 -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=j0fkr1s7lYqsoGSIzKOM2wMPJFaaHe6yvvwpIEU6Rn8=; b=dX8Sj2y1yUXaRGBbQ2WsMdkIqKBWor0asITwSGZoukV05t1WhKhL8yzrm5XWFZ5IGR 5h+ThEV+Pb1XP0eJQLZITLBjVnz77myBQh81/u6Rs4cdye4M+O+APtkDhX0RxmAyMFOY Ha6rcUz3lXOD5azftulmyImX825dk9eYMCnQrskUaRKX4vWSpkBdnKakO1wj0A3WNTUI nq/CNpgLjFDXPcRabvjZO6Y0X9RibxccAyw8vwYlmetV17SiedMn7Jex3UE9ICBeI30I 82x9cu8A0YD1mvze0BWRivolAiZc/8uVctDSXJ70n64RemllsOvRRVZv0pOsX3nuEqVc lJOA== Received: by 10.58.128.3 with SMTP id nk3mr676442veb.9.1343686752362; Mon, 30 Jul 2012 15:19:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.9 with HTTP; Mon, 30 Jul 2012 15:18:51 -0700 (PDT) In-Reply-To: References: From: Silvia Pfeiffer Date: Tue, 31 Jul 2012 08:18:51 +1000 Message-ID: To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:19:13 -0000 On Tue, Jul 31, 2012 at 8:08 AM, Stephan Wenger wrote: > Hi Silvia, > > On 7.30.2012 14:54 , "Silvia Pfeiffer" wrote: > >>> >>> A. Change control. Normatively referencing a document not under IETF >>>change control as mandatory-to-implement means that a core aspect of the >>>standard would be subject to change without IETF review. >> >>How about this one? http://tools.ietf.org/html/rfc6386 >> >>It's an IETF document and therefore not subject to change without IETF >>review. > > While an RFC is static, this RFC is NOT an IETF document. It's the end > result of an independent submission to the RFC editor. It's not an IETF > product, and it's not under IETF "change control". Btw., wikipedia got > that doc status wrong as well; you are not alone :-) Oh, I'm fully aware of the informal state of this document. However, IETF still has change control - they can still stop any further submissions / updates of that document. After all, they are the publisher. While it's not a document that was created by an IETF group, it's still a specification document with fixed content. It would be possible to re-do this document through a working group with group input and going through the formal IETF process. Maybe that is something that this WG should consider doing. >>> B. FRAND status. SDO IPR policies (and legal precedents) confer >>>important benefits to documents that have gone through a standards >>>process. Without this, potential IPR claims have no upper bound. >> >>MPEG-LA has been working on its patent pool for VP8 for more than 18 >>months now [1] - does anyone know when this will conclude? >> >>[1] http://www.mpegla.com/main/pid/vp8/default.aspx > > Those who know are not allow to talk about it. What a shame! Let's hope it's soon so we get some clarification. Cheers, Silvia. From stewe@stewe.org Mon Jul 30 16:01:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22D421F861F for ; Mon, 30 Jul 2012 16:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAdJtpd58P-i for ; Mon, 30 Jul 2012 16:01:52 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id CF61921F85F7 for ; Mon, 30 Jul 2012 16:01:51 -0700 (PDT) Received: from mail87-db3-R.bigfish.com (10.3.81.233) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jul 2012 23:01:51 +0000 Received: from mail87-db3 (localhost [127.0.0.1]) by mail87-db3-R.bigfish.com (Postfix) with ESMTP id C3DA9260239; Mon, 30 Jul 2012 23:01:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zz98dIc430I1432Izz1202h1082kzz8275bh8275dhz2fh2a8h668h839h944he5bhf0ah107ah) Received-SPF: pass (mail87-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail87-db3 (localhost.localdomain [127.0.0.1]) by mail87-db3 (MessageSwitch) id 1343689307714857_5860; Mon, 30 Jul 2012 23:01:47 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.250]) by mail87-db3.bigfish.com (Postfix) with ESMTP id AC9A32A005B; Mon, 30 Jul 2012 23:01:47 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jul 2012 23:01:45 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.193]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0175.005; Mon, 30 Jul 2012 23:01:44 +0000 From: Stephan Wenger To: Silvia Pfeiffer Thread-Topic: [rtcweb] non-standard codecs Thread-Index: AQHNbltVnEEltQX51kaUa/L9MQch/JdCXvcA//+OlICAAHhWgP//lqAA Date: Mon, 30 Jul 2012 23:01:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <558726972E819E459F55697ADAD8B27C@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:01:53 -0000 Hi Silvia, On 7.30.2012 15:18 , "Silvia Pfeiffer" wrote: >>> >>>It's an IETF document and therefore not subject to change without IETF >>>review. >> >> While an RFC is static, this RFC is NOT an IETF document. It's the end >> result of an independent submission to the RFC editor. It's not an IETF >> product, and it's not under IETF "change control". Btw., wikipedia got >> that doc status wrong as well; you are not alone :-) > >Oh, I'm fully aware of the informal state of this document. However, >IETF still has change control - they can still stop any further >submissions / updates of that document. After all, they are the >publisher. It's an independent submission to the RFC editor, and not an IETF document. This page explains what those independent submissions are: http://www.rfc-editor.org/indsubs.html It is not an IETF document, and the IETF has no change control. The IETF cannot stop any further submissions or updates unless the IESG finds that the doc is harmful to the Internet, and AFAIK, the IETF is not the publisher of the doc. > >While it's not a document that was created by an IETF group, it's >still a specification document with fixed content. Fixed content, yes. Spec doc: depends on whom you ask :-) Stephan > >It would be possible to re-do this document through a working group >with group input and going through the formal IETF process. Maybe that >is something that this WG should consider doing. > > >>>> B. FRAND status. SDO IPR policies (and legal precedents) confer >>>>important benefits to documents that have gone through a standards >>>>process. Without this, potential IPR claims have no upper bound. >>> >>>MPEG-LA has been working on its patent pool for VP8 for more than 18 >>>months now [1] - does anyone know when this will conclude? >>> >>>[1] http://www.mpegla.com/main/pid/vp8/default.aspx >> >> Those who know are not allow to talk about it. > >What a shame! Let's hope it's soon so we get some clarification. > > >Cheers, >Silvia. > From stewe@stewe.org Mon Jul 30 17:12:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF21611E80C5 for ; Mon, 30 Jul 2012 17:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2t4nOZPcfS9 for ; Mon, 30 Jul 2012 17:12:30 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8411E809B for ; Mon, 30 Jul 2012 17:12:30 -0700 (PDT) Received: from mail47-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 00:12:29 +0000 Received: from mail47-co1 (localhost [127.0.0.1]) by mail47-co1-R.bigfish.com (Postfix) with ESMTP id B60767000CC for ; Tue, 31 Jul 2012 00:12:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 5 X-BigFish: PS5(zzc85eh14ffIzz1202h1082kzzd0f34h8275bhz2fh2a8h668h839he5bhf0ah107ahbe3k) Received-SPF: pass (mail47-co1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail47-co1 (localhost.localdomain [127.0.0.1]) by mail47-co1 (MessageSwitch) id 134369354859467_11233; Tue, 31 Jul 2012 00:12:28 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.246]) by mail47-co1.bigfish.com (Postfix) with ESMTP id 0CAA260004B for ; Tue, 31 Jul 2012 00:12:28 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 00:12:28 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.193]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0175.005; Tue, 31 Jul 2012 00:12:26 +0000 From: Stephan Wenger To: "rtcweb@ietf.org" Thread-Topic: Video decoder complexity and battery power optimizations with hardware decoding Thread-Index: AQHNbrEqeIvAUDBowE+z0J2urA7e0w== Date: Tue, 31 Jul 2012 00:12:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: multipart/alternative; boundary="_000_CC3C70F389CACstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [rtcweb] Video decoder complexity and battery power optimizations with hardware decoding X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 00:12:31 -0000 --_000_CC3C70F389CACstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I promised in the meeting a link to the following doc: JCTVC-J0128 To summarize, using a single core of the iPad3's dual core processor, softw= are decoding of HEVC (forthcoming H.265) at 720p30 resolution and 1.5 Mbit/= s bitrate is possible. A fully charged battery is empty after 8 hours. Th= is compares to 10 hours when decoding H.264 using hardware acceleration. My take from this data point is that battery life is not all that much affe= cted by hardware-based decoding, at least not for tablets and larger device= s. If your screen and battery are considerably smaller, but your processin= g demands similar, hardware decoding may become more beneficial, relatively= speaking. However, if you scale down video resolution with screen size, t= hings ought to be approximately in the same ballpark. While at this discussion, let me reiterate two other points made in the mee= ting. First, AFAIK, there are no hardware-accelerated encoders in today's = products that could meaningfully be used for conversational applications; e= ncoders run software-only, and their complexity is necessarily considerably= higher than that of a decoder (because an encoder includes all features of= a decoder exept the entropy decoding, plus all the search/mode decision me= chanics, forward transform/quantization, assorted filters i.e. for motion c= ompensation, and the entropy encoder). And second, today's hardware based = decoding is not well suited for video conference decoding use, as it does n= ot offer functionalities such as error control or concealment beyond re-syc= hronization after IDR pictures=97and one should avoid IDR pictures in conve= rsational applications because of their size and resulting delay. Stephan --_000_CC3C70F389CACstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,
I promised in the meeting a link to the following doc: JCTVC-J0128
To summarize, using a single core of the iPad3's dual core processor, = software decoding of HEVC (forthcoming H.265) at 720p30 resolution and 1.5 = Mbit/s bitrate is possible.  A fully charged battery is empty after 8 = hours.  This compares to 10 hours when decoding H.264 using hardware acceleration.
My take from this data point is that battery life is not all that much= affected by hardware-based decoding, at least not for tablets and larger d= evices.  If your screen and battery are considerably smaller, but your= processing demands similar, hardware decoding may become more beneficial, relatively speaking.  However, i= f you scale down video resolution with screen size, things ought to be appr= oximately in the same ballpark.
While at this discussion, let me reiterate two other points made in th= e meeting.  First, AFAIK, there are no hardware-accelerated encod= ers in today's products that could meaningfully be used for conversational = applications; encoders run software-only, and their complexity is necessarily considerably higher than that of a dec= oder (because an encoder includes all features of a decoder exept the entro= py decoding, plus all the search/mode decision mechanics, forward transform= /quantization, assorted filters i.e. for motion compensation, and the entropy encoder).  And second,&= nbsp;today's hardware based decoding is not well suited for video conferenc= e decoding use, as it does not offer functionalities such as error control = or concealment beyond re-sychronization after IDR pictures=97and one should avoid IDR pictures in conversational applica= tions because of their size and resulting delay.  
Stephan 
--_000_CC3C70F389CACstewesteweorg_-- From mandyam@quicinc.com Mon Jul 30 12:11:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8F411E81B1 for ; Mon, 30 Jul 2012 12:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.119 X-Spam-Level: X-Spam-Status: No, score=-5.119 tagged_above=-999 required=5 tests=[AWL=1.479, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD2GFEoW4mQN for ; Mon, 30 Jul 2012 12:11:46 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id C92D311E81A4 for ; Mon, 30 Jul 2012 12:11:46 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6788"; a="216026665" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 30 Jul 2012 12:11:47 -0700 X-IronPort-AV: E=Sophos;i="4.77,681,1336374000"; d="scan'208,217";a="299492080" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Jul 2012 12:11:47 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 30 Jul 2012 12:11:46 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.4]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.02.0309.002; Mon, 30 Jul 2012 12:11:46 -0700 From: "Mandyam, Giridhar" To: "rtcweb@ietf.org" Thread-Topic: RTCWeb Data Stream and RTP Synchronization - new I.-D. Thread-Index: Ac1uhw6a/JJcvNvQQAOvCTbyQufuQQ== Date: Mon, 30 Jul 2012 19:11:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627CACCnasanexd01hnaqu_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 30 Jul 2012 18:05:46 -0700 Subject: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 19:11:47 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627CACCnasanexd01hnaqu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNClBsZWFzZSBub3RlIHRoZSBpbnRlcm5ldCBkcmFmdCByZWNlbnRseSB1cGxvYWRl ZDogIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hbmR5YW0tcnRjd2ViLWRhdGEt c3luY2gtMDAgZW50aXRsZWQg4oCcUlRDV2ViIERhdGEgU3RyZWFtIGFuZCBSVFAgU3luY2hyb25p emF0aW9uLuKAnCAgIEFsbCBjb21tZW50cywgc3VnZ2VzdGlvbnMsIHJlcXVlc3RzIGZvciBjbGFy aWZpY2F0aW9uLCBjb3JyZWN0aW9ucyBhcmUgd2VsY29tZS4NCg0KDQoNClRoYW5rcywNCg0KLUdp cmkgTWFuZHlhbSwgUXVhbGNvbW0gSW5ub3ZhdGlvbiBDZW50ZXINCg== --_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627CACCnasanexd01hnaqu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVs bG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIG5vdGUgdGhlIGludGVybmV0IGRyYWZ0IHJlY2VudGx5 IHVwbG9hZGVkOiZuYnNwOyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1tYW5keWFtLXJ0Y3dlYi1kYXRhLXN5bmNoLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1tYW5keWFtLXJ0Y3dlYi1kYXRhLXN5bmNoLTAwPC9hPiBlbnRpdGxlZCDigJxSVENX ZWIgRGF0YSBTdHJlYW0gYW5kIFJUUCBTeW5jaHJvbml6YXRpb24u4oCcICZuYnNwOyZuYnNwO0Fs bCBjb21tZW50cywgc3VnZ2VzdGlvbnMsIHJlcXVlc3RzIGZvciBjbGFyaWZpY2F0aW9uLCBjb3Jy ZWN0aW9ucyBhcmUgd2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LUdpcmkgTWFuZHlhbSwgUXVhbGNvbW0gSW5ub3Zh dGlvbiBDZW50ZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CAC8DBE4E9704C41BCB290C2F3CC921A1627CACCnasanexd01hnaqu_-- From silviapfeiffer1@gmail.com Mon Jul 30 18:18:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709CA11E80EC for ; Mon, 30 Jul 2012 18:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPzTiLudSedo for ; Mon, 30 Jul 2012 18:18:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7795711E8091 for ; Mon, 30 Jul 2012 18:18:47 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5571223vcb.31 for ; Mon, 30 Jul 2012 18:18:47 -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=oh7sT+unrJEgFPDWVvWPrHOunHaGsHtYd6VDtHYmGGM=; b=LG871xHJQJrWVJwZCjwUxnMezF6qv4Xuzt/kmEUjzHbJzyfsZkQ4XnfFbfAYLYC0Qc 6/Llv6nQxnW7bbebd6A1Y8WioNYFmY50p8LGEHtQIMJfy1570mt8VqgSGP/4t5QsZP5T Ha1VojWa/BHy/869A5JAipoOg96sYEr7X/eBPZYbjSrRtU/vwFTDdk+rIhRDIy39g0HL JSLCEnswpZWJ7NU8THwG+qyAoHSQGnEwSojm//WHHiifSZyxqOmJUJysi/PzcDqSxLhb +DBV2BpQbjYVam3qDsxvbhNNDNUZPtcsX4/BrAvWtNbqK4crLnEhub7DPcNS/+tqTrla 1eog== Received: by 10.52.98.101 with SMTP id eh5mr11243267vdb.8.1343697526982; Mon, 30 Jul 2012 18:18:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.9 with HTTP; Mon, 30 Jul 2012 18:18:25 -0700 (PDT) In-Reply-To: References: From: Silvia Pfeiffer Date: Tue, 31 Jul 2012 11:18:25 +1000 Message-ID: To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] non-standard codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 01:18:52 -0000 On Tue, Jul 31, 2012 at 9:01 AM, Stephan Wenger wrote: > Hi Silvia, > > On 7.30.2012 15:18 , "Silvia Pfeiffer" wrote: > >>>> >>>>It's an IETF document and therefore not subject to change without IETF >>>>review. >>> >>> While an RFC is static, this RFC is NOT an IETF document. It's the end >>> result of an independent submission to the RFC editor. It's not an IETF >>> product, and it's not under IETF "change control". Btw., wikipedia got >>> that doc status wrong as well; you are not alone :-) >> >>Oh, I'm fully aware of the informal state of this document. However, >>IETF still has change control - they can still stop any further >>submissions / updates of that document. After all, they are the >>publisher. > > It's an independent submission to the RFC editor, and not an IETF > document. This page explains what those independent submissions are: > http://www.rfc-editor.org/indsubs.html > It is not an IETF document, and the IETF has no change control. The IETF > cannot stop any further submissions or updates unless the IESG finds that > the doc is harmful to the Internet, and AFAIK, the IETF is not the > publisher of the doc. Depends on what you understand by "the IETF". The RFC editor and the IESG can stop it and they are part of IETF processes. Also, the document is published on a ietf.org domain and has the following copyright statement: Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. As I read it, the IETF is the publisher for all intents and purposes. Regards, Silvia. From stewe@stewe.org Mon Jul 30 19:54:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCE911E809C for ; Mon, 30 Jul 2012 19:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyqCNsM8eSB3 for ; Mon, 30 Jul 2012 19:54:48 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id CE04011E8087 for ; Mon, 30 Jul 2012 19:54:48 -0700 (PDT) Received: from mail38-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 02:54:48 +0000 Received: from mail38-co1 (localhost [127.0.0.1]) by mail38-co1-R.bigfish.com (Postfix) with ESMTP id 0B44C920105; Tue, 31 Jul 2012 02:54:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zzc85eh4015Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839he5bhf0ah107ahbe3k) Received-SPF: pass (mail38-co1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail38-co1 (localhost.localdomain [127.0.0.1]) by mail38-co1 (MessageSwitch) id 1343703285758276_17880; Tue, 31 Jul 2012 02:54:45 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.227]) by mail38-co1.bigfish.com (Postfix) with ESMTP id AD6A458015A; Tue, 31 Jul 2012 02:54:45 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 02:54:45 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.193]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0175.005; Tue, 31 Jul 2012 02:54:39 +0000 From: Stephan Wenger To: "Mandyam, Giridhar" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D. Thread-Index: Ac1uhw6a/JJcvNvQQAOvCTbyQufuQQABhYqA Date: Tue, 31 Jul 2012 02:54:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/alternative; boundary="_000_CC3C96D889CD0stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 02:54:49 -0000 --_000_CC3C96D889CD0stewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =85 And the IPR declaration that goes with it: https://datatracker.ietf.org= /ipr/1837/ Good luck with your draft, you'll need it. Stephan From: , Giridhar > Date: Monday, 30 July, 2012 12:11 To: "rtcweb@ietf.org" > Subject: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D. Hello, Please note the internet draft recently uploaded: http://tools.ietf.org/ht= ml/draft-mandyam-rtcweb-data-synch-00 entitled =93RTCWeb Data Stream and RT= P Synchronization.=93 All comments, suggestions, requests for clarificati= on, corrections are welcome. Thanks, -Giri Mandyam, Qualcomm Innovation Center --_000_CC3C96D889CD0stewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8B5F8D3A9C0D7E4A99FBB00B9A34E5A2@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
=85 And the IPR declaration that goes with it: https://datatracker.ietf.org/ipr/1837/<= /div>
Good luck with your draft, you'll need it.
Stephan

From: <Mandyam>, Giridhar <= ;mandyam@quicinc.com>
Date: Monday, 30 July, 2012 12:11 <= br> To: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: [rtcweb] RTCWeb Data Strea= m and RTP Synchronization - new I.-D.

Hello,

Please note the internet draft recently uploaded:&nb=
sp; http://tools.ietf.org/html/draft-mandyam-rtcweb-data-synch-00 entitl=
ed =93RTCWeb Data Stream and RTP Synchronization.=93   All commen=
ts, suggestions, requests for clarification, corrections are welcome.<=
/o:p>
 
Thanks,
-Giri Mandyam, Qualcomm Innovation Center
 --_000_CC3C96D889CD0stewesteweorg_-- From basilgohar@librevideo.org Mon Jul 30 21:44:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4731111E80C5 for ; Mon, 30 Jul 2012 21:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6IGa87cxGIg for ; Mon, 30 Jul 2012 21:44:27 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6B65411E80D2 for ; Mon, 30 Jul 2012 21:44:27 -0700 (PDT) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id E7C1E641511 for ; Tue, 31 Jul 2012 00:44:25 -0400 (EDT) Message-ID: <501762A6.3@librevideo.org> Date: Tue, 31 Jul 2012 00:44:22 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5015D506.5010201@mozilla.com> In-Reply-To: <5015D506.5010201@mozilla.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 04:44:29 -0000 On 07/29/2012 08:27 PM, Timothy B. Terriberry wrote: > Justin Uberti wrote: >> Given the ability to deliver a royalty-free platform with no compromises >> on quality, we see no reason to include mandatory royalty-bearing >> codecs. > > +1 > > As Brendan Eich, Mozilla's CTO, outlined in his article > https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ back > in March, we believe very strongly in keeping WebRTC unencumbered. +1 -- Libre Video http://librevideo.org From stefan.lk.hakansson@ericsson.com Tue Jul 31 02:13:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7B121F86C5 for ; Tue, 31 Jul 2012 02:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXDL8XG3yMG3 for ; Tue, 31 Jul 2012 02:13:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 809BE21F86C6 for ; Tue, 31 Jul 2012 02:13:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-af-5017a1af9eff Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 00.D8.07365.FA1A7105; Tue, 31 Jul 2012 11:13:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Tue, 31 Jul 2012 11:13:19 +0200 Message-ID: <5017A1AD.4070904@ericsson.com> Date: Tue, 31 Jul 2012 11:13:17 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre76heIBBmuXSlus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD3dNxgLFjJXzH2/hKWB8RRTFyMnh4SAicStzTehbDGJC/fW s3UxcnEICZxilJh76iMThLOcUWLP4wOMIFW8AtoSxzpOs4PYLAKqEo1LzjOD2GwCNhJru6eA TRIVCJFY820KVL2gxMmZT1hAbBEBYYmtr3rBaoQFDCT65ixlA7GFBAIkNv6eDVTDwcEpECix eYI3SJhZwEJi8ZuD7BC2vMT2t3OYIcp1Jd69vsc6gVFgFpINs5C0zELSsoCReRWjcG5iZk56 uaFealFmcnFxfp5eceomRmD4HdzyW3cH46lzIocYpTlYlMR5uZL2+wsJpCeWpGanphakFsUX leakFh9iZOLglGpg5JORctuk0n3qw8LGJs0jKw89+e+hZO3NsZ/9dsdpvX+VLVa8Yu3Xbs7K VYu4mXLqLJMa/yPBE9qBUy4aFXs83vOQhe+4yPW76/dvOONnfNg0oqt4n4eLktnSE//bVzx6 uvjnDEnuP9+yFrYsnBOu+mqN7iSnVcqHenj1Xrdt2bZG9Igi6/snDkosxRmJhlrMRcWJAK42 cmgNAgAA Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 09:13:21 -0000 On 07/30/2012 02:14 AM, Justin Uberti wrote: ... > > On the audio side, we believe that Opus should be the default > mandatory-to-implement audio codec, assuming the remaining licensing > issues can be resolved. What are the remaining licensing issues? Any plan/schedule for resolving them? (I guess this in a way belongs to the codec WG, but is also relevant for rtcweb if Opus is going to be MTI). From likepeng@huawei.com Tue Jul 31 02:27:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0CB21F86D4 for ; Tue, 31 Jul 2012 02:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUP5Mi+yHgjr for ; Tue, 31 Jul 2012 02:27:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC321F86D1 for ; Tue, 31 Jul 2012 02:27:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM54953; Tue, 31 Jul 2012 05:27:46 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 02:25:03 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 02:25:02 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Tue, 31 Jul 2012 17:24:59 +0800 From: Likepeng To: Justin Uberti Thread-Topic: [rtcweb] Fw: New Version Notification for draft-li-rtcweb-jsep-xmpp-mapping-00.txt Thread-Index: AQHNbiTIl1A6XHCWTUGcMhcvyZeTZ5dBi+BwgAABaICAAZKREA== Date: Tue, 31 Jul 2012 09:24:59 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F207BD4F1F@szxeml525-mbx.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F207BD4A03@szxeml525-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.124] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD4F1Fszxeml525mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fw: New Version Notification for draft-li-rtcweb-jsep-xmpp-mapping-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 09:27:47 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD4F1Fszxeml525mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZmVlZGJhY2suDQoNCkkg d2lsbCBtYWtlIGEgcmV2aXNpb24gdG8gaW5jbHVkZSB0aGVtLg0KDQpLaW5kIFJlZ2FyZHMNCktl cGVuZw0KDQrlj5Hku7bkuro6IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5j b21dDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ35pyIMzHml6UgMToyMg0K5pS25Lu25Lq6OiBMaWtl cGVuZw0K5oqE6YCBOiBydGN3ZWJAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtydGN3ZWJdIEZ3OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAtbWFw cGluZy0wMC50eHQNCg0KTGlrZXBlbmcsDQoNClRoaXMgZHJhZnQgc2hvd3MgaG93IEpTIGNsaWVu dHMgY291bGQgdXNlIHRoZSBKaW5nbGUgcHJvdG9jb2wgdG8gZXN0YWJsaXNoIGEgc2Vzc2lvbiwg YnV0IEkgZGlkbid0IHNlZSBhIHNlY3Rpb24gd2hlcmUgaXQgZXhwbGFpbnMgaG93IHRvIG1hcCB0 aGUgSmluZ2xlIG1lc3NhZ2VzIHRvIHRoZSBKU0VQIEFQSSwgb3IgdGhlIHBheWxvYWRzIG9mIHRo ZXNlIG1lc3NhZ2VzIHRvIFNEUCAoYXMgcmVxdWlyZWQgYnkgdGhlIEFQSSkuDQoNCkkgdGhpbmsg dGhpcyBjb3VsZCBiZSBlYXNpbHkgYWRkZWQgLSBmb3IgZXhhbXBsZSwgYSByZWNlaXZlZCBzZXNz aW9uLWluaXRpYXRlIHdpbGwgbWFwIHRvIGEgc2V0UmVtb3RlRGVzY3JpcHRpb24gLSBidXQgaW4g b3JkZXIgZm9yIGEgZGV2ZWxvcGVyIHRvIGltcGxlbWVudCBhbiBKaW5nbGUgY2xpZW50IGluIEpT LCB0aGVzZSBtYXBwaW5ncyBuZWVkIHRvIGJlIGNsZWFybHkgZGVmaW5lZC4NCg0KT24gTW9uLCBK dWwgMzAsIDIwMTIgYXQgMjoyMCBBTSwgTGlrZXBlbmcgPGxpa2VwZW5nQGh1YXdlaS5jb208bWFp bHRvOmxpa2VwZW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCldlbGNvbWUgeW91ciBjb21tZW50cyB0 byB0aGlzIGRyYWZ0Lg0KDQpIYXZlIGEgbmljZSBtZWV0aW5nIGluIFZhbmNvdXZlciENCg0KS2lu ZCBSZWdhcmRzDQpLZXBlbmcNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+XQ0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0N+aciDMw5pelIDE1OjI3DQrmlLbku7bkuro6 IExpa2VwZW5nDQrmioTpgIE6IExpa2VwZW5nDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAwLnR4dA0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAwLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXBlbmcgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC1saS1ydGN3 ZWItanNlcC14bXBwLW1hcHBpbmcNClJldmlzaW9uOiAgICAgICAgMDANClRpdGxlOiAgICAgICAg ICAgUlRDV2ViIEpTRVAgWE1QUC9KaW5nbGUgTWFwcGluZw0KQ3JlYXRpb24gZGF0ZTogICAyMDEy LTA3LTMwDQpXRyBJRDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9m IHBhZ2VzOiAxMA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDAudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktcnRjd2Vi LWpzZXAteG1wcC1tYXBwaW5nDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAtbWFwcGluZy0wMA0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgbWFwcGluZyBtZXNzYWdlIHJlcHJlc2VudGF0aW9u cyBiZXR3ZWVuIFJUQ1dlYg0KICAgSmF2YXNjcmlwdCBTZXNzaW9uIEVzdGFibGlzaG1lbnQgUHJv dG9jb2woSlNFUCkgc2NoZW1lIGFuZCBYTVBQLw0KICAgSmluZ2xlIFtYRVAtMDE2Nl0gbWVzc2Fn aW5nIHNjaGVtZS4gIFN1Y2ggYSBzaWduYWxpbmcgbWFwcGluZyBpcw0KICAgaW50ZW5kZWQgdG8g ZW5hYmxlIEphdmFzY3JpcHQgdG8gdXNlIFhNUFAvSmluZ2xlIHRvIGVzdGFibGlzaCBhDQogICBz ZXNzaW9uIGJldHdlZW4gdHdvIFJUQ1dlYiBlbmFibGVkIGJyb3dzZXJzLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD4F1Fszxeml525mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65Y2O5paH57uG6buROw0KCXBhbm9zZS0xOjIg MSA2IDAgNCAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMi Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEDljY7mlofnu4bpu5EiOw0KCXBhbm9zZS0xOjIgMSA2IDAgNCAxIDEgMSAxIDE7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZmVlZGJhY2suPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5J IHdpbGwgbWFrZSBhIHJldmlzaW9uIHRvIGluY2x1ZGUgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PktpbmQgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5LZXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBKdXN0aW4gVWJlcnRp IFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ IDIwMTI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9 IkVOLVVTIj43PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4zMTwvc3Bhbj7ml6U8c3BhbiBs YW5nPSJFTi1VUyI+IDE6MjI8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gTGlrZXBlbmc8YnI+DQo8L3NwYW4+ PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gcnRjd2ViQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbcnRjd2ViXSBGdzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmct MDAudHh0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGlrZXBlbmcsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBkcmFmdCBzaG93cyBob3cgSlMgY2xpZW50 cyBjb3VsZCB1c2UgdGhlIEppbmdsZSBwcm90b2NvbCB0byBlc3RhYmxpc2ggYSBzZXNzaW9uLCBi dXQgSSBkaWRuJ3Qgc2VlIGEgc2VjdGlvbiB3aGVyZSBpdCBleHBsYWlucyBob3cgdG8gbWFwIHRo ZSBKaW5nbGUgbWVzc2FnZXMgdG8gdGhlIEpTRVAgQVBJLCBvciB0aGUgcGF5bG9hZHMgb2YgdGhl c2UgbWVzc2FnZXMgdG8gU0RQDQogKGFzIHJlcXVpcmVkIGJ5IHRoZSBBUEkpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGlzIGNvdWxk IGJlIGVhc2lseSBhZGRlZCAtIGZvciBleGFtcGxlLCBhIHJlY2VpdmVkIHNlc3Npb24taW5pdGlh dGUgd2lsbCBtYXAgdG8gYSBzZXRSZW1vdGVEZXNjcmlwdGlvbiAtIGJ1dCBpbiBvcmRlciBmb3Ig YSBkZXZlbG9wZXIgdG8gaW1wbGVtZW50IGFuIEppbmdsZSBjbGllbnQgaW4gSlMsIHRoZXNlIG1h cHBpbmdzIG5lZWQgdG8gYmUgY2xlYXJseSBkZWZpbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTW9uLCBK dWwgMzAsIDIwMTIgYXQgMjoyMCBBTSwgTGlrZXBlbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpsaWtl cGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGlrZXBlbmdAaHVhd2VpLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5XZWxjb21lIHlvdXIgY29tbWVudHMgdG8gdGhpcyBkcmFmdC48YnI+ DQo8YnI+DQpIYXZlIGEgbmljZSBtZWV0aW5nIGluIFZhbmNvdXZlciE8YnI+DQo8YnI+DQpLaW5k IFJlZ2FyZHM8YnI+DQpLZXBlbmc8YnI+DQotLS0tLTwvc3Bhbj7pgq7ku7bljp/ku7Y8c3BhbiBs YW5nPSJFTi1VUyI+LS0tLS08YnI+DQo8L3NwYW4+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi PjogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPg0KPC9zcGFuPuWPkemA geaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46IDIwMTI8L3NwYW4+5bm0PHNwYW4gbGFuZz0iRU4t VVMiPjc8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjMwPC9zcGFuPuaXpTxzcGFuIGxhbmc9 IkVOLVVTIj4gMTU6Mjc8YnI+DQo8L3NwYW4+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjog TGlrZXBlbmc8YnI+DQo8L3NwYW4+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjogTGlrZXBlbmc8 YnI+DQo8L3NwYW4+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDAudHh0PGJyPg0K PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAtbWFw cGluZy0wMC50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtlcGVu ZyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpGaWxl bmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtbGktcnRjd2ViLWpzZXAteG1w cC1tYXBwaW5nPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJy Pg0KVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUlRDV2ViIEpTRVAg WE1QUC9KaW5nbGUgTWFwcGluZzxicj4NCkNyZWF0aW9uIGRhdGU6ICZuYnNwOyAyMDEyLTA3LTMw PGJyPg0KV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVh bCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiAxMDxicj4NClVSTDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAw LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbGktcnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nLTAwLnR4dDwvYT48YnI+DQpTdGF0 dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLXJ0Y3dlYi1qc2VwLXhtcHAtbWFwcGluZyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGkt cnRjd2ViLWpzZXAteG1wcC1tYXBwaW5nPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s aS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1ydGN3ZWItanNlcC14bXBwLW1hcHBpbmctMDA8L2E+ PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgcHJv cG9zZXMgbWFwcGluZyBtZXNzYWdlIHJlcHJlc2VudGF0aW9ucyBiZXR3ZWVuIFJUQ1dlYjxicj4N CiZuYnNwOyAmbmJzcDtKYXZhc2NyaXB0IFNlc3Npb24gRXN0YWJsaXNobWVudCBQcm90b2NvbChK U0VQKSBzY2hlbWUgYW5kIFhNUFAvPGJyPg0KJm5ic3A7ICZuYnNwO0ppbmdsZSBbWEVQLTAxNjZd IG1lc3NhZ2luZyBzY2hlbWUuICZuYnNwO1N1Y2ggYSBzaWduYWxpbmcgbWFwcGluZyBpczxicj4N CiZuYnNwOyAmbmJzcDtpbnRlbmRlZCB0byBlbmFibGUgSmF2YXNjcmlwdCB0byB1c2UgWE1QUC9K aW5nbGUgdG8gZXN0YWJsaXNoIGE8YnI+DQombmJzcDsgJm5ic3A7c2Vzc2lvbiBiZXR3ZWVuIHR3 byBSVENXZWIgZW5hYmxlZCBicm93c2Vycy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlh dDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_34966E97BE8AD64EAE9D3D6E4DEE36F207BD4F1Fszxeml525mbxchi_-- From harald@alvestrand.no Tue Jul 31 09:03:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF3621F863F for ; Tue, 31 Jul 2012 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.324 X-Spam-Level: X-Spam-Status: No, score=-110.324 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVkuSU7AHI1z for ; Tue, 31 Jul 2012 09:03:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 42A8321F8620 for ; Tue, 31 Jul 2012 09:03:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A913839E127 for ; Tue, 31 Jul 2012 18:03:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeXfMF0d8Bt2 for ; Tue, 31 Jul 2012 18:03:23 +0200 (CEST) Received: from [IPv6:2001:df8:0:80:221:6aff:fe8f:cf14] (unknown [IPv6:2001:df8:0:80:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 01E7539E031 for ; Tue, 31 Jul 2012 18:03:22 +0200 (CEST) Message-ID: <501801DB.3030600@alvestrand.no> Date: Tue, 31 Jul 2012 09:03:39 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010001060305010105000709" Subject: Re: [rtcweb] RTCWeb Data Stream and RTP Synchronization - new I.-D. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 16:03:36 -0000 This is a multi-part message in MIME format. --------------010001060305010105000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/30/2012 12:11 PM, Mandyam, Giridhar wrote: > > Hello, > > Please note the internet draft recently uploaded:http://tools.ietf.org/html/draft-mandyam-rtcweb-data-synch-00 entitled "RTCWeb Data Stream and RTP Synchronization." All comments, suggestions, requests for clarification, corrections are welcome. > Hello - I scanned your draft quickly, and I see a lot of talk about signaling that synchronization between data tracks and RTP tracks is requested, but nothing about how you intended to represent timestamps in SCTP. Could you clarify what timestamps you intended to synchronize? Harald > Thanks, > -Giri Mandyam, Qualcomm Innovation Center > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------010001060305010105000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/30/2012 12:11 PM, Mandyam, Giridhar wrote:

Hello,

Please note the internet draft recently uploaded:  http://tools.ietf.org/html/draft-mandyam-rtcweb-data-synch-00 entitled “RTCWeb Data Stream and RTP Synchronization.“   All comments, suggestions, requests for clarification, corrections are welcome.
 
Hello - I scanned your draft quickly, and I see a lot of talk about signaling that synchronization between data tracks and RTP tracks is requested, but nothing about how you intended to represent timestamps in SCTP.

Could you clarify what timestamps you intended to synchronize?

                 Harald

Thanks,
-Giri Mandyam, Qualcomm Innovation Center


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


--------------010001060305010105000709-- From stefan.lk.hakansson@ericsson.com Tue Jul 31 13:01:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C2F21F8898 for ; Tue, 31 Jul 2012 13:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3S9Wm7xgq5x for ; Tue, 31 Jul 2012 13:01:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3FB21F888D for ; Tue, 31 Jul 2012 13:01:00 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-6e-5018397b7661 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DB.49.12641.B7938105; Tue, 31 Jul 2012 22:00:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Tue, 31 Jul 2012 22:00:58 +0200 Message-ID: <50183978.9010500@ericsson.com> Date: Tue, 31 Jul 2012 22:00:56 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <03FBA798AC24E3498B74F47FD082A92F177082F7@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F177082F7@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+JvrW61pUSAwbZDEhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49e+hUwFa70qFi6ex9TA2GzTxcjJISFgIrHr0AF2CFtM4sK9 9WxdjFwcQgKnGCXamiYzQjjLGSV+z2pgA6niFdCWOPLjMXMXIwcHi4CqxOtuO5Awm4CNxNru KUwgtqhAiMSab1MYIcoFJU7OfMICYosIqEtcfngBbJkwkP3y1V9WEFtIIEZiwc8XYL2cArES 80/MYgQZzyxgL/FgaxlImFlAXqJ562xmiHJdiXev77FOYBSYhWTDLISOWUg6FjAyr2IUzk3M zEkvN9dLLcpMLi7Oz9MrTt3ECAy9g1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2M1ufj13pZfv69yiZE05vDsumu/YJHqZx2Uz7n7XwaEVdzuIyH7dnj CKu2iy+r5tb1TKx4IdertjfK2Xa6Tqjdse4C5+C9skILtGxfFD19/au3ueeBjfWjw7MLs4qn lfyKXf3mBKP/HK9WIfHQ02sm3Jt6UWfpo9s8ieWH85XV5vZbqbhq/H2ixFKckWioxVxUnAgA iUzI1AsCAAA= Subject: Re: [rtcweb] jsep 01 comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 20:01:02 -0000 On 07/05/2012 09:42 PM, Ejzak, Richard P (Richard) wrote: ... > In the paragraph before figure 2 in section 4.2, the text justifies the > notion of multiple outstanding offers and answers based on RFC 3264. > This is incorrect. RFC 3264 very clearly describes (in section 4) how > each offer cannot be updated until an answer is received and that an > answer is final. This should be made clear in jsep. The actual > justifications for multiple outstanding offers and answers should be > made clear and their use within the context of RFC 3264 needs to be made > clear. I agree, those things should be clarified. I am especially interested in that the following is clearly described: * "OFFER-OFFER" which can be used to avoid glare (according to [1]) when both sides add/remove streams simultaneously. This seems like a really useful technique as the number of potential glare situations can be reduced. However, I can't find any info on in what circumstances it is possible, and it also seems to violate the state diagram in [2] (basically the browser would be in two states at the same time: sentOffer and receviedOffer). * The possibility to update certain parts of the session without an offer/answer that Justing mentioned in the rtcweb session Monday/Vancouver. It was specifically mentioned in the context of sending updated imageattributes without waiting for the answer of the previous one sent. This seems to be applicable to certain parts of the session and not others, and this should be described (so that apps can utilize this, and so that different implementations are working the same in this respect). [1] http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-8.pdf, slide 16 [2] https://docs.google.com/document/d/13TYiNSEmFkB7IeNLEJFxI0xMNk8q_LhXE_hbvFbXRTU/edit# Stefan Specifically within the context of SIP, there is no > justification or support for multiple offers, and the only justification > for multiple answers is to provide a limited mechanism for dealing with > some SIP forking cases. > > The 2^nd paragraph of section 4.5 should make clear that XMPP is an > example application supporting the capability (ICE trickling) and SIP is > not. > > In section 4.7, it should be made clear that SIP forking is being > considered (with clear references) and any XMPP analogs, if they exist. > Obviously section 4.7.2 should indicate cloning as a possible strategy > to fully address parallel forking that is not currently supported. The > text should describe that in the absence of cloning ICE and DTLS may not > begin until a “winning” target is selected, thus potentially delaying > the start of media flow, whereas ICE and DTLS could occur in parallel > were cloning supported. > > Section 4.8 needs updating. It is not clear from the description if a > new PeerConnection needs to be established (or how to re-establish the > old one) and how to ensure that the new PeerConnection will be > compatible with the old LocalDescription. I think the description > should say that PeerConnection is recreated using the old parameters and > (reconstructed?) MediaStreams. Something is also needed to describe how > to ensure the continued availability of the old MediaStreams. > Rehydration will require end-to-end offer/answer to recreate the > PeerConnection anyway, and I’m not sure of the value of attempting to > reuse the old LocalDescription since it may not make sense to force some > of the old attributes. Some discussion of how to ensure this is needed > if the concept of reusing the old LocalDescription (and MediaStreams) is > retained. > > In section 5.1.1, the first paragraph describes createOffer the first > time it is invoked but not necessarily its behavior for subsequent > invocations. The last sentence of the 2^nd paragraph is inconsistent > with the last sentence of the first paragraph under some circumstances. > The local description used to populate the offer once the session is > established, but may come in three flavors (noting that an offerer may > later become an answerer for the same PeerConnection and vice versa): 1) > the local description set by the prior offerer before receiving a final > answer (thus reflecting all supported codecs and capabilities according > to the constraints); 2) the local description set by the prior answerer > (thus reflecting only the selected codecs and capabilities); and 3) the > local description set by the prior offerer but where createOffer occurs > after receiving final answer to the previous offer (in this case the > offer may include codecs and capabilities already released by the browser). > > The last paragraph of section 5.1.1 describes that in case 3) the offer > should be modified to reflect the “current state of the system”. It’s > not completely clear if this is intended to describe the current > resources allocated to the PeerConnection or the potential resources > that could be allocated (i.e., the full set of available codecs and > capabilities). It is similarly unclear for case 2) if the offer is to > be changed and how. > > The last sentence of the second paragraph of section 5.1.1 is also > inconsistent with the last paragraph of the section and it is not clear > which one takes precedence. > > This potential inconsistency in the behavior of createOffer is > problematic to an application since the range of capabilities reflected > in the SDP is state dependent. The result of createOffer should not > depend on whether the browser was previously offerer or answerer and it > should be possible to request either current capabilities or the > complete list of potential capabilities for each unchanged m line in the > offer using the constraints parameter. > > I was asked during the interim to justify the need for a “full” offer as > compared to an offer that just reflects the current capabilities. There > are many examples in SIP where a node is sent an “empty re-INVITE” or a > “REFER with REPLACES” during a session to trigger the node to send a new > SDP offer to renegotiate media. This may be triggered due to an > interface change, a network server (e.g., acting as B2BUA) moving the > media to another endpoint such as a conference server, etc. In all > these cases there is no guarantee that the new target will support the > same codecs or have the same capabilities, so the best way forward is to > create a “full” offer to make it most likely that an acceptable media > configuration can be achieved in a single offer/answer transaction. > There are other cases where it may be acceptable to send a “minimal” > offer, but only the application can determine which one is needed. > > The 3^rd paragraph of 5.1.2 says that createAnswer should also reflect > the “current state” of the system. It is very confusing to use the same > words to describe createOffer and createAnswer since they should not > mean the same thing. The text should be clarified to distinguish > between these two cases. > > There is a great need for a new section (possibly a subsection of 4) > that describes the relationship between MediaStreams and media lines. > An rtcweb MediaStream is not the same as an RFC 3264 media stream, > thus causing endless potential for confusion (I admit to being one of > the victims). An RFC 3264 media stream is more akin to a > MediaStreamTrack, and even that is not completely accurate since we will > allow multiple MediaStreamTracks per m line. How does the browser > decide how to allocate MediaStreamTracks to m lines? The easy solution > is to assign each track to a separate m line but this is wasteful when > multiple tracks carry the same media type. But not all tracks of the > same media type should be forced to use the same m line since it may be > necessary to negotiate different capabilities for these tracks. It must > somehow be made clear to the browser which tracks can be combined on an > m line and which cannot so that it can generate an appropriate offer > with the proper number of m lines. > > In section 5.1.4, it should be pointed out that the need to support both > old and new local descriptions means that the PeerConnection must in > some sense be “cloned” since there may be completely different remote > candidates and codecs selected for use with the new description and both > configurations need to be simultaneously supported for an interim > period. It is also not explained how to remove the new configuration if > the 2^nd offer/answer fails. I do not think that the state diagram > supports a transition from offer state or pranswer state back to stable > state without processing a valid answer. Note this is also another > implicit meaning of pranswer that should be described for subsequent > offer/answer transactions – both the old and new configurations need to > be supported until receipt of final answer or failure is indicated. > > Sections 5.1.6 and 5.1.7 should clarify the relationship between the > local/remote description and the actual resources allocated. One of > them usually reflects the configured resources while the other is > generally a superset. If this is not the intended semantic, then that > should also be clarified. > > In section 5.2, I believe the RTP header extension attribute in RFC 5285 > is a=extmap rather than a=rtphdr-ext. > > Richard > From singer@apple.com Tue Jul 31 15:12:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AB421F8869 for ; Tue, 31 Jul 2012 15:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijqb9ZL9zr01 for ; Tue, 31 Jul 2012 15:12:21 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7C521F8867 for ; Tue, 31 Jul 2012 15:12:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M8100AB0NE59GT9@mail-out.apple.com> for rtcweb@ietf.org; Tue, 31 Jul 2012 15:12:20 -0700 (PDT) X-AuditID: 11807112-b7f796d000000feb-4a-50185844f9df Received: from singda.apple.com (singda.apple.com [17.197.32.11]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 4A.53.04075.44858105; Tue, 31 Jul 2012 15:12:20 -0700 (PDT) From: David Singer In-reply-to: <501640E3.1000009@jesup.org> Date: Tue, 31 Jul 2012 15:12:20 -0700 Message-id: <3425F545-99A6-4CAD-8ECD-E888275A27DD@apple.com> References: <5015D506.5010201@mozilla.com> <5015E6FF.2000804@reavy.org> <5015FBE7.9060809@thaumas.net> <501640E3.1000009@jesup.org> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRPKrAresSIRFgMPW1scXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+NTYwlzwlLWi99wltgbGqyxdjBwcEgImEtO+e3YxcgKZYhIX 7q1n62Lk4hASmM4ksXnBAyaQBLOAlsSNfy/BbF4BPYnZ7XNYQGxhAQOJvjlL2UBsNgFViQdz jjGCzOQU0JTYvNAOJMwCFD68EKKcWUBbYtnC18wQY2wkjnZ0sEDsOsEosf7kbnaQhIiAusTl hxfYIQ6Slfh++DzbBEa+WUjOmIXkjFlI5i5gZF7FKFiUmpNYaWiul1hQkJOql5yfu4kRFEgN hUI7GO/v0jvEKMDBqMTD26AmESDEmlhWXJl7iFGCg1lJhJd1hXiAEG9KYmVValF+fFFpTmrx IUZpDhYlcd5/y4UChATSE0tSs1NTC1KLYLJMHJxSDYwewe9qZ+aUT2Vximpc+rWS+/mzbbP3 qlW9PNFaKHbs4TTe8Ly0V0KLNBS09ppMDVI4eMSopt92ht9T+1al8qhpH/5uMs8PDLj0huNC QbrIqvnH/Lk5205yq0YvtXwQs4utdGmD4JaG1n8q7jbHS5/OlAx2ZshXzZoXf898mZe9p+Uv pVoJTSWW4oxEQy3mouJEABrz1sogAgAA Subject: Re: [rtcweb] Google statement on codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 31 Jul 2012 22:12:22 -0000 On Jul 30, 2012, at 1:08 , Randell Jesup wrote: > On 7/29/2012 8:13 PM, Ralph Giles wrote: >> On 12-07-29 6:44 PM, Maire Reavy wrote: >> >>> Mandating encumbered codecswould force open-source projects to violate >>> the spec (by not implementing a mandatory codec). For this reason and >>> the reasons Justin cites, we believe Opus, G.711 and VP8 are the best >>> mandatory-to-implement choices for the spec. >> +1 > There are open-source implementations of encumbered codecs (e.g. x264); and I expect that there are proprietary codecs that are believed to be unencumbered :-). Let's not confuse the two classes. David Singer Multimedia and Software Standards, Apple Inc.