From tim@phonefromhere.com Sun Apr 1 10: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 74B8C21F8B68 for ; Sun, 1 Apr 2012 10:35:43 -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 sIAmJFAdSgVR for ; Sun, 1 Apr 2012 10:35:43 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id D703221F8B66 for ; Sun, 1 Apr 2012 10:35:42 -0700 (PDT) Received: from [192.168.157.66] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 1439E37A902 for ; Sun, 1 Apr 2012 18:44:50 +0100 (BST) From: Tim Panton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Apr 2012 18:35:40 +0100 Message-Id: <4C7C1012-7846-4D38-990E-605300F6EF32@phonefromhere.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [rtcweb] The importance of selecting a realistic mandatory video 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: Sun, 01 Apr 2012 17:35:43 -0000 In the ITEF 83 meeting I put forward the importance of a common video = codec, "even if it is a grotty one". What I tried to convey and may not have got over is that it needs to be = a codec that all the browser vendors will actually deliver, ideally in their first production = releases of RTCweb. Whilst a common codec is desirable for interop, it isn't essential, = there can/will be transcoding proxies which will paper over the differences and RTCweb can still succeed. However if we see widespread use of transcoding, we will lose 2 of = RTCweb's most exciting properties. 1) True P2P - i.e. the case where ICE can negotiate a direct connection = behind a big NAT 2) security for calls over untrusted networks. I am looking at use-cases for RTCweb where these are very important = properties - think disaster relief for example, without them RTCweb will be significantly harder to deploy over adhoc = mesh wifis where the connection to the internet is very low bandwidth = (if it exists at all) but where the meshed nodes can cover quite a big = area with decent, if variable, throughput. For these cases it is essential we mandate a codec that will be = delivered by _everyone_ . I don't care which it is. The same arguments go for a mandated audio codec=20 - with the additional requirements that it needs to be resilient to packetloss (probably have FEC) and able to dynamically adjust bitrate to = cope with the mesh changing topology. Tim.= From basilgohar@librevideo.org Sun Apr 1 12:27: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 7185C21F88CD for ; Sun, 1 Apr 2012 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 rRqbve4wDKUU for ; Sun, 1 Apr 2012 12:27:05 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED1521F88CF for ; Sun, 1 Apr 2012 12:27:05 -0700 (PDT) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id DA6EB64FD82 for ; Sun, 1 Apr 2012 15:27:00 -0400 (EDT) Message-ID: <4F78AC01.30107@librevideo.org> Date: Sun, 01 Apr 2012 15:26:57 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4C7C1012-7846-4D38-990E-605300F6EF32@phonefromhere.com> In-Reply-To: <4C7C1012-7846-4D38-990E-605300F6EF32@phonefromhere.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] The importance of selecting a realistic mandatory video 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: Sun, 01 Apr 2012 19:27:06 -0000 On 04/01/2012 01:35 PM, Tim Panton wrote: > In the ITEF 83 meeting I put forward the importance of a common video codec, "even if it is a grotty one". > What I tried to convey and may not have got over is that it needs to be a codec that all the browser > vendors will actually deliver, ideally in their first production releases of RTCweb. > > Whilst a common codec is desirable for interop, it isn't essential, there can/will be transcoding proxies > which will paper over the differences and RTCweb can still succeed. > > However if we see widespread use of transcoding, we will lose 2 of RTCweb's most exciting properties. > > 1) True P2P - i.e. the case where ICE can negotiate a direct connection behind a big NAT > 2) security for calls over untrusted networks. > > I am looking at use-cases for RTCweb where these are very important properties - think disaster relief for example, > without them RTCweb will be significantly harder to deploy over adhoc mesh wifis where the connection to the internet is very low bandwidth (if it exists at all) but where the meshed nodes can cover quite a big area with > decent, if variable, throughput. > > For these cases it is essential we mandate a codec that will be delivered by _everyone_ . I don't care which it is. > > The same arguments go for a mandated audio codec > - with the additional requirements that it needs to be resilient to > packetloss (probably have FEC) and able to dynamically adjust bitrate to cope with the mesh changing topology. > > Tim. Tim, You bring up a very good point. I will make and explain the case for my suggestions here. For audio, there is a format that is in the final stages of being finalized that exceeds anything else out there in nearly all metrics, namely, Opus[1]. Opus is a royalty-free, free and open-source audio codec that features high quality, efficiency, and latency. Several of the devs are on this list, so I will let them respond about the issue of FEC, but I think this is present as well. It was desired with this kind of usage in mind, and is a merger of the CELT "music" codec and Skype's SILK voice codec. In short, Opus is a shoe-in for audio for WebRTC, as it is superior in every category to anything that could come reasonably close to be sufficient for its needs. For video, we get back to the same discussion as has come-up time and again. The crux of your point is to avoid the need for a defacto deployment by implementors of wide-scale transcoding in conjunction with WebRTC as that would introduce undesirable side effects. I don't think anyone here disagrees with you, as having as unhindered a connection as possible is ideal in communications. The problem is there are vested interests that will choose one video format over another for reasons that are unsympathetic to all sides. For this reason, it's important to fall back onto the reasoning for the success of the Internet as a universal medium for communication, and that has been due, in no small part, to the adoption of technologies that provide no legal barrier to their implementation. As you can probably see, I am making the case for VP8 to be the format of choice for this reason. VP8 provides absolutely no barrier to adoption to a new player in the field of realtime communications, and a minimal one to someone that's already a player. Implementations in both hardware and software exist for VP8, and the developers have made realtime communications a focus for design choices, as well as quality, efficiency, and performance. As a baseline video format, it doesn't get better than VP8. Will this prevent others from implementing transcoding as part of their WebRTC infrastructure? We cannot force nor guarantee that (except by explicitly stating that in the spec, which I think is a bad idea for the few cases where such a tranform would be needed and/or useful). But we can at least lower the barrier of participation for new players so that they can implement WebRTC without requiring additional licenses. VP8 will allow for that, and make long-term, sustainable adoption of the standard that much easier. -- Libre Video http://librevideo.org From juberti@google.com Sun Apr 1 20:17: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 4B82E11E8085 for ; Sun, 1 Apr 2012 20:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.821 X-Spam-Level: X-Spam-Status: No, score=-99.821 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ETDjAhtJFNYi for ; Sun, 1 Apr 2012 20:17:10 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 277BF11E80A3 for ; Sun, 1 Apr 2012 20:17:09 -0700 (PDT) Received: by qafi31 with SMTP id i31so1812024qaf.15 for ; Sun, 01 Apr 2012 20:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=fStNSKNaw8SWHnXrJtXPwX4siN28CLlyRstUg2eUeKU=; b=Z5O8NUMngYBEgOM8nI8759WCxxu8u7a+xPKzT41g2sRR1fg3zTKKGy1Lng2hFqLvk2 GFJcsyI3ZDR874IoFK4I5JCPHnTNuEJIcm3+4pW5vkr8/iABQ5mdtEeEvCeLYqpf4RmM SPL/txjz91glnN3ip9j6j5443MKE5tIuNNYxDmNdH6eUkvFrQMubnTq/YxTf/HYjfP6e eJrzHOmENf+2sBRska/4QqSWrxaeZSNb+I1f8pVWODjC32fgz6zUS1qYKK2eZgYYy4HW ZYjfcv0yiXsC01cl1LkSy7tUUYFy3jfY7t7j516pQyM7olphM20jXY/csFgDSYfuv4u2 Zgxg== 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=fStNSKNaw8SWHnXrJtXPwX4siN28CLlyRstUg2eUeKU=; b=Y6UCcendWCLzjyjAGFP9m1CrsiQ9EFGTs0JO8WKlvl0HQe8QQ1kOT34uVC6zOrKOkk 1nPKseoef3T93OUIlvlfCA1V8dnHSopDCP7tcpS7NDVMylYohM4K+pi1NhsnG75xgEMo 4kuAgLSFP2aIYkLqnrnD+Ifb1oRrWsqD5hQmWKLQnasQqayn37Oh4FqDj9ei3MGmzRgf fhwU1YlZunkTabjcDm/DJas/d8bz7Rf8LcDg1L9zD36CvFG5Xj6o5TmLVAqHsRlD3Mfd mdOyK/3DpWpF2klcbnMH3sOOezZy0WanG7o9dMzaQr2knAJbokbsznY5f5d5+9/9APjL ySqQ== Received: by 10.224.218.195 with SMTP id hr3mr9084913qab.26.1333336629571; Sun, 01 Apr 2012 20:17:09 -0700 (PDT) Received: by 10.224.218.195 with SMTP id hr3mr9084904qab.26.1333336629442; Sun, 01 Apr 2012 20:17:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Sun, 1 Apr 2012 20:16:49 -0700 (PDT) In-Reply-To: <4F7698EF.1090306@ericsson.com> References: <4F7575FB.8010201@ericsson.com> <4F762813.6040506@jesup.org> <4F76937B.9020901@ericsson.com> <4F7698EF.1090306@ericsson.com> From: Justin Uberti Date: Sun, 1 Apr 2012 23:16:49 -0400 Message-ID: To: Stefan Hakansson LK Content-Type: multipart/alternative; boundary=20cf3005dc4029f92c04bca9a0be X-System-Of-Record: true X-Gm-Message-State: ALoCoQksvaoQZSdcN1cktv3xb6+nAENAOYp5Tv3qzHiyIpQZD+SxcOSMGZeubytFO75RL7TUiII0B+7mQsZ04XtzNTo51EV1dS8IkSG5Vwa5F9PrhcDMCSCiNAfbNg2WZqzrF7PnmRGE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interaction between MediaStream API and signaling 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 Apr 2012 03:17:11 -0000 --20cf3005dc4029f92c04bca9a0be Content-Type: text/plain; charset=UTF-8 On Sat, Mar 31, 2012 at 1:41 AM, Stefan Hakansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 03/31/2012 07:17 AM, Stefan Hakansson LK wrote: > >> On 03/30/2012 11:39 PM, Randell Jesup wrote: >> >>> On 3/30/2012 4:59 AM, Stefan Hakansson LK wrote: >>> >>>> The JS API has deals with MediaStreams (this is what you send and >>>> receive using PeerConnection from an application perspective). >>>> >>>> A browser receiving RTP streams, needs side info to be able to >>>> assemble those RTP streams into MediaStreams in a correct way. The >>>> current model is that this is signaled using SDP exchanges (where >>>> Haralds MSID proposal would tell which MediaStream an RTP stream >>>> belongs to). >>>> >>>> As I brought up at the mike yesterday, I think we may have a race >>>> condition for the responder. >>>> >>>> For the initiator side browser, this is clear: once an (PR-)ANSWER is >>>> received, the responder has received the SDP, and hence can map >>>> incoming RTP streams into MediaStreams. >>>> >>>> But for the responder side this is less clear to me. Imagine >>>> applications where the responder just mirrors the initiator - if one >>>> of the parties adds a MediaStream to PeerConnection, the other end >>>> would add the corresponding MediaStream. >>>> >>>> This can happen any time in the session, so ICE can very well be up >>>> and running. One example could be that the data channel is used for >>>> text chat, when one side clicks a button to start video. And the >>>> application can have asked for permission to use all input devices >>>> earlier, so no user interaction may be involved. >>>> >>>> In this situation the responder's (added) RTP streams can very well >>>> arrive before the ANSWER if I understand correctly. >>>> >>> >>> Yes. Just like in SIP. And so when you send an OFFER (or modified >>> re-OFFER), you must be ready to receive data per that offer even if no >>> ANSWER has been received - just like in SIP. And if its a re-offer, you >>> need to accept the old, and accept the new (though you could probably >>> use reception of obviously new-OFFER media to turn off >>> decoding/rendering old-OFFER in preparation for the ANSWER). >>> >>> The flip side of this is the responder has to infer when the sender >>> switches over to the result of the ANSWER from the media. For example: >>> >>> A B >>> <--- H.261 ---> >>> re-OFFER(VP8) ---> >>> <-- ANSWER(VP8) (delayed in reception) >>> <-----------VP8 (A should infer that B ANSWERed and accepted >>> VP8) >>> ----------> H.261 >>> <-- ANSWER(VP8) (received) >>> <--------VP8----------> (B should infer by reception of VP8 that ANSWER >>> was received) >>> >>> (Personally, I hate inferences, but without a 3 (or 4) way handshake, >>> you have to). If you switches of codecs are staged, then this isn't >>> (much) of a problem. Either leave old codec on the list, or leave it on >>> the list until accept, and then re-OFFER to remove the un-used codec. >>> >> >> I think I understand what you mean, and this would work fine as long as >> you just switch codecs that are used in already set-up MediaStreams. >> >> But if A in this case, as part of re-OFFERING the session, not only >> offers a new codec (VP8) for the already flowing video but also adds a >> new outgoing video stream (e.g. front cam), and then (without receiving >> the ANSWER - delayed in reception) starts receiving VP8 video it could >> not really know if this VP8 video is new video from the responders front >> cam or just a new codec for the existing (back cam) video from the >> responder to the sender. >> > > This may have been a very bad example. Probably you can tell them apart on > the SSRC. But even so, the A browser won't know what the VP8 stream (if it > has an unknown SSRC) represents without receiving the ANSWER. I think this is only an issue if you decide to add streams in the ANSWER. But even so, eventually the ANSWER arrives and you can start demuxing/decoding appropriately. Regardless, if the app wants to require some sort of ACK message to begin transmission, or perhaps require that the remote side ask for the media streams it wants to be sent, I think this could be implemented in the app-specific signaling layer; the streams could initially be added as inactive, and only changed to sendrecv when the ACK arrives. > > > >> >>> One problem is what to do in the switchover window when you might get a >>> mixture of old and new media, especially if you moved them to different >>> ports and so can't count on RTP sequence re-ordering to un-mix them; in >>> the past I dealt with that (and long codec-switch times) by locking out >>> codec changes for a fraction of a second after I do one. Not a huge >>> deal, however. >>> >>> My apologies if I've missed something in JSEP; I've been heads-down >>> enough in Data Channels and bring-up that I could have a disconnect here >>> and be saying something silly. >>> >> >> Actually I don't think this is very JSEP related; it is the generic >> problem that the browser receiving RTP streams need some side info about >> them before being able to do anything sensible with them. >> >> >>> I think we need to find a way to handle this. One way is to add an >>>> "ACK" that indicates to the responder that the initiator has received >>>> the ANSWER, but I'm not sure that is the best way. >>>> >>> >>> If you need to know that, you need a SIP-style ACK. >>> >> >> As explained, I do think we need to know that. >> >> >>> >> ______________________________**_________________ >> 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 > --20cf3005dc4029f92c04bca9a0be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Mar 31, 2012 at 1:41 AM, Stefan = Hakansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 03/31/2012 07:17 AM, Stefan Hakansson LK wrote:
On 03/30/2012 11:39 PM, Randell Jesup wrote:
On 3/30/2012 4:59 AM, Stefan Hakansson LK wrote:
The JS API has deals with MediaStreams (this is what you send and
receive using PeerConnection from an application perspective).

A browser receiving RTP streams, needs side info to be able to
assemble those RTP streams into MediaStreams in a correct way. The
current model is that this is signaled using SDP exchanges (where
Haralds MSID proposal would tell which MediaStream an RTP stream
belongs to).

As I brought up at the mike yesterday, I think we may have a race
condition for the responder.

For the initiator side browser, this is clear: once an (PR-)ANSWER is
received, the responder has received the SDP, and hence can map
incoming RTP streams into MediaStreams.

But for the responder side this is less clear to me. Imagine
applications where the responder just mirrors the initiator - if one
of the parties adds a MediaStream to PeerConnection, the other end
would add the corresponding MediaStream.

This can happen any time in the session, so ICE can very well be up
and running. One example could be that the data channel is used for
text chat, when one side clicks a button to start video. And the
application can have asked for permission to use all input devices
earlier, so no user interaction may be involved.

In this situation the responder's (added) RTP streams can very well
arrive before the ANSWER if I understand correctly.

Yes. =C2=A0Just like in SIP. =C2=A0And so when you send an OFFER (or modifi= ed
re-OFFER), you must be ready to receive data per that offer even if no
ANSWER has been received - just like in SIP. =C2=A0And if its a re-offer, y= ou
need to accept the old, and accept the new (though you could probably
use reception of obviously new-OFFER media to turn off
decoding/rendering old-OFFER in preparation for the ANSWER).

The flip side of this is the responder has to infer when the sender
switches over to the result of the ANSWER from the media. =C2=A0For example= :

A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B
<--- H.261 --->
re-OFFER(VP8) --->
<-- ANSWER(VP8) (delayed in reception)
<-----------VP8 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(A should infer= that B ANSWERed and accepted VP8)
=C2=A0 =C2=A0----------> =C2=A0 H.261
<-- ANSWER(VP8) (received)
<--------VP8----------> =C2=A0 (B should infer by reception of VP8 th= at ANSWER
was received)

(Personally, I hate inferences, but without a 3 (or 4) way handshake,
you have to). =C2=A0If you switches of codecs are staged, then this isn'= ;t
(much) of a problem. =C2=A0Either leave old codec on the list, or leave it = on
the list until accept, and then re-OFFER to remove the un-used codec.

I think I understand what you mean, and this would work fine as long as
you just switch codecs that are used in already set-up MediaStreams.

But if A in this case, as part of re-OFFERING the session, not only
offers a new codec (VP8) for the already flowing video but also adds a
new outgoing video stream (e.g. front cam), and then (without receiving
the ANSWER - delayed in reception) starts receiving VP8 video it could
not really know if this VP8 video is new video from the responders front cam or just a new codec for the existing (back cam) video from the
responder to the sender.

This may have been a very bad example. Probably you can tell them apart on = the SSRC. But even so, the A browser won't know what the VP8 stream (if= it has an unknown SSRC) represents without receiving the ANSWER.

I think this is only an issue if you decide to add stre= ams in the ANSWER. But even so, eventually the ANSWER arrives and you can s= tart demuxing/decoding appropriately.

Regardless, = if the app wants to require some sort of ACK message to begin transmission,= or perhaps require that the remote side ask for the media streams it wants= to be sent, I think this could be implemented in the app-specific signalin= g layer; the streams could initially be added as inactive, and only changed= to sendrecv when the ACK arrives.
=C2=A0




One problem is what to do in the switchover window when you might get a
mixture of old and new media, especially if you moved them to different
ports and so can't count on RTP sequence re-ordering to un-mix them; in=
the past I dealt with that (and long codec-switch times) by locking out
codec changes for a fraction of a second after I do one. =C2=A0Not a huge deal, however.

My apologies if I've missed something in JSEP; I've been heads-down=
enough in Data Channels and bring-up that I could have a disconnect here and be saying something silly.

Actually I don't think this is very JSEP related; it is the generic
problem that the browser receiving RTP streams need some side info about them before being able to do anything sensible with them.


I think we need to find a way to handle this. One way is to add an
"ACK" that indicates to the responder that the initiator has rece= ived
the ANSWER, but I'm not sure that is the best way.

If you need to know that, you need a SIP-style ACK.

As explained, I do think we need to know that.



_______________________________________________
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

--20cf3005dc4029f92c04bca9a0be-- From juberti@google.com Sun Apr 1 20:22: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 4B44F21F8776 for ; Sun, 1 Apr 2012 20:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.654 X-Spam-Level: X-Spam-Status: No, score=-100.654 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_05=-1.11, 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 eqwka79kMKBZ for ; Sun, 1 Apr 2012 20:22:10 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 844C021F8775 for ; Sun, 1 Apr 2012 20:22:10 -0700 (PDT) Received: by qcsg15 with SMTP id g15so1909108qcs.27 for ; Sun, 01 Apr 2012 20:22:10 -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=4WHof32Rse3cpJHPxAA5MKoerQ0vVIxl9A6PM3vcVDw=; b=INTMC2PGDCK5K9a2SxiFX6GqqO+hVUEaPDhH1KW6gSVdoMyWQo+UHKefzHZGcGGYGz odUexFD4TwkJvSq/hmXFIkJMHQ1YmLuIe5PQeM4MEzZM6FNbrXNaq2L7xy4oh7uvOHTw MlZhIDXekGijOTV2LmgSiIkB2vOWXUQmvtnjCrU1h2X2CiC4m6iWolexTb8gFhgqp2Vf K0HDYgZ4W5I+sD7DXdwMxjMp5QDpkuAPxrRi9saWe6NYiaVPscbia0jr+y/Cm3Sa9yg0 z2+b/MdGteOFR+KlHbHSV6RafUeFDURNO8ZKy2fFLchpe/0SnmtxJUjI47iGpIcbC7TE EydQ== 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=4WHof32Rse3cpJHPxAA5MKoerQ0vVIxl9A6PM3vcVDw=; b=M27mO1jE9oF8zQxnQ8P1Fzb7eZ9jGB1iXYHEIrbunvSYb5QjUO57vA2OPKRL4RsUTT pk7ltw8B84pZQII0e3Ydl7zU7zExbjgbfUB+l+l6mrJECBcB5oFtvzqx/qBrE6qmH2/W GQF/KMTHENmjjuyA11qsdD4hXc91M0SIB5oydMrJyB6WXhtUfn/zfkkhDFmXSjdaE9eV llSjC4OliO9Ui0tgs+thWWK6vVyo6+zezE12bWbVhqUDOQGgkkjQC4FkSfcvmyyn5+9p FhP3bLWruKt2eeFwJ/kXGVJAlQteQsF1G21AzL1VLp+aqMxCFX6NN3fS2easrcCHXdfd Qlew== Received: by 10.224.105.65 with SMTP id s1mr7347034qao.75.1333336930039; Sun, 01 Apr 2012 20:22:10 -0700 (PDT) Received: by 10.224.105.65 with SMTP id s1mr7347029qao.75.1333336929963; Sun, 01 Apr 2012 20:22:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Sun, 1 Apr 2012 20:21:49 -0700 (PDT) In-Reply-To: <4F7415D5.80604@ericsson.com> References: <4F7415D5.80604@ericsson.com> From: Justin Uberti Date: Sun, 1 Apr 2012 23:21:49 -0400 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf3074da54138cd604bca9b220 X-System-Of-Record: true X-Gm-Message-State: ALoCoQknlLFAkPFui+h2neJF9imy26TpkYCEtvXQRaOzazSjs2t+q7OioVO9MKYAmqiCSmwpM4l2IgFfXyD5SWtBfm5kMDPdYL5oXc20GkRUE+Ez8ZlT1jkrTUymJLZbPXB8aAVGOFQg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 03:22:11 -0000 --20cf3074da54138cd604bca9b220 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 29, 2012 at 3:57 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, as individual > > As just discussed in the meeting Justin and Hadriel didn't think that > you could clone PeerConnections properly. I do believe it is possible. > > If the API provides a method where you can clone a current > peerConnection you can actually share the transport layer information at > one end-point for multiple peer connections assuming that the other > end-points transport addresses are different between the different > peerConnections being cloned. > > This works as the complete ICE username is the concatenation of both > sides, as long as an secondary answer contains a different username and > has candidates with different transport addresses (address+port). Then > end-point A receiving the second answer can have the ICE stack accept > both usernames and if connectivity checks works then you create > different 5-tuple filter to divide any media streams to the right peer > connections media handler. > > When you clone a PC then must allocate the media decoding resources for > each cloning. And that is something the cloning function may block on. > > Thanks Magnus. This sounds reasonable; it might even be possible to make cloning work using the existing API by taking the local description from one PC and installing it as the local description for a new PC; the browser could recognize that the candidates refer to existing ports and behave as you mention above. However, given that this seems to be mostly an edge case, I think we can probably save this for v2. --20cf3074da54138cd604bca9b220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 29, 2012 at 3:57 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wrote:
WG, as individual

As just discussed in the meeting Justin and Hadriel didn't think that you could clone PeerConnections properly. I do believe it is possible.

If the API provides a method where you can clone a current
peerConnection you can actually share the transport layer information at one end-point for multiple peer connections assuming that the other
end-points transport addresses are different between the different
peerConnections being cloned.

This works as the complete ICE username is the concatenation of both
sides, as long as an secondary answer contains a different username and
has candidates with different transport addresses (address+port). Then
end-point A receiving the second answer can have the ICE stack accept
both usernames and if connectivity checks works then you create
different 5-tuple filter to divide any media streams to the right peer
connections media handler.

When you clone a PC then must allocate the media decoding resources for
each cloning. And that is something the cloning function may block on.


Thanks Magnus. This sounds reasonable;= it might even be possible to make cloning work using the existing API by t= aking the local description from one PC and installing it as the local desc= ription for a new PC; the browser could recognize that the candidates refer= to existing ports and behave as you mention above.

However, given that this seems to be mostly an edge cas= e, I think we can probably save this for v2.

--20cf3074da54138cd604bca9b220-- From paulej@packetizer.com Sun Apr 1 20:56: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 7F54821F8746 for ; Sun, 1 Apr 2012 20:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 oo08hlCL7dy1 for ; Sun, 1 Apr 2012 20:56:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9263121F8745 for ; Sun, 1 Apr 2012 20:56:40 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q323ucCr017662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Apr 2012 23:56:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333338999; bh=L82//oIleUOIv3YKfT4l5hAQVKuvDyRG55ZDlORl34c=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=a7U5YEYWb5JX9MWIMNM+v3bCFKrII9L7ovsKxRIPXPsgVelvCaDk6Z3Z1+2PGoJXp NoER6voBG5hLWQMCo/XZT26tFP6H/ACsvjYHxbEy9/EpqGCZ1BS/aNrRqHKZxRNAB9 blYH1CYi7CiI4CckosOPftADY88mteEvJ2TtFH2Y= From: "Paul E. Jones" To: "'Stephan Wenger'" , "'Basil Mohamed Gohar'" , References: <4F746163.5090506@hidayahonline.org> In-Reply-To: Date: Sun, 1 Apr 2012 23:56:40 -0400 Message-ID: <00fe01cd1084$9c9fac90$d5df05b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOJExXox33VFTnW+1d6xv3Vg0BA8JMO1Ygw Content-Language: en-us Subject: Re: [rtcweb] Proposal for H.263 baseline 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, 02 Apr 2012 03:56:41 -0000 Stephan, > The most commonly cited timeline for a widely in use technology to be > "save" from a patent viewpoint, based on equitable defenses such as laches > (in the US) is six years. In some countries of significant size, this > time is longer, and in others, equitable defenses do not exist. (Very > briefly, and perhaps incorrectly put, those equitable defenses allow a > defendant to argue successfully that a patent cannot be enforced as the > right holder knew that the patent claim was likely being infringed, and > did not enforce the patent.). Recall that Unisys forced people to pay royalties for using the GIF file format long after it became widely popular. The company asserted IPR claims on GIF since it used a compression algorithm to which it acquired the rights, and it started doing so right near the end of the 20-year period during which a patent is considered valid. In short, I really do not think one should ever assume it might be safe to use any technology. > In addition, as I pointed out in the meeting, the use of a video codec > created by a body such as MPEG or ITU-T SG16 has the advantage of that the > patents of all participating players are available at least under > Reasonable and Non Discriminatory (RAND) terms. This may sound like a Bad > Thing if you operate under a business model that prevents you to pay > anything for patent licenses, but it is surely a Good Thing if you are > willing to dish out a moderate amount of money for a license. RAND > recently has gotten teeth, not so much in terms of the monetary > compensation aspect, but in terms of difficulty (if not unavailability) to > obtain injunctive relive, among others. H.26x and the MPEG standards > benefit from RAND commitments, VP8, AFAIK, does not. I believe your point here is perhaps worth even more consideration. I really know nothing about the IPR that exists or might be claimed on VP8. That said, I know there has such an incredible amount of work by so many companies to produce H.264 that I would be utterly surprised to find that VP8 does not infringe on something. All of the technology that went into H.264 represents only a subset of all of the IPR that exists in the video coding space. It's the rest of the IPR, a bunch of IPR owned by companies who actually have significant investment in video coding technologies, that I believe people should worry about. Everyone who worked on H.264 did so as part of an open standards process, as you mention above. They spent a lot of time and energy in the process, coming to an agreement to license the technology that went into H.264. They did not agree to license technology that did not go into H.264. So, if one of those participating companies were to subsequently sue over some IPR used in VP8, I would not dare call them a troll. Trolls always exist and may even lay claims to H.264, but I suspect it would be much harder for a troll to lay claim to H.264. That codec spent years in development with input from tons of people. If a troll were to come in and lay claim to some part of H.264, I suspect there would be several companies that would stand up and beat them down. After all, a claim against H.264 would not only present a problem for the defendant in a lawsuit, but would be an issue for every company with IPR on H.264. Further, no matter what part of H.264 such a troll might decide to pick on, there are a number of world-class engineers who (as you indicated about H.263) could probably name the person or persons who contributed the section of text, algorithm, procedure, etc., all of which is covered with a known license. VP8 does not have the benefit of such significant peer review and collaboration, nor does it benefit from any IPR licensing agreements from legitimate companies holding tons of video coding-related IPR. Paul From silviapfeiffer1@gmail.com Sun Apr 1 22:28: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 E475A21F8717 for ; Sun, 1 Apr 2012 22:28:55 -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 J-zAm2hL9qas for ; Sun, 1 Apr 2012 22:28:55 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 283C721F8716 for ; Sun, 1 Apr 2012 22:28:55 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1136143ggm.31 for ; Sun, 01 Apr 2012 22:28:54 -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:content-transfer-encoding; bh=9y/vMqwR6aWKWpFRebUYvusJd7uqsP587WUtQ6zBg/8=; b=t/cPBE0qDs5cD3dyZtMoyX+AmMN71cXpj91MzwJ76bmGhCgT0B560qZ9SS7ggiCBft OVjpt7UzQKvyqT+7kaxYLOjaABeCMsgDBr5h7ebrqtgeG998GkQmhPnA1LnjNIdkqcAj PEKn/QwFbkP+COIPH70tr7FOaV7vlK/AC53jSnYYDE+bOmXALnHpvyRx5Bs+sKrSM0l9 l4j754k+Ef7YsJ7iJJdGHxluL02MlIUId5OjeUguMiAjaqh669yBZGW2pNSVcbeMyUX9 vPL0JCQ8DK7RJsdMK/p7+0G4VPpvzxQXfDQ27aPbtU3Nl71mS39a+mIVX5erkxb9ciu4 j72w== Received: by 10.236.176.197 with SMTP id b45mr5736492yhm.72.1333344534746; Sun, 01 Apr 2012 22:28:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.99.3 with HTTP; Sun, 1 Apr 2012 22:28:34 -0700 (PDT) In-Reply-To: <00fe01cd1084$9c9fac90$d5df05b0$@packetizer.com> References: <4F746163.5090506@hidayahonline.org> <00fe01cd1084$9c9fac90$d5df05b0$@packetizer.com> From: Silvia Pfeiffer Date: Sun, 1 Apr 2012 22:28:34 -0700 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for H.263 baseline 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, 02 Apr 2012 05:28:56 -0000 Note that H.264 isn't even under discussion here. Also, my question on H.263 hasn't been answered yet. I do wonder about the patent situation there! Cheers, Silvia. On Sun, Apr 1, 2012 at 8:56 PM, Paul E. Jones wrote= : > Stephan, > >> The most commonly cited timeline for a widely in use technology to be >> "save" from a patent viewpoint, based on equitable defenses such as lach= es >> (in the US) is six years. =A0In some countries of significant size, this >> time is longer, and in others, equitable defenses do not exist. =A0(Very >> briefly, and perhaps incorrectly put, those equitable defenses allow a >> defendant to argue successfully that a patent cannot be enforced as the >> right holder knew that the patent claim was likely being infringed, and >> did not enforce the patent.). > > Recall that Unisys forced people to pay royalties for using the GIF file > format long after it became widely popular. =A0The company asserted IPR c= laims > on GIF since it used a compression algorithm to which it acquired the > rights, and it started doing so right near the end of the 20-year period > during which a patent is considered valid. > > In short, I really do not think one should ever assume it might be safe t= o > use any technology. > >> In addition, as I pointed out in the meeting, the use of a video codec >> created by a body such as MPEG or ITU-T SG16 has the advantage of that t= he >> patents of all participating players are available at least under >> Reasonable and Non Discriminatory (RAND) terms. =A0This may sound like a= Bad >> Thing if you operate under a business model that prevents you to pay >> anything for patent licenses, but it is surely a Good Thing if you are >> willing to dish out a moderate amount of money for a license. =A0RAND >> recently has gotten teeth, not so much in terms of the monetary >> compensation aspect, but in terms of difficulty (if not unavailability) = to >> obtain injunctive relive, among others. =A0H.26x and the MPEG standards >> benefit from RAND commitments, VP8, AFAIK, does not. > > I believe your point here is perhaps worth even more consideration. > > I really know nothing about the IPR that exists or might be claimed on VP= 8. > That said, I know there has such an incredible amount of work by so many > companies to produce H.264 that I would be utterly surprised to find that > VP8 does not infringe on something. =A0All of the technology that went in= to > H.264 represents only a subset of all of the IPR that exists in the video > coding space. > > It's the rest of the IPR, a bunch of IPR owned by companies who actually > have significant investment in video coding technologies, that I believe > people should worry about. =A0Everyone who worked on H.264 did so as part= of > an open standards process, as you mention above. =A0They spent a lot of t= ime > and energy in the process, coming to an agreement to license the technolo= gy > that went into H.264. =A0They did not agree to license technology that di= d not > go into H.264. =A0So, if one of those participating companies were to > subsequently sue over some IPR used in VP8, I would not dare call them a > troll. > > Trolls always exist and may even lay claims to H.264, but I suspect it wo= uld > be much harder for a troll to lay claim to H.264. =A0That codec spent yea= rs in > development with input from tons of people. =A0If a troll were to come in= and > lay claim to some part of H.264, I suspect there would be several compani= es > that would stand up and beat them down. =A0After all, a claim against H.2= 64 > would not only present a problem for the defendant in a lawsuit, but woul= d > be an issue for every company with IPR on H.264. =A0Further, no matter wh= at > part of H.264 such a troll might decide to pick on, there are a number of > world-class engineers who (as you indicated about H.263) could probably n= ame > the person or persons who contributed the section of text, algorithm, > procedure, etc., all of which is covered with a known license. > > VP8 does not have the benefit of such significant peer review and > collaboration, nor does it benefit from any IPR licensing agreements from > legitimate companies holding tons of video coding-related IPR. > > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From paulej@packetizer.com Mon Apr 2 00:16: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 9D67611E8073 for ; Mon, 2 Apr 2012 00:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 qNem-zz5VCIz for ; Mon, 2 Apr 2012 00:16:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9019C21F860F for ; Mon, 2 Apr 2012 00:16:43 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q327GfUj021509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 03:16:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333351002; bh=vtYrMRXfT+aA8Sr7q5kE2obcU+rx4NT2pxnrs7HrM7c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DrAA/hA6Yma7m0A3jwmLwezPj6FmABRciSdRejjpWPV4sj5FTGO6OEwih69gBMxYM ugQYNEX4BcpHMl4Q1/KgfOIaea6BJx3vTIzTPFao/Y74ibgtY/T24j/hUvm0cheiMX 9kRL3vBNELKBVVVEuEbQflfSG8Roy1ZIygaUV7qU= From: "Paul E. Jones" To: "'Silvia Pfeiffer'" References: <4F746163.5090506@hidayahonline.org> <00fe01cd1084$9c9fac90$d5df05b0$@packetizer.com> In-Reply-To: Date: Mon, 2 Apr 2012 03:16:43 -0400 Message-ID: <012901cd10a0$8f3724e0$ada56ea0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI2rUoArrfLbc4yW3pZoF1fCBAdzQOJExXoAX2irIQB2Q199JV85SJg Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for H.263 baseline 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, 02 Apr 2012 07:16:47 -0000 Silvia, I believe H.263 would be covered if you license the MPEG-4 Visual = "patent pool". I might be wrong, but you can certainly get clarification from = MPEG LA. You could also reach out to the list of companies who have claimed = IPR at the ITU (search for ITU IPR database). I think there are about 14 companies who have IPR claims submitted. As with H.264, it was a very open process. Those involved are likely = the only ones with IPR claims. Perhaps not, but given the pervasive use of H.263 already on the Internet, one would think if there was some IPR in hiding, it would have appeared already. Paul > -----Original Message----- > From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] > Sent: Monday, April 02, 2012 1:29 AM > To: Paul E. Jones > Cc: Stephan Wenger; Basil Mohamed Gohar; rtcweb@ietf.org > Subject: Re: [rtcweb] Proposal for H.263 baseline codec >=20 > Note that H.264 isn't even under discussion here. >=20 > Also, my question on H.263 hasn't been answered yet. I do wonder about = the > patent situation there! >=20 > Cheers, > Silvia. >=20 > On Sun, Apr 1, 2012 at 8:56 PM, Paul E. Jones > wrote: > > Stephan, > > > >> The most commonly cited timeline for a widely in use technology to = be > >> "save" from a patent viewpoint, based on equitable defenses such as > >> laches (in the US) is six years. =A0In some countries of = significant > >> size, this time is longer, and in others, equitable defenses do not > >> exist. =A0(Very briefly, and perhaps incorrectly put, those = equitable > >> defenses allow a defendant to argue successfully that a patent = cannot > >> be enforced as the right holder knew that the patent claim was = likely > >> being infringed, and did not enforce the patent.). > > > > Recall that Unisys forced people to pay royalties for using the GIF > > file format long after it became widely popular. =A0The company = asserted > > IPR claims on GIF since it used a compression algorithm to which it > > acquired the rights, and it started doing so right near the end of = the > > 20-year period during which a patent is considered valid. > > > > In short, I really do not think one should ever assume it might be > > safe to use any technology. > > > >> In addition, as I pointed out in the meeting, the use of a video > >> codec created by a body such as MPEG or ITU-T SG16 has the = advantage > >> of that the patents of all participating players are available at > >> least under Reasonable and Non Discriminatory (RAND) terms. =A0This = may > >> sound like a Bad Thing if you operate under a business model that > >> prevents you to pay anything for patent licenses, but it is surely = a > >> Good Thing if you are willing to dish out a moderate amount of = money > >> for a license. =A0RAND recently has gotten teeth, not so much in = terms > >> of the monetary compensation aspect, but in terms of difficulty (if > >> not unavailability) to obtain injunctive relive, among others. = =A0H.26x > >> and the MPEG standards benefit from RAND commitments, VP8, AFAIK, = does > not. > > > > I believe your point here is perhaps worth even more consideration. > > > > I really know nothing about the IPR that exists or might be claimed = on > VP8. > > That said, I know there has such an incredible amount of work by so > > many companies to produce H.264 that I would be utterly surprised to > > find that > > VP8 does not infringe on something. =A0All of the technology that = went > > into > > H.264 represents only a subset of all of the IPR that exists in the > > video coding space. > > > > It's the rest of the IPR, a bunch of IPR owned by companies who > > actually have significant investment in video coding technologies, > > that I believe people should worry about. =A0Everyone who worked on > > H.264 did so as part of an open standards process, as you mention > > above. =A0They spent a lot of time and energy in the process, coming = to > > an agreement to license the technology that went into H.264. =A0They = did > > not agree to license technology that did not go into H.264. =A0So, = if > > one of those participating companies were to subsequently sue over > > some IPR used in VP8, I would not dare call them a troll. > > > > Trolls always exist and may even lay claims to H.264, but I suspect = it > > would be much harder for a troll to lay claim to H.264. =A0That = codec > > spent years in development with input from tons of people. =A0If a = troll > > were to come in and lay claim to some part of H.264, I suspect there > > would be several companies that would stand up and beat them down. > > After all, a claim against H.264 would not only present a problem = for > > the defendant in a lawsuit, but would be an issue for every company > > with IPR on H.264. =A0Further, no matter what part of H.264 such a = troll > > might decide to pick on, there are a number of world-class engineers > > who (as you indicated about H.263) could probably name the person or > > persons who contributed the section of text, algorithm, procedure, = etc., > all of which is covered with a known license. > > > > VP8 does not have the benefit of such significant peer review and > > collaboration, nor does it benefit from any IPR licensing agreements > > from legitimate companies holding tons of video coding-related IPR. > > > > Paul > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From salvatore.loreto@ericsson.com Mon Apr 2 03:55: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 538C021F8910 for ; Mon, 2 Apr 2012 03:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 O+gdBK9FjM+F for ; Mon, 2 Apr 2012 03:55:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02F6C21F879E for ; Mon, 2 Apr 2012 03:55:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-7c-4f79859e23ec Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 20.2F.25560.E95897F4; Mon, 2 Apr 2012 12:55:27 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012 12:55:26 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2B4552323 for ; Mon, 2 Apr 2012 13:55:26 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 40415526CE for ; Mon, 2 Apr 2012 13:55:26 +0300 (EEST) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ECF0C4FE35 for ; Mon, 2 Apr 2012 13:55:25 +0300 (EEST) Message-ID: <4F79859D.1050208@ericsson.com> Date: Mon, 2 Apr 2012 13:55:25 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F71982B.4010208@alvestrand.no> In-Reply-To: <4F71982B.4010208@alvestrand.no> Content-Type: multipart/alternative; boundary="------------090800020007060104070806" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Query regarding rtcweb use cases and 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, 02 Apr 2012 10:55:29 -0000 --------------090800020007060104070806 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit at moment the requirements/use case for Data are in the following draft http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00 /Salvatore On 3/27/12 1:36 PM, Harald Alvestrand wrote: > On 03/27/2012 09:51 AM, ajrmeyn@gmail.com wrote: >> Hi, >> >> This is with regards to the following document: >> Web Real-Time Communication Use-cases and Requirements >> draft-ietf-rtcweb-use-cases-and-requirements-06.txt >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1 >> I have noticed that the use cases with regards to Data API of web >> real time communication, have not been addressed. For example: use >> cases that are related to file sharing between browsers. >> is there any particular reason for the same? > Requirement F23 is a data-passing requirement. > > For communications that did not need low latency, the WG felt that the > RTCWEB requirements were not different from the requirements of any > other application, so those could be fulfilled with other types of > interfaces, including server-mediated file transfers. > > The WG is suggesting data API/protocol solutions that can be used for > other things than fulfiling the most narrow interpretation of the > requirement listed, but did not feel a need to add a requirement > covering those. > > The purpose of the "use cases and requirements" is to find a minimum > set of things that the protocol suite has to be able to do in order to > be "good enough", not to delineate everything the protocol can be used > for. > > My interpretation.... > > Harald > > > > >> Regards, >> Antony Meyn >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > -- Salvatore Loreto, PhD www.sloreto.com --------------090800020007060104070806 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit at moment the requirements/use case for Data are in the following draft
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00


/Salvatore


On 3/27/12 1:36 PM, Harald Alvestrand wrote:
On 03/27/2012 09:51 AM, ajrmeyn@gmail.com wrote: 
Hi,
 
This is with regards to the following document:
Web Real-Time Communication Use-cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-06.txt
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1
I have noticed that the use cases with regards to Data API of web real time communication, have not been addressed. For example: use cases that are related to file sharing between browsers.
 
is there any particular reason for the same?
Requirement F23 is a data-passing requirement.

For communications that did not need low latency, the WG felt that the RTCWEB requirements were not different from the requirements of any other application, so those could be fulfilled with other types of interfaces, including server-mediated file transfers.

The WG is suggesting data API/protocol solutions that can be used for other things than fulfiling the most narrow interpretation of the requirement listed, but did not feel a need to add a requirement covering those.

The purpose of the "use cases and requirements" is to find a minimum set of things that the protocol suite has to be able to do in order to be "good enough", not to delineate everything the protocol can be used for.

My interpretation....

                      Harald




 
Regards,
Antony Meyn

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




-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------090800020007060104070806-- From oscar.ohlsson@ericsson.com Mon Apr 2 05:17: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 16E4421F86A2 for ; Mon, 2 Apr 2012 05:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.974 X-Spam-Level: X-Spam-Status: No, score=-6.974 tagged_above=-999 required=5 tests=[AWL=-3.625, BAYES_50=0.001, 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 or4PH6bcuZh4 for ; Mon, 2 Apr 2012 05:17:12 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C382A21F8693 for ; Mon, 2 Apr 2012 05:17:11 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-09-4f7998c63c53 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AE.5F.03534.6C8997F4; Mon, 2 Apr 2012 14:17:10 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.51]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 2 Apr 2012 14:17:10 +0200 From: Oscar Ohlsson To: Gregory Maxwell , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Mon, 2 Apr 2012 14:17:09 +0200 Thread-Topic: [rtcweb] Support of SDES in WebRTC Thread-Index: Ac0NwVWL/pAf3KWyRBuDtl/dfJ3iTAALdbdgAAFEo7YAs0GcIA== Message-ID: References: <4F742344.802@infosecurity.ch> , In-Reply-To: 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: AAAAAA== Cc: "" Subject: Re: [rtcweb] Support of SDES in WebRTC 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 Apr 2012 12:17:13 -0000 =20 > -----Original Message----- > From: Gregory Maxwell [mailto:gmaxwell@juniper.net]=20 > Sent: Thursday, March 29, 2012 11:59 PM > To: Oscar Ohlsson; I=F1aki Baz Castillo > Cc: > Subject: RE: [rtcweb] Support of SDES in WebRTC >=20 > Oscar Ohlsson [oscar.ohlsson@ericsson.com] wrote: > > That's why I wrote "the entire webapp" below. If it was not clear I=20 > > meant that the > > - main HTML page > > - all external CSS files, JavaScript files, images, etc > > - all XmlHttpRequests > > - all WebSocket connections > > are protected with TLS. This is obviously verifiable and=20 > it's a feature supported by all modern browsers (no mixed content). >=20 > Even this is insufficient. >=20 > First, even if it is in principle possible to provide=20 > adequate cryptographic security inside the JS applications a=20 > great many of them won't (for many reasons). We can't=20 > eliminate inconsistency in the security of webrtc=20 > applications- but we can certainly make it hard to go below > a certain level of security especially by accident. In particular, > if JS applications provide only authentication services (e.g.=20 > by giving them access to hashes of the ephemeral session=20 > keys, but not the session keys themselves) then a=20 > cryptographically-incompetent application can only fail the=20 > user by failing to provide the authentication it promised=20 > over and above the platform baseline capability. Yes, and that's exactly why DTLS-SRTP is offered by default. >=20 > With HTTPS applications are currently free to do dumb things=20 > (mixed content, esp scripts) but at least the browser can=20 > detected this and alerts the user with varying degrees of=20 > loudness. In a SDES/SRTP world the browser will not be=20 > generally able to detect insecure behavior by applications-=20 > creating something of a lemon market for webrtc based=20 > application security. As a resutl its important to narrow the=20 > amount of insecurity possible. If mixed content is in use then SDES is not available. The user would never= be=20 queried since it's unlikely that he can make that kind of decision. >=20 > This is effectively a repeat of the arguments against=20 > supporting plaintext. If plaintext is supported it will be=20 > commonly used because it's easiest, because users can't=20 > easily tell how insecure their connection is, and because=20 > users often don't have a good feel for the threat model (e.g.=20 > things like firesheep were _very_ surprising to most people)... > Because of this the platform should provide the highest level=20 > of security that can reasonably be provided in the platform,=20 > and that means (among other things) perfect-forward-secrecy-=20 > while allowing applications to add things like authentication=20 > on top (because while strong ephemerally keyed crypto can be=20 > done very low in the stack, meaningful authentication needs=20 > layer-7/8 hooks). I don't understand this argument. Are you saying that SDES would be more co= mmoly used since it's easier? I seriously doubt that. The easiest is to go = with default which is DTLS-SRTP. Only in the legacy interop case would it b= e necessary to turn on SDES. >=20 > There is also the application/library split issue- if a=20 > vulnerability is found in a common negotiation procedure what=20 > secures users better? Updating a few easily identified=20 > browsers / softphone apps? > or a much larger base of webapps, many of which would be run=20 > by security ignorant/clueless people? (and at least if the=20 > webserver is clueful but the client operator is not the app=20 > could yell about the insecure client, > the other way around doesn't work as well). - Really, cryptographic > negotiation is not properly an application feature, it=20 > belongs lower in the stack, and many applications that roll=20 > their own crypto have done a poor job of it. The application is not performing any real cryptographic operations. It bas= ically only forwards SDP blobs between the PeerConnection object and the TL= S channel. So security is to a very large extent handled by lower layers. >=20 > It's also inadequate on purely technical grounds: Javascript=20 > provides no mechanism for working with mlocked memory, no=20 > mechanism to ensure that garbage collected data gets=20 > zeroized. Your crypto app in JS could easily have its long=20 > term keying material pulled out of free ram by malware long=20 > after it runs, or pulled off the disk from swap. > The breakneck pace of fancy JIT systems makes it seem=20 > unlikely to me that javascript will provide for that any time soon. I think you're exaggerating here. I don't know the details of how memory ma= nagment works in JavaScript but if you start considering malware applicatio= ns and infected devices then there's probably very little we can do. Quotin= g I.D.ietf-rtcweb-security-arch, Section 3: "Conversely, if the browser is compromised, then no security guarantees are= possible."=20 I would appreciate if you could describe your attack in more detail and exp= lain the assumptions that you make. I suspect that some parts are left out = or have been greatly simplified. Regards, Oscar >=20 >=20 >=20 > = From oscar.ohlsson@ericsson.com Mon Apr 2 05:32: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 0FF0521F8669 for ; Mon, 2 Apr 2012 05:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.612 X-Spam-Level: X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[AWL=-0.363, 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 XmAUn6I1Gq0j for ; Mon, 2 Apr 2012 05:32:48 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C7D0121F866A for ; Mon, 2 Apr 2012 05:32:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-f4-4f799c6e83c7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EE.FF.25560.E6C997F4; Mon, 2 Apr 2012 14:32:46 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.51]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 2 Apr 2012 14:32:46 +0200 From: Oscar Ohlsson To: Gregory Maxwell , Randell Jesup , "rtcweb@ietf.org" Date: Mon, 2 Apr 2012 14:32:45 +0200 Thread-Topic: [rtcweb] SRTP and "marketing" Thread-Index: Ac0N903AuI/AsopKSqCZGCBYPaD84QAjG+neAJHOMjA= Message-ID: References: <4F72D6B3.40803@bbn.com> <5D67671F-417C-4C78-A560-0B16AC65E4E2@acmepacket.com> <4F73B2B6.9080008@jesup.org> <6493BD08-5A9B-48AB-8D5C-8778384948A3@acmepacket.com>, <4F74DAA1.4080103@jesup.org> In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] SRTP and "marketing" 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 Apr 2012 12:32:49 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gregory Maxwell > Sent: Friday, March 30, 2012 5:38 PM > To: Randell Jesup; rtcweb@ietf.org > Subject: Re: [rtcweb] SRTP and "marketing" >=20 >=20 > A point which needs to be emphasized is that undetectable=20 > attacks are not at all the same thing as detectable attacks:=20 > Even when the chance of detection is somewhat low, if the=20 > cost of detection is high the possibility of it can be an=20 > effective deterrent. >=20 It is definely important to distinguish between detectable and un-detectabl= e interception. But as I mentioned earlier, I don't think enabling SDES in = WebRTC will enable un-detectable interception. If both parties open up Tool= s->PageInfo->Media->session-security and see something like: Is SDES turned on? Yes Is this endpoint capable of DTLS-SRTP? Yes Then they could automatically assume that they're are beeing intercepted. I= n my opinion this is not that much different from comparing fingerprints. Regards, Oscar From marshall.eubanks@gmail.com Mon Apr 2 05:43: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 4E28321F851E for ; Mon, 2 Apr 2012 05:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 e8P4hErEkmzg for ; Mon, 2 Apr 2012 05:43:43 -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 64F6E21F8513 for ; Mon, 2 Apr 2012 05:43:42 -0700 (PDT) Received: by lagj5 with SMTP id j5so3721498lag.31 for ; Mon, 02 Apr 2012 05:43: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:content-transfer-encoding; bh=5r6lUSDdPVpDADVq/mtPh4NvZAiZQFt9ubaW2xUt500=; b=rhv7yTMwNH8k2twJjXKaYVDywAV6u/s1h0BOC11zEwIZgi9YAENTA38jg0u1+NGUxV GG1aEknjWdUn1pLblHwxNGzBC3L13E3dgybvYG+980YLdukZpNy0uy5javmYboxPRhAI mu2dxMbITDbj5xyMqelav+BUbsc2MvLg2f8IJqwcFJz0gXoa1zhAmCc+/HtUAT0U+NC2 T7Nd2AKVVP7WV7dZvH+0griFDgyn8MQ2KeOT+Dp4KWCjAlryl6I1gE23OPSgEOD+zR3Z DmeeTBQSzH4lDLwXqG49/Z2KLjckdkLIRpfnlEeW7d9YblK0q63fyguJFqvxdMvetv1K 7Vnw== MIME-Version: 1.0 Received: by 10.152.146.67 with SMTP id ta3mr3780516lab.25.1333370621345; Mon, 02 Apr 2012 05:43:41 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Mon, 2 Apr 2012 05:43:41 -0700 (PDT) In-Reply-To: <012901cd10a0$8f3724e0$ada56ea0$@packetizer.com> References: <4F746163.5090506@hidayahonline.org> <00fe01cd1084$9c9fac90$d5df05b0$@packetizer.com> <012901cd10a0$8f3724e0$ada56ea0$@packetizer.com> Date: Mon, 2 Apr 2012 08:43:41 -0400 Message-ID: From: Marshall Eubanks To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for H.263 baseline 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, 02 Apr 2012 12:43:45 -0000 On Mon, Apr 2, 2012 at 3:16 AM, Paul E. Jones wrote= : > Silvia, > > I believe H.263 would be covered if you license the MPEG-4 Visual "patent > pool". =A0I might be wrong, but you can certainly get clarification from = MPEG > LA. You could also reach out to the list of companies who have claimed IP= R > at the ITU (search for ITU IPR database). =A0I think there are about 14 > companies who have IPR claims submitted. According to this http://www.nine-9s.com/h-263-codec-software.htm Lucent is not covered by MPEG-LA, although it is not clear if they actually claim IPR. Regards Marshall > > As with H.264, it was a very open process. =A0Those involved are likely t= he > only ones with IPR claims. =A0Perhaps not, but given the pervasive use of > H.263 already on the Internet, one would think if there was some IPR in > hiding, it would have appeared already. > > Paul > >> -----Original Message----- >> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] >> Sent: Monday, April 02, 2012 1:29 AM >> To: Paul E. Jones >> Cc: Stephan Wenger; Basil Mohamed Gohar; rtcweb@ietf.org >> Subject: Re: [rtcweb] Proposal for H.263 baseline codec >> >> Note that H.264 isn't even under discussion here. >> >> Also, my question on H.263 hasn't been answered yet. I do wonder about t= he >> patent situation there! >> >> Cheers, >> Silvia. >> >> On Sun, Apr 1, 2012 at 8:56 PM, Paul E. Jones >> wrote: >> > Stephan, >> > >> >> The most commonly cited timeline for a widely in use technology to be >> >> "save" from a patent viewpoint, based on equitable defenses such as >> >> laches (in the US) is six years. =A0In some countries of significant >> >> size, this time is longer, and in others, equitable defenses do not >> >> exist. =A0(Very briefly, and perhaps incorrectly put, those equitable >> >> defenses allow a defendant to argue successfully that a patent cannot >> >> be enforced as the right holder knew that the patent claim was likely >> >> being infringed, and did not enforce the patent.). >> > >> > Recall that Unisys forced people to pay royalties for using the GIF >> > file format long after it became widely popular. =A0The company assert= ed >> > IPR claims on GIF since it used a compression algorithm to which it >> > acquired the rights, and it started doing so right near the end of the >> > 20-year period during which a patent is considered valid. >> > >> > In short, I really do not think one should ever assume it might be >> > safe to use any technology. >> > >> >> In addition, as I pointed out in the meeting, the use of a video >> >> codec created by a body such as MPEG or ITU-T SG16 has the advantage >> >> of that the patents of all participating players are available at >> >> least under Reasonable and Non Discriminatory (RAND) terms. =A0This m= ay >> >> sound like a Bad Thing if you operate under a business model that >> >> prevents you to pay anything for patent licenses, but it is surely a >> >> Good Thing if you are willing to dish out a moderate amount of money >> >> for a license. =A0RAND recently has gotten teeth, not so much in term= s >> >> of the monetary compensation aspect, but in terms of difficulty (if >> >> not unavailability) to obtain injunctive relive, among others. =A0H.2= 6x >> >> and the MPEG standards benefit from RAND commitments, VP8, AFAIK, doe= s >> not. >> > >> > I believe your point here is perhaps worth even more consideration. >> > >> > I really know nothing about the IPR that exists or might be claimed on >> VP8. >> > That said, I know there has such an incredible amount of work by so >> > many companies to produce H.264 that I would be utterly surprised to >> > find that >> > VP8 does not infringe on something. =A0All of the technology that went >> > into >> > H.264 represents only a subset of all of the IPR that exists in the >> > video coding space. >> > >> > It's the rest of the IPR, a bunch of IPR owned by companies who >> > actually have significant investment in video coding technologies, >> > that I believe people should worry about. =A0Everyone who worked on >> > H.264 did so as part of an open standards process, as you mention >> > above. =A0They spent a lot of time and energy in the process, coming t= o >> > an agreement to license the technology that went into H.264. =A0They d= id >> > not agree to license technology that did not go into H.264. =A0So, if >> > one of those participating companies were to subsequently sue over >> > some IPR used in VP8, I would not dare call them a troll. >> > >> > Trolls always exist and may even lay claims to H.264, but I suspect it >> > would be much harder for a troll to lay claim to H.264. =A0That codec >> > spent years in development with input from tons of people. =A0If a tro= ll >> > were to come in and lay claim to some part of H.264, I suspect there >> > would be several companies that would stand up and beat them down. >> > After all, a claim against H.264 would not only present a problem for >> > the defendant in a lawsuit, but would be an issue for every company >> > with IPR on H.264. =A0Further, no matter what part of H.264 such a tro= ll >> > might decide to pick on, there are a number of world-class engineers >> > who (as you indicated about H.263) could probably name the person or >> > persons who contributed the section of text, algorithm, procedure, etc= ., >> all of which is covered with a known license. >> > >> > VP8 does not have the benefit of such significant peer review and >> > collaboration, nor does it benefit from any IPR licensing agreements >> > from legitimate companies holding tons of video coding-related IPR. >> > >> > Paul >> > >> > _______________________________________________ >> > 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 internet-drafts@ietf.org Mon Apr 2 05:59: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 6DD0721F86BD; Mon, 2 Apr 2012 05:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 FFl2oFsg8+YA; Mon, 2 Apr 2012 05:59:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8021F8433; Mon, 2 Apr 2012 05:59:50 -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.00 Message-ID: <20120402125950.7468.60954.idtracker@ietfa.amsl.com> Date: Mon, 02 Apr 2012 05:59:50 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-07.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, 02 Apr 2012 12:59:50 -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-browse= rs Working Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-07.txt Pages : 24 Date : 2012-04-02 This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-require= ments-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirem= ents-07.txt From HKaplan@acmepacket.com Mon Apr 2 06:02: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 0A7AA21F8441 for ; Mon, 2 Apr 2012 06:02: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 dwkf5TgGbsn7 for ; Mon, 2 Apr 2012 06:02:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 641C321F8421 for ; Mon, 2 Apr 2012 06:02:39 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 2 Apr 2012 09:02:35 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.219]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Mon, 2 Apr 2012 09:02:34 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received Thread-Index: AQHNENDeKuBUNLaVPkqTmaT4kSIuvg== Date: Mon, 2 Apr 2012 13:02:33 +0000 Message-ID: <0E6A0E0D-BFDD-4974-87BE-B0DCD1ECE9D5@acmepacket.com> References: <4F7415D5.80604@ericsson.com> In-Reply-To: <4F7415D5.80604@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 13:02:40 -0000 Hi, I was thinking the tricky part is more about the local transport stuff gett= ing cloned - i.e., imagine if you're using a TCP-based TURN connection. But maybe it's a non-issue. -hadriel On Mar 29, 2012, at 3:57 AM, Magnus Westerlund wrote: > WG, as individual >=20 > As just discussed in the meeting Justin and Hadriel didn't think that > you could clone PeerConnections properly. I do believe it is possible. >=20 > If the API provides a method where you can clone a current > peerConnection you can actually share the transport layer information at > one end-point for multiple peer connections assuming that the other > end-points transport addresses are different between the different > peerConnections being cloned. >=20 > This works as the complete ICE username is the concatenation of both > sides, as long as an secondary answer contains a different username and > has candidates with different transport addresses (address+port). Then > end-point A receiving the second answer can have the ICE stack accept > both usernames and if connectivity checks works then you create > different 5-tuple filter to divide any media streams to the right peer > connections media handler. >=20 > When you clone a PC then must allocate the media decoding resources for > each cloning. And that is something the cloning function may block on. >=20 >=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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Mon Apr 2 06: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 4C8F021F84C5 for ; Mon, 2 Apr 2012 06:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=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 o9vVH5zsVGzM for ; Mon, 2 Apr 2012 06:13:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 68B1121F84B3 for ; Mon, 2 Apr 2012 06:13:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-0a-4f79a607be92 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.19.25560.806A97F4; Mon, 2 Apr 2012 15:13:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 2 Apr 2012 15:13:43 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Mon, 2 Apr 2012 15:13:42 +0200 Thread-Topic: Draft new version: draft-ietf-rtcweb-use-cases-and-requirements Thread-Index: Ac0Q0YaunTwioqKTTgetP12w6MwsAA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42C04A61@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: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C42C04A61ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-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, 02 Apr 2012 13:13:46 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C42C04A61ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a new version of the use-case-and-reqs document. The main reason for the new version is that the previous version was about = to expire. The only change is that we have changed the numbering for 3 of t= he requirements. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C42C04A61ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

 

We’ve submitted a new version of = the use-case-and-reqs document.

&nb= sp;

The main reason for the new version is th= at the previous version was about to expire. The only change is that we hav= e changed the numbering for 3 of the requirements.

 

Regards,<= /p>

 

Christer<= o:p>

= --_000_7F2072F1E0DE894DA4B517B93C6A05852C42C04A61ESESSCMS0356e_-- From stefan.lk.hakansson@ericsson.com Mon Apr 2 06:55: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 2FBAB21F8568 for ; Mon, 2 Apr 2012 06:55:38 -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=[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 N1dG3Ra78d+i for ; Mon, 2 Apr 2012 06:55:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7400221F8567 for ; Mon, 2 Apr 2012 06:55:31 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-6e-4f79afd28dd9 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.34.03534.2DFA97F4; Mon, 2 Apr 2012 15:55:30 +0200 (CEST) Received: from [150.132.142.222] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012 15:55:30 +0200 Message-ID: <4F79AFD1.8030401@ericsson.com> Date: Mon, 2 Apr 2012 15:55:29 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Justin Uberti References: <4F7575FB.8010201@ericsson.com> <4F762813.6040506@jesup.org> <4F76937B.9020901@ericsson.com> <4F7698EF.1090306@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interaction between MediaStream API and signaling 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 Apr 2012 13:55:38 -0000 On 04/02/2012 05:16 AM, Justin Uberti wrote: > > > On Sat, Mar 31, 2012 at 1:41 AM, Stefan Hakansson LK > > wrote: > > On 03/31/2012 07:17 AM, Stefan Hakansson LK wrote: > > On 03/30/2012 11:39 PM, Randell Jesup wrote: > > On 3/30/2012 4:59 AM, Stefan Hakansson LK wrote: > > The JS API has deals with MediaStreams (this is what you > send and > receive using PeerConnection from an application > perspective). > > A browser receiving RTP streams, needs side info to be > able to > assemble those RTP streams into MediaStreams in a > correct way. The > current model is that this is signaled using SDP > exchanges (where > Haralds MSID proposal would tell which MediaStream an > RTP stream > belongs to). > > As I brought up at the mike yesterday, I think we may > have a race > condition for the responder. > > For the initiator side browser, this is clear: once an > (PR-)ANSWER is > received, the responder has received the SDP, and hence > can map > incoming RTP streams into MediaStreams. > > But for the responder side this is less clear to me. Imagine > applications where the responder just mirrors the > initiator - if one > of the parties adds a MediaStream to PeerConnection, the > other end > would add the corresponding MediaStream. > > This can happen any time in the session, so ICE can very > well be up > and running. One example could be that the data channel > is used for > text chat, when one side clicks a button to start video. > And the > application can have asked for permission to use all > input devices > earlier, so no user interaction may be involved. > > In this situation the responder's (added) RTP streams > can very well > arrive before the ANSWER if I understand correctly. > > > Yes. Just like in SIP. And so when you send an OFFER (or > modified > re-OFFER), you must be ready to receive data per that offer > even if no > ANSWER has been received - just like in SIP. And if its a > re-offer, you > need to accept the old, and accept the new (though you could > probably > use reception of obviously new-OFFER media to turn off > decoding/rendering old-OFFER in preparation for the ANSWER). > > The flip side of this is the responder has to infer when the > sender > switches over to the result of the ANSWER from the media. > For example: > > A B > <--- H.261 ---> > re-OFFER(VP8) ---> > <-- ANSWER(VP8) (delayed in reception) > <-----------VP8 (A should infer that B ANSWERed > and accepted VP8) > ----------> H.261 > <-- ANSWER(VP8) (received) > <--------VP8----------> (B should infer by reception of > VP8 that ANSWER > was received) > > (Personally, I hate inferences, but without a 3 (or 4) way > handshake, > you have to). If you switches of codecs are staged, then > this isn't > (much) of a problem. Either leave old codec on the list, or > leave it on > the list until accept, and then re-OFFER to remove the > un-used codec. > > > I think I understand what you mean, and this would work fine as > long as > you just switch codecs that are used in already set-up MediaStreams. > > But if A in this case, as part of re-OFFERING the session, not only > offers a new codec (VP8) for the already flowing video but also > adds a > new outgoing video stream (e.g. front cam), and then (without > receiving > the ANSWER - delayed in reception) starts receiving VP8 video it > could > not really know if this VP8 video is new video from the > responders front > cam or just a new codec for the existing (back cam) video from the > responder to the sender. > > > This may have been a very bad example. Probably you can tell them > apart on the SSRC. But even so, the A browser won't know what the > VP8 stream (if it has an unknown SSRC) represents without receiving > the ANSWER. > > > I think this is only an issue if you decide to add streams in the > ANSWER. But even so, eventually the ANSWER arrives and you can start > demuxing/decoding appropriately. Yes, I agree to that it is only an issue if you add streams in the answer. Perhaps it is a model we should move away from - but that is the model used in the basic examples of the JSEP draft. I think there is a risk of clipping if you start sending immediately, but can only start demuxing/decoding once an answer is received. > > Regardless, if the app wants to require some sort of ACK message to > begin transmission, or perhaps require that the remote side ask for the > media streams it wants to be sent, I think this could be implemented in > the app-specific signaling layer; the streams could initially be added > as inactive, and only changed to sendrecv when the ACK arrives. To me it is the browser that would need the info to be able give something sensible to the app for playout - not the app itself. > > > > > > One problem is what to do in the switchover window when you > might get a > mixture of old and new media, especially if you moved them > to different > ports and so can't count on RTP sequence re-ordering to > un-mix them; in > the past I dealt with that (and long codec-switch times) by > locking out > codec changes for a fraction of a second after I do one. > Not a huge > deal, however. > > My apologies if I've missed something in JSEP; I've been > heads-down > enough in Data Channels and bring-up that I could have a > disconnect here > and be saying something silly. > > > Actually I don't think this is very JSEP related; it is the generic > problem that the browser receiving RTP streams need some side > info about > them before being able to do anything sensible with them. > > > I think we need to find a way to handle this. One way is > to add an > "ACK" that indicates to the responder that the initiator > has received > the ANSWER, but I'm not sure that is the best way. > > > If you need to know that, you need a SIP-style ACK. > > > As explained, I do think we need to know that. > > > > _________________________________________________ > 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 Mon Apr 2 07:00: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 ED02F21F850B for ; Mon, 2 Apr 2012 07:00:49 -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=[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 pREjNRh8P8Te for ; Mon, 2 Apr 2012 07:00:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B7D0321F84EB for ; Mon, 2 Apr 2012 07:00:48 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-3b-4f79b10f21e9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E6.45.03534.F01B97F4; Mon, 2 Apr 2012 16:00:47 +0200 (CEST) Received: from [150.132.142.222] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012 16:00:43 +0200 Message-ID: <4F79B10B.9010207@ericsson.com> Date: Mon, 2 Apr 2012 16:00:43 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Clarify "simultaneous video add" of JSEP draft 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 Apr 2012 14:00:50 -0000 Hi Justin, I'm reading the JSEP draft (http://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/?include_text=1), and got to section 7.4 which is an example of simultaneous add of video. I think it is a very good thing to support, as one side adding video would not delay the other one (if doing so more or less simultaneously). However, I'm not sure I understand the flow in the example. I could make some guesses on what is happening, but I would rather not make a complete fool of myself - could you elaborate a little bit on it? Br, Stefan From roman@telurix.com Mon Apr 2 09:09: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 AD3D221F8680 for ; Mon, 2 Apr 2012 09:09:26 -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 2MFH1LjjyHqz for ; Mon, 2 Apr 2012 09:09:26 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57C21F865C for ; Mon, 2 Apr 2012 09:09:25 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2054826qcs.31 for ; Mon, 02 Apr 2012 09:09:25 -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=r4dwylDRkDG1RC5XxHk04/FyJRNtjZhz46FRoM7t0h0=; b=Lw1UylgU0Hac7bSTAEUacg31uTVOE1uYf40b+WUXnABNHRMwZbZmFeN72z/Gv7ouuG f0zsKPT1+ETaqhvQ6KiJkVvMM3VLC8THwxRxt8P3AAOeAdl03zZTXn8hJXK4bnXgT8Oz //hKr9b+F5T1o1dteh0fmCkh1ZCW1+RWBb6yEwZ4ZFfUpowe0/XWo9nk7ckusK+YX5kx 3/uEcyR0a7KRcZ5KfvtOIWodH8p6o+BduB7rU7826wlE1eFwVOXQ+8SZs56G17hosWGm /yqDbfySFyz6OIcK/qZV8ebNIl1y+5oD/E9De2yPK6X085S5YpAA4adYL0clRUCKWNdg kwaA== Received: by 10.224.213.7 with SMTP id gu7mr12027484qab.25.1333382965439; Mon, 02 Apr 2012 09:09:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id fp8sm35235296qab.20.2012.04.02.09.09.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 09:09:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1430628ghb.31 for ; Mon, 02 Apr 2012 09:09:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.237.1 with SMTP id uy1mr21835184pbc.99.1333382962969; Mon, 02 Apr 2012 09:09:22 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Mon, 2 Apr 2012 09:09:22 -0700 (PDT) In-Reply-To: <0E6A0E0D-BFDD-4974-87BE-B0DCD1ECE9D5@acmepacket.com> References: <4F7415D5.80604@ericsson.com> <0E6A0E0D-BFDD-4974-87BE-B0DCD1ECE9D5@acmepacket.com> Date: Mon, 2 Apr 2012 12:09:22 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b33cb6cdb7add04bcb469ad X-Gm-Message-State: ALoCoQkQ0ofXPO8j9mWJoI3oCd7OXgdTC3IfAVLPpSflVTpzYvR2bS+vimW5AmYuvGKqaZC0nerg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 16:09:26 -0000 --047d7b33cb6cdb7add04bcb469ad Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 2, 2012 at 9:02 AM, Hadriel Kaplan wrote: > > Hi, > I was thinking the tricky part is more about the local transport stuff > getting cloned - i.e., imagine if you're using a TCP-based TURN connection. > But maybe it's a non-issue. > > This really depends on how the TURN support is implemented, but typically using the same TCP connection or any other TURN allocation for multiple PC should be no more of an issue then using same connection for multiple streams within the PC. _____________ Roman Shpount --047d7b33cb6cdb7add04bcb469ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 2, 2012 at 9:02 AM= , Hadriel Kaplan <HKaplan@acmepacket.com> wrote:

Hi,
I was thinking the tricky part is more about the local transport stuff gett= ing cloned - i.e., imagine if you're using a TCP-based TURN connection.=
But maybe it's a non-issue.

=A0
This really depends on how the TURN sup= port is implemented, but typically using the same TCP connection or any oth= er TURN allocation for multiple PC should be no more of an issue then using= same connection for multiple streams within the PC.
_____________
Roman Shpount
--047d7b33cb6cdb7add04bcb469ad-- From randell-ietf@jesup.org Mon Apr 2 10:25: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 25D7421F85F2 for ; Mon, 2 Apr 2012 10:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_14=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 jRJj71-8bXBF for ; Mon, 2 Apr 2012 10:25:26 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1B66821F85ED for ; Mon, 2 Apr 2012 10:25:25 -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 1SEl0P-0002KY-2r for rtcweb@ietf.org; Mon, 02 Apr 2012 12:25:25 -0500 Message-ID: <4F79E03B.3090802@jesup.org> Date: Mon, 02 Apr 2012 13:22:03 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7415D5.80604@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] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 17:25:27 -0000 On 4/1/2012 11:21 PM, Justin Uberti wrote: > If the API provides a method where you can clone a current > peerConnection you can actually share the transport layer information at > one end-point for multiple peer connections assuming that the other > end-points transport addresses are different between the different > peerConnections being cloned. > > This works as the complete ICE username is the concatenation of both > sides, as long as an secondary answer contains a different username and > has candidates with different transport addresses (address+port). Then > end-point A receiving the second answer can have the ICE stack accept > both usernames and if connectivity checks works then you create > different 5-tuple filter to divide any media streams to the right peer > connections media handler. > Thanks Magnus. This sounds reasonable; it might even be possible to make > cloning work using the existing API by taking the local description from > one PC and installing it as the local description for a new PC; the > browser could recognize that the candidates refer to existing ports and > behave as you mention above. Yes, this seems like it would work. > However, given that this seems to be mostly an edge case, I think we can > probably save this for v2. So the question for me is "what scenarios/use-cases does this enable?" 1) Mesh Conferencing While there are many ways to handle conferencing, if you have a mesh (full or partial), you need to create new PeerConnections for existing members of the mesh when someone joins. There are two ways to do this: a) somehow application-specific tell the new member who to send invites to, and then start N PeerConnection calls with some "I'm in the conference" token; b)have them send N separate generic invites to the service provider which either forwards it to an existing member, or returns it with "it's ok, I've already forwarded invites for it); c) somehow tell all the existing members to invite the new member; or d) have the service provider fork the OFFER from the new member to all the existing members, and have all of them reply with ANSWERs. This requires PeerConnection cloning to work well. I strongly prefer d), and it also reduces conference join time (less round-trips, at least in theory - perhaps noticeably less by sharing the ICE candidate generation). 2) "Hanging" invites at a service provider You send an OFFER, which is "held" at the service provider and then "forked"/forwarded to other clients when the server decides to. This is of use in cases where there is external state (a game, virtual environment ala Second Life, virtual conference hall, etc) where something at the server decides when you should actually be connected and to whom (or multiple people). Example (applies to several of these): as you move around a game/virtual-environment, your app is connected to other nearby players when they're in audible range. This could be done by having the server tell your client to generate an OFFER (with attendant ICE discovery delay) on demand for each other person who comes in range, but that would be sub-optimal and again involve setup delay. It also allows permission to be dealt-with up front and not delay actual connection. I imagine there are others, but those are two which I think are pretty likely uses (we've been talking mesh conferences since the beginning, and this sort of environmental audio/teamspeak type stuff is an obvious use). Our game-table demo showed chess, but other uses would involve more players (4 for bridge, etc) where you might want a full-mesh conference). So, I'd really like to push to support cloning if possible. -- Randell Jesup randell-ietf@jesup.org From salvatore.loreto@ericsson.com Mon Apr 2 11:33: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 4948B21F85CE for ; Mon, 2 Apr 2012 11:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.749 X-Spam-Level: X-Spam-Status: No, score=-105.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_BACKHAIR_24=1, 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 DOCR4O2n7WCZ for ; Mon, 2 Apr 2012 11:33:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 420C821F85CC for ; Mon, 2 Apr 2012 11:33:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-e6-4f79f0fb5153 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9F.08.25560.BF0F97F4; Mon, 2 Apr 2012 20:33:32 +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.213.0; Mon, 2 Apr 2012 20:33:31 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4476D2323 for ; Mon, 2 Apr 2012 21:33:31 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5A61B52679 for ; Mon, 2 Apr 2012 21:33:31 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0F913517DB for ; Mon, 2 Apr 2012 21:33:31 +0300 (EEST) Message-ID: <4F79F0FA.80604@ericsson.com> Date: Mon, 2 Apr 2012 21:33:30 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F760634.207@ericsson.com> <4F761AFC.5090503@jesup.org> In-Reply-To: <4F761AFC.5090503@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Data channel comments and questions 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 Apr 2012 18:33:34 -0000 On 3/30/12 11:43 PM, Randell Jesup wrote: >>> >> 2. Multihoming and interface switching: I don't suggest going for the >>> >> multipath support on the SCTP level. I think it would be best to deal >>> >> with this through ICE in the same way as for RTP, i.e. adding and >>> >> removing candidates as interfaces become available or go. Or let the >>> >> application handle it by creating a new data channel and continue from >>> >> the breakpoint. The most important requirement is that the application >>> >> gets notified about these changes downstrairs so it can act. >> > that is exact the proposal in the data-channel draft. >> > Anyway you can not use multihoming because of the fact that SCTP runs on >> > top of DTLS > Correct, though there was some in-room discussion of running it over > multiple DTLS connections to support smooth handoff across interfaces > (think mobile and 4g<->WiFi switchover). definitely, that is also something else worth to investigate more deeply -- Salvatore Loreto, PhD www.sloreto.com From chat2jesse@gmail.com Mon Apr 2 16: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 0C81B21F874C for ; Mon, 2 Apr 2012 16:34:50 -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=[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 wCXH21KFEdDD for ; Mon, 2 Apr 2012 16:34:49 -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 2AE6321F867B for ; Mon, 2 Apr 2012 16:34:49 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2636605obb.31 for ; Mon, 02 Apr 2012 16:34: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=3EIlHgLBrpg2tozq915yXmCJccF4+1o5jb0krlCr/zY=; b=fGj18kDJw7ScTTEBfKF0A4ZSvsFE8M0H7bkw0iL8COe/3HrphWf5BjgbPUPvXL6lUG TUXHtYVFmJgbu2LUzl3AmC3NKBWGGAcJcXGB47c1OVeTs1XqU1dPeOMvBSSOjSwSm/5S QM98VJUw8Us0pScpUuFM901/29pYFfrSByHY8+smA22rkzfk9vGPAj1/2WwOO5Zv6Nu9 KY1+1ErRXp5dTJZTSLLbBisXHxwJWPw2xKv3WpkGWfYzWWcWN2eX1ZWRXi/kbf0Zo9cw saMdsOT0afC9rk/+yyUib2joFdLwfvJb2TN1/dA0mimFTj704hBZNtWuP+PDzjWlQusn YPAA== MIME-Version: 1.0 Received: by 10.60.13.37 with SMTP id e5mr15523083oec.70.1333409688533; Mon, 02 Apr 2012 16:34:48 -0700 (PDT) Received: by 10.182.60.105 with HTTP; Mon, 2 Apr 2012 16:34:46 -0700 (PDT) Received: by 10.182.60.105 with HTTP; Mon, 2 Apr 2012 16:34:46 -0700 (PDT) In-Reply-To: <4F737DB3.5020804@hidayahonline.org> References: <4F732531.2030208@ericsson.com> <4F737DB3.5020804@hidayahonline.org> Date: Mon, 2 Apr 2012 16:34:46 -0700 Message-ID: From: jesse To: Basil Mohamed Gohar Content-Type: multipart/alternative; boundary=e89a8fb1f350d33d2104bcbaa26b Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security 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 Apr 2012 23:34:50 -0000 --e89a8fb1f350d33d2104bcbaa26b Content-Type: text/plain; charset=ISO-8859-1 On Mar 28, 2012 2:08 PM, "Basil Mohamed Gohar" < abu_hurayrah@hidayahonline.org> wrote: > > On 03/28/2012 04:41 PM, Roman Shpount wrote: > > My main objection is that if an application developer does not take > > care to develop a secure application, nothing you can do on the > > standard side will make it a secure application. If I am building a > > public voice blog that records a voice message that anybody can listen > > to on the web site security is not needed. My assumption is that a > > fair number of applications would be like this. So for such > > applications this is an unnecessary feature. > > > > WebRTC will not exist in vacuum. It will communicate with other > > systems. It is not limited to old SIP devices. It can be something new > > like server side speech recognition that is integrated with web > > application. For such application extra code and interop requirements > > to support security will represent a real and significant cost. Any > > requirement, unless absolutely necessary will create barriers to entry > > for new applications. I would like to avoid as many of those as > > possible. > > _____________ > > Roman Shpount > Roman, > > You make a lot of good points. However, the inverse is true as well - > namely, that is if encryption is not mandated, most implementations will > likely leave it out, That means SRTP unnecessary to fullfill major practical usage cases. The decision to use telnet or ssh for remote desktop should be made by IT department, not by standard committee. - jesse and adoption of secured communications would be > stifled even longer. I cannot speak about the implementation > difficulties, but I can speak from the user side that most people will > remain ignorant of the underlying technology and not know enough to > demand nor enable a feature if it is optional to implement and/or use. > > As WebRTC is a new standard, requiring encryption will ensure that, at > least going forward, the important concept of encryption is widely > adopted correctly from the beginning. Tacking it on later, no matter > how much it is emphasized, will be difficult or impossible. > > The scope of WebRTC is broad enough to consider that we need to think > about what's best going forward with regards to its implementation. > Security by default is one of the best practices in general, the support > from the browser community and others that are behind it will definitely > ensure that adoption is widespread enough to make it easy enough to > integrate into existing systems, as free software solutions will become > available shortly after the standard emerges. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --e89a8fb1f350d33d2104bcbaa26b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 28, 2012 2:08 PM, "Basil Mohamed Gohar" <abu_hurayrah@hidayahonline.org> = wrote:
>
> On 03/28/2012 04:41 PM, Roman Shpount wrote:
> > My main objection is that if an application developer does not ta= ke
> > care to develop a secure application, nothing you can do on the > > standard side will make it a secure application. If I am building= a
> > public voice blog that records a voice message that anybody can l= isten
> > to on the web site security is not needed. My assumption is that = a
> > fair number of applications would be like this. So for such
> > applications this is an unnecessary feature.
> >
> > WebRTC will not exist in vacuum. It will communicate with other > > systems. It is not limited to old SIP devices. It can be somethin= g new
> > like server side speech recognition that is integrated with web > > application. For such application extra code and interop requirem= ents
> > to support security will represent a real and significant cost. A= ny
> > requirement, unless absolutely necessary will create barriers to = entry
> > for new applications. I would like to avoid as many of those as > > possible.
> > _____________
> > Roman Shpount
> Roman,
>
> You make a lot of good points. =A0However, the inverse is true as well= -
> namely, that is if encryption is not mandated, most implementations wi= ll
> likely leave it out,

That means SRTP unnecessary to fullfill major practical usage cases.

The decision to use telnet or ssh for remote desktop should be made by I= T department, not by standard committee.

- jesse

and adoption of secured communications would be
> stifled even longer. =A0I cannot speak about the implementation
> difficulties, but I can speak from the user side that most people will=
> remain ignorant of the underlying technology and not know enough to > demand nor enable a feature if it is optional to implement and/or use.=
>
> As WebRTC is a new standard, requiring encryption will ensure that, at=
> least going forward, the important concept of encryption is widely
> adopted correctly from the beginning. =A0Tacking it on later, no matte= r
> how much it is emphasized, will be difficult or impossible.
>
> The scope of WebRTC is broad enough to consider that we need to think<= br> > about what's best going forward with regards to its implementation= .
> Security by default is one of the best practices in general, the suppo= rt
> from the browser community and others that are behind it will definite= ly
> ensure that adoption is widespread enough to make it easy enough to > integrate into existing systems, as free software solutions will becom= e
> available shortly after the standard emerges.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--e89a8fb1f350d33d2104bcbaa26b-- From ibc@aliax.net Mon Apr 2 16:45: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 B470321F86F7 for ; Mon, 2 Apr 2012 16:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 VYIXXbtJ9g6t for ; Mon, 2 Apr 2012 16:45:43 -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 2613A21F86F1 for ; Mon, 2 Apr 2012 16:45:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2406763vbb.31 for ; Mon, 02 Apr 2012 16:45: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=E5ckXDxhJ72Hd+LPWTMCsOFy+/QJYeEB/40Vf3vqogk=; b=YTtIMFFSlGJB46EAt2xN878cpaRE+eREfJA64yAFfGURrpS3bNTQVD/4MpmrcIiprj rIfNMisaFF/cnd9FJ+FdkY0EVqIlHvV+0y+twvWtajhMjuRVm+TnNSxuXO1M64b/aPWO kg7JdS3RVaddYG0PSpJhgVny+W+7L/7Pup5T3GVeWpRZjCL05yLZf6KwJUiHlLCyCAEQ 2b8xnHhDUcSYPXSODQ4L/xzxNiWX15uf4jGKYE4dSqhZHxm3VHz7N+U3sOfeZsDHCmV2 FL7icokkAov/f7lIy+YPlkEcn952gzxPNFiHeJy+JUgXgk5MG7DgxwKmhDGHv0z0IQRg JAmw== MIME-Version: 1.0 Received: by 10.52.22.148 with SMTP id d20mr4089285vdf.102.1333410342658; Mon, 02 Apr 2012 16:45:42 -0700 (PDT) Received: by 10.52.170.165 with HTTP; Mon, 2 Apr 2012 16:45:42 -0700 (PDT) Received: by 10.52.170.165 with HTTP; Mon, 2 Apr 2012 16:45:42 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> <4F737DB3.5020804@hidayahonline.org> Date: Tue, 3 Apr 2012 01:45:42 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: jesse Content-Type: multipart/alternative; boundary=20cf307d00f0d0616204bcbac9c8 X-Gm-Message-State: ALoCoQmwcam4TIrk/LYTq0JeR8VLNLmKqOZPTxPy/Oeu+xfRgJWjmp0gnZN9I+Wg+5wD2i3coMvT Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security 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 Apr 2012 23:45:45 -0000 --20cf307d00f0d0616204bcbac9c8 Content-Type: text/plain; charset=UTF-8 Mar 28, 2012 2:08 PM, "Basil Mohamed Gohar" wrote: > > That means SRTP unnecessary to fullfill major practical usage cases. > > The decision to use telnet or ssh for remote desktop should be made by IT department, not by standard committee. The more than 500 millions of Facebook users are end users, not an IT department. --20cf307d00f0d0616204bcbac9c8 Content-Type: text/html; charset=UTF-8

Mar 28, 2012 2:08 PM, "Basil Mohamed Gohar" <abu_hurayrah@hidayahonline.org> wrote:

>
> That means SRTP unnecessary to fullfill major practical usage cases.
>
> The decision to use telnet or ssh for remote desktop should be made by IT department, not by standard committee.

The more than 500 millions of Facebook users are end users, not an IT department.

--20cf307d00f0d0616204bcbac9c8-- From roman@telurix.com Mon Apr 2 17:44: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 6615B21F8683 for ; Mon, 2 Apr 2012 17:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 Pqf-0ycAO9qI for ; Mon, 2 Apr 2012 17:44:09 -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 85EC721F8682 for ; Mon, 2 Apr 2012 17:44:04 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4886727pbb.31 for ; Mon, 02 Apr 2012 17:44:04 -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=rdE4i7QH1tg8atSaTM1pB63oI/o/LqTIqVJjbLmIlhk=; b=OH80DbOofFoLgc96SDsQ7Fb652Pbs2msT7uL0+Cwzgr6LIcNH+dyYpyLWxI49Z2lrp eBngLBfEt982gNY5rji79tCnE+QUW50o/7vVCX1H0seTI5S0/tz0o3+9XOnXGi4GyRUD UtDo5XrSjK+A8m8wB4b77d//8R9wceFUx4TuY/PZXg+r2SQhkdN5E4ZoClvJvnGuDLYy gPrrBqGWsGzKhyI3kv5ZjE5dbLamBrwTfC/5IsjWEmuGMPDwBhJdhaIwh0GMixhlJr4B Nn3THkZLfqPmr/LgmOKQgK3q37kTI6/1Xrmq7Jo/u12zKCVKBDqC1IOfTstX4B4qzZUY PfzQ== Received: by 10.68.136.41 with SMTP id px9mr24262664pbb.147.1333413844244; Mon, 02 Apr 2012 17:44:04 -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 z5sm15077866pbn.35.2012.04.02.17.44.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 17:44:03 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4886702pbb.31 for ; Mon, 02 Apr 2012 17:44:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.72.138 with SMTP id d10mr24989402pbv.15.1333413841486; Mon, 02 Apr 2012 17:44:01 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Mon, 2 Apr 2012 17:44:01 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> <4F737DB3.5020804@hidayahonline.org> Date: Mon, 2 Apr 2012 20:44:01 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d040f9bae5c423604bcbb9ac5 X-Gm-Message-State: ALoCoQkmkpaCk9HgrXI8Urz/QxMe53HaXXNeOTny4h0TI79ktxff/ipuGiivTAlgEGe1wzEJFlvT Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security 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 Apr 2012 00:44:09 -0000 --f46d040f9bae5c423604bcbb9ac5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 2, 2012 at 7:45 PM, I=F1aki Baz Castillo wrote: > The more than 500 millions of Facebook users are end users, not an IT > department. > If Facebook does not want to provide security to its users, standards committee will not make it secure. _____________ Roman Shpount --f46d040f9bae5c423604bcbb9ac5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 2, 2012 at 7:4= 5 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
On Wed, Mar 28, 2012 at 5:08 P= M, Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org> wrote:
You make a lot of good points. =A0However, the inverse is true as well - namely, that is if encryption is not mandated, most implementations will likely leave it out, and adoption of secured communications would be
stifled even longer. =A0I cannot speak about the implementation
difficulties, but I can speak from the user side that most people will
remain ignorant of the underlying technology and not know enough to
demand nor enable a feature if it is optional to implement and/or use.


If application developer does not care about sec= urity nothing we do will force the application to be secure. For instance, = if SDES-SRTP is allowed, I can implement something that will communicate wi= th it with less then 1000 lines of code. I will drop the replay protection,= real random key generation and will just leave AES-CM and check sum calcul= ation. This will still successfully communicate with WebRTC end points but = will not be secure by a long stretch. We can provide the tools to secure th= e communications, but unless application is properly developed, it will onl= y go through the motions of encryption without achieving any real results. = So, as a result, allowing non-encrypted communications will actually result= in more secure ecosystem. Where people who need security will support it, = and people who do not need security will clearly show that secure communica= tions are not implemented by their application.
_____________
Roman Shpount

--e89a8ff1cce4afb4bc04bcbbba6f-- From harald@alvestrand.no Tue Apr 3 03:10: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 557FC21F871C for ; Tue, 3 Apr 2012 03:10:36 -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 N5S6F7r+ITer for ; Tue, 3 Apr 2012 03:10:35 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCFA21F871A for ; Tue, 3 Apr 2012 03:10:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 78F5D39E173 for ; Tue, 3 Apr 2012 12:10:29 +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 MMnxKAEdLJG3 for ; Tue, 3 Apr 2012 12:10:28 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C962F39E146 for ; Tue, 3 Apr 2012 12:10:28 +0200 (CEST) Message-ID: <4F7ACC96.90206@alvestrand.no> Date: Tue, 03 Apr 2012 12:10:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch> In-Reply-To: <4F749C82.4070305@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Which servers to trust (Re: Consensus call regarding media security) 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 Apr 2012 10:10:36 -0000 Changing the subject, since this message is not a position on the consensus call. On 03/29/2012 07:31 PM, Fabio Pietrosanti (naif) wrote: > On 3/29/12 7:02 PM, Ravindran, Parthasarathi wrote: >> WebRTC trust model has to be considered as one of the main factor for deciding the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HTTPS RTCWeb server must be trusted in case of SDES. There is no means to track or analyze whether Dr.Evil involves in monitoring or recording or terminate the media traffic. It will be good in case whoever advocate for SDES explain how SDES fits within WebRTC trust model. > Sure! > > From: > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/?include_text=1 > > " The basic assumption of this architecture is that network resources > exist in a hierarchy of trust, rooted in the browser, which serves as > the user's TRUSTED COMPUTING BASE (TCB). Any security property which > the user wishes to have enforced must be ultimately guaranteed by the > browser (or transitively by some property the browser verifies)." > > So, it means that if the browser already have a hierarchy of trust to > use TLS for HTTPS, then SDES-SRTP will inherit the trust-properties of > the HTTPS website from which it's loaded. Ahem.... SDES-SRTP will "inherit" the property that as long as the HTTPS trust chain is intact, only attacks where the HTTPS website, or entities that the HTTPS website chooses to reveal the key to (voluntarily or involuntarily) can listen in on the call. (The plenary at the IETF made interesting background for this claim.) > It seems to me quite easy to fit SDES-SRTP into the browser model, as it > allow you to assure that the communication path between the client and > the server is secure. > > Do you expect WebRTC to be only peer-to-peer/client-to-client? > > I sincerly expect *a lot* of communications to goes trough SIP/RTP media > proxy for security purpose, for billing purposes, for value added > service purpose. In the cases where a gateway needs to decrypt the packets, the gateway is the logical peer with the browser in the (DTLS-)SRTP trust relationship. > SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to > establish security with the server, assuming that it already have > established security trough HTTPS/TLS that's a consolidate trust method. The term "the server" is a fallacy. The Web server and the media gateway (if there is one) are likely not the same server, and may even be operated by different entities. SDES-SRTP forces you to trust both. > From ibc@aliax.net Tue Apr 3 04:55: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 C65FB21F875A for ; Tue, 3 Apr 2012 04:55:59 -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=[AWL=0.079, 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 Wg8s9AUoPV25 for ; Tue, 3 Apr 2012 04:55:59 -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 0A57221F8759 for ; Tue, 3 Apr 2012 04:55:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2761255vbb.31 for ; Tue, 03 Apr 2012 04:55:58 -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=eagaw3gz14m4sACeCfh6QcJmr7NY2rUIcWnxeE9OFrQ=; b=E0IOOQ28H4XK2GCJWRtUEoe9OhLKe2aw58sjet3w+qe91yshZRrXVGdfHSDrU2yYMX 7j/XBliTCPktftP6w2A6vxTT1SVceeWYpTIc//1iVki6Vpio/mlRlpNa5KbmUqx/zjjZ QQskthj35gKJkD+8aKeDOo8OTfDceNMwg3kR6LmrRh/6JnLwev2wGHs7vWUX6jl3JpNl Xucr9CEBq+hWtE9K9QPiOK8Kl9OEKmbUK1gtVXIMuH8UNHnA4LZWLzCjl3ePmqNjvn1d z+0JKrrfuNY7FrTclsIibCPSmaiKwWWluIf5BaA0vkuUGSaFvACHmIOEWybHDZPpFa57 uZ1A== Received: by 10.52.27.1 with SMTP id p1mr5505322vdg.17.1333454158494; Tue, 03 Apr 2012 04:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 04:55:38 -0700 (PDT) In-Reply-To: <4F7ACC96.90206@alvestrand.no> References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch> <4F7ACC96.90206@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 13:55:38 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn1vKWCCEgGdFzxtKnr/wZ0dBjTd3X4++XuBUI7r5fMXjbPFYKwOj4fhBOOMP2K/HFzlStE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Which servers to trust (Re: Consensus call regarding media security) 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 Apr 2012 11:55:59 -0000 2012/4/3 Harald Alvestrand : >> SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to >> establish security with the server, assuming that it already have >> established security trough HTTPS/TLS that's a consolidate trust method. > > The term "the server" is a fallacy. The Web server and the media gateway = (if > there is one) are likely not the same server, and may even be operated by > different entities. > SDES-SRTP forces you to trust both. If you trust the Web server (i.e. due to HTTPS usage with a valid server certificate) then you will also trust that the Web server will not signal your WebRTC communication to a malicious destination, am I wrong? Don't take me wrong but, which kind of security obsession are we trying to satisfy in rtcweb? a media communication is not more important than a web access to my back website in which I enter my credit card PIN. Does IETF define "security standards" for POS ("Point of sale terminal") for making a bank payment via a 3rd web (e-commerce)? AFAIK not. If the Web server (assuming HTTPS) is trusted and SDES-SRTP used, we should trust the communication. If it fails that is because the Web server has been attacked. If that occurs, it's really worse the case in which my bank website has been attacked (I'm giving my credit card PIN to the attacker). Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Apr 3 04:57: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 1406F21F8570 for ; Tue, 3 Apr 2012 04:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, 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 ZCkXZEvBi8t3 for ; Tue, 3 Apr 2012 04:57:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE621F856A for ; Tue, 3 Apr 2012 04:57:11 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2773838vcb.31 for ; Tue, 03 Apr 2012 04:57:10 -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=rrXRik4p45g7KlRLrKz6GTv2c6a2Km9jQG8CItLN/Qo=; b=iIpQxfWFaWgpjKjApWr+hLttw1dxeA5YlX5Src3ZbXZ0KyzdvmcgYlxgscRy70KGa5 cBtNYq7b1Gxp7jjzQEx6Uo4UD2Hs9WSpfIoIdprOR6D9Z/gdNXhsCWsvbT0joeHnamFu C6G17M+pQnibaEA3ieohSrmty/cragmE0Y07+LAhNerh+5bKYD+66lSQMenoQ2mu7Gt6 komN2TIRKquhBo23q5GUAFdkCuF1lKyLp8Jr6C9JkUP6VVf447Fm9mwRAOOlywp757yR 4I7o47QdgH7jRfdgwlrTQpB2s3HUZFKhHL/Qmm1KMTXDxYRwp29K7TbKZgoy4Xt64ym3 8YNA== Received: by 10.52.15.233 with SMTP id a9mr5403274vdd.34.1333454230649; Tue, 03 Apr 2012 04:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 04:56:50 -0700 (PDT) In-Reply-To: References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch> <4F7ACC96.90206@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 13:56:50 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQknXctgIjvkwx3zPUz3Jw6SNwarr5VjFjN//9e3s9aSA43lsQWWE9IgohgNIYyAwd3qnMSA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Which servers to trust (Re: Consensus call regarding media security) 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 Apr 2012 11:57:12 -0000 2012/4/3 I=C3=B1aki Baz Castillo : > Don't take me wrong but, which kind of security obsession are we > trying to satisfy in rtcweb? a media communication is not more > important than a web access to my back website typo: I meant "bank website" --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Tue Apr 3 05:35: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 7A53B21F879D for ; Tue, 3 Apr 2012 05:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_40=-0.185, SARE_MILLIONSOF=0.315] 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 4jSJsadDPfrb for ; Tue, 3 Apr 2012 05:35:15 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A4FC121F8764 for ; Tue, 3 Apr 2012 05:35:15 -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 1SF2x8-0001hQ-1g for rtcweb@ietf.org; Tue, 03 Apr 2012 07:35:14 -0500 Message-ID: <4F7AEDB6.8000907@jesup.org> Date: Tue, 03 Apr 2012 08:31:50 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch> <4F7ACC96.90206@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Which servers to trust (Re: Consensus call regarding media security) 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 Apr 2012 12:35:16 -0000 On 4/3/2012 7:55 AM, Iñaki Baz Castillo wrote: > 2012/4/3 Harald Alvestrand: >>> SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to >>> establish security with the server, assuming that it already have >>> established security trough HTTPS/TLS that's a consolidate trust method. >> >> The term "the server" is a fallacy. The Web server and the media gateway (if >> there is one) are likely not the same server, and may even be operated by >> different entities. >> SDES-SRTP forces you to trust both. > > > If you trust the Web server (i.e. due to HTTPS usage with a valid > server certificate) then you will also trust that the Web server will > not signal your WebRTC communication to a malicious destination, am I > wrong? Partly. First, as you mention, the site can be hacked. Another issue is that you may NOT trust the website to avoid tapping your communication (and in fact they may be legally obligated to do so, and have no choice in the matter). Also, as shown by Diginotar, website certs can be forged transparently if a CA is hacked. Those are both real-world cases where you cannot trust the site you connect to via https to secure your data (in addition to "the site was hacked", even if they are "trustworthy". > Don't take me wrong but, which kind of security obsession are we > trying to satisfy in rtcweb? a media communication is not more > important than a web access to my back website in which I enter my > credit card PIN. Does IETF define "security standards" for POS ("Point > of sale terminal") for making a bank payment via a 3rd web > (e-commerce)? AFAIK not. No, but other organizations define such standards in great detail - and still there are weekly breaches of security that require credit card companies to send out thousands or millions of replace cards & numbers. And a site providing media communication will not have the ultra-strict security reviews and audits that come with processing credit card info, and so is much more likely to be hacked. > If the Web server (assuming HTTPS) is trusted and SDES-SRTP used, we > should trust the communication. If it fails that is because the Web > server has been attacked. If that occurs, it's really worse the case > in which my bank website has been attacked (I'm giving my credit card > PIN to the attacker). It can be far worse - most people are given guarantees about how much they can lose (often $0) - a hassle is all usually; sometimes a big hassle, but not harmful personally. Media interception (especially video) can cause horrible repercussions in some cases - blackmail, embarrassment, scandal, and in countries like Iran or cases like the Arab Spring, jail or death. -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Tue Apr 3 05:58: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 C17FD21F879C for ; Tue, 3 Apr 2012 05:58:58 -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 S1f2ifF5kyjh for ; Tue, 3 Apr 2012 05:58:58 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5411C21F879B for ; Tue, 3 Apr 2012 05:58:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9876A39E173 for ; Tue, 3 Apr 2012 14:58:52 +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 plg4kSLGd2lk for ; Tue, 3 Apr 2012 14:58:52 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2478C39E146 for ; Tue, 3 Apr 2012 14:58:52 +0200 (CEST) Message-ID: <4F7AF40D.3010706@alvestrand.no> Date: Tue, 03 Apr 2012 14:58:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Identity and PSTN gateways 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 Apr 2012 12:58:58 -0000 One thing that has come up repeatedly in the discussion is the claim that "you can't have a verified identity when you talk to someone via a telephone gateway" (and therefore is not needed / not an added benefit / other claim). I think this is a fallacy. Sure, as people have commented numerous times, telephone numbers are identities; they're being used as such every time someone prints them on a business card or a billboard. When you're connecting via a gateway to the PSTN, the gateway operator gives you a guarantee that you're being connected to the right person; that's what gateways are for. This makes for a fairly simple mapping to the "identity / identity provider" model we've been bandying about for the "full-blown" IdP / endpoint case: The identity is the telephone number. The identity provider (one of many possible ones for the number) is the gateway operator. Thus - if you call a telephone number via a gateway, you would perform a DTLS key exchange with the gateway, and an identity verification exchange with the gateway operator; you would then guarantee that the gateway operator vouches for this being a legitimate gateway function that you can reach for that number. That's just about the best guarantee you can get when talking to the telephone system. But if we're using the IdP + DTLS-SRTP version, the exchange guarantees you that: a) nobody is listening in between you and the gateway (even if they snooped your signalling) b) the gateway operator vouches for the gateway being the right gateway to reach that number Seems like a little bit better than what you get with SDES. Only a little. Harald From oej@edvina.net Tue Apr 3 06:05: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 2C8C911E8087 for ; Tue, 3 Apr 2012 06:05:31 -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 YjqBkIyMXWq4 for ; Tue, 3 Apr 2012 06:05:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 63E3811E8088 for ; Tue, 3 Apr 2012 06:05:29 -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 25192754A8AA; Tue, 3 Apr 2012 13:05:27 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4F7AF40D.3010706@alvestrand.no> Date: Tue, 3 Apr 2012 15:05:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7AF40D.3010706@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1257) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 13:05:31 -0000 3 apr 2012 kl. 14:58 skrev Harald Alvestrand: > One thing that has come up repeatedly in the discussion is the claim = that "you can't have a verified identity when you talk to someone via a = telephone gateway" (and therefore is not needed / not an added benefit / other claim). >=20 > I think this is a fallacy. >=20 > Sure, as people have commented numerous times, telephone numbers are = identities; they're being used as such every time someone prints them on = a business card or a billboard. >=20 > When you're connecting via a gateway to the PSTN, the gateway operator = gives you a guarantee that you're being connected to the right person; = that's what gateways are for. >=20 > This makes for a fairly simple mapping to the "identity / identity = provider" model we've been bandying about for the "full-blown" IdP / = endpoint case: >=20 > The identity is the telephone number. > The identity provider (one of many possible ones for the number) is = the gateway operator. >=20 > Thus - if you call a telephone number via a gateway, you would perform = a DTLS key exchange with the gateway, and an identity verification = exchange with the gateway operator; you would then guarantee that the = gateway operator vouches for this being a legitimate gateway function = that you can reach for that number. >=20 > That's just about the best guarantee you can get when talking to the = telephone system. But if we're using the IdP + DTLS-SRTP version, the = exchange guarantees you that: > a) nobody is listening in between you and the gateway (even if they = snooped your signalling) > b) the gateway operator vouches for the gateway being the right = gateway to reach that number >=20 > Seems like a little bit better than what you get with SDES. Only a = little. Now we will have to separate "PSTN-emulating" gateways that accept calls = to all phone numbers but play a prompt saying "You gotta be kidding me - = calling a phone number?" from REAL gateways that have a connection to = the PSTN world.=20 Will guys connecting with SS7 have a certificate signed by the ITU as a = "TRUE" PSTN provider and the voip guy in the basement next door just = have a "Best effort fourth-tier PSTN service" certificate? I think that any identity of any PSTN gateway just identifies the = gateway as a server. Not as a service. /O= From ibc@aliax.net Tue Apr 3 06: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 7E69821F86BD for ; Tue, 3 Apr 2012 06:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.040, 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 3XeoEPViN-2Y for ; Tue, 3 Apr 2012 06:13:40 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD41C21F86B3 for ; Tue, 3 Apr 2012 06:13:40 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2826817vcb.31 for ; Tue, 03 Apr 2012 06:13:40 -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=QnPfSkt6luw9YbHaG1Qd9Wm2iEUf8lj3aCNq5rX8RZQ=; b=YprcdZ/ZsVItSwDAVEkZdw6c7SCqz/ay5WM7m7qHzuYHjmpX9ikewwaAXaZKH80KgW 3ayatTC942EkQeGt4tMCfqKbmdYM2BefppeyOad6c4uA00EatTaNi5o2vjOwPX1jb8pF hYkjvWiGm4eEqDUmASBZxhVEia5GxyNQ0QsMSz2m/tmg4C3UgJrRV5vaW1qfqGC5GmjP ribzNvOdTkQ2bsR1phCdqWGZhFNBLFkHQY9Dxg4OgCca0Qfg0wPyImSfti8s8bL1aS59 LUHi5SrLNc5nEobLT1CuST6waxJDkXzqe5pFUwHE5IWeOmAZV1vn5CfT54rVknhAzjA0 qidw== Received: by 10.220.140.196 with SMTP id j4mr6263002vcu.22.1333458820169; Tue, 03 Apr 2012 06:13:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 06:13:20 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 15:13:20 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmwtWZlKEtsM+Fq6xleV1/fYbUtQd9RL+38qfJ3ED69nbI1py76rJXmoYM6YzdIqGElSd4E Subject: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 13:13:41 -0000 Hi all, I've made two "pictures" showing WebRTC and SIP interop for two cases: 1) SDES-SRTP is allowed in WebRTC: http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png 2) Just DTLS-ETK-SRTP is allowed in WebRTC [*] http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png [*] slides 30-35 in http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf For those claiming to mandate *just* DTLS-EKT-SRTP in WebRTC, please see the *cost* of such a decision, and also: - Thanks for requiring a super Signaling+Media B2BUA/SBC in WebRTC/SIP interop scenarios. Some vendors will be very happy and will become very rich. Such a super device (also a DTLS to SDES conversor, including DTLS key updates to re-INVITE) will be "a bit"... expensive. - Thanks for disallowing *pure* SIP protocol usage (and instead requiring SIP B2BUAs/SBCs or custom WebRTC signaling to SIP conversion gateways). WebRTC is supposed to let the signaling protocol up to the application, but pure SIP protocol will not be possible since a SIP B2BUA/SBC is required, and those devices always break/limit the SIP protocol (*always*). So IMHO, option 2 ("just DTLS-EKT-SRTP is allowed in WebRTC") is The Barrie= r. Best regards. PS: Note that the same is true for WebRTC/XMPP-Jingle interop. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Apr 3 06:31: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 DEAF411E8074 for ; Tue, 3 Apr 2012 06:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, 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 ckamFhgFIaNr for ; Tue, 3 Apr 2012 06:31:59 -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 AA7E211E8072 for ; Tue, 3 Apr 2012 06:31:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2830382vbb.31 for ; Tue, 03 Apr 2012 06:31:53 -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=AMEinye633qgbyou00qAtOG+aWJ8w/nb5K9OxdVTrqw=; b=c6IyZcHQeS1yJQoXbD1q3RshMuZlSYdBzIaKhiknSfaOo63nGnJ44y6+cOeFDNyQCk osbxkZ1vuk7/Ing4GeCwkN6GLf/YQrJ/McwFzxkFqmTC+oxGVmIMk4fZ6lYkErCb6iWa RJdx0qyjpY0BVE8/sv8gXPTXzgVJGcffPkQDsOET+w0I68dW6S1vZC26xeiBEXmz+L06 0AwEsvXlxMulpcNCCAgdVJHyoISljdhhoeXehQp1rxicIY7sqMSuHY9MHF8tY1qSg8Ma 7mA/u/vm0avo9D8AsD5RMuHwmx0AK92QALHidjRE0XoA1yCKYYGVeCkPWzd9Fs9F4HtQ gMnA== Received: by 10.52.88.4 with SMTP id bc4mr5480472vdb.51.1333459913146; Tue, 03 Apr 2012 06:31:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 06:31:33 -0700 (PDT) In-Reply-To: <4F7AF40D.3010706@alvestrand.no> References: <4F7AF40D.3010706@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 15:31:33 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkZsIoCzJLYMPXKLFRieOKb3KZoTCXhC4h0ePMVMJAjSF4CB/nJZmGFPjnG6mT+ZFt/2PUg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 13:32:00 -0000 2012/4/3 Harald Alvestrand : > Thus - if you call a telephone number via a gateway, you would perform a > DTLS key exchange with the gateway A super gateway like in in this figure: http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png Taking into account that SIP-PSTN gateways into most of the SIP PSTN providers don't support SRTP or ICE, how long will take the scenario you mean to become real and widely adopted/implemented? IMHO 10 years. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Tue Apr 3 06:48: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 1AD8821F86CA for ; Tue, 3 Apr 2012 06:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 UsVuahcvdFMl for ; Tue, 3 Apr 2012 06:48:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A451821F86C6 for ; Tue, 3 Apr 2012 06:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E12F239E173; Tue, 3 Apr 2012 15:48:52 +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 kMV4gRzVMStL; Tue, 3 Apr 2012 15:48:51 +0200 (CEST) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8825439E146; Tue, 3 Apr 2012 15:48:51 +0200 (CEST) Message-ID: <4F7B0033.7060101@alvestrand.no> Date: Tue, 03 Apr 2012 15:50:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F7AF40D.3010706@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 13:48:55 -0000 On 04/03/2012 03:31 PM, Iñaki Baz Castillo wrote: > 2012/4/3 Harald Alvestrand: >> Thus - if you call a telephone number via a gateway, you would perform a >> DTLS key exchange with the gateway > A super gateway like in in this figure: > > http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png > > Taking into account that SIP-PSTN gateways into most of the SIP PSTN > providers don't support SRTP or ICE, how long will take the scenario > you mean to become real and widely adopted/implemented? IMHO 10 years. > Real: 1 year. Widely adopted: Just in time to see the PSTN shut down because nobody uses it any more :-) From ibc@aliax.net Tue Apr 3 06:53: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 6773721F8526 for ; Tue, 3 Apr 2012 06:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.026, 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 B1KiDOV-qyg6 for ; Tue, 3 Apr 2012 06:53:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E20F711E8079 for ; Tue, 3 Apr 2012 06:53:00 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2858091vcb.31 for ; Tue, 03 Apr 2012 06:53:00 -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=sB/Hy0p20QR9JFZbBmCaLJ2Ql608vxX0soYagq0Uxcw=; b=cRAhnrXd1DjpaLUMpQAc2PladQXtaJer+7MvGSpUPk47hmfHNNx1J5ueHHBwdLhwRK 5FWns+wbTU3ymKL6cywQ0Y41R463NKEx2QqWKxyxMvipdPKbfmk1fgeGN0AsUDjpQ2vt PANxqPTVleytLPTibZRknpPK0JPVGy6YjN64oZeHSEoVAtz0POE71xcMPk1kxmt3gY9C OnrGZpM2kmP91NTC/xpWjfWqFxD9+SOO5AraQRSDFrrs6r5jjpnl+lZtI5eK4FzBg6g0 hzibvDAG9kVKKnZL/a+l16xJUKY3eBMN2w1hdfgaq14dzE6/9oNVq3i915jNnCMGIOEa AEaw== Received: by 10.52.88.4 with SMTP id bc4mr5509473vdb.51.1333461179968; Tue, 03 Apr 2012 06:52:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 06:52:39 -0700 (PDT) In-Reply-To: <4F7B0033.7060101@alvestrand.no> References: <4F7AF40D.3010706@alvestrand.no> <4F7B0033.7060101@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 15:52:39 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQllfVR5BtvVd28J6gN2obDz4IfWRkZJIwAiGFPRoL+csrRQEjY8lvRYjd0SMnfjlXl4UHXR Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 13:53:05 -0000 2012/4/3 Harald Alvestrand : > Real: 1 year. > > Widely adopted: Just in time to see the PSTN shut down because nobody use= s > it any more :-) Hope you are right :) Anyhow I still want to interoperate with SIP devices, regardless they are not boring PSTN gateways ;) --=20 I=C3=B1aki Baz Castillo From huilan.lu@alcatel-lucent.com Tue Apr 3 07:12: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 B5A7711E80B4 for ; Tue, 3 Apr 2012 07:12:04 -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 NKo36OvonoSr for ; Tue, 3 Apr 2012 07:12:04 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9611E80AF for ; Tue, 3 Apr 2012 07:12:03 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q33EBuP8005026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Apr 2012 09:11:56 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q33EBsvR020367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Apr 2012 09:11:55 -0500 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.136]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 3 Apr 2012 09:11:54 -0500 From: "Lu, Hui-Lan (Huilan)" To: "'Olle E. Johansson'" , Harald Alvestrand Date: Tue, 3 Apr 2012 09:11:53 -0500 Thread-Topic: [rtcweb] Identity and PSTN gateways Thread-Index: Ac0Rmndy6ZpXOf2oTYK4HxbtfSFB0AAB53rg Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4F7AF40D.3010706@alvestrand.no> 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.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 14:12:04 -0000 It seems the same problem exists when a TURN relay is involved in an inter-= browser call. The endpoints cannot verify each other's identity directly. T= hey need to trust the relay to interconnect them and not to do anything evi= l, such as snooping. Huilan > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of > Olle E. Johansson > Sent: Tuesday, April 03, 2012 9:05 AM > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Identity and PSTN gateways >=20 >=20 > 3 apr 2012 kl. 14:58 skrev Harald Alvestrand: >=20 > > One thing that has come up repeatedly in the discussion is the claim th= at > "you can't have a verified identity when you talk to someone via a > telephone gateway" (and therefore here> is not needed / not an added benefit / other claim). > > > > I think this is a fallacy. > > > > Sure, as people have commented numerous times, telephone numbers are > identities; they're being used as such every time someone prints them on = a > business card or a billboard. > > > > When you're connecting via a gateway to the PSTN, the gateway operator > gives you a guarantee that you're being connected to the right person; > that's what gateways are for. > > > > This makes for a fairly simple mapping to the "identity / identity > provider" model we've been bandying about for the "full-blown" IdP / > endpoint case: > > > > The identity is the telephone number. > > The identity provider (one of many possible ones for the number) is the > gateway operator. > > > > Thus - if you call a telephone number via a gateway, you would perform = a > DTLS key exchange with the gateway, and an identity verification exchange > with the gateway operator; you would then guarantee that the gateway > operator vouches for this being a legitimate gateway function that you ca= n > reach for that number. > > > > That's just about the best guarantee you can get when talking to the > telephone system. But if we're using the IdP + DTLS-SRTP version, the > exchange guarantees you that: > > a) nobody is listening in between you and the gateway (even if they > snooped your signalling) > > b) the gateway operator vouches for the gateway being the right gateway > to reach that number > > > > Seems like a little bit better than what you get with SDES. Only a litt= le. >=20 > Now we will have to separate "PSTN-emulating" gateways that accept calls = to > all phone numbers but play a prompt saying "You gotta be kidding me - > calling a phone number?" from REAL gateways that have a connection to the > PSTN world. >=20 > Will guys connecting with SS7 have a certificate signed by the ITU as a > "TRUE" PSTN provider and the voip guy in the basement next door just have= a > "Best effort fourth-tier PSTN service" certificate? >=20 > I think that any identity of any PSTN gateway just identifies the gateway > as a server. Not as a service. >=20 > /O > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Tue Apr 3 07:24: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 3F29911E80C2 for ; Tue, 3 Apr 2012 07:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.023, 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 l38lR4MKvGNB for ; Tue, 3 Apr 2012 07:24:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67711E80C1 for ; Tue, 3 Apr 2012 07:24:11 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2883100vcb.31 for ; Tue, 03 Apr 2012 07:24: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=nueh+cAG4jqju8qWi6CQpO37XGW4RcruQiOmF4yjAT8=; b=G/muUSDfUCoXQG9ze4sKEYGioqenZJJ1DOJHImXJcCAoqSAPyNSLMUqZp3RkyuazNX OTTF66+dz+0idgw+xAxv67FUM/gX4PnUOj2O9nDK68ODm99gZp/1UaSokd6QWng4lh5F Ob9VXkcFgF1fUGUPKG+o8pqC+fLo+bKUHwsMIX2bsrp8U6Wfiwqcfe0TLPrV71NeD6FR 6vITdqVqqmouZu4eTfRnCqm4fB0tOccZQfvCgG2+heLGuLjHzel+Y/SWYSqvshFilFoZ RStzIckYshRf8A5oVt3/WujLkqxn2og3eNt0fqpPRPNQNhXctY5lrJAZfwQcQGnq/8nR GBQw== Received: by 10.52.27.1 with SMTP id p1mr5712226vdg.17.1333463051029; Tue, 03 Apr 2012 07:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 07:23:50 -0700 (PDT) In-Reply-To: <4F7AEDB6.8000907@jesup.org> References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch> <4F7ACC96.90206@alvestrand.no> <4F7AEDB6.8000907@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 16:23:50 +0200 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnv4HVzD1iUtZoWwDkIKboz4QmGOUuDF+EXDBQ2AV/PIN/JqzMub1GqApMv7/Qx5XJXY/v5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Which servers to trust (Re: Consensus call regarding media security) 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 Apr 2012 14:24:12 -0000 2012/4/3 Randell Jesup : > On 4/3/2012 7:55 AM, I=C3=B1aki Baz Castillo wrote: >> If you trust the Web server (i.e. due to HTTPS usage with a valid >> server certificate) then you will also trust that the Web server will >> not signal your WebRTC communication to a malicious destination, am I >> wrong? > > > Partly. =C2=A0First, as you mention, the site can be hacked. If the site is hacked then it does not matter whether SDES or DTLS is being used. Both can be hacked as demostrated in some draft (whose name cannot remember now). > Another issue is that you may NOT trust the website to avoid tapping your= communication The communication is not just the RTP, but also the signaling. If my wife (if I had) realizes that yesterday night I called to my ex-girlfriend, that's important enough for me (regardless my wife does not know what I talked with her). So what? no servers? no proxies? pure P2P for all? Also, as said in other mail (by other person in this maillist), if you don't trust the web server, then we must also drop TURN from WebRTC since TURN URI's are provided by the web server (and it can be hacked and so...). Regards. --=20 I=C3=B1aki Baz Castillo From martin.thomson@gmail.com Tue Apr 3 08:18: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 C7B8F21F8610 for ; Tue, 3 Apr 2012 08:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=-1.750, 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 fzQhAWClH5xb for ; Tue, 3 Apr 2012 08:18:04 -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 CC53D21F8608 for ; Tue, 3 Apr 2012 08:18:03 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3832818bku.31 for ; Tue, 03 Apr 2012 08:18: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=hVfIQTr79p9vN9fsW4FII6H70gdrfulkEeIY4Yll+/s=; b=OxRAl83B+DBNVXInK/amNaDVar9AGnz2OpmW4k7k/sfaX/ueoj+vBhHZYTs3GhISQi OEKK8UE8v6V4sonKU1FaiorJJHKTvCkdzmJ7q3FsYVZhjvzLa/tA7W6HswvqqVz1NjcJ i4BvLo3VWpy6ofoHt8mHkOlvHapIXJx4FRwzM6RJK6JhWTDsVvFDkpqP6XDENyISvyQu fEUn8No/S2NxO7rkjOoX8oBxdJSrL453CLS5DjBRRtY3sWJe/yFxhFmBwi6ZGyvIFH6L TEo/S55j4jBQfx/Y8qio96yHymkBCSc2qhgp0RLLuKCg+fFT5APjHA/r268hYJhLd0K9 zn1A== MIME-Version: 1.0 Received: by 10.204.133.205 with SMTP id g13mr523962bkt.94.1333466282893; Tue, 03 Apr 2012 08:18:02 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Tue, 3 Apr 2012 08:18:02 -0700 (PDT) In-Reply-To: <4F7AF40D.3010706@alvestrand.no> References: <4F7AF40D.3010706@alvestrand.no> Date: Tue, 3 Apr 2012 17:18:02 +0200 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 15:18:04 -0000 On 3 April 2012 14:58, Harald Alvestrand wrote: > The identity is the telephone number. > The identity provider (one of many possible ones for the number) is the > gateway operator. The difference here is that the identity provider is not making an authoritative statement about a namespace that it controls. That means that you need to trust the gateway provider. Third-party, non-authoritative assertions of this sort require an additional layer of trust, which adds to their fragility. When alvestrand.no asserts that harald@alvestrand.no is who he says he is, then we are able to rely on that assertion because we have identified alvestrand.no. By definition, alvestrand.no controls that namespace. We could apply the same policy to a gateway and gain a lower value assertion than the one you seek. That is, +1-234-555-6789@alvestrand.no is a valid identifier within the namespace that alvestrand.no controls, but it is fundamentally different to +1-234-555-6789@gateway.example.com. The only problem is that I don't know how to explain this distinction to my grandmother any more than I could explain that john.smith@example.com and john.smith@example.org are different people. > That's just about the best guarantee you can get when talking to the > telephone system. But if we're using the IdP + DTLS-SRTP version, the > exchange guarantees you that: > a) nobody is listening in between you and the gateway (even if they snooped > your signalling) > b) the gateway operator vouches for the gateway being the right gateway to > reach that number The problem here is that it requires that you trust the gateway provider in order to believe b). > Seems like a little bit better than what you get with SDES. Only a little. If you can get b), then it's arguably better. If not, then you get the same level of assurance, though eavesdropping requires insertion of a media gateway (which is made easier with EKT). --Martin From martin.thomson@gmail.com Tue Apr 3 08:21: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 D187D11E80DF for ; Tue, 3 Apr 2012 08:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.766 X-Spam-Level: X-Spam-Status: No, score=-4.766 tagged_above=-999 required=5 tests=[AWL=-1.167, 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 DRTjgTLllHCy for ; Tue, 3 Apr 2012 08:21:08 -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 AF1F911E80DE for ; Tue, 3 Apr 2012 08:21:07 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3836166bku.31 for ; Tue, 03 Apr 2012 08:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GILjhdmOzvdVdjVXIw0y5nlzKtz+C5SKL0hUXpm4jiE=; b=gaRbZE4yo815Vmx1LYImP0z5BNcj9gYVYt8+uzlQrfi63A7QaeEq5+MWQS3dNLYcBY 9r4bP+UPN9Bbdgg0JW7JdRgB/ixqik37CInrfTOyHVp5bVkwGTsZNG+gA+NAUBYNRldl 4VcNzenUgl2F/D1JNWWwfXvpCfsGaHMXR0Fdqz21CfRIi2NFQvUcy9jOCzRl+R3pnrJ+ wBwhY8UbkOiDeCfUqdZk68Z2qaRqS8d/6THpzUckPnczHa0ieys6kA6RIhjbsut+dzsO lxtDEWBNQROVfeDlmOjUkH6tSTFhdfW0PHOi4a1fddgn+l0/kAZ32vbLszTx6lnyyUG6 1GqQ== MIME-Version: 1.0 Received: by 10.204.154.82 with SMTP id n18mr5563220bkw.85.1333466466542; Tue, 03 Apr 2012 08:21:06 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Tue, 3 Apr 2012 08:21:06 -0700 (PDT) In-Reply-To: <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4F7AF40D.3010706@alvestrand.no> <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> Date: Tue, 3 Apr 2012 17:21:06 +0200 Message-ID: From: Martin Thomson To: "Lu, Hui-Lan (Huilan)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 15:21:09 -0000 On 3 April 2012 16:11, Lu, Hui-Lan (Huilan) wrote: > It seems the same problem exists when a TURN relay is involved in an inter-browser call. The endpoints cannot verify each other's identity directly. They need to trust the relay to interconnect them and not to do anything evil, such as snooping. TURN relays UDP packets. Since DTLS operates at a higher layer, it passes through the relay unmodified. TURN isn't a problem. Sure, the relay can copy packets, but it is no better off than any other on-path attacker. --Martin From pravindran@sonusnet.com Tue Apr 3 08:30: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 2E98921F866A for ; Tue, 3 Apr 2012 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-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 kaiPDhJnWktf for ; Tue, 3 Apr 2012 08:30:36 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 5678421F8665 for ; Tue, 3 Apr 2012 08:30:19 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT3sXirSzSa87R6HXncLPSpZSa+SkdLuG@postini.com; Tue, 03 Apr 2012 08:30:19 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 3 Apr 2012 11:30:41 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 21:00:13 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Harald Alvestrand" Thread-Topic: [rtcweb] Identity and PSTN gateways Thread-Index: AQHNEZmNnPRL9tkinU2DTXVjXBsiv5aIvMSAgAAFW4CAAACLgIAAdAWg Date: Tue, 3 Apr 2012 15:30:38 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E223D5D@inba-mail01.sonusnet.com> References: <4F7AF40D.3010706@alvestrand.no> <4F7B0033.7060101@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 15:30:37 -0000 SW5ha2ksDQoNCkkgcmVtZW1iZXIgdGhhdCB5b3UgaGF2ZSBtZW50aW9uZWQgdGhhdCAiV2ViUlRD IGlzIG5vdCBTSVAiIGFuZCAiSU1ITyB3ZSBzaG91bGQgc3RvcCB0YWxraW5nIGFib3V0IFNJUCBp biB0aGlzIFdHIiBhbmQgeW91ciByZWxhdGVkIG1haWwgdGhyZWFkIGlzIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cwMjc0NC5odG1sLiAgT2Yg Y291cnNlLCBsb3Qgb2YgKzEgZm9yIHlvdXIgbWFpbCA7LSkNCg0KQUZBSUsgaW4gV2ViUlRDLCBT UlRQLURUTFMgbWFrZXMgbW9yZSBzZW5zZS4gIEhhdmluZyBzYWlkIHRoYXQsIHlvdSBjYW4gcHJv dmUgd2ViIGZvbGtzIHRoYXQgU1JUUC1EVExTIGlzIG5vdCBzdWl0YWJsZSBmb3Igd2ViIGFuZCBT REVTIGlzIGJldHRlciA6LSkNCg0KQXBhcnQgZnJvbSB0aGlzLCBJIHdpc2ggc2luZ2xlIHNlY3Vy ZWQgUlRQIGtleS1leGNoYW5nZSBtZWNoYW5pc20gZm9yIFdlYlJUQyBhcyBpdCByZWR1Y2VzIHRo ZSBudW1iZXIgb2YgY29tYmluYXRpb24gaW4gV2ViUlRDIGdhdGV3YXlzIGRlc2lnbiBhcyB3ZWxs Lg0KDQpQYXJ0aGENCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogcnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmDQo+T2YgScOxYWtpIEJheiBDYXN0aWxsbw0KPlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAy MDEyIDc6MjMgUE0NCj5UbzogSGFyYWxkIEFsdmVzdHJhbmQNCj5DYzogcnRjd2ViQGlldGYub3Jn DQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIElkZW50aXR5IGFuZCBQU1ROIGdhdGV3YXlzDQo+DQo+ MjAxMi80LzMgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPjoNCj4+IFJl YWw6IDEgeWVhci4NCj4+DQo+PiBXaWRlbHkgYWRvcHRlZDogSnVzdCBpbiB0aW1lIHRvIHNlZSB0 aGUgUFNUTiBzaHV0IGRvd24gYmVjYXVzZSBub2JvZHkNCj4+IHVzZXMgaXQgYW55IG1vcmUgOi0p DQo+DQo+SG9wZSB5b3UgYXJlIHJpZ2h0IDopDQo+DQo+QW55aG93IEkgc3RpbGwgd2FudCB0byBp bnRlcm9wZXJhdGUgd2l0aCBTSVAgZGV2aWNlcywgcmVnYXJkbGVzcyB0aGV5DQo+YXJlIG5vdCBi b3JpbmcgUFNUTiBnYXRld2F5cyA7KQ0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxp YmNAYWxpYXgubmV0Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+cnRjd2ViIG1haWxpbmcgbGlzdA0KPnJ0Y3dlYkBpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From ibc@aliax.net Tue Apr 3 08:50: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 D5DB911E80ED for ; Tue, 3 Apr 2012 08:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.020, 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 7SFgepApOhCT for ; Tue, 3 Apr 2012 08:50:39 -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 DB71E11E80AE for ; Tue, 3 Apr 2012 08:50:38 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2945017vbb.31 for ; Tue, 03 Apr 2012 08:50: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Hk6aumDHkxr32xyyP70sS1MWULa025d/52rIm7UXJ9Y=; b=YGNtQaRiIXmI48r7rr3D58ejw1zXwA+vkr4E38kK2Uk+0M1dcQc+qPhDTdp8jVRFk/ +77faNTRQgImBFYB5hR/HsBxGqQuOshCVip5qrqqK7K9uB2GryjMms4PdmLtHkvC74lP hAEnlIExSRfG9gcHPNSq1LH9dzkb6b6/R1Kc3nJFPTvIv/7Q5hicXtjy25wz0oNJQf9w yOeyx+NlN0jhfABTECJ6m6d/FDWPoypk9UjLanmPoobgPO7Biby6Nmkz0T/AinUZMpZD jMz1D4CodrhQ6X8JWKPLsPVOdg6ofKO0DnsxILNuRUmHDr+3H7h/koOVM7ZHa5RuMgTz 8RpA== Received: by 10.52.88.4 with SMTP id bc4mr5681103vdb.51.1333468238358; Tue, 03 Apr 2012 08:50:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 08:50:18 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E223D5D@inba-mail01.sonusnet.com> References: <4F7AF40D.3010706@alvestrand.no> <4F7B0033.7060101@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0E223D5D@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 17:50:18 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl7hiTn0FuMwIgmEcYr4i7NwM53iWJr/ywYyIQVf3tmpKG+Suq3jIHzRBgcao4kYQrrWXwf Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 15:50:39 -0000 2012/4/3 Ravindran, Parthasarathi : > Inaki, > > I remember that you have mentioned that "WebRTC is not SIP" and "IMHO we = should stop talking about SIP in this WG" and your related mail thread is h= ttp://www.ietf.org/mail-archive/web/rtcweb/current/msg02744.html. =C2=A0Of = course, lot of +1 for your mail ;-) Sure I remember :) And I still say the same, sure. Security is a need for WebRTC and interop with SIP should not make it worse. But IMHO SDES-SRTP (with the adition of secure signaling HTTPS/WSS) is a good solution, the very same for ICE which is ***poorly*** implemented in SIP world. Of course interoperability between WebRTC and SIP is a good point, and that's a good reason to allow SDES-SRTP. > AFAIK in WebRTC, SRTP-DTLS makes more sense. =C2=A0Having said that, you = can prove web folks that SRTP-DTLS is not suitable for web and SDES is bett= er :-) I don't say that SRTP-DTLS is bad, not at all. I agree that it MUST be the preferred option for a WebRTC communication. > Apart from this, I wish single secured RTP key-exchange mechanism for Web= RTC as it reduces the number of combination in WebRTC gateways design as we= ll. You probably would be happy building the Super-SIP-Media-B2BUA-DTLS-EKT-SDES-ICE-Capable-WebRTC-Gateway, but not me ;) Regards. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Tue Apr 3 08: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 867F511E80F9 for ; Tue, 3 Apr 2012 08:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.102, 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 L4wut7pJm9O4 for ; Tue, 3 Apr 2012 08:51:17 -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 EA74C11E80EF for ; Tue, 3 Apr 2012 08:51:16 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so29988pbb.31 for ; Tue, 03 Apr 2012 08:51:16 -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=9aZee0qP0/41gTfRugzTZAydR3Ha1c3Zv4ynRMlG8/A=; b=pFfdi8aHj6sRBWHMKG0HvsVDTWH34DlT6hO5NNdkRKJgvuxUbqJJOOwkx/PUUL23IQ gav3QG8B902GIxYVHqYndAE+Cnl3tm7OaFqoP43FAOIJbEwAv4Ohs+Flc/a6jDAqFUi8 BJOpn1KPsgJXhw00od1BvS69lSqI0QUrNQiVk3dqqHDlFrmGFKo5Yjq565Z7GLyt3iU5 PXXvAAM8PfrIxv5NyOOY8XH4TBnpfYUNnyke4zY20Mmtj18Q/KfkiiJryVvFdIZxUUjg +2UMt5UYLQvU/3nLRBclXszauafcLMkf+WMf/Unl/CaH1XHJJ5gI+JfmiRL402yblqKx S1/g== Received: by 10.68.197.194 with SMTP id iw2mr30174722pbc.26.1333468276723; Tue, 03 Apr 2012 08:51:16 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id d3sm10280569pbq.9.2012.04.03.08.51.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 08:51:14 -0700 (PDT) Received: by dady13 with SMTP id y13so5025390dad.27 for ; Tue, 03 Apr 2012 08:51:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.69 with SMTP id gw5mr29962105pbc.141.1333468273757; Tue, 03 Apr 2012 08:51:13 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 3 Apr 2012 08:51:13 -0700 (PDT) In-Reply-To: References: <4F7AF40D.3010706@alvestrand.no> Date: Tue, 3 Apr 2012 11:51:13 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=e89a8fb208dcc6ce7004bcc84696 X-Gm-Message-State: ALoCoQkF4ZA4ak6dTSJGmtelyNqxzB93AZcan9ekyjaxT+F5/O9aMqsWlHlBLOdNiaRFdoHOtyX/ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 15:51:17 -0000 --e89a8fb208dcc6ce7004bcc84696 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 3, 2012 at 9:05 AM, Olle E. Johansson wrote: > > Now we will have to separate "PSTN-emulating" gateways that accept calls > to all phone numbers but play a prompt saying "You gotta be kidding me - > calling a phone number?" from REAL gateways that have a connection to the > PSTN world. > > Will guys connecting with SS7 have a certificate signed by the ITU as a > "TRUE" PSTN provider and the voip guy in the basement next door just have a > "Best effort fourth-tier PSTN service" certificate? > > I think that any identity of any PSTN gateway just identifies the gateway > as a server. Not as a service. > > I agree with you that you can only identify the gateway. Above this, I think the whole discussion is pointless since there are no security guarantees within PSTN. A million of people can be listening in. You can be connected to a completely different number then the one you've dialed due to LNP, call routing rules, call forwarding, or anything else. If you are dialing internationally your traffic often goes over unsecured public internet. So far, 99.999% of all phone calls were unsecured, tapped into, recorded and listen by anybody who possessed even the moderate desire to do so. If you start talking about calls coming from PSTN, you have even less guarantees about accuracy of the caller ID information. You are currently trying to secure the edge and provide identity on top of this mess. _____________ Roman Shpount --e89a8fb208dcc6ce7004bcc84696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2012 at 9:05 AM= , Olle E. Johansson <oej@edvina.net> wrote:

Now we will have to separate "PSTN-emulating" gateways that accep= t calls to all phone numbers but play a prompt saying "You gotta be ki= dding me - calling a phone number?" from REAL gateways that have a con= nection to the PSTN world.

Will guys connecting with SS7 have a certificate signed by the ITU as a &qu= ot;TRUE" PSTN provider and the voip guy in the basement next door just= have a "Best effort fourth-tier PSTN service" certificate?

I think that any identity of any PSTN gateway just identifies the gateway a= s a server. Not as a service.

I agree with you that = you can only identify the gateway. Above this, I think the whole discussion= is pointless since there are no security guarantees within PSTN. A million= of people can be listening in. You can be connected to a completely differ= ent number then the one you've dialed due to LNP, call routing rules, c= all forwarding, or anything else. If you are dialing internationally your t= raffic often goes over unsecured public internet. So far, 99.999% of all ph= one calls were unsecured, tapped into, recorded and listen by anybody who p= ossessed even the moderate desire to do so. If you start talking about call= s coming from PSTN, you have even less guarantees about accuracy of the cal= ler ID information. You are currently trying to secure the edge and provide= identity on top of this mess.
_____________
Roman Shpount
--e89a8fb208dcc6ce7004bcc84696-- From ibc@aliax.net Tue Apr 3 08:54: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 6FCC311E80FF for ; Tue, 3 Apr 2012 08:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, 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 jiUAt4RktRqo for ; Tue, 3 Apr 2012 08:54:09 -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 41AFB11E80F0 for ; Tue, 3 Apr 2012 08:54:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2948070vbb.31 for ; Tue, 03 Apr 2012 08:54: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=VeawQwRYP/pezd7FxZtaTCml46o0VNC7VcleV3CuKxc=; b=mSoQXalRA0fop6TQH9Qj3ncqc21jsG7W1SzGikDqulrbNZin9/WTqYSjS6AgKpqso3 1JFLA/5O48omMxfXRESTA5DuWN9nygz5JdL5J7cLBLYQtCHhQl/jZHyv7AjbPqMzORY4 tAxPizNujzZ8xF1oYdevDsTUwi/WY+ov9SDVaqVgHOS6izPa7E5EOZaBvXYJO3aiJlVn hXoXS0A6disvInkwmLV6I6Gkj/rR6P3LmyRG3NYsHrsIrfJquz+xZXYziiniAHZ2nYiv bQ8JyQEZHGb5Y7QacqzT/ClDPT/ad0O1Q4aXVgDvKGB0vzGqnTJnkURICCQdn80z+lBX 9r8g== Received: by 10.52.15.233 with SMTP id a9mr5737732vdd.34.1333468447764; Tue, 03 Apr 2012 08:54:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 08:53:47 -0700 (PDT) In-Reply-To: References: <4F7AF40D.3010706@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 17:53:47 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl74WVqMeKglbfAhhgEtu4qbASdUN5Le020Zf2KBaCj9w1ggd5JGwFpunTcomT2Z3YY8Nn2 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 15:54:09 -0000 2012/4/3 Roman Shpount : > On Tue, Apr 3, 2012 at 9:05 AM, Olle E. Johansson wrote: >> >> >> Now we will have to separate "PSTN-emulating" gateways that accept calls >> to all phone numbers but play a prompt saying "You gotta be kidding me - >> calling a phone number?" from REAL gateways that have a connection to th= e >> PSTN world. >> >> Will guys connecting with SS7 have a certificate signed by the ITU as a >> "TRUE" PSTN provider and the voip guy in the basement next door just hav= e a >> "Best effort fourth-tier PSTN service" certificate? >> >> I think that any identity of any PSTN gateway just identifies the gatewa= y >> as a server. Not as a service. >> > I agree with you that you can only identify the gateway. Above this, I th= ink > the whole discussion is pointless since there are no security guarantees > within PSTN. A million of people can be listening in. You can be connecte= d > to a completely different number then the one you've dialed due to LNP, c= all > routing rules, call forwarding, or anything else. If you are dialing > internationally your traffic often goes over unsecured public internet. S= o > far, 99.999% of all phone calls were unsecured, tapped into, recorded and > listen by anybody who possessed even the moderate desire to do so. If you > start talking about calls coming from PSTN, you have even less guarantees > about accuracy of the caller ID information. You are currently trying to > secure the edge and provide identity on top of this mess. I don't understand why we are trying to resolve eternal PSTN problems in rt= cweb. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Tue Apr 3 08:58: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 E2FF211E8118 for ; Tue, 3 Apr 2012 08:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 b9Q52AVOi4gf for ; Tue, 3 Apr 2012 08:58:16 -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 652B911E8116 for ; Tue, 3 Apr 2012 08:58:16 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so35776pbb.31 for ; Tue, 03 Apr 2012 08:58:16 -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=9+tIGwFd+hvtuDvlgefEwFi+WnC+MLBJamewEsZEsrU=; b=igSsbN6shVttY5gtUhYa9uj77F64awPg9/Mk3atUB0uZ5HXjT2Cz8zPK+R3QoqGX1u YIjAzWD9khj61Gu2KtNNSff2im1TLmPPSl3Z7rVemiafPlLhVSnLPzgCtonTJxFpTi+6 yl/evurAUnpDdO4GrzGziFbmKqbqTE0KA6JJTJL6LCBStAJ+axFnz2jyqshu4IvG7/h1 c684sqC861Alal9yGypswJr5Kkc/kmrfrSn87SIS/zpclhhNa8FSjA42pyEUTV4rQ1l6 2vYuDmP6uf33nrWQ34hNxL6skVrNGT/aCOQ9686xKQC5FhamNvptfYf6JSlMbpewj3Ep K1Pg== Received: by 10.68.195.38 with SMTP id ib6mr29990526pbc.28.1333468696166; Tue, 03 Apr 2012 08:58:16 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id vz18sm13565921pbb.44.2012.04.03.08.58.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 08:58:15 -0700 (PDT) Received: by dady13 with SMTP id y13so5034691dad.27 for ; Tue, 03 Apr 2012 08:58:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.237.1 with SMTP id uy1mr29827209pbc.99.1333468694507; Tue, 03 Apr 2012 08:58:14 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 3 Apr 2012 08:58:14 -0700 (PDT) In-Reply-To: References: <4F7AF40D.3010706@alvestrand.no> <4F7B0033.7060101@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0E223D5D@inba-mail01.sonusnet.com> Date: Tue, 3 Apr 2012 11:58:14 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b33cb6cdaf23c04bcc85f60 X-Gm-Message-State: ALoCoQle3vnKf6uqfLmYEF3CZ1mUDVvtHewI0NFBoq3T0k6FhK3+h+cI7KyYyivio43RtZFhgj75 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 15:58:17 -0000 --047d7b33cb6cdaf23c04bcc85f60 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2012 at 11:50 AM, I=F1aki Baz Castillo wrote= : > I don't say that SRTP-DTLS is bad, not at all. I agree that it MUST be > the preferred option for a WebRTC communication. > I actually would say that SRTP-DTLS is bad. It adds latency to call setup, provides a bunch of features nobody needs, and does not map to SDES-SRTP without re-encrypting the traffic. It has no deployed base and makes interop a lot harder. Unfortunately this is the ony thing that provides anything even remotely qualifying as secure communications right now. I would prefer to see a new key exchange protocol designed instead of DTLS-SRTP. I know that there is effort to patch DTLS-SRTP to fix call setup delays, but all those patches will only make interop harder, since they increase the number of necessary tests. _____________ Roman Shpount --047d7b33cb6cdaf23c04bcc85f60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2012 at 11:50 A= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
I don't say that SRTP-DTLS is bad, not at all. I agree that it MUST be<= br> the preferred option for a WebRTC communication.

= I actually would say that SRTP-DTLS is bad. It adds latency to call setup, = provides a bunch of features nobody needs, and does not map to SDES-SRTP wi= thout re-encrypting the traffic. It has no deployed base and makes interop = a lot harder. Unfortunately this is the ony thing that provides anything ev= en remotely qualifying as secure communications right now. I would prefer t= o see a new key exchange protocol designed instead of DTLS-SRTP. I know tha= t there is effort to patch DTLS-SRTP to fix call setup delays, but all thos= e patches will only make interop harder, since they increase the number of = necessary tests.
_____________
Roman Shpount

--047d7b33cb6cdaf23c04bcc85f60-- From roman@telurix.com Tue Apr 3 09:01: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 53BA711E8108 for ; Tue, 3 Apr 2012 09:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 GgVdj33QeSKB for ; Tue, 3 Apr 2012 09:01:37 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BC55E21F84CD for ; Tue, 3 Apr 2012 09:01:37 -0700 (PDT) Received: by dady13 with SMTP id y13so5039247dad.27 for ; Tue, 03 Apr 2012 09:01: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VQCJqSh40gbfixMs+VEebgGzjWyfmUorNUyK9QlWWbU=; b=YF4Ijqf4Eq44TSpS7mmdo+ruqruIoVuwC+GN+qcgtAYyY0wx/WvedOS6kN2WfRAX5x lv07VLbS4+H4p+I9sjFYIelOBPQJtS0ysNcmHs6MR5zW6ADgRHa0EaUyO91rujMqyu9n PO8A942lMluMPNpgGIA4Oi4s5fwPgBFcgNzCgn2r0VHb4CIV5xog2JTY0BRY2+hrQQ9e UTzrgYfI7tluFgJ6CljK5R1WquSSEO1IZ/ejm9u0cr7LltliIuZVuQlhWEHuzC+Oib2k gqeWIeoYFkw57fkCmv+lfZXB5e6fJcs/bMZMsJpUya4SSe7cICXdv96BNdzZszniIXYW VKfA== Received: by 10.68.136.69 with SMTP id py5mr29573501pbb.71.1333468897598; Tue, 03 Apr 2012 09:01:37 -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 b7sm16589346pba.2.2012.04.03.09.01.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 09:01:36 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so38781pbb.31 for ; Tue, 03 Apr 2012 09:01:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.200.225 with SMTP id jv1mr17844327pbc.120.1333468895099; Tue, 03 Apr 2012 09:01:35 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 3 Apr 2012 09:01:35 -0700 (PDT) In-Reply-To: References: <4F7AF40D.3010706@alvestrand.no> Date: Tue, 3 Apr 2012 12:01:35 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b15ac43cfba8304bcc86b89 X-Gm-Message-State: ALoCoQnVdJlaPoXgcoxwWfuTY4hKYpupuHzMu1LcJXzCOHCLBfGXuv/JE5WugkvnTWPa+NZMuh8A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 16:01:38 -0000 --047d7b15ac43cfba8304bcc86b89 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2012 at 11:53 AM, I=F1aki Baz Castillo wrote= : > 2012/4/3 Roman Shpount : > > I agree with you that you can only identify the gateway. Above this, I > think > > the whole discussion is pointless since there are no security guarantee= s > > within PSTN. A million of people can be listening in. You can be > connected > > to a completely different number then the one you've dialed due to LNP, > call > > routing rules, call forwarding, or anything else. If you are dialing > > internationally your traffic often goes over unsecured public internet. > So > > far, 99.999% of all phone calls were unsecured, tapped into, recorded a= nd > > listen by anybody who possessed even the moderate desire to do so. If y= ou > > start talking about calls coming from PSTN, you have even less guarante= es > > about accuracy of the caller ID information. You are currently trying t= o > > secure the edge and provide identity on top of this mess. > > > I don't understand why we are trying to resolve eternal PSTN problems in > rtcweb. > > I do not, even though you repeatedly say that you want to fix the Interne= t via WebRTC. All I am saying that the PSTN gateway cannot provide identity on behalf of the phone number. PSTN phone number is not an identity and we should never display something that says "You have a secure communication with +1800YOURBANK". You can only say "You have a secure communication with ACME Telecom Phone Gateway" _____________ Roman Shpount --047d7b15ac43cfba8304bcc86b89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2012 at 11:53 A= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/4/3 Roman Shpount <roman@telur= ix.com>:
> I agree with you that you can only i= dentify the gateway. Above this, I think
> the whole discussion is pointless since there are no security guarante= es
> within PSTN. A million of people can be listening in. You can be conne= cted
> to a completely different number then the one you've dialed due to= LNP, call
> routing rules, call forwarding, or anything else. If you are dialing > internationally your traffic often goes over unsecured public internet= . So
> far, 99.999% of all phone calls were unsecured, tapped into, recorded = and
> listen by anybody who possessed even the moderate desire to do so. If = you
> start talking about calls coming from PSTN, you have even less guarant= ees
> about accuracy of the caller ID information. You are currently trying = to
> secure the edge and provide identity on top of this mess.


I don't understand why we are trying to resolve eternal PST= N problems in rtcweb.

I do no= t, even though you repeatedly say that you want to fix the Internet via Web= RTC. All I am saying that the PSTN gateway cannot provide identity on behal= f of the phone number. PSTN phone number is not an identity and we should n= ever display something that says "You have a secure communication with= +1800YOURBANK". You can only say "You have a secure communicatio= n with ACME Telecom Phone Gateway"
_____________
Roman Shpount
=A0
--047d7b15ac43cfba8304bcc86b89-- From oej@edvina.net Tue Apr 3 09:25: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 C092E11E8157 for ; Tue, 3 Apr 2012 09:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 qjjDMzyt-vi0 for ; Tue, 3 Apr 2012 09:25:51 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 17B1A11E8152 for ; Tue, 3 Apr 2012 09:25:50 -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 5B10B754A8A2; Tue, 3 Apr 2012 16:25:47 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Tue, 3 Apr 2012 18:25:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36657126-D663-409A-9D34-D3AF70ED2CD7@edvina.net> References: <4F7AF40D.3010706@alvestrand.no> To: Roman Shpount X-Mailer: Apple Mail (2.1257) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 16:25:51 -0000 3 apr 2012 kl. 18:01 skrev Roman Shpount: >=20 > On Tue, Apr 3, 2012 at 11:53 AM, I=F1aki Baz Castillo = wrote: > 2012/4/3 Roman Shpount : > > I agree with you that you can only identify the gateway. Above this, = I think > > the whole discussion is pointless since there are no security = guarantees > > within PSTN. A million of people can be listening in. You can be = connected > > to a completely different number then the one you've dialed due to = LNP, call > > routing rules, call forwarding, or anything else. If you are dialing > > internationally your traffic often goes over unsecured public = internet. So > > far, 99.999% of all phone calls were unsecured, tapped into, = recorded and > > listen by anybody who possessed even the moderate desire to do so. = If you > > start talking about calls coming from PSTN, you have even less = guarantees > > about accuracy of the caller ID information. You are currently = trying to > > secure the edge and provide identity on top of this mess. >=20 >=20 > I don't understand why we are trying to resolve eternal PSTN problems = in rtcweb. >=20 > I do not, even though you repeatedly say that you want to fix the = Internet via WebRTC. All I am saying that the PSTN gateway cannot = provide identity on behalf of the phone number. PSTN phone number is not = an identity and we should never display something that says "You have a = secure communication with +1800YOURBANK". You can only say "You have a = secure communication with ACME Telecom Phone Gateway"=20 Exactly. Thanks. /O From ibc@aliax.net Tue Apr 3 10:00: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 C519B21F86EA for ; Tue, 3 Apr 2012 10:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, 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 YxG8yl0DhGuJ for ; Tue, 3 Apr 2012 10:00:11 -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 3634921F86E4 for ; Tue, 3 Apr 2012 10:00:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3000972vbb.31 for ; Tue, 03 Apr 2012 10:00:10 -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=UvAaxvuVEXOwRnPF53uIIl7ir/ha9N7ywSb5M2gQo3E=; b=Z4dfgyZNMuelBmCa18Ub+f/GcjZzps703RfmJ5BEovuUzyvAp1RuxWigP70bD7vf4f 0vMQaO6WGeLdzSxz/amIdhpYc/jnJbGhGv1rGg3sjlLb2zcb6ra1sNDsJT0lwRggBnlt jiiNL6VkQ57DgwMiGZzDwvzYScsjpTWBQlKULGywzxvFj1LexBunhCOFobdDJvc04251 JvrP3KsfOjNbeDLXs8d23cIXqcvV/KTwhjzXy06uz8H/7n9CcebGF7TtsLfWX3b287QN IB3G+OOAY5Z49pflELhTPW8rEaw/3y8LbQvPzWJoZW7e5+fpWb56pT2Dfnunp6hnYZK+ 96dg== Received: by 10.52.27.1 with SMTP id p1mr5947547vdg.17.1333472410699; Tue, 03 Apr 2012 10:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 09:59:49 -0700 (PDT) In-Reply-To: References: <4F7AF40D.3010706@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 18:59:49 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmcpWwUAfp/lHQ2ZneoxkEr9jADHT0te94nWZitdNyMYPQG0STx+XTGQZqtKz2qxvvf7Xk/ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 17:00:11 -0000 2012/4/3 Roman Shpount : > On Tue, Apr 3, 2012 at 11:53 AM, I=C3=B1aki Baz Castillo = wrote: >> I don't understand why we are trying to resolve eternal PSTN problems in >> rtcweb. >> > I do not, even though you repeatedly say that you want to fix the Interne= t > via WebRTC. Disallowing plain and hyper-unsecure RTP is not fixing Internet, IMHO ;) > All I am saying that the PSTN gateway cannot provide identity on > behalf of the phone number. PSTN phone number is not an identity and we > should never display something that says "You have a secure communication > with +1800YOURBANK". You can only say "You have a secure communication wi= th > ACME Telecom Phone Gateway" And for sure you are 100% right. PSTN is insecure by nature (signed: a telco worker). --=20 I=C3=B1aki Baz Castillo From igor.faynberg@alcatel-lucent.com Tue Apr 3 10:12: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 A5F5321F856C for ; Tue, 3 Apr 2012 10:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Ami3EUD0kPMd for ; Tue, 3 Apr 2012 10:12:08 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B55F321F87A8 for ; Tue, 3 Apr 2012 10:12:08 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q33HC7MZ000585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Apr 2012 12:12: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 q33HC6Oj000323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Apr 2012 12:12:07 -0500 Received: from [135.244.35.225] (faynberg.lra.lucent.com [135.244.35.225]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q33HC65E024073; Tue, 3 Apr 2012 12:12:06 -0500 (CDT) Message-ID: <4F7B2F66.1050700@alcatel-lucent.com> Date: Tue, 03 Apr 2012 13:12: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: <4F7AF40D.3010706@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Identity and PSTN gateways 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, 03 Apr 2012 17:12:09 -0000 I cannot quite agree with Iñaki, although I do need to qualify this. (Maybe we don't disagree after all.) POTS has been as secure as anything could be (short of attacks involving splicing the twisted pair or cable), but all kinds of games played with gateways have made it vulnerable as far as caller identification is concerned. But here--at least in the US--there are strong regulations that protect the POTS end-points (i.e., consumers). The major point though is that wireless networking has been sufficiently secure in 3G and 4G. To this end, a mobile phone with the SIM application is a strong authentication device, and there are many interesting way to bootstrap this into IdP services. We had a very interesting discussion during the BrowserID session, which came I think very closely to this point. Igor On 4/3/2012 12:59 PM, Iñaki Baz Castillo wrote: > ... > And for sure you are 100% right. PSTN is insecure by nature (signed: a > telco worker). > > > From sergel@google.com Tue Apr 3 10:55: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 93D3621F85FD for ; Tue, 3 Apr 2012 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.776 X-Spam-Level: X-Spam-Status: No, score=-99.776 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 iWzrsZMVlnvl for ; Tue, 3 Apr 2012 10:55:27 -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 7210221F85B7 for ; Tue, 3 Apr 2012 10:55:27 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3947228obb.31 for ; Tue, 03 Apr 2012 10:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=L15NJnUpbK6x2Kt3M7dkColgVJEBYofSM1E5wON8SIY=; b=RnX04NMVLm+aNMEbAhgMUNhmBhzG9ESsG5emqQPSSKZkvtsZ9x2Kk8RwF632aLrzc9 6/HUoIEemRjrLy6fSQ5lFwEjmtumO9e5e7kCLQ2sjfv6Gkv3zGT/v8z2vdJ/OpI2P/6f theDntkN3FelDmIEnTr5Jb1fqnpfT1S5PY97whxEiJopwaE2KXcwkCulfYa4D63cSfJ9 tRq5EQj64EUfIo6ahQaIkfSgf/IOrDODOrgnr3W4Y3DslpYQPDjg43Vh1ehCDqlc3iYQ rZVzJgvxeA8LTquNBBv1m+eRhkIAqaZPC7IKMcZ0Ph9Mq93XHuqaXq+HGd2wboJgcq5L MRtg== 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 :x-system-of-record:x-gm-message-state; bh=L15NJnUpbK6x2Kt3M7dkColgVJEBYofSM1E5wON8SIY=; b=geHaRsXDBn9LOBurs8puvAW/fRHNCnx5bOTZM9Yq4rBmIxx9qsgWmxTaMkk8h9WLy9 9DrpFGlDIR0bFcxwrl503Z8TIoYyknoOsFXbpTMz0DdiAhFexLSAXSRlVFVJmBbJ7oV7 mm9vnOlU7KJEHkCb/1mSCODNDXnwwZ6Ij9tK+3BNDJyigBUH5LpDDNcPSnaZNetncfaR SbS6mnvZ/0yX9QJ2BAlzltEzD9bETQK+3dsRfzz71I5G1WMeqOgW22I2q4I3+X8vGPWE QaTWIyUIftR8rl/5sz8sOZoX/aOVsVLzXZ1kKi/uv+tyxE3+VZEGaelXqpceO3YXdHVS rR0Q== Received: by 10.60.36.100 with SMTP id p4mr20091322oej.42.1333475726840; Tue, 03 Apr 2012 10:55:26 -0700 (PDT) Received: by 10.60.36.100 with SMTP id p4mr20091308oej.42.1333475726711; Tue, 03 Apr 2012 10:55:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.27.97 with HTTP; Tue, 3 Apr 2012 10:54:56 -0700 (PDT) From: Serge Lachapelle Date: Tue, 3 Apr 2012 19:54:56 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=14dae9c09bc201ddde04bcca0336 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlfV5ledC25HiCA3IP/hfEBLk/AVpuOwrRwN6WS2otFqZ7Em5SbtmgikZh0InUy1i0l2lLMbP3vnuLzc1J5grtqIioJsfcT03e1DTAbRk8e2O+zgdRK9Jbx4ljUHXq4Hbx/Wyyo Subject: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Tue, 03 Apr 2012 17:55:28 -0000 --14dae9c09bc201ddde04bcca0336 Content-Type: text/plain; charset=ISO-8859-1 *[Forking the thread]* * * *Hello folks,* Google confirms that the VP8 patent grant applies to both third-party hardware and software implementations of VP8. * * *Google encourages the community to create hardware implementations of VP8, and has recently blogged about a number of new hardware implementations on the WebM blog ( http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware.html). * * * *Google is quite proud of what the community has done with VP8 and looks forward to seeing more implementations of VP8 in both hardware and software. * * * *Regards,* * * */Serge Lachapelle, Google, Stockholm* On Thu, Mar 29, 2012 at 16:53, Stephan Wenger wrote: > > > On 3.29.2012 16:24 , "Basil Mohamed Gohar" > wrote: > > >On 03/29/2012 10:20 AM, Stephan Wenger wrote: > >> The second part of your sentence may or may not be true, depending on > >>your > >> relationship with google, your willingness to use the webm > >>implementation > >> in unchanged form, and other factors. Please see the webm license > >> conditions, which AFAIK can be found here: > >> http://www.webmproject.org/license/additional/ > >Correct. I think you are referring to this part, explicitly: > >> If you or your agent or exclusive licensee institute or order or agree > >> to the institution of patent litigation against any entity (including > >> a cross-claim or counterclaim in a lawsuit) alleging that this > >> implementation of VP8 or any code incorporated within this > >> implementation of VP8 constitutes direct or contributory patent > >> infringement, or inducement of patent infringement, then any patent > >> rights granted to you under this License for this implementation of > >> VP8 shall terminate as of the date such litigation is filed. > >Perhaps I assumed that that is a very reasonable part of the license. > >That is, if you are suing someone alleging a patent infringement within > >VP8, you are no longer granted the license to use VP8's patented > >technologies that Google owns. > > Yes, that's one issue. Call it personal preference for different type of > reciprocity conditions :-) (I could rant about it for hours, but let's > continue to pretend that this is mostly a technical mailing list) > > The other issue, though (the fact that the license grant extends only to > the VP8 implementation as provided by google, and does not extent to > derivative works such as hardware implementations) should be moderately > alarming even for an open source person. With respect to this clause, I > will note that I criticized the licensing conditions in private and in > public (IETF mike) several times, months ago, and nothing happened. > Suggests to me one of three things: (1) google is a large company and > decisions take time, or (2) google's legal is currently occupied with > other stuff, or (3) that the choice of language is intentional, and > intended to prevent forks. Take your pick. > Stephan > > >_______________________________________________ > >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 > 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. > -- Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32 -- 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. --14dae9c09bc201ddde04bcca0336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[Forking the thread]

Hello folks,

Google confirms that the VP8 patent g= rant applies to both third-party hardware and software implementations of V= P8.=A0

Google encourages the = community to create hardware implementations of VP8, and has recently blogg= ed about a number of new hardware implementations on the WebM blog ( http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware= .html ).=A0

Google is quite proud = of what the community has done with VP8 and looks forward to seeing more im= plementations of VP8 in both hardware and software.=A0

Regards,

/Serge Lachapelle, Google, Stockholm

On Thu, Mar 29, 2012 at 16:53, Stephan Wenger <<= a href=3D"mailto:stewe@stewe.org" target=3D"_blank">stewe@stewe.org>= wrote:


On 3.29.2012 16:24 , "Basil Mohamed Gohar" <basilgohar@librevideo.org&= gt;
wrote:

>On 03/29/2012 10:20 AM, Stephan Wenger wrote:
>> The second part of your sentence may or may not be true, depending= on
>>your
>> relationship with google, your willingness to use the webm
>>implementation
>> in unchanged form, and other factors. =A0Please see the webm licen= se
>> conditions, which AFAIK can be found here:
>> http://www.webmproject.org/license/additional/
>Correct. =A0I think you are referring to this part, explicitly:
>> If you or your agent or exclusive licensee institute or order or a= gree
>> to the institution of patent litigation against any entity (includ= ing
>> a cross-claim or counterclaim in a lawsuit) alleging that this
>> implementation of VP8 or any code incorporated within this
>> implementation of VP8 constitutes direct or contributory patent >> infringement, or inducement of patent infringement, then any paten= t
>> rights granted to you under this License for this implementation o= f
>> VP8 shall terminate as of the date such litigation is filed.
>Perhaps I assumed that that is a very reasonable part of the license. >That is, if you are suing someone alleging a patent infringement within=
>VP8, you are no longer granted the license to use VP8's patented >technologies that Google owns.

Yes, that's one issue. =A0Call it personal preference for d= ifferent type of
reciprocity conditions :-) =A0(I could rant about it for hours, but let'= ;s
continue to pretend that this is mostly a technical mailing list)

The other issue, though (the fact that the license grant extends only to the VP8 implementation as provided by google, and does not extent to
derivative works such as hardware implementations) should be moderately
alarming even for an open source person. =A0With respect to this clause, I<= br> will note that I criticized the licensing conditions in private and in
public (IETF mike) several times, months ago, and nothing happened.
Suggests to me one of three things: (1) google is a large company and
decisions take time, or (2) google's legal is currently occupied with other stuff, or (3) that the choice of language is intentional, and
intended to prevent forks. =A0Take your pick.
Stephan

>_______________________________________________
>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
Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | O= rg. nr. 556656-6880=A0

Apparently, this footer is required = in Europe. Apologies. This email may be confidential or privileged. =A0If y= ou received this communication by mistake, please don't forward it to a= nyone else,please erase all copies and attachments, and please let me know = that it went to the wrong person. =A0Thanks.


--
Serge Lachapelle=A0|=A0Product Ma= nager=A0|=A0sergel@goog= le.com=A0|=A0+46 732 01 22 32


--
Serge Lachape= lle=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.
--14dae9c09bc201ddde04bcca0336-- From lists@infosecurity.ch Tue Apr 3 11:00: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 0E09311E809F for ; Tue, 3 Apr 2012 11:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 OUhElBeL-+lC for ; Tue, 3 Apr 2012 11:00:43 -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 D628811E809D for ; Tue, 3 Apr 2012 11:00:42 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2720375wgb.13 for ; Tue, 03 Apr 2012 11:00:42 -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 :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=uyqZTPRuu4VgmPh1rT0CsBhcsd7IQrj+EN3HhrFeOWw=; b=J/dhwGegE7Xwh9BqGwbinTK8baosZ6zIgeUMHvUsicR7LYTW8TrpMKe8ofP8CylRgx K2CM0g9BMkoogzAsU+qcXVcXrRq7qGsMs2w+qA+WsHES5X+VHn4Z1uBSjW9ibopBIM1C pYpK8lPIJNVhTXoIXkiky5oPmBNxcTHMwMbPsYg2VVvsHQwppeVFcRL32DbHt6LtUDKK FGV42LYN8LSfu9VCgr2V7jX8+vFzz1NKX+U/Grn4uGUCR8enbLPJ9RcHaw1jP7cwk9qz AHwXipMI5QNimeLn3gb/rdkyuG/vL2Bk7i4/vXGJCFMccHu8EptO47KfHHdPZpc1iDGy RnJw== Received: by 10.180.84.164 with SMTP id a4mr38615303wiz.2.1333476042046; Tue, 03 Apr 2012 11:00:42 -0700 (PDT) Received: from sonyvaiop13.local (host146-199-static.115-2-b.business.telecomitalia.it. [2.115.199.146]) by mx.google.com with ESMTPS id n20sm72198124wiw.5.2012.04.03.11.00.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 11:00:38 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7B3AC1.8080804@infosecurity.ch> Date: Tue, 03 Apr 2012 20:00:33 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmF27GcI6lcOPYvvIo8YGMAMLFq8XsqHRtIzA1UsUkp65zLvNzHoXOOZje48TUeN8ZzxNVP Subject: [rtcweb] On DTLS-SRTP trust model (and consideration for SDES-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: Tue, 03 Apr 2012 18:00:44 -0000 >From trust model SDES-SRTP it's very similar with DTLS-SRTP with the regards to the need to trust third party with no real end-to-end authentication/encryption support. Let me explain this assumption: - DTLS-SRTP key exchange without fingerprint/identity verification mean "false sense of security" = no security - DTLS-SRTP to verify fingerprint require identity services - Identity services rely on trusted third parties - Trusted third party identity services rely on TLS (https) So basically in any case the 'root of trust' is based on TLS. >From http://www.ietf.org/id/draft-ietf-rtcweb-security-arch-01.txt : 4.1. Initial Signaling [...] Based purely on the interface provided by the signaling server, they know that the signaling server claims that the call is from Alice to Bob. 4.3. DTLS Handshake [...] If Alice and Bob authenticated via their IdPs, then they also know that the signaling service is not attacking them. Even if they do not use an IdP, as long as they have minimal trust in the signaling service not to perform a man-in-the-middle attack, they know that their communications are secure against the signaling service as well. 5.1. Origin and Web Security Issues The basic unit of permissions for RTCWEB is the origin [RFC6454]. Because the security of the origin depends on being able to authenticate content from that origin, the origin can only be securely established if data is transferred over HTTPS [RFC2818]. So, while i totally agree to get DTLS-SRTP into the standard but please don't consider it the "panacea" as it's trust model, for how it's proposed: - DTLS-SRTP work securely when relying on trusted third party for idP - DTLS-SRTP work securely when you trust the signaling services - DTLS-SRTP work securely only when you trust third party that are trued via other TLS/CA based trust chain: - signaling service (web server) - identity provider So to have a "secure DTLS-SRTP" infrastructure that guarantee end-to-end encryption the user is not independent (like for ZRTP SAS that the authors of rtcweb-security-arch doesn't consider a valuable point) but must rely on at least 2 separate third party services that rely on TLS trust model. With SDES-SRTP you get "less security" than what DTLS-SRTP can provide but with an "order of magnitude" of simplicity because: - SDES-SRTP work securely when relying on a single party for TLS So again summarizing: - DTLS-SRTP "can" provide end-to-end crypto... ...ONLY IF the user trust 2 services that rely on TLS (the user trust at least 2 different services, signaling + idP) - SDES-SRTP "can" provide end-to-site crypto... ..ONLY IF the user trust 1 single service with TLS That's my point in arguing that SDES-SRTP MUST be implemented for it's strongest simplicity in implementation and in providing end-to-site encryption without all the high complexity DTLS-SRTP. But always consider that DTLS-SRTP, in order to be secure, still require the user to trust some third party and it's not able to independently verify the trust-condition of the other user. It's a matter of considering which trust scenario you want to protect about. DTLS-SRTP represent the "elephant in a room" concept, where a *huge level of complexity* is under the hood to be able to provide even a basic security level (even end-to-site encryption), and the end-user doesn't have a real way to understand "which security level" he is. At least with SDES-SRTP the user know that there is less, but simpler to be guaranteed, specific end-to-site security model (i connect to gmail, i trust gmail snooping my email). Please consider that as the stratification of complexity for DTLS-SRTP will probably result in practical less-reduced-security. IMHO any technology must provide protection against a specific risk model, here in this WG we are saying that DTLS-SRTP is the panacea for all the risk-model. That's unfortunately not true. There is "the right technology" to face "the right risk context" and when you try to make the use of a "specific technology" to satisfy all the risk context, the results are not always very good, due to the complexity of different factors to be considered. If we think that just providing something that can deliver "unsecure end-to-end encryption" by providing a "false sense of security" is a good things, let's goes on. But imho every technology must be specifically adapted to a specific risk scenario. If we want to really consider DTLS-SRTP's end-to-end encryption, the fingerprint checking must be completely in the hand of the user, with ZRTP's like SAS checking and not rely on third party services for trust. Fabio From lists@infosecurity.ch Tue Apr 3 11:11: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 C5FEA11E80D1 for ; Tue, 3 Apr 2012 11:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 L2TFKMBAOoyc for ; Tue, 3 Apr 2012 11:11:08 -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 07FB511E8083 for ; Tue, 3 Apr 2012 11:11:07 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2727412wgb.13 for ; Tue, 03 Apr 2012 11:11:07 -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=NT1BkhRS5AcBCMA+VvBUL5Fjhb6ZqTAysYgHtF2k5g8=; b=hp9eeJkrLoBuF7e9gdUMu1gnsmVC2qQd/MjTumlkiH2ySEQLDe+r3wKalCrwPQ+8rb adKxrspI5+cJFHgaVmyOhbRy/B8nIW/6g8+AlXAYQGhyyktUKWIACH9oBxbbKZC2R7zp /SIMuR9/Iht9rLWybMb1JTBvXht+jr0Z1/OFEG4vRaUd0RhjHFU5P5HrufPTaSZ6nNq8 aM7QHp8UhFvwA0vAAdkyf30UiE/XMXVI4HDPXkCNwlian6zWMScQXezspjxUS7ZKxn+7 enaRjSrIoK8qil4j8ocihrdejpnNSVSsV0xsqG9RrGDrj+oyTa4m5AD5rvIaL/aiHyH2 3mhg== Received: by 10.180.104.230 with SMTP id gh6mr38336066wib.22.1333476666464; Tue, 03 Apr 2012 11:11:06 -0700 (PDT) Received: from sonyvaiop13.local (host146-199-static.115-2-b.business.telecomitalia.it. [2.115.199.146]) by mx.google.com with ESMTPS id w10sm72325602wiy.3.2012.04.03.11.10.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 11:11:01 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7B3D12.4090406@infosecurity.ch> Date: Tue, 03 Apr 2012 20:10:26 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F742344.802@infosecurity.ch> , In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm8we9SoREjyxiVMBeYQQM/RP9RJI59jc2qxjqaP7rPp0FiiDHafGqiIsIVyfFhUTdd+rV3 Subject: Re: [rtcweb] Support of SDES in WebRTC (Javascript Crypto Extensions) 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 Apr 2012 18:11:16 -0000 On 3/29/12 11:59 PM, Gregory Maxwell wrote: > Oscar Ohlsson [oscar.ohlsson@ericsson.com] wrote: >> That's why I wrote "the entire webapp" below. If it was not clear I meant that the >> - main HTML page >> - all external CSS files, JavaScript files, images, etc >> - all XmlHttpRequests >> - all WebSocket connections >> are protected with TLS. This is obviously verifiable and it's a feature supported by all modern browsers (no mixed content). > > Even this is insufficient. > > First, even if it is in principle possible to provide adequate > cryptographic security inside the JS applications a great many of them > won't (for many reasons). That's a on-going debate that for many years kept researcher from working on JS-crypto, but nowdays the value of JS-crypto it's well recognized with valuable projects working on it. I think that in 2012 the old http://www.matasano.com/articles/javascript-cryptography/ on Javascript crypto can be considered superseded by http://hellais.wordpress.com/2011/12/27/how-to-improve-javascript-cryptography/ and by the discussion that arised from the OpenPGPJS mailing lists https://github.com/tanx/SafeWith.me/wiki/FAQ . The overall result is that it's possible to do securely enough crypto in javascript and that, as everything, it depends on the way you use it. So this is a typical out-of-date javascript crypto security consideration that is practically discussed in all the mailing lists i'm subscribed about javascript crypto. But from a pragmatic point of view there are very valuable way to implement secure Javascript Crypto and browser vendors are supporting and driving the path of JS-crypto securization. The cryptographic negotiation can be, and imho should be, pluggable, to be able to work at application level. Thunderbird doesn't provide OpenPGP encryption, but Enigmail (as a plugin) does. So imho we should leave to the application the ability to improve and adapt the security mechanisms, given all the context and use-cases that this WG cannot even forecast. Do we want rtcweb security working as "a blackbox" or do we want to make it working also like an "open platform" where it may be possible. This is not the strongest argument to have also support for SDES-SRTP, but it's for sure an argument, where the two strongest factor of SDES are: - simplicity - interoperability - opennes (so ability to hook custom crypto key exchange methods, due to it's simplicity in handling keys relying on TLS transport) > It's also inadequate on purely technical grounds: Javascript provides > no mechanism for working with mlocked memory, no mechanism to ensure > that garbage collected data gets zeroized. Your crypto app in JS could > easily have its long term keying material pulled out of free ram by > malware long after it runs, or pulled off the disk from swap. > The breakneck pace of fancy JIT systems makes it seem unlikely to me > that javascript will provide for that any time soon. That's a not real issue that cannot be fixed in any case, also in case you are using a bullet-proof native-code VoIP client. If you local machine compromised there's no mlock/garbage collection that can protect against memory dumping and memory injection. Javascript encryption is secure, for most context, as native encryption and many attacks considered to javascript crypto are attacks present in native implementation of crypto. Fabio From basilgohar@librevideo.org Tue Apr 3 11:37: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 3DBAF11E8099 for ; Tue, 3 Apr 2012 11:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_46=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 odZXiWq9wsox for ; Tue, 3 Apr 2012 11:37:19 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5A77711E8083 for ; Tue, 3 Apr 2012 11:37:19 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 33086641003 for ; Tue, 3 Apr 2012 14:37:18 -0400 (EDT) Message-ID: <4F7B435B.6030205@librevideo.org> Date: Tue, 03 Apr 2012 14:37:15 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Tue, 03 Apr 2012 18:37:20 -0000 Serge, Thank you very much for this. To go a step forward, I would encourage that this be made more legally obvious, because a reference to a single e-mail on an "obscure" mailing list (relative to what most people are familiar with) will not provide the deepest levels of assurance to those not actively involved with the WebRTC project. I would humbly request an unambiguous statement somewhere on the WebM project website that makes this assertion clear, because what is publicly available is, at the very least, ambiguous, and at the worst, "evidence of Google's nefarious scheme to pounce on hardware implementers after wide adoption". On 04/03/2012 01:54 PM, Serge Lachapelle wrote: > *[Forking the thread]* > * > > > * > *Hello folks,* > > Google confirms that the VP8 patent grant applies to both third-party > hardware and software implementations of VP8. > * > * > *Google encourages the community to create hardware implementations of > VP8, and has recently blogged about a number of new hardware > implementations on the WebM blog ( > http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware.html > ). * > * > * > *Google is quite proud of what the community has done with VP8 and > looks forward to seeing more implementations of VP8 in both hardware > and software. * > * > * > *Regards,* > * > * > */Serge Lachapelle, > Google, Stockholm* > > On Thu, Mar 29, 2012 at 16:53, Stephan Wenger > wrote: > > > > On 3.29.2012 16:24 , "Basil Mohamed Gohar" > > > wrote: > > >On 03/29/2012 10:20 AM, Stephan Wenger wrote: > >> The second part of your sentence may or may not be true, > depending on > >>your > >> relationship with google, your willingness to use the webm > >>implementation > >> in unchanged form, and other factors. Please see the webm license > >> conditions, which AFAIK can be found here: > >> http://www.webmproject.org/license/additional/ > >Correct. I think you are referring to this part, explicitly: > >> If you or your agent or exclusive licensee institute or order > or agree > >> to the institution of patent litigation against any entity > (including > >> a cross-claim or counterclaim in a lawsuit) alleging that this > >> implementation of VP8 or any code incorporated within this > >> implementation of VP8 constitutes direct or contributory patent > >> infringement, or inducement of patent infringement, then any patent > >> rights granted to you under this License for this implementation of > >> VP8 shall terminate as of the date such litigation is filed. > >Perhaps I assumed that that is a very reasonable part of the license. > >That is, if you are suing someone alleging a patent infringement > within > >VP8, you are no longer granted the license to use VP8's patented > >technologies that Google owns. > > Yes, that's one issue. Call it personal preference for different > type of > reciprocity conditions :-) (I could rant about it for hours, but > let's > continue to pretend that this is mostly a technical mailing list) > > The other issue, though (the fact that the license grant extends > only to > the VP8 implementation as provided by google, and does not extent to > derivative works such as hardware implementations) should be > moderately > alarming even for an open source person. With respect to this > clause, I > will note that I criticized the licensing conditions in private and in > public (IETF mike) several times, months ago, and nothing happened. > Suggests to me one of three things: (1) google is a large company and > decisions take time, or (2) google's legal is currently occupied with > other stuff, or (3) that the choice of language is intentional, and > intended to prevent forks. Take your pick. > Stephan > > >_______________________________________________ > >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 > 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. > > > > > -- > Serge Lachapelle | Product Manager | sergel@google.com > | +46 732 01 22 32 > > > -- > 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. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Libre Video http://librevideo.org From randell-ietf@jesup.org Tue Apr 3 13:04: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 149B611E815F for ; Tue, 3 Apr 2012 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=1.436, 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 WEILoTDF0Gws for ; Tue, 3 Apr 2012 13:04: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 8287B11E80E3 for ; Tue, 3 Apr 2012 13:04:19 -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 1SF9xi-0007sH-TU for rtcweb@ietf.org; Tue, 03 Apr 2012 15:04:18 -0500 Message-ID: <4F7B56F6.6080401@jesup.org> Date: Tue, 03 Apr 2012 16:00:54 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7AF40D.3010706@alvestrand.no> <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> In-Reply-To: <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.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] Identity and PSTN gateways 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 Apr 2012 20:04:20 -0000 On 4/3/2012 10:11 AM, Lu, Hui-Lan (Huilan) wrote: > It seems the same problem exists when a TURN relay is involved in an inter-browser call. The endpoints cannot verify each other's identity directly. They need to trust the relay to interconnect them and not to do anything evil, such as snooping. That shouldn't be the case if you're using DTLS-SRTP (i.e. TURN server doesn't decrypt/re-encrypt; if it does then it's a MITM). If it's SDES-SRTP, then the TURN server could tap off the encrypted traffic for later analysis by whomever has the key, or be supplied with the key to do realtime decode-and-forward, analysis or traffic modification. -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Tue Apr 3 13:48: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 1D6FA11E80CB for ; Tue, 3 Apr 2012 13:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014, 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 bBSivxiJgFiz for ; Tue, 3 Apr 2012 13:48:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B07F11E809D for ; Tue, 3 Apr 2012 13:48:12 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so101539vcb.31 for ; Tue, 03 Apr 2012 13:48:12 -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=zDyCK5onHR8lMDGs1GvrUgaL5/IMhMxv4i6cAvfdAnI=; b=Kgg9DfJiVFPvixoKM1Lb1g6qL98GgWtpcAq0Ax6D8ohfQb5ELlcCQss8pGlOWsadWI w1y13AQMPnZbv+xfy33i5Ydj55YVvZIM64g3Ulpcovj6LspMnbJ13VHYrXQIb8tyBY2F 930TNiruj2PoglPaRUCvJzfM891YtwY0DDcqEgd80yWh3B/fYBayW4plMzY52iTOKYsL n7BpiiV2KWMvIV82BmCFSEz/45/5X1jdazlDIDNUea6jEr3/FwyxTDKmHwsk0TTtlDcJ lQXneGXDx/HtaVSBTkJm4wdUCvaPFlIK5khGi4cFg04X+/40K3mOC9jKbk5P9ulgCmct 7QMw== Received: by 10.220.152.205 with SMTP id h13mr7051967vcw.12.1333486091943; Tue, 03 Apr 2012 13:48:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 3 Apr 2012 13:47:51 -0700 (PDT) In-Reply-To: <4F7B56F6.6080401@jesup.org> References: <4F7AF40D.3010706@alvestrand.no> <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> <4F7B56F6.6080401@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 3 Apr 2012 22:47:51 +0200 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlZ5IfACOB0NVZosS1RZ8c7DIF0toM/54iWMJKGiFi15LP9fjwXSp9DL+CI7M+6sIQuQdYA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Identity and PSTN gateways 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 Apr 2012 20:48:13 -0000 2012/4/3 Randell Jesup : > On 4/3/2012 10:11 AM, Lu, Hui-Lan (Huilan) wrote: >> >> It seems the same problem exists when a TURN relay is involved in an >> inter-browser call. The endpoints cannot verify each other's identity >> directly. They need to trust the relay to interconnect them and not to d= o >> anything evil, such as snooping. > > > That shouldn't be the case if you're using DTLS-SRTP (i.e. TURN server > doesn't decrypt/re-encrypt; if it does then it's a MITM). > If it's > SDES-SRTP, then the TURN server could tap off the encrypted traffic for > later analysis by whomever has the key, And who has the key? The trusted HTTPS server. > or be supplied with the key to do > realtime decode-and-forward, analysis or traffic modification. And who has the key? The trusted HTTPS server. So what is the real problem? the trusted HTTPS server when attacked. The *same* is true in case of DTLS-SRTP when the HTTPS server or the identity provider (via TLS again) is attacked. Please read the mail "On DTLS-SRTP trust model (and consideration for SDES-SRTP)" from Fabio. DTLS is not the panacea. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Tue Apr 3 15:16: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 733EC11E8086 for ; Tue, 3 Apr 2012 15:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.957, 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 MVkHm+f8XJgd for ; Tue, 3 Apr 2012 15:16:35 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E419311E8074 for ; Tue, 3 Apr 2012 15:16: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 1SFC1h-0007Do-MG for rtcweb@ietf.org; Tue, 03 Apr 2012 17:16:33 -0500 Message-ID: <4F7B75F5.5030308@jesup.org> Date: Tue, 03 Apr 2012 18:13:09 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7AF40D.3010706@alvestrand.no> <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> <4F7B56F6.6080401@jesup.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Identity and PSTN gateways 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 Apr 2012 22:16:35 -0000 On 4/3/2012 4:47 PM, Iñaki Baz Castillo wrote: > 2012/4/3 Randell Jesup: >> If it's >> SDES-SRTP, then the TURN server could tap off the encrypted traffic for >> later analysis by whomever has the key, > > And who has the key? The trusted HTTPS server. > >> or be supplied with the key to do >> realtime decode-and-forward, analysis or traffic modification. > > And who has the key? The trusted HTTPS server. > > So what is the real problem? the trusted HTTPS server when attacked. > The *same* is true in case of DTLS-SRTP when the HTTPS server or the > identity provider (via TLS again) is attacked. Ah, but Identity Provider != Service Provider. (It may be the same, but for smaller entities it wouldn't be - typically the Idp's will be "big sites" that act as primary email hosts, like Google.) Yes, it's well-known in the discussion that if the service provider == Idp then the Idp can MITM you (or at least make things more complex; it may be possible to use key-chaining to reduce risk some). > Please read the mail "On DTLS-SRTP trust model (and consideration for > SDES-SRTP)" from Fabio. DTLS is not the panacea. Nothing is. :-) -- Randell Jesup randell-ietf@jesup.org From paulej@packetizer.com Tue Apr 3 19:45: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 BCEC511E809B for ; Tue, 3 Apr 2012 19:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 BZ0RVeab4qa4 for ; Tue, 3 Apr 2012 19:45:52 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 930C011E8072 for ; Tue, 3 Apr 2012 19:45:52 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q342joVR010555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Apr 2012 22:45:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333507551; bh=7QXvDCx8DNsBNdIKSSFv/Dm85yPU32VGohNW/uqEkvI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=bhrnYHSLbMuFs9SoqxNYZedfk5HjM0Oj+dQkKdLgckrVe0X9EEbWLVbiiPAnSHx7e fscfk9mHXAe6s9rOng/xalyGnKeyLuvRX8nRoiYNwROAcWYA97qbwx3SmW8VGwcC+0 V531xQZXSnUxxgiYEe09Fx5Yup8bu1ctK3VnpJBo= From: "Paul E. Jones" To: "'Serge Lachapelle'" , References: In-Reply-To: Date: Tue, 3 Apr 2012 22:45:56 -0400 Message-ID: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AD_01CD11EB.88EF66F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0Jpk2coDA Content-Language: en-us Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 04 Apr 2012 02:45:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03AD_01CD11EB.88EF66F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Will Google indemnify all implementers against any IPR claims? Do that, and I think the debate would be over. Paul From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Serge Lachapelle Sent: Tuesday, April 03, 2012 1:55 PM To: rtcweb@ietf.org Subject: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline codec] [Forking the thread] Hello folks, Google confirms that the VP8 patent grant applies to both third-party hardware and software implementations of VP8. Google encourages the community to create hardware implementations of VP8, and has recently blogged about a number of new hardware implementations on the WebM blog ( http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware.html ). Google is quite proud of what the community has done with VP8 and looks forward to seeing more implementations of VP8 in both hardware and software. Regards, /Serge Lachapelle, Google, Stockholm On Thu, Mar 29, 2012 at 16:53, Stephan Wenger wrote: On 3.29.2012 16:24 , "Basil Mohamed Gohar" wrote: >On 03/29/2012 10:20 AM, Stephan Wenger wrote: >> The second part of your sentence may or may not be true, depending on >>your >> relationship with google, your willingness to use the webm >>implementation >> in unchanged form, and other factors. Please see the webm license >> conditions, which AFAIK can be found here: >> http://www.webmproject.org/license/additional/ >Correct. I think you are referring to this part, explicitly: >> If you or your agent or exclusive licensee institute or order or agree >> to the institution of patent litigation against any entity (including >> a cross-claim or counterclaim in a lawsuit) alleging that this >> implementation of VP8 or any code incorporated within this >> implementation of VP8 constitutes direct or contributory patent >> infringement, or inducement of patent infringement, then any patent >> rights granted to you under this License for this implementation of >> VP8 shall terminate as of the date such litigation is filed. >Perhaps I assumed that that is a very reasonable part of the license. >That is, if you are suing someone alleging a patent infringement within >VP8, you are no longer granted the license to use VP8's patented >technologies that Google owns. Yes, that's one issue. Call it personal preference for different type of reciprocity conditions :-) (I could rant about it for hours, but let's continue to pretend that this is mostly a technical mailing list) The other issue, though (the fact that the license grant extends only to the VP8 implementation as provided by google, and does not extent to derivative works such as hardware implementations) should be moderately alarming even for an open source person. With respect to this clause, I will note that I criticized the licensing conditions in private and in public (IETF mike) several times, months ago, and nothing happened. Suggests to me one of three things: (1) google is a large company and decisions take time, or (2) google's legal is currently occupied with other stuff, or (3) that the choice of language is intentional, and intended to prevent forks. Take your pick. Stephan >_______________________________________________ >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 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. -- Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32 -- 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. ------=_NextPart_000_03AD_01CD11EB.88EF66F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will Google indemnify all implementers against any IPR claims?  = Do that, and I think the debate would be over.

 

Paul

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Serge Lachapelle
Sent: Tuesday, April 03, 2012 1:55 = PM
To: rtcweb@ietf.org
Subject: [rtcweb] Google VP8 = Patent Grant for third parties [Was Re:Proposal for H.263 baseline = codec]

 

[Forking the = thread]

 

Hello = folks,


Google = confirms that the VP8 patent grant applies to both third-party hardware = and software implementations of = VP8. 

 

Google = encourages the community to create hardware implementations of VP8, and = has recently blogged about a number of new hardware implementations on = the WebM blog ( http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-h= ardware.html ). 

 

Google is = quite proud of what the community has done with VP8 and looks forward to = seeing more implementations of VP8 in both hardware and = software. 

 

Regards,

 

/Serge = Lachapelle, Google, Stockholm

 

On Thu, Mar 29, 2012 at 16:53, Stephan Wenger <stewe@stewe.org> wrote:



On 3.29.2012 16:24 , "Basil Mohamed = Gohar" <basilgohar@librevideo.org>
wrote:<= /p>


>On 03/29/2012 10:20 AM, Stephan = Wenger wrote:
>> The second part of your sentence may or may = not be true, depending on
>>your
>> relationship with = google, your willingness to use the = webm
>>implementation
>> in unchanged form, and other = factors.  Please see the webm license
>> conditions, which = AFAIK can be found here:
>> http://www.webmproject.org/license/additional/
&= gt;Correct.  I think you are referring to this part, = explicitly:
>> If you or your agent or exclusive licensee = institute or order or agree
>> to the institution of patent = litigation against any entity (including
>> a cross-claim or = counterclaim in a lawsuit) alleging that this
>> implementation = of VP8 or any code incorporated within this
>> implementation = of VP8 constitutes direct or contributory patent
>> = infringement, or inducement of patent infringement, then any = patent
>> rights granted to you under this License for this = implementation of
>> VP8 shall terminate as of the date such = litigation is filed.
>Perhaps I assumed that that is a very = reasonable part of the license.
>That is, if you are suing someone = alleging a patent infringement within
>VP8, you are no longer = granted the license to use VP8's patented
>technologies that = Google owns.

Yes, that's = one issue.  Call it personal preference for different type = of
reciprocity conditions :-)  (I could rant about it for hours, = but let's
continue to pretend that this is mostly a technical mailing = list)

The other issue, though (the fact that the license grant = extends only to
the VP8 implementation as provided by google, and = does not extent to
derivative works such as hardware implementations) = should be moderately
alarming even for an open source person. =  With respect to this clause, I
will note that I criticized the = licensing conditions in private and in
public (IETF mike) several = times, months ago, and nothing happened.
Suggests to me one of three = things: (1) google is a large company and
decisions take time, or (2) = google's legal is currently occupied with
other stuff, or (3) that = the choice of language is intentional, and
intended to prevent forks. =  Take your pick.
Stephan


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

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.


 

-- =
Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32

 

-- =

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.

------=_NextPart_000_03AD_01CD11EB.88EF66F0-- From basilgohar@librevideo.org Tue Apr 3 21:25: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 4F0AA11E809B for ; Tue, 3 Apr 2012 21:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] 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 ha3sAFaaDVZI for ; Tue, 3 Apr 2012 21:25:02 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBB11E8072 for ; Tue, 3 Apr 2012 21:25:02 -0700 (PDT) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id C161C644F59 for ; Wed, 4 Apr 2012 00:25:00 -0400 (EDT) Message-ID: <4F7BCD1A.7020508@librevideo.org> Date: Wed, 04 Apr 2012 00:24:58 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> In-Reply-To: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 04 Apr 2012 04:25:04 -0000 While it would be great if such a thing were possible, even the MPEG-LA does not indemnify users of H.264 from any IPR claims. Expecting Google to do so is unreasonable. Moreover, there are other practical issues such as NDAs that patent litigation frequently invokes that would still allow someone to be sued even if Google did offer indemnification. The strongest thing Google can do, I think, is what they already do in relation to nullifying all grants to their patents that cover VP8 should someone engage in a lawsuit against Google. The software patent landscape, sadly, does not leave many more options on the table. Perhaps someone more familiar with patent law can expand and/or correct what I've said. It should go without saying that IANAL. -- Libre Video http://librevideo.org On 04/03/2012 10:45 PM, Paul E. Jones wrote: > > Will Google indemnify all implementers against any IPR claims? Do > that, and I think the debate would be over. > > Paul > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Serge Lachapelle > *Sent:* Tuesday, April 03, 2012 1:55 PM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Google VP8 Patent Grant for third parties [Was > Re:Proposal for H.263 baseline codec] > > [Forking the thread] > > Hello folks, > > > Google confirms that the VP8 patent grant applies to both third-party > hardware and software implementations of VP8. > > Google encourages the community to create hardware implementations of > VP8, and has recently blogged about a number of new hardware > implementations on the WebM blog ( > http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware.html > ). > > Google is quite proud of what the community has done with VP8 and > looks forward to seeing more implementations of VP8 in both hardware > and software. > > Regards, > > /Serge Lachapelle, Google, Stockholm > > On Thu, Mar 29, 2012 at 16:53, Stephan Wenger > wrote: > > > > On 3.29.2012 16:24 , "Basil Mohamed Gohar" > > wrote: > > > >On 03/29/2012 10:20 AM, Stephan Wenger wrote: > >> The second part of your sentence may or may not be true, depending on > >>your > >> relationship with google, your willingness to use the webm > >>implementation > >> in unchanged form, and other factors. Please see the webm license > >> conditions, which AFAIK can be found here: > >> http://www.webmproject.org/license/additional/ > >Correct. I think you are referring to this part, explicitly: > >> If you or your agent or exclusive licensee institute or order or agree > >> to the institution of patent litigation against any entity (including > >> a cross-claim or counterclaim in a lawsuit) alleging that this > >> implementation of VP8 or any code incorporated within this > >> implementation of VP8 constitutes direct or contributory patent > >> infringement, or inducement of patent infringement, then any patent > >> rights granted to you under this License for this implementation of > >> VP8 shall terminate as of the date such litigation is filed. > >Perhaps I assumed that that is a very reasonable part of the license. > >That is, if you are suing someone alleging a patent infringement within > >VP8, you are no longer granted the license to use VP8's patented > >technologies that Google owns. > > Yes, that's one issue. Call it personal preference for different type of > reciprocity conditions :-) (I could rant about it for hours, but let's > continue to pretend that this is mostly a technical mailing list) > > The other issue, though (the fact that the license grant extends only to > the VP8 implementation as provided by google, and does not extent to > derivative works such as hardware implementations) should be moderately > alarming even for an open source person. With respect to this clause, I > will note that I criticized the licensing conditions in private and in > public (IETF mike) several times, months ago, and nothing happened. > Suggests to me one of three things: (1) google is a large company and > decisions take time, or (2) google's legal is currently occupied with > other stuff, or (3) that the choice of language is intentional, and > intended to prevent forks. Take your pick. > Stephan > > From paulej@packetizer.com Tue Apr 3 22:23: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 C26FE21F86D6 for ; Tue, 3 Apr 2012 22:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, 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 vzKzbLLnENqf for ; Tue, 3 Apr 2012 22:23:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9800321F86D5 for ; Tue, 3 Apr 2012 22:23:29 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q345NSwO014823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2012 01:23:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333517008; bh=A1Oun/ALQpaY7NA1lfEujf+uWJ8yWmlYMHC+nDQIeX4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=MB8ihvGGWNyl+QHOWVRm9ugF84xJ1vTfptx1+NkXFTrqpKkdAbzpqiu31j7p7HUCA BOOm2vYSs+hK4sro2MBC95A0008ZD+XToFCaJBMYddLK2Vju6QBuefHmtNnB+OYKFo 5Z1pjARAgl96hZrkljMeKrxhPRLfzj2Y9cqI1ZIo= From: "Paul E. Jones" To: "'Basil Mohamed Gohar'" , References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> In-Reply-To: <4F7BCD1A.7020508@librevideo.org> Date: Wed, 4 Apr 2012 01:23:34 -0400 Message-ID: <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNyZHW3p4A== Content-Language: en-us Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 04 Apr 2012 05:23:30 -0000 Basil, I disagree. If VP8 is believed so strongly to be free of any IPR, then Google could boldly indemnify a company. Personally, I have my doubts that it is. MPEG-LA is not in the business of indemnifying people, nor do I believe they would make a claim that H.264 is not covered by another patent holder. That said, I do believe that there is a significantly increased probability that all patent holders either license through MPEG-LA or have listed IPR on H.264 in the ITU's IPR database. I would have a high degree of confidence that I could identify all H.264 IPR holders. I have no degree of confidence I could do the same for VP8. Paul > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Basil Mohamed Gohar > Sent: Wednesday, April 04, 2012 12:25 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was > Re:Proposal for H.263 baseline codec] > > While it would be great if such a thing were possible, even the MPEG-LA > does not indemnify users of H.264 from any IPR claims. Expecting Google > to do so is unreasonable. Moreover, there are other practical issues such > as NDAs that patent litigation frequently invokes that would still allow > someone to be sued even if Google did offer indemnification. > > The strongest thing Google can do, I think, is what they already do in > relation to nullifying all grants to their patents that cover VP8 should > someone engage in a lawsuit against Google. The software patent > landscape, sadly, does not leave many more options on the table. > Perhaps someone more familiar with patent law can expand and/or correct > what I've said. > > It should go without saying that IANAL. > > -- > Libre Video > http://librevideo.org > > > On 04/03/2012 10:45 PM, Paul E. Jones wrote: > > > > Will Google indemnify all implementers against any IPR claims? Do > > that, and I think the debate would be over. > > > > Paul > > > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > > Behalf Of *Serge Lachapelle > > *Sent:* Tuesday, April 03, 2012 1:55 PM > > *To:* rtcweb@ietf.org > > *Subject:* [rtcweb] Google VP8 Patent Grant for third parties [Was > > Re:Proposal for H.263 baseline codec] > > > > [Forking the thread] > > > > Hello folks, > > > > > > Google confirms that the VP8 patent grant applies to both third-party > > hardware and software implementations of VP8. > > > > Google encourages the community to create hardware implementations of > > VP8, and has recently blogged about a number of new hardware > > implementations on the WebM blog ( > > http://blog.webmproject.org/2012/03/webm-gaining-momentum-in- > hardware.html > > ). > > > > Google is quite proud of what the community has done with VP8 and > > looks forward to seeing more implementations of VP8 in both hardware > > and software. > > > > Regards, > > > > /Serge Lachapelle, Google, Stockholm > > > > On Thu, Mar 29, 2012 at 16:53, Stephan Wenger > > wrote: > > > > > > > > On 3.29.2012 16:24 , "Basil Mohamed Gohar" > > > > wrote: > > > > > > >On 03/29/2012 10:20 AM, Stephan Wenger wrote: > > >> The second part of your sentence may or may not be true, depending on > > >>your > > >> relationship with google, your willingness to use the webm > > >>implementation > > >> in unchanged form, and other factors. Please see the webm license > > >> conditions, which AFAIK can be found here: > > >> http://www.webmproject.org/license/additional/ > > >Correct. I think you are referring to this part, explicitly: > > >> If you or your agent or exclusive licensee institute or order or > agree > > >> to the institution of patent litigation against any entity (including > > >> a cross-claim or counterclaim in a lawsuit) alleging that this > > >> implementation of VP8 or any code incorporated within this > > >> implementation of VP8 constitutes direct or contributory patent > > >> infringement, or inducement of patent infringement, then any patent > > >> rights granted to you under this License for this implementation of > > >> VP8 shall terminate as of the date such litigation is filed. > > >Perhaps I assumed that that is a very reasonable part of the license. > > >That is, if you are suing someone alleging a patent infringement within > > >VP8, you are no longer granted the license to use VP8's patented > > >technologies that Google owns. > > > > Yes, that's one issue. Call it personal preference for different type > of > > reciprocity conditions :-) (I could rant about it for hours, but let's > > continue to pretend that this is mostly a technical mailing list) > > > > The other issue, though (the fact that the license grant extends only to > > the VP8 implementation as provided by google, and does not extent to > > derivative works such as hardware implementations) should be moderately > > alarming even for an open source person. With respect to this clause, I > > will note that I criticized the licensing conditions in private and in > > public (IETF mike) several times, months ago, and nothing happened. > > Suggests to me one of three things: (1) google is a large company and > > decisions take time, or (2) google's legal is currently occupied with > > other stuff, or (3) that the choice of language is intentional, and > > intended to prevent forks. Take your pick. > > Stephan > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From basilgohar@librevideo.org Wed Apr 4 06:42: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 23FBA21F860F for ; Wed, 4 Apr 2012 06:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=1.507, 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 NakYz-eZ82BY for ; Wed, 4 Apr 2012 06:42:17 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0585221F85A5 for ; Wed, 4 Apr 2012 06:42:16 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id EF69D652275 for ; Wed, 4 Apr 2012 09:42:15 -0400 (EDT) Message-ID: <4F7C4FB4.4070703@librevideo.org> Date: Wed, 04 Apr 2012 09:42:12 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> In-Reply-To: <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 04 Apr 2012 13:42:18 -0000 Paul, What you are asking for is something no one in the media industry offers for something comparable. As was pointed out elsewhere on this list, even the H.264 standard has been updated to include additional patents over time deemed to be "essential". One could be non-infringing in the past and suddenly find yourself infringing. I don't know what all of Google's public statements about VP8 IPR status are, but we know that the patents they own are granted via the license, and we know that a public call for the formation of a patent pool over a year ago has yielded not even a follow-up announcement from MPEG-LA. Furthermore, not a single patent has been brought forward publicly as being even remotely doubtful as to its application to VP8. So, until there is some actual evidence that there is an IPR threat, then with all due respect, statements such as yours must be classified as spreading FUD, because they serve to drive adoption away from a free, open, unencumbered standard to one that is on baseless claims. -- Libre Video http://librevideo.org On 04/04/2012 01:23 AM, Paul E. Jones wrote: > Basil, > > I disagree. If VP8 is believed so strongly to be free of any IPR, then > Google could boldly indemnify a company. Personally, I have my doubts that > it is. > > MPEG-LA is not in the business of indemnifying people, nor do I believe they > would make a claim that H.264 is not covered by another patent holder. That > said, I do believe that there is a significantly increased probability that > all patent holders either license through MPEG-LA or have listed IPR on > H.264 in the ITU's IPR database. > > I would have a high degree of confidence that I could identify all H.264 IPR > holders. I have no degree of confidence I could do the same for VP8. > > Paul > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Basil Mohamed Gohar >> Sent: Wednesday, April 04, 2012 12:25 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was >> Re:Proposal for H.263 baseline codec] >> >> While it would be great if such a thing were possible, even the MPEG-LA >> does not indemnify users of H.264 from any IPR claims. Expecting Google >> to do so is unreasonable. Moreover, there are other practical issues such >> as NDAs that patent litigation frequently invokes that would still allow >> someone to be sued even if Google did offer indemnification. >> >> The strongest thing Google can do, I think, is what they already do in >> relation to nullifying all grants to their patents that cover VP8 should >> someone engage in a lawsuit against Google. The software patent >> landscape, sadly, does not leave many more options on the table. >> Perhaps someone more familiar with patent law can expand and/or correct >> what I've said. >> >> It should go without saying that IANAL. >> >> -- >> Libre Video >> http://librevideo.org >> >> >> On 04/03/2012 10:45 PM, Paul E. Jones wrote: >>> Will Google indemnify all implementers against any IPR claims? Do >>> that, and I think the debate would be over. >>> >>> Paul >>> >>> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On >>> Behalf Of *Serge Lachapelle >>> *Sent:* Tuesday, April 03, 2012 1:55 PM >>> *To:* rtcweb@ietf.org >>> *Subject:* [rtcweb] Google VP8 Patent Grant for third parties [Was >>> Re:Proposal for H.263 baseline codec] >>> >>> [Forking the thread] >>> >>> Hello folks, >>> >>> >>> Google confirms that the VP8 patent grant applies to both third-party >>> hardware and software implementations of VP8. >>> >>> Google encourages the community to create hardware implementations of >>> VP8, and has recently blogged about a number of new hardware >>> implementations on the WebM blog ( >>> http://blog.webmproject.org/2012/03/webm-gaining-momentum-in- >> hardware.html >>> ). >>> >>> Google is quite proud of what the community has done with VP8 and >>> looks forward to seeing more implementations of VP8 in both hardware >>> and software. >>> >>> Regards, >>> >>> /Serge Lachapelle, Google, Stockholm >>> >>> On Thu, Mar 29, 2012 at 16:53, Stephan Wenger >> > wrote: >>> >>> >>> >>> On 3.29.2012 16:24 , "Basil Mohamed Gohar" >> > >>> wrote: >>> >>> >>>> On 03/29/2012 10:20 AM, Stephan Wenger wrote: >>>>> The second part of your sentence may or may not be true, depending on >>>>> your >>>>> relationship with google, your willingness to use the webm >>>>> implementation >>>>> in unchanged form, and other factors. Please see the webm license >>>>> conditions, which AFAIK can be found here: >>>>> http://www.webmproject.org/license/additional/ >>>> Correct. I think you are referring to this part, explicitly: >>>>> If you or your agent or exclusive licensee institute or order or >> agree >>>>> to the institution of patent litigation against any entity (including >>>>> a cross-claim or counterclaim in a lawsuit) alleging that this >>>>> implementation of VP8 or any code incorporated within this >>>>> implementation of VP8 constitutes direct or contributory patent >>>>> infringement, or inducement of patent infringement, then any patent >>>>> rights granted to you under this License for this implementation of >>>>> VP8 shall terminate as of the date such litigation is filed. >>>> Perhaps I assumed that that is a very reasonable part of the license. >>>> That is, if you are suing someone alleging a patent infringement within >>>> VP8, you are no longer granted the license to use VP8's patented >>>> technologies that Google owns. >>> Yes, that's one issue. Call it personal preference for different type >> of >>> reciprocity conditions :-) (I could rant about it for hours, but let's >>> continue to pretend that this is mostly a technical mailing list) >>> >>> The other issue, though (the fact that the license grant extends only to >>> the VP8 implementation as provided by google, and does not extent to >>> derivative works such as hardware implementations) should be moderately >>> alarming even for an open source person. With respect to this clause, I >>> will note that I criticized the licensing conditions in private and in >>> public (IETF mike) several times, months ago, and nothing happened. >>> Suggests to me one of three things: (1) google is a large company and >>> decisions take time, or (2) google's legal is currently occupied with >>> other stuff, or (3) that the choice of language is intentional, and >>> intended to prevent forks. Take your pick. >>> Stephan >>> >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Wed Apr 4 09:44: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 3D9F521F86B1 for ; Wed, 4 Apr 2012 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013, 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 HmEmyDjrzJ8u for ; Wed, 4 Apr 2012 09:44:08 -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 1868C21F85DF for ; Wed, 4 Apr 2012 09:44:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so380095vbb.31 for ; Wed, 04 Apr 2012 09:44: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:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=oqKYzqy1HXcJJfzfH2rStrTOX/Sx7njoM0iWtOGHfec=; b=a+LV7GAOvKZlOGVCOXsGgULgnYYgo1SC7Nu72QhmJ370LF+W28YnihZjOdGgfdWjQu U75GpW3JZnhpjaXKfYitFlKtxkX90tW/688g8OBcl5mliS8MzIFambbvpK9ZS/0kk6uO 3eIPA1zE/cCQCE/rajTwDSt6LYJz/iJM6ezJ1UBk2YkCv3r+YDp9Wn2txHgAWHDRMsK7 bZiBxRbpNpTw+us4QHqBFOqRnXxZkklyTV1wy3KFkFVML+nHZ4b6Rvw+cidgNstqjx95 k4IqLB0gCdQO8D8dW7E3NXTwwjelqpoZe5AQ9xzlda3h7pF5aNN8KL1MsTphlwzHGPk1 2Ajw== Received: by 10.52.15.233 with SMTP id a9mr7681527vdd.34.1333557847524; Wed, 04 Apr 2012 09:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 4 Apr 2012 09:43:47 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 4 Apr 2012 18:43:47 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkl5OSf9RxoyfquSY2sPxmQL5fvJvyDTLeIW+xmOuj6ZJaaQb27GKOzDJweX/ZXQmOwImLV Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 16:44:09 -0000 2012/4/3 I=C3=B1aki Baz Castillo : > Hi all, > > I've made two "pictures" showing WebRTC and SIP interop for two cases: > > 1) SDES-SRTP is allowed in WebRTC: > =C2=A0 =C2=A0 =C2=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDE= S-SRTP.png > > 2) Just DTLS-ETK-SRTP is allowed in WebRTC [*] > =C2=A0 =C2=A0 =C2=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTL= S-EKT-SRTP.png > > [*] slides 30-35 in > http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf > > > For those claiming to mandate *just* DTLS-EKT-SRTP in WebRTC, please > see the *cost* of such a decision, and also: > > - Thanks for requiring a super Signaling+Media B2BUA/SBC in WebRTC/SIP > interop scenarios. Some vendors will be very happy and will become > very rich. Such a super device (also a DTLS to SDES conversor, > including DTLS key updates to re-INVITE) will be "a bit"... expensive. > > - Thanks for disallowing *pure* SIP protocol usage (and instead > requiring SIP B2BUAs/SBCs or custom WebRTC signaling to SIP conversion > gateways). WebRTC is supposed to let the signaling protocol up to the > application, but pure SIP protocol will not be possible since a SIP > B2BUA/SBC is required, and those devices always break/limit the SIP > protocol (*always*). > > > So IMHO, option 2 ("just DTLS-EKT-SRTP is allowed in WebRTC") is The Barr= ier. Hi, nobody cares about the implications of option 2 ??? Do all the people planning to interop with SIP assume that they'll need the super B2BUA in the second image (without the possibility of using a pure SIP proxy)?: http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png BTW Fabio has sent two magistral mails explaining why DTLS is not the panacea and why SDES can be good enough to satisfy the same level of security than DTLS. No comments? Regards. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Wed Apr 4 10:24: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 F20E421F8750 for ; Wed, 4 Apr 2012 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_BIZOP=0.7] 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 gEsWOvPQhjmt for ; Wed, 4 Apr 2012 10:24: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 9CF7621F8732 for ; Wed, 4 Apr 2012 10:24:42 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so502935pbb.31 for ; Wed, 04 Apr 2012 10:24: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=yz5eiyCMnmFGJeALxNhXcnACfDjMYIWRD29jKi9Hyb8=; b=CAmtOi/1xwlJZcc6TDF+m1zTR73dpreR+0eu3eIDAQlUkbeJnE8CnjKhl45wDFhYnY dA1YZNCF2OeyyJnDoSP4p1gKiTpNoMbu+GnqDKjCkr/Ab6HrCzKv78RmV2/vEu+Q+jfY J+kjaHcqEuJ27lix/9s1BfrQ6AFjd2mAcY3wXypPGJPpbnVzBX2QDzSb5COUkeGeVcYY DJ33/G3QwNoFYgCCeYI0CwM8NE81e3E39d3MVpXzKCHMgyZMJSFQnr0zqI19YelnNn62 rTAQP0k3YWwRf1Ztwrt5uDZwf2d4UyQEh8h2Dp+G7Tm+t0lOiFaNIoU96Q94HVYQlJk6 5YTw== Received: by 10.68.230.8 with SMTP id su8mr242090pbc.105.1333560282428; Wed, 04 Apr 2012 10:24:42 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id d2sm1028282pbw.39.2012.04.04.10.24.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 10:24:40 -0700 (PDT) Received: by dady13 with SMTP id y13so731977dad.27 for ; Wed, 04 Apr 2012 10:24:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.69 with SMTP id gw5mr39388626pbc.141.1333560279519; Wed, 04 Apr 2012 10:24:39 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 4 Apr 2012 10:24:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Apr 2012 13:24:39 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8fb208dcbf527804bcddb251 X-Gm-Message-State: ALoCoQmsLh02oVgdNOFeAOQbj1n6fm2gYUbFO9loKVC01yFNaC988a1wqkhu5hDWRGmkydYFF1Z2 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 17:24:44 -0000 --e89a8fb208dcbf527804bcddb251 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 4, 2012 at 12:43 PM, I=F1aki Baz Castillo wrote= : > Hi, nobody cares about the implications of option 2 ??? > > Do all the people planning to interop with SIP assume that they'll > need the super B2BUA in the second image (without the possibility of > using a pure SIP proxy)?: > > http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png > > I guess we should look at this as a business opportunity ;) I am not sure why you assume that building such gateway would take 10 years. I can sell a gateway like this to anybody who needs it right now. My assumption is that IP phones will migrate to WebRTC effectively eliminating SIP in end user devices. The only place where SIP will remain would be federation, which commonly uses some sort of SBC anyway. This SBC will need to be extended to support ICE anyway. Might as well through in support for DTLS-EKV-SRTP. I doubt it will map DTLS key updates to re-invites. Most probably it will simply re-encode. ______________ Roman Shpount --e89a8fb208dcbf527804bcddb251 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 4, 2012 at 12:43 PM, I=F1aki Baz Cas= tillo <ibc@aliax.net<= /a>> wrote:
Hi, nobody cares about the implications of option 2 ???

Do all the people planning to interop with SIP assume that they'll
need the super B2BUA in the second image (without the possibility of
using a pure SIP proxy)?:

=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Intero= p_DTLS-EKT-SRTP.png


<sarcasm>I guess we should look at this as= a business opportunity ;) I am not sure why you assume that building such = gateway would take 10 years. I can sell a gateway like this to anybody who = needs it right now.</sarcasm>

My assumption is that IP phones will migrate to WebRTC effectively elim= inating SIP in end user devices. The only place where SIP will remain would= be federation, which commonly uses some sort of SBC anyway. This SBC will = need to be extended to support ICE anyway. Might as well through in support= for DTLS-EKV-SRTP. I doubt it will map DTLS key updates to re-invites. Mos= t probably it will simply re-encode.
=A0
______________
Roman Shpount
--e89a8fb208dcbf527804bcddb251-- From ibc@aliax.net Wed Apr 4 10:34: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 D632C21F8732 for ; Wed, 4 Apr 2012 10:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_BIZOP=0.7] 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 idlE3rREHXAT for ; Wed, 4 Apr 2012 10:34:39 -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 2BA3621F86DA for ; Wed, 4 Apr 2012 10:34:39 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so437218vbb.31 for ; Wed, 04 Apr 2012 10:34: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=63Z/PKP7mLc7b7xmS7rSVFdw2wCgvsoWF5XhTnVkwEA=; b=XzPUkIiqq+vnDcT1afxc8qbiS/w6mJFY9gd0YpucLCf926dDpml78NvtdhlnKogOGz +bkzhr51+pyZr/MeZ6lO+X7g/rtvIKiDxPPPQTw/wSIgubB6nSFAI0lfq8sd0UAZ49SX BUs0xvVQE55NRBPbqg5MJpEMrdHgmxeYBIakJ2LtNZ3tqOClkS+Ex2vlDazQJi5YjVem CxrhJUArQgCUpa7bU4CZ3d6mbmEQ3oFCwa3EuC9QiiAPIUBez/TzXl3tN3UYqEvO0Pgk 3l4FJ+mgxYEwKiG66ABziJE6z4VqJY7JRDjoO1aP0K+Vub4MdiEFywJyH4nXQ1SJOPAH lETw== Received: by 10.52.27.1 with SMTP id p1mr7945954vdg.17.1333560878631; Wed, 04 Apr 2012 10:34:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 4 Apr 2012 10:34:18 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 4 Apr 2012 19:34:18 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlVmnivPbzgBj0SrGVdM8cLHBeHUXb9JccNoja36y4/HDC97OeGOAfglZq+SGlGaqB3dTc9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 17:34:40 -0000 2012/4/4 Roman Shpount : > On Wed, Apr 4, 2012 at 12:43 PM, I=C3=B1aki Baz Castillo = wrote: >> >> Hi, nobody cares about the implications of option 2 ??? >> >> Do all the people planning to interop with SIP assume that they'll >> need the super B2BUA in the second image (without the possibility of >> using a pure SIP proxy)?: >> >> =C2=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.pn= g >> > > I guess we should look at this as a business opportunity ;) I am > not sure why you assume that building such gateway would take 10 years. I > can sell a gateway like this to anybody who needs it right now. > > My assumption is that IP phones will migrate to WebRTC effectively > eliminating SIP in end user devices. The only place where SIP will remain > would be federation, which commonly uses some sort of SBC anyway. This SB= C > will need to be extended to support ICE anyway. Might as well through in > support for DTLS-EKV-SRTP. I doubt it will map DTLS key updates to > re-invites. Most probably it will simply re-encode. Roman... I hope you missed the closing tag just HERE, am I right? XDDD --=20 I=C3=B1aki Baz Castillo From sergel@google.com Wed Apr 4 11:45: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 6692811E80B2 for ; Wed, 4 Apr 2012 11:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.076 X-Spam-Level: X-Spam-Status: No, score=-101.076 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 9hn8V4MVZh4C for ; Wed, 4 Apr 2012 11:45:05 -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 07CDD11E80B0 for ; Wed, 4 Apr 2012 11:45:04 -0700 (PDT) Received: by yenm5 with SMTP id m5so419683yen.31 for ; Wed, 04 Apr 2012 11:45:04 -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=Awnl11+KEjCpLZ0aM6XDycx/Qf4VwTD1X7eJLTb7gpA=; b=Q2nO/19XwRJVGyVyc88bDgmYqCqWZBZgIBgT4gmg5bWZzBnIH3ZBX0OOUT6iMoq9F5 zfPmir3VBr3Sun0WeE8ehr1CUkRYxOVwsGGJgmfaNxOT5eD6Yt/ubeVpX/rkqojg23mZ 9yuO59mqCZXcprb8vUjn2J1Kk9/ArcMi+tFrYI5MTkZLoh6jgBijH4iwolxqahfNOFCo RyPHWUWeKBpW+C/lPO4okEY4rPg8srUvhiVNBMzKlNalfTGdr3pwVvxF8NNI0Sg8vVU6 rWAF0/aQJJ9VfBpDCmUt9/O93vygpJ/hWHeRyhKveDd7mPWV/YSmnt/Qgk4vG53BVZxy vlHw== 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=Awnl11+KEjCpLZ0aM6XDycx/Qf4VwTD1X7eJLTb7gpA=; b=lQ5ZgDyz2NnmW+PdAffm6YgTySPRflRCFsVPIiMUiU3760DHSR2znEw1vCT/BBw54V 0gIvtHdQ8hmGWguHa4ucc00NBGwC8m792kq2vDpubj7+38DL3MSDBRbwGfyvp9Qe344O 8qDQGk17hF1lyCiFf1rYs52Dp3qVLxoqifpD1vLS8p9dnEiuNpNZTgyQZ7wncBtOm4sW 0+7hzdbaSDNsu2PuNdOx8+6s8gr5NpQCkKl0AUqEHFsBaCzYPWXD3b8YHYlvte4IHDwI 1I+2b92DWlL45WMZfBMjLhflBMICteFlxl4WUfjr83e2kSQjHweNGPtEvh+IUtRTt4+p EdGQ== Received: by 10.60.3.99 with SMTP id b3mr25935726oeb.72.1333565104471; Wed, 04 Apr 2012 11:45:04 -0700 (PDT) Received: by 10.60.3.99 with SMTP id b3mr25935708oeb.72.1333565104317; Wed, 04 Apr 2012 11:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.27.97 with HTTP; Wed, 4 Apr 2012 11:44:34 -0700 (PDT) In-Reply-To: <4F7B435B.6030205@librevideo.org> References: <4F7B435B.6030205@librevideo.org> From: Serge Lachapelle Date: Wed, 4 Apr 2012 20:44:34 +0200 Message-ID: To: Basil Mohamed Gohar Content-Type: multipart/alternative; boundary=e89a8f503c5853e33204bcded2d8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnOCED3VmZG8XR7MYp4Hpc1wvoxqph2xyirspfXbxQcq/NjahVjXZEfsE38bzmXbT0rYCs/ok9wSsUG3WiJzfaFvgcPT4ZJBmzC1OsU7cJnmt6YADQuWblz5l4BWmEbGR8hi1Bo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 04 Apr 2012 18:45:06 -0000 --e89a8f503c5853e33204bcded2d8 Content-Type: text/plain; charset=ISO-8859-1 Thank you for your feedback Basil. Google posted this as a result: http://www.webmproject.org/about/faq/#does-the-vp8-patent-grant-also-extend-to-hardware-implementations /Serge On Tue, Apr 3, 2012 at 20:37, Basil Mohamed Gohar wrote: > Serge, > > Thank you very much for this. To go a step forward, I would encourage > that this be made more legally obvious, because a reference to a single > e-mail on an "obscure" mailing list (relative to what most people are > familiar with) will not provide the deepest levels of assurance to those > not actively involved with the WebRTC project. > > I would humbly request an unambiguous statement somewhere on the WebM > project website that makes this assertion clear, because what is > publicly available is, at the very least, ambiguous, and at the worst, > "evidence of Google's nefarious scheme to pounce on hardware > implementers after wide adoption". > > On 04/03/2012 01:54 PM, Serge Lachapelle wrote: > > *[Forking the thread]* > > * > > > > > > * > > *Hello folks,* > > > > Google confirms that the VP8 patent grant applies to both third-party > > hardware and software implementations of VP8. > > * > > * > > *Google encourages the community to create hardware implementations of > > VP8, and has recently blogged about a number of new hardware > > implementations on the WebM blog ( > > > http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware.html > > ). * > > * > > * > > *Google is quite proud of what the community has done with VP8 and > > looks forward to seeing more implementations of VP8 in both hardware > > and software. * > > * > > * > > *Regards,* > > * > > * > > */Serge Lachapelle, > > Google, Stockholm* > > > > On Thu, Mar 29, 2012 at 16:53, Stephan Wenger > > wrote: > > > > > > > > On 3.29.2012 16:24 , "Basil Mohamed Gohar" > > > > > wrote: > > > > >On 03/29/2012 10:20 AM, Stephan Wenger wrote: > > >> The second part of your sentence may or may not be true, > > depending on > > >>your > > >> relationship with google, your willingness to use the webm > > >>implementation > > >> in unchanged form, and other factors. Please see the webm license > > >> conditions, which AFAIK can be found here: > > >> http://www.webmproject.org/license/additional/ > > >Correct. I think you are referring to this part, explicitly: > > >> If you or your agent or exclusive licensee institute or order > > or agree > > >> to the institution of patent litigation against any entity > > (including > > >> a cross-claim or counterclaim in a lawsuit) alleging that this > > >> implementation of VP8 or any code incorporated within this > > >> implementation of VP8 constitutes direct or contributory patent > > >> infringement, or inducement of patent infringement, then any > patent > > >> rights granted to you under this License for this implementation > of > > >> VP8 shall terminate as of the date such litigation is filed. > > >Perhaps I assumed that that is a very reasonable part of the > license. > > >That is, if you are suing someone alleging a patent infringement > > within > > >VP8, you are no longer granted the license to use VP8's patented > > >technologies that Google owns. > > > > Yes, that's one issue. Call it personal preference for different > > type of > > reciprocity conditions :-) (I could rant about it for hours, but > > let's > > continue to pretend that this is mostly a technical mailing list) > > > > The other issue, though (the fact that the license grant extends > > only to > > the VP8 implementation as provided by google, and does not extent to > > derivative works such as hardware implementations) should be > > moderately > > alarming even for an open source person. With respect to this > > clause, I > > will note that I criticized the licensing conditions in private and > in > > public (IETF mike) several times, months ago, and nothing happened. > > Suggests to me one of three things: (1) google is a large company and > > decisions take time, or (2) google's legal is currently occupied with > > other stuff, or (3) that the choice of language is intentional, and > > intended to prevent forks. Take your pick. > > Stephan > > > > >_______________________________________________ > > >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 > > 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. > > > > > > > > > > -- > > Serge Lachapelle | Product Manager | sergel@google.com > > | +46 732 01 22 32 > > > > > > -- > > 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. > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Libre Video > http://librevideo.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. --e89a8f503c5853e33204bcded2d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for your feedback Basil. Google posted this as a result:

=

/Serge

On Tue, A= pr 3, 2012 at 20:37, Basil Mohamed Gohar <basilgohar@librevideo.org> w= rote:
Serge,

Thank you very much for this. =A0To go a step forward, I would encourage that this be made more legally obvious, because a reference to a single
e-mail on an "obscure" mailing list (relative to what most people= are
familiar with) will not provide the deepest levels of assurance to those not actively involved with the WebRTC project.

I would humbly request an unambiguous statement somewhere on the WebM
project website that makes this assertion clear, because what is
publicly available is, at the very least, ambiguous, and at the worst,
"evidence of Google's nefarious scheme to pounce on hardware
implementers after wide adoption".

On 04/03/2012 01:54 PM, Serge Lachapelle wrote:
> *[Forking the thread]*
> *
>
>
> *
> *Hello folks,*
>
> Google confirms that the VP8 patent grant applies to both third-party<= br> > hardware and software implementations of VP8.
> *
> *
> *Google encourages the community to create hardware implementations of=
> VP8, and has recently blogged about a number of new = hardware
> implementations on the WebM blog (
> http://blog.webmproject.org/2012/03/webm= -gaining-momentum-in-hardware.html
> ). *
> *
> *
> *Google is quite proud of what the community has done with VP8 and
> looks forward to seeing more implementations of VP8 = in both hardware
> and software. *
> *
> *
> *Regards,*
> *
> *
> */Serge Lachapelle,
> Google, Stockholm*
>
> On Thu, Mar 29, 2012 at 16:53, Stephan Wenger <stewe@stewe.org
> <mailto:= stewe@stewe.org>> wrote:
>
>
>
> =A0 =A0 On 3.29.2012 16:24 , "Basil Mohamed Gohar"
> =A0 =A0 <basilgo= har@librevideo.org <mailto:basilgohar@librevideo.org>>
> =A0 =A0 wrote:
>
> =A0 =A0 >On 03/29/2012 10:20 AM, Stephan Wenger wrote:
> =A0 =A0 >> The second part of your sentence may or may not be tr= ue,
> =A0 =A0 depending on
> =A0 =A0 >>your
> =A0 =A0 >> relationship with google, your willingness to use the= webm
> =A0 =A0 >>implementation
> =A0 =A0 >> in unchanged form, and other factors. =A0Please see t= he webm license
> =A0 =A0 >> conditions, which AFAIK can be found here:
> =A0 =A0 >> http://www.webmproject.org/license/additional/<= br> > =A0 =A0 >Correct. =A0I think you are referring to this part, explic= itly:
> =A0 =A0 >> If you or your agent or exclusive licensee institute = or order
> =A0 =A0 or agree
> =A0 =A0 >> to the institution of patent litigation against any e= ntity
> =A0 =A0 (including
> =A0 =A0 >> a cross-claim or counterclaim in a lawsuit) alleging = that this
> =A0 =A0 >> implementation of VP8 or any code incorporated within= this
> =A0 =A0 >> implementation of VP8 constitutes direct or contribut= ory patent
> =A0 =A0 >> infringement, or inducement of patent infringement, t= hen any patent
> =A0 =A0 >> rights granted to you under this License for this imp= lementation of
> =A0 =A0 >> VP8 shall terminate as of the date such litigation is= filed.
> =A0 =A0 >Perhaps I assumed that that is a very reasonable part of t= he license.
> =A0 =A0 >That is, if you are suing someone alleging a patent infrin= gement
> =A0 =A0 within
> =A0 =A0 >VP8, you are no longer granted the license to use VP8'= s patented
> =A0 =A0 >technologies that Google owns.
>
> =A0 =A0 Yes, that's one issue. =A0Call it personal preference for = different
> =A0 =A0 type of
> =A0 =A0 reciprocity conditions :-) =A0(I could rant about it for hours= , but
> =A0 =A0 let's
> =A0 =A0 continue to pretend that this is mostly a technical mailing li= st)
>
> =A0 =A0 The other issue, though (the fact that the license grant exten= ds
> =A0 =A0 only to
> =A0 =A0 the VP8 implementation as provided by google, and does not ext= ent to
> =A0 =A0 derivative works such as hardware implementations) should be > =A0 =A0 moderately
> =A0 =A0 alarming even for an open source person. =A0With respect to th= is
> =A0 =A0 clause, I
> =A0 =A0 will note that I criticized the licensing conditions in privat= e and in
> =A0 =A0 public (IETF mike) several times, months ago, and nothing happ= ened.
> =A0 =A0 Suggests to me one of three things: (1) google is a large comp= any and
> =A0 =A0 decisions take time, or (2) google's legal is currently oc= cupied with
> =A0 =A0 other stuff, or (3) that the choice of language is intentional= , and
> =A0 =A0 intended to prevent forks. =A0Take your pick.
> =A0 =A0 Stephan
>
> =A0 =A0 >_______________________________________________
> =A0 =A0 >rtcweb mailing list
> =A0 =A0 >rtcweb@ietf= .org <mailto:rtcweb@ietf.org&= gt;
> =A0 =A0 >https://www.ietf.org/mailman/listinfo/rt= cweb
> =A0 =A0 >
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 rtcweb mailing list
> =A0 =A0 rtcweb@ietf.org &= lt;mailto:rtcweb@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/rtcweb=
> =A0 =A0 Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr.=
> =A0 =A0 556656-6880
>
> =A0 =A0 Apparently, this footer is required in Europe. Apologies. This=
> =A0 =A0 email may be confidential or privileged. =A0If you received th= is
> =A0 =A0 communication by mistake, please don't forward it to anyon= e
> =A0 =A0 else,please erase all copies and attachments, and please let m= e
> =A0 =A0 know that it went to the wrong person. =A0Thanks.
> =A0 =A0 <https://www.ietf.org/mailman/listinfo/rtcweb>=
>
>
>
> --
> Serge Lachapelle | Product Manager | sergel@google.com
> <mailto:sergel@google.co= m> | +46 732 01 22 32
>
>
> --
> Serge Lachapelle | Product Manager | sergel@google.com
> <mailto:sergel@google.co= m> | +46 732 01 22 32
> Google Sweden AB | Kungsbron 2, SE-111 22 Sto= ckholm | Org. nr.
> 556656-6880
>
> Apparently, this footer is required in Europe. Apologies. This email > may be confidential or privileged. =A0If you received this communicati= on
> by mistake, please don't forward it to anyone else,please erase al= l
> copies and attachments, and please let me know that it went to the
> wrong person. =A0Thanks.
>
>
> _______________________________________= ________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--
Libre Video
http://librevideo.org

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



--
=
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.
--e89a8f503c5853e33204bcded2d8-- From basilgohar@librevideo.org Wed Apr 4 11:53: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 95DEA11E80C4 for ; Wed, 4 Apr 2012 11:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, J_CHICKENPOX_46=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 aW9ov6wxp0uH for ; Wed, 4 Apr 2012 11:53:49 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8796011E80C1 for ; Wed, 4 Apr 2012 11:53:49 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 7B60D641F7E for ; Wed, 4 Apr 2012 14:53:48 -0400 (EDT) Message-ID: <4F7C98B8.6050104@librevideo.org> Date: Wed, 04 Apr 2012 14:53:44 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7B435B.6030205@librevideo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 04 Apr 2012 18:53:50 -0000 Serge, Thank you very much for this much-needed, public clarification. Just one more bit of FUD knocked down! -- Libre Video http://librevideo.org On 04/04/2012 02:44 PM, Serge Lachapelle wrote: > Thank you for your feedback Basil. Google posted this as a result: > > http://www.webmproject.org/about/faq/#does-the-vp8-patent-grant-also-extend-to-hardware-implementations > > /Serge > > On Tue, Apr 3, 2012 at 20:37, Basil Mohamed Gohar > > wrote: > > Serge, > > Thank you very much for this. To go a step forward, I would encourage > that this be made more legally obvious, because a reference to a > single > e-mail on an "obscure" mailing list (relative to what most people are > familiar with) will not provide the deepest levels of assurance to > those > not actively involved with the WebRTC project. > > I would humbly request an unambiguous statement somewhere on the WebM > project website that makes this assertion clear, because what is > publicly available is, at the very least, ambiguous, and at the worst, > "evidence of Google's nefarious scheme to pounce on hardware > implementers after wide adoption". > > On 04/03/2012 01:54 PM, Serge Lachapelle wrote: > > *[Forking the thread]* > > * > > > > > > * > > *Hello folks,* > > > > Google confirms that the VP8 patent grant applies to both > third-party > > hardware and software implementations of VP8. > > * > > * > > *Google encourages the community to create hardware > implementations of > > VP8, and has recently blogged about a number of new hardware > > implementations on the WebM blog ( > > > http://blog.webmproject.org/2012/03/webm-gaining-momentum-in-hardware.html > > ). * > > * > > * > > *Google is quite proud of what the community has done with VP8 and > > looks forward to seeing more implementations of VP8 in both hardware > > and software. * > > * > > * > > *Regards,* > > * > > * > > */Serge Lachapelle, > > Google, Stockholm* > > > > On Thu, Mar 29, 2012 at 16:53, Stephan Wenger > > >> wrote: > > > > > > > > On 3.29.2012 16:24 , "Basil Mohamed Gohar" > > > >> > > wrote: > > > > >On 03/29/2012 10:20 AM, Stephan Wenger wrote: > > >> The second part of your sentence may or may not be true, > > depending on > > >>your > > >> relationship with google, your willingness to use the webm > > >>implementation > > >> in unchanged form, and other factors. Please see the > webm license > > >> conditions, which AFAIK can be found here: > > >> http://www.webmproject.org/license/additional/ > > >Correct. I think you are referring to this part, explicitly: > > >> If you or your agent or exclusive licensee institute or order > > or agree > > >> to the institution of patent litigation against any entity > > (including > > >> a cross-claim or counterclaim in a lawsuit) alleging that > this > > >> implementation of VP8 or any code incorporated within this > > >> implementation of VP8 constitutes direct or contributory > patent > > >> infringement, or inducement of patent infringement, then > any patent > > >> rights granted to you under this License for this > implementation of > > >> VP8 shall terminate as of the date such litigation is filed. > > >Perhaps I assumed that that is a very reasonable part of > the license. > > >That is, if you are suing someone alleging a patent > infringement > > within > > >VP8, you are no longer granted the license to use VP8's > patented > > >technologies that Google owns. > > > > Yes, that's one issue. Call it personal preference for > different > > type of > > reciprocity conditions :-) (I could rant about it for > hours, but > > let's > > continue to pretend that this is mostly a technical mailing > list) > > > > The other issue, though (the fact that the license grant extends > > only to > > the VP8 implementation as provided by google, and does not > extent to > > derivative works such as hardware implementations) should be > > moderately > > alarming even for an open source person. With respect to this > > clause, I > > will note that I criticized the licensing conditions in > private and in > > public (IETF mike) several times, months ago, and nothing > happened. > > Suggests to me one of three things: (1) google is a large > company and > > decisions take time, or (2) google's legal is currently > occupied with > > other stuff, or (3) that the choice of language is > intentional, and > > intended to prevent forks. Take your pick. > > Stephan > > > > >_______________________________________________ > > >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 > > 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. > > > > > > > > > > -- > > Serge Lachapelle | Product Manager | sergel@google.com > > > > | +46 732 > 01 22 32 > > > > > > -- > > 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. > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Libre Video > http://librevideo.org > -- Libre Video http://librevideo.org From harald@alvestrand.no Wed Apr 4 15:08: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 44DB511E80D2 for ; Wed, 4 Apr 2012 15:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 RFLdXZjy7s24 for ; Wed, 4 Apr 2012 15:08:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AD3BF11E80C2 for ; Wed, 4 Apr 2012 15:08:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9466839E151 for ; Thu, 5 Apr 2012 00:08:21 +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 DpF51IXVJLAm for ; Thu, 5 Apr 2012 00:08:20 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BC18B39E082 for ; Thu, 5 Apr 2012 00:08:20 +0200 (CEST) Message-ID: <4F7CC650.9000907@alvestrand.no> Date: Thu, 05 Apr 2012 00:08:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> In-Reply-To: <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 04 Apr 2012 22:08:24 -0000 On 04/04/2012 07:23 AM, Paul E. Jones wrote: > I would have a high degree of confidence that I could identify all H.264 IPR > holders. Question .... how would you do that? I'm genuinely curious. The subject has come up in other discussions, including in ISO in connection with the WebVC and IVC projects. The database in question is an ISO database, not an ITU database, and the format is most un-database-like; it is here: http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/JTC1_Patents_database.html?nodeid=3777806&vernum=-2 From chat2jesse@gmail.com Wed Apr 4 17:42: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 A270F11E80C7 for ; Wed, 4 Apr 2012 17:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_BIZOP=0.7] 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 xPvn0YelLYr8 for ; Wed, 4 Apr 2012 17:42: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 F32CB11E8086 for ; Wed, 4 Apr 2012 17:42:45 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1194186obb.31 for ; Wed, 04 Apr 2012 17:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8pdO80Z3EnItFiJDDg18W01XnD/MX5wZvnhkYvCNyzU=; b=HUXXQ6TDfKv9IFKra5kO/DUD/1YeePW+DXH6fqpAeG0vAy5fe8mLLqk+YK7qr50aVO icyVwH+r8joIVXJt/WTEzG+ax7xZHiLugvnlnHZXuAkPHTTLP9lYQDY8CZDHtQBa4yeZ rCGk7e8fT+6RUlpJWqkG/8V4/RA7FE5zNyQzfXPisub+6g+8lVhjUmkSRR54gtI4EMNe qEUBX4/UnYO0ech4kZ6wXr12vxXzWMfaCEYfuNmqQBpddyTJVy2GZEEz8kDsqP6ksw4w ZVbRUV1Cjjd3POh3HIu0bu2jnufK18sW1/4Ovq0hdS8jgnvnjbp54eFxMxtoDZFsX/FF yzDw== MIME-Version: 1.0 Received: by 10.182.147.99 with SMTP id tj3mr683345obb.40.1333586565631; Wed, 04 Apr 2012 17:42:45 -0700 (PDT) Received: by 10.182.60.105 with HTTP; Wed, 4 Apr 2012 17:42:44 -0700 (PDT) Received: by 10.182.60.105 with HTTP; Wed, 4 Apr 2012 17:42:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Apr 2012 17:42:44 -0700 Message-ID: From: jesse To: Roman Shpount Content-Type: multipart/alternative; boundary=f46d044473c9858cff04bce3d1f5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 00:42:46 -0000 --f46d044473c9858cff04bce3d1f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 4, 2012 10:24 AM, "Roman Shpount" wrote: > > On Wed, Apr 4, 2012 at 12:43 PM, I=F1aki Baz Castillo wro= te: >> >> Hi, nobody cares about the implications of option 2 ??? >> >> Do all the people planning to interop with SIP assume that they'll >> need the super B2BUA in the second image (without the possibility of >> using a pure SIP proxy)?: >> >> http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png >> > > I guess we should look at this as a business opportunity ;) I am not sure why you assume that building such gateway would take 10 years. I can sell a gateway like this to anybody who needs it right now. > > My assumption is that IP phones will migrate to WebRTC effectively eliminating SIP in end user devices. That is your academic assumption, why does IT department need to spend extra money to either desert or upgrade its existing SIP devices without substantial gain? After all, tons of users are still using window xp. Backward capability is a key to the success of new technology. -Jesse The only place where SIP will remain would be federation, which commonly uses some sort of SBC anyway. This SBC will need to be extended to support ICE anyway. Might as well through in support for DTLS-EKV-SRTP. I doubt it will map DTLS key updates to re-invites. Most probably it will simply re-encode. > > ______________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d044473c9858cff04bce3d1f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 4, 2012 10:24 AM, "Roman Shpount" <roman@telurix.com> wrote:
>
> On Wed, Apr 4, 2012 at 12:43 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
>>
>> Hi, nobody cares about the implications of option 2 ???
>>
>> Do all the people planning to interop with SIP assume that they= 9;ll
>> need the super B2BUA in the second image (without the possibility = of
>> using a pure SIP proxy)?:
>>
>> =A0http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT= -SRTP.png
>>
>
> <sarcasm>I guess we should look at this as a business opportunit= y ;) I am not sure why you assume that building such gateway would take 10 = years. I can sell a gateway like this to anybody who needs it right now.<= ;/sarcasm>
>
> My assumption is that IP phones will migrate to WebRTC effectively eli= minating SIP in end user devices.

That is your academic assumption, why does IT department need to spend e= xtra money to either desert or upgrade its existing SIP devices without sub= stantial gain? After all, tons of users are still using window xp.

Backward capability is a key to the success of new technology.

-Jesse

The only place where SIP will remain would be federation, which commonl= y uses some sort of SBC anyway. This SBC will need to be extended to suppor= t ICE anyway. Might as well through in support for DTLS-EKV-SRTP. I doubt i= t will map DTLS key updates to re-invites. Most probably it will simply re-= encode.
> =A0
> ______________
> Roman Shpount
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--f46d044473c9858cff04bce3d1f5-- From roman@telurix.com Wed Apr 4 19:14: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 59A8A11E8073 for ; Wed, 4 Apr 2012 19:14:08 -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.158, 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 3z+2fb08VCFS for ; Wed, 4 Apr 2012 19:14:06 -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 7F76121F851D for ; Wed, 4 Apr 2012 19:14:05 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so898701pbb.31 for ; Wed, 04 Apr 2012 19:14:05 -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=5QqjEZV0EHx3dAUaUfS5SfpZiLNYRRe9G9OeH1GxH8s=; b=Ql1JgneA2rAIQzH+gVjFuxKKTbUvff5EWVXIYh1WV7L39ThfakTE3FYfczN7gvOlle Gxn1ytm8Sl7gWd7H3NWXB95HyGSwg3DyYWMKepcwhsjBhYMBMXk2/dLDwcklSE6t0jtw wXIDhoxgCKaXJTU6NbFJ+DHPH0lMdiV1jIYNpl/4sGzZBS7rjhy1qUsR1+T0bx5/B+cm 2mSyHNWoDzJR4H4t7Hp6S1Q+yG3ujP6SwTobPxyS+ZW7NFb5ZZOfuCkUQKP5D/b6XypT XATxs2xLZ6XXxvHzsKV5cYmqW/1+Ljcnw7GSK2j+zIoN4IEnH2c64pI0zPisBhLT9N3S gNaA== Received: by 10.68.196.138 with SMTP id im10mr2486973pbc.156.1333592045130; Wed, 04 Apr 2012 19:14:05 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id d2sm1848659pbw.39.2012.04.04.19.14.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 19:14:04 -0700 (PDT) Received: by dady13 with SMTP id y13so1355238dad.27 for ; Wed, 04 Apr 2012 19:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.231.138 with SMTP id tg10mr2398497pbc.57.1333592042656; Wed, 04 Apr 2012 19:14:02 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Wed, 4 Apr 2012 19:14:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Apr 2012 22:14:02 -0400 Message-ID: From: Roman Shpount To: jesse Content-Type: multipart/alternative; boundary=047d7b339ccffa53d604bce51752 X-Gm-Message-State: ALoCoQn9s13uS9LN/LshEO+np7BOfZpADF6UsYrkXvCQPhVyu/MNZ7jn+fvPAKR+bUKaSNOujjUz Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 02:14:08 -0000 --047d7b339ccffa53d604bce51752 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 4, 2012 at 8:42 PM, jesse wrote: > > On Apr 4, 2012 10:24 AM, "Roman Shpount" wrote: > > > > My assumption is that IP phones will migrate to WebRTC effectively > eliminating SIP in end user devices. > > That is your academic assumption, why does IT department need to spend > extra money to either desert or upgrade its existing SIP devices without > substantial gain? After all, tons of users are still using window xp. > > Backward capability is a key to the success of new technology. > Please note the tags. On the more serious note, very few SIP end points offer working ICE support. So, in a large sense, interop with them is not an option. Out of the ones that do support ICE and SRTP, very few are actually connected directly to a public internet. Most of them are connected to some sort of PBX or an IP PBX type service. So, in reality you do not need to bridge every IP phone with WebRTC. If a few PBX and hosted centrex vendors will add support for WebRTC required features, we will get compatibility with existing end points. To support the rest you will need to deploy some sort of gateway. In my personal opinion, tons of users use XP due to the fact that never MS OS versions do not offer a significant reason to upgrade, while introducing enough usability and operational issues to create a significant upgrade hurdle (I am trying to be politically correct here). WebRTC enabled end points, on the other hand, will offer significant benefits to traditional SIP phones, since they will allow development of higher quality integrated real time communications services. I hope this will drive a much quicker standard adoption. _____________ Roman Shpount --047d7b339ccffa53d604bce51752 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 4, 2012 at 8:42 PM= , jesse <chat2= jesse@gmail.com> wrote:


On Apr 4, 2012 10:24 AM, "Roman Shpount" <roman@telurix.com> wrote:
>
> My assumption is that IP phones will migrate to WebRTC effectively eli= minating SIP in end user devices.

That is your academic assumption, why does IT department need to s= pend extra money to either desert or upgrade its existing SIP devices witho= ut substantial gain? After all, tons of users are still using window xp.

Backward capability is a key to the success of new technology.

Please note the <sarcasm> tags.

On the more seri= ous note, very few SIP end points offer working ICE support. So, in a large= sense, interop with them is not an option. Out of the ones that do support= ICE and SRTP, very few are actually connected directly to a public interne= t. Most of them are connected to some sort of PBX or an IP PBX type service= . So, in reality you do not need to bridge every IP phone with WebRTC. If a= few PBX and hosted centrex vendors will add support for WebRTC required fe= atures, we will get compatibility with existing end points. To support the = rest you will need to deploy some sort of gateway.

In my personal opinion, tons of users use XP due to the fact that never= MS OS versions do not offer a significant reason to upgrade, while introdu= cing enough usability and operational issues to create a significant upgrad= e hurdle (I am trying to be politically correct here). WebRTC enabled end p= oints, on the other hand, will offer significant benefits to traditional SI= P phones, since they will allow development of higher quality integrated re= al time communications services. I hope this will drive a much quicker stan= dard adoption.
_____________
Roman Shpount

--047d7b339ccffa53d604bce51752-- From paulej@packetizer.com Wed Apr 4 23:47: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 F0FAF21F8528 for ; Wed, 4 Apr 2012 23:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 18eq4ltw2Q9c for ; Wed, 4 Apr 2012 23:47:32 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D02EB21F8527 for ; Wed, 4 Apr 2012 23:47:31 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q356lUnn020697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 02:47:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333608451; bh=LUJa39aBw04iL8DJzx+SS/DI5Fx70HLf6x0M4W0jqZk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=huJzdP1e+I/OfOdmG1Num1Tglc3ipZhYNWLyqsiX5TkEl+gbeHn//fYNN/xx98UV2 icIf24dOulDQPrNicmBmT1rGbUcBU1fgcNqgVz/xmZniK121O2dt2wzhDl5e2s5M4L p+bqafdNNs9MBA72upaayFR3Qp75UPiZyVsaLkEw= From: "Paul E. Jones" To: "'Basil Mohamed Gohar'" , References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> In-Reply-To: <4F7C4FB4.4070703@librevideo.org> Date: Thu, 5 Apr 2012 02:47:34 -0400 Message-ID: <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNwB1VzUBAGtdKoUmQL4ToA= Content-Language: en-us Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 05 Apr 2012 06:47:33 -0000 Basil, > What you are asking for is something no one in the media industry offers > for something comparable. I know, but the reluctance to do so means that Google knows that there *may be* IPR on VP8. This is just the facts of life. I believe it's extremely important that people know and understand that nobody knows the IPR situation with VP8. If they did, they would offer indemnity, because there is nothing to worry about, but nobody can. > As was pointed out elsewhere on this list, even > the H.264 standard has been updated to include additional patents over > time deemed to be "essential". One could be non-infringing in the past > and suddenly find yourself infringing. Indeed, but I have a significantly higher level of confidence that I can identify all of the legitimate companies with IPR on H.264, whereas I haven't a clue where to start (outside of Google) for VP8. > I don't know what all of Google's public statements about VP8 IPR status > are, but we know that the patents they own are granted via the license, > and we know that a public call for the formation of a patent pool over a > year ago has yielded not even a follow-up announcement from MPEG-LA. > Furthermore, not a single patent has been brought forward publicly as > being even remotely doubtful as to its application to VP8. If I owned IPR on VP8 (which I don't personally; can't speak for my employer), I certainly would not tell you and I would not join a patent pool, either. I would wait until you adopt VP8, build it into software and hardware products, have it massively deployed, and then I'd come along and collect my royalties. There is absolutely no financial incentive for an IPR holder to join a patent pool. H.264, on the other hand, is different. H.264 was developed jointly by video coding experts in ISO and ITU. As an part of that participation, they are requested to disclose IPR. And, respectable companies will disclose their IPR. Every company participating in that work has a vested interest in the success of H.264. Some are looking for royalties and some are looking for the technology to enable their products. Thus, the formation of the patent pool is in the best interest of all involved so that people will adopt the technology. While there are those not in the pool, they have submitted IPR statements to the ITU. > So, until there is some actual evidence that there is an IPR threat, then > with all due respect, statements such as yours must be classified as > spreading FUD, because they serve to drive adoption away from a free, > open, unencumbered standard to one that is on baseless claims. My statement is intended to spread FUD, but not maliciously; I'm trying to be helpful. You SHOULD be fearful of not only patent trolls, but also legitimate companies who are not obligated to disclose their IPR and who have a vested interest in H.264 and who will take full advantage of their position should VP8 be widely deployed. You SHOULD feel some level of uncertainty about the IPR situation surrounding VP8. And, you SHOULD doubt any claim made that there is no IPR on VP8. While there may be undisclosed IPR on H.264, I find it hard to believe that there would be much, if any, at this point. Keep in mind that H.264 is product of the joint effort of a bunch of people who are experts in the field. I would be suspicious of any company not involved in the development of H.264 claiming to have IPR, because somebody in the joint committee probably owns that IPR. Sure, there might be something ... something very minor. Perhaps. And what if there is something that comes up? Every company participating in the work on H.264 would have a vested interest in disproving the claims, particularly if whomever makes claims refuses to license or tries to demand insane royalties. I could imagine a stream of expert witnesses coming into a courtroom to defend H.264. With no vested interest in VP8, who cares if you get sued for 50% of product revenues? Understand, all of this commentary has nothing to do with the technical merits of VP8 vs. H.264. There are risks with selecting either technology. That said, I personally have a much higher degree of confidence that I will not get sued out of business if I were to select H.264, contact all of the IPR holders registered in the ITU and ISO patent databases, and negotiate a license directly (or via MPEG-LA when possible). I have no degree of confidence whatsoever with VP8, except that Google was kind enough to make its IPR available at no cost. I just don't know who else is out there, and it might be 10 or 15 H.264 patent holders, all with an interest to exercise their rights when the time comes. Paul From paulej@packetizer.com Thu Apr 5 00:15: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 8C56811E80E7 for ; Thu, 5 Apr 2012 00:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 Xjzg7YqNYdUG for ; Thu, 5 Apr 2012 00:15:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6F12011E8079 for ; Thu, 5 Apr 2012 00:15:58 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q357FskX021636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 03:15:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333610155; bh=INv6PQrBz25Ofy6Y4G0EeoaWkXn6Fk/258fKXsrX+60=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XwJdZWqtIHrXdd0rgbuVfHimYcxhhZXhtxG2vAaeKIPZElIv1620PY5XMvNqoacvP PAY/SGKbKzMTYTPMLK7Xwtyg3ZV7bXoiyLX6IEtMAQxioXe5SLGRIYpyYyHI6sPzGD Fo0B147q+e5Iv4pEaKFLPOt+0xcwSFLPDx2xIjOM= From: "Paul E. Jones" To: "'Harald Alvestrand'" , References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7CC650.9000907@alvestrand.no> In-Reply-To: <4F7CC650.9000907@alvestrand.no> Date: Thu, 5 Apr 2012 03:15:58 -0400 Message-ID: <008301cd12fb$f3c8d950$db5a8bf0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNwB1VzUBAH3gTRamQCyxsA= Content-Language: en-us Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 05 Apr 2012 07:15:59 -0000 Harald, > On 04/04/2012 07:23 AM, Paul E. Jones wrote: > > I would have a high degree of confidence that I could identify all > > H.264 IPR holders. > Question .... how would you do that? > I'm genuinely curious. The subject has come up in other discussions, > including in ISO in connection with the WebVC and IVC projects. > > The database in question is an ISO database, not an ITU database, and the > format is most un-database-like; it is here: > > http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/JTC1_Patent > s_database.html?nodeid=3777806&vernum=-2 > ts_database.html?nodeid=3777806&vernum=-2> There are two databases. One with ISO (and you have the link) and the other is ITU: http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS Just enter "H.264" into the box under "Recommendation No" and hit ENTER. There are 327 filed IPR claims. Of course, this is not all of the IPR that may exist, but my point is that it's highly unlikely that more exists from companies not listed given the ITU and ISO's patent policies, participating companies' mutual desire to see the technology succeed, etc. Virtually every concept you can imagine that found its way into H.264 is either prior art or new IPR introduced by participating companies, all of which SHOULD be listed. If a company participated and failed to disclose IPR... that's really bad. Not only would the defendant be unhappy, but said IPR holder might very well be blocked from further participation. Something would be done. And, they might have a tough time arguing in court, knowing they were withholding information and, thus, misleading the defendant who could demonstrate an effort was made to negotiate with all IPR holders. If I were a judge, I would not take kindly to such subversive, destructive behavior in an standards organization. That leaves only patent trolls who did not participate in the H.264 work. There is little we can do with such entities who, quite likely, never invented anything in H.264, but have a patent worded just well enough to give the illusion that they invented something in the standard. This is an unfortunate reality in our world with all technology. Now, as I look at the 327 patents filed on H.264 (in the ITU database alone), I'm left wondering... nobody in the whole world has even one on VP8 outside of On2 / Google? I'd bet there are. I personally would not want to take the risk, but that's me. Paul From ibc@aliax.net Thu Apr 5 02:04: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 0550621F85D4 for ; Thu, 5 Apr 2012 02:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_39=0.6, 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 EJfTnTGEBgAx for ; Thu, 5 Apr 2012 02:04:43 -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 D027921F8709 for ; Thu, 5 Apr 2012 02:04:37 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1006522vbb.31 for ; Thu, 05 Apr 2012 02:04: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=Fsb1O7M5sF/GK3BM+29KYZUJa7ETIDR4L8mvebJ2e8Q=; b=VT0MfgVKLWCRsPrRbBxCDkD9l0EjdSPqZbPeGBZ0iH6NZG7qSbKyxqRjC0toTsObAg 8xA5m+Ln20TbGsJWdgZWVus+qnMqvD8XDwLvJ5DmzvYHOVwGeeMCrv0vwp3q0nbrpdna I7PJ0OSMqli8wu5mqmdcpK81qV0ca3kAVxEp32F2jqpHsJYVBOyskby5VAOH1xnfda6N NdMU9d5mITjb1S+Uvt+lDRfApzDKQJXOCLLsgqYbINhCsu2ADkF9AoeAGFhGt7kK2Y8l zrJGVLUqvty4wg2O9ECDxvTWLTu1F+eVmSm1Vgf49Le1DYNnnjggH9vqTGKks5LmwIvi Volw== Received: by 10.52.94.233 with SMTP id df9mr1073040vdb.119.1333616677202; Thu, 05 Apr 2012 02:04:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 02:04:17 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 11:04:17 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnC1+t2BTaMNsfgcO4ncXx5wJYrScbUHoWKneid0Vdr2vn43P50x0f0yIPOnBcugx5I1jso Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 09:04:44 -0000 2012/4/5 Roman Shpount : > On the more serious note, very few SIP end points offer working ICE suppo= rt. > So, in a large sense, interop with them is not an option. For me there is a BIG difference when a kind of B2BUA is required (which involves signaling "transaction"). That's the barrier IMHO. ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see: http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png The problem arises when media encrypt/decrypt is required, and evenr more when a key update in RTP (like the DTLS EKT update) must be converted into a signaling re-INVITE by a super Signaling+Media B2BUA: http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png > Out of the ones > that do support ICE and SRTP, very few are actually connected directly to= a > public internet. Most of them are connected to some sort of PBX or an IP = PBX > type service. So, in reality you do not need to bridge every IP phone wit= h > WebRTC. That is a *very* limited scope of what WebRTC can provide. An IT department should be able to deploy its own WebRTC infrastructure (a Web+WebSocket server) within its "local" network, so browsers accessing to such a local website share the network with SIP/XMPP phones/devices/softphones. Please don't imagine WebRTC and SIP interop as the communication between two islands ;) > If a few PBX and hosted centrex vendors will add support for WebRTC > required features, we will get compatibility with existing end points. Pure SIP proxies do exist. A PBX is not always needed, so again, SIP world does not require to be "an island". > To support the rest you will need to deploy some sort of gateway. Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent mails about SDES and DTLS). > hurdle (I am trying to be politically correct here). WebRTC enabled end > points, on the other hand, will offer significant benefits to traditional > SIP phones, since they will allow development of higher quality integrate= d > real time communications services. I hope this will drive a much quicker > standard adoption. The problem is that there is a *NEW* SRTP related spec for WebRTC: http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-03 Maybe it could also become a standard for SIP? I hope, but currently it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a island. Regards. --=20 I=C3=B1aki Baz Castillo From ron.even.tlv@gmail.com Thu Apr 5 02:11: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 ABE7F21F86A2 for ; Thu, 5 Apr 2012 02:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 yekpbeVK3c+X for ; Thu, 5 Apr 2012 02:11: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 45DA421F8656 for ; Thu, 5 Apr 2012 02:11:17 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so739724wgb.13 for ; Thu, 05 Apr 2012 02:11:16 -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=dEDVm7siMDRzMw71wG9IE/HDYQ4FBxPBq8P1pBcq8eU=; b=K1i7wbAqeszbgN1b2NhhY0mfRoMYa8cJjKoYHCJzcr0/nF3d6Qi6Y/yGmAyIaQgvuw 7mKZeEoKOZ9IdvtGIUZWyMHx/e1yxMX/jjP8q0b/CwRS/WXQ3QejGVCs9iLeMKp1JTWn xQS3cxdcl5Fn4nj4dJuFwPdyK3b0taldKgDnwGsXVhLOBqKRzGql4hpI+ImNs9nllklW 3hY1VGoRW+IboYmwXrrh9qsSKnhTGz+HKd4XhBP6JhRXb8kbJmzMgTGfpIpWUq3Xym76 Xe1+FOG+yn/zfPmCNLWI43WBkK/Qljt9dyOoafzKjp5twO9coYcEGtjkXNkOIA/815GR Lwtg== Received: by 10.180.85.69 with SMTP id f5mr2906616wiz.18.1333617076424; Thu, 05 Apr 2012 02:11:16 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id k6sm12035317wie.9.2012.04.05.02.11.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 02:11:15 -0700 (PDT) From: "Roni Even" To: "'Roman Shpount'" , "'jesse'" References: In-Reply-To: Date: Thu, 5 Apr 2012 12:09:50 +0300 Message-ID: <4f7d61b3.2614b40a.09b2.ffffa149@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01CD1325.01F65150" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0S0c7D4fm9hja5TUimMgrQ+AzougAOOveA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 09:11:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01CD1325.01F65150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I think that your point of view about IP PBX that need to support RTCweb is interesting but the problem is that RTCweb is not the application, it is an enabler, so you may see multiple applications servers that will offer communication services (like Skype, MS Messenger, Google), so I am wondering if the IP PBX will need to peer with all of them or will the application servers peer with the IP PBXs using SIP as was proposed in RTCweb. Roni Even From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount Sent: Thursday, April 05, 2012 5:14 AM To: jesse Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need On Wed, Apr 4, 2012 at 8:42 PM, jesse wrote: On Apr 4, 2012 10:24 AM, "Roman Shpount" wrote: > > My assumption is that IP phones will migrate to WebRTC effectively eliminating SIP in end user devices. That is your academic assumption, why does IT department need to spend extra money to either desert or upgrade its existing SIP devices without substantial gain? After all, tons of users are still using window xp. Backward capability is a key to the success of new technology. Please note the tags. On the more serious note, very few SIP end points offer working ICE support. So, in a large sense, interop with them is not an option. Out of the ones that do support ICE and SRTP, very few are actually connected directly to a public internet. Most of them are connected to some sort of PBX or an IP PBX type service. So, in reality you do not need to bridge every IP phone with WebRTC. If a few PBX and hosted centrex vendors will add support for WebRTC required features, we will get compatibility with existing end points. To support the rest you will need to deploy some sort of gateway. In my personal opinion, tons of users use XP due to the fact that never MS OS versions do not offer a significant reason to upgrade, while introducing enough usability and operational issues to create a significant upgrade hurdle (I am trying to be politically correct here). WebRTC enabled end points, on the other hand, will offer significant benefits to traditional SIP phones, since they will allow development of higher quality integrated real time communications services. I hope this will drive a much quicker standard adoption. _____________ Roman Shpount ------=_NextPart_000_00D8_01CD1325.01F65150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I think that your point of view about IP PBX that need to support = RTCweb is interesting but the problem is that RTCweb is not the = application, it is an enabler, so you may see multiple applications = servers that will offer communication services (like Skype, MS = Messenger, Google), so I am wondering if the IP PBX will need to peer = with all of them or will the application servers peer with the IP PBXs = using SIP as was proposed in RTCweb.

Roni Even

 

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Thursday, April 05, 2012 5:14 = AM
To: jesse
Cc: rtcweb@ietf.org
Subject: = Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a = need

 


On Wed, Apr 4, 2012 = at 8:42 PM, jesse <chat2jesse@gmail.com> = wrote:


On Apr 4, 2012 10:24 AM, "Roman = Shpount" <roman@telurix.com> wrote:
>
> My = assumption is that IP phones will migrate to WebRTC effectively = eliminating SIP in end user devices.

That is your = academic assumption, why does IT department need to spend extra money to = either desert or upgrade its existing SIP devices without substantial = gain? After all, tons of users are still using window = xp.

Backward capability is a key to the success of new = technology.

Please note the <sarcasm> tags. =

On the more serious note, very few SIP end points offer working = ICE support. So, in a large sense, interop with them is not an option. = Out of the ones that do support ICE and SRTP, very few are actually = connected directly to a public internet. Most of them are connected to = some sort of PBX or an IP PBX type service. So, in reality you do not = need to bridge every IP phone with WebRTC. If a few PBX and hosted = centrex vendors will add support for WebRTC required features, we will = get compatibility with existing end points. To support the rest you will = need to deploy some sort of gateway.

In my personal opinion, tons = of users use XP due to the fact that never MS OS versions do not offer a = significant reason to upgrade, while introducing enough usability and = operational issues to create a significant upgrade hurdle (I am trying = to be politically correct here). WebRTC enabled end points, on the other = hand, will offer significant benefits to traditional SIP phones, since = they will allow development of higher quality integrated real time = communications services. I hope this will drive a much quicker standard = adoption.
_____________
Roman = Shpount

------=_NextPart_000_00D8_01CD1325.01F65150-- From ibc@aliax.net Thu Apr 5 02:19: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 626DD21F86D3 for ; Thu, 5 Apr 2012 02:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=0.074, 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 g8TkPW0sVYG1 for ; Thu, 5 Apr 2012 02:19:02 -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 BFCB921F869D for ; Thu, 5 Apr 2012 02:19:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1012334vbb.31 for ; Thu, 05 Apr 2012 02:19:01 -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=5ErYzDs78SJk7b0ra4FD/G8V31QvGhuMtU6bfaqpGHU=; b=RgBcWouthnCI46wqL7VhXCkQAnE8AF7uojJC+/DZg/9uugQHwt8+BcXUKl+fn7lc7Z hW/C0jnHNS0fpk0pHbDMSzY4vC83clOoqeq/NREloTGJkE/e+qMGnU6zdSChpiakRYlU +2nDS+Dnbe0dFjP7lBlGqH2HpESwGwUVH5+IiDLLnl4rgvxIJFeWAEaUmYCz7TAmF5lS lxU5jUadmoFC/L+eotfObtmEDB/4K6N+/YCMVJg2gURkcpE+G7JRoO1TmGiF8Vsu9EYl TplhsoN7KGp+ExJA1wwgYHFQtBG1R4CaJcliJE5/x7D5o3/cFIRcfHsZcPM0t9vEEo6Y e9IA== Received: by 10.52.94.233 with SMTP id df9mr1095252vdb.119.1333617541213; Thu, 05 Apr 2012 02:19:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 02:18:40 -0700 (PDT) In-Reply-To: <4f7d61b3.2614b40a.09b2.ffffa149@mx.google.com> References: <4f7d61b3.2614b40a.09b2.ffffa149@mx.google.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 11:18:40 +0200 Message-ID: To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQno7UIuaCeeCt7kZQV7q0fKtdtz30djFfpV2g1EtghkE6yH9TIVR0IA2wn2KqdZyfhyz9zd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 09:19:02 -0000 2012/4/5 Roni Even : > so I am wondering if the IP PBX will need to peer with all of them or wil= l > the application servers peer with the IP PBXs using SIP as was proposed i= n > RTCweb. You don't need to make a web browser to talk SIP (UDP/TCP/TLS) in order to interop with a SIP network. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Thu Apr 5 02:55: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 5255C21F8709 for ; Thu, 5 Apr 2012 02:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-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 s0WqWmwbpR+3 for ; Thu, 5 Apr 2012 02:55:40 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id E34E021F8701 for ; Thu, 5 Apr 2012 02:55:39 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT31sG/sk3AHV2pGSSfO6SiWaKZzyGJOC@postini.com; Thu, 05 Apr 2012 02:55:40 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Apr 2012 05:56:03 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 5 Apr 2012 15:25:33 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount Thread-Topic: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need Thread-Index: AQHNEZuczUxvY8zq3kSCmeoWT7GsQ5aKhMuAgAALa4CAAHpmAIAAGYIAgAByn4CAAGfrAA== Date: Thu, 5 Apr 2012 09:55:58 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2251F8@inba-mail01.sonusnet.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.70.54.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 09:55:41 -0000 SU1ITywgdGhlcmUgaXMgbm8gbmVlZCB0byB0d2VhayBXZWJSVEMgcmVjb21tZW5kYXRpb24gZm9y IHRoZSBzYWtlIG9mIFNJUCBwcm94eS4gSSdtIGZpbmUgYXMgbG9uZyBhcyB0aGVyZSBpcyBhIHdh eSBpbiBXZWJSVEMgdG8gaW50ZXJvcCB3aXRoIFNJUC4gRm9yIGV4YW1wbGUsIFNJUCBwcm94eSBp cyBub3Qgc3VpdGFibGUgZm9yIElFVEYgU0lQUkVDIHJlY29yZGluZyBpbXBsZW1lbnRhdGlvbiBp dHNlbGYhISENCg0KQnV0IEknbSBhbHNvIHN1cnByaXNlZCB0byBzZWUgdGhhdCB0aGVyZSBpcyBu byByZXNwb25zZSBmb3IgRmFiaW8gUGlldHJvc2FudGkgbWFpbCBvbiBEVExTLVNSVFAgdHJ1c3Qg bW9kZWwgbWFpbCB0aHJlYWQuDQoNClRoYW5rcw0KUGFydGhhIA0KDQo+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj5Gcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBJw7Fha2kgQmF6IENhc3RpbGxvDQo+ U2VudDogVGh1cnNkYXksIEFwcmlsIDA1LCAyMDEyIDI6MzQgUE0NCj5UbzogUm9tYW4gU2hwb3Vu dA0KPkNjOiBydGN3ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2ViUlRDLVNJ UCBpbnRlcm9wOiBhbmQgd2h5IFNERVMtU1JUUCBpcyBhIG5lZWQNCj4NCj4yMDEyLzQvNSBSb21h biBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT46DQo+PiBPbiB0aGUgbW9yZSBzZXJpb3VzIG5v dGUsIHZlcnkgZmV3IFNJUCBlbmQgcG9pbnRzIG9mZmVyIHdvcmtpbmcgSUNFDQo+c3VwcG9ydC4N Cj4+IFNvLCBpbiBhIGxhcmdlIHNlbnNlLCBpbnRlcm9wIHdpdGggdGhlbSBpcyBub3QgYW4gb3B0 aW9uLg0KPg0KPkZvciBtZSB0aGVyZSBpcyBhIEJJRyBkaWZmZXJlbmNlIHdoZW4gYSBraW5kIG9m IEIyQlVBIGlzIHJlcXVpcmVkICh3aGljaA0KPmludm9sdmVzIHNpZ25hbGluZyAidHJhbnNhY3Rp b24iKS4gVGhhdCdzIHRoZSBiYXJyaWVyIElNSE8uDQo+DQo+SUNFIHN1cHBvcnQgY2FuIGJlIGlt cGxlbWVudGVkIGluIGEgSUNFLUxpdGUgUlRQL1NSVFAgcHJveHksIHNlZToNCj4NCj4gIGh0dHA6 Ly9wdWJsaWMuYWxpYXgubmV0L1dlYlJUQy9XZWJSVENfU0lQX0ludGVyb3BfU0RFUy1TUlRQLnBu Zw0KPg0KPlRoZSBwcm9ibGVtIGFyaXNlcyB3aGVuIG1lZGlhIGVuY3J5cHQvZGVjcnlwdCBpcyBy ZXF1aXJlZCwgYW5kIGV2ZW5yDQo+bW9yZSB3aGVuIGEga2V5IHVwZGF0ZSBpbiBSVFAgKGxpa2Ug dGhlIERUTFMgRUtUIHVwZGF0ZSkgbXVzdCBiZQ0KPmNvbnZlcnRlZCBpbnRvIGEgc2lnbmFsaW5n IHJlLUlOVklURSBieSBhIHN1cGVyIFNpZ25hbGluZytNZWRpYSBCMkJVQToNCj4NCj4gIGh0dHA6 Ly9wdWJsaWMuYWxpYXgubmV0L1dlYlJUQy9XZWJSVENfU0lQX0ludGVyb3BfRFRMUy1FS1QtU1JU UC5wbmcNCj4NCj4NCj4NCj4+IE91dCBvZiB0aGUgb25lcw0KPj4gdGhhdCBkbyBzdXBwb3J0IElD RSBhbmQgU1JUUCwgdmVyeSBmZXcgYXJlIGFjdHVhbGx5IGNvbm5lY3RlZCBkaXJlY3RseQ0KPj4g dG8gYSBwdWJsaWMgaW50ZXJuZXQuIE1vc3Qgb2YgdGhlbSBhcmUgY29ubmVjdGVkIHRvIHNvbWUg c29ydCBvZiBQQlgNCj4+IG9yIGFuIElQIFBCWCB0eXBlIHNlcnZpY2UuIFNvLCBpbiByZWFsaXR5 IHlvdSBkbyBub3QgbmVlZCB0byBicmlkZ2UNCj4+IGV2ZXJ5IElQIHBob25lIHdpdGggV2ViUlRD Lg0KPg0KPlRoYXQgaXMgYSAqdmVyeSogbGltaXRlZCBzY29wZSBvZiB3aGF0IFdlYlJUQyBjYW4g cHJvdmlkZS4gQW4gSVQNCj5kZXBhcnRtZW50IHNob3VsZCBiZSBhYmxlIHRvIGRlcGxveSBpdHMg b3duIFdlYlJUQyBpbmZyYXN0cnVjdHVyZSAoYQ0KPldlYitXZWJTb2NrZXQgc2VydmVyKSB3aXRo aW4gaXRzICJsb2NhbCIgbmV0d29yaywgc28gYnJvd3NlcnMNCj5hY2Nlc3NpbmcgdG8gc3VjaCBh IGxvY2FsIHdlYnNpdGUgc2hhcmUgdGhlIG5ldHdvcmsgd2l0aCBTSVAvWE1QUA0KPnBob25lcy9k ZXZpY2VzL3NvZnRwaG9uZXMuDQo+DQo+UGxlYXNlIGRvbid0IGltYWdpbmUgV2ViUlRDIGFuZCBT SVAgaW50ZXJvcCBhcyB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuDQo+dHdvIGlzbGFuZHMgOykN Cj4NCj4NCj4NCj4+IElmIGEgZmV3IFBCWCBhbmQgaG9zdGVkIGNlbnRyZXggdmVuZG9ycyB3aWxs IGFkZCBzdXBwb3J0IGZvciBXZWJSVEMNCj4+IHJlcXVpcmVkIGZlYXR1cmVzLCB3ZSB3aWxsIGdl dCBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3RpbmcgZW5kIHBvaW50cy4NCj4NCj5QdXJlIFNJUCBw cm94aWVzIGRvIGV4aXN0LiBBIFBCWCBpcyBub3QgYWx3YXlzIG5lZWRlZCwgc28gYWdhaW4sIFNJ UA0KPndvcmxkIGRvZXMgbm90IHJlcXVpcmUgdG8gYmUgImFuIGlzbGFuZCIuDQo+DQo+DQo+PiBU byBzdXBwb3J0IHRoZSByZXN0IHlvdSB3aWxsIG5lZWQgdG8gZGVwbG95IHNvbWUgc29ydCBvZiBn YXRld2F5Lg0KPg0KPk5vdCBpbiB0aGUgY2FzZSBTREVTK1NSVFAgaXMgYWxsb3dlZCBpbiBXZWJS VEMgKHNlZSBGYWJpdXMncyByZWNlbnQNCj5tYWlscyBhYm91dCBTREVTIGFuZCBEVExTKS4NCj4N Cj4NCj4NCj4+IGh1cmRsZSAoSSBhbSB0cnlpbmcgdG8gYmUgcG9saXRpY2FsbHkgY29ycmVjdCBo ZXJlKS4gV2ViUlRDIGVuYWJsZWQNCj4+IGVuZCBwb2ludHMsIG9uIHRoZSBvdGhlciBoYW5kLCB3 aWxsIG9mZmVyIHNpZ25pZmljYW50IGJlbmVmaXRzIHRvDQo+PiB0cmFkaXRpb25hbCBTSVAgcGhv bmVzLCBzaW5jZSB0aGV5IHdpbGwgYWxsb3cgZGV2ZWxvcG1lbnQgb2YgaGlnaGVyDQo+PiBxdWFs aXR5IGludGVncmF0ZWQgcmVhbCB0aW1lIGNvbW11bmljYXRpb25zIHNlcnZpY2VzLiBJIGhvcGUg dGhpcyB3aWxsDQo+PiBkcml2ZSBhIG11Y2ggcXVpY2tlciBzdGFuZGFyZCBhZG9wdGlvbi4NCj4N Cj5UaGUgcHJvYmxlbSBpcyB0aGF0IHRoZXJlIGlzIGEgKk5FVyogU1JUUCByZWxhdGVkIHNwZWMg Zm9yIFdlYlJUQzoNCj4NCj4gIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt YXZ0LXNydHAtZWt0LTAzDQo+DQo+TWF5YmUgaXQgY291bGQgYWxzbyBiZWNvbWUgYSBzdGFuZGFy ZCBmb3IgU0lQPyBJIGhvcGUsIGJ1dCBjdXJyZW50bHkNCj5pdCdzIG5vdCwgc28gYnkgKm1hbmRh dGluZyogRFRMUy1FS1QtU1JUUCBpbiBXZWJSVEMgd2UgYXJlIGNyZWF0aW5nIGENCj5pc2xhbmQu DQo+DQo+DQo+UmVnYXJkcy4NCj4NCj4NCj4tLQ0KPknDsWFraSBCYXogQ2FzdGlsbG8NCj48aWJj QGFsaWF4Lm5ldD4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From ibc@aliax.net Thu Apr 5 03:03: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 8EBEE21F86D8 for ; Thu, 5 Apr 2012 03:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=0.065, 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 wkr9qOsFVP4Q for ; Thu, 5 Apr 2012 03:03: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 DE5E421F86D1 for ; Thu, 5 Apr 2012 03:03:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1032563vbb.31 for ; Thu, 05 Apr 2012 03:03: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=/FacmTT5EosJuRZ6d9Ta+Admvcl5Ya6CnhmO1dgrzJk=; b=erGAR67BeuBLOdEe4ZX8ScJC+gqS8afwz6KWSbIt2K5CiGhRl/Kygc355u3gxj3G7n I+zh9IOCzjfXdV0ahV/JHwWOV4DTgbC8FXcZEcbQGPL6Vy14zFUZdPeDuaxQf5Ad+v3s sVuN0FXGrhHERbLRhKOASUFlXd745jb2nT1iQR4D8VLigpFDKs7q0x8f6KGlsaf1BVC0 kmL9iTv4/rSdAi+71Y17AtuymWjfsj9HNyK/1wiOMT8VgRnkTFC0yFhptLsB0C1dDFjn C8RQ3AfgxzzhDxpBpSNLeOpdqcJD/3AHHic061vti+pHdv6zdjpzAi2KrmEwPiMBIXKu QDhw== Received: by 10.52.88.4 with SMTP id bc4mr1192218vdb.51.1333620193304; Thu, 05 Apr 2012 03:03:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 03:02:53 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2251F8@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E2251F8@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 12:02:53 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnYKBo3wvZvgrZaNQROULanJkSBiugvwoNuy5b/kubswafQ3I7jaNRT/RXA8kxdzKnzY4Fc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 10:03:14 -0000 2012/4/5 Ravindran, Parthasarathi : > IMHO, there is no need to tweak WebRTC recommendation for the sake of SIP= proxy. I'm fine as long as there is a way in WebRTC to interop with SIP. F= or example, SIP proxy is not suitable for IETF SIPREC recording implementat= ion itself!!! For the cases in which you need recording, ok, go ahead with a SIP SBC/B2BUA/server or whatever you need, but please let using a pure SIP proxy for those not interested in media recording ;) > But I'm also surprised to see that there is no response for Fabio Pietros= anti mail on DTLS-SRTP trust model mail thread. Me too. I hope Fabio's nice explanations will be considered by the WG rather than continuing with "DTLS (which has been NEVER tested with SRTP) is the only magical solution for the multimedia communications". --=20 I=C3=B1aki Baz Castillo From lists@infosecurity.ch Thu Apr 5 03:16: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 ECC3221F864C for ; Thu, 5 Apr 2012 03:16:41 -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 wtKJdmb48qqT for ; Thu, 5 Apr 2012 03:16:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBD7321F8611 for ; Thu, 5 Apr 2012 03:16:40 -0700 (PDT) Received: by eeke51 with SMTP id e51so399425eek.31 for ; Thu, 05 Apr 2012 03:16: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 :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=NNiUgtHXBF8Go5eFrir+5xtNfVJDy8SzC464IgHFBs0=; b=Ki42bYCwZHhObLZfWpCs10DjhXJQECvbmjWdkvScFAhvznRDPeLMOxVuq4vZO2/wF9 Ot2ti3gKAL3+NbK5ZMJcdonGG5N0msm4dcs/gckkFRdS1fCSZPoHhXvPqOUp5g5AVH3s a6l4a89eCvuyFtvv1VQNoQ8vPrHlK8QOmCNAQBpaVj0+VkgYGqWcttyG8kzTlTw2E3Qp 0Ue/DehucfmUUCWBMzlotAR7gGFJlj0MJdlLHc1bMbdmnWSR7AsqwQmzWLf0Sy3aW9lB Fcm96mlwD53ALBTEshQJeYy8h3xmWg8SCz6R9zKYGmzb4Yrz2jgdMCeVX50oc5hWNO63 omzQ== Received: by 10.213.10.196 with SMTP id q4mr344219ebq.294.1333620999466; Thu, 05 Apr 2012 03:16: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 m42sm11573650eef.0.2012.04.05.03.16.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 03:16:38 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7D7103.6040102@infosecurity.ch> Date: Thu, 05 Apr 2012 12:16:35 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkWMLmRYTzn49mYRC7zjFv61ANNgwoDoKF5yTk6CdtRIj2y5zo00AKJGa8GHzZ2iWPrEbI1 Subject: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 10:16:42 -0000 Hi, i've been discussing with several friends about the current discussion on the security standard in this mailing lists, in particular regarding the topic of DTLS-SRTP trust model posted there http://www.ietf.org/mail-archive/web/rtcweb/current/msg04007.html . I found that there is no common definition for the concept of "end-to-end encryption" and there are a lot of misunderstanding about it. In particular, the fact that two peer can community by exchanging keys directly among them, tend to typically to be defined as end-to-end encryption. However the term "end-to-end encryption" have also a general misconception that's something that "no one can intercept" . Unfortunately this is not true for DTLS-SRTP, while for example it's true for OpenPGP/MIME or for ZRTP with SAS. We need to separate the 4 concepts: - end-to-end encryption Ability for a key management system to exchange keys directly without relying on intermediate server actively involved in encryption process. - end-to-end authentication Ability for end-user to authenticate the end-to-end encryption process without the need to rely on a single or multiple set of trusted third parties - end-to-site encryption Ability for a key management system to exchange keys with/trough the server with which data are exchanged, involving it in the authentication process. - end-to-site authentication Ability for end-user to authenticate the end-to-site encryption process based on the same security mechanism used to establish trust with the server with which data are exchanged. What i would like to focus is that: - DTLS does provide end-to-end encryption (in specific context of use) - DTLS does provide end-to-site authentication (rely on third party trust) - ZRTP does provide end-to-end encryption (in all context of use) - ZRTP does provide end-to-end authentication (does not rely on third party trust) - SDES-SRTP does provide end-to-site encryption (encryption with/trough your server) - SDES-SRTP does provide end-to-site authentication (you trust your server involved in key exchange) So when we tend to think about the "how much security a technology provide" we should probably compare in a scale: - ZRTP - end-to-end encryption - end-to-end authentication - DTLS-SRTP - end-to-end encryption - end-to-site authentication - SDES-SRTP - end-to-site encryption - end-to-site authentication So currently we can affirm that: - ZRTP does not rely on third party trust for effective security - DTLS-SRTP rely on third party trust for effective security - SDES-SRTP rely on third party trust for effective security This is the *MOST IMPORTANT* distinction for an encryption technology: WHO SHOULD I TRUST? Well, basically it seems to me that DTLS-SRTP and SDES-SRTP both require So, my point are to: - Introduce SDES-SRTP for compatibility and simplicity - Specify that the Browser will need to provide indicate the security level to the user (like the lock of HTTPS, same security model) - Introduce end-to-end authentication support for DTLS-SRTP via SAS - Specify that the browser will need to to provide the end-user way to use end-to-end authentication and indicate the security level to the user. Then it will be up to the signaling server and/or to the browser settings to specificy the required security model: - end-to-end encryption + end-to-end authentication or - end-to-site encryption + end-to-site authentication But please don't mix those two as it will be *Very difficult, near to impossible* to explain to the user "WHO SHOULD HE TRUST" . Fabio From christer.holmberg@ericsson.com Thu Apr 5 04:14: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 2811D21F872A for ; Thu, 5 Apr 2012 04:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=0.6, 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 XkGs+FeYrZYO for ; Thu, 5 Apr 2012 04:14:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9C82A21F869A for ; Thu, 5 Apr 2012 04:14:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-8a-4f7d7e893645 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 53.3E.25560.98E7D7F4; Thu, 5 Apr 2012 13:14:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 5 Apr 2012 13:14:17 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount Date: Thu, 5 Apr 2012 13:14:17 +0200 Thread-Topic: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need Thread-Index: Ac0TCyYmp6MwdX5GQYiyzCiscN+u/AAEc4jQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42CA74D4@ESESSCMS0356.eemea.ericsson.se> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 11:14:21 -0000 DQo+IFRoZSBwcm9ibGVtIGFyaXNlcyB3aGVuIG1lZGlhIGVuY3J5cHQvZGVjcnlwdCBpcyByZXF1 aXJlZCwgYW5kIGV2ZW5yIG1vcmUgd2hlbiBhIGtleSB1cGRhdGUgaW4gUlRQIChsaWtlIHRoZSBE VExTIEVLVCB1cGRhdGUpIG11c3QgYmUgY29udmVydGVkIGludG8gYSBzaWduYWxpbmcgcmUtSU5W SVRFIGJ5IGEgc3VwZXIgU2lnbmFsaW5nK01lZGlhIEIyQlVBOg0KDQouLi5hbmQsIGluIGdlbmVy YWwgd2Ugc2hvdWxkIG5vdCBzcGVjaWZ5IHByb2NlZHVyZXMgd2hpY2ggcmVxdWlyZSBhbiBpbnRl cm1lZGlhcnkgdG8gdHJpZ2dlciBhbmQgc2VuZCByZS1JTlZJVEVzIGluIHRoZSBmaXJzdCBwbGFj ZSwgYmVjYXVzZSB0aGF0IGl0c2VsZiBjYW4gdGhlbiBjYXVzZSBsb3RzIG9mIGlzc3Vlcy4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KPiBPdXQgb2YgdGhlIG9uZXMNCj4gdGhhdCBk byBzdXBwb3J0IElDRSBhbmQgU1JUUCwgdmVyeSBmZXcgYXJlIGFjdHVhbGx5IGNvbm5lY3RlZCBk aXJlY3RseSANCj4gdG8gYSBwdWJsaWMgaW50ZXJuZXQuIE1vc3Qgb2YgdGhlbSBhcmUgY29ubmVj dGVkIHRvIHNvbWUgc29ydCBvZiBQQlggDQo+IG9yIGFuIElQIFBCWCB0eXBlIHNlcnZpY2UuIFNv LCBpbiByZWFsaXR5IHlvdSBkbyBub3QgbmVlZCB0byBicmlkZ2UgDQo+IGV2ZXJ5IElQIHBob25l IHdpdGggV2ViUlRDLg0KDQpUaGF0IGlzIGEgKnZlcnkqIGxpbWl0ZWQgc2NvcGUgb2Ygd2hhdCBX ZWJSVEMgY2FuIHByb3ZpZGUuIEFuIElUIGRlcGFydG1lbnQgc2hvdWxkIGJlIGFibGUgdG8gZGVw bG95IGl0cyBvd24gV2ViUlRDIGluZnJhc3RydWN0dXJlIChhDQpXZWIrV2ViU29ja2V0IHNlcnZl cikgd2l0aGluIGl0cyAibG9jYWwiIG5ldHdvcmssIHNvIGJyb3dzZXJzDQphY2Nlc3NpbmcgdG8g c3VjaCBhIGxvY2FsIHdlYnNpdGUgc2hhcmUgdGhlIG5ldHdvcmsgd2l0aCBTSVAvWE1QUCBwaG9u ZXMvZGV2aWNlcy9zb2Z0cGhvbmVzLg0KDQpQbGVhc2UgZG9uJ3QgaW1hZ2luZSBXZWJSVEMgYW5k IFNJUCBpbnRlcm9wIGFzIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdHdvIGlzbGFuZHMgOykN Cg0KDQoNCj4gSWYgYSBmZXcgUEJYIGFuZCBob3N0ZWQgY2VudHJleCB2ZW5kb3JzIHdpbGwgYWRk IHN1cHBvcnQgZm9yIFdlYlJUQyANCj4gcmVxdWlyZWQgZmVhdHVyZXMsIHdlIHdpbGwgZ2V0IGNv bXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBlbmQgcG9pbnRzLg0KDQpQdXJlIFNJUCBwcm94aWVz IGRvIGV4aXN0LiBBIFBCWCBpcyBub3QgYWx3YXlzIG5lZWRlZCwgc28gYWdhaW4sIFNJUCB3b3Js ZCBkb2VzIG5vdCByZXF1aXJlIHRvIGJlICJhbiBpc2xhbmQiLg0KDQoNCj4gVG8gc3VwcG9ydCB0 aGUgcmVzdCB5b3Ugd2lsbCBuZWVkIHRvIGRlcGxveSBzb21lIHNvcnQgb2YgZ2F0ZXdheS4NCg0K Tm90IGluIHRoZSBjYXNlIFNERVMrU1JUUCBpcyBhbGxvd2VkIGluIFdlYlJUQyAoc2VlIEZhYml1 cydzIHJlY2VudCBtYWlscyBhYm91dCBTREVTIGFuZCBEVExTKS4NCg0KDQoNCj4gaHVyZGxlIChJ IGFtIHRyeWluZyB0byBiZSBwb2xpdGljYWxseSBjb3JyZWN0IGhlcmUpLiBXZWJSVEMgZW5hYmxl ZCANCj4gZW5kIHBvaW50cywgb24gdGhlIG90aGVyIGhhbmQsIHdpbGwgb2ZmZXIgc2lnbmlmaWNh bnQgYmVuZWZpdHMgdG8gDQo+IHRyYWRpdGlvbmFsIFNJUCBwaG9uZXMsIHNpbmNlIHRoZXkgd2ls bCBhbGxvdyBkZXZlbG9wbWVudCBvZiBoaWdoZXIgDQo+IHF1YWxpdHkgaW50ZWdyYXRlZCByZWFs IHRpbWUgY29tbXVuaWNhdGlvbnMgc2VydmljZXMuIEkgaG9wZSB0aGlzIHdpbGwgDQo+IGRyaXZl IGEgbXVjaCBxdWlja2VyIHN0YW5kYXJkIGFkb3B0aW9uLg0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0 IHRoZXJlIGlzIGEgKk5FVyogU1JUUCByZWxhdGVkIHNwZWMgZm9yIFdlYlJUQzoNCg0KICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dC1zcnRwLWVrdC0wMw0KDQpNYXli ZSBpdCBjb3VsZCBhbHNvIGJlY29tZSBhIHN0YW5kYXJkIGZvciBTSVA/IEkgaG9wZSwgYnV0IGN1 cnJlbnRseSBpdCdzIG5vdCwgc28gYnkgKm1hbmRhdGluZyogRFRMUy1FS1QtU1JUUCBpbiBXZWJS VEMgd2UgYXJlIGNyZWF0aW5nIGEgaXNsYW5kLg0KDQoNClJlZ2FyZHMuDQoNCg0KLS0NCknDsWFr aSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From ibc@aliax.net Thu Apr 5 04:20: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 A171321F8736 for ; Thu, 5 Apr 2012 04:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.062, 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 VikbFUsNRq0v for ; Thu, 5 Apr 2012 04:20:26 -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 05D9821F872E for ; Thu, 5 Apr 2012 04:20:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1074123vbb.31 for ; Thu, 05 Apr 2012 04:20:25 -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=JUdG/LyMqdyjqosNI1sqpbAXY+mAnA/raIKXl7Po7ro=; b=JHlYf30b61qJ196wMWwAvuDs/ZOid6MEN9m9KT2G0YU8TuYyVwCcGEckO19r8ulR7m f3TgFL4o9ZcVOzuN6FGqSUgpyKO8iEaBnOCh4rUVif4u2D518XArLwkDqIN0Nz2tsA33 UH7wz0YWcEZC4Ft2s9QHx6qM9dYqZBtOseExvysIUANrDPsC0koozrEtfB+S9YHYOBzA 2nQDJ3gji3BGehs5JLOOl3APRLkzVIL7GkLTPAUTDyqpmbT6l/CXVv+7awsPjxOIGk1F P+L46H2UkrC6RogyrBpPjtFW/5AElOpm02l0dXheUqBX94AEF20MbPy5h+tg755xCj0c cDCQ== Received: by 10.52.94.233 with SMTP id df9mr1303266vdb.119.1333624825380; Thu, 05 Apr 2012 04:20:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 04:20:05 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42CA74D4@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C42CA74D4@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 13:20:05 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlItc2tYuqrLxSf/1udydlAWdQhqvI6rC33SG3UA0/1AGdpoBhnIFBSUG8CQJJjvQi54VlQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 11:20:26 -0000 2012/4/5 Christer Holmberg : >> The problem arises when media encrypt/decrypt is required, and evenr mor= e when a key update in RTP (like the DTLS EKT update) must be converted int= o a signaling re-INVITE by a super Signaling+Media B2BUA: > > ...and, in general we should not specify procedures which require an inte= rmediary to trigger and send re-INVITEs in the first place, because that it= self can then cause lots of issues. Agreed. So if WebRTC-SIP interop is important (or a valuable point for WebRTC) then please DON'T rely on the existence of such a monstrous super signaling+media B2BUA, and DON'T assume that WebRTC-SIP interop is the communication between two separate islands. Please. It should be much better, and allowing SDES-SRTP is the key for that. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu Apr 5 06:53: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 7C24121F858F for ; Thu, 5 Apr 2012 06:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, 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 5vO4+gXi4qLT for ; Thu, 5 Apr 2012 06:53:23 -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 5E75221F8577 for ; Thu, 5 Apr 2012 06:53:23 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1496305pbb.31 for ; Thu, 05 Apr 2012 06:53:23 -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=F2YWlil47VIB8pjnQ+9p7gFby0HV8l9zLyqpNoYBgBU=; b=pOWlDnmphZzcX0FAp0urkTemOgRfXVFAvjykXr3OAUDv4dtpunM51PNNEmxSyqYSjl TA4s4pn68KKiA+cb04wskoVTl/1vjpwsJa7PWS9hKPw96I5d2mXvymc+MLa6n/Wf2L0P 2t/SZfmS4xTYRnbAmpE1fO0EolD+7VTCuXMCFhL+ZQ4OXhgEKTJk60SUI7bAfEx6yZRr mnZLo6Fz/EO8QX8AIBa8zZmXFT+6RxI5ZUQOfC/S69d+NRLdAm1lcsq2AUBk4eCXvUj8 SD7KNTSekUrF7czU9bAZcVyWwsKyZhT1PZTNvzdDWePQRzYlerGWGh+l3e7DzDp+fqxv y/MQ== Received: by 10.68.228.168 with SMTP id sj8mr3847944pbc.101.1333634003098; Thu, 05 Apr 2012 06:53:23 -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 l4sm3333139pbl.27.2012.04.05.06.53.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 06:53:22 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1496270pbb.31 for ; Thu, 05 Apr 2012 06:53:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.234.228 with SMTP id uh4mr2348679pbc.78.1333634000948; Thu, 05 Apr 2012 06:53:20 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 06:53:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 09:53:20 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b33da10e30f4504bceedcbc X-Gm-Message-State: ALoCoQl0LFuG/L+6N8ycrq7ElibkX/WtVY4hrbc0ckFi5oL6I144ZTbLzT2sEI6T1ww3MNZpLemm Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 13:53:24 -0000 --047d7b33da10e30f4504bceedcbc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2012 at 5:04 AM, I=F1aki Baz Castillo wrote: > 2012/4/5 Roman Shpount : > > On the more serious note, very few SIP end points offer working ICE > support. > > So, in a large sense, interop with them is not an option. > > For me there is a BIG difference when a kind of B2BUA is required > (which involves signaling "transaction"). That's the barrier IMHO. > > ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see: > > http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png This picture is not entirely correct -- ICE Lite proxy should be on both SIP and Media path. The problem arises when media encrypt/decrypt is required, and evenr > more when a key update in RTP (like the DTLS EKT update) must be > converted into a signaling re-INVITE by a super Signaling+Media B2BUA: > > http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png > > Not sure why key update needs to be converted into signaling if media is re-encrypted. Key updates on both sides of the proxy are independent. Such proxy can also change SDES-SRTP key on each re-INVITE initiated by either side, but apart from doing actual encryption/decryption, operation wise it should not be any different then ICE-Lite proxy. > > Out of the ones > > that do support ICE and SRTP, very few are actually connected directly > to a > > public internet. Most of them are connected to some sort of PBX or an I= P > PBX > > type service. So, in reality you do not need to bridge every IP phone > with > > WebRTC. > > That is a *very* limited scope of what WebRTC can provide. An IT > department should be able to deploy its own WebRTC infrastructure (a > Web+WebSocket server) within its "local" network, so browsers > accessing to such a local website share the network with SIP/XMPP > phones/devices/softphones. > > Please don't imagine WebRTC and SIP interop as the communication > between two islands ;) > I actually do imagine WebRTC/SIP interop as two islands. If we need to proxy media and convert Web+WebSocket into SIP this is a definition of island bridge for me. > If a few PBX and hosted centrex vendors will add support for WebRTC > > required features, we will get compatibility with existing end points. > > Pure SIP proxies do exist. A PBX is not always needed, so again, SIP > world does not require to be "an island". > Once again, if SIP proxy is combined with media proxy, you can bridge SIP and WebRTC, even if DTLS-SRTP is used. > > To support the rest you will need to deploy some sort of gateway. > > Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent > mails about SDES and DTLS). > > Once again, we still need a gateway to support ICE. If end point is adding ICE to interop with WebRTC, why not add DTLS-SRTP at the same time. > > hurdle (I am trying to be politically correct here). WebRTC enabled end > > points, on the other hand, will offer significant benefits to tradition= al > > SIP phones, since they will allow development of higher quality > integrated > > real time communications services. I hope this will drive a much quicke= r > > standard adoption. > > The problem is that there is a *NEW* SRTP related spec for WebRTC: > > http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-03 > > Maybe it could also become a standard for SIP? I hope, but currently > it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a > island. > > Same as above. P.S. I actually do not like DTLS-SRTP, since it does not have a large installed base, comes with too many features, slows down call setup, will requirecomplex interop and such. At the same time I do not think that interop with legacy SDES-SRTP is a reason not to use it. I believe we should design a new key exchange method, that can be mapped to SDES-SRTP via signaling alone, addresses SDES-SRTP issues (transmitting keys over clear channel in signaling, replay of signaling) without introducing all the problems related to DTLS-SRTP. Any number of methods using public key based exchange over signaling and ICE should do the trick. _____________ Roman Shpount --047d7b33da10e30f4504bceedcbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 5:04 AM= , I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/4/5 Roman Shpount <roman@telurix.com>:
> On the more serious note, very few SIP end points offer working I= CE support.
> So, in a large sense, interop with them is not an option.

For me there is a BIG difference when a kind of B2BUA is required
(which involves signaling "transaction"). That's the barrier = IMHO.

ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see:

=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SD= ES-SRTP.png

This picture is not entirely correct -= - ICE Lite proxy should be on both SIP and Media path.

The problem arises when media encrypt/decrypt is required, and evenr
more when a key update in RTP (like the DTLS EKT update) must be
converted into a signaling re-INVITE by a super Signaling+Media B2BUA:

=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Intero= p_DTLS-EKT-SRTP.png

=A0
Not sure why key update need= s to be converted into signaling if media is re-encrypted. Key updates on b= oth sides of the proxy are independent. Such proxy can also change SDES-SRT= P key on each re-INVITE initiated by either side, but apart from doing actu= al encryption/decryption, operation wise it should not be any different the= n ICE-Lite proxy.
=A0
> Out of the ones
> that do support ICE and SRTP, very few are actually connected directly= to a
> public internet. Most of them are connected to some sort of PBX or an = IP PBX
> type service. So, in reality you do not need to bridge every IP phone = with
> WebRTC.

That is a *very* limited scope of what WebRTC can provide. An IT
department should be able to deploy its own WebRTC infrastructure (a
Web+WebSocket server) within its "local" network, so browsers
accessing to such a local website share the network with SIP/XMPP
phones/devices/softphones.

Please don't imagine WebRTC and SIP interop as the communication
between two islands ;)

I actually do imagine WebRT= C/SIP interop as two islands. If we need to proxy media and convert Web+Web= Socket into SIP this is a definition of island bridge for me.

> If a few PBX and hosted centrex vendors will add support for WebRTC > required features, we will get compatibility with existing end points.=

Pure SIP proxies do exist. A PBX is not always needed, so again, SIP<= br> world does not require to be "an island".

Once=A0 again, if SIP proxy is combined wi= th media proxy, you can bridge SIP and WebRTC, even if DTLS-SRTP is used.
=A0
> To support the rest you will need to deploy some sort of gateway.

Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's rece= nt
mails about SDES and DTLS).

=A0
Once again, we still need a gateway to support ICE. If end point is addi= ng ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.
=A0
> hurdle (I am trying to be politically correct here). WebRTC enabled en= d
> points, on the other hand, will offer significant benefits to traditio= nal
> SIP phones, since they will allow development of higher quality integr= ated
> real time communications services. I hope this will drive a much quick= er
> standard adoption.

The problem is that there is a *NEW* SRTP related spec for WebRTC:
=A0http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-03

Maybe it could also become a standard for SIP? I hope, but currently
it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a island.


Same as above.
P.S. I actually do not like DTLS-SRTP, since it does not have a large= installed base, comes with too many features, slows down call setup, will = requirecomplex interop and such. At the same time I do not think that inter= op with legacy SDES-SRTP is a reason not to use it. I believe we should des= ign a new key exchange method, that can be mapped to SDES-SRTP via signalin= g alone, addresses SDES-SRTP issues (transmitting keys over clear channel i= n signaling, replay of signaling) without introducing all the problems rela= ted to DTLS-SRTP. Any number of methods using public key based exchange ove= r signaling and ICE should do the trick.
_____________
Roman Shpount

--047d7b33da10e30f4504bceedcbc-- From ibc@aliax.net Thu Apr 5 07:40: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 2785C21F85C3 for ; Thu, 5 Apr 2012 07:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_39=0.6, 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 APDqCSHUU0VC for ; Thu, 5 Apr 2012 07:40:00 -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 3CB2921F85C0 for ; Thu, 5 Apr 2012 07:40:00 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1221159vbb.31 for ; Thu, 05 Apr 2012 07:39:59 -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=fsYFEzQ0+yK2guzOmPpK5E9mOpSXCniVkFZtd6oDgJI=; b=d+umbB83JE9ZzUG0+Yoaska0Oe0t7ezPmZ50n0gxeSwdAF/DmP3duQK/eDHULPeQIh QzWRgGiogJQx8aAII6+Y5AOak9cuOlTT7jldQgbEORC/uzthpXNeDYmcbPefbaml8thU 1Nn5LO78fdufOlz/Gwo1ZjcZUQeSLOn8wvJHSYsxY2b9qWFEprKD4L+vlVBzm8BahB5x D/jB14gt5alXUIG/8cnVswoeDeZWDxk6HBcmEFvpBdZf1rDzw3VhXTCcKqG926F7s116 b26SNZm4ZUSoMyToiloY66FJQFtyswCLehPoRvI6ojntBHLJHmI/fTBlpAcJpKi6KZui 0CRw== Received: by 10.52.27.1 with SMTP id p1mr1846691vdg.17.1333636799717; Thu, 05 Apr 2012 07:39:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 07:39:39 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 16:39:39 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlN4Wn54bJu4j3lVWl4XL4hw0aHjTGnM9llgKs50+k7eDJ7YnU60riFwgHEnC6jocvqQuph Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 14:40:01 -0000 2012/4/5 Roman Shpount : > > On Thu, Apr 5, 2012 at 5:04 AM, I=C3=B1aki Baz Castillo w= rote: >> ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see: >> >> =C2=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png > > > This picture is not entirely correct -- ICE Lite proxy should be on both = SIP > and Media path. Incorrect. The proxy would communicate with the ICE-Lite server(s) using some kind of proprietary protocol. This is already true in some SIP proxies (SER, Kamailio, OpenSer) and media-proxies (rtpproxy, mediaproxy, irtpproxy). >> The problem arises when media encrypt/decrypt is required, and evenr >> more when a key update in RTP (like the DTLS EKT update) must be >> converted into a signaling re-INVITE by a super Signaling+Media B2BUA: >> >> =C2=A0http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.pn= g >> > > Not sure why key update needs to be converted into signaling if media is > re-encrypted. Key updates on both sides of the proxy are independent. Suc= h > proxy can also change SDES-SRTP key on each re-INVITE initiated by either > side, but apart from doing actual encryption/decryption, operation wise i= t > should not be any different then ICE-Lite proxy. Maybe. >> That is a *very* limited scope of what WebRTC can provide. An IT >> department should be able to deploy its own WebRTC infrastructure (a >> Web+WebSocket server) within its "local" network, so browsers >> accessing to such a local website share the network with SIP/XMPP >> phones/devices/softphones. >> >> Please don't imagine WebRTC and SIP interop as the communication >> between two islands ;) > > > I actually do imagine WebRTC/SIP interop as two islands. If we need to pr= oxy > media and convert Web+WebSocket into SIP this is a definition of island > bridge for me. If you say that we need to "convert Web+WebSocket into SIP" then you are absolutely wrong, even more taking into account that "draft-ibc-sipcore-sip-websocket-01" (The WebSocket Protocol as a Transport for SIP) is being adopted by the IETF SIPCORE Working Group as a new SIP transport. The slide 8 in [2] shows a *pure* SIP proxy, and not a "WebSocket to SIP gateway". So ***NO*** island at signaling level, not at all. [1] http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 [2] http://sip-on-the-web.aliax.net/ >> Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent >> mails about SDES and DTLS). >> > > Once again, we still need a gateway to support ICE. If end point is addin= g > ICE to interop with WebRTC, why not add DTLS-SRTP at the same time. Building an ICE-Lite RTP/SRTP tunnel/proxy is "easy". After ICE "handhake" the server can relay UDP packets as kernel space (conntrack in Linux), but if you need to decrypt and encrypt you need to do that at user space, which is much worse and requires much more CPU. > P.S. I actually do not like DTLS-SRTP, since it does not have a large > installed base, comes with too many features, slows down call setup, will > requirecomplex interop and such. > I believe we should > design a new key exchange method, that can be mapped to SDES-SRTP via > signaling alone, And wouldn't that be a mechanism with "non a large installed base"? > addresses SDES-SRTP issues (transmitting keys over clear > channel in signaling, replay of signaling) If HTTPS / WSS is used, there is no "clear channel". It would be easy to mandate *all* the browser communication using TLS for the case in which SDES-SRTP is used. That is a feasible and valid requirement IMHO. > without introducing all the > problems related to DTLS-SRTP. Any number of methods using public key bas= ed > exchange over signaling and ICE should do the trick. So a complete new protocol. Bye any kind of interop (except if you have the magic super B2BUA). PS: Please consider reading Fabios's mails and reply to them. The discussion will be more interesting is such nice explanations are not ignored ;) --=20 I=C3=B1aki Baz Castillo From jmvalin@mozilla.com Thu Apr 5 08:10: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 7485821F86D3 for ; Thu, 5 Apr 2012 08:10:22 -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 h02tQZvILCbs for ; Thu, 5 Apr 2012 08:10:21 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6D21F8618 for ; Thu, 5 Apr 2012 08:10:21 -0700 (PDT) Received: from [192.168.1.15] (modemcable014.207-160-184.mc.videotron.ca [184.160.207.14]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 12E5B4AEDD2; Thu, 5 Apr 2012 08:10:20 -0700 (PDT) Message-ID: <4F7DB5DC.40507@mozilla.com> Date: Thu, 05 Apr 2012 11:10:20 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> In-Reply-To: <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 05 Apr 2012 15:10:22 -0000 On 05/04/12 02:47 AM, Paul E. Jones wrote: > I know, but the reluctance to do so means that Google knows that there *may > be* IPR on VP8. This is just the facts of life. I believe it's extremely > important that people know and understand that nobody knows the IPR > situation with VP8. If they did, they would offer indemnity, because there > is nothing to worry about, but nobody can. Personally, I would be reluctant to indemnify anyone over IPR in a paper clip. This is the sad state of the patent system and it applies to every piece of technology. > Indeed, but I have a significantly higher level of confidence that I can > identify all of the legitimate companies with IPR on H.264, whereas I > haven't a clue where to start (outside of Google) for VP8. Obviously, that makes H.264 so much safer, right? http://www.theregister.co.uk/2012/03/29/microsoft_motorola_patent_cases/ > If I owned IPR on VP8 (which I don't personally; can't speak for my > employer), I certainly would not tell you and I would not join a patent > pool, either. I would wait until you adopt VP8, build it into software and > hardware products, have it massively deployed, and then I'd come along and > collect my royalties. There is absolutely no financial incentive for an IPR > holder to join a patent pool. I assume this is why we've seen all these lawsuits against Google, Microsoft, Cisco, Apple... over their use of Vorbis and Speex, right? Seriously, I can count at least 10 free AV codecs and none of them have had any patent lawsuits that I'm aware of. > H.264, on the other hand, is different. H.264 was developed jointly by > video coding experts in ISO and ITU. As an part of that participation, they > are requested to disclose IPR. And, respectable companies will disclose > their IPR. Every company participating in that work has a vested interest > in the success of H.264. Some are looking for royalties and some are > looking for the technology to enable their products. Thus, the formation of > the patent pool is in the best interest of all involved so that people will > adopt the technology. While there are those not in the pool, they have > submitted IPR statements to the ITU. The best interest of a H.264 patent owner is to avoid having to disclose, wait for adoption, and then be free to ask for a lot more than what they would get from the patent pool. This is why I consider H.264 to be a higher risk than VP8. The current Motorola lawsuit confirms this. Cheers, Jean-Marc From roman@telurix.com Thu Apr 5 08:40: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 A20E221F8658 for ; Thu, 5 Apr 2012 08:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, 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 GEV8OcA9w4V4 for ; Thu, 5 Apr 2012 08:40:30 -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 8E45221F864F for ; Thu, 5 Apr 2012 08:40:30 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1599820pbb.31 for ; Thu, 05 Apr 2012 08:40:30 -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=X2nlrgS3cT5b3R2c16b76cPiyIIN+LriuJlhvUwABc0=; b=cmNl+OdSIi7T8M7P1PsbIQ14JCid1Z7M72KvIGaeU/w/BHivscV1opWYzWgI3TT98g IvVfFiBmQNgRXewnMwwDaVxkt6XZQ0Zj5KIBPT6gUAXirUqkvnX0MQwVkLpP5Jnregdy N3TZ2IJSWAEtYa2wOP5fvTA7QW9lRDGyKttaIB5pQGTY7qgO15w85GMIRDhq0UppJaEQ 7OfRqpeo59byV0NEEUsouuyP7t7dJtLZczB3m0UGnjqJ4KKiPgLwAFAZc/xvHRojUUFX zMvnyX2PYrdf+jAGLWCMlKlsmr9f57+0dUzxcz3fm6jyWyShLKHe4Hn1acN6x0FeaxjE Bhpg== Received: by 10.68.201.201 with SMTP id kc9mr8106592pbc.50.1333640430155; Thu, 05 Apr 2012 08:40:30 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id s10sm3559649pbp.14.2012.04.05.08.40.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:40:29 -0700 (PDT) Received: by dady13 with SMTP id y13so2461034dad.27 for ; Thu, 05 Apr 2012 08:40:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.197.3 with SMTP id iq3mr8106844pbc.36.1333640428404; Thu, 05 Apr 2012 08:40:28 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 08:40:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 11:40:28 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8ff1c650fe3ffa04bcf05b1b X-Gm-Message-State: ALoCoQm1x/xpKMuodp6LCkg9AtBJEb1amv8QO3bDf1sQNpUa5LYh+JzU2PmLXjHb02JRePE8p0qK Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 15:40:31 -0000 --e89a8ff1c650fe3ffa04bcf05b1b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2012 at 10:39 AM, I=F1aki Baz Castillo wrote= : > 2012/4/5 Roman Shpount : > > > > On Thu, Apr 5, 2012 at 5:04 AM, I=F1aki Baz Castillo > wrote: > >> ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see: > >> > >> http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png > > > > > > This picture is not entirely correct -- ICE Lite proxy should be on bot= h > SIP > > and Media path. > > Incorrect. The proxy would communicate with the ICE-Lite server(s) > using some kind of proprietary protocol. This is already true in some > SIP proxies (SER, Kamailio, OpenSer) and media-proxies (rtpproxy, > mediaproxy, irtpproxy). > > Internal protocols do not matter. The "super B2BUA" can be using a custom protocol between RTP forwarder and SIP processor. Does not change the fact that from logical point of view it is on both SIP and media path. At minimum you are missing a custom protocol connection between ICE-Lite gateway and SIP proxy. So, your picture is still wrong. > >> That is a *very* limited scope of what WebRTC can provide. An IT > >> department should be able to deploy its own WebRTC infrastructure (a > >> Web+WebSocket server) within its "local" network, so browsers > >> accessing to such a local website share the network with SIP/XMPP > >> phones/devices/softphones. > >> > >> Please don't imagine WebRTC and SIP interop as the communication > >> between two islands ;) > > > > > > I actually do imagine WebRTC/SIP interop as two islands. If we need to > proxy > > media and convert Web+WebSocket into SIP this is a definition of island > > bridge for me. > > If you say that we need to "convert Web+WebSocket into SIP" then you > are absolutely wrong, even more taking into account that > "draft-ibc-sipcore-sip-websocket-01" (The WebSocket Protocol as a > Transport for SIP) is being adopted by the IETF SIPCORE Working Group > as a new SIP transport. > > The slide 8 in [2] shows a *pure* SIP proxy, and not a "WebSocket to > SIP gateway". So ***NO*** island at signaling level, not at all. > > > [1] http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 > [2] http://sip-on-the-web.aliax.net/ > > This assumes ICE support in SIP end points. If they do not support ICE yo= u still need a media proxy driven by SIP proxy. Not that different from encryption. > >> Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent > >> mails about SDES and DTLS). > >> > > > > Once again, we still need a gateway to support ICE. If end point is > adding > > ICE to interop with WebRTC, why not add DTLS-SRTP at the same time. > > Building an ICE-Lite RTP/SRTP tunnel/proxy is "easy". After ICE > "handhake" the server can relay UDP packets as kernel space (conntrack > in Linux), but if you need to decrypt and encrypt you need to do that > at user space, which is much worse and requires much more CPU. > > You can still get STUN messages after initial handshake, so you need to monitor/filter media. Not sure this is possible with conntrack. If you are doing media proxy with re-encryption in the user space you can probably get about 10GB/sec worth of throughput with the modern dual Xeon E5 server. > > P.S. I actually do not like DTLS-SRTP, since it does not have a large > > installed base, comes with too many features, slows down call setup, wi= ll > > requirecomplex interop and such. > > > I believe we should > > design a new key exchange method, that can be mapped to SDES-SRTP via > > signaling alone, > > And wouldn't that be a mechanism with "non a large installed base"? > I would prefer a simpler new protocol then a complex existing one with no real user base. Something as simple as sending public key in the SDP and sending session key in ICE handshake STUN message would be better the DTLS. It is simple to implement, does not send keys over clear channel, and can be mapped to SDES-SRTP using ICE-Lite proxy with no additional signaling messages or doing re-encryption. This probably needs to be enhanced to support public key algorithm/key length negotiation and replay protection, but this should be trivial as well. > > addresses SDES-SRTP issues (transmitting keys over clear > > channel in signaling, replay of signaling) > > If HTTPS / WSS is used, there is no "clear channel". It would be easy > to mandate *all* the browser communication using TLS for the case in > which SDES-SRTP is used. That is a feasible and valid requirement > IMHO. > HTTPS/WSS is used you provide better protection, but there are still issues with cross-site scripting, web site security etc. You did prevent some of the attacks, but you still nowhere near being secure. Once again, if we have a key exchnage that can be mapped to SDES-SRTP, there is no need to compromise. > without introducing all the > > problems related to DTLS-SRTP. Any number of methods using public key > based > > exchange over signaling and ICE should do the trick. > > So a complete new protocol. Bye any kind of interop (except if you > have the magic super B2BUA). > I think idea of interop is gone for all practical purposes. We gave it up when we made ICE a requirement. > PS: Please consider reading Fabios's mails and reply to them. The > discussion will be more interesting is such nice explanations are not > ignored ;) > > I've read it. Nice tutorial, but does not change anything I am saying here. P.S. I have feeling that anything security related keeps being discussed here without converging anywhere. My proposal (DTLS-SRTP by default, SDES-SRTP from HTTPS sessions or RTP from HTTP session if enabled) got ignored as well. This at least inline with current HTTP(S) security model. ______________ Roman Shpount --e89a8ff1c650fe3ffa04bcf05b1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 10:39 A= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/4/5 Roman Shpount <roman@telurix.com>:
>
> On Thu, Apr 5, 2012 at 5:04 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
>> ICE support can be implemented in a ICE-Li= te RTP/SRTP proxy, see:
>>
>> =A0http://public.aliax.net/WebRTC/WebRTC_SIP_In= terop_SDES-SRTP.png
>
>
> This picture is not entirely correct -- ICE Lite proxy should be on bo= th SIP
> and Media path.

Incorrect. The proxy would communicate with the ICE-Lite server(s) using some kind of proprietary protocol. This is already true in some
SIP proxies (SER, Kamailio, OpenSer) and media-proxies (rtpproxy,
mediaproxy, irtpproxy).

Internal protocols do not mat= ter. The "super B2BUA" can be using a custom protocol between RTP= forwarder and SIP processor. Does not change the fact that from logical po= int of view it is on both SIP and media path. At minimum you are missing a = custom protocol connection between ICE-Lite gateway and SIP proxy. So, your= picture is still wrong.
=A0
>> That is a *very* limited scope of what WebRTC can provide. An IT >> department should be able to deploy its own WebRTC infrastructure = (a
>> Web+WebSocket server) within its "local" network, so bro= wsers
>> accessing to such a local website share the network with SIP/XMPP<= br> >> phones/devices/softphones.
>>
>> Please don't imagine WebRTC and SIP interop as the communicati= on
>> between two islands ;)
>
>
> I actually do imagine WebRTC/SIP interop as two islands. If we need to= proxy
> media and convert Web+WebSocket into SIP this is a definition of islan= d
> bridge for me.

If you say that we need to "convert Web+WebSocket into SIP"= then you
are absolutely wrong, even more taking into account that
"draft-ibc-sipcore-sip-websocket-01" (The WebSocket Protocol as a=
Transport for SIP) is being adopted by the IETF SIPCORE Working Group
as a new SIP transport.

The slide 8 in [2] shows a *pure* SIP proxy, and not a "WebSocket to SIP gateway". So ***NO*** island at signaling level, not at all.


[1] http://tools.ietf.org/html/draft-ibc-sipcore-sip-webso= cket-01
[2] http://s= ip-on-the-web.aliax.net/

This assumes ICE support in SIP end points. If = they do not support ICE you still need a media proxy driven by SIP proxy. N= ot that different from encryption.

=A0
>> Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's r= ecent
>> mails about SDES and DTLS).
>>
>
> Once again, we still need a gateway to support ICE. If end point is ad= ding
> ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.
Building an ICE-Lite RTP/SRTP tunnel/proxy is "easy". After= ICE
"handhake" the server can relay UDP packets as kernel space (conn= track
in Linux), but if you need to decrypt and encrypt you need to do that
at user space, which is much worse and requires much more CPU.

You can still get STUN messag= es after initial handshake, so you need to monitor/filter media. Not sure t= his is possible with conntrack. If you are doing media proxy with re-encryp= tion in the user space you can probably get about 10GB/sec worth of through= put with the modern dual Xeon E5 server.
=A0
> P.S. I actually do not like DTLS-SRTP, since it does not have a large<= br> > installed base, comes with too many features, slows down call setup, w= ill
> requirecomplex interop and such.

> I believe we should
> design a new key exchange method, that can be mapped to SDES-SRTP via<= br> > signaling alone,

And wouldn't that be a mechanism with "non a large installed= base"?

I would prefer a simpler new protocol= then a complex existing one with no real user base. Something as simple as= sending public key in the SDP and sending session key in ICE handshake STU= N message would be better the DTLS. It is simple to implement, does not sen= d keys over clear channel, and can be mapped to SDES-SRTP using ICE-Lite pr= oxy with no additional signaling messages or doing re-encryption. This prob= ably needs to be enhanced to support public key algorithm/key length negoti= ation and replay protection, but this should be trivial as well.
=A0
> addresses SDES-SRTP issues (transmitting keys over c= lear
> channel in signaling, replay of signaling)

If HTTPS / WSS is used, there is no "clear channel". It wou= ld be easy
to mandate *all* the browser communication using TLS for the case in
which SDES-SRTP is used. That is a feasible and valid requirement
IMHO.

HTTPS/WSS is used you provide= better protection, but there are still issues with cross-site scripting, w= eb site security etc. You did prevent some of the attacks, but you still no= where near being secure. Once again, if we have a key exchnage that can be = mapped to SDES-SRTP, there is no need to compromise.

> without introducing all the
> problems related to DTLS-SRTP. Any number of methods using public key = based
> exchange over signaling and ICE should do the trick.

So a complete new protocol. Bye any kind of interop (except if you have the magic super B2BUA).

I think idea of inter= op is gone for all practical purposes. We gave it up when we made ICE a req= uirement.
=A0
PS: Please consider reading Fabios's mails and reply to them. The
discussion will be more interesting is such nice explanations are not
ignored ;)


I've read it. Nice tut= orial, but does not change anything I am saying here.

P.S. I have fe= eling that anything security related keeps being discussed here without con= verging anywhere. My proposal (DTLS-SRTP by default, SDES-SRTP from HTTPS s= essions or RTP from HTTP session if enabled) got ignored as well. This at = least inline with current HTTP(S) security model.
______________
Roman Shpount
--e89a8ff1c650fe3ffa04bcf05b1b-- From igor.faynberg@alcatel-lucent.com Thu Apr 5 08:49: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 13CE821F8712 for ; Thu, 5 Apr 2012 08:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 momEYPMYd3e0 for ; Thu, 5 Apr 2012 08:49:23 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A6BB921F85C3 for ; Thu, 5 Apr 2012 08:49:18 -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 q35FnHjv029405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Apr 2012 10:49:18 -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 q35FnHUC009347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Apr 2012 10:49:17 -0500 Received: from [135.244.43.110] (faynberg.lra.lucent.com [135.244.43.110]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q35FnH0K028351; Thu, 5 Apr 2012 10:49:17 -0500 (CDT) Message-ID: <4F7DBEFC.6040302@alcatel-lucent.com> Date: Thu, 05 Apr 2012 11:49:16 -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: <4F7D7103.6040102@infosecurity.ch> In-Reply-To: <4F7D7103.6040102@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.12 Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP) 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, 05 Apr 2012 15:49:24 -0000 Fabio, I am finding these definitions hard to understand. I am afraid that somehow the activity (encryption) gets mixed with the services (confidentiality and authentication). I think your major point is that effective encryption must rely on symmetric keys, and that the key distribution is crucial to ensuring confidentiality provably. I agree with that. I also agree with sepating the case when session keys are handed out by another entity (such as KDC) and the case where the keys are known only to the end-points. The latter can be achieved with signed Diffie-Hellman (using PKI, or PAK, or EKE). Confidentiality, of course, relies on authentication: If I encrypt something with the key I share only with you, I'd better know that I share this key ONLY with you. But I don't get the point of the taxonomy you propose... Igor On 4/5/2012 6:16 AM, Fabio Pietrosanti (naif) wrote: > Hi, > > i've been discussing with several friends about the current discussion > on the security standard in this mailing lists, in particular regarding > the topic of DTLS-SRTP trust model posted there > http://www.ietf.org/mail-archive/web/rtcweb/current/msg04007.html . > > I found that there is no common definition for the concept of > "end-to-end encryption" and there are a lot of misunderstanding about it. > > In particular, the fact that two peer can community by exchanging keys > directly among them, tend to typically to be defined as end-to-end > encryption. > > However the term "end-to-end encryption" have also a general > misconception that's something that "no one can intercept" . > > Unfortunately this is not true for DTLS-SRTP, while for example it's > true for OpenPGP/MIME or for ZRTP with SAS. > > We need to separate the 4 concepts: > > - end-to-end encryption > Ability for a key management system to exchange keys directly without > relying on intermediate server actively involved in encryption process. > > - end-to-end authentication > Ability for end-user to authenticate the end-to-end encryption process > without the need to rely on a single or multiple set of trusted third > parties > > - end-to-site encryption > Ability for a key management system to exchange keys with/trough the > server with which data are exchanged, involving it in the authentication > process. > > - end-to-site authentication > Ability for end-user to authenticate the end-to-site encryption process > based on the same security mechanism used to establish trust with the > server with which data are exchanged. > > > What i would like to focus is that: > > - DTLS does provide end-to-end encryption (in specific context of use) > - DTLS does provide end-to-site authentication (rely on third party trust) > > - ZRTP does provide end-to-end encryption (in all context of use) > - ZRTP does provide end-to-end authentication (does not rely on third > party trust) > > - SDES-SRTP does provide end-to-site encryption (encryption with/trough > your server) > - SDES-SRTP does provide end-to-site authentication (you trust your > server involved in key exchange) > > So when we tend to think about the "how much security a technology > provide" we should probably compare in a scale: > > - ZRTP > - end-to-end encryption > - end-to-end authentication > - DTLS-SRTP > - end-to-end encryption > - end-to-site authentication > - SDES-SRTP > - end-to-site encryption > - end-to-site authentication > > So currently we can affirm that: > > - ZRTP does not rely on third party trust for effective security > - DTLS-SRTP rely on third party trust for effective security > - SDES-SRTP rely on third party trust for effective security > > This is the *MOST IMPORTANT* distinction for an encryption technology: > WHO SHOULD I TRUST? > > Well, basically it seems to me that DTLS-SRTP and SDES-SRTP both require > > So, my point are to: > > - Introduce SDES-SRTP for compatibility and simplicity > - Specify that the Browser will need to provide indicate the security > level to the user (like the lock of HTTPS, same security model) > > - Introduce end-to-end authentication support for DTLS-SRTP via SAS > - Specify that the browser will need to to provide the end-user way to > use end-to-end authentication and indicate the security level to the user. > > Then it will be up to the signaling server and/or to the browser > settings to specificy the required security model: > - end-to-end encryption + end-to-end authentication > or > - end-to-site encryption + end-to-site authentication > > But please don't mix those two as it will be *Very difficult, near to > impossible* to explain to the user "WHO SHOULD HE TRUST" . > > Fabio > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Thu Apr 5 08:54: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 1217A21F86D0 for ; Thu, 5 Apr 2012 08:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.085, 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 x1LYbh1ygudz for ; Thu, 5 Apr 2012 08:54:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD621F8674 for ; Thu, 5 Apr 2012 08:54:39 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so756898vcb.31 for ; Thu, 05 Apr 2012 08:54: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=vCR7phMyySLlAvNbrmaYRAhvbG29Pgb9mHTeOfKQ6/E=; b=maqgc4QXc319A6C3GSx8etcoO6nICWo7KIThjPtAtr+jejhRSGZixdjANDrfzFhyXA c/Ti0bewH/eUTJ7dYd1TcuVnzNaLc2Ymotl9QVyXDLPCkJibiFjHRn2JO95HcoBecQAJ 0xz+EYD1Pw76Je3BunDLs7kFQuzFONS6JS9ZTXHOuQifR+r2GMLBrRAiZRhuqEqjTiws A1o2WsENrJ6iH+1qXCAc5XVKLAQ96JZLmFJ+PVWojzYOUkLsURLw98/Gy5xpPclHJs2c bGtRSUEckJyye51ytAA92su2nHDWwPOPQq6kLsRPXERH732COqIQgcRSfd5fAKmTrkpN xczw== Received: by 10.52.15.233 with SMTP id a9mr1966362vdd.34.1333641278560; Thu, 05 Apr 2012 08:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 08:54:18 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 17:54:18 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnQ0LXm3ojbppAj2ZwkGFnBJKG7tRrd1+uTfro57QOvFiIO1rjGnIWjOKpm7QXlpEht88Qw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 15:54:41 -0000 2012/4/5 Roman Shpount : > > On Thu, Apr 5, 2012 at 10:39 AM, I=C3=B1aki Baz Castillo = wrote: >> Incorrect. The proxy would communicate with the ICE-Lite server(s) >> using some kind of proprietary protocol. This is already true in some >> SIP proxies (SER, Kamailio, OpenSer) and media-proxies (rtpproxy, >> mediaproxy, irtpproxy). > Internal protocols do not matter. The "super B2BUA" can be using a custom > protocol between RTP forwarder and SIP processor. Does not change the fac= t > that from logical point of view it is on both SIP and media path. At mini= mum > you are missing a custom protocol connection between ICE-Lite gateway and > SIP proxy. So, your picture is still wrong. Too much lines if I draw such a custom protocol ;) > This assumes ICE support in SIP end points. If they do not support ICE yo= u > still need a media proxy driven by SIP proxy. Not that different from > encryption. Lot's of SIP providers force the media throught a RTP proxy, which indeed is a protocol violation since such proxies do alter the SDP which is not allowed (theorically). But such a RTP proxy is just a UDP tunnel so it can be done at kernel space (and it is). >> Building an ICE-Lite RTP/SRTP tunnel/proxy is "easy". After ICE >> "handhake" the server can relay UDP packets as kernel space (conntrack >> in Linux), but if you need to decrypt and encrypt you need to do that >> at user space, which is much worse and requires much more CPU. >> > You can still get STUN messages after initial handshake, so you need to > monitor/filter media. Not sure this is possible with conntrack. It's possible, sure. First packets are handled in user space, and later go to kernel space with conntrack rules. It's real and there are two RTP proxies doing that: MediaProxy and irtpProxy. > If you are > doing media proxy with re-encryption in the user space you can probably g= et > about 10GB/sec worth of throughput with the modern dual Xeon E5 server. If the "EKT update to SIP re-INVITE" is not required that's a good new (at least). What I would HATE is having to deal with a signaling B2BUA for interop with SIP. >> If HTTPS / WSS is used, there is no "clear channel". It would be easy >> to mandate *all* the browser communication using TLS for the case in >> which SDES-SRTP is used. That is a feasible and valid requirement >> IMHO. > > > HTTPS/WSS is used you provide better protection, but there are still issu= es > with cross-site scripting, web site security etc. You did prevent some of > the attacks, but you still nowhere near being secure. Once again, if we h= ave > a key exchnage that can be mapped to SDES-SRTP, there is no need to > compromise. I'm sure that DTLS does not solve *all* those problems. > I think idea of interop is gone for all practical purposes. We gave it up > when we made ICE a requirement. I don't agree. At least ICE is specified for SIP and XMPP-Jingle. SIP vendors are lazy since they rely of annoying SBC's that break everything but gives them money, so they "don't need" ICE. But if WebRTC becomes real then SIP vendors will read the ICE RFC and can implement it. The same is not true if a new DTLS-XXXX spec is born for WebRTC since that would require a new standard also for SIP, XMPP and so. > P.S. I have feeling that anything security related keeps being discussed > here without converging anywhere. Well, I'm learning a lot about SRTP, SDES and DTLS XD > My proposal (DTLS-SRTP by default, > SDES-SRTP from HTTPS sessions or RTP from HTTP session if enabled) got > ignored as well. This at least inline with current HTTP(S) security model= . So you proposed allowing plain RTP and now just a new DTLS-XXXX-SRTP is valid for you? :) Well, ok, IMHO there is enough debate for now. Let's wait a bit :) --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu Apr 5 09:30: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 85F0021F872E for ; Thu, 5 Apr 2012 09:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.111, 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 pV7v6AkUyeKF for ; Thu, 5 Apr 2012 09:30:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBDE721F8747 for ; Thu, 5 Apr 2012 09:30:12 -0700 (PDT) Received: by iazz13 with SMTP id z13so2399741iaz.31 for ; Thu, 05 Apr 2012 09:30:12 -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=/OyBNP47IF252jK6Cu/bQAXj8LW+4S+6IZHi4KT939A=; b=o3ZU93ZDksknBWRzY4sHqXLzpV19K30DPWe7Sp/E+86JivxE8jpjcHaPH8Nnl5NmeW V94o2AwkJGihcyH+hWxfRumSQ7CTh02Q5CzBcnzURRRQ0rBt4t8Ld9PFlVqoSBvgI1BK NUyA/ziB5h2LAnV69v5oSzu7mNqmFzXPUyir2mITyZOE7qTZvRwqOKj9L8LqN5OYxqTW VQp7u9zXR18Dq/IRNcNxO+5ut8te41FleQb1ErCBgcxM5rCccJAuW+iNvHjPv5N53tY2 p4q2di4eQuvn41OA6evLc+VPTDHkjPzM+RbE0VsTTMI9d0Nj/aKSzo8rnnOHfkSfrNyi PDAw== Received: by 10.42.156.74 with SMTP id y10mr2052662icw.57.1333643412293; Thu, 05 Apr 2012 09:30:12 -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 v1sm3666191pbk.10.2012.04.05.09.30.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 09:30:11 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1645370pbb.31 for ; Thu, 05 Apr 2012 09:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.69 with SMTP id gw5mr8397929pbc.141.1333643410460; Thu, 05 Apr 2012 09:30:10 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 09:30:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 12:30:10 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8fb208dcbcce4204bcf10d81 X-Gm-Message-State: ALoCoQmZ/sQ5fDfpa9MYAC2J52hXJ3d7rYQiZ4nC6zMJ83Vfq8v1lwqbQBIpBgGAFfsxYt4GJmBP Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 16:30:13 -0000 --e89a8fb208dcbcce4204bcf10d81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2012 at 11:54 AM, I=F1aki Baz Castillo wrote= : > 2012/4/5 Roman Shpount : > It's possible, sure. First packets are handled in user space, and > later go to kernel space with conntrack rules. It's real and there are > two RTP proxies doing that: MediaProxy and irtpProxy. > > I do not believe either one of them does ICE-Lite to RTP. As far as I know, they are both RTP-to-RTP only. > > My proposal (DTLS-SRTP by default, > > SDES-SRTP from HTTPS sessions or RTP from HTTP session if enabled) got > > ignored as well. This at least inline with current HTTP(S) security > model. > > So you proposed allowing plain RTP and now just a new DTLS-XXXX-SRTP > is valid for you? :) > I am still proposing the same thing -- some new protocol instead of DTLS-SRTP, which does public key key exchange, and SDES-SRTP from HTTPS with RTP from HTTP if enabled. This should allow the widest possible interop without forcing a security model on them. I do not belive this compromises security since it allows the application developer pick the security model they want (new and most secure, old but interoperable, or none at all). ______________ Roman Shpount --e89a8fb208dcbcce4204bcf10d81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 11:54 A= M, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/4/5 Roman Shpount <roman@telurix.com>:
It's possible, sure. First packets are handled in user space, and=
later go to kernel space with conntrack rules. It's real and there are<= br> two RTP proxies doing that: MediaProxy and irtpProxy.

I do not believe either one o= f them does ICE-Lite to RTP. As far as I know, they are both RTP-to-RTP onl= y.
=A0
> My proposal (DTLS-SRTP by default,
> SDES-SRTP from HTTPS sessions or RTP from HTTP session if enabled) got=
> ignored as well. This at least inline with current HTTP(S) security mo= del.

So you proposed allowing plain RTP and now just a new DTLS-XXXX-SRTP<= br> is valid for you? :)

I am still proposing the same thing -- some new proto= col instead of DTLS-SRTP, which does public key key exchange, and SDES-SRTP= from HTTPS with RTP from HTTP if enabled. This should allow the widest pos= sible interop without forcing a security model on them. I do not belive thi= s compromises security since it allows the application developer pick the s= ecurity model they want (new and most secure, old but interoperable, or non= e at all).
______________
Roman Shpount
--e89a8fb208dcbcce4204bcf10d81-- From ibc@aliax.net Thu Apr 5 09:35: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 EF68C21F8710 for ; Thu, 5 Apr 2012 09:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.081, 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 RFgQNxltDm76 for ; Thu, 5 Apr 2012 09:35:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0954F21F8709 for ; Thu, 5 Apr 2012 09:35:30 -0700 (PDT) Received: by ggmi1 with SMTP id i1so902189ggm.31 for ; Thu, 05 Apr 2012 09:35:30 -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=9UcdCj2iKzaxzXyJCYHg3PTsekNWvwtdKcK75mM6oBQ=; b=WGC1cpOE1GHnbK/shqANCJNpxigFY6QtE1aEFQEhTdHe37qtFJsBRSqXEuAAaApZtO jRJusEarfpe/lMxySNZeIlRr/OUD2LIbmaNrTeDAnAM9LH/b0nY9+YnW2+ljpAbcSr0P /GCVwHrFtmkOksUZYLkUmMKHLVLxZnpoRc6BMI+1b//TnbUMJvhOHlsbDcRGDtc9uQjM sHcCeQpyvuH6JGH+vMggwyH7TEq16Gqp0To6FiKxF1Una/LfsI+9jwkyQtJzlBfOxtyK LauwDvsrtMcpRRAHOvBF6CYNwwfyFaJ07r43lTU2zWPojAJHL1+jOmjlYT7v+2ryN3Uw xmxA== Received: by 10.236.136.33 with SMTP id v21mr2926653yhi.17.1333643730518; Thu, 05 Apr 2012 09:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 09:35:10 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 18:35:10 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkXQBSm0i9O4caFZgC7BizleKBjHtbyh9/2mQYWQrIMYErnivs+3aehXCchnaOEOMJvoT9W Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 16:35:32 -0000 2012/4/5 Roman Shpount : >> 2012/4/5 Roman Shpount : >> It's possible, sure. First packets are handled in user space, and >> later go to kernel space with conntrack rules. It's real and there are >> two RTP proxies doing that: MediaProxy and irtpProxy. >> > I do not believe either one of them does ICE-Lite to RTP. As far as I kno= w, > they are both RTP-to-RTP only. Sure. I just say that "it's feasible" to do. > I am still proposing the same thing -- some new protocol instead of > DTLS-SRTP, which does public key key exchange, and SDES-SRTP from HTTPS w= ith > RTP from HTTP if enabled. This should allow the widest possible interop > without forcing a security model on them. I do not belive this compromise= s > security since it allows the application developer pick the security mode= l > they want (new and most secure, old but interoperable, or none at all). draft required :) --=20 I=C3=B1aki Baz Castillo From lists@infosecurity.ch Thu Apr 5 10:05: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 8260321F8767 for ; Thu, 5 Apr 2012 10:05:02 -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 vmXpOO1rxJUJ for ; Thu, 5 Apr 2012 10:05:01 -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 918A521F8749 for ; Thu, 5 Apr 2012 10:05:01 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1037794wgb.13 for ; Thu, 05 Apr 2012 10:05:00 -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 :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=2vs9r8D/JnlFr+0tu0eOpzuMn4ud5GpOCXR2tEaFtWo=; b=jDG48IdpJMk5mYBqVUZU7d4QqrskclYtcQKZeyZSh/Nid4KxszvLJF6c2qh805OccD c6cvhFMfWI/a6O2GD2ciRQVw7ldaNM7277dEkM8DDwMD2EQ3lkx1bdng5Fh6n8zqMU8U jNacwG771H0YVCg/pRdOZ1A0gR9wOthSjwDbDUaYUpraql54n/VOb12Z10JhSCBRGCw6 Y9hHsCGG0wpiSs/hF2tS/U3J+iKQx8X/QfDFVGQ7tEfqM8DC5JIxzLwA23uNgi4Exu8q YovKKq3jXCUna+cJGKPmleu18dLKoIxgeecf9iz4cLl+QIgPKsz5raXTYpGHKdcreQW2 w61Q== Received: by 10.216.225.12 with SMTP id y12mr2085532wep.39.1333645500606; Thu, 05 Apr 2012 10:05:00 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id n20sm19276161wiw.5.2012.04.05.10.04.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 10:04:58 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7DD0B8.2030900@infosecurity.ch> Date: Thu, 05 Apr 2012 19:04:56 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlm8daVQ1La+M4/eJ4HPGybXA3D+G7DzMlNNqjj3mpdmahHwckE2PhK0EAuB/DljjQ/Zgrq Subject: [rtcweb] DTLS-SRTP with end-to-end security: Short Authentication String 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 Apr 2012 17:05:02 -0000 Hi, i've been reviewing the WebRTC security architecture and it seems to me that the authors did not considered the value of end-to-end security. DTLS-SRTP does not provide end-to-end security because it rely on third party of key authentication. In the RTCWeb security there is a proposed solution, to use SAS: http://tools.ietf.org/html/draft-ietf-rtcweb-security-02#section-4.3.2.2 SAS, Short authentication string, allow to achieve end-to-end security within the DTLS-SRTP end-to-end encryption protocol. Unfortunately the author of rtcweb-security described the SAS as a bad way to verify fingerprints. I would like to argue that SAS are instead a valuable, secure mechanism to provide end-to-end authentication to an end-to-end encryption system, thus realizing end-to-end security. I would like to bring the attention of the WG to provide a MANDATORY requirement to enable SAS verification. RFC 6189 (ZRTP) explain the reason why SAS are secure enough and the comments on the rtcweb-security draft should be reconsidered: http://tools.ietf.org/html/rfc6189#section-15 "Some questions have been raised about voice spoofing during the short authentication string (SAS) comparison. But it is a mistake to think this is simply an exercise in voice impersonation (perhaps this could be called the "Rich Little" attack). Although there are digital signal processing techniques for changing a person's voice, that does not mean a MiTM attacker can safely break into a phone conversation and inject his own SAS at just the right moment. He doesn't know exactly when or in what manner the users will choose to read aloud the SAS, or in what context they will bring it up or say it, or even which of the two speakers will say it, or if indeed they both will say it. In addition, some methods of rendering the SAS involve using a list of words such as the PGP word list[Juola2], in a manner analogous to how pilots use the NATO phonetic alphabet to convey information. This can make it even more complicated for the attacker, because these words can be worked into the conversation in unpredictable ways. If the session also includes video (an increasingly common usage scenario), the MiTM may be further deterred by the difficulty of making the lips sync with the voice-spoofed SAS. The PGP word list is designed to make each word phonetically distinct, which also tends to create distinctive lip movements. Remember that the attacker places a very high value on not being detected, and if he makes a mistake, he doesn't get to do it over. A question has been raised regarding the safety of the SAS procedure for people who don't know each other's voices, because it may allow an attack from a MiTM even if he lacks voice impersonation capabilities. This is not as much of a problem as it seems, because it isn't necessary that users recognize each other by their voice. It is only necessary that they detect that the voice used for the SAS procedure doesn't match the voice in the rest of the phone conversation." In any crypto-system if the user is not able to INDEPENDENTLY verify the integrity of the key exchange we refer it to END-TO-SITE SECURITY. In any crypto-system if the user is able to INDEPENDENTLY verify the integrity of the key exchange, we refer it to END-TO-END SECURITY. So basically WebRTC currently does NOT guarantee end-to-end security. But making SAS mandatory will allow independent way to verify the keys. Fabio From lists@infosecurity.ch Thu Apr 5 10:07: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 8B51721F8767 for ; Thu, 5 Apr 2012 10:07:20 -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 Aptmd2xFFLDK for ; Thu, 5 Apr 2012 10:07:19 -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 7D65821F872B for ; Thu, 5 Apr 2012 10:07:19 -0700 (PDT) Received: by werb10 with SMTP id b10so1199803wer.31 for ; Thu, 05 Apr 2012 10:07:18 -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=afkpmnPDX9vso33hy8GY4afKYhAk4aeWa2t42FFw/fE=; b=Us8o02LzbMJN69Lh1Y+yX7r14p/ZsjF/857iIKlF+xncPkBV7letMCLBM+qmRz82Wa buGmwwIxBOjjRijD1R34ODddI0CqVqY2HKN9oukJKf1Og09XdklO+QqehIqHqi6186ox dilLb73qaMJbEMRJzI+c015iyrsJXycfdZ+vp98PE6XyWH40gck9fidc1tu0mWgeO9zO xziToglJccd1zVcb4fChmPOl/sPPK3IKF56B5HXp5TAAJB2CyoHqiBEW8MsgEmAE8U2+ sxffCCyUu0I8Mo7stcCi+zmSfeCJI1IgGTjzldWUlg/ZoFVAvHRwJNDKPros87QzFcxy gbJA== Received: by 10.180.98.8 with SMTP id ee8mr6610217wib.14.1333645635461; Thu, 05 Apr 2012 10:07:15 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id o2sm19280867wiv.11.2012.04.05.10.07.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 10:07:13 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7DD13F.2010006@infosecurity.ch> Date: Thu, 05 Apr 2012 19:07:11 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> In-Reply-To: <4F7DBEFC.6040302@alcatel-lucent.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmoVHbFyvNZixIYAC1cgdcg5cTsBSmAswcwbQ5XEw0PYvIy87bvBqqBFL1nKWkKWYlYPkb2 Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 17:07:20 -0000 On 4/5/12 5:49 PM, Igor Faynberg wrote: > Fabio, > > I am finding these definitions hard to understand. I am afraid that > somehow the activity (encryption) gets mixed with the services > (confidentiality and authentication). > > I think your major point is that effective encryption must rely on > symmetric keys, and that the key distribution is crucial to ensuring > confidentiality provably. I agree with that. > > I also agree with sepating the case when session keys are handed out by > another entity (such as KDC) and the case where the keys are known only > to the end-points. The latter can be achieved with signed > Diffie-Hellman (using PKI, or PAK, or EKE). > > Confidentiality, of course, relies on authentication: If I encrypt > something with the key I share only with you, I'd better know that I > share this key ONLY with you. > > But I don't get the point of the taxonomy you propose... Well, the main point is that DTLS-SRTP claim to provide end-to-end encryption, however the user is not able to deliver "end-to-end security" . end-to-end encryption != end-to-end security . In the encryption technologies landscape, when we refer to end-to-end encryption we always refer to cryptographic architecture where the users communicating are guaranteed respect to the underlying transport and communication architecture. This bring a misleading concept on DTLS-SRTP in WebRTC because it's referred as end-to-end encryption, but it doesn't provide end-to-end security like other encryption technologies does (ZRTP, OpenPGP, OTR, etc). DTLS-SRTP rely on third party for security verification. DTLS-SRTP = end-to-site security SRTP-SDES = end-to-site security ZRTP = end-to-end security This means that DTLS-SRTP, from a trust-model point of view, does not provide end-to-end security because there will always be a trusted third party able to authorize Man in the Middle to do eavesdropping. >From that point of view SDES-SRTP provide very similar warranty, except that you have to trust only 1 third party rather than 2 third party. Fabio From roman@telurix.com Thu Apr 5 10:42: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 F0F9921F86D5 for ; Thu, 5 Apr 2012 10:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=0.251, 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 QiUAY9jNnj7q for ; Thu, 5 Apr 2012 10:42:26 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 98A6821F8692 for ; Thu, 5 Apr 2012 10:42:20 -0700 (PDT) Received: by dady13 with SMTP id y13so2600579dad.27 for ; Thu, 05 Apr 2012 10:42:20 -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=ls8qGDXpKYbcsazgRl2o5GYumKOJ9+/uG9gbiH/jgbo=; b=Xt6aiydTUt+dx+Z5eAK/oo6fF3TSRIac1awUPzvKaJ9kf4NrxY2F55SM99AZxXtJc2 DQc24AuSucPbsVrtQwPqOwNyVYDY2nZnvhKglfalvq6TGUBqun4woAlDrfi0tHKCcxMj /STx6v1bCPG94fSv8El9A+0RweyzN7zVE+QeyOsFji3Z7lhtouEqVIlwnFCMEY8pumiu zvZ2lAse1ENfFQSvHM00n6NJSnEd+HvPpLZg1/aTKpUg5htifxpdcpoqtwRnTNYuB8OO OLpIp4JGoG+MQf/gAEtPl5GbRlTzNju+Les80FGUGA7DQ8RVsiGcmqa9usBcUTpWEMv1 JY7g== Received: by 10.68.225.39 with SMTP id rh7mr8505314pbc.104.1333647740159; Thu, 05 Apr 2012 10:42:20 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id z1sm3806856pbc.38.2012.04.05.10.42.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 10:42:19 -0700 (PDT) Received: by dady13 with SMTP id y13so2600524dad.27 for ; Thu, 05 Apr 2012 10:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.234.228 with SMTP id uh4mr3585169pbc.78.1333647737834; Thu, 05 Apr 2012 10:42:17 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 10:42:17 -0700 (PDT) In-Reply-To: <4F7DD13F.2010006@infosecurity.ch> References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> Date: Thu, 5 Apr 2012 13:42:17 -0400 Message-ID: From: Roman Shpount To: "Fabio Pietrosanti (naif)" Content-Type: multipart/alternative; boundary=047d7b33da10ab4be704bcf20f8e X-Gm-Message-State: ALoCoQmI+Y77te7ctD75TJBQHEvEqxWMxE+DXKtKRY/9lB35EXpTwPZhmDuxhMJ5H5/qgjEapOwp Cc: rtcweb@ietf.org Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 17:42:27 -0000 --047d7b33da10ab4be704bcf20f8e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 5, 2012 at 1:07 PM, Fabio Pietrosanti (naif) < lists@infosecurity.ch> wrote: > This means that DTLS-SRTP, from a trust-model point of view, does not > provide end-to-end security because there will always be a trusted third > party able to authorize Man in the Middle to do eavesdropping. > Incorrect. If fingerprint is exposed and can be verified, DTLS-SRTP does provide end-to-end security. No third parties involved. ______________ Roman Shpount --047d7b33da10ab4be704bcf20f8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 1:07 PM= , Fabio Pietrosanti (naif) <lists@infosecurity.ch> wrote:
This means that DTLS-SRTP, from a trust-model point of view, does not
provide end-to-end security because there will always be a trusted third party able to authorize Man in the Middle to do eavesdropping.

Incorrect. If fingerprint is exposed and can be verified, DTL= S-SRTP does provide end-to-end security. No third parties involved.
______________
Roman Shpount
--047d7b33da10ab4be704bcf20f8e-- From ibc@aliax.net Thu Apr 5 10:44: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 4970C21F8702 for ; Thu, 5 Apr 2012 10:44:14 -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=[AWL=0.078, 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 g7NFu6wDYkMq for ; Thu, 5 Apr 2012 10:44:13 -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 33F6621F869D for ; Thu, 5 Apr 2012 10:44:13 -0700 (PDT) Received: by yhkk25 with SMTP id k25so970613yhk.31 for ; Thu, 05 Apr 2012 10:44:12 -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=xATHWTpzsH7m5hZaHwepwNigrgEzoh5MfwtFMzwteRQ=; b=Nu6ckIzsjWJDhHh+IWN4R1U122vI2efLmn9jGtLkEQWkmpNcRmeyu2DJa7dqnTEDsn aP/NCkBmtriI0d3Cz9GDcPBAyTCD1ablZa7A+xhM6KheJeVN14ISJeV5mX2ND9WrpBsy BOZIKcv+XLNjoRARtyq7qRWGmFJdOZh3tp9KvNrehR+6m0m7+eRkhbSRk3Y6WUT1v/Me RYaV4OJ2drLJmE2QYbFHtn7BubKFRlETUx6N69hAO/OzpwYv4rGcqTBZUmOhe+KKe8W9 ZggW/y66EqskZtD4N4p86LddbcboqKdchcw0s4VHNU4uw5Drql7OfNWGDrttZx0YDFs2 PADA== Received: by 10.236.156.230 with SMTP id m66mr3212934yhk.52.1333647852812; Thu, 05 Apr 2012 10:44:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 10:43:52 -0700 (PDT) In-Reply-To: References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 19:43:52 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk0X1Kb1TBHWBgBJohe4bw9hfxQj1w+2r5OL7wjpHegqyOW03cCxWseURcJiYT7iohtLzhT Cc: rtcweb@ietf.org Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 17:44:14 -0000 2012/4/5 Roman Shpount : > On Thu, Apr 5, 2012 at 1:07 PM, Fabio Pietrosanti (naif) > wrote: >> >> This means that DTLS-SRTP, from a trust-model point of view, does not >> provide end-to-end security because there will always be a trusted third >> party able to authorize Man in the Middle to do eavesdropping. > > > Incorrect. If fingerprint is exposed and can be verified, DTLS-SRTP does > provide end-to-end security. No third parties involved. The fingerprint is included in the SDP which goes throught the Web server, right? You know what I mean ;) --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Thu Apr 5 10:45: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 6987321F8702 for ; Thu, 5 Apr 2012 10:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=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 6Z2EG-it+SrC for ; Thu, 5 Apr 2012 10:45: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 94D9221F869D for ; Thu, 5 Apr 2012 10:45:53 -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 1SFqkq-0004rg-GS for rtcweb@ietf.org; Thu, 05 Apr 2012 12:45:52 -0500 Message-ID: <4F7DD97D.6050109@jesup.org> Date: Thu, 05 Apr 2012 13:42:21 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.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: 8bit 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] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 17:45:54 -0000 On 4/5/2012 9:53 AM, Roman Shpount wrote: > > On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo > wrote: > > 2012/4/5 Roman Shpount >: > > On the more serious note, very few SIP end points offer working > ICE support. > > So, in a large sense, interop with them is not an option. > > For me there is a BIG difference when a kind of B2BUA is required > (which involves signaling "transaction"). That's the barrier IMHO. > > ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see: > > http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png > > > This picture is not entirely correct -- ICE Lite proxy should be on both > SIP and Media path. I agree. > The problem arises when media encrypt/decrypt is required, and evenr > more when a key update in RTP (like the DTLS EKT update) must be > converted into a signaling re-INVITE by a super Signaling+Media B2BUA: > > http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png > > Not sure why key update needs to be converted into signaling if media is > re-encrypted. Key updates on both sides of the proxy are independent. > Such proxy can also change SDES-SRTP key on each re-INVITE initiated by > either side, but apart from doing actual encryption/decryption, > operation wise it should not be any different then ICE-Lite proxy. I think he's assuming the gateway/B2BUA would not decrypt/re-encrypt, but would proxy keys from one protocol to the other. That's obviously lower overhead, but a more complex protocol. I have never assumed that proxying of keys would be the default. > > > Out of the ones > > that do support ICE and SRTP, very few are actually connected > directly to a > > public internet. Most of them are connected to some sort of PBX > or an IP PBX > > type service. So, in reality you do not need to bridge every IP > phone with > > WebRTC. > > That is a *very* limited scope of what WebRTC can provide. An IT > department should be able to deploy its own WebRTC infrastructure (a > Web+WebSocket server) within its "local" network, so browsers > accessing to such a local website share the network with SIP/XMPP > phones/devices/softphones. > > Please don't imagine WebRTC and SIP interop as the communication > between two islands ;) > > > I actually do imagine WebRTC/SIP interop as two islands. If we need to > proxy media and convert Web+WebSocket into SIP this is a definition of > island bridge for me. > > > If a few PBX and hosted centrex vendors will add support for WebRTC > > required features, we will get compatibility with existing end > points. > > Pure SIP proxies do exist. A PBX is not always needed, so again, SIP > world does not require to be "an island". > > > Once again, if SIP proxy is combined with media proxy, you can bridge > SIP and WebRTC, even if DTLS-SRTP is used. > > > To support the rest you will need to deploy some sort of gateway. > > Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent > mails about SDES and DTLS). > > Once again, we still need a gateway to support ICE. If end point is > adding ICE to interop with WebRTC, why not add DTLS-SRTP at the same time. > > > hurdle (I am trying to be politically correct here). WebRTC > enabled end > > points, on the other hand, will offer significant benefits to > traditional > > SIP phones, since they will allow development of higher quality > integrated > > real time communications services. I hope this will drive a much > quicker > > standard adoption. > > The problem is that there is a *NEW* SRTP related spec for WebRTC: > > http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-03 > > Maybe it could also become a standard for SIP? I hope, but currently > it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a > island. > > > Same as above. > > P.S. I actually do not like DTLS-SRTP, since it does not have a large > installed base, comes with too many features, slows down call setup, > will requirecomplex interop and such. At the same time I do not think > that interop with legacy SDES-SRTP is a reason not to use it. I believe > we should design a new key exchange method, that can be mapped to > SDES-SRTP via signaling alone, addresses SDES-SRTP issues (transmitting > keys over clear channel in signaling, replay of signaling) without > introducing all the problems related to DTLS-SRTP. Any number of methods > using public key based exchange over signaling and ICE should do the trick. I find this argument more compelling than the previous one. Call setup is certainly an issue (though I believe there are answers to it). If there's a good alternative (and of course I remember the IETF presentation from a number of years ago that showed all 14 or so extant key-exchange methods, none of which was an obvious choice (witness all the problems actually ever agreeing on one, which is why SDES has become the lowest-common-denominator exchange, even though most don't actually use it). However, the bar for introducing Yet Another Key Exchange Protocol at this late date is pretty darn high, unless it's amazingly simple (and likely insecure or with other unwelcome properties) or a modification of an existing protocol. I strongly dislike SDES for a number of reasons - not solely that the key is exposed to the server (as in the server/app may be evil or hacked), but exposure of the keys will likely engender requirements from authorities to record keys to allow for later decryption of media. That's a direct threat to privacy (especially given many organizations willingness to provide access without legal orders). Also, once those keys are recorded, the database of such keys becomes a tempting target in of itself (though it's only of use to someone tapping the raw packets, which limits the exposure - governments generally have no problem getting that; individuals have more problems (but can)). And as mentioned earlier, it makes the servers much more of a target for hacking and requests/orders from authorities. -- Randell Jesup randell-ietf@jesup.org From igor.faynberg@alcatel-lucent.com Thu Apr 5 10:55: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 842CC21F875D for ; Thu, 5 Apr 2012 10:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.227 X-Spam-Level: X-Spam-Status: No, score=-8.227 tagged_above=-999 required=5 tests=[AWL=-1.628, 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 c9AFA2haP9AN for ; Thu, 5 Apr 2012 10:55:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E9BB821F8753 for ; Thu, 5 Apr 2012 10:55:11 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q35HtASK012310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Apr 2012 12:55:11 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q35HtAkT031886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Apr 2012 12:55:10 -0500 Received: from [135.244.43.110] (faynberg.lra.lucent.com [135.244.43.110]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q35HtAhR003963; Thu, 5 Apr 2012 12:55:10 -0500 (CDT) Message-ID: <4F7DDC7D.7040001@alcatel-lucent.com> Date: Thu, 05 Apr 2012 13:55:09 -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: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> In-Reply-To: <4F7DD13F.2010006@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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP) 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, 05 Apr 2012 17:55:12 -0000 On 4/5/2012 1:07 PM, Fabio Pietrosanti (naif) wrote: > ... > Well, the main point is that DTLS-SRTP claim to provide end-to-end > encryption, however the user is not able to deliver "end-to-end security" . > > end-to-end encryption != end-to-end security . Yes, so far this is how I read the present state of affairs. We had a very interesting meeting with BrowserID people, but it was too short--at least for me--to figure everything out. I find the issue of self-signed certificates problematic, too. DTLS-SRTP would provide end-to-end security though if 1) the end points had a common PKI chain of trust or 2) if each of them could be authenticated to another by an assertion from a trusted IdP. In neither case there would be a key escrow, right? A level below is the KDC (Kerberos-like) arrangement. Here both end points would need to trust the KDC, and there are serious business cases for that. > ... > This bring a misleading concept on DTLS-SRTP in WebRTC because it's > referred as end-to-end encryption, but it doesn't provide end-to-end > security like other encryption technologies does (ZRTP, OpenPGP, OTR, etc). > > DTLS-SRTP rely on third party for security verification. > > DTLS-SRTP = end-to-site security > SRTP-SDES = end-to-site security > ZRTP = end-to-end security > > This means that DTLS-SRTP, from a trust-model point of view, does not > provide end-to-end security because there will always be a trusted third > party able to authorize Man in the Middle to do eavesdropping. > > > From that point of view SDES-SRTP provide very similar warranty, except > that you have to trust only 1 third party rather than 2 third party. Yes, now I understand what you were saying. I agree. SRTP-SDES is, in fact, what should work with KDC. And, to throw oil to the fire, did take a look at IBAKE RFCs? This provides an interesting example of what you call end-to-site. Igor From lists@infosecurity.ch Thu Apr 5 11:10: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 68D5721F85A5 for ; Thu, 5 Apr 2012 11:10:47 -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 v0boIlyFbUyU for ; Thu, 5 Apr 2012 11:10:46 -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 42CCA21F8601 for ; Thu, 5 Apr 2012 11:10:45 -0700 (PDT) Received: by werb10 with SMTP id b10so1237257wer.31 for ; Thu, 05 Apr 2012 11:10:40 -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:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=CX0pxSyFOr1quaXTMgnhK7MC3RP5vd0wW49JlJplk3U=; b=Uii6/UVn6qu66bXXJ6V4cTqs31ovz+4oa4T5QVE6ouososSD41/s/d/b+ivxatrWN0 vd0gtLwRnxPPMyMJj3y3feofdcqGBRIRnHqP6zd6oZZRx1gHBTlWT+6bT3tgvPsWw87K Xa8zOYwuHX1uvWEoNGwvRHRuqcJ0g945TtBh1XK+aNUvndVtsgjxhePf/EWkLcTBbNSX hArvctJVer/zs40RJz1EYPj5bta8rLGGlqrex6Eq3RmYG+bPtLlv7nwARWOtIcExU4Bd roROSE1m/VSNb024fNL3GufolCDJlDAKSBSnGxN+EmtGyvd56F9yXVv9LZ2M1zeMjINg RXEQ== Received: by 10.216.137.149 with SMTP id y21mr2231286wei.110.1333649440356; Thu, 05 Apr 2012 11:10:40 -0700 (PDT) Received: from sonyvaiop13.local (93-32-161-128.ip34.fastwebnet.it. [93.32.161.128]) by mx.google.com with ESMTPS id ff2sm19963404wib.9.2012.04.05.11.10.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 11:10:38 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F7DE01C.4040800@infosecurity.ch> Date: Thu, 05 Apr 2012 20:10:36 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlXj/ju5czVNJOaJIF9PvHh3zmOi1VxhmqvP5pzQ3yerI/ppvTiqLcWxDZZ/NZw4iUuAbsa Cc: rtcweb@ietf.org Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 18:10:47 -0000 On 4/5/12 7:42 PM, Roman Shpount wrote: > > On Thu, Apr 5, 2012 at 1:07 PM, Fabio Pietrosanti (naif) > > wrote: > > This means that DTLS-SRTP, from a trust-model point of view, does not > provide end-to-end security because there will always be a trusted third > party able to authorize Man in the Middle to do eavesdropping. > > > Incorrect. If fingerprint is exposed and can be verified, DTLS-SRTP does > provide end-to-end security. No third parties involved. No, you are wrong in the understanding. The fingerprint is always delivered from the signaling services, so by the HTTPS website providing the JS calling application. >From : RTCWEB Security Architecture http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-4.1 4.1. Initial Signaling [...] In either case, it will contain: o Media channel information o ICE candidates o A fingerprint attribute binding the communication to Alice's public key [RFC5763] [...] This message is sent to the signaling server, e.g., by XMLHttpRequest [XmlHttpRequest] or by WebSockets [RFC6455] The signaling server processes the message from Alice's browser So basically the "signaling service" provide the fingerprint information. Additionally, in case you want to trust the fingerprint verification via an identity provider, please read below: From: RTCWEB Generic Identity Provider Interface http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-00#section-5.4.1 5.4.3.1. Authenticating Party [...] o If a IdP is provided by the calling application use that. The IdP is provide *by the signaling service*. So basically: - The user get the calling application from signaling service - The user get the fingerprint from signaling service - The user get the IdP from the signaling service So basically the signaling service can ALWAYS do MITM and provide eavesdropping services to authorized and non-authorized users. >From a trust model point of view: DTLS-SRTP = SDES-RTP Because in both case the "signaling service" is a trusted third party able to intercept phone calls. It's important to define clearly somewhere that "WebRTC does not provide end-to-end security" Fabio From roman@telurix.com Thu Apr 5 11:14: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 D90C621F860E for ; Thu, 5 Apr 2012 11:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=0.230, 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 uYG1CNrUv49T for ; Thu, 5 Apr 2012 11:14:08 -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 365A821F8604 for ; Thu, 5 Apr 2012 11:14:08 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1716939pbb.31 for ; Thu, 05 Apr 2012 11:14:08 -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=4HxyOPPOZ/O5Qlnt630omUp+C32c/MqmgjnS1/vlYsc=; b=DqWlKRfFfL1rBHyicn+ANvu95SZ9hGsSKIqHR7z2SxiJqWbT/FI00FE2pyWNapHfQq JUOea3yjnWpkXZQ63Tsf/FquKhoqzBkIrdSXgSAu7fqKpTh0U0HkFhK2+iaveAMW4ICj jtfceMFJChXuYjsrHgTz21FU3tOgYAEX9eIdiacLkw6oQT6p74gipuP6J+RsBVWI1CYF 8YnZZdWnFXw4H5oNMzPV5w6Zr96FGzAFl/2E1QfucVpO+aSTH1KwgNpR3gS8x5mCwn/l a9XM7AeiJq3+QdTP99byS47QoXlFmF3Nt8drjbMHMvIfMjgCfsXIbLMrj4EMwml+Lwlt RfaA== Received: by 10.68.129.133 with SMTP id nw5mr8736894pbb.159.1333649648001; Thu, 05 Apr 2012 11:14:08 -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 l1sm3872560pbs.34.2012.04.05.11.14.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 11:14:07 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1716911pbb.31 for ; Thu, 05 Apr 2012 11:14:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.134.136 with SMTP id pk8mr8767809pbb.99.1333649646446; Thu, 05 Apr 2012 11:14:06 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 11:14:06 -0700 (PDT) In-Reply-To: <4F7DD97D.6050109@jesup.org> References: <4F7DD97D.6050109@jesup.org> Date: Thu, 5 Apr 2012 14:14:06 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=047d7b10d0676e679904bcf2812b X-Gm-Message-State: ALoCoQnyUbf4cWWgTGEKoWqybFDRMawNYV4I5rcn7bkrfa1YYSaegH4WXU95X+wqr8tUpYW+0fvH Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 18:14:09 -0000 --047d7b10d0676e679904bcf2812b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 5, 2012 at 1:42 PM, Randell Jesup wrote: > However, the bar for introducing Yet Another Key Exchange Protocol at this > late date is pretty darn high, unless it's amazingly simple (and likely > insecure or with other unwelcome properties) or a modification of an > existing protocol. > > My issue is that patching DTLS-SRTP also comes with a fairly high cost now and for the foreseeable future, since each of the patches will require an independent interop. We either need to define and make all of those patches a requirement, or each end point communicating with WebRTC will need to verify if public-key exchange is supported, if ICE key exchange is supported , and such. Each option provides a different key exchange path, which would be a challenge for interop and provide a potential attack vector (from my experience, protocols with a lot of complex scenarios serving the same purpose are typically easier to break into). > I strongly dislike SDES for a number of reasons - not solely that the key > is exposed to the server (as in the server/app may be evil or hacked), but > exposure of the keys will likely engender requirements from authorities to > record keys to allow for later decryption of media. That's a direct threat > to privacy (especially given many organizations willingness to provide > access without legal orders). Also, once those keys are recorded, the > database of such keys becomes a tempting target in of itself (though it's > only of use to someone tapping the raw packets, which limits the exposure - > governments generally have no problem getting that; individuals have more > problems (but can)). And as mentioned earlier, it makes the servers much > more of a target for hacking and requests/orders from authorities. > I dislike SDES for being a "somewhat secure" protocol. This is a very dangerous territory where end user is under impression of being protected, but reality is different. IMHO, in such situations it is better to have no security at all, so that users know not to do anything they will regret. ______________ Roman Shpount --047d7b10d0676e679904bcf2812b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 1:42 PM= , Randell Jesup <randell-ietf@jesup.org> wrote:
However, the bar for introducing Yet Another Key Exchange Protocol at this = late date is pretty darn high, unless it's amazingly simple (and likely= insecure or with other unwelcome properties) or a modification of an exist= ing protocol.

My issue is that patching DTLS-SRTP also comes with a= fairly high cost now and for the foreseeable future, since each of the pat= ches will require an independent interop. We either need to define and make= all of those patches a requirement, or each end point communicating with W= ebRTC will need to verify if public-key exchange is supported, if ICE key e= xchange is supported , and such. Each option provides a different key excha= nge path, which would be a challenge for interop and provide a potential at= tack vector (from my experience, protocols with a lot of complex scenarios = serving the same purpose are typically easier to break into).
=A0
I strongly dislike SDES for a number of reasons - not solely that the key i= s exposed to the server (as in the server/app may be evil or hacked), but e= xposure of the keys will likely engender requirements from authorities to r= ecord keys to allow for later decryption of media. That's a direct thre= at to privacy (especially given many organizations willingness to provide a= ccess without legal orders). =A0Also, once those keys are recorded, the dat= abase of such keys becomes a tempting target in of itself (though it's = only of use to someone tapping the raw packets, which limits the exposure -= governments generally have no problem getting that; individuals have more = problems (but can)). =A0And as mentioned earlier, it makes the servers much= more of a target for hacking and requests/orders from authorities.

I dislike SDES for being a "somewhat secure&quo= t; protocol. This is a very dangerous territory where end user is under imp= ression of being protected, but reality is different. IMHO, in such situati= ons it is better to have no security at all, so that users know not to do a= nything they will regret.
______________
Roman Shpount
--047d7b10d0676e679904bcf2812b-- From roman@telurix.com Thu Apr 5 11:17: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 65ADE21F869F for ; Thu, 5 Apr 2012 11:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=0.212, 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 Fal6nx6NSi3p for ; Thu, 5 Apr 2012 11:17:23 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id B789721F869C for ; Thu, 5 Apr 2012 11:17:23 -0700 (PDT) Received: by dady13 with SMTP id y13so2647578dad.27 for ; Thu, 05 Apr 2012 11:17:23 -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=fRfCqv7sAiicwM2UcNFTuQSrnxyvVlHy975v+/GhkZY=; b=NCbQcVyiGMo4E09srssAFD+6Kwlm6O/19FPlD8dOUmEL8k9dQjNuSM9pWyswE2hpAN pziWco6ntc7iLY78Adm0lPr50Yl6MnJTE4GRhCymt/80yBlWJXQktv2HXZWJdxe0Cai7 BGUbHVs5/IDPlEuFryg4g3RVIgZOxMiQ152vxQiuk6WCr37xmY3uR7ivR/9VMc4NPDzM 3SKaECMMkVxxiP4A3gN34psmQdBPJqfxrYn9y7AMeqjz+PmzRbAd8tvY/shQZBiGXaRI PLUpdShQJfRM/R5PCh5jBfxVSLSWpwN54kxUE+0N0/frdwApfy2OdAni09HdfHCizpVY i32g== Received: by 10.68.194.103 with SMTP id hv7mr6742098pbc.133.1333649843560; Thu, 05 Apr 2012 11:17:23 -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 y2sm3868256pbe.67.2012.04.05.11.17.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 11:17:22 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1719718pbb.31 for ; Thu, 05 Apr 2012 11:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.234.228 with SMTP id uh4mr3837414pbc.78.1333649841891; Thu, 05 Apr 2012 11:17:21 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 11:17:21 -0700 (PDT) In-Reply-To: <4F7DE01C.4040800@infosecurity.ch> References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> <4F7DE01C.4040800@infosecurity.ch> Date: Thu, 5 Apr 2012 14:17:21 -0400 Message-ID: From: Roman Shpount To: "Fabio Pietrosanti (naif)" Content-Type: multipart/alternative; boundary=047d7b33da1014a87804bcf28d42 X-Gm-Message-State: ALoCoQlBmilZRMponeEJ0JaZPEpPRnFRZ0NPWmN2zxmZALqc666FRz1yNcRHp/biOcmMFfrQ4NTB Cc: rtcweb@ietf.org Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 18:17:24 -0000 --047d7b33da1014a87804bcf28d42 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 5, 2012 at 2:10 PM, Fabio Pietrosanti (naif) < lists@infosecurity.ch> wrote: > On 4/5/12 7:42 PM, Roman Shpount wrote: > > > > On Thu, Apr 5, 2012 at 1:07 PM, Fabio Pietrosanti (naif) > > > wrote: > > > > This means that DTLS-SRTP, from a trust-model point of view, does not > > provide end-to-end security because there will always be a trusted > third > > party able to authorize Man in the Middle to do eavesdropping. > > > > > > Incorrect. If fingerprint is exposed and can be verified, DTLS-SRTP does > > provide end-to-end security. No third parties involved. > > No, you are wrong in the understanding. > > The fingerprint is always delivered from the signaling services, so by > the HTTPS website providing the JS calling application. > > If fingerprint is exposed to the user and be compared through some alternative communications channel, the it can provide an independent security validation similar to the one used in ZRTP. If signaling server replaces the fingerprint for some sort of attack this can be detected, even though it can be argued that very few people will do so. ______________ Roman Shpount --047d7b33da1014a87804bcf28d42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 5, 2012 at 2:1= 0 PM, Fabio Pietrosanti (naif) <lists@infosecurity.ch> wrote:
On 4/5/12 7:42 PM, Roman Shpount wrote:
>
> On Thu, Apr 5, 2012 at 1:07 PM, Fabio Pietrosanti (naif)
> <l= ists@infosecurity.ch <mailto:lists@infosecurity.ch>> wrote:
>
> =A0 =A0 This means that DTLS-SRTP, from a trust-model point of view, d= oes not
> =A0 =A0 provide end-to-end security because there will always be a tru= sted third
> =A0 =A0 party able to authorize Man in the Middle to do eavesdropping.=
>
>
> Incorrect. If fingerprint is exposed and can be verified, DTLS-SRTP do= es
> provide end-to-end security. No third parties involved.

No, you are wrong in the understanding.

The fingerprint is always delivered from the signaling services, so by
the HTTPS website providing the JS calling application.

If fingerprint is exposed to the user and be compared= through some alternative communications channel, the it can provide an ind= ependent security validation similar to the one used in ZRTP. If signaling = server replaces the fingerprint for some sort of attack this can be detecte= d, even though it can be argued that very few people will do so.
______________
Roman Shpount
--047d7b33da1014a87804bcf28d42-- From ibc@aliax.net Thu Apr 5 11:20: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 D175621F86A3 for ; Thu, 5 Apr 2012 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=0.074, 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 dvgfnE7FKXgH for ; Thu, 5 Apr 2012 11:20:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4621F8692 for ; Thu, 5 Apr 2012 11:20:00 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1006490ggm.31 for ; Thu, 05 Apr 2012 11:20:00 -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=DkDIczqEwj5+ut8Kz70qAbk/tO6L8yCRDfPTu4762I4=; b=B0oer1meaxOuPXEW28HknzpvnNwffYW3RX4vbkyFbuJoutwJmCw0VYxsYlaUQcZV3U Kpjo68Zytrzg6bHR/cgrc5B0Du8BBIgdMzpJUNrZkk+oPZZDQLnxmLtzk6aBfWQQrpky 5/sxPi/vfsGQ3deRuP2J/FTt0UbOHX++Hwrs6CbZb6f8JWa8ALQG/v5B8uq4yir5gswi UmfY6EM5FyUZE+UhnfNGLNG3+BMTHC8Zp0TuuzgQpWylfDeuOhYghipLOc94gM/LMHPf peQQhwnpd0bz7S0i6Sm0AqGE7UpoZSrS70DA66bJa8vw3VFqJ67sd5+kzGdpeQQIj6VN 7o4Q== Received: by 10.101.180.17 with SMTP id h17mr1040268anp.51.1333649999903; Thu, 05 Apr 2012 11:19:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 11:19:39 -0700 (PDT) In-Reply-To: References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> <4F7DE01C.4040800@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 20:19:39 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQloFMr/lEqiQF4PVziONIC4L8DX3VHdUOcgc16B1Dr46l8VNNTiJHB70h6Dvi4C4B/nuMWk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 18:20:00 -0000 2012/4/5 Roman Shpount : >> The fingerprint is always delivered from the signaling services, so by >> the HTTPS website providing the JS calling application. >> > If fingerprint is exposed to the user and be compared through some > alternative communications channel, the it can provide an independent > security validation similar to the one used in ZRTP. Define such an "alternative communications channel" and explain me how the signaling server cannot alter that channel. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Apr 5 11:21: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 A0FA021F84B5 for ; Thu, 5 Apr 2012 11:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=0.071, 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 2-ibNYxyDU8V for ; Thu, 5 Apr 2012 11:21:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFC821F863B for ; Thu, 5 Apr 2012 11:21:25 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1012040ghb.31 for ; Thu, 05 Apr 2012 11:21:25 -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=NPm6Dip+c+hZEiSCuSygI0xqMHm0IO569G16PURg62o=; b=RPYwySsAPRPc1gPpPHV29GmWd5JXlcorXYkrIivVVl12x2Mz5p8jYT/BjbhcCYSj4a gaCSq6GDIleuupDmkZd+AJdMEWywnGooIZIPST9oxp7KgRa8O5sUpH9BurbOUW3O78OR PmrO6RH/hhqhe0pxaDZtVGvcZUa/WSXG791cV3UGopEXt27kdG3BKqTopKqIaqlpsmEJ +Yb8F8djFKYOrtXNQvNDQloS8KqLVQLk9YsSRvAguQztG17LOkEjjGkzlK7yLP6gsmSh eTc9UtYrJDe66DfzjeavDXm3XumPakVGn76uF2TT2Br8HI/YwSvv7ADx2MGpwmm2twe2 rNgw== Received: by 10.236.156.230 with SMTP id m66mr3402751yhk.52.1333650085151; Thu, 05 Apr 2012 11:21:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 11:21:04 -0700 (PDT) In-Reply-To: References: <4F7DD97D.6050109@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 20:21:04 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmlXbteP9ORFLQ1iUydz84nwCbEnCf1i8HZmfaMThYNRSufflCinKZkBaDps7E9S1zhpJ63 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 18:21:26 -0000 2012/4/5 Roman Shpount : > I dislike SDES for being a "somewhat secure" protocol. This is a very > dangerous territory where end user is under impression of being protected= , > but reality is different. IMHO, in such situations it is better to have n= o > security at all, so that users know not to do anything they will regret. And the same is true for DTLS, so? --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu Apr 5 11:24: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 DC2B621F84B5 for ; Thu, 5 Apr 2012 11:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.047, 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 lxLtL9TxWtH9 for ; Thu, 5 Apr 2012 11:24:22 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0491421F86AA for ; Thu, 5 Apr 2012 11:24:21 -0700 (PDT) Received: by dady13 with SMTP id y13so2656242dad.27 for ; Thu, 05 Apr 2012 11:24: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cUFMVdlz8ib6GL2pcNcbEYjXEvaUs74UQBRxmNuTE/c=; b=JcW2g05F3TaEHVNCwG3M4qEk2lCSYlU/qEKZxyQoP0muKC7sYyxHPRB3aW9zEiKATX dS6U9X8JhAGoh7bC82JlNqq+11zyhteD58Mv3DmjQwWqePuAo5o+p+nwrICraaDfbnug Wd84BTyts8LfObLWI7bc4cVrzRLanhQRYnGamD79BOQK1dOzJTBhCoLXmeb4VZLCwNo/ BWIxCol7q10EKI5Mvlroiya28QqJ9J75Wka0NS6kkL3DFqBdnb9gCtI2ll11kJ88XPpQ fOLCxTzm7h/35CRqQsfB5CRacYXE3zhtlskY8Nz6+FN8nZd5rmOJtNsRgL7E42lffKnE nx6w== Received: by 10.68.234.228 with SMTP id uh4mr3889888pbc.78.1333650261859; Thu, 05 Apr 2012 11:24:21 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id f7sm3900158pbr.3.2012.04.05.11.24.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 11:24:21 -0700 (PDT) Received: by dady13 with SMTP id y13so2656215dad.27 for ; Thu, 05 Apr 2012 11:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.42 with SMTP id rp10mr8651612pbc.162.1333650260391; Thu, 05 Apr 2012 11:24:20 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 11:24:20 -0700 (PDT) In-Reply-To: References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> <4F7DE01C.4040800@infosecurity.ch> Date: Thu, 5 Apr 2012 14:24:20 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8ff2521c0675f904bcf2a6c6 X-Gm-Message-State: ALoCoQnK2HNJqVg5Zp5qHrnZE3j0mr8emY1dQu9kDf9lfDKo8Kqe1Cauhn/o+Vp55bMla58NxXcP Cc: rtcweb@ietf.org Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 18:24:23 -0000 --e89a8ff2521c0675f904bcf2a6c6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2012 at 2:19 PM, I=F1aki Baz Castillo wrote: > Define such an "alternative communications channel" and explain me how > the signaling server cannot alter that channel. > > I will send it to you using Frogo, my trusty carrier pidgin ;). I can read them to you (possible to modify but much harder then simple signaling), I can email them to you using some sort of trusted service, or I can call you using old fashioned telephone. I remember times when such keys were exchanged via fax. ______________ Roman Shpount --e89a8ff2521c0675f904bcf2a6c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 2:19 PM= , I=F1aki Baz Castillo <ibc@aliax.net> wrote:
Define such an "alternative communications channel" and explain m= e how
the signaling server cannot alter that channel.


I will send it to you using= Frogo, my trusty carrier pidgin ;).

I can read them to you (possibl= e to modify but much harder then simple signaling), I can email them to you= using some sort of trusted service, or I can call you using old fashioned = telephone. I remember times when such keys were exchanged via fax.
______________
Roman Shpount
--e89a8ff2521c0675f904bcf2a6c6-- From roman@telurix.com Thu Apr 5 11:37: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 1E21121F8642 for ; Thu, 5 Apr 2012 11:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.044, 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 shVjvk1TJDYh for ; Thu, 5 Apr 2012 11:37:26 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id EC48C21F85E5 for ; Thu, 5 Apr 2012 11:37:25 -0700 (PDT) Received: by dady13 with SMTP id y13so2673284dad.27 for ; Thu, 05 Apr 2012 11:37:25 -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=2VB9DfXtfHuaYvmRjnGpkVpyG8BBDAg8ZGZYZUN3jxk=; b=X06jE2H7pAqeBIJIY74Mv18lhrDxibkQukpUNJLLEPEh7CF/sSMJtGQY6An9FaGhBc krS1lg/leJxlsHgtCzG3EdTx3nGNo7n2XHuTDPClrfQmgyE/IsSe7MPo2OGegwSmF54c c2B9I1hxbxrTJZoNBV9ANc8CT1Ims8IiIG3hL0LoOXjYZjOa2u5VSHXCCWWhGSmcNveu JVZczgDx3V6LTPeWyOE/M4+/LSesW7jtY2XUWv3Xi1q6YJ02Kq34jwUfwPdsf3cBQurt GQ2m0Tfd9F4W/WFl+x+OMqhOjXEqPgxrJSySzkANecVu4EgyI94u1TFU7pdeGg8Zsi8k TOog== Received: by 10.68.213.230 with SMTP id nv6mr9032014pbc.69.1333651045755; Thu, 05 Apr 2012 11:37:25 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id mg3sm3913300pbc.51.2012.04.05.11.37.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 11:37:24 -0700 (PDT) Received: by dady13 with SMTP id y13so2673240dad.27 for ; Thu, 05 Apr 2012 11:37:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.72.138 with SMTP id d10mr6442000pbv.15.1333651044132; Thu, 05 Apr 2012 11:37:24 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 11:37:23 -0700 (PDT) In-Reply-To: References: <4F7DD97D.6050109@jesup.org> Date: Thu, 5 Apr 2012 14:37:23 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d040f9baebd677104bcf2d41c X-Gm-Message-State: ALoCoQnPC0pzGR7wa/K2jw02ztJl+3knASMB+yGSYSHzoCWvIKMeCY04wai0z0E4Jfhp3NA5TKCn Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 18:37:27 -0000 --f46d040f9baebd677104bcf2d41c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2012 at 2:21 PM, I=F1aki Baz Castillo wrote: > 2012/4/5 Roman Shpount : > > I dislike SDES for being a "somewhat secure" protocol. This is a very > > dangerous territory where end user is under impression of being > protected, > > but reality is different. IMHO, in such situations it is better to have > no > > security at all, so that users know not to do anything they will regret= . > > And the same is true for DTLS, so? > > This can be mitigated with either identity validation or via fingerprint validation via an independent channel. For SDES-SRTP the only way is secure is that everything on its path is secure, which is much harder to validate. _____________ Roman Shpount --f46d040f9baebd677104bcf2d41c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 2:21 PM= , I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2012/4/5 Roman Shpount <roman@telur= ix.com>:
> I dislike SDES for being a "somewhat secure&quo= t; protocol. This is a very
> dangerous territory where end user is under impression of being protec= ted,
> but reality is different. IMHO, in such situations it is better to hav= e no
> security at all, so that users know not to do anything they will regre= t.

And the same is true for DTLS, so?

This ca= n be mitigated with either identity validation or via fingerprint validatio= n via an independent channel. For SDES-SRTP the only way is secure is that = everything on its path is secure, which is much harder to validate.
_____________
Roman Shpount
--f46d040f9baebd677104bcf2d41c-- From ibc@aliax.net Thu Apr 5 11:41: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 A9EE421F869C for ; Thu, 5 Apr 2012 11:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=0.068, 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 LA6+0DHL9xlt for ; Thu, 5 Apr 2012 11:41:03 -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 227CD21F8686 for ; Thu, 5 Apr 2012 11:41:03 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1020980yhk.31 for ; Thu, 05 Apr 2012 11:41:02 -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=bI5gQHPbge7oom4siBUGsO2pkwhMFagbKjgEsFL4ScA=; b=PjzdUYxKSr7EBWnbHC4B0HrUv+p2bj+mhNeuBxPcKl2adSRhTSmBp+BexnxnYg82JC RJALJhvyYPztO99NmfH7lI+R5sqDiwtBm/+71eFm33UPi1u3jCNp0n0heRspetgdXMAZ uCSeUB6ELQQkVV/SnOnMnspkYDdjPpwel1yH/1qz9z1IowRSyAkh0RGGopMuNYYMtzt+ rRfvwe8y6Yny5HB/u4ewbpX3O0t6hgVbjGRLYHNYQpghNTeD087NcNWhPS+c+g4z4m5k m8i+KgQNwseDAD8jetwERdVnDagOTu8t6fh0I9uMq62CTScFZGdGPOLHUMRlJyizIzjE O39w== Received: by 10.236.136.33 with SMTP id v21mr3579194yhi.17.1333651262749; Thu, 05 Apr 2012 11:41:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 11:40:42 -0700 (PDT) In-Reply-To: References: <4F7DD97D.6050109@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 20:40:42 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnE43WzXH+VsYQnDpAFP0Y4zIwrrO69uM0GaZ1ZK33kRgEJcFmmj1vcvU1mLMZhjH5D6IL0 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need 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 Apr 2012 18:41:03 -0000 2012/4/5 Roman Shpount : > This can be mitigated with either identity validation This argument has been already refuted by Fabio, am I right? The identity is provided by the signaling server so nothing new here. > or via fingerprint > validation via an independent channel. Again, define such an "independent channel" and let me know how the signaling server CANNOT alter it. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Apr 5 11: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 C06F521F86C2 for ; Thu, 5 Apr 2012 11:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=0.066, 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 t9Ju9SSbQW0u for ; Thu, 5 Apr 2012 11:45:18 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A54B21F86A0 for ; Thu, 5 Apr 2012 11:45:18 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1028953ggm.31 for ; Thu, 05 Apr 2012 11:45: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=BcRkwJpmFwSx0nGALRLffda4U2VLjmFdk0Rts6gxI+M=; b=WiB/3meC5larsx/qZt3qZJydTYXjS+Nt9PzrKMPvuJozG/ufQ99gyIkZ0egMxUK4Pc DQ0p5Z/2gL2V2tHj3AqLBMHu+Yci9GWQZdzhHHAqKcc/UhdK1AmK3Dcv0lwGt7KaYSd9 s+gMEgv/BgwJOvNLNpHzCIP80HI7n+dp+lm+pNZZL0YDwivTZGN2c6jeDw+YkDQOh29q Bbyrtnz1s9b/uEbSMkbWXy+fYTl2wjge5Rdm3NZ0l8DKAydXTDu1SnFiFTPB09cqYoa/ J6pbEz9U6XERdPuiTUORWwXCv1AMuukoZwp1wVXi2PbcYhMi1aGYiTFHONRQHmQ+e/4P ht0w== Received: by 10.236.136.33 with SMTP id v21mr3599329yhi.17.1333651517802; Thu, 05 Apr 2012 11:45:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 11:44:57 -0700 (PDT) In-Reply-To: References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch> <4F7DE01C.4040800@infosecurity.ch> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Apr 2012 20:44:57 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkmtWP5i2JqovRXlWvh80LmBPuzqBpnkA5joAvATCvIqiU+ibuHKlH3t0aicOcI0lixznj4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Thu, 05 Apr 2012 18:45:18 -0000 2012/4/5 Roman Shpount : > On Thu, Apr 5, 2012 at 2:19 PM, I=C3=B1aki Baz Castillo w= rote: >> >> Define such an "alternative communications channel" and explain me how >> the signaling server cannot alter that channel. >> > > I will send it to you using Frogo, my trusty carrier pidgin ;). > > I can read them to you (possible to modify but much harder then simple > signaling), I can email them to you using some sort of trusted service, o= r I > can call you using old fashioned telephone. I remember times when such ke= ys > were exchanged via fax. So the success of DTLS (the "security end-to-end panacea") depends on two users of any web sharing their "keys" via email, phone, or fax... Did you forget the tag? XD --=20 I=C3=B1aki Baz Castillo From paulej@packetizer.com Thu Apr 5 11: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 D334521F86C2 for ; Thu, 5 Apr 2012 11:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 x-ABb+D44bxD for ; Thu, 5 Apr 2012 11:50:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B84CA21F86A0 for ; Thu, 5 Apr 2012 11:50:31 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q35IoUkG010417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 14:50:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333651831; bh=y7vqYAcj7HLluwoqaPQfblFgqZMtemHICZVarpTSLaU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qqw0UIhdCRVGzVgh7P4dYDe10Ft6lG+U13BJTKmL2Q3NwHzRoiTR1K40ESbdGnYaY YTf6ta1GnWHIVmeyWC0IaVrdsSK/ZW8ZBW6bXN/VbYcgDRF1u2u9MeERH9EU5RzTQ2 wqwK7UnoGTKkL62ShIKF0036HZb+odAVn2y8PmUk= From: "Paul E. Jones" To: "'Jean-Marc Valin'" References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> <4F7DB5DC.40507@mozilla.com> In-Reply-To: <4F7DB5DC.40507@mozilla.com> Date: Thu, 5 Apr 2012 14:50:35 -0400 Message-ID: <011e01cd135c$fcdc08d0$f6941a70$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNwB1VzUBAGtdKoUAdUR/YIBXjpAbJjqAzsw Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 05 Apr 2012 18:50:32 -0000 Jean-Marc, > Personally, I would be reluctant to indemnify anyone over IPR in a paper > clip. This is the sad state of the patent system and it applies to every > piece of technology. Oh, I agree with you. :-) > > Indeed, but I have a significantly higher level of confidence that I > > can identify all of the legitimate companies with IPR on H.264, > > whereas I haven't a clue where to start (outside of Google) for VP8. > > Obviously, that makes H.264 so much safer, right? > http://www.theregister.co.uk/2012/03/29/microsoft_motorola_patent_cases/ Motorola is a known patent holder. So if Microsoft. I assume Microsoft elected to ignore Motorola's patent claims, and I assume Motorola ignored Microsoft's patents, too, as I'm sure there would have been a reciprocity agreement in place otherwise. I don't know, but if you want to use H.264, then you would have known to talk to Motorola and MS. > > If I owned IPR on VP8 (which I don't personally; can't speak for my > > employer), I certainly would not tell you and I would not join a > > patent pool, either. I would wait until you adopt VP8, build it into > > software and hardware products, have it massively deployed, and then > > I'd come along and collect my royalties. There is absolutely no > > financial incentive for an IPR holder to join a patent pool. > > I assume this is why we've seen all these lawsuits against Google, > Microsoft, Cisco, Apple... over their use of Vorbis and Speex, right? > Seriously, I can count at least 10 free AV codecs and none of them have > had any patent lawsuits that I'm aware of. The "why" is unknown. It might be that a license was acquired. It might be that patent holders do not care since the same companies are already licensing their patents. Perhaps the usage is not as high as other codecs, including MP3 and G.729? The fact there isn't a lawsuit does not mean these are free from patents, unless the technology is so old patents are expired. (I think that's one argument for using H.261, in spite of its small video sizes.) > The best interest of a H.264 patent owner is to avoid having to disclose, > wait for adoption, and then be free to ask for a lot more than what they > would get from the patent pool. This is why I consider H.264 to be a > higher risk than VP8. The current Motorola lawsuit confirms this. The Motorola lawsuit does not confirm this at all. This is nothing but a fight between those two companies, both of which were likely aware of the others' IPR here. You're ignoring one point I made. Those involved in the creation of H.264 have quite likely filed IPR statements with ISO or ITU. If some other company were to come out of the closet on this with something that blindsides the industry, the industry would fight it. At the very least, whatever bit of IPR that is claimed would have to be put into perspective with respect to the other hundreds of patents on H.264. H.264 has already become widely deployed. Work is well underway on H.265 now. So, there are patent trolls out there, right now is the time to start filing lawsuits. And as I said, the reputable companies would have disclosed IPR and you'd know to talk to them. VP8 is a technology where nobody other than Google has to answer about IPR. BT, Oki, France Telecom, Qualcom, Nokia, Microsoft, Sony, NTT, Motorola, TI, etc. are not obligated to make a statement, yet it would not surprise me in the least if these companies do not have IPR. Whether the enforce it is another matter. They will only if it is in their interest. Paul From silviapfeiffer1@gmail.com Thu Apr 5 14:34: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 9EBCC21F85B4 for ; Thu, 5 Apr 2012 14:34:03 -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 vw5joigoXSFD for ; Thu, 5 Apr 2012 14:34:02 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1B021F85AE for ; Thu, 5 Apr 2012 14:34:02 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1159494ghb.31 for ; Thu, 05 Apr 2012 14:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1ra8IHzyxHfIRRE4i92anhcQzR6BVZfdJWpJ0MlOM0o=; b=fdg3AOq1c0m3M3aaSv2Dutq6A+HqYvzqo2zyQjtlf6odVfavmRJrTxI50TKYnSEwWz j3+e8iyCIwfowyzSbL0X4u7Gk8t90VvxxxvXh3yyb3BZX+jevcCtXPwykn8Q8ZDheuug 4upI+/5zQPwqUX8OWkAcY6i+GTnSJ+UWqZDtQkntTOfEAf1DFcWe1wisfmeHHX7K8WDd 1llO5IS87Siw723Y1HgNHQYRJ7pujBAQ78mJeXJQW7TH8Ag925mDMdmdMjLokXiG622X WRMPhuoSBk7b9y1mPxR+Q7KD0WM8dgE0HLQiNnah81DCQLwiugZIUyRKIwcqis8buqSe Aygg== Received: by 10.101.134.3 with SMTP id l3mr1280522ann.44.1333661642043; Thu, 05 Apr 2012 14:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.99.3 with HTTP; Thu, 5 Apr 2012 14:33:41 -0700 (PDT) In-Reply-To: <011e01cd135c$fcdc08d0$f6941a70$@packetizer.com> References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> <4F7DB5DC.40507@mozilla.com> <011e01cd135c$fcdc08d0$f6941a70$@packetizer.com> From: Silvia Pfeiffer Date: Fri, 6 Apr 2012 07:33:41 +1000 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 05 Apr 2012 21:34:03 -0000 On Fri, Apr 6, 2012 at 4:50 AM, Paul E. Jones wrote= : >> > Indeed, but I have a significantly higher level of confidence that I >> > can identify all of the legitimate companies with IPR on H.264, >> > whereas I haven't a clue where to start (outside of Google) for VP8. >> >> Obviously, that makes H.264 so much safer, right? >> http://www.theregister.co.uk/2012/03/29/microsoft_motorola_patent_cases/ > > Motorola is a known patent holder. =A0So if Microsoft. =A0I assume Micros= oft > elected to ignore Motorola's patent claims, and I assume Motorola ignored > Microsoft's patents, too, as I'm sure there would have been a reciprocity > agreement in place otherwise. =A0I don't know, but if you want to use H.2= 64, > then you would have known to talk to Motorola and MS. So what's the point in having the patent pool if you have to talk to all the individual patent owners anyway? >> > If I owned IPR on VP8 (which I don't personally; can't speak for my >> > employer), I certainly would not tell you and I would not join a >> > patent pool, either. =A0I would wait until you adopt VP8, build it int= o >> > software and hardware products, have it massively deployed, and then >> > I'd come along and collect my royalties. =A0There is absolutely no >> > financial incentive for an IPR holder to join a patent pool. >> >> I assume this is why we've seen all these lawsuits against Google, >> Microsoft, Cisco, Apple... over their use of Vorbis and Speex, right? >> Seriously, I can count at least 10 free AV codecs and none of them have >> had any patent lawsuits that I'm aware of. > > The "why" is unknown. It might be that a license was acquired. It might b= e > that patent holders do not care since the same companies are already > licensing their patents. =A0Perhaps the usage is not as high as other cod= ecs, > including MP3 and G.729? You might be surprised about the usage - a substantial amount of games use Vorbis because they don't have to pay for a license. Indeed, it is well known that Microsoft's Halo used Vorbis. For that very reason, I doubt that any of those companies acquired a patent license from any company claiming to own a patent on Vorbis or Speex. In fact, since nobody has claimed to have such patents, how would you even know who to license it from? > =A0The fact there isn't a lawsuit does not mean these > are free from patents, unless the technology is so old patents are expire= d. > (I think that's one argument for using H.261, in spite of its small video > sizes.) Existing lawsuits are the only quantitative measure that is available to find out about whether somebody is prepared to fight for their patents on a technology. Even patent pools don't work for this, apparently. >> The best interest of a H.264 patent owner is to avoid having to disclose= , >> wait for adoption, and then be free to ask for a lot more than what they >> would get from the patent pool. This is why I consider H.264 to be a >> higher risk than VP8. The current Motorola lawsuit confirms this. > > The Motorola lawsuit does not confirm this at all. =A0This is nothing but= a > fight between those two companies, both of which were likely aware of the > others' IPR here. > > You're ignoring one point I made. =A0Those involved in the creation of H.= 264 > have quite likely filed IPR statements with ISO or ITU. =A0If some other > company were to come out of the closet on this with something that > blindsides the industry, the industry would fight it. =A0At the very leas= t, > whatever bit of IPR that is claimed would have to be put into perspective > with respect to the other hundreds of patents on H.264. If somebody was to come out of the woodworks over VP8, I'd expect Google to fight them. And all the other companies that have now invested into VP8. I don't think patents mean anything when it comes to the decision of whether to fight a patent claim or not: money talks. > H.264 has already become widely deployed. =A0Work is well underway on H.2= 65 > now. =A0So, there are patent trolls out there, right now is the time to s= tart > filing lawsuits. =A0And as I said, the reputable companies would have > disclosed IPR and you'd know to talk to them. > > VP8 is a technology where nobody other than Google has to answer about IP= R. > BT, Oki, France Telecom, Qualcom, Nokia, Microsoft, Sony, NTT, Motorola, = TI, > etc. are not obligated to make a statement, yet it would not surprise me = in > the least if these companies do not have IPR. =A0Whether the enforce it i= s > another matter. =A0They will only if it is in their interest. If they've decided to use VP8, they license makes them take choose sides. There's no need for a patent pool to force them to take sides (in fact, that doesn't seem to have worked for Motorola and Microsoft anyway. Cheers, Silvia. From stewe@stewe.org Thu Apr 5 15:33: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 8C1AE21F863E for ; Thu, 5 Apr 2012 15:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 UKo3fFuAD1dI for ; Thu, 5 Apr 2012 15:33:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 54BC821F8638 for ; Thu, 5 Apr 2012 15:33:36 -0700 (PDT) Received: from mail95-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 22:33:35 +0000 Received: from mail95-tx2 (localhost [127.0.0.1]) by mail95-tx2-R.bigfish.com (Postfix) with ESMTP id D16EF3C0239; Thu, 5 Apr 2012 22:33:35 +0000 (UTC) X-SpamScore: -33 X-BigFish: PS-33(z11d7lz9371I1432N1418M1453M98dKzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944h) 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 Received-SPF: pass (mail95-tx2: 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 mail95-tx2 (localhost.localdomain [127.0.0.1]) by mail95-tx2 (MessageSwitch) id 1333665213737423_11258; Thu, 5 Apr 2012 22:33:33 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.246]) by mail95-tx2.bigfish.com (Postfix) with ESMTP id AF09E460051; Thu, 5 Apr 2012 22:33:33 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 22:33:32 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.175]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0143.003; Thu, 5 Apr 2012 22:33:31 +0000 From: Stephan Wenger To: Silvia Pfeiffer , "Paul E. Jones" Thread-Topic: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline codec] Thread-Index: AQHNE3PVLR6QSFfXKU6yg0UOXaUil5aMW/0A Date: Thu, 5 Apr 2012 22:33:31 +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.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 05 Apr 2012 22:33:37 -0000 Hi, Joining the fun again, so that Paul does not feel lonely... Albeit at a slower pace, due to day job requirements plus splendid (and plentiful) Sierra snow :-) Stephan On 4.5.2012 14:33 , "Silvia Pfeiffer" wrote: >On Fri, Apr 6, 2012 at 4:50 AM, Paul E. Jones >wrote: >>> > Indeed, but I have a significantly higher level of confidence that I >>> > can identify all of the legitimate companies with IPR on H.264, >>> > whereas I haven't a clue where to start (outside of Google) for VP8. >>> >>> Obviously, that makes H.264 so much safer, right? >>>=20 >>>http://www.theregister.co.uk/2012/03/29/microsoft_motorola_patent_cases/ >> >> Motorola is a known patent holder. So if Microsoft. I assume Microsoft >> elected to ignore Motorola's patent claims, and I assume Motorola >>ignored >> Microsoft's patents, too, as I'm sure there would have been a >>reciprocity >> agreement in place otherwise. I don't know, but if you want to use >>H.264, >> then you would have known to talk to Motorola and MS. > >So what's the point in having the patent pool if you have to talk to >all the individual patent owners anyway? The answer to this rhetoric question is twofold. The obvious part is that it's usually cheaper and easier to pick one license from a pool at known and published terms than to negotiate a license with all those rightholders outside of a pool arrangement (which, by the way, is an option some companies have chosen). The less obvious part is that the percentage of patents in a pool reading on a standard is normally substantial. For H.264, one estimate I have heard (and that I believe could well be realistic) is 80%. As the terms of the pool and the number of patents therein are known, one can calculate a "market price" for a patent license reading on H.264. It's not that easy for a rightholder outside the pool to ask for royalties substantially higher than what the pool charges (and get away with it); at least not without raising concerns about the fairness and reasonableness of said rightholder. Which one of the more important aspects of what currently happens in the antitrust activity going on in Europe in the Moto/MS case. As I have said in the meeting: FRAND has recently gotten teeth. I firmly believe so. > > >>> > If I owned IPR on VP8 (which I don't personally; can't speak for my >>> > employer), I certainly would not tell you and I would not join a >>> > patent pool, either. I would wait until you adopt VP8, build it into >>> > software and hardware products, have it massively deployed, and then >>> > I'd come along and collect my royalties. There is absolutely no >>> > financial incentive for an IPR holder to join a patent pool. >>> >>> I assume this is why we've seen all these lawsuits against Google, >>> Microsoft, Cisco, Apple... over their use of Vorbis and Speex, right? >>> Seriously, I can count at least 10 free AV codecs and none of them have >>> had any patent lawsuits that I'm aware of. >> >> The "why" is unknown. It might be that a license was acquired. It might >>be >> that patent holders do not care since the same companies are already >> licensing their patents. Perhaps the usage is not as high as other >>codecs, >> including MP3 and G.729? > >You might be surprised about the usage - a substantial amount of games >use Vorbis because they don't have to pay for a license. Indeed, it is >well known that Microsoft's Halo used Vorbis. For that very reason, I >doubt that any of those companies acquired a patent license from any >company claiming to own a patent on Vorbis or Speex. In fact, since >nobody has claimed to have such patents, how would you even know who >to license it from? The vast majority of patent disputes never see a courtroom and never get published. A rightholder sends a letter alleging infringement, the parties meet, a license is being negotiated (the terms may or may not include a monetary component), and that's the end of it. Outside of certain ideologically restricted circles, pragmatic solutions can be found rather easily in many cases. > >> The fact there isn't a lawsuit does not mean these >> are free from patents, unless the technology is so old patents are >>expired. >> (I think that's one argument for using H.261, in spite of its small >>video >> sizes.) > >Existing lawsuits are the only quantitative measure that is available >to find out about whether somebody is prepared to fight for their >patents on a technology. Even patent pools don't work for this, >apparently. > > >>> The best interest of a H.264 patent owner is to avoid having to >>>disclose, >>> wait for adoption, and then be free to ask for a lot more than what >>>they >>> would get from the patent pool. This is why I consider H.264 to be a >>> higher risk than VP8. The current Motorola lawsuit confirms this. >> >> The Motorola lawsuit does not confirm this at all. This is nothing but >>a >> fight between those two companies, both of which were likely aware of >>the >> others' IPR here. Paul is correct here. Motorola did not come out of the woods. The patents asserted are well known, and at least one of them has been asserted and litigated before (in an MPEG-2 context) if I recall correctly. They were also declared as being available under RAND terms in both ISO/IEC an the ITU. >> >> You're ignoring one point I made. Those involved in the creation of >>H.264 >> have quite likely filed IPR statements with ISO or ITU. If some other >> company were to come out of the closet on this with something that >> blindsides the industry, the industry would fight it. At the very >>least, >> whatever bit of IPR that is claimed would have to be put into >>perspective >> with respect to the other hundreds of patents on H.264. > >If somebody was to come out of the woodworks over VP8, I'd expect >Google to fight them. And all the other companies that have now >invested into VP8. I don't think patents mean anything when it comes >to the decision of whether to fight a patent claim or not: money >talks. > >> H.264 has already become widely deployed. Work is well underway on >>H.265 >> now. So, there are patent trolls out there, right now is the time to >>start >> filing lawsuits. And as I said, the reputable companies would have >> disclosed IPR and you'd know to talk to them. >> >> VP8 is a technology where nobody other than Google has to answer about >>IPR. >> BT, Oki, France Telecom, Qualcom, Nokia, Microsoft, Sony, NTT, >>Motorola, TI, >> etc. are not obligated to make a statement, yet it would not surprise >>me in >> the least if these companies do not have IPR. Whether the enforce it is >> another matter. They will only if it is in their interest. > >If they've decided to use VP8, they license makes them take choose >sides. There's no need for a patent pool to force them to take sides >(in fact, that doesn't seem to have worked for Motorola and Microsoft >anyway. > >Cheers, >Silvia. >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From paulej@packetizer.com Thu Apr 5 19:04: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 EDF2511E808F for ; Thu, 5 Apr 2012 19:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 f3gSLeg2g5Ub for ; Thu, 5 Apr 2012 19:04:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B7A3D11E808E for ; Thu, 5 Apr 2012 19:04:38 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3624aLp022660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 22:04:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333677877; bh=2i3SAXSpQLVgFacZhSINRegibkUlT71uFVXvxe9VtCE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Bx6POiUE9OggfpTcDanfEwGRarAL6KoQUrTUsomWIV/mtUAc3/gSge5z7ZvBiJGE8 ldU3NhUOb77FFZEnlvXXJbyZIB3GR5fMz82e2L+rDj6yvidQ7wc/C5r5ZiLGwXZcuU tIIharS51A4EGAz9+mPb81lFzOUeiGzzMbfv19B4= From: "Paul E. Jones" To: "'Silvia Pfeiffer'" References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> <4F7DB5DC.40507@mozilla.com> <011e01cd135c$fcdc08d0$f6941a70$@packetizer.com> In-Reply-To: Date: Thu, 5 Apr 2012 22:04:42 -0400 Message-ID: <007401cd1399$a1fb56e0$e5f204a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNwB1VzUBAGtdKoUAdUR/YIBXjpAbAG0OcKCAnrjnEeYyS8QgA== Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Fri, 06 Apr 2012 02:04:40 -0000 Silvia, > > Motorola is a known patent holder. =A0So if Microsoft. =A0I assume > > Microsoft elected to ignore Motorola's patent claims, and I assume > > Motorola ignored Microsoft's patents, too, as I'm sure there would > > have been a reciprocity agreement in place otherwise. =A0I don't = know, > > but if you want to use H.264, then you would have known to talk to > Motorola and MS. >=20 > So what's the point in having the patent pool if you have to talk to = all > the individual patent owners anyway? Motorola is not part of the pool, I do not believe. I would assume one would not have to talk to those that do participate in the pool, but = that may not be true, either. In any case, the pool certainly makes it = easier to license the collective set of patents that are listed in the pool. > > The "why" is unknown. It might be that a license was acquired. It > > might be that patent holders do not care since the same companies = are > > already licensing their patents. =A0Perhaps the usage is not as high = as > > other codecs, including MP3 and G.729? >=20 > You might be surprised about the usage - a substantial amount of games = use > Vorbis because they don't have to pay for a license. Indeed, it is = well > known that Microsoft's Halo used Vorbis. For that very reason, I doubt > that any of those companies acquired a patent license from any company > claiming to own a patent on Vorbis or Speex. In fact, since nobody has > claimed to have such patents, how would you even know who to license = it > from? One would not. And, one would still have to pay through the nose, potentially, for patent infringement. That's the problem with patents = and technology where the patent landscape is entirely unknown. =20 > > =A0The fact there isn't a lawsuit does not mean these are free from > > patents, unless the technology is so old patents are expired. > > (I think that's one argument for using H.261, in spite of its small > > video > > sizes.) >=20 > Existing lawsuits are the only quantitative measure that is available = to > find out about whether somebody is prepared to fight for their patents = on > a technology. Even patent pools don't work for this, apparently. Can't agree with that one. Recall the GIF file format? Well after it became widely used, Unisys went around forcing people to pay royalties. = How many years did people believe that was free? =20 > > You're ignoring one point I made. =A0Those involved in the creation = of > > H.264 have quite likely filed IPR statements with ISO or ITU. =A0If = some > > other company were to come out of the closet on this with something > > that blindsides the industry, the industry would fight it. =A0At the > > very least, whatever bit of IPR that is claimed would have to be put > > into perspective with respect to the other hundreds of patents on = H.264. >=20 > If somebody was to come out of the woodworks over VP8, I'd expect = Google > to fight them. And all the other companies that have now invested into > VP8. I don't think patents mean anything when it comes to the decision = of > whether to fight a patent claim or not: money talks. By "fighting", I mean coming into court with evidence that would = contradict the infringed patent. Google might be able to show that the particular = way that the bits of video are manipulated were already public or covered by = one of their patents, maybe not. My feeling -- and that's all it is -- likely has a bunch more patent = holders who could demonstrate that their patents covered whatever it is that a patent troll might try to claim. =20 > > VP8 is a technology where nobody other than Google has to answer = about > IPR. > > BT, Oki, France Telecom, Qualcom, Nokia, Microsoft, Sony, NTT, > > Motorola, TI, etc. are not obligated to make a statement, yet it = would > > not surprise me in the least if these companies do not have IPR. > > Whether the enforce it is another matter. =A0They will only if it is = in > their interest. >=20 > If they've decided to use VP8, they license makes them take choose = sides. > There's no need for a patent pool to force them to take sides (in = fact, > that doesn't seem to have worked for Motorola and Microsoft anyway. I don't understand your point here. Perhaps I was not clear. My point = was that these companies have no obligation to report IPR they hold on VP8, whereas they do have some obligation to report on H.264. It just comes down to the fact that I can *probably* identify all the = patent holders of H.264. I might miss one, but it's doubtful that a legitimate company would have not reported IPR by now. That only leaves trolls to = deal with on H.264, and I suspect they would have a hard time making = successful claims. VP8, though, is a wide-open opportunity for patent trolls and legit companies alike to lay claim after the technology is widely deployed. = It does not mean they will, but it's your gamble. :-) Paul From marshall.eubanks@gmail.com Thu Apr 5 20:37: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 2296D11E8081 for ; Thu, 5 Apr 2012 20:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.499 X-Spam-Level: X-Spam-Status: No, score=-104.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, 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 h27AIlGvQ6Fn for ; Thu, 5 Apr 2012 20:37:29 -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 3967321F8525 for ; Thu, 5 Apr 2012 20:37:29 -0700 (PDT) Received: by lbok13 with SMTP id k13so494522lbo.31 for ; Thu, 05 Apr 2012 20:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zu+PGAuyS2m/Iov+KlCRT+XiI7l7ewttk7tfVMRjre0=; b=GhHX5esfyxK80NBFaco/DaFPQVTBC9FJ1bQrUHocIHUzYH0hPm7ag9KEtIx15cAULC yd+O620f7XOQKJaEm2/NEXmCsu5yCUy4ElhaEZN8mk+V/WIpQEhokhsapZT5Fq4LKYBP 3LqiHH0NyiiteKnDIPAWxKMzeon+ve6sCQWbLWmmxDDUtwWO94kLMpeHAVFiRljL8qRx N9DLUMAy00mbzvVYeEKtSl+LuCWikpZhWW8H75may9czeL1p8xDwZ+1R2Xpk9lMRUJG5 cqbZis+58QX0G4bvgpt/jOeEbXuuLIhUABYbZJJ0QmXLwLN/KSm1J0XZS0kwuMUHVIhV zRNA== MIME-Version: 1.0 Received: by 10.152.104.80 with SMTP id gc16mr6357513lab.46.1333683448160; Thu, 05 Apr 2012 20:37:28 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Thu, 5 Apr 2012 20:37:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 23:37:28 -0400 Message-ID: From: Marshall Eubanks To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Fri, 06 Apr 2012 03:37:31 -0000 On Thu, Apr 5, 2012 at 6:33 PM, Stephan Wenger wrote: > Hi, > Joining the fun again, so that Paul does not feel lonely... > Albeit at a slower pace, due to day job requirements plus splendid (and > plentiful) Sierra snow :-) > Stephan > > On 4.5.2012 14:33 , "Silvia Pfeiffer" wrote: > >>On Fri, Apr 6, 2012 at 4:50 AM, Paul E. Jones >>wrote: >>>> > Indeed, but I have a significantly higher level of confidence that I >>>> > can identify all of the legitimate companies with IPR on H.264, >>>> > whereas I haven't a clue where to start (outside of Google) for VP8. >>>> >>>> Obviously, that makes H.264 so much safer, right? >>>> >>>>http://www.theregister.co.uk/2012/03/29/microsoft_motorola_patent_cases= / >>> >>> Motorola is a known patent holder. =A0So if Microsoft. =A0I assume Micr= osoft >>> elected to ignore Motorola's patent claims, and I assume Motorola >>>ignored >>> Microsoft's patents, too, as I'm sure there would have been a >>>reciprocity >>> agreement in place otherwise. =A0I don't know, but if you want to use >>>H.264, >>> then you would have known to talk to Motorola and MS. >> >>So what's the point in having the patent pool if you have to talk to >>all the individual patent owners anyway? > > The answer to this rhetoric question is twofold. =A0The obvious part is t= hat > it's usually cheaper and easier to pick one license from a pool at known > and published terms than to negotiate a license with all those > rightholders outside of a pool arrangement (which, by the way, is an > option some companies have chosen). =A0The less obvious part is that the > percentage of patents in a pool reading on a standard is normally > substantial. =A0For H.264, one estimate I have heard (and that I believe > could well be realistic) is 80%. =A0As the terms of the pool and the numb= er > of patents therein are known, one can calculate a "market price" for a > patent license reading on H.264. =A0It's not that easy for a rightholder > outside the pool to ask for royalties substantially higher than what the > pool charges (and get away with it); at least not without raising concern= s > about the fairness and reasonableness of said rightholder. =A0Which one o= f > the more important aspects of what currently happens in the antitrust > activity going on in Europe in the Moto/MS case. =A0As I have said in the > meeting: FRAND has recently gotten teeth. =A0I firmly believe so. > I think that the EC may agree with you : http://europa.eu/rapid/pressReleasesAction.do?reference=3DIP/12/345&format= =3DHTML&aged=3D0&language=3DEN&guiLanguage=3Den "Following complaints by Apple and Microsoft, the Commission will investigate, in particular, whether by seeking and enforcing injunctions against Apple's and Microsoft's flagship products such as iPhone, iPad, Windows and Xbox on the basis of patents it had declared essential to produce standard-compliant products, Motorola has failed to honour its irrevocable commitments made to standard setting organisations. In these commitments, Motorola engaged to license those standard-essential patents on fair, reasonable and non-discriminatory (FRAND) terms. The Commission will examine whether Motorola's behaviour amounts to an abuse of a dominant market position prohibited by Article 102 of the Treaty on the Functioning of the EU (TFEU)." I believe that the primary SSO of issue here is ETSI. Regards Marshall >> >> >>>> > If I owned IPR on VP8 (which I don't personally; can't speak for my >>>> > employer), I certainly would not tell you and I would not join a >>>> > patent pool, either. =A0I would wait until you adopt VP8, build it i= nto >>>> > software and hardware products, have it massively deployed, and then >>>> > I'd come along and collect my royalties. =A0There is absolutely no >>>> > financial incentive for an IPR holder to join a patent pool. >>>> >>>> I assume this is why we've seen all these lawsuits against Google, >>>> Microsoft, Cisco, Apple... over their use of Vorbis and Speex, right? >>>> Seriously, I can count at least 10 free AV codecs and none of them hav= e >>>> had any patent lawsuits that I'm aware of. >>> >>> The "why" is unknown. It might be that a license was acquired. It might >>>be >>> that patent holders do not care since the same companies are already >>> licensing their patents. =A0Perhaps the usage is not as high as other >>>codecs, >>> including MP3 and G.729? >> >>You might be surprised about the usage - a substantial amount of games >>use Vorbis because they don't have to pay for a license. Indeed, it is >>well known that Microsoft's Halo used Vorbis. For that very reason, I >>doubt that any of those companies acquired a patent license from any >>company claiming to own a patent on Vorbis or Speex. In fact, since >>nobody has claimed to have such patents, how would you even know who >>to license it from? > > The vast majority of patent disputes never see a courtroom and never get > published. =A0A rightholder sends a letter alleging infringement, the > parties meet, a license is being negotiated (the terms may or may not > include a monetary component), and that's the end of it. =A0Outside of > certain ideologically restricted circles, pragmatic solutions can be foun= d > rather easily in many cases. > >> >>> =A0The fact there isn't a lawsuit does not mean these >>> are free from patents, unless the technology is so old patents are >>>expired. >>> (I think that's one argument for using H.261, in spite of its small >>>video >>> sizes.) >> >>Existing lawsuits are the only quantitative measure that is available >>to find out about whether somebody is prepared to fight for their >>patents on a technology. Even patent pools don't work for this, >>apparently. >> >> >>>> The best interest of a H.264 patent owner is to avoid having to >>>>disclose, >>>> wait for adoption, and then be free to ask for a lot more than what >>>>they >>>> would get from the patent pool. This is why I consider H.264 to be a >>>> higher risk than VP8. The current Motorola lawsuit confirms this. >>> >>> The Motorola lawsuit does not confirm this at all. =A0This is nothing b= ut >>>a >>> fight between those two companies, both of which were likely aware of >>>the >>> others' IPR here. > > Paul is correct here. =A0Motorola did not come out of the woods. =A0The > patents asserted are well known, and at least one of them has been > asserted and litigated before (in an MPEG-2 context) if I recall > correctly. =A0They were also declared as being available under RAND terms= in > both ISO/IEC an the ITU. > >>> >>> You're ignoring one point I made. =A0Those involved in the creation of >>>H.264 >>> have quite likely filed IPR statements with ISO or ITU. =A0If some othe= r >>> company were to come out of the closet on this with something that >>> blindsides the industry, the industry would fight it. =A0At the very >>>least, >>> whatever bit of IPR that is claimed would have to be put into >>>perspective >>> with respect to the other hundreds of patents on H.264. >> >>If somebody was to come out of the woodworks over VP8, I'd expect >>Google to fight them. And all the other companies that have now >>invested into VP8. I don't think patents mean anything when it comes >>to the decision of whether to fight a patent claim or not: money >>talks. >> >>> H.264 has already become widely deployed. =A0Work is well underway on >>>H.265 >>> now. =A0So, there are patent trolls out there, right now is the time to >>>start >>> filing lawsuits. =A0And as I said, the reputable companies would have >>> disclosed IPR and you'd know to talk to them. >>> >>> VP8 is a technology where nobody other than Google has to answer about >>>IPR. >>> BT, Oki, France Telecom, Qualcom, Nokia, Microsoft, Sony, NTT, >>>Motorola, TI, >>> etc. are not obligated to make a statement, yet it would not surprise >>>me in >>> the least if these companies do not have IPR. =A0Whether the enforce it= is >>> another matter. =A0They will only if it is in their interest. >> >>If they've decided to use VP8, they license makes them take choose >>sides. There's no need for a patent pool to force them to take sides >>(in fact, that doesn't seem to have worked for Motorola and Microsoft >>anyway. > > > >> >>Cheers, >>Silvia. >>_______________________________________________ >>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 randell-ietf@jesup.org Thu Apr 5 22:01: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 7954E21F858B for ; Thu, 5 Apr 2012 22:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=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 G1XdpEOQkvNG for ; Thu, 5 Apr 2012 22:01:08 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1F21F858A for ; Thu, 5 Apr 2012 22:01:08 -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 1SG1IJ-0008Bj-7l for rtcweb@ietf.org; Fri, 06 Apr 2012 00:01:07 -0500 Message-ID: <4F7E77BF.4090006@jesup.org> Date: Fri, 06 Apr 2012 00:57:35 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7DD0B8.2030900@infosecurity.ch> In-Reply-To: <4F7DD0B8.2030900@infosecurity.ch> 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] DTLS-SRTP with end-to-end security: Short Authentication String 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 Apr 2012 05:01:09 -0000 tl;dr: I believe SAS should be supported by the browser (or non-browser app/device) UI, and I believe that's the current plan though perhaps it's not written as a MUST. I am much more hesitant to endorse key-chaining due to usability issues. On 4/5/2012 1:04 PM, Fabio Pietrosanti (naif) wrote: > In the RTCWeb security there is a proposed solution, to use SAS: > http://tools.ietf.org/html/draft-ietf-rtcweb-security-02#section-4.3.2.2 > > SAS, Short authentication string, allow to achieve end-to-end security > within the DTLS-SRTP end-to-end encryption protocol. > > Unfortunately the author of rtcweb-security described the SAS as a bad > way to verify fingerprints. > > I would like to argue that SAS are instead a valuable, secure mechanism > to provide end-to-end authentication to an end-to-end encryption system, > thus realizing end-to-end security. The reason the document described it that way (and it was a subject of discussion at IETF 81 or an interim phone call since then) is that users generally don't use or understand SAS. Yes, extremely security-conscious individuals can use it to verify a given connection. The ZRTP key-chaining is somewhat problematic in a modern world where destinations are people who may use one of N devices, not hard-coded numbers tied to a specific piece of hardware. ZRTP was designed to lower the bar for encryption, by making it possible to ignore SAS initially under the assumption that the first connection is safe. That assumption might not hold. And the occasional key-chaining failure caused by either loss of key-chain info (device reset, etc) or by substitution of devices or forwarding of a call will cause an ongoing level of false-positives that will weaken any response to a real MITM. If in response to a failure they don't do SAS, but instead just accept it, then they are now silently MITM'd until they do SAS. Fundamentally, though, as stated in the meetings, the ease-of-use bar for ZRTP-like SAS+chaining is just too high for non-security-experts (or the non-paranoid (whether rightfully non-paranoid or not)). We could run chaining with the current design, and that has been discussed, but when I call you from my tablet instead of my PC, the chain won't match and the MITM flag would fire. This is why we explored and suggested to allow for an Idp to allow authentication of the other party to a call. Does this provide the same level of security by default as a working PKI infrastructure, or of ZRTP+SAS? No. But SAS is still supported (I believe this question was asked at IETF 83), so the truly security knowledgeable can verify end-to-end security anytime they want, while general users can get considerably more security (if the Idp is not also their service/app provider) than they would with SDES. Note that if the cert used by an attacker is the result of a hack like Diginotar (or government-sponsored spoofing via a captive CA), then the user is severely at risk in any scenario due to injection of compromised JS code from a supposedly trusted source, doubly so if the app has been granted the right to turn on cameras and mics. SDES is totally broken at that point. > I would like to bring the attention of the WG to provide a MANDATORY > requirement to enable SAS verification. I think the question was asked at IETF (paraphrased): will SAS be available through the UI in some manner? Yes. So I don't think there's any problem with this request. Chaining may be more problematical. -- Randell Jesup randell-ietf@jesup.org From pravindran@sonusnet.com Thu Apr 5 23:23: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 02B9011E8091 for ; Thu, 5 Apr 2012 23:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 5V93cDlS6CbE for ; Thu, 5 Apr 2012 23:23:42 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8CF11E8085 for ; Thu, 5 Apr 2012 23:23:41 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT36L7KT6lvv8xAUW1+IziGJvIsBGFr++@postini.com; Thu, 05 Apr 2012 23:23:41 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 6 Apr 2012 02:24:04 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 11:53:35 +0530 From: "Ravindran, Parthasarathi" To: "Fabio Pietrosanti (naif)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP) Thread-Index: AQHNExU2rLdj93x8tkit4g2OJGitOJaNUhqQ Date: Fri, 6 Apr 2012 06:24:02 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E225544@inba-mail01.sonusnet.com> References: <4F7D7103.6040102@infosecurity.ch> In-Reply-To: <4F7D7103.6040102@infosecurity.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-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: Fri, 06 Apr 2012 06:23:43 -0000 Fabio, End-to-end looks misnomer to me as the maximum media security/authenticatio= n provided shall be between two media hops. The media hops in the RTCWeb ar= e web-browser. So, the aim of the media security/authentication mechanism h= as to between two web-browsers. The intermediate elements like http proxy s= hould not be in a position to perform MITM attack or atleast, web-browser s= hould have the mechanism to perform post-mortem analysis that man-in-the-mi= ddle exist as HTTP proxy. I wish to see the discussion for media security/a= uthentication between web-browser to web-browser first. Please note that web-browser is not required to standard browser like Chrom= e, IE, Mozilla but web-browser shall be custom-made which is RTCWeb complia= nt. AFAIK, SDES-SRTP does not provide web-browser to web-browser authentication= and it shall mimic web-browser to web-browser security. I agree with Hadri= el that SDES-SRTP mechanism provides marketing advance as most of the user = atleast believes that the session is secured :-) but it should not be crite= ria for selecting key mechanism. We shall discuss in detail about DTLS-SRT= P or zRTP or any other mechanism if exists for web-browser to web-browser m= edia security. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Fabio Pietrosanti (naif) >Sent: Thursday, April 05, 2012 3:47 PM >To: rtcweb@ietf.org >Subject: [rtcweb] End-to-end encryption vs end-to-end authentication >(DTLS-SRTP / SDES-SRTP) > >Hi, > >i've been discussing with several friends about the current discussion >on the security standard in this mailing lists, in particular regarding >the topic of DTLS-SRTP trust model posted there >http://www.ietf.org/mail-archive/web/rtcweb/current/msg04007.html . > >I found that there is no common definition for the concept of "end-to- >end encryption" and there are a lot of misunderstanding about it. > >In particular, the fact that two peer can community by exchanging keys >directly among them, tend to typically to be defined as end-to-end >encryption. > >However the term "end-to-end encryption" have also a general >misconception that's something that "no one can intercept" . > >Unfortunately this is not true for DTLS-SRTP, while for example it's >true for OpenPGP/MIME or for ZRTP with SAS. > >We need to separate the 4 concepts: > >- end-to-end encryption >Ability for a key management system to exchange keys directly without >relying on intermediate server actively involved in encryption process. > >- end-to-end authentication >Ability for end-user to authenticate the end-to-end encryption process >without the need to rely on a single or multiple set of trusted third >parties > >- end-to-site encryption >Ability for a key management system to exchange keys with/trough the >server with which data are exchanged, involving it in the authentication >process. > >- end-to-site authentication >Ability for end-user to authenticate the end-to-site encryption process >based on the same security mechanism used to establish trust with the >server with which data are exchanged. > > >What i would like to focus is that: > >- DTLS does provide end-to-end encryption (in specific context of use) >- DTLS does provide end-to-site authentication (rely on third party >trust) > >- ZRTP does provide end-to-end encryption (in all context of use) >- ZRTP does provide end-to-end authentication (does not rely on third >party trust) > >- SDES-SRTP does provide end-to-site encryption (encryption with/trough >your server) >- SDES-SRTP does provide end-to-site authentication (you trust your >server involved in key exchange) > >So when we tend to think about the "how much security a technology >provide" we should probably compare in a scale: > >- ZRTP > - end-to-end encryption > - end-to-end authentication >- DTLS-SRTP > - end-to-end encryption > - end-to-site authentication >- SDES-SRTP > - end-to-site encryption > - end-to-site authentication > >So currently we can affirm that: > >- ZRTP does not rely on third party trust for effective security >- DTLS-SRTP rely on third party trust for effective security >- SDES-SRTP rely on third party trust for effective security > >This is the *MOST IMPORTANT* distinction for an encryption technology: > WHO SHOULD I TRUST? > >Well, basically it seems to me that DTLS-SRTP and SDES-SRTP both require > >So, my point are to: > >- Introduce SDES-SRTP for compatibility and simplicity > - Specify that the Browser will need to provide indicate the security >level to the user (like the lock of HTTPS, same security model) > >- Introduce end-to-end authentication support for DTLS-SRTP via SAS > - Specify that the browser will need to to provide the end-user way to >use end-to-end authentication and indicate the security level to the >user. > >Then it will be up to the signaling server and/or to the browser >settings to specificy the required security model: >- end-to-end encryption + end-to-end authentication or >- end-to-site encryption + end-to-site authentication > >But please don't mix those two as it will be *Very difficult, near to >impossible* to explain to the user "WHO SHOULD HE TRUST" . > >Fabio >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Fri Apr 6 09:13: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 617A821F853E for ; Fri, 6 Apr 2012 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.382 X-Spam-Level: X-Spam-Status: No, score=-100.382 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=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 Ee+Z9RGHF63z for ; Fri, 6 Apr 2012 09:13:15 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 537E321F8539 for ; Fri, 6 Apr 2012 09:13:15 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1756315qcs.31 for ; Fri, 06 Apr 2012 09:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pAX51332wrxqbCgfLp4J7t6csb/TIyHYoDRFhgOOpRU=; b=hrbE770MNLohFtBGwxuGXxDUbvOc4Hvt709catjEagO+Xo/KCg1JDM2vGkwRd5qh/T Q8+zNLG71lIc97PQtqwh/dCiMLVUCgP0g557NnlXGfRNi+c3SOJZHrxNPjaLR3Pw//xY rLyCY1dTD2OvGc0RR9jtGl6uP3zC6iZHPqaPBb5nGIU8RErvF8zBwPxFSzx/irbWTgBq ZAo5egD92FHtRGSjMtHSrVdqn9A70xrOcxn9liq2NpVLZNi0zPaGgvtcr9eul1LQNStf uJ1sut5B0ybB2ha621pleUdj3ne3UXVjHVHj/IIxMORPJc/ftRWtKNZRV+GhZlGccGdM 7uNQ== 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=pAX51332wrxqbCgfLp4J7t6csb/TIyHYoDRFhgOOpRU=; b=c8uUybLfjRGIIHih4FioQgZjw4exwoUqPFVR0TGee75r5A9oic49u4hOWEwQXeKub9 IOcjlJfXCYAxD3E5BXbC2cjvoTwNflQTbawlA6Ke2YrOGtilGcHalc42+vu5S9VgfqGe 5UmGMUKQDEo1cLrOp3ei2LmNO/XeeLATUzRory4uFnW4wDQHAMv6VS8ZCT/V1jwkosjX doAmjTAx9VgKAOtQF3KTs53gTrUukS931ZAqJpmlPJ8o82+0ygHTzeYTFn7dospjqiXO oYnGbnojRR5YTI786aUrC91KQuj4mEIHRQWjquqPIHvqTQR4wNuvZJorfq6oXIaVz5WM DHow== Received: by 10.224.31.197 with SMTP id z5mr10001768qac.26.1333728794732; Fri, 06 Apr 2012 09:13:14 -0700 (PDT) Received: by 10.224.31.197 with SMTP id z5mr10001756qac.26.1333728794606; Fri, 06 Apr 2012 09:13:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Fri, 6 Apr 2012 09:12:54 -0700 (PDT) In-Reply-To: <4F7E77BF.4090006@jesup.org> References: <4F7DD0B8.2030900@infosecurity.ch> <4F7E77BF.4090006@jesup.org> From: Justin Uberti Date: Fri, 6 Apr 2012 12:12:54 -0400 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=20cf306f72ee077b4d04bd04efe2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnCznz7L4UR6iDt5lp0HW2CRrzaMDAZOQa5uZI8z6O4ZpobiYsLQ8PJLKOhXabX7s/hjDbokcLlKjyi7ahIFgPodbTxVkisFfPtfJkm/mzT7n2nA4ZXfE65C0nilXwGm+ApgAuN Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DTLS-SRTP with end-to-end security: Short Authentication String 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 Apr 2012 16:13:16 -0000 --20cf306f72ee077b4d04bd04efe2 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 6, 2012 at 12:57 AM, Randell Jesup wrote: > tl;dr: I believe SAS should be supported by the browser (or non-browser > app/device) UI, and I believe that's the current plan though perhaps it's > not written as a MUST. I am much more hesitant to endorse key-chaining due > to usability issues. +1 for browsers presenting the digest information to the user on demand, so that they can perform a manual verification step, if desired. > > > On 4/5/2012 1:04 PM, Fabio Pietrosanti (naif) wrote: > >> In the RTCWeb security there is a proposed solution, to use SAS: >> http://tools.ietf.org/html/**draft-ietf-rtcweb-security-02#** >> section-4.3.2.2 >> >> SAS, Short authentication string, allow to achieve end-to-end security >> within the DTLS-SRTP end-to-end encryption protocol. >> >> Unfortunately the author of rtcweb-security described the SAS as a bad >> way to verify fingerprints. >> >> I would like to argue that SAS are instead a valuable, secure mechanism >> to provide end-to-end authentication to an end-to-end encryption system, >> thus realizing end-to-end security. >> > > The reason the document described it that way (and it was a subject of > discussion at IETF 81 or an interim phone call since then) is that users > generally don't use or understand SAS. Yes, extremely security-conscious > individuals can use it to verify a given connection. The ZRTP key-chaining > is somewhat problematic in a modern world where destinations are people who > may use one of N devices, not hard-coded numbers tied to a specific piece > of hardware. > > ZRTP was designed to lower the bar for encryption, by making it possible > to ignore SAS initially under the assumption that the first connection is > safe. That assumption might not hold. And the occasional key-chaining > failure caused by either loss of key-chain info (device reset, etc) or by > substitution of devices or forwarding of a call will cause an ongoing level > of false-positives that will weaken any response to a real MITM. If in > response to a failure they don't do SAS, but instead just accept it, then > they are now silently MITM'd until they do SAS. > > Fundamentally, though, as stated in the meetings, the ease-of-use bar for > ZRTP-like SAS+chaining is just too high for non-security-experts (or the > non-paranoid (whether rightfully non-paranoid or not)). We could run > chaining with the current design, and that has been discussed, but when I > call you from my tablet instead of my PC, the chain won't match and the > MITM flag would fire. > > This is why we explored and suggested to allow for an Idp to allow > authentication of the other party to a call. Does this provide the same > level of security by default as a working PKI infrastructure, or of > ZRTP+SAS? No. But SAS is still supported (I believe this question was > asked at IETF 83), so the truly security knowledgeable can verify > end-to-end security anytime they want, while general users can get > considerably more security (if the Idp is not also their service/app > provider) than they would with SDES. > > Note that if the cert used by an attacker is the result of a hack like > Diginotar (or government-sponsored spoofing via a captive CA), then the > user is severely at risk in any scenario due to injection of compromised JS > code from a supposedly trusted source, doubly so if the app has been > granted the right to turn on cameras and mics. SDES is totally broken at > that point. > > > I would like to bring the attention of the WG to provide a MANDATORY >> requirement to enable SAS verification. >> > > I think the question was asked at IETF (paraphrased): will SAS be > available through the UI in some manner? Yes. > > So I don't think there's any problem with this request. Chaining may be > more problematical. > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --20cf306f72ee077b4d04bd04efe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 6, 2012 at 12:57 AM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
tl;dr: =C2=A0I believe SAS should be supported by the browser (or non-brows= er app/device) UI, and I believe that's the current plan though perhaps= it's not written as a MUST. =C2=A0I am much more hesitant to endorse k= ey-chaining due to usability issues.

+1 for browsers presenting the digest information to th= e user on demand, so that they can perform a manual verification step, if d= esired.=C2=A0
=C2=A0


On 4/5/2012 1:04 PM, Fabio Pietrosanti (naif) wrote:
In the RTCWeb security there is a proposed solution, to use SAS:
http://tools.ietf.org/html/draft-ietf-rt= cweb-security-02#section-4.3.2.2

SAS, Short authentication string, allow to achieve end-to-end security
within the DTLS-SRTP end-to-end encryption protocol.

Unfortunately the author of rtcweb-security described the SAS as a bad
way to verify fingerprints.

I would like to argue that SAS are instead a valuable, secure mechanism
to provide end-to-end authentication to an end-to-end encryption system, thus realizing end-to-end security.

The reason the document described it that way (and it was a subject of disc= ussion at IETF 81 or an interim phone call since then) is that users genera= lly don't use or understand SAS. =C2=A0Yes, extremely security-consciou= s individuals can use it to verify a given connection. =C2=A0The ZRTP key-c= haining is somewhat problematic in a modern world where destinations are pe= ople who may use one of N devices, not hard-coded numbers tied to a specifi= c piece of hardware.

ZRTP was designed to lower the bar for encryption, by making it possible to= ignore SAS initially under the assumption that the first connection is saf= e. =C2=A0That assumption might not hold. =C2=A0And the occasional key-chain= ing failure caused by either loss of key-chain info (device reset, etc) or = by substitution of devices or forwarding of a call will cause an ongoing le= vel of false-positives that will weaken any response to a real MITM. =C2=A0= If in response to a failure they don't do SAS, but instead just accept = it, then they are now silently MITM'd until they do SAS.

Fundamentally, though, as stated in the meetings, the ease-of-use bar for Z= RTP-like SAS+chaining is just too high for non-security-experts (or the non= -paranoid (whether rightfully non-paranoid or not)). =C2=A0We could run cha= ining with the current design, and that has been discussed, but when I call= you from my tablet instead of my PC, the chain won't match and the MIT= M flag would fire.

This is why we explored and suggested to allow for an Idp to allow authenti= cation of the other party to a call. =C2=A0Does this provide the same level= of security by default as a working PKI infrastructure, or of ZRTP+SAS? = =C2=A0No. =C2=A0But SAS is still supported (I believe this question was ask= ed at IETF 83), so the truly security knowledgeable can verify end-to-end s= ecurity anytime they want, while general users can get considerably more se= curity (if the Idp is not also their service/app provider) than they would = with SDES.

Note that if the cert used by an attacker is the result of a hack like Digi= notar (or government-sponsored spoofing via a captive CA), then the user is= severely at risk in any scenario due to injection of compromised JS code f= rom a supposedly trusted source, doubly so if the app has been granted the = right to turn on cameras and mics. =C2=A0SDES is totally broken at that poi= nt.


I would like to bring the attention of the WG to provide a MANDATORY
requirement to enable SAS verification.

I think the question was asked at IETF (paraphrased): will SAS be available= through the UI in some manner? =C2=A0Yes.

So I don't think there's any problem with this request. =C2=A0Chain= ing may be more problematical.

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

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

--20cf306f72ee077b4d04bd04efe2-- From harald@alvestrand.no Mon Apr 9 04:02: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 C59B621F86B3 for ; Mon, 9 Apr 2012 04:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.517 X-Spam-Level: X-Spam-Status: No, score=-109.517 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_05=-1.11, J_CHICKENPOX_14=0.6, 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 iNYwrYJH-vVm for ; Mon, 9 Apr 2012 04:02:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C021F86B2 for ; Mon, 9 Apr 2012 04:02:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB08139E1CD for ; Mon, 9 Apr 2012 13:02:39 +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 kFBwzUnhZEFT for ; Mon, 9 Apr 2012 13:02:39 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5123339E072 for ; Mon, 9 Apr 2012 13:02:39 +0200 (CEST) Message-ID: <4F82C1C0.60809@alvestrand.no> Date: Mon, 09 Apr 2012 13:02:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7415D5.80604@ericsson.com> <4F79E03B.3090802@jesup.org> In-Reply-To: <4F79E03B.3090802@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 11:02:41 -0000 On 04/02/2012 07:22 PM, Randell Jesup wrote: > So the question for me is "what scenarios/use-cases does this enable?" > > 1) Mesh Conferencing > > While there are many ways to handle conferencing, if you have a mesh > (full or partial), you need to create new PeerConnections for existing > members of the mesh when someone joins. There are two ways to do this: > a) somehow application-specific tell the new member who to send > invites to, and then start N PeerConnection calls with some "I'm in > the conference" token; > b)have them send N separate generic invites to the service provider > which either forwards it to an existing member, or returns it with > "it's ok, I've already forwarded invites for it); > c) somehow tell all the existing members to invite the new member; or > d) have the service provider fork the OFFER from the new member to all > the existing members, and have all of them reply with ANSWERs. This > requires PeerConnection cloning to work well. > > I strongly prefer d), and it also reduces conference join time (less > round-trips, at least in theory - perhaps noticeably less by sharing > the ICE candidate generation). Hmm.... for one new member, I don't think d) is actually different from the case where the client sends an "extra" OFFER when he joins, and the server uses the "hanging OFFER" to signal the new member. This is a windowing protocol, though - the client would need to send a new "hanging OFFER" after the current "hanging OFFER" has been "used up". Cloning allows you to connect multiple new conference mebers as fast as the Javascript can accept them. (Which may have issues with congestion, but that might be a price worth paying). It's not clear to me whether hanging OFFERs work with NAT traversal; would the ICE machine send keepalives for an association that hasn't been associated yet? Harald From ekr@rtfm.com Mon Apr 9 06:58: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 AD8A821F8735 for ; Mon, 9 Apr 2012 06:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.377 X-Spam-Level: X-Spam-Status: No, score=-100.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 zWZkZLTPCnuW for ; Mon, 9 Apr 2012 06:58:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7024B21F8622 for ; Mon, 9 Apr 2012 06:58:22 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2162193vcb.31 for ; Mon, 09 Apr 2012 06:58:22 -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 :content-type:x-gm-message-state; bh=fiywv+Q/m/HJqg5agLOipDxGjO1ExmTSCq1JM2PkrTo=; b=nhUKa3EoyFegeWLYkp1Mtm3WfpBkL3tp1Sr65sb42/68JWKDDK7OBlLPNNZzu5t3ph Nl5Zdw5qpOf5NbHf0SL7OuLHoCSsbpnuugcUPdAAHuhmyrp09z180ErfPipnO2x7wiEx MsatEAasx3XxcGfGE7Q1GV7N25zcZJs0WoSMLBWnwXxmaIlYWAJbdjxd4pHDlCWECip2 CrKc2tSlWPskpt6d8CehKvbsqcSegerVe7LRtL2TmO7Ih8DSlLwqrTiC+7eBcH2NQw/W vxF4JRBFfraU0Qc4w4Jd/RQE1bXauT9ir/c3jzAmTBSxGIlDCtll1k7PKwSVwMyIg/c+ LjJQ== Received: by 10.220.57.205 with SMTP id d13mr3626002vch.53.1333979901940; Mon, 09 Apr 2012 06:58:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Mon, 9 Apr 2012 06:57:39 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 9 Apr 2012 06:57:39 -0700 Message-ID: To: rtcweb@ietf.org, public-webrtc@w3.org Content-Type: multipart/mixed; boundary=00235445b92231536004bd3f663c X-Gm-Message-State: ALoCoQkuB+WJrbgYP9snEwSLtV0mWAYV0bJaBK9oinlBpcqHH5q3lGugBVCHWXNxq9mXYwDMjPwy Subject: [rtcweb] Data on travel times 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 Apr 2012 13:58:23 -0000 --00235445b92231536004bd3f663c Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Since it seems like we're going to be having a large number of interims, I thought it might be instructive to try to analyze a bunch of different locations to figure out the best strategy. My first cut analysis is below. Note that I'm not trying to make any claims about what the best set of venues is. It's obviously easy to figure out any statistic we want about each proposed venue, but how you map that data to "best" is up to you. In particular, there's some tradeoff between minimal total travel time and a "fair" distribution of travel times (not that I claim to know what that means). METHODOLOGY The data below is derived by treating both people and venues as airport locations and using travel time as our primary instrument. 1. For each responder for the current Doodle poll, assign a home airport based on their draft publication history. We're missing a few people but basically it should be pretty complete. Since these people responded before the venue is known, it's at least somewhat unbiased. 2. Compute the shortest advertised flight between each home airport and the locations for each venue by looking at the shortest advertised Kayak flights around one of the proposed interim dates (6/10 - 6/13), ignoring price, but excluding "Hacker fares". [Thanks to Martin Thomson or helping me gather these.] This lets us compute statistics for any venue and/or combination of venues, based on the candidate attendee list. The three proposed venues: - San Francisco (SFO) - Boston (BOS) - Stockholm (ARN) Three hubs not too distant from the proposed venues: - London (LHR) - Frankfurt (FRA) - New York (NYC) [0] Also, Calgary (YYC), since the other two chair locations (BOS and SFO) were already proposed as venues, and I didn't want Cullen to feel left out. RESULTS Here are the results for each of the above venues, measured in total hours of travel (i.e., round trip). Venue Mean Median SD ---------------------------------------------- SFO 13.5 11 12.2 BOS 12.3 11 7.5 ARN 17.0 21 10.7 FRA 14.8 17 7.3 LHR 13.3 14 7.5 NYC 11.5 11 5.8 YYC 14.9 13 10.2 SFO/BOS/ARN 14.3 13 3.6 SFO/NYC/LHR 12.7 11.3 3.7 XXX/YYY/ZZZ a three-way rotation of XXX, YYY, and ZZZ. Obviously, mean and median are intended to be some sort of aggregate measure of travel time. I don't have any way to measure "fairness", but SD is intended as some metric of the variation in travel time between attendees. The raw data and software are attached. The files are: home-airports -- the list of people's home airports durations.txt -- the list of airport-airport durations doodle.txt -- the attendees list pairings.py -- the software to compute travel times doodle-out.txt -- the computed travel times for each attendee Obviously, there could be an error in the raw data or the software. Please feel free to send corrections, especially if you find something material. OBSERVATIONS Obviously, it's hard to know what the optimal solution is without some model for optimality, but we can still make some observations based on this data: 1. If we're just concerned with minimizing total travel time, then we would always in New York, since it has both the shortest mean travel time and the shortest median travel time, but as I said above, this arguably isn't fair to people who live either in Europe or California, since they always have to travel. 2. Combining West Coast, East Coast, and European venues has comparable (or at least not too much worse) mean/median values than NYC with much lower SDs. So, arguably that kind of mix is more fair. 3. There's a pretty substantial difference between hub and non-hub venues. In particular, LHR has a median travel time 7 hours less than ARN, and the SFO/NYC/LHR combination has a median/mean travel time about 2 hours less than SFO/BOS/ARN (primarily accounted for by the LHR/ARN difference). [Full disclosure, I've favored Star Alliance hubs here, but you'd probably get similar results if, for instance, you used AMS instead of LHR.] Obviously, your mileage may vary based on your location and feelings about what's fair, but based on this data, it looks to me like a three-way rotation between West Coast, East Coast, and European hubs offers a good compromise between minimum cost and a flat distribution of travel times. Personally, whatever we decide to do I'd ask that the WG settle now on a pattern going forward so that we can predictably budget our travel time and dollars. [0] Treating all three NYC airports as a single location. --00235445b92231536004bd3f663c Content-Type: text/plain; charset=US-ASCII; name="durations.txt" Content-Disposition: attachment; filename="durations.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0tliymc1 CiMgU0ZPCkJPUyBTRk8gMTIKVExWIFNGTyAzNApJQ04gU0ZPIDIzCkxIUiBTRk8gMjEKSEVMIFNG TyAzMApNQ08gU0ZPIDExCkVXUiBTRk8gMTEKVFJOIFNGTyAyOApERlcgU0ZPIDcKU0VBIFNGTyA0 CkNERyBTRk8gMjEKQ0hTIFNGTyAxNApZWUMgU0ZPIDYKTUZSIFNGTyAxIDEKQVJOIFNGTyAxNCAx MwpTVEwgU0ZPIDQgNApQSEwgU0ZPIDYgNQpQRUsgU0ZPIDEyIDEyCk1PVyBTRk8gMTYgMTUKR0xB IFNGTyAxNCAxMwpJQUQgU0ZPIDYgNQoKIyBCT1MJClNGTyBCT1MgNSA2ClRMViBCT1MgMTUgMTMK SUNOIEJPUyAxNyAxNwpMSFIgQk9TIDcgNgpIRUwgQk9TIDEwIDEwCk1DTyBCT1MgMyAzCkVXUiBC T1MgMSAxClRSTiBCT1MgMTEgMTAKREZXIEJPUyAzIDQKU0VBIEJPUyA1IDYKQ0RHIEJPUyA3IDcK Q0hTIEJPUyA0IDQKWVlDIEJPUyA2IDcKTUZSIEJPUyA3IDgKQVJOIEJPUyAxMCA5ClNUTCBCT1Mg MyAzClBITCBCT1MgMSAxClBFSyBCT1MgMTYgMTcKTU9XIEJPUyAxMiAxMQpHTEEgQk9TIDEwIDgK SUFEIEJPUyAxIDIKCiMgQVJOClNGTyBBUk4gMTMgMTQKQk9TIEFSTiA5IDEwClRMViBBUk4gNyA2 CklDTiBBUk4gMTIgMTEKTEhSIEFSTiAyIDIKSEVMIEFSTiAxIDEKTUNPIEFSTiAxMiAxMwpFV1Ig QVJOIDggOQpUUk4gQVJOIDQgNQpERlcgQVJOIDE0IDE0ClNFQSBBUk4gMTEgMTMKQ0RHIEFSTiAy IDMKQ0hTIEFSTiAxMiAxMwpZWUMgQVJOIDEzIDEyCk1GUiBBUk4gMTUgMTkKU1RMIEFSTiAxMyAx MwpQSEwgQVJOIDExIDEyClBFSyBBUk4gMTAgOQpNT1cgQVJOIDIgMgpHTEEgQVJOIDUgNQpJQUQg QVJOIDEwIDExCgojSkZLCk1PVyBKRksgOSA5ClBFSyBKRksgMTMgMTQKUEhMIEpGSyAxIDEKU1RM IEpGSyAzIDMKQVJOIEpGSyA5IDkKTUZSIEpGSyA3IDgKWVlDIEpGSyA3IDcKQ0hTIEpGSyAyIDIK Q0RHIEpGSyA4IDcKU0VBIEpGSyA1IDYKRVdSIEpGSyAwIDAKREZXIEpGSyA0IDQKTUNPIEpGSyAz IDMKU0ZPIEpGSyA2IDYKQk9TIEpGSyAxIDEKVExWIEpGSyAxMiAxMApJQ04gSkZLIDE0IDE0CkhF TCBKRksgOSA4CkxIUiBKRksgOCA3ClRSTiBKRksgMTEgMTAKR0xBIEpGSyAxMCA5CklBRCBKRksg MSAxCgojRlJBCk1PVyBGUkEgMyAzClBITCBGUkEgOCA5CkFSTiBGUkEgMiAyCk1GUiBGUkEgMTMg MTQKQ0RHIEZSQSA5IDEwClNFQSBGUkEgMTAgMTAKU1RMIEZSQSAxMCAxMgpZWUMgRlJBIDkgMTAK Q0hTIEZSQSAxMCAxMgpQRUsgRlJBIDEwIDkKRVdSIEZSQSA3IDkKVFJOIEZSQSAxIDEKREZXIEZS QSAxMCAxMQpNQ08gRlJBIDkgMTAKSEVMIEZSQSAzIDIKTEhSIEZSQSAyIDIKSUNOIEZSQSAxMiAx MApUTFYgRlJBIDUgNApCT1MgRlJBIDcgOApTRk8gRlJBIDExIDExCkdMQSBGUkEgMyA0CklBRCBG UkEgOCA5CgoKI0xIUgpNT1cgTEhSIDQgNApQSEwgTEhSIDcgNwpBUk4gTEhSIDIgMgpNRlIgTEhS IDE0IDE2CkNERyBMSFIgMSAxClNFQSBMSFIgOSAxMApTVEwgTEhSIDEwIDExCllZQyBMSFIgOSA5 CkNIUyBMSFIgMTAgMTIKUEVLIExIUiAxMSAxMApFV1IgTEhSIDcgOApUUk4gTEhSIDMgNApERlcg TEhSIDkgMTAKTUNPIExIUiAxMCAxMgpIRUwgTEhSIDMgMwpJQ04gTEhSIDEyIDExClRMViBMSFIg NSA1CkJPUyBMSFIgNiA3ClNGTyBMSFIJMTAgMTEKR0xBIExIUiAxIDEKSUFEIExIUiA3IDgKCgoj WVlDCk1PVyBZWUMgMTYgMTQKUEhMIFlZQyA3IDYKQVJOIFlZQyAxMiAxMwpNRlIgWVlDIDQgNApD REcgWVlDIDEyIDEyClNFQSBZWUMgMSAyClNUTCBZWUMgNSA1CkNIUyBZWUMgNyA3ClBFSyBZWUMg MTQgMTQKRVdSIFlZQyA1IDQKVFJOIFlZQyAxMyAxMgpERlcgWVlDIDQgNApNQ08gWVlDIDggNwpI RUwgWVlDIDE2IDEzCklDTiBZWUMgMTMgMTQKVExWIFlZQyAxOSAxNQpCT1MgWVlDIDcgNgpTRk8g WVlDIDMgMwpHTEEgWVlDIDEyIDEyCklBRCBZWUMgNiA2CkxIUiBZWUMgOSA5CgojTllDClRMViBO WUMgMTIgMTAKQk9TIE5ZQyAxIDEKTEhSIE5ZQyA4IDcKU0ZPIE5ZQyA1IDYKSEVMIE5ZQyA5IDgK SUNOIE5ZQyAxNCAxNApNQ08gTllDIDMgMwpUUk4gTllDIDExIDEwCkRGVyBOWUMgMyA0CkNERyBO WUMgOCA3ClNFQSBOWUMgNSA2Ck1GUiBOWUMgOSA5CkNIUyBOWUMgMiAyClNUTCBOWUMgMiAzCkFS TiBOWUMgOSA4CllZQyBOWUMgNSA1ClBITCBOWUMgMSAxClBFSyBOWUMgMTMgMTQKTU9XIE5ZQyA5 IDkKR0xBIE5ZQyA4IDcKSUFEIE5ZQyAxIDEKI0RPTkUKCgoKI1RFTVBMQVRFCk1PVyBYWFgKUEhM IFhYWApBUk4gWFhYCk1GUiBYWFgKQ0RHIFhYWApTRUEgWFhYClNUTCBYWFgKWVlDIFhYWApDSFMg WFhYClBFSyBYWFgKRVdSIFhYWApUUk4gWFhYCkRGVyBYWFgKTUNPIFhYWApIRUwgWFhYCklDTiBY WFgKVExWIFhYWApCT1MgWFhYClNGTyBYWFgKR0xBIFhYWApJQUQgWFhYCkxIUiBYWFgK --00235445b92231536004bd3f663c Content-Type: application/octet-stream; name=home-airports Content-Disposition: attachment; filename=home-airports Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0tlind60 RGFuIFdpbmcgICAgICAgICAgICAgICAgU0ZPCkp1c3RpbiBVYmVydGkgICAgICAgICAgIEJPUwpM ZW9uIFBvcnRtYW4gICAgICAgICAgICBUTFYKV29uc3VrIExlZSAgICAgICAgICAgICAgSUNOClNv by1IeXVuIENob2kgICAgICAgICAgIExIUgpBbmFudCBOYXJheWFuYW4gICAgICAgICBTRk8KQWxl a3NhbmRyIEF2c2V5ZXYgICAgICAgU0ZPCkdvbnphbG8gQ2FtYXJpbGxvICAgICAgIEhFTApEYW4g QnVybmV0dCAgICAgICAgICAgICBNQ08KUm9oaXQgUHVyaSAgICAgICAgICAgICAgU0ZPICAKU3Rl cGhhbiBXZW5nZXIgICAgICAgICAgRVdSCk1hdXJvIENhYnV0dG8gICAgICAgICAgIFRSTgpSb2Jl cnQgU3BhcmtzICAgICAgICAgICBERlcKVGltb3RoeSBUZXJyaWJlcnJ5ICAgICAgU0ZPCkJlcm5h cmQgQWJvYmEgICAgICAgICAgIFNFQQpNYXJ5IEJhcm5lcyAgICAgICAgICAgICBERlcKVmVua2F0 ZXNoIFZlbmthdGFyYW1hbmFuICAgIFNGTyAgICAgCkppbSBCYXJuZXR0ICAgICAgICAgICAgIEJP UyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIApBbmRyZXcgSHV0dG9uICAgICAgICAgICBM SFIKWGF2aWVyIE1hcmpvdSAgICAgICAgICAgQ0RHClJhbmRhbGwgU3Rld2FydCAgICAgICAgIENI UwpIZW5yeSBMdW0gICAgICAgICAgICAgICBZWUMKTWlsYW4gWW91bmcgICAgICAgICAgICAgTUZS CllhaXIgV2llbmVyICAgICAgICAgICAgIFRMVgpBcm9uIFJvc2VuYmVyZyAgICAgICAgICBTRk8K RGFuIERydXRhICAgICAgICAgICAgICAgU0VBCkNocmlzdGVyIEhvbG1iZXJnICAgICAgIEFSTgpT cGVuY2VyIERhd2tpbnMgICAgICAgICBERlcKT3NjYXIgT2hsc3NvbiAgICAgICAgICAgQVJOCk5l aWwgU3RyYXRmb3JkICAgICAgICAgIExIUgpNYXJjIFBldGl0LUh1Z3VlbmluICAgICBTRk8KRXJp YyBSZXNjb3JsYSAgICAgICAgICAgU0ZPCk1hcmt1cyBJc29tYWtpICAgICAgICAgIEhFTApNYXRo aWV1IEhvZm1hbiAgICAgICAgICBTRk8gClN0ZWZhbiBIYWthbnNzb24gICAgICAgIEFSTgpKb25h dGhhbiBMZW5ub3ggICAgICAgICBFV1IKTWF0dGhldyBLYXVmbWFuICAgICAgICAgU0ZPCk1haGFs aW5nYW0gTWFuaSAgICAgICAgIFNGTwpDdWxsZW4gSmVubmluZ3MgICAgICAgICBZWUMKTWFnbnVz IFdlc3Rlcmx1bmQgICAgICAgQVJOCkhhcmFsZCBBbHZlc3RyYW5kICAgICAgIEFSTgpNaWNoYWVs IFRob3JuYnVyZ2ggICAgICBTRk8KQWxhbiBKb2huc3RvbiAgICAgICAgICAgU1RMCk1hcnRpbiBU aG9tc29uICAgICAgICAgIFNGTwpSYW5kZWxsIEplc3VwICAgICAgICAgICBQSEwKTWFpcmUgRC4g UmVhdnkgICAgICAgICAgUEhMCkNhcnkgRml0emdlcmFsZCAgICAgICAgIFNGTwpMaSBaaGVuZ2Rv bmcgICAgICAgICAgICBQRUsKSm9uYXRoYW4gUm9zZW5iZXJnICAgICAgRVdSClRlZCBIYXJkaWUg ICAgICAgICAgICAgIFNGTwpBZGFtIEJlcmdrdmlzdCAgICAgICAgICBBUk4KU3VoYXMgTmFuZGFr dW1hciAgICAgICAgU0ZPCkxhcnMgRWdnZXJ0ICAgICAgICAgICAgIEhFTApIYWRyaWVsIEthcGxh biAgICAgICAgICBCT1MKTWFuamVzaCBNYWxhdmFsbGkgICAgICAgU0ZPCkFsZXhleSBBeWxhcm92 ICAgICAgICAgIE1PVwpMYXphciBCaXZvbGFyc2tpICAgICAgICBTRk8KUm9iZXJ0IFdvbGZmCkFz aGlzaCBUaGFwbGl5YWwKRG9taW5pcXVlIEhhemFlbC1NYXNzaWV1eCBDREcKQ29saW4gUGVya2lu cyBHTEEKUm9uaSBFdmVuIFRMVgpSaWNoYXJkIEJhcm5lcyBJQUQKRGFuIFJvbWFzY2FudSBUTFYK Q2hhcmxlcyBFY2tlbCBTRk8KQW5kcmV3IEFsbGVuIE1DTwpFS1IgU0ZPCg== --00235445b92231536004bd3f663c Content-Type: text/plain; charset=US-ASCII; name="doodle.txt" Content-Disposition: attachment; filename="doodle.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0tljeui2 TWFnbnVzIFdlc3Rlcmx1bmQJCQkJCQkKVGVkIEhhcmRpZQkJCQkJCQpEb21pbmlxdWUgSGF6YWVs LU1hc3NpZXV4CQkJCkJlcm5hcmQgQWJvYmEJCk1hcnRpbiBUaG9tc29uCQkJCQkJCkhhcmFsZCBB bHZlc3RyYW5kCQkJCQkJCk1hcnkgQmFybmVzCQpDb2xpbiBQZXJraW5zCQkJCQkJClJpY2hhcmQg QmFybmVzCQkJCQkJCkdvbnphbG8gQ2FtYXJpbGxvCQkJCQkKRGFuIFdpbmcJCQkJCQkKSmltIEJh cm5ldHQJCQkJCQkKTGFycyBFZ2dlcnQJClZlbmthdGVzaCBWZW5rYXRhcmFtYW5hbgkJCQkJCQpN YWhhbGluZ2FtIE1hbmkKQXJvbiBSb3NlbmJlcmcJCQkJCQkKQ2hyaXN0ZXIgSG9sbWJlcmcJCQkJ CQkKQW5kcmV3IEh1dHRvbgkJCQkJCQpDaGFybGVzIEVja2VsCQpSb25pIEV2ZW4JClJhbmRlbGwg SmVzdXAJCQkJCQkKU3RlZmFuIEhha2Fuc3NvbgkKSnVzdGluIFViZXJ0aQkJCQkJCQpEYW4gUm9t YXNjYW51CQkKRGFuIERydXRhCQkJCQkJCkFuZHJldyBBbGxlbgkKSGFkcmllbCBLYXBsYW4KRUtS CkN1bGxlbiBKZW5uaW5ncwo= --00235445b92231536004bd3f663c Content-Type: application/octet-stream; name="pairings.py" Content-Disposition: attachment; filename="pairings.py" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0tljq9r3 IyEvdXNyL2Jpbi9lbnYgcHl0aG9uCmltcG9ydCBzeXMKaW1wb3J0IHJlCmltcG9ydCBtYXRoCmZy b20gb3B0cGFyc2UgaW1wb3J0IE9wdGlvblBhcnNlcgoKCkhPTUVfQUlSUE9SVFNfRklMRSA9ICJo b21lLWFpcnBvcnRzIgpEVVJBVElPTlNfRklMRSA9ICJkdXJhdGlvbnMudHh0IgoKSE9NRV9BSVJQ T1JUUyA9IHt9CkRVUkFUSU9OUyA9IHt9CkFUVEVOREVFUyA9IFtdCkFJUlBPUlRTID0gW10KTE9D QVRJT05TID0gWydTRk8nLCAnQk9TJywgJ0FSTicsICdGUkEnLCAnSkZLJywgJ0xIUicsICdZWUMn LCAnTllDJ10KTUFYX0RVUkFUSU9OID0gMAoKCmRlZiBkaWUobXNnKToKICAgIHByaW50IG1zZwog ICAgc3lzLmV4aXQoMSkKCmRlZiBkdW1wX3VybHMoKToKICAgIHcgPSBvcGVuKCJsb2NhdGlvbnMt dXJscy5odG1sIiwndycpCiAgICB0ID0gb3BlbigiZHVyYXRpb25zLXRtcGwudHh0IiwgJ3cnKQoK ICAgIGZvciBsIGluIExPQ0FUSU9OUzoKICAgICAgICB3LndyaXRlKCI8aDM+JXM8L2gzPiIlbCkK ICAgICAgICB3LndyaXRlKCJcbiIpCiAgICAgICAgdC53cml0ZSgiXG4jICVzXG4iJWwpCiAgICAg ICAgZm9yIGEgaW4gQUlSUE9SVFM6CiAgICAgICAgICAgIGlmIGEgPT0gbDoKICAgICAgICAgICAg ICAgIGNvbnRpbnVlCiAgICAgICAgICAgIHcud3JpdGUoJzxhIGhyZWY9Imh0dHA6Ly93d3cua2F5 YWsuY29tLyMvZmxpZ2h0cy8lcy0lcy8yMDEyLTA2LTEwLzIwMTItMDYtMTMvMWFkdWx0cyI+JXMt JXM8L2E+PGJyPiclKGEsbCxhLGwpKQogICAgICAgICAgICB3LndyaXRlKCJcbiIpCiAgICAgICAg ICAgIHQud3JpdGUoIiVzICVzXG4iJShhLGwpKQoKZGVmIGNvbXB1dGVfbG9jYXRpb25fc3RhdHMo bCk6CiAgICBkdXJhdGlvbl90b3RhbCA9IDAKICAgIGR1cmF0aW9uX2hpc3QgPSBbXQogICAgZHVy YXRpb25zID0ge30KCiAgICBmb3IgaSBpbiByYW5nZSgwLE1BWF9EVVJBVElPTiArIDEpOgogICAg ICAgIGR1cmF0aW9uX2hpc3QuYXBwZW5kKDApCiAgICAgICAgICAgICAgICAgICAKICAgIGZvciBh IGluIEFUVEVOREVFUzoKICAgICAgICBob21lX2FpcnBvcnQgPSBIT01FX0FJUlBPUlRTW2FdCiAg ICAgICAgaWYgaG9tZV9haXJwb3J0ID09IGw6CiAgICAgICAgICAgIGR1cmF0aW9uID0gMAogICAg ICAgIGVsaWYgaG9tZV9haXJwb3J0ID09ICJFV1IiIGFuZCBsID09ICJOWUMiOgogICAgICAgICAg ICBkdXJhdGlvbiA9IDAKICAgICAgICBlbHNlOgogICAgICAgICAgICByb3V0ZSA9ICIlczolcyIl KGhvbWVfYWlycG9ydCwgbCkKICAgICAgICAgICAgZHVyYXRpb24gPSBEVVJBVElPTlNbcm91dGVd CiAgICAgICAgZHVyYXRpb25fdG90YWwgKz0gZHVyYXRpb24KICAgICAgICBkdXJhdGlvbl9oaXN0 W2R1cmF0aW9uXSArPSAxCiAgICAgICAgZHVyYXRpb25zW2FdID0gZHVyYXRpb24KCiAgICByZXR1 cm4gW3JvdW5kKGR1cmF0aW9uX3RvdGFsIC8gbGVuKEFUVEVOREVFUykpLCBkdXJhdGlvbl9oaXN0 LCBkdXJhdGlvbnNdCgoKZGVmIHJlYWRfYWlycG9ydHMoKToKICAgICMgUmVhZCBob21lIGFpcnBv cnRzIGZpbGUKICAgIGYgPSBvcGVuKEhPTUVfQUlSUE9SVFNfRklMRSkKICAgIGlmIGYgaXMgTm9u ZToKICAgICAgICBkaWUoIkNvdWxkbid0IG9wZW4gYXR0ZW5kZWVzIGZpbGUiKQogICAgZm9yIGwg aW4gZjoKICAgICAgICBsID0gbC5zdHJpcCgpCiAgICAgICAgYXJncyA9IGwuc3BsaXQoIiAiKQog ICAgICAgIGFpcnBvcnQgPSBhcmdzLnBvcCgpCiAgICAgICAgaWYgcmUubWF0Y2goIl5bQS1aXSsk IiwgYWlycG9ydCkgaXMgTm9uZToKICAgICAgICAgICAgcHJpbnQgIkFpcnBvcnQgbm90IHNwZWNp ZmllZCBmb3IgJXMiJSIgIi5qb2luKGFyZ3MpLnN0cmlwKCkKICAgICAgICAgICAgY29udGludWUK ICAgIAogICAgICAgIGF0dGVuZGVlID0gIiAiLmpvaW4oYXJncykuc3RyaXAoKQogICAgICAgIGlm IGF0dGVuZGVlIGluIEhPTUVfQUlSUE9SVFM6CiAgICAgICAgICAgIGRpZSgiUmVwZWF0IGF0dGVu ZGVlICVzIiVhdHRlbmRlZSkKICAgIAogICAgICAgIEhPTUVfQUlSUE9SVFNbYXR0ZW5kZWVdID0g YWlycG9ydAogICAgICAgIHByaW50ICJBaXJwb3J0ID0gIiArIGFpcnBvcnQKICAgICAgICBpZiBu b3QgYWlycG9ydCBpbiBBSVJQT1JUUzoKICAgICAgICAgICAgQUlSUE9SVFMuYXBwZW5kKGFpcnBv cnQpCiAgICAKICAgIHByaW50ICJBbGwgYWlycG9ydHMgKCVkKSAiJShsZW4oQUlSUE9SVFMpKSwg QUlSUE9SVFMKCmRlZiByZWFkX2F0dGVuZGVlcygpOgogICAgIyBSZWFkIHRoZSBhdHRlbmRlZXMg bGlzdAogICAgZiA9IG9wZW4ob3B0aW9ucy5hdHRlbmRlZXMpCiAgICBpZiBmIGlzIE5vbmU6CiAg ICAgICAgZGllKCJDb3VsZG4ndCBvcGVuIGF0dGVuZGVlcyBmaWxlIikKICAgIGZvciBsIGluIGY6 CiAgICAgICAgbCA9IGwuc3RyaXAoKQogICAgICAgIGlmIG5vdCBsIGluIEhPTUVfQUlSUE9SVFM6 CiAgICAgICAgICAgIGRpZSgiQ291bGQgbm90IGZpbmQgaG9tZSBhaXJwb3J0IGZvciAlcyIlbCkK ICAgICAgICBBVFRFTkRFRVMuYXBwZW5kKGwpCiAgICAKI2R1bXBfdXJscygpCgpkZWYgcmVhZF9k dXJhdGlvbnMoKToKICAgIGdsb2JhbCBNQVhfRFVSQVRJT04KICAgIAogICAgIyBSZWFkIHRoZSBh aXJwb3J0IGRpc3RhbmNlcwogICAgZiA9IG9wZW4oRFVSQVRJT05TX0ZJTEUpCiAgICBpZiBmIGlz IE5vbmU6CiAgICAgICAgZGllKCJDb3VsZG4ndCBvcGVuIGR1cmF0aW9ucyBmaWxlIikKICAgIGZv ciBsIGluIGY6CiAgICAgICAgbCA9IGwuc3RyaXAoKQogICAgICAgIGlmIGwgPT0gIiI6CiAgICAg ICAgICAgIGNvbnRpbnVlCiAgICAgICAgaWYgbCA9PSAiI0RPTkUiOgogICAgICAgICAgICBicmVh awogICAgICAgIGlmIHJlLm1hdGNoKCJeIyIsIGwpOgogICAgICAgICAgICBjb250aW51ZQogICAg ICAgIGFyZ3MgPSBsLnNwbGl0KCIgIikKICAgICAgICBpZiBsZW4oYXJncykgPT0gNDoKICAgICAg ICAgICAgZHVyYXRpb24gPSBpbnQoYXJnc1syXSkgKyBpbnQoYXJnc1szXSkKICAgICAgICBlbGlm IGxlbihhcmdzKSA9PSAzOgogICAgICAgICAgICBkdXJhdGlvbiA9IGludChhcmdzWzJdKQogICAg ICAgIGVsc2U6CiAgICAgICAgICAgIGRpZSgiQm9ndXMgbGluZSAlcyIlbCkKICAgIAogICAgICAg IGlmIGR1cmF0aW9uID4gTUFYX0RVUkFUSU9OOgogICAgICAgICAgICBNQVhfRFVSQVRJT04gPSBk dXJhdGlvbgogICAgICAgIERVUkFUSU9OU1siJXM6JXMiJShhcmdzWzBdLCBhcmdzWzFdKV09ZHVy YXRpb24KICAgICAgICBEVVJBVElPTlNbIiVzOiVzIiUoYXJnc1sxXSwgYXJnc1swXSldPWR1cmF0 aW9uCiAgICAKCgpwYXJzZXIgPSBPcHRpb25QYXJzZXIoKQpwYXJzZXIuYWRkX29wdGlvbignLWEn LCAnLS1hdHRlbmRlZXMnLCBkZXN0PSdhdHRlbmRlZXMnLAogICAgICAgICAgICAgICAgICBkZWZh dWx0PSdkb29kbGUudHh0JykKcGFyc2VyLmFkZF9vcHRpb24oJy1vJywgJy0tb3V0cHV0JywgZGVz dD0nb3V0cHV0JywKICAgICAgICAgICAgICAgICAgZGVmYXVsdD0nb3V0cHV0LnR4dCcpCnBhcnNl ci5hZGRfb3B0aW9uKCctTycsICctLWhpc3QnLCBkZXN0PSdoaXN0JywKICAgICAgICAgICAgICAg ICAgZGVmYXVsdD0naGlzdC50eHQnKQoob3B0aW9ucywgYXJncykgPSBwYXJzZXIucGFyc2VfYXJn cygpCgpyZWFkX2FpcnBvcnRzKCkKcmVhZF9hdHRlbmRlZXMoKQpyZWFkX2R1cmF0aW9ucygpCgpE RVRBSUwgPSB7fQpISVNUID0ge30KCiMgTm93IGNvbXB1dGUgdGhlIHJlc3VsdHMKZm9yIGwgaW4g TE9DQVRJT05TOgogICAgcmVzID0gY29tcHV0ZV9sb2NhdGlvbl9zdGF0cyhsKQogICAgREVUQUlM W2xdID0gcmVzWzJdCiAgICBISVNUW2xdID0gcmVzWzFdCiAgICBwcmludCAiJXMgJWQiJShsLCBy ZXNbMF0pCiAgICAKCm8gPSBvcGVuKG9wdGlvbnMub3V0cHV0LCAndycpCmlmIG8gaXMgTm9uZToK ICAgIGRpZSgiQ291bGQgbm90IG9wZW4gJXMiJW9wdGlvbnMub3V0cHV0KQoKby53cml0ZSgiQXR0 ZW5kZWUiKQoKZm9yIGwgaW4gTE9DQVRJT05TOgogICAgby53cml0ZSgiXHQlcyIlbCkKby53cml0 ZSgiXG4iKQoKZm9yIGF0dGVuZGVlIGluIEFUVEVOREVFUzoKICAgIG8ud3JpdGUoYXR0ZW5kZWUp CiAgICBmb3IgbCBpbiBMT0NBVElPTlM6CiAgICAgICAgby53cml0ZSgiXHQlZCIlKERFVEFJTFts XVthdHRlbmRlZV0pKQogICAgby53cml0ZSgiXG4iKQoKby5jbG9zZSgpCgoKbyA9IG9wZW4ob3B0 aW9ucy5oaXN0LCAndycpCmlmIG8gaXMgTm9uZToKICAgIGRpZSgiQ291bGQgbm90IG9wZW4gJXMi JW9wdGlvbnMuaGlzdCkKby53cml0ZSgiSG91cnMiKSAgICAKZm9yIGwgaW4gTE9DQVRJT05TOgog ICAgby53cml0ZSgiXHQlcyIlbCkKby53cml0ZSgiXG4iKQoKZm9yIGkgaW4gcmFuZ2UoMCwgTUFY X0RVUkFUSU9OICsgMSk6CiAgICBvLndyaXRlKCIlZCIlaSkKICAgIGZvciBsIGluIExPQ0FUSU9O UzoKICAgICAgICBvLndyaXRlKCJcdCVzIiVISVNUW2xdW2ldKQogICAgby53cml0ZSgiXG4iKQoK CgogICAgICAgIAoKICAgIAo= --00235445b92231536004bd3f663c Content-Type: text/plain; charset=US-ASCII; name="doodle-out.txt" Content-Disposition: attachment; filename="doodle-out.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0tlk0vc4 QXR0ZW5kZWUJU0ZPCUJPUwlBUk4JRlJBCUpGSwlMSFIJWVlDCU5ZQwpNYWdudXMgV2VzdGVybHVu ZAkyNwkxOQkwCTQJMTgJNAkyNQkxNwpUZWQgSGFyZGllCTAJMTEJMjcJMjIJMTIJMjEJNgkxMQpE b21pbmlxdWUgSGF6YWVsLU1hc3NpZXV4CTIxCTE0CTUJMTkJMTUJMgkyNAkxNQpCZXJuYXJkIEFi b2JhCTQJMTEJMjQJMjAJMTEJMTkJMwkxMQpNYXJ0aW4gVGhvbXNvbgkwCTExCTI3CTIyCTEyCTIx CTYJMTEKSGFyYWxkIEFsdmVzdHJhbmQJMjcJMTkJMAk0CTE4CTQJMjUJMTcKTWFyeSBCYXJuZXMJ Nwk3CTI4CTIxCTgJMTkJOAk3CkNvbGluIFBlcmtpbnMJMjcJMTgJMTAJNwkxOQkyCTI0CTE1ClJp Y2hhcmQgQmFybmVzCTExCTMJMjEJMTcJMgkxNQkxMgkyCkdvbnphbG8gQ2FtYXJpbGxvCTMwCTIw CTIJNQkxNwk2CTI5CTE3CkRhbiBXaW5nCTAJMTEJMjcJMjIJMTIJMjEJNgkxMQpKaW0gQmFybmV0 dAkxMQkwCTE5CTE1CTIJMTMJMTMJMgpMYXJzIEVnZ2VydAkzMAkyMAkyCTUJMTcJNgkyOQkxNwpW ZW5rYXRlc2ggVmVua2F0YXJhbWFuYW4JMAkxMQkyNwkyMgkxMgkyMQk2CTExCk1haGFsaW5nYW0g TWFuaQkwCTExCTI3CTIyCTEyCTIxCTYJMTEKQXJvbiBSb3NlbmJlcmcJMAkxMQkyNwkyMgkxMgky MQk2CTExCkNocmlzdGVyIEhvbG1iZXJnCTI3CTE5CTAJNAkxOAk0CTI1CTE3CkFuZHJldyBIdXR0 b24JMjEJMTMJNAk0CTE1CTAJMTgJMTUKQ2hhcmxlcyBFY2tlbAkwCTExCTI3CTIyCTEyCTIxCTYJ MTEKUm9uaSBFdmVuCTM0CTI4CTEzCTkJMjIJMTAJMzQJMjIKUmFuZGVsbCBKZXN1cAkxMQkyCTIz CTE3CTIJMTQJMTMJMgpTdGVmYW4gSGFrYW5zc29uCTI3CTE5CTAJNAkxOAk0CTI1CTE3Ckp1c3Rp biBVYmVydGkJMTEJMAkxOQkxNQkyCTEzCTEzCTIKRGFuIFJvbWFzY2FudQkzNAkyOAkxMwk5CTIy CTEwCTM0CTIyCkRhbiBEcnV0YQk0CTExCTI0CTIwCTExCTE5CTMJMTEKQW5kcmV3IEFsbGVuCTEx CTYJMjUJMTkJNgkyMgkxNQk2CkhhZHJpZWwgS2FwbGFuCTExCTAJMTkJMTUJMgkxMwkxMwkyCkVL UgkwCTExCTI3CTIyCTEyCTIxCTYJMTEKQ3VsbGVuIEplbm5pbmdzCTYJMTMJMjUJMTkJMTQJMTgJ MAkxMAo= --00235445b92231536004bd3f663c-- From randell-ietf@jesup.org Mon Apr 9 07:23: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 BF7D521F8725 for ; Mon, 9 Apr 2012 07:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, J_CHICKENPOX_14=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 kMBDZrzw1611 for ; Mon, 9 Apr 2012 07:23:16 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2643021F86CE for ; Mon, 9 Apr 2012 07:23:15 -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 1SHFUx-0001Lh-6a for rtcweb@ietf.org; Mon, 09 Apr 2012 09:23:15 -0500 Message-ID: <4F82EFF5.5040604@jesup.org> Date: Mon, 09 Apr 2012 10:19:33 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7415D5.80604@ericsson.com> <4F79E03B.3090802@jesup.org> <4F82C1C0.60809@alvestrand.no> In-Reply-To: <4F82C1C0.60809@alvestrand.no> 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] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 14:23:16 -0000 On 4/9/2012 7:02 AM, Harald Alvestrand wrote: > On 04/02/2012 07:22 PM, Randell Jesup wrote: >> So the question for me is "what scenarios/use-cases does this enable?" >> >> 1) Mesh Conferencing >> >> While there are many ways to handle conferencing, if you have a mesh >> (full or partial), you need to create new PeerConnections for existing >> members of the mesh when someone joins. There are two ways to do this: >> a) somehow application-specific tell the new member who to send >> invites to, and then start N PeerConnection calls with some "I'm in >> the conference" token; >> b)have them send N separate generic invites to the service provider >> which either forwards it to an existing member, or returns it with >> "it's ok, I've already forwarded invites for it); >> c) somehow tell all the existing members to invite the new member; or >> d) have the service provider fork the OFFER from the new member to all >> the existing members, and have all of them reply with ANSWERs. This >> requires PeerConnection cloning to work well. >> >> I strongly prefer d), and it also reduces conference join time (less >> round-trips, at least in theory - perhaps noticeably less by sharing >> the ICE candidate generation). > > Hmm.... for one new member, I don't think d) is actually different from > the case where the client sends an "extra" OFFER when he joins, and the > server uses the "hanging OFFER" to signal the new member. > This is a windowing protocol, though - the client would need to send a > new "hanging OFFER" after the current "hanging OFFER" has been "used > up". Right, and there would be complication when a new "hanging offer" hadn't yet been sent when another member joins (and it would be very easy for bugs to creep in there, as it's evil race-condition testing). "hanging offers" is not a protocol that I would like to implement. > Cloning allows you to connect multiple new conference mebers as > fast as the Javascript can accept them. (Which may have issues with > congestion, but that might be a price worth paying). And removes a whole passel of error paths and handling. > It's not clear to me whether hanging OFFERs work with NAT traversal; > would the ICE machine send keepalives for an association that hasn't > been associated yet? This certainly needs investigation; I could see it needing some type of occasional "still holding it" notification from the server anyways to keep the state active in the client. -- Randell Jesup randell-ietf@jesup.org From marshall.eubanks@gmail.com Mon Apr 9 08:36: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 A384C21F874A for ; Mon, 9 Apr 2012 08:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 LmSMYmrzrkJB for ; Mon, 9 Apr 2012 08:36:00 -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 5CB6B21F86FF for ; Mon, 9 Apr 2012 08:36:00 -0700 (PDT) Received: by lbok13 with SMTP id k13so2055890lbo.31 for ; Mon, 09 Apr 2012 08:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2IAlMV+0la8FHaSuoCcwdDgbYv0Fyy163Lp0goHpqR0=; b=SF0c1ON+TElUTsM8YD45cCLDXTGRtG8PkOXQj0Mo5M8ReJFT0kxj7B6epkvXU1y4ue VDMAq2dVm4IQVtOg032YO+Aeia4/Vn3zTgIyldsVKAaVOUDMx0B8dXkcdlCoDzZ19FkZ IBS4zThIgoh6bEssSsy3nWRJynm0sgVS6Kel7o707rZ6fXfyC0QLEMSqpSYTFQu3vXqA E5tjG/hXB9KwKIUpoc6bYM2t1MRo+DAneKdmo6ydwVChfYEYzf9O6XZfEc6WB8TOGCY8 zeVSDTWpHhRi1d53rawqkZ0VNyz2tu+DQenj3iQiAKyC6kANeO3fsOXgGcfZ99b4GcX7 Kc/g== MIME-Version: 1.0 Received: by 10.152.105.19 with SMTP id gi19mr12101175lab.11.1333985759187; Mon, 09 Apr 2012 08:35:59 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Mon, 9 Apr 2012 08:35:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Apr 2012 11:35:59 -0400 Message-ID: From: Marshall Eubanks To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] Data on travel times 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 Apr 2012 15:36:01 -0000 I really like this analysis. Some questions. 2012/4/9 Eric Rescorla : > Hi folks, > > Since it seems like we're going to be having a large number of > interims, I thought it might be instructive to try to analyze a bunch > of different locations to figure out the best strategy. My first cut > analysis is below. > > Note that I'm not trying to make any claims about what the best set of > venues is. It's obviously easy to figure out any statistic we want > about each proposed venue, but how you map that data to "best" is up > to you. In particular, there's some tradeoff between minimal total > travel time and a "fair" distribution of travel times (not that I > claim to know what that means). > > > METHODOLOGY > The data below is derived by treating both people and venues as > airport locations and using travel time as our primary instrument. > > 1. For each responder for the current Doodle poll, assign a home > =A0 airport based on their draft publication history. =A0We're missing a > =A0 few people but basically it should be pretty complete. Since > =A0 these people responded before the venue is known, it's at > =A0 least somewhat unbiased. > > 2. Compute the shortest advertised flight between each home airport > =A0 and the locations for each venue by looking at the shortest > =A0 advertised Kayak flights around one of the proposed interim > =A0 dates (6/10 - 6/13), ignoring price, but excluding "Hacker fares". > =A0 [Thanks to Martin Thomson or helping me gather these.] > 1.) Why are some fields doubled ? I.e., ARN SFO 14 13 Are these counted twice ? That would, of course, give more weight to those records. 2.) At any rate, I couldn't quite match your numbers. For SFO, for example, I got # SFO Records 29 | Mean 12.52 | RMS 15.34 | Std Dev 8.55 | Minimum 1.00 | Maximum 34.00 | This assumes that each doubled entry counts as 2 separate entries. If the second entries are ignored, I get # SFO Records 21 | Mean 14.05 | RMS 17.05 | Std Dev 9.14 | Minimum 1.00 | Maximum 34.00 | If two entries are averaged together (when present) # SFO Records 21 | Mean 13.93 | RMS 16.97 | Std Dev 9.18 | Minimum 1.00 | Maximum 34.00 | None of these 3 options match your Venue Mean Median SD ---------------------------------------------- SFO 13.5 11 12.2 In particular, your SD value seems high. (Note, I use the SD =3D root mean square /(n-1) not / n convention, but that won't explain the difference. ) Regards Marshall > This lets us compute statistics for any venue and/or combination > of venues, based on the candidate attendee list. > > The three proposed venues: > > - San Francisco (SFO) > - Boston (BOS) > - Stockholm (ARN) > > Three hubs not too distant from the proposed venues: > > - London (LHR) > - Frankfurt (FRA) > - New York (NYC) [0] > > Also, Calgary (YYC), since the other two chair locations (BOS and SFO) > were already proposed as venues, and I didn't want Cullen to feel > left out. > > > RESULTS > Here are the results for each of the above venues, measured in total > hours of travel (i.e., round trip). > > Venue =A0 =A0 =A0 =A0 Mean =A0 =A0 =A0 =A0 Median =A0 =A0 =A0 =A0 =A0 SD > ---------------------------------------------- > SFO =A0 =A0 =A0 =A0 =A0 13.5 =A0 =A0 =A0 =A0 =A0 =A0 11 =A0 =A0 =A0 =A0 1= 2.2 > BOS =A0 =A0 =A0 =A0 =A0 12.3 =A0 =A0 =A0 =A0 =A0 =A0 11 =A0 =A0 =A0 =A0 = =A07.5 > ARN =A0 =A0 =A0 =A0 =A0 17.0 =A0 =A0 =A0 =A0 =A0 =A0 21 =A0 =A0 =A0 =A0 1= 0.7 > FRA =A0 =A0 =A0 =A0 =A0 14.8 =A0 =A0 =A0 =A0 =A0 =A0 17 =A0 =A0 =A0 =A0 = =A07.3 > LHR =A0 =A0 =A0 =A0 =A0 13.3 =A0 =A0 =A0 =A0 =A0 =A0 14 =A0 =A0 =A0 =A0 = =A07.5 > NYC =A0 =A0 =A0 =A0 =A0 11.5 =A0 =A0 =A0 =A0 =A0 =A0 11 =A0 =A0 =A0 =A0 = =A05.8 > YYC =A0 =A0 =A0 =A0 =A0 14.9 =A0 =A0 =A0 =A0 =A0 =A0 13 =A0 =A0 =A0 =A0 1= 0.2 > SFO/BOS/ARN =A0 14.3 =A0 =A0 =A0 =A0 =A0 =A0 13 =A0 =A0 =A0 =A0 =A03.6 > SFO/NYC/LHR =A0 12.7 =A0 =A0 =A0 =A0 =A0 =A0 11.3 =A0 =A0 =A0 =A03.7 > > XXX/YYY/ZZZ a three-way rotation of XXX, YYY, and ZZZ. Obviously, mean > and median are intended to be some sort of aggregate measure of travel > time. I don't have any way to measure "fairness", but SD is intended > as some metric of the variation in travel time between attendees. > > The raw data and software are attached. The files are: > > =A0home-airports =A0 =A0 -- the list of people's home airports > =A0durations.txt =A0 =A0 -- the list of airport-airport durations > =A0doodle.txt =A0 =A0 =A0 =A0-- the attendees list > =A0pairings.py =A0 =A0 =A0 -- the software to compute travel times > =A0doodle-out.txt -- the computed travel times for each attendee > > Obviously, there could be an error in the raw data or the software. > Please feel free to send corrections, especially if you find > something material. > > > OBSERVATIONS > Obviously, it's hard to know what the optimal solution is without > some model for optimality, but we can still make some observations > based on this data: > > 1. If we're just concerned with minimizing total travel time, then we > would always in New York, since it has both the shortest mean travel > time and the shortest median travel time, but as I said above, this > arguably isn't fair to people who live either in Europe or California, > since they always have to travel. > > 2. Combining West Coast, East Coast, and European venues has > comparable (or at least not too much worse) mean/median values than > NYC with much lower SDs. So, arguably that kind of mix is more fair. > > 3. There's a pretty substantial difference between hub and non-hub > venues. In particular, LHR has a median travel time 7 hours less than > ARN, and the SFO/NYC/LHR combination has a median/mean travel time > about 2 hours less than SFO/BOS/ARN (primarily accounted for by the > LHR/ARN difference). [Full disclosure, I've favored Star Alliance hubs > here, but you'd probably get similar results if, for instance, you > used AMS instead of LHR.] > > > Obviously, your mileage may vary based on your location and feelings > about what's fair, but based on this data, it looks to me like a > three-way rotation between West Coast, East Coast, and European hubs > offers a good compromise between minimum cost and a flat distribution > of travel times. > > Personally, whatever we decide to do I'd ask that the WG settle now on > a pattern going forward so that we can predictably budget our travel > time and dollars. > > > [0] Treating all three NYC airports as a single location. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From ekr@rtfm.com Mon Apr 9 09:03: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 C96EC21F8753 for ; Mon, 9 Apr 2012 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[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 tJPIF2uw48Ca for ; Mon, 9 Apr 2012 09:03:21 -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 A2BDD21F8720 for ; Mon, 9 Apr 2012 09:03:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2785194vbb.31 for ; Mon, 09 Apr 2012 09:03:21 -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=4x6yI90r4nVRFELvADA733gj7ghqLXgACz7bijSd9X4=; b=B1ZKQLGGbkKi1IJoeJOQXb31maBuj/oDpCc8Z1ehbIgMcYBRSCFZ4Ri6kpIeNRsrrF 4iXU5zbaJLabh72NIHFZHT2G6aOb5DOP4W66mDLlBvprxHycFPlpGxLF5qCezDkiYuqC gpzvxnKvzGDoCe16SIokSH+3+aLWmIh676CCKUqCB4LGFObkdWPcS9HX45AFuPH/23Jr vbj7OxwnJSqSdlVbH97zJV7e6fwM4Z7AVJzjzfV8/Qrl2U1kNkblEVWgE5MB8KYY54KU mUNBZV+G8Jn9id1q5d2Mgz4K0gnst255caMszn+714l1PaGlYED0S8UkH2Mfh7vDlqIx p8LA== Received: by 10.220.153.8 with SMTP id i8mr3840272vcw.73.1333987401157; Mon, 09 Apr 2012 09:03:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Mon, 9 Apr 2012 09:02:41 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: From: Eric Rescorla Date: Mon, 9 Apr 2012 09:02:41 -0700 Message-ID: To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkoRJoPQsGGoFAKTlhD/iyte5PprletJQW7dxurPWSq+88Ho7QunAVA4iqvb4hdx+6Drxno Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] Data on travel times 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 Apr 2012 16:03:22 -0000 On Mon, Apr 9, 2012 at 8:35 AM, Marshall Eubanks wrote: > I really like this analysis. Some questions. > > 2012/4/9 Eric Rescorla : >> Hi folks, >> >> Since it seems like we're going to be having a large number of >> interims, I thought it might be instructive to try to analyze a bunch >> of different locations to figure out the best strategy. My first cut >> analysis is below. >> >> Note that I'm not trying to make any claims about what the best set of >> venues is. It's obviously easy to figure out any statistic we want >> about each proposed venue, but how you map that data to "best" is up >> to you. In particular, there's some tradeoff between minimal total >> travel time and a "fair" distribution of travel times (not that I >> claim to know what that means). >> >> >> METHODOLOGY >> The data below is derived by treating both people and venues as >> airport locations and using travel time as our primary instrument. >> >> 1. For each responder for the current Doodle poll, assign a home >> =A0 airport based on their draft publication history. =A0We're missing a >> =A0 few people but basically it should be pretty complete. Since >> =A0 these people responded before the venue is known, it's at >> =A0 least somewhat unbiased. >> >> 2. Compute the shortest advertised flight between each home airport >> =A0 and the locations for each venue by looking at the shortest >> =A0 advertised Kayak flights around one of the proposed interim >> =A0 dates (6/10 - 6/13), ignoring price, but excluding "Hacker fares". >> =A0 [Thanks to Martin Thomson or helping me gather these.] >> > > 1.) Why are some fields doubled ? I.e., > > ARN SFO 14 13 > > Are these counted twice ? That would, of course, give more weight to > those records. Laziness. When I started recording flight times, I used the total time and then later realized that what I wanted was to break them out by out and back, but I was too lazy to go back and fix the earlier ones. > 2.) At any rate, I couldn't quite match your numbers. For SFO, for > example, I got > > # SFO > > =A0Records =A0 =A0 =A0 =A0 =A0 =A029 =A0| > =A0Mean =A0 =A0 =A0 =A0 =A0 =A012.52 =A0| > =A0RMS =A0 =A0 =A0 =A0 =A0 =A0 15.34 =A0| > =A0Std Dev =A0 =A0 =A0 =A0 =A08.55 =A0| > =A0Minimum =A0 =A0 =A0 =A0 =A01.00 =A0| > =A0Maximum =A0 =A0 =A0 =A0 34.00 =A0| > > This assumes that each doubled entry counts as 2 separate entries. If > the second entries are ignored, I get I'm not sure what procedure you are following here, but if it's taking the SD of the data in durations.txt, that's not what I did. That's just the input data. The summary data that I am showing is produced by weighting by participant from each home airport. The script to generate that is pairings.py and the results are found in doodle-out.txt. Of course, it could still all be wrong. FWIW, I'm using R's sd() which uses n-1. -Ekr > # SFO > > =A0Records =A0 =A0 =A0 =A0 =A0 =A021 =A0| > =A0Mean =A0 =A0 =A0 =A0 =A0 =A014.05 =A0| > =A0RMS =A0 =A0 =A0 =A0 =A0 =A0 17.05 =A0| > =A0Std Dev =A0 =A0 =A0 =A0 =A09.14 =A0| > =A0Minimum =A0 =A0 =A0 =A0 =A01.00 =A0| > =A0Maximum =A0 =A0 =A0 =A0 34.00 =A0| > > If two entries are averaged together (when present) > > # SFO > =A0Records =A0 =A0 =A0 =A0 =A0 =A021 =A0| > =A0Mean =A0 =A0 =A0 =A0 =A0 =A013.93 =A0| > =A0RMS =A0 =A0 =A0 =A0 =A0 =A0 16.97 =A0| > =A0Std Dev =A0 =A0 =A0 =A0 =A09.18 =A0| > =A0Minimum =A0 =A0 =A0 =A0 =A01.00 =A0| > =A0Maximum =A0 =A0 =A0 =A0 34.00 =A0| > > None of these 3 options match your > > Venue =A0 =A0 =A0 =A0 Mean =A0 =A0 =A0 =A0 Median =A0 =A0 =A0 =A0 =A0 SD > ---------------------------------------------- > SFO =A0 =A0 =A0 =A0 =A0 13.5 =A0 =A0 =A0 =A0 =A0 =A0 11 =A0 =A0 =A0 =A0 1= 2.2 > > In particular, your SD value seems high. > > (Note, I use the SD =3D root mean square /(n-1) not / n convention, but > that won't explain the difference. ) > > Regards > Marshall > > >> This lets us compute statistics for any venue and/or combination >> of venues, based on the candidate attendee list. >> >> The three proposed venues: >> >> - San Francisco (SFO) >> - Boston (BOS) >> - Stockholm (ARN) >> >> Three hubs not too distant from the proposed venues: >> >> - London (LHR) >> - Frankfurt (FRA) >> - New York (NYC) [0] >> >> Also, Calgary (YYC), since the other two chair locations (BOS and SFO) >> were already proposed as venues, and I didn't want Cullen to feel >> left out. >> >> >> RESULTS >> Here are the results for each of the above venues, measured in total >> hours of travel (i.e., round trip). >> >> Venue =A0 =A0 =A0 =A0 Mean =A0 =A0 =A0 =A0 Median =A0 =A0 =A0 =A0 =A0 SD >> ---------------------------------------------- >> SFO =A0 =A0 =A0 =A0 =A0 13.5 =A0 =A0 =A0 =A0 =A0 =A0 11 =A0 =A0 =A0 =A0 = 12.2 >> BOS =A0 =A0 =A0 =A0 =A0 12.3 =A0 =A0 =A0 =A0 =A0 =A0 11 =A0 =A0 =A0 =A0 = =A07.5 >> ARN =A0 =A0 =A0 =A0 =A0 17.0 =A0 =A0 =A0 =A0 =A0 =A0 21 =A0 =A0 =A0 =A0 = 10.7 >> FRA =A0 =A0 =A0 =A0 =A0 14.8 =A0 =A0 =A0 =A0 =A0 =A0 17 =A0 =A0 =A0 =A0 = =A07.3 >> LHR =A0 =A0 =A0 =A0 =A0 13.3 =A0 =A0 =A0 =A0 =A0 =A0 14 =A0 =A0 =A0 =A0 = =A07.5 >> NYC =A0 =A0 =A0 =A0 =A0 11.5 =A0 =A0 =A0 =A0 =A0 =A0 11 =A0 =A0 =A0 =A0 = =A05.8 >> YYC =A0 =A0 =A0 =A0 =A0 14.9 =A0 =A0 =A0 =A0 =A0 =A0 13 =A0 =A0 =A0 =A0 = 10.2 >> SFO/BOS/ARN =A0 14.3 =A0 =A0 =A0 =A0 =A0 =A0 13 =A0 =A0 =A0 =A0 =A03.6 >> SFO/NYC/LHR =A0 12.7 =A0 =A0 =A0 =A0 =A0 =A0 11.3 =A0 =A0 =A0 =A03.7 >> >> XXX/YYY/ZZZ a three-way rotation of XXX, YYY, and ZZZ. Obviously, mean >> and median are intended to be some sort of aggregate measure of travel >> time. I don't have any way to measure "fairness", but SD is intended >> as some metric of the variation in travel time between attendees. >> >> The raw data and software are attached. The files are: >> >> =A0home-airports =A0 =A0 -- the list of people's home airports >> =A0durations.txt =A0 =A0 -- the list of airport-airport durations >> =A0doodle.txt =A0 =A0 =A0 =A0-- the attendees list >> =A0pairings.py =A0 =A0 =A0 -- the software to compute travel times >> =A0doodle-out.txt -- the computed travel times for each attendee >> >> Obviously, there could be an error in the raw data or the software. >> Please feel free to send corrections, especially if you find >> something material. >> >> >> OBSERVATIONS >> Obviously, it's hard to know what the optimal solution is without >> some model for optimality, but we can still make some observations >> based on this data: >> >> 1. If we're just concerned with minimizing total travel time, then we >> would always in New York, since it has both the shortest mean travel >> time and the shortest median travel time, but as I said above, this >> arguably isn't fair to people who live either in Europe or California, >> since they always have to travel. >> >> 2. Combining West Coast, East Coast, and European venues has >> comparable (or at least not too much worse) mean/median values than >> NYC with much lower SDs. So, arguably that kind of mix is more fair. >> >> 3. There's a pretty substantial difference between hub and non-hub >> venues. In particular, LHR has a median travel time 7 hours less than >> ARN, and the SFO/NYC/LHR combination has a median/mean travel time >> about 2 hours less than SFO/BOS/ARN (primarily accounted for by the >> LHR/ARN difference). [Full disclosure, I've favored Star Alliance hubs >> here, but you'd probably get similar results if, for instance, you >> used AMS instead of LHR.] >> >> >> Obviously, your mileage may vary based on your location and feelings >> about what's fair, but based on this data, it looks to me like a >> three-way rotation between West Coast, East Coast, and European hubs >> offers a good compromise between minimum cost and a flat distribution >> of travel times. >> >> Personally, whatever we decide to do I'd ask that the WG settle now on >> a pattern going forward so that we can predictably budget our travel >> time and dollars. >> >> >> [0] Treating all three NYC airports as a single location. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> From igor.faynberg@alcatel-lucent.com Mon Apr 9 16:55: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 595B521F87E3 for ; Mon, 9 Apr 2012 16:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.684 X-Spam-Level: X-Spam-Status: No, score=-7.684 tagged_above=-999 required=5 tests=[AWL=-1.086, 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 wdLykUGx0PIU for ; Mon, 9 Apr 2012 16:55:06 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 40E5921F87DB for ; Mon, 9 Apr 2012 16:55:05 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q39Nt3jP024936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Apr 2012 18:55:03 -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 q39Nt2YJ010665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Apr 2012 18:55:03 -0500 Received: from [135.244.0.96] (faynberg.lra.lucent.com [135.244.0.96]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q39Nt2fD017159; Mon, 9 Apr 2012 18:55:02 -0500 (CDT) Message-ID: <4F8376D5.5020905@alcatel-lucent.com> Date: Mon, 09 Apr 2012 19:55:01 -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: multipart/alternative; boundary="------------020703020000000006030103" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Data on travel times 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: Mon, 09 Apr 2012 23:55:07 -0000 This is a multi-part message in MIME format. --------------020703020000000006030103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This post is the first in the history of standards--for the past 200 or so years-- that I have been following where a scientific approach for a decision on the meeting venue has been planned and actually carried out. Bravo, Eric! Igor On 4/9/2012 9:57 AM, Eric Rescorla wrote: > Hi folks, > > Since it seems like we're going to be having a large number of > interims, I thought it might be instructive to try to analyze a bunch > of different locations to figure out the best strategy. My first cut > analysis is below. > > Note that I'm not trying to make any claims about what the best set of > venues is. It's obviously easy to figure out any statistic we want > about each proposed venue, but how you map that data to "best" is up > to you. In particular, there's some tradeoff between minimal total > travel time and a "fair" distribution of travel times (not that I > claim to know what that means). > > > METHODOLOGY > The data below is derived by treating both people and venues as > airport locations and using travel time as our primary instrument. > > 1. For each responder for the current Doodle poll, assign a home > airport based on their draft publication history. We're missing a > few people but basically it should be pretty complete. Since > these people responded before the venue is known, it's at > least somewhat unbiased. > > 2. Compute the shortest advertised flight between each home airport > and the locations for each venue by looking at the shortest > advertised Kayak flights around one of the proposed interim > dates (6/10 - 6/13), ignoring price, but excluding "Hacker fares". > [Thanks to Martin Thomson or helping me gather these.] > > This lets us compute statistics for any venue and/or combination > of venues, based on the candidate attendee list. > > The three proposed venues: > > - San Francisco (SFO) > - Boston (BOS) > - Stockholm (ARN) > > Three hubs not too distant from the proposed venues: > > - London (LHR) > - Frankfurt (FRA) > - New York (NYC) [0] > > Also, Calgary (YYC), since the other two chair locations (BOS and SFO) > were already proposed as venues, and I didn't want Cullen to feel > left out. > > > RESULTS > Here are the results for each of the above venues, measured in total > hours of travel (i.e., round trip). > > Venue Mean Median SD > ---------------------------------------------- > SFO 13.5 11 12.2 > BOS 12.3 11 7.5 > ARN 17.0 21 10.7 > FRA 14.8 17 7.3 > LHR 13.3 14 7.5 > NYC 11.5 11 5.8 > YYC 14.9 13 10.2 > SFO/BOS/ARN 14.3 13 3.6 > SFO/NYC/LHR 12.7 11.3 3.7 > > XXX/YYY/ZZZ a three-way rotation of XXX, YYY, and ZZZ. Obviously, mean > and median are intended to be some sort of aggregate measure of travel > time. I don't have any way to measure "fairness", but SD is intended > as some metric of the variation in travel time between attendees. > > The raw data and software are attached. The files are: > > home-airports -- the list of people's home airports > durations.txt -- the list of airport-airport durations > doodle.txt -- the attendees list > pairings.py -- the software to compute travel times > doodle-out.txt -- the computed travel times for each attendee > > Obviously, there could be an error in the raw data or the software. > Please feel free to send corrections, especially if you find > something material. > > > OBSERVATIONS > Obviously, it's hard to know what the optimal solution is without > some model for optimality, but we can still make some observations > based on this data: > > 1. If we're just concerned with minimizing total travel time, then we > would always in New York, since it has both the shortest mean travel > time and the shortest median travel time, but as I said above, this > arguably isn't fair to people who live either in Europe or California, > since they always have to travel. > > 2. Combining West Coast, East Coast, and European venues has > comparable (or at least not too much worse) mean/median values than > NYC with much lower SDs. So, arguably that kind of mix is more fair. > > 3. There's a pretty substantial difference between hub and non-hub > venues. In particular, LHR has a median travel time 7 hours less than > ARN, and the SFO/NYC/LHR combination has a median/mean travel time > about 2 hours less than SFO/BOS/ARN (primarily accounted for by the > LHR/ARN difference). [Full disclosure, I've favored Star Alliance hubs > here, but you'd probably get similar results if, for instance, you > used AMS instead of LHR.] > > > Obviously, your mileage may vary based on your location and feelings > about what's fair, but based on this data, it looks to me like a > three-way rotation between West Coast, East Coast, and European hubs > offers a good compromise between minimum cost and a flat distribution > of travel times. > > Personally, whatever we decide to do I'd ask that the WG settle now on > a pattern going forward so that we can predictably budget our travel > time and dollars. > > > [0] Treating all three NYC airports as a single location. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020703020000000006030103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This post is the first in the history of standards--for the past 200 or so years-- that I have been following where a scientific approach for a decision on the meeting venue has been planned and actually carried out.

Bravo, Eric!

Igor


On 4/9/2012 9:57 AM, Eric Rescorla wrote: 
Hi folks,

Since it seems like we're going to be having a large number of
interims, I thought it might be instructive to try to analyze a bunch
of different locations to figure out the best strategy. My first cut
analysis is below.

Note that I'm not trying to make any claims about what the best set of
venues is. It's obviously easy to figure out any statistic we want
about each proposed venue, but how you map that data to "best" is up
to you. In particular, there's some tradeoff between minimal total
travel time and a "fair" distribution of travel times (not that I
claim to know what that means).


METHODOLOGY
The data below is derived by treating both people and venues as
airport locations and using travel time as our primary instrument.

1. For each responder for the current Doodle poll, assign a home
   airport based on their draft publication history.  We're missing a
   few people but basically it should be pretty complete. Since
   these people responded before the venue is known, it's at
   least somewhat unbiased.

2. Compute the shortest advertised flight between each home airport
   and the locations for each venue by looking at the shortest
   advertised Kayak flights around one of the proposed interim
   dates (6/10 - 6/13), ignoring price, but excluding "Hacker fares".
   [Thanks to Martin Thomson or helping me gather these.]

This lets us compute statistics for any venue and/or combination
of venues, based on the candidate attendee list.

The three proposed venues:

- San Francisco (SFO)
- Boston (BOS)
- Stockholm (ARN)

Three hubs not too distant from the proposed venues:

- London (LHR)
- Frankfurt (FRA)
- New York (NYC) [0]

Also, Calgary (YYC), since the other two chair locations (BOS and SFO)
were already proposed as venues, and I didn't want Cullen to feel
left out.


RESULTS
Here are the results for each of the above venues, measured in total
hours of travel (i.e., round trip).

Venue         Mean         Median           SD
----------------------------------------------
SFO           13.5             11         12.2
BOS           12.3             11          7.5
ARN           17.0             21         10.7
FRA           14.8             17          7.3
LHR           13.3             14          7.5
NYC           11.5             11          5.8
YYC           14.9             13         10.2
SFO/BOS/ARN   14.3             13          3.6
SFO/NYC/LHR   12.7             11.3        3.7

XXX/YYY/ZZZ a three-way rotation of XXX, YYY, and ZZZ. Obviously, mean
and median are intended to be some sort of aggregate measure of travel
time. I don't have any way to measure "fairness", but SD is intended
as some metric of the variation in travel time between attendees.

The raw data and software are attached. The files are:

  home-airports     -- the list of people's home airports
  durations.txt     -- the list of airport-airport durations
  doodle.txt        -- the attendees list
  pairings.py       -- the software to compute travel times
  doodle-out.txt -- the computed travel times for each attendee

Obviously, there could be an error in the raw data or the software.
Please feel free to send corrections, especially if you find
something material.


OBSERVATIONS
Obviously, it's hard to know what the optimal solution is without
some model for optimality, but we can still make some observations
based on this data:

1. If we're just concerned with minimizing total travel time, then we
would always in New York, since it has both the shortest mean travel
time and the shortest median travel time, but as I said above, this
arguably isn't fair to people who live either in Europe or California,
since they always have to travel.

2. Combining West Coast, East Coast, and European venues has
comparable (or at least not too much worse) mean/median values than
NYC with much lower SDs. So, arguably that kind of mix is more fair.

3. There's a pretty substantial difference between hub and non-hub
venues. In particular, LHR has a median travel time 7 hours less than
ARN, and the SFO/NYC/LHR combination has a median/mean travel time
about 2 hours less than SFO/BOS/ARN (primarily accounted for by the
LHR/ARN difference). [Full disclosure, I've favored Star Alliance hubs
here, but you'd probably get similar results if, for instance, you
used AMS instead of LHR.]


Obviously, your mileage may vary based on your location and feelings
about what's fair, but based on this data, it looks to me like a
three-way rotation between West Coast, East Coast, and European hubs
offers a good compromise between minimum cost and a flat distribution
of travel times.

Personally, whatever we decide to do I'd ask that the WG settle now on
a pattern going forward so that we can predictably budget our travel
time and dollars.


[0] Treating all three NYC airports as a single location.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--------------020703020000000006030103-- From magnus.westerlund@ericsson.com Tue Apr 10 01:18: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 5537B21F8782 for ; Tue, 10 Apr 2012 01:18:35 -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 7vcU651wiX17 for ; Tue, 10 Apr 2012 01:18:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4021F87AD for ; Tue, 10 Apr 2012 01:18:31 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-8f-4f83ecd6fefc Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E8.F8.03534.6DCE38F4; Tue, 10 Apr 2012 10:18:31 +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.213.0; Tue, 10 Apr 2012 10:18:30 +0200 Message-ID: <4F83ECD5.1060405@ericsson.com> Date: Tue, 10 Apr 2012 10:18:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Roman Shpount References: <4F7415D5.80604@ericsson.com> <0E6A0E0D-BFDD-4974-87BE-B0DCD1ECE9D5@acmepacket.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 08:18:35 -0000 On 2012-04-02 18:09, Roman Shpount wrote: > > On Mon, Apr 2, 2012 at 9:02 AM, Hadriel Kaplan > wrote: > > > Hi, > I was thinking the tricky part is more about the local transport > stuff getting cloned - i.e., imagine if you're using a TCP-based > TURN connection. > But maybe it's a non-issue. > > > This really depends on how the TURN support is implemented, but > typically using the same TCP connection or any other TURN allocation for > multiple PC should be no more of an issue then using same connection for > multiple streams within the PC. Actually TURN forces one to setup at least new permissions for each peer that you want to accept flows from. Thus, even cloning an existing local state will require additional actions for any TURN candidates. I haven't looked into the detail for TURN TCP. 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 magnus.westerlund@ericsson.com Tue Apr 10 02:44: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 747BC21F878E for ; Tue, 10 Apr 2012 02:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 rbaEWjPhS-w9 for ; Tue, 10 Apr 2012 02:44:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADAE11E8076 for ; Tue, 10 Apr 2012 02:44:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-e4-4f8400ef0f14 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 82.D3.25560.FE0048F4; Tue, 10 Apr 2012 11:44:15 +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.213.0; Tue, 10 Apr 2012 11:44:14 +0200 Message-ID: <4F8400E8.6010102@ericsson.com> Date: Tue, 10 Apr 2012 11:44:08 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Roman Shpount References: <4F4759DC.7060303@ericsson.com> <4F6AECC6.8020004@alvestrand.no> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> <4F6CC346.9000703@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris 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 Apr 2012 09:44:23 -0000 On 2012-03-29 08:20, Roman Shpount wrote: > > On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand > wrote: > > __ > It seems to me that you are arguing that the scenarios in section > 4.1 of the use cases document do not cover that specific case, and I > think you are right in that; the list is: > > The following considerations are applicable to all use cases: > o Clients can be on IPv4-only > o Clients can be on IPv6-only > o Clients can be on dual-stack > o Clients can be on wideband (10s of Mbits/sec) > o Clients can be on narrowband (10s to 100s of Kbits/sec) > o Clients can be on variable-media-quality networks (wireless) > o Clients can be on congested networks > o Clients can be on firewalled networks with no UDP allowed > o Clients can be on networks with cone NAT > o Clients can be on networks with symmetric NAT > > Now, there are two ways to interpret this omission: > > - The WG did not think of that use case when the list was created > - The WG does not want that use case on the list because it > constrains the solution space too much > > If (re)opening this issue, I think I'd find myself in the "do not > want that use case" camp. > > > I do not recall this use case ever being discussed on the working group, > so I would assume the current situation is due to WG not thinking about > this case when the list was created. Hi, If I followed this thread I do believe that we do have a use case description that puts in requirements for controlling how the media traffic flows in and out of an enterprise when using WebRTC: 4.2.4. Simple Video Communication Service, enterprise aspects 4.2.4.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 4.2.1). What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application session used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddle the boundary between the internal network and the external. The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want to have the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possibele to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by autoconfiguration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. My interpretation of this and the discussion I can remember is that an enterprise would configure the browsers for their internal computers with a TURN server sitting on the border between the inside and outside. That way one can at least log and audit which communication that occurs using WebRTC from the inside to the outside. The enterprise can also select to record media flows in the TURN server. This still leaves the question if one can get to the keys. That will depend on the mechanism used for keying and its transport and what methods have been put in place to capture such traffic. 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 roman@telurix.com Tue Apr 10 11:22: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 B656B11E80D9 for ; Tue, 10 Apr 2012 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 CFdxQfjntbQH for ; Tue, 10 Apr 2012 11:22:28 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17411E80B8 for ; Tue, 10 Apr 2012 11:22:26 -0700 (PDT) Received: by dady13 with SMTP id y13so135128dad.27 for ; Tue, 10 Apr 2012 11:22:26 -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=EfGh/r/3HutQEvM8F6XYn85E9GKY4W6IwI7mp/FdHao=; b=ML0zlrDTxXQ7l8RKWUWHr+CLP7YOyCPOxiCgDJvGo1Yq0OM4+B/chs6JFaS/SILbF2 UNhqHJWNFzf+uBytsfNKmCsv+/KXA8J7GSpFKGPjRLVyl8OTyaa/RbBzlk2+AFRkOrEk nAb1xc9p9MlfinREq3J0Ea2K9LYAsa6Xza6JzinGWQnW55Ih4e1WuS5uhj7gY/vwORpu VpJDA3RBfV0M6EZCNwUiG46/UtVAyY6h298hrbYJWrm3vnczBT3x/ayBJlQhVMOi3pxQ J8PneGFtCHMoQYRWKZ7Eq9broHGaVhrrpcye++RN2niqG/AQZyS/OT9bTq2lsNHdWEpD E6Uw== Received: by 10.68.216.167 with SMTP id or7mr9522753pbc.140.1334082145986; Tue, 10 Apr 2012 11:22:25 -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 or6sm501365pbc.43.2012.04.10.11.22.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 11:22:23 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so270602pbb.31 for ; Tue, 10 Apr 2012 11:22:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.35 with SMTP id gv3mr30773925pbc.57.1334082142343; Tue, 10 Apr 2012 11:22:22 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 10 Apr 2012 11:22:22 -0700 (PDT) In-Reply-To: <4F8400E8.6010102@ericsson.com> References: <4F4759DC.7060303@ericsson.com> <4F6AECC6.8020004@alvestrand.no> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> <4F6CC346.9000703@alvestrand.no> <4F8400E8.6010102@ericsson.com> Date: Tue, 10 Apr 2012 14:22:22 -0400 Message-ID: From: Roman Shpount To: Magnus Westerlund Content-Type: multipart/alternative; boundary=e89a8ff1c34032140a04bd57340e X-Gm-Message-State: ALoCoQnHXQ/ljLa3ARa6swSmO+unTkbWHFPbS3pRIEEnMJsDf4Q5NQ5iTsIN6e6iukO3Qh30j92U Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris 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 Apr 2012 18:22:30 -0000 --e89a8ff1c34032140a04bd57340e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 5:44 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2012-03-29 08:20, Roman Shpount wrote: > > > > On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand > > wrote: > > > > __ > > It seems to me that you are arguing that the scenarios in section > > 4.1 of the use cases document do not cover that specific case, and I > > think you are right in that; the list is: > > > > The following considerations are applicable to all use cases: > > o Clients can be on IPv4-only > > o Clients can be on IPv6-only > > o Clients can be on dual-stack > > o Clients can be on wideband (10s of Mbits/sec) > > o Clients can be on narrowband (10s to 100s of Kbits/sec) > > o Clients can be on variable-media-quality networks (wireless) > > o Clients can be on congested networks > > o Clients can be on firewalled networks with no UDP allowed > > o Clients can be on networks with cone NAT > > o Clients can be on networks with symmetric NAT > > > > Now, there are two ways to interpret this omission: > > > > - The WG did not think of that use case when the list was created > > - The WG does not want that use case on the list because it > > constrains the solution space too much > > > > If (re)opening this issue, I think I'd find myself in the "do not > > want that use case" camp. > > > > > > I do not recall this use case ever being discussed on the working group, > > so I would assume the current situation is due to WG not thinking about > > this case when the list was created. > > Hi, > > If I followed this thread I do believe that we do have a use case > description that puts in requirements for controlling how the media > traffic flows in and out of an enterprise when using WebRTC: > > 4.2.4. Simple Video Communication Service, enterprise aspects > > 4.2.4.1. Description > > This use-case is similar to the Simple Video Communication Service > use-case (Section 4.2.1). > > What is added is aspects when using the service in enterprises. ICE > is assumed in the further description of this use-case. > > An enterprise that uses a RTCWEB based web application for > communication desires to audit all RTCWEB based application session > used from inside the company towards any external peer. To be able > to do this they deploy a TURN server that straddle the boundary > between the internal network and the external. > > The firewall will block all attempts to use STUN with an external > destination unless they go to the enterprise auditing TURN server. > In cases where employees are using RTCWEB applications provided by an > external service provider they still want to have the traffic to stay > inside their internal network and in addition not load the straddling > TURN server, thus they deploy a STUN server allowing the RTCWEB > client to determine its server reflexive address on the internal > side. Thus enabling cases where peers are both on the internal side > to connect without the traffic leaving the internal network. It must > be possibele to configure the browsers used in the enterprise with > network specific STUN and TURN servers. This should be possible to > achieve by autoconfiguration methods. The RTCWEB functionality will > need to utilize both network specific STUN and TURN resources and > STUN and TURN servers provisioned by the web application. > > My interpretation of this and the discussion I can remember is that an > enterprise would configure the browsers for their internal computers > with a TURN server sitting on the border between the inside and outside. > That way one can at least log and audit which communication that occurs > using WebRTC from the inside to the outside. The enterprise can also > select to record media flows in the TURN server. > > This still leaves the question if one can get to the keys. That will > depend on the mechanism used for keying and its transport and what > methods have been put in place to capture such traffic. I thought about customer provided TURN servers and I do not think they will be sufficient, due to the fact that no information describing the media (URL of the application that initiated this media call, codec,any codec related parameters, keys). I think some sort of network based hook that will allow browser to send all the signaling information to some sort of WebRTC signaling proxy server would be required to enable any type of managed corporate use. Since we gave up the standard signaling protocol we gave up a lot of functionality enterprise customers expect from real time communications. In case of SIP enterprise can deploy some sort of proxy server and enforce any type of enterprise specific policy. The only way to fill this gap is to provide an ability to modify signaling coming from and being sent via WebRTC API in a manner independent of the application code, by configuring a policy enforcement server in web browser. The protocol used to communicate with the policy enforcement server can be something as simple as HTTP post with SDP data with response being policy server modified SDP. Any additional requirements such as authentication and encryption of communications between WebRTC client and WebRTC policy server will be provided via standard HTTP means (HTTPS, and Digest authentication). _____________ Roman Shpount --e89a8ff1c34032140a04bd57340e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 10, 2012 at 5:44 A= M, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On 2012-03-29 08:20, Roman Shpount wrote:
>
> On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand <harald@alvestrand.no
> <mailto:harald@alvest= rand.no>> wrote:
>
> =A0 =A0 __
> =A0 =A0 It seems to me that you are = arguing that the scenarios in section
> =A0 =A0 4.1 of the use cases document do not cover that specific case,= and I
> =A0 =A0 think you are right in that; the list is:
>
> =A0 =A0 =A0 =A0The following considerations are applicable to all use = cases:
> =A0 =A0 =A0 =A0o =A0Clients can be on IPv4-only
> =A0 =A0 =A0 =A0o =A0Clients can be on IPv6-only
> =A0 =A0 =A0 =A0o =A0Clients can be on dual-stack
> =A0 =A0 =A0 =A0o =A0Clients can be on wideband (10s of Mbits/sec)
> =A0 =A0 =A0 =A0o =A0Clients can be on narrowband (10s to 100s of Kbits= /sec)
> =A0 =A0 =A0 =A0o =A0Clients can be on variable-media-quality networks = (wireless)
> =A0 =A0 =A0 =A0o =A0Clients can be on congested networks
> =A0 =A0 =A0 =A0o =A0Clients can be on firewalled networks with no UDP = allowed
> =A0 =A0 =A0 =A0o =A0Clients can be on networks with cone NAT
> =A0 =A0 =A0 =A0o =A0Clients can be on networks with symmetric NAT
>
> =A0 =A0 Now, there are two ways to interpret this omission:
>
> =A0 =A0 - The WG did not think of that use case when the list was crea= ted
> =A0 =A0 - The WG does not want that use case on the list because it > =A0 =A0 constrains the solution space too much
>
> =A0 =A0 If (re)opening this issue, I think I'd find myself in the = "do not
> =A0 =A0 want that use case" camp.
>
>
> I do not recall this use case ever being discussed on the working grou= p,
> so I would assume the current situation is due to WG not thinking abou= t
> this case when the list was created.

Hi,

If I followed this thread I do believe that we do have a use case
description that puts in requirements for controlling how the media
traffic flows in and out of an enterprise when using WebRTC:

4.2.4. =A0Simple Video Communication Service, enterprise aspects

4.2.4.1. =A0Description

=A0 This use-case is similar to the Simple Video Communication Service
=A0 use-case (Section 4.2.1).

=A0 What is added is aspects when using the service in enterprises. =A0ICE=
=A0 is assumed in the further description of this use-case.

=A0 An enterprise that uses a RTCWEB based web application for
=A0 communication desires to audit all RTCWEB based application session =A0 used from inside the company towards any external peer. =A0To be able<= br> =A0 to do this they deploy a TURN server that straddle the boundary
=A0 between the internal network and the external.

=A0 The firewall will block all attempts to use STUN with an external
=A0 destination unless they go to the enterprise auditing TURN server.
=A0 In cases where employees are using RTCWEB applications provided by an<= br> =A0 external service provider they still want to have the traffic to stay<= br> =A0 inside their internal network and in addition not load the straddling<= br> =A0 TURN server, thus they deploy a STUN server allowing the RTCWEB
=A0 client to determine its server reflexive address on the internal
=A0 side. =A0Thus enabling cases where peers are both on the internal side=
=A0 to connect without the traffic leaving the internal network. =A0It mus= t
=A0 be possibele to configure the browsers used in the enterprise with
=A0 network specific STUN and TURN servers. =A0This should be possible to<= br> =A0 achieve by autoconfiguration methods. =A0The RTCWEB functionality will=
=A0 need to utilize both network specific STUN and TURN resources and
=A0 STUN and TURN servers provisioned by the web application.

My interpretation of this and the discussion I can remember is that an
enterprise would configure the browsers for their internal computers
with a TURN server sitting on the border between the inside and outside. That way one can at least log and audit which communication that occurs
using WebRTC from the inside to the outside. The enterprise can also
select to record media flows in the TURN server.

This still leaves the question if one can get to the keys. That will
depend on the mechanism used for keying and its transport and what
methods have been put in place to capture such traffic.
I thought about customer provided TURN servers and I do not think they wi= ll be sufficient, due to the fact that no information describing the media = (URL of the application that initiated this media call, codec,any codec rel= ated parameters, keys). I think some sort of network based hook that will a= llow browser to send all the signaling information to some sort of WebRTC s= ignaling proxy server would be required to enable any type of managed corpo= rate use. Since we gave up the standard signaling protocol we gave up a lot= of functionality enterprise customers expect from real time communications= . In case of SIP enterprise can deploy some sort of proxy server and enforc= e any type of enterprise specific policy. The only way to fill this gap is = to provide an ability to modify signaling coming from and being sent via We= bRTC API in a manner independent of the application code, by configuring a = policy enforcement server in web browser. The protocol used to communicate = with the policy enforcement server can be something as simple as HTTP post = with SDP data with response being policy server modified SDP.=A0 Any additi= onal requirements such as authentication and encryption of communications b= etween WebRTC client and WebRTC policy server will be provided via standard= HTTP means (HTTPS, and Digest authentication).
_____________
Roman Shpount

--e89a8ff1c34032140a04bd57340e-- From harald@alvestrand.no Tue Apr 10 11:39: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 4FCEF11E812E for ; Tue, 10 Apr 2012 11:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.06 X-Spam-Level: X-Spam-Status: No, score=-110.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 ap8zSElIejzx for ; Tue, 10 Apr 2012 11:39:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 64D9411E80B8 for ; Tue, 10 Apr 2012 11:39:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CA3239E20A; Tue, 10 Apr 2012 20:39:35 +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 136X5Y7J568T; Tue, 10 Apr 2012 20:39:35 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 188BE39E17B; Tue, 10 Apr 2012 20:39:35 +0200 (CEST) Message-ID: <4F847E66.4080702@alvestrand.no> Date: Tue, 10 Apr 2012 20:39:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Roman Shpount References: <4F4759DC.7060303@ericsson.com> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> <4F6CC346.9000703@alvestrand.no> <4F8400E8.6010102@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris 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 Apr 2012 18:39:40 -0000 On 04/10/2012 08:22 PM, Roman Shpount wrote: > I thought about customer provided TURN servers and I do not think they > will be sufficient, due to the fact that no information describing the > media (URL of the application that initiated this media call, > codec,any codec related parameters, keys). I think some sort of > network based hook that will allow browser to send all the signaling > information to some sort of WebRTC signaling proxy server would be > required to enable any type of managed corporate use. Since we gave up > the standard signaling protocol we gave up a lot of functionality > enterprise customers expect from real time communications. In case of > SIP enterprise can deploy some sort of proxy server and enforce any > type of enterprise specific policy. The only way to fill this gap is > to provide an ability to modify signaling coming from and being sent > via WebRTC API in a manner independent of the application code, by > configuring a policy enforcement server in web browser. The protocol > used to communicate with the policy enforcement server can be > something as simple as HTTP post with SDP data with response being > policy server modified SDP. Any additional requirements such as > authentication and encryption of communications between WebRTC client > and WebRTC policy server will be provided via standard HTTP means > (HTTPS, and Digest authentication). This requires the code that sends the SDP to the policy server to be part of the browser, since you obviously can't trust the Javascript to do the call-out to the server. (If you could trust the Javascript, you could also trust it to enforce policy.) In that case, why don't you just require that the browser do the wiretapping for you by copying the media? Much simpler, and you don't have to worry about interpreting the SIP. Harald From dean.willis@softarmor.com Tue Apr 10 11:50: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 3D4F511E8133 for ; Tue, 10 Apr 2012 11:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, 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 M50BvbVzYgxV for ; Tue, 10 Apr 2012 11:50:43 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8829711E80B8 for ; Tue, 10 Apr 2012 11:50:42 -0700 (PDT) Received: by ggmi1 with SMTP id i1so98814ggm.31 for ; Tue, 10 Apr 2012 11:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/5UG2fyz/dwUrwK7tpdg9s8PWCnDs1JPSBPUmletLXA=; b=SB5p4Pngzw1HXjBXTh0fE7ouQ6dVCg95+Ea0M7KwZwpRL8A5uezzjk9tJtb5tPhX6+ /IS5LuvKMHhxOUXOFKhTptiNM4KD8YV7/etblwNOFYJkNdtP74QM8DrMbnKd3HxugTbv ByorW4BQP76tvFEboMMK/AiKyzbNArHmit1hA= 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=/5UG2fyz/dwUrwK7tpdg9s8PWCnDs1JPSBPUmletLXA=; b=koOJGJ4suByHDQGUOjXadXUI6ekZF1OWbfBCv2U7G+N4SEoV7+LmpuikRld9doYVZf 0em6HW6zOWQyEajsDAxm9UQVHCUY0ZCccqPR2Snp8KLrxpswpF60n8FsYYd7FmRtvjOm S0c0KjVq3l3ZguwQ2u7vhIrfYQr3BgxVzu5DZF4toDIziWfEnwdZrExIpHSMMWIbbYct zfza+grU1PzX2wZFhTv0J1y0vkLXbA0bpcd8Isd3736IX/19u7BYJ/PE7ZMyeKMtFeRf Fx0XU126g02r4VJAyIuSmrQKX1cDvNAx4qhJm8I0E4BrGTFqXU84jCCE7C5IzHGv8gMt M9QA== MIME-Version: 1.0 Received: by 10.60.12.162 with SMTP id z2mr17350039oeb.47.1334083841970; Tue, 10 Apr 2012 11:50:41 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Tue, 10 Apr 2012 11:50:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 13:50:41 -0500 Message-ID: From: Dean Willis To: Serge Lachapelle Content-Type: multipart/alternative; boundary=e89a8f83a03b80513b04bd57995b X-Gm-Message-State: ALoCoQnKahhDP+OafAnVkBMfEtudi0fZg+cXAoZ52BcydIz+H6AzJY/b/aJrVT5t+W2/D6lcFuic Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Tue, 10 Apr 2012 18:50:44 -0000 --e89a8f83a03b80513b04bd57995b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 3, 2012 at 12:54 PM, Serge Lachapelle wrote: > > Google confirms that the VP8 patent grant applies to both third-party > hardware and software implementations of VP8. > * > * > > That's very nice of Google, but I'm personally not worried about Google filing suit against me (as a small developer) if I implement using VP8. What I'm worried about is either a troll who has acquired a patent through the usual fire-sale process, or a Big Old Research Lab that has a gazillion patents but no revenue and decides to start monetizing patents its management team had forgotten existed. Both sorts of entities are very active in today's world of patent fights. And there are patents on design patterns going way back; we're approaching a world of "solid invention" where every alternative design for anything we know how to do has already been described in a patent filing. So if you really want me to be comfortable with implementing using VP8, buy me an insurance policy that will indemnify me (and any other developer) for any costs related to defending against any future infringement claims on VP8. Perhaps I'd even settle for a free software stack that includes such indemnification in its license. This wouldn't help the hardware implementer, much, however. -- Dean --e89a8f83a03b80513b04bd57995b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 3, 2012 at 12:54 PM, Serge L= achapelle <sergel= @google.com> wrote:

Google confirms that the VP8 patent g= rant applies to both third-party hardware and software implementations of V= P8.=A0



That's very nice o= f Google, but I'm personally not worried about Google filing suit again= st me (as a small developer) if I implement using VP8.=A0

What I'm worried about is either a troll who has acquired a patent= through the usual fire-sale process, or a Big Old Research Lab that has a = gazillion patents but no revenue and decides to start monetizing patents it= s management team had forgotten existed. Both sorts of entities are very ac= tive in today's world of patent fights. And there are patents on design= patterns going way back; we're approaching a world of "solid inve= ntion" where every alternative design for anything we know how to do h= as already been described in a patent filing.

So if you really want me to be comfortable with impleme= nting using VP8, buy me an insurance policy that will indemnify me (and any= other developer) for any costs related to defending against any future inf= ringement claims on VP8. Perhaps I'd even settle for a free software st= ack that includes such indemnification in its license. This wouldn't he= lp the hardware implementer, much, however.

--
Dean
--e89a8f83a03b80513b04bd57995b-- From roman@telurix.com Tue Apr 10 11:56: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 A663F11E80F2 for ; Tue, 10 Apr 2012 11:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=0.198, 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 sd95P9GNy4kf for ; Tue, 10 Apr 2012 11:56:19 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2920C11E80B8 for ; Tue, 10 Apr 2012 11:56:19 -0700 (PDT) Received: by dady13 with SMTP id y13so184155dad.27 for ; Tue, 10 Apr 2012 11:56:19 -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=C/Td7bU1LASQaxXoseE6S5iE5l5NFQZNmzmm8157ta4=; b=VC7577tkFFK3mWeH3SM+fUxeidSXR+lFsroLTliPIUQi/DYrFt2zWdXzPtQFZK3aEF j9FCelC2lGMThTpSR+w0Ak7cePTupW9UU1R5/FjQ2MdRdCAC894pLPKd549zxbWFXGjm Pv9Ol8G1fqJtlvfXAttmdISzfnDAdkF2AIXH/AyMIPcraikPs6vpFQg2VJWbq58kDUz6 re/3CmEU3TbPD8K4nRg8erhYuq+HXf8jo6PbbhH5cMwfgXr5na6vewRWlQvQr49MBQEV FY1gUtGT9/2J+AhcWd5HIUGRBkNAJhDRmM438OpL+iewj1AhwjJgbMBydbIj/mFg7xi+ VtgQ== Received: by 10.68.238.42 with SMTP id vh10mr15907315pbc.70.1334084178843; Tue, 10 Apr 2012 11:56:18 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id f8sm569202pbe.42.2012.04.10.11.56.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 11:56:17 -0700 (PDT) Received: by dady13 with SMTP id y13so184112dad.27 for ; Tue, 10 Apr 2012 11:56:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.198 with SMTP id uw6mr10122046pbc.99.1334084176762; Tue, 10 Apr 2012 11:56:16 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 10 Apr 2012 11:56:16 -0700 (PDT) In-Reply-To: <4F83ECD5.1060405@ericsson.com> References: <4F7415D5.80604@ericsson.com> <0E6A0E0D-BFDD-4974-87BE-B0DCD1ECE9D5@acmepacket.com> <4F83ECD5.1060405@ericsson.com> Date: Tue, 10 Apr 2012 14:56:16 -0400 Message-ID: From: Roman Shpount To: Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7b33d7c474d54704bd57adce X-Gm-Message-State: ALoCoQkPkQ/Efqn3oq6iwKcY7VgShV0oOIJN13fN6qxL3up7Wxq9WJCPGdM7wM4RAWwnGJDtLDUY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding cloning of PeerConnections when multiple answers are received 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 Apr 2012 18:56:19 -0000 --047d7b33d7c474d54704bd57adce Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 4:18 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Actually TURN forces one to setup at least new permissions for each peer > that you want to accept flows from. Thus, even cloning an existing local > state will require additional actions for any TURN candidates. I haven't > looked into the detail for TURN TCP. > > You are correct, when a new remote peer is added to a given allocation TURN allocation, a new permission needs to be added if remote peer address is different (permission is per address), new channel needs to be created(optional but highly recommended for RTP), and ICE exchange should be completed to confirm the connectivity. This procedure is the same for adding new remote peer due to normal session re-negotiation (you can send an offer with the same SDP on existing connetion and get a new response with different peers back), reusing TURN allocation in case of bundle, or in case we discuss -- forking. I would expect that a functional WebRTC implementation must be able to reuse the same TURN allocation for multiple connections within the same call. I do not think that adding support for this to enable reuse of the same allocation across multiple calls would complicate things too much. _____________ Roman Shpount --047d7b33d7c474d54704bd57adce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 10, 2012 at 4:18 A= M, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Actually TURN forces one to setup at least new permissions for each peer that you want to accept flows from. Thus, even cloning an existing local state will require additional actions for any TURN candidates. I haven'= t
looked into the detail for TURN TCP.


You are correct, when a new= remote peer is added to a given allocation TURN allocation, a new permissi= on needs to be added if remote peer address is different (permission is per= address), new channel needs to be created(optional but highly recommended = for RTP), and ICE exchange should be completed to confirm the connectivity.= This procedure is the same for adding new remote peer due to normal sessio= n re-negotiation (you can send an offer with the same SDP on existing conne= tion and get a new response with different peers back), reusing TURN alloca= tion in case of bundle, or in case we discuss -- forking. I would expect th= at a functional WebRTC implementation must be able to reuse the same TURN a= llocation for multiple connections within the same call. I do not think tha= t adding support for this to enable reuse of the same allocation across mul= tiple calls would complicate things too much.
_____________
Roman Shpount
--047d7b33d7c474d54704bd57adce-- From roman@telurix.com Tue Apr 10 12:06: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 EC6E211E80F4 for ; Tue, 10 Apr 2012 12:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.187, 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 ID1WcuDq9WPq for ; Tue, 10 Apr 2012 12:06:39 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 508D411E80DF for ; Tue, 10 Apr 2012 12:06:39 -0700 (PDT) Received: by dady13 with SMTP id y13so198968dad.27 for ; Tue, 10 Apr 2012 12:06:39 -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=6QIh7BC5Bx72JPdxBurUPh3uNmivwIGy34HPvq+m2EU=; b=L+V9IPeYy6Uc8PTM6GiX0PaaYMf+5cgim56qdI+QuGIVlZ8ASo0f6C+rEidkZnTfLx KJLHHWELUkMdRdo4sj/ADgSwcAXwxB3/V2D2UmG6B51h/KPO/2Vdy29flNUOLlsyukCQ KALdFPH7pDuLy3cuFfPt/BtfWzGI1HTzQ56KkHTI06F+KWPfPEKTMw87uLFQ5FsOk3G+ AbB5ZwNKoxe2v1w15BSokN2LxIuU4qLas9QK2TkNgGENTAPkkFdb7xKgnlEZI21H2jj9 pfDN429e/MPCmOtzZ29yXFlDTeMvRHizgN39Z/9uE/d3wK5iO5eaa7yFrlXZaO2vTafk t1RQ== Received: by 10.68.218.33 with SMTP id pd1mr16005630pbc.96.1334084799128; Tue, 10 Apr 2012 12:06:39 -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 ms1sm592601pbb.38.2012.04.10.12.06.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 12:06:38 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so311231pbb.31 for ; Tue, 10 Apr 2012 12:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.169 with SMTP id kz9mr11335018pbc.78.1334084797230; Tue, 10 Apr 2012 12:06:37 -0700 (PDT) Received: by 10.68.6.67 with HTTP; Tue, 10 Apr 2012 12:06:37 -0700 (PDT) In-Reply-To: <4F847E66.4080702@alvestrand.no> References: <4F4759DC.7060303@ericsson.com> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> <4F6CC346.9000703@alvestrand.no> <4F8400E8.6010102@ericsson.com> <4F847E66.4080702@alvestrand.no> Date: Tue, 10 Apr 2012 15:06:37 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=e89a8ffbae9f706d5304bd57d218 X-Gm-Message-State: ALoCoQn4rf5eSgK49upAI5SthgLLcnulCIU9zgqg1PM2brYRiewbyzxEZ4xfjVfhjm+qQOwGwBDL Cc: "" Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris 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 Apr 2012 19:06:40 -0000 --e89a8ffbae9f706d5304bd57d218 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 2:39 PM, Harald Alvestrand wrote: > > This requires the code that sends the SDP to the policy server to be part > of the browser, since you obviously can't trust the Javascript to do the > call-out to the server. (If you could trust the Javascript, you could also > trust it to enforce policy.) > > In that case, why don't you just require that the browser do the > wiretapping for you by copying the media? Much simpler, and you don't have > to worry about interpreting the SIP. > I do think this should be part of the browser, but I am not sure why you insist on limiting this to wiretapping. Wiretapping is just one of the use cases. Other use cases can be supported are things like: 1. Allocate only certain amount of bandwidth to WebRTC, disallow WebRTC calls when bandwidth is exausted 2. Disable video calling from my network. Voice calling would still be non-monitored encrypted and allowed 3. Force certain codec preference from my network (disable anything above 16KB/s) 4. Allow WebRTC communications outside of my network only when SDP descriptions are signed by certain white listed companies. There is a reason why proxy servers, both SIP and HTTP, exist. What I am trying to explain is that in a lot of environments user network experience is managed. This management requires tools. WebRTC, due to its consumer oriented user rights focus and prioritization of security, provides none, which, I believe, will create a barrier to its deployment in enterprise environments. _____________ Roman Shpount --e89a8ffbae9f706d5304bd57d218 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 10, 2012 at 2:39 P= M, Harald Alvestrand <harald@alvestrand.no> wrote:

This requires the code that sends the SDP to the policy server to be part o= f the browser, since you obviously can't trust the Javascript to do the= call-out to the server. (If you could trust the Javascript, you could also= trust it to enforce policy.)

In that case, why don't you just require that the browser do the wireta= pping for you by copying the media? Much simpler, and you don't have to= worry about interpreting the SIP.

I do think this should be part of the browser, but I am not sure = why you insist on limiting this to wiretapping. Wiretapping is just one of = the use cases. Other use cases can be supported are things like:

1. Allocate only certain amount of bandwidth to WebRTC, disallow WebRTC cal= ls when bandwidth is exausted
2. Disable video calling from my network. = Voice calling would still be non-monitored encrypted and allowed
3. Forc= e certain codec preference from my network (disable anything above 16KB/s)<= br> 4. Allow WebRTC communications outside of my network only when SDP descript= ions are signed by certain white listed companies.

There is a reason= why proxy servers, both SIP and HTTP, exist. What I am trying to explain i= s that in a lot of environments user network experience is managed. This ma= nagement requires tools. WebRTC, due to its consumer oriented user rights f= ocus and prioritization of security, provides none, which, I believe, will = create a barrier to its deployment in enterprise environments.

_____________
Roman Shpount

--e89a8ffbae9f706d5304bd57d218-- From randell-ietf@jesup.org Tue Apr 10 12:32: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 A804911E810A for ; Tue, 10 Apr 2012 12:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, 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 JC8Q9QxX3mgJ for ; Tue, 10 Apr 2012 12:32:44 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2126311E8100 for ; Tue, 10 Apr 2012 12:32:43 -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 1SHgnz-00084H-4g for rtcweb@ietf.org; Tue, 10 Apr 2012 14:32:43 -0500 Message-ID: <4F8489FA.10102@jesup.org> Date: Tue, 10 Apr 2012 15:28:58 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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 VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Tue, 10 Apr 2012 19:32:44 -0000 On 4/10/2012 2:50 PM, Dean Willis wrote: > > On Tue, Apr 3, 2012 at 12:54 PM, Serge Lachapelle > wrote: > > > Google confirms that the VP8 patent grant applies to both > third-party hardware and software implementations of VP8. > * > * > > > That's very nice of Google, but I'm personally not worried about > Google filing suit against me (as a small developer) if I implement > using VP8. > > What I'm worried about is either a troll who has acquired a patent > through the usual fire-sale process, or a Big Old Research Lab that > has a gazillion patents but no revenue and decides to start monetizing > patents its management team had forgotten existed. Both sorts of > entities are very active in today's world of patent fights. And there > are patents on design patterns going way back; we're approaching a > world of "solid invention" where every alternative design for anything > we know how to do has already been described in a patent filing. > > So if you really want me to be comfortable with implementing using > VP8, buy me an insurance policy that will indemnify me (and any other > developer) for any costs related to defending against any future > infringement claims on VP8. Perhaps I'd even settle for a free > software stack that includes such indemnification in its license. This > wouldn't help the hardware implementer, much, however. Such is the world of patents (especially software/algorithmic patents). Stick to stuff that's ~25-30 years old and you're probably ok (though someone may ding you for combining old thing A with old thing B). Original MPEG-1 for video is probably ok, just don't add anything to it or extend it or use it in a way not originally envisioned (like over the internet). Or live with non-0 risk of patent trolls. -- Randell Jesup randell-ietf@jesup.org From xiphmont@gmail.com Tue Apr 10 12:34: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 CBD1E11E810A for ; Tue, 10 Apr 2012 12:34: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=[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 xIsVIUDOmUcI for ; Tue, 10 Apr 2012 12:34:53 -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 396DB11E80DF for ; Tue, 10 Apr 2012 12:34:53 -0700 (PDT) Received: by bkuw5 with SMTP id w5so138339bku.31 for ; Tue, 10 Apr 2012 12:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tOb67gM6u2uHnsCJAnfDfMKsB+CqsuiA+uAmjzB2kEs=; b=WtK1+0/dGFiqJT1Mk/LStKPAbpH56Q9307LvGzDAUdJqY6jmMvCdvtw0TI7y5AxJ2z ApKoceWD+fGM1mUpPM4fIpoRz70xKc3qzY+ci/CtMWrqR1wXw/CZ3iPTbIDytReI252a maOHTtWGK/QLPIaegpbjG9jhsGbg7UfV1nqhoyX4Rgvn8XHIn/czK/y1jnzj6KCRBLBt yhByA/zxVWKQmOBVGJm6x5WqjJfeUbqmGn3qn01sspfeBNMNLkF46SjZYB1m6egDdwk8 +DzZdD6E3go82F1W7ZODnJjPKO0GOn0Cpg006qEGJ3IFhFTknhBgN3JgxWsf8d0/QosV e9kA== MIME-Version: 1.0 Received: by 10.204.157.20 with SMTP id z20mr5093328bkw.99.1334086492017; Tue, 10 Apr 2012 12:34:52 -0700 (PDT) Received: by 10.204.189.5 with HTTP; Tue, 10 Apr 2012 12:34:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 15:34:51 -0400 Message-ID: From: Monty Montgomery To: Dean Willis Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Tue, 10 Apr 2012 19:34:57 -0000 (not actually a quote): > So if you really want me to be comfortable with implementing using h264, buy > me an insurance policy that will indemnify me (and any other developer) for > any costs related to defending against any future infringement claims on > h264. Perhaps I'd even settle for a fully licensed software stack that includes such > indemnification in its license. This wouldn't help the hardware implementer, > much, however. Well darn, that isn't going to fly either! Monty Xiph.Org From paulej@packetizer.com Tue Apr 10 21:19: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 E391F11E80F6 for ; Tue, 10 Apr 2012 21:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_50=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 uzr7f0PbESb2 for ; Tue, 10 Apr 2012 21:18:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C027C11E8096 for ; Tue, 10 Apr 2012 21:18:55 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3B4Irua009024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Apr 2012 00:18:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334117934; bh=a4+sBYP4UFF145hKupIwBjrqDHGc8xOcCPKK5yRKE1o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VpuclLyS8tFTuATcROxEsSrIldpU2lvUlacIS4fGFqmSqsExGAsXwbUpGpAQ0pQA+ JLLTu/s5bh0fv2UJ/3vFGEG5ddsprYueVC+UUVyMtDJ+q1ooNSlMV7Uw1tc70zyNq6 oQUy5KxhXzj8CkQxfu+WY2O40a5ImgYPtOTKwHUY= From: "Paul E. Jones" To: "'Monty Montgomery'" , "'Dean Willis'" References: In-Reply-To: Date: Wed, 11 Apr 2012 00:18:59 -0400 Message-ID: <046501cd179a$38ab3840$aa01a8c0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgIAbFTrARQFXm6ZKNuucA== Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Wed, 11 Apr 2012 04:19:07 -0000 > (not actually a quote): > > > So if you really want me to be comfortable with implementing using > > h264, buy me an insurance policy that will indemnify me (and any other > > developer) for any costs related to defending against any future > > infringement claims on h264. Perhaps I'd even settle for a fully > > licensed software stack that includes such indemnification in its > > license. This wouldn't help the hardware implementer, much, however. > > Well darn, that isn't going to fly either! We're still debating this on this? I said before, either direction is a gamble. But, the odds of not getting successfully sued are in your favor with H.264, in my opinion. Here's why: 1) Virtually all companies that have IPR on H.264 are known and the odds of new companies entering the scene at this late stage are slim (seriously, what troll would not have already made a claim by now) 2) Companies who developed H.264 have a financial interest in ensuring H.264's success and would work to defend against bogus claims (I cannot offer up their legal resources, but clearly they will not want some bogus claim to stand in the way of profits, either from use of H.264 themselves or licensing H.264 technology) 3) H.264 is EXTREMELY WIDELY deployed now and anything less than a concrete claim is going to scrutinized heavily, the costs to pursue claims very high, etc. Legitimate companies with IPR should have already filed statements and serious questions would have been asked. To say such "holdout" companies would not win friends at this point with some claim would be an understatement. 4) While law and logic are sometimes at odds, I have to work from logic since I'm not a lawyer. Logically speaking, if there are 200+ patents covering various aspects of H.264 and one more company comes in to make claims, what should any reasonable court agree as to the value of that lone patent versus the 200+ others on the same piece of technology? (OK, this might be reaching, but I seriously do think that damage awards would have to considered in the context of that background.) 5) A damaging claim against H.264 at this point would affect entire industries, and not just one industry. I think even governments should care, because it has an economic impact on a country. I cannot imagine that any court would issue an in injunction to halt sale of videos or streaming video services world-wide, for example, on the basis of some claim relating to some unknown patent nearly 10 years after the standard was produced. If such a claimant had valid IPR and even remotely claimed to be a subject matter expert, they should be fully aware that every effort has been made to identify IPR holders. If I were a judge, I would not be too tolerant of this (what I classify) deliberate, malicious, destructive behavior. Now, should you choose to go down the path of VP8: 1) The only known IPR holder is Google, who has kindly offered to make their IPR available for free 2) There are many, many companies who have IPR on H.264 because their business includes, entirely or as a part, video coding. It's impossible for me to believe that with so much IPR on H.264 and so much research that went into H.264, much of that research NOT finding its way into H.264, that not a single one of those inventions by one of those companies does not cover VP8 3) There are legitimate companies who have invested millions in the development of H.264 and own IPR on H.264. Should VP8 becomes successful and those companies lose revenue at the expense of VP8 and they hold IPR on VP8, they would have every valid reason to assess royalties on your use of VP8. What do you want to bet that the royalties will be even higher than use of H.264, too? (That's a different bet, but since we're gambling here...) 4) VP8 is not a standard and nobody was obligated to file any IPR statements on VP8 (whereas participants in the development of H.264 were all requested to submit statements; company representatives are asked at nearly every meeting) 5) VP8 is not widely deployed and, quite possibly, not widely studied, even by a good many experts in the video coding space (I'm sure some have studied it, but I am sure others are busy building "the next great thing"). As such, nobody should be surprised one day if VP8 does become widely deployed that a company other than Google comes along and lays claim to the technology 6) Should you get sued for embedding VP8 in your hardware or using it in your software, Google is not going to indemnify you. You are on your own. The industry is not going to back you up (whereas I think they would for H.264's benefit), because we all know that using VP8 is done so at our own risk. Perhaps with really good luck an H.264 patent holder might come to your defense with evidence to refute, but don't count on it. Those IPR holders would prefer you switch to H.264. As I said before, my opinions say nothing about the technical merits of one codec vs. the other. This is just my ramblings as I think through the legal minefield here. I personally see H.264 as relatively safe as compared to VP8. Of course, we will never know until VP8 gets widely deployed. No IPR holder who would be seeking to profit on VP8 will disclose a thing until VP8 is widely deployed. It is a gamble. Place your bets. My money is on H.264 as the safer option. Paul From magnus.westerlund@ericsson.com Wed Apr 11 00:47: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 E07EB21F8683 for ; Wed, 11 Apr 2012 00:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Zhc7ttRhIXiZ for ; Wed, 11 Apr 2012 00:47:19 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B6E1321F8682 for ; Wed, 11 Apr 2012 00:47:18 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-34-4f8537056ebf Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DC.10.03534.507358F4; Wed, 11 Apr 2012 09:47:17 +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.213.0; Wed, 11 Apr 2012 09:47:16 +0200 Message-ID: <4F853704.1030000@ericsson.com> Date: Wed, 11 Apr 2012 09:47:16 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F740AB6.1080609@ericsson.com> In-Reply-To: <4F740AB6.1080609@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Poll for dates for Interim Meeting before IETF 84 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 Apr 2012 07:47:20 -0000 WG, I would like to remind about the poll for the date of the Interim meeting between now and IETF 84. We will make a decision after Friday (13th of April). Locations considered so far are Stockholm, Boston Area or Silicon Valley. The meeting is planned to be a 2 day meeting. Please indicate which of the suggest times that works for you. http://doodle.com/nm3pp69znr3286cy 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 harald@alvestrand.no Wed Apr 11 04:46: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 E046521F8665 for ; Wed, 11 Apr 2012 04:46: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 kS7+CmJE2Fnx for ; Wed, 11 Apr 2012 04:46:15 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D46D221F867B for ; Wed, 11 Apr 2012 04:46:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D969939E146 for ; Wed, 11 Apr 2012 13:46:13 +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 4jLX5+bXKw2O for ; Wed, 11 Apr 2012 13:46:12 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D9A3439E098 for ; Wed, 11 Apr 2012 13:46:12 +0200 (CEST) Message-ID: <4F856F04.5050301@alvestrand.no> Date: Wed, 11 Apr 2012 13:46:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F740AB6.1080609@ericsson.com> <4F853704.1030000@ericsson.com> In-Reply-To: <4F853704.1030000@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Poll for dates for Interim Meeting before IETF 84 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 Apr 2012 11:46:16 -0000 Just so that members are aware of this... if it's permissible by W3C rules and logistics, the W3C WEBRTC WG plans to hold a WG meeting in conjunction with this RTCWEB meeting. It will likely be an one-day meeting. Harald On 04/11/2012 09:47 AM, Magnus Westerlund wrote: > WG, > > I would like to remind about the poll for the date of the Interim > meeting between now and IETF 84. We will make a decision after Friday > (13th of April). > > Locations considered so far are Stockholm, Boston Area or Silicon > Valley. The meeting is planned to be a 2 day meeting. Please indicate > which of the suggest times that works for you. > > http://doodle.com/nm3pp69znr3286cy > > 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 magnus.westerlund@ericsson.com Wed Apr 11 05:52: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 9EEF321F8692 for ; Wed, 11 Apr 2012 05:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.229 X-Spam-Level: X-Spam-Status: No, score=-106.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 jjN9rRtFMfph for ; Wed, 11 Apr 2012 05:52:59 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CACBC21F86D8 for ; Wed, 11 Apr 2012 05:52:58 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-55-4f857ea96798 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1A.91.03534.9AE758F4; Wed, 11 Apr 2012 14:52:57 +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.213.0; Wed, 11 Apr 2012 14:52:57 +0200 Message-ID: <4F857EA8.8030003@ericsson.com> Date: Wed, 11 Apr 2012 14:52:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Considerations for Interim Meetings 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 Apr 2012 12:53:00 -0000 WG, We chair would like to discuss some policies we WG chairs intended to use for interim meetings going forward. 1) For physical meetings the WG chairs select the location in a round-robin fashion among regions where we have significant amount of active contributors. This is to spread the inconvenience and cost of long distance travel. 2) We will in the future pick the location prior to any poll for suitable dates so that participants can weigh the location fully into there response to any such poll. 3) For Virtual Interims the time of the day when the meeting is held will be alternated among possible times if necessary to enable reasonable participation times for regions with significant amount of active contributors. This is also to spread the pain of inconvenient time periods of the day. Please comment on these policies. Additional policies that you want us WG chairs to use? Cheers Magnus Westerlund (WG chair) ---------------------------------------------------------------------- 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 remi.scavenius@wanadoo.fr Wed Apr 11 06:38: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 1C45011E8148 for ; Wed, 11 Apr 2012 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 DxplxHWiAzzl for ; Wed, 11 Apr 2012 06:38:24 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) by ietfa.amsl.com (Postfix) with ESMTP id 26CE411E8138 for ; Wed, 11 Apr 2012 06:38:23 -0700 (PDT) Received: from new-host.home ([90.45.197.122]) by mwinf5d32 with ME id wdeN1i0072evqia03deNW8; Wed, 11 Apr 2012 15:38:23 +0200 From: Remi Scavenius Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Apr 2012 15:38:22 +0200 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] WebRTC 2012: CFP deadline extension 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 Apr 2012 13:38:25 -0000 The WebRTC 2012 CFP deadline has been extended to April 30. More details at: http://www.uppersideconferences.com/webrtc2012/webrtc2012intro.html From oej@edvina.net Wed Apr 11 06:48: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 3E8E311E8159 for ; Wed, 11 Apr 2012 06:48:28 -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 gt0kvXKjlkLP for ; Wed, 11 Apr 2012 06:48:27 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8627311E8141 for ; Wed, 11 Apr 2012 06:48:26 -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 F3253754A8AA; Wed, 11 Apr 2012 13:48:24 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Wed, 11 Apr 2012 15:48:24 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [rtcweb] WebRTC 2012: CFP deadline extension 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 Apr 2012 13:48:28 -0000 11 apr 2012 kl. 15:38 skrev Remi Scavenius: > > The WebRTC 2012 CFP deadline has been extended to April 30. > More details at: > http://www.uppersideconferences.com/webrtc2012/webrtc2012intro.html What's the IETF policy in regards to this kind of messages. This conference is highly commercial and not related to the IETF. In my view, it's very close to spamming. /O From mary.ietf.barnes@gmail.com Wed Apr 11 08:15: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 3EA5B11E815C for ; Wed, 11 Apr 2012 08:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AS-nCGu-zldg for ; Wed, 11 Apr 2012 08:15:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7D411E80D5 for ; Wed, 11 Apr 2012 08:15:08 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so805932vcb.31 for ; Wed, 11 Apr 2012 08:15: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=Wywc+eNegUC2Zl1B9HQHyPjEGwkbUa6PhxF9zyqah78=; b=MoT23Mj82KulabTI/gvlDddLI8+f+wVgy7P8iXcsvb0xsWkirKSUBVszAgHAsGVIim OaHA3esTeyO0EeBRzcxAB8s3wqr4txPo+VzTo8OV+QSf2sUqcoZBNJM+eWzrC+rI59Rc UAsLTK1kk8t4kYfJWBEvvKUdjz5XDFqBpdZNhZnTJV07+NKAeHyVdrb5MNPMBuPjxrwK suqlArQDlBlidQ+zi2WzKLvILukmtkeRGnmwoa64TvPIH2SkgKkhmGRGxBoBZKDZiYqJ Dss8gLVrG7f58IUcpc1g1n1P+NPLHRRhcECX8MU/Y5IwIV0xWRu1UIc9AE5s6ulVf5c+ iNng== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr6442000vdh.38.1334157308543; Wed, 11 Apr 2012 08:15:08 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Wed, 11 Apr 2012 08:15:08 -0700 (PDT) In-Reply-To: <4F856F04.5050301@alvestrand.no> References: <4F740AB6.1080609@ericsson.com> <4F853704.1030000@ericsson.com> <4F856F04.5050301@alvestrand.no> Date: Wed, 11 Apr 2012 10:15:08 -0500 Message-ID: From: Mary Barnes To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf3079bc9e73434e04bd68b4a9 Subject: Re: [rtcweb] Poll for dates for Interim Meeting before IETF 84 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 Apr 2012 15:15:10 -0000 --20cf3079bc9e73434e04bd68b4a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And, just so folks are aware, we are also trying to schedule a CLUE meeting (as announced at IETF-83) in conjunction with the RTCWEB meeting as there is overlap in participation as well as technical issues: The doodle for CLUE was crafted around the dates originally proposed for the RTCWEB meeting: http://doodle.com/zd4mhfsb63wkm7ww It still remains a possibility given the current results that we could hold the meetings the same week. Mary. CLUE WG co-chair On Wed, Apr 11, 2012 at 6:46 AM, Harald Alvestrand wr= ote: > Just so that members are aware of this... > > if it's permissible by W3C rules and logistics, the W3C WEBRTC WG plans t= o > hold a WG meeting in conjunction with this RTCWEB meeting. It will likely > be an one-day meeting. > > Harald > > > On 04/11/2012 09:47 AM, Magnus Westerlund wrote: > >> WG, >> >> I would like to remind about the poll for the date of the Interim >> meeting between now and IETF 84. We will make a decision after Friday >> (13th of April). >> >> Locations considered so far are Stockholm, Boston Area or Silicon >> Valley. The meeting is planned to be a 2 day meeting. Please indicate >> which of the suggest times that works for you. >> >> http://doodle.com/**nm3pp69znr3286cy >> >> 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 > --20cf3079bc9e73434e04bd68b4a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And, just so folks are aware, we are also trying to schedule a CLUE meeting= (as announced at IETF-83) in conjunction with the RTCWEB meeting as there = is overlap in participation as well as technical issues:
=A0=A0
The doodle for CLUE was crafted around the dates originally proposed for th= e RTCWEB meeting: =A0http://= doodle.com/zd4mhfsb63wkm7ww

It still remains a possi= bility given the current results that we could hold the meetings the same w= eek.=A0

Mary.=A0
CLUE WG co-chair

On Wed, Apr 11, 2012 at 6:46 AM, Harald Al= vestrand <hara= ld@alvestrand.no> wrote:
Just so that members are aware of this...
if it's permissible by W3C rules and logistics, the W3C WEBRTC WG plans= to hold a WG meeting in conjunction with this RTCWEB meeting. It will like= ly be an one-day meeting.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald


On 04/11/2012 09:47 AM, Magnus Westerlund wrote:
WG,

I would like to remind about the poll for the date of the Interim
meeting between now and IETF 84. We will make a decision after Friday
(13th of April).

Locations considered so far are Stockholm, Boston Area or Silicon
Valley. The meeting is planned to be a 2 day meeting. Please indicate
which of the suggest times that works for you.

http://doo= dle.com/nm3pp69znr3286cy

Cheers

Magnus Westerlund

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

--20cf3079bc9e73434e04bd68b4a9-- From harald@alvestrand.no Wed Apr 11 11:00: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 E7DC811E808D for ; Wed, 11 Apr 2012 11:00:10 -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 h5sIY2QaPTpb for ; Wed, 11 Apr 2012 11:00:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2B22C11E8098 for ; Wed, 11 Apr 2012 11:00:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6935C39E17B; Wed, 11 Apr 2012 20:00:09 +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 sufTiElGTSL9; Wed, 11 Apr 2012 20:00:08 +0200 (CEST) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 922FB39E098; Wed, 11 Apr 2012 20:00:08 +0200 (CEST) Message-ID: <4F85C6A4.4050608@alvestrand.no> Date: Wed, 11 Apr 2012 20:00:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Magnus Westerlund References: <4F857EA8.8030003@ericsson.com> In-Reply-To: <4F857EA8.8030003@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Considerations for Interim Meetings 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 Apr 2012 18:00:11 -0000 On 04/11/2012 02:52 PM, Magnus Westerlund wrote: > WG, > > We chair would like to discuss some policies we WG chairs intended to > use for interim meetings going forward. > > 1) For physical meetings the WG chairs select the location in a > round-robin fashion among regions where we have significant amount of > active contributors. This is to spread the inconvenience and cost of > long distance travel. When considering where to put the next instalment of the round-robin, will the location of IETF meetings be considered too? I note that the 3 next IETF meetings are all in North America (Vancouver, Atlanta and Orlando). It would be very strange if a meeting between Atlanta and Orlando were held in the eastern US. > > 2) We will in the future pick the location prior to any poll for > suitable dates so that participants can weigh the location fully into > there response to any such poll. > > 3) For Virtual Interims the time of the day when the meeting is held > will be alternated among possible times if necessary to enable > reasonable participation times for regions with significant amount of > active contributors. This is also to spread the pain of inconvenient > time periods of the day. > > Please comment on these policies. Additional policies that you want us > WG chairs to use? For logistics, long lead times are a Good Thing; the formal W3C announcement lead time is 8 weeks. This means that it will be good to announce the intent of holding an interim *before* the prior IETF meeting. For interims in response to breaking issues, we should use teleconferences, IMHO. > > Cheers > > Magnus Westerlund > (WG chair) > > ---------------------------------------------------------------------- > 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 dean.willis@softarmor.com Wed Apr 11 23:29: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 819E121F84D5 for ; Wed, 11 Apr 2012 23:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.62 X-Spam-Level: X-Spam-Status: No, score=-101.62 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_40=-0.185, 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 uISPfOYDZ-B4 for ; Wed, 11 Apr 2012 23:29:17 -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 8BB1E21F84D6 for ; Wed, 11 Apr 2012 23:29:14 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2633355obb.31 for ; Wed, 11 Apr 2012 23:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NMVTTZZzFSyjjFKAcIXgN5dNIP/FaEkgPscD08CGWiQ=; b=b+ihzOeUu/c1ImylBq0oTHrYp3AKhXQ4HSedK2h7s8gk6I0OWuDIH8xNE5Xgsk0pxp WKy9mnRFbxElo8z862ZKR3Xnf2CjO+qeLtgZ2iyDLp3Ffj5Ho6dgLZqu5BEGuB44GliI 7ukFkkeeuoG7dqVZ97iWd9InenqfMkBKWIakk= 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=NMVTTZZzFSyjjFKAcIXgN5dNIP/FaEkgPscD08CGWiQ=; b=garxMKPh1nibKHAkqw9l8343m4wGNAxuqtZqG2zXTW0pR3UbSVoA3r5h5vFHl0B+c3 /jfDCxRS8Yd3RlM6f07Cocjqsz1luOfi+r0ALl0i14Jw8GHNX+8go8ATEkdKnxYp7PFD Fq5s/PLZaue9PV4IZlGrEIQpbBoHfTtAx7h5Xk/qAVYLrRwhJY7qUzKtjaQMbGwYdYN3 e1Cv5zwFbZbGMOb3TRz3F7oQ8CpY6Td/WR9RRVWZAWwxdxJNdeeFwU82Iaty971X1jpx D/kqcuGHifRTzqBCDCWUDGrRQD/RtuR0UmNmCwUulq7GK+6Xr16jVHN754Beh8woe+Oj swdQ== MIME-Version: 1.0 Received: by 10.182.119.6 with SMTP id kq6mr1455008obb.67.1334212154023; Wed, 11 Apr 2012 23:29:14 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Wed, 11 Apr 2012 23:29:13 -0700 (PDT) In-Reply-To: <046501cd179a$38ab3840$aa01a8c0$@packetizer.com> References: <046501cd179a$38ab3840$aa01a8c0$@packetizer.com> Date: Thu, 12 Apr 2012 01:29:13 -0500 Message-ID: From: Dean Willis To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d0444ee237edf8304bd757954 X-Gm-Message-State: ALoCoQlzuPoxVa0eg7Ar2Fxl1t9jbKcMkbqr0cZte1kYk61+EuQezjo1SeBb4ePl5GE/ScszUk51 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 06:29:18 -0000 --f46d0444ee237edf8304bd757954 Content-Type: text/plain; charset=ISO-8859-1 > > > > I said before, either direction is a gamble. But, the odds of not getting > successfully sued are in your favor with H.264, in my opinion. Here's why: > > That's arguable. As a small developer (and a poor one), I'm not able to pay for licensing H.264. Therefore, my odds of getting sued (if anybody notices my work) are pretty high. Just ask Microsoft what the odds of getting sued for using H.264 are ... or the costs of trying to license it (reports are that Moto was asking $4 billion for their patents alone). http://www.rethink-wireless.com/article.asp?article_id=23154 I'm not saying VP8 is any safer in the long run, but it's certainly easier to comply with its licensing terms up front. So I might accidentally infringe, but it wouldn't be willful (at least on the essential core; there are a lot of patents about there about stuff you might want to do with the video that cover both codecs). Think of it as picking up a random snake that MIGHT be venomous, versus picking up one that's already buzzing its tail and striking at movement (caught one in my yard Monday, actually). The thing to remember is that you need to handle both with respect. They're still snakes. Even an unenvenomed bite can get infected. And the quiet one might be a cobra instead of a rattlesnake. -- Dean --f46d0444ee237edf8304bd757954 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


I said before, either direction is a gamble. =A0But, the odds of not gettin= g
successfully sued are in your favor with H.264, in my opinion. =A0Here'= s why:


That's arguable. As a sm= all developer (and a poor one), I'm not able to pay for licensing H.264= . Therefore, my odds of getting sued (if anybody notices my work) are prett= y high. Just ask Microsoft what the odds of getting sued for using H.264 ar= e ... or the costs of trying to license it (reports are that Moto was askin= g $4 billion for their patents alone).


I'm not saying VP8 is any safer in the long r= un, but it's certainly easier to comply with its licensing terms up fro= nt. So I might accidentally infringe, but it wouldn't be willful (at le= ast on the essential core; there are a lot of patents about there about stu= ff you might want to do with the video that cover both codecs).

Think of it as picking up a random snake that MIGHT be = venomous, versus picking up one that's already buzzing its tail and str= iking at movement (caught one in my yard Monday, actually).

The thing to remember is that you need to handle both with respe= ct. They're still snakes. Even an unenvenomed bite can get infected. An= d the quiet one might be a cobra instead of a rattlesnake.

--
Dean
--f46d0444ee237edf8304bd757954-- From dean.willis@softarmor.com Wed Apr 11 23:50: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 9FEF421F84D6 for ; Wed, 11 Apr 2012 23:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.502 X-Spam-Level: X-Spam-Status: No, score=-101.502 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_40=-0.185, 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 dvA3jT0oCJmz for ; Wed, 11 Apr 2012 23:50:22 -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 4B96C21F84DF for ; Wed, 11 Apr 2012 23:50:22 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2658245obb.31 for ; Wed, 11 Apr 2012 23:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JiMX7YeDMgeiLrtoHHmrYYe0XzoQTPJjyCVm/sMKf04=; b=VmHprXyALq5r5xv3LhHk3p2ABbFcC386gIurR0/IP++68uO16Zr9yKaNG6ovgc4viV zV1SpEK4D/X0rexXrAFFLjbvIiKB8rDV0qczCdW2tTtNf3Ej5YimasOKrAswG6LmsP4W 0RZRUtAdHWtg6J99DZOwy7FEMM8VTC8ZiHvR0= 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=JiMX7YeDMgeiLrtoHHmrYYe0XzoQTPJjyCVm/sMKf04=; b=UzT4emk4htMd4LdwxXOSGDiQojPcEOwR2g/7sol1tSSmRHF6nOFVxhy6EV0jHtvnkG 9FpSkQ1CFp7Rnx60e+skdvRKm76TOfXym/i9rs9WTcItZ1aJFdcW69CzwGPYGJP+prdI AxS4mCpQnh8mUtr9fjGiIQoyrQwN6rt58oUW2Y8io160GSusZv2fx2drcCX3gM04sfRl yy7+5ftiGTNrcBllRbuyU3IB55grNgmpUMOKbtMcvZdnwMD7rvACGU14qMWj9I4knQcv LkrNh6rGi/wXIwHaGleQi2jU3GurnQMMhEp96JRJlmvoslsMaLTtRahD+2JqSRzso4fY FmUA== MIME-Version: 1.0 Received: by 10.60.4.170 with SMTP id l10mr1433557oel.67.1334213421002; Wed, 11 Apr 2012 23:50:21 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Wed, 11 Apr 2012 23:50:20 -0700 (PDT) In-Reply-To: <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> Date: Thu, 12 Apr 2012 01:50:20 -0500 Message-ID: From: Dean Willis To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f86203701204bd75c557 X-Gm-Message-State: ALoCoQkN8MTxQd4tcRuhpfDDfWlEeYx2crXtsjyZ9OQZnjkdauKjz7QtjN9Vgc7k1zxJSAwvYQdS Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 06:50:23 -0000 --e89a8fb1f86203701204bd75c557 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 5, 2012 at 1:47 AM, Paul E. Jones

> While there may be undisclosed IPR on H.264, I find it hard to believe that > there would be much, if any, at this point. Keep in mind that H.264 is > product of the joint effort of a bunch of people who are experts in the > field. I would be suspicious of any company not involved in the > development > of H.264 claiming to have IPR, because somebody in the joint committee > probably owns that IPR. Sure, there might be something ... something very > minor. Perhaps. > > Both H.264 and VP8 are motion-vector codings, right? A quick search on Google Patents shows about 32,400 existing motion vector video patents. What do you want to bet some of those apply to one or the other? Or both? Or both plus H.263? Just because they haven't been asserted yet doesn't mean they're not real. It might mean that the people that own them aren't paying attention. Or weren't, but have started. Or don't care, but might be willing to sell their patent to someone who does. The simple fact is that there are a crapload of patents out there, and creative reading can get a patent owner fired up enough to start trying to collect revenue on even a very bad patent -- and with hundreds of thousands of patents in the area, some of them are likely to be very good. And in certain venues (the Eastern District of Texas comes to mind), there's a strong presumption that patents are valid and the courts are known to grant damages even though a reexamination is pending. And even if the patent is bogus and you win, you've still spent a lot of money. I'd guess your firm spends more than my yearly revenue on defending even the lamest individual suit. So what I'm saying is that it doesn't matter whether you use H.264 or VP8; you're eventually going to get sued by somebody, and it's going to be expensive and annoying. Build in a revenue margin to plan for it. But there is an argument to make that if you use H.264, you know that somebody with an M in their name is going to be involved SOON unless you fork out cash in advance, whereas if you use VP8, you can hope to maybe wait longer for the surprise and can save your money until then. That said, they both still make me nervous. Can't we just use tin cans and string? ;-) -- Dean --e89a8fb1f86203701204bd75c557 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 5, 2012 at 1:47 AM, Paul E. = Jones <p
While there may be undisclosed IPR on H.264, I find it hard to believe that=
there would be much, if any, at this point. =A0Keep in mind that H.264 is product of the joint effort of a bunch of people who are experts in the
field. =A0I would be suspicious of any company not involved in the developm= ent
of H.264 claiming to have IPR, because somebody in the joint committee
probably owns that IPR. =A0Sure, there might be something ... something ver= y
minor. =A0Perhaps.


Both H.264 and =A0VP8 are motion-vecto= r codings, right?

A quick search on Google Patents= shows about 32,400 existing motion vector video patents. What do you want = to bet some of those apply =A0to one or the other? Or both? Or both plus H.= 263?

Just because they haven't been asserted yet doesn&#= 39;t mean they're not real. It might mean that the people that own them= aren't paying attention. Or weren't, but have started. Or don'= t care, but might be willing to sell their patent to someone who does.

The simple fact is that there are a crapload of patents= out there, and creative reading can get a patent owner fired up enough to = start trying to collect revenue on even a very bad patent -- and with hundr= eds of thousands of patents in the area, some of them are likely to be very= good. And in certain venues (the Eastern District of Texas comes to mind),= there's a strong presumption that patents are valid and the courts are= known to grant damages even though a reexamination is pending. And even if= the patent is bogus and you win, you've still spent a lot of money. I&= #39;d guess your firm spends more than my yearly revenue on defending even = the lamest individual suit.

So what I'm saying is that it doesn't matter wh= ether you use H.264 or VP8; you're eventually going to get sued by some= body, and it's going to be expensive and annoying. Build in a revenue m= argin to plan for it. But there is an argument to make that if you use H.26= 4, you know that somebody with an M in their name is going to be involved S= OON unless you fork out cash in advance, whereas if you use VP8, you can ho= pe to maybe wait longer for the surprise and can save your money until then= .

That said, they both still make me nervous. Can't w= e just use tin cans and string? ;-)

--
Dean
--e89a8fb1f86203701204bd75c557-- From dean.willis@softarmor.com Thu Apr 12 00:03: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 6098321F84E4 for ; Thu, 12 Apr 2012 00:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=0.361, 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 7dxbNBSque-H for ; Thu, 12 Apr 2012 00:03:51 -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 C353421F84B9 for ; Thu, 12 Apr 2012 00:03:51 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2674878obb.31 for ; Thu, 12 Apr 2012 00:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tndbk7CbzSaZuo34jbA6hK7cqfEUMAYtXc8whGeFgrY=; b=QpNAwRX+8pgMX8ta0XINU+dmyv9fXgbId5m8PJjJijj4xwugvjHar1nfL/2+Lcv5xp YMVRGDstoWuts/lM6MJKtCVlyhKBUitR/A2J710CPCkxk4xqtM0w+rgpkpRQox6zuqJ2 Oy82dY3OqyRUABg/VesByHSOO9L4WuN4g0/YY= 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=Tndbk7CbzSaZuo34jbA6hK7cqfEUMAYtXc8whGeFgrY=; b=MycLFKx4uj17PjS14AvVlR0k6fvsE2F7pyAGQtXaPBt4kKztcIEBG8Dr1Z8rsfoIVA ySJxFvJo0AOkZqU4Ooxbl+EYOlLK+x7dHzW/ZcFt6YsaOZlQJx/NzG8PC/y9HcY/LsYC U8lXHiHhdtMWM1h/oHn1d+49Em5FadOnyGAfeT/zyRCuDwC0/TDkVdPwT7k4KgTkCIpV 3t6QDk/Pn5KtA7BEvk6l7yLBn+ojbCWbuH+7kSWfsCR/v7tG+YZScGaXwDrtMwrcqOXT AISK7bEiHbEUuWAoQwz0v/v8S9pas4cC5WIK0xvrMCYOwgOo4JebNBDd6uk26ZhWpAbQ Mvfw== MIME-Version: 1.0 Received: by 10.60.4.170 with SMTP id l10mr1467354oel.67.1334214231337; Thu, 12 Apr 2012 00:03:51 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Thu, 12 Apr 2012 00:03:51 -0700 (PDT) In-Reply-To: <011e01cd135c$fcdc08d0$f6941a70$@packetizer.com> References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> <4F7DB5DC.40507@mozilla.com> <011e01cd135c$fcdc08d0$f6941a70$@packetizer.com> Date: Thu, 12 Apr 2012 02:03:51 -0500 Message-ID: From: Dean Willis To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f862502a5b04bd75f5ce X-Gm-Message-State: ALoCoQngHlM4NnZbpAT7LLsbqaqC5mtvcEHJC9KVPJYqQa7ctqa+FoBnA9YUhloyHQ9ibPACA9br Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 07:03:52 -0000 --e89a8fb1f862502a5b04bd75f5ce Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 5, 2012 at 1:50 PM, Paul E. Jones wrote: > > You're ignoring one point I made. Those involved in the creation of H.264 > have quite likely filed IPR statements with ISO or ITU. If some other > company were to come out of the closet on this with something that > blindsides the industry, the industry would fight it. At the very least, > whatever bit of IPR that is claimed would have to be put into perspective > with respect to the other hundreds of patents on H.264. > > This actually is a good point. Since the existing H.264 claimants gain revenue therefrom, they are likely to act to protect their share of the revenue. It's kind of like the local mob keeping outsiders from putting the squeeze on businesses in their domain. On the other hand, if I can't afford to "buy in" to their protection racket up front, my kneecaps might be in trouble. So do you want a nice safe Northeastern city with a godfather who will make you an offer you can't refuse, or a Wild West free-for-all with a mix of hard working frontiersmen, militant ranch-barons, drunken cowboys, and the occasional marauding aborigine? Different strokes for different folks, I think. -- Dean --e89a8fb1f862502a5b04bd75f5ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 5, 2012 at 1:50 PM, Paul E. = Jones <paulej= @packetizer.com> wrote:

You're ignoring one point I made. =A0Those involved in the creation of = H.264
have quite likely filed IPR statements with ISO or ITU. =A0If some other company were to come out of the closet on this with something that
blindsides the industry, the industry would fight it. =A0At the very least,=
whatever bit of IPR that is claimed would have to be put into perspective with respect to the other hundreds of patents on H.264.


This actually is a good point. Since the existing H.26= 4 claimants gain revenue therefrom, they are likely to act to protect their= share of the revenue. It's kind of like the local mob keeping outsider= s from putting the squeeze on businesses in their domain.=A0

On the other hand, if I can't afford to "buy i= n" to their protection racket up front, my kneecaps might be in troubl= e.

So do you want a nice safe Northeastern city wi= th a godfather who will make you an offer you can't refuse, or a Wild W= est free-for-all with a mix of hard working frontiersmen, militant ranch-ba= rons, drunken cowboys, and the occasional marauding aborigine?=A0

Different strokes for different folks, I think.

--
Dean

--e89a8fb1f862502a5b04bd75f5ce-- From paulej@packetizer.com Thu Apr 12 00:09: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 ACE8711E809A for ; Thu, 12 Apr 2012 00:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_40=-0.185, 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 3Ij7+JiuFy2k for ; Thu, 12 Apr 2012 00:09:50 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 129FE11E8089 for ; Thu, 12 Apr 2012 00:09:49 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3C79mdj026354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Apr 2012 03:09:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334214589; bh=a7c4aleo1lfrhxpK5WOK/+tm+CTwONgWZUPrrsobIww=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lLEdn/vuDDPdXznTpGGYLlDjjCt2vGgVvhiSkZlEydktzbTqRZPoFCUy2vBEXVGAM +8ltuh4Fp+GQQzeE1XUpu0Jg9RAgxDMxBjUKa5R4OsBKBARctTv1jIH9+H1qWxY/c4 8XCQhB30c3LGh/TT04NmH3t5yAvsYRfby3gemYyI= From: "Paul E. Jones" To: "'Dean Willis'" References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> In-Reply-To: Date: Thu, 12 Apr 2012 03:09:52 -0400 Message-ID: <011201cd187b$426e2090$c74a61b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0113_01CD1859.BB5D43E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNwB1VzUBAGtdKoUAdUR/YICM5hPIpjtwgKA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 07:09:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0113_01CD1859.BB5D43E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To be fair, Microsoft and Motorola are just having a lovers quarrel. Do recall that Microsoft has sued Motorola over Android, now they're suing back. It would not surprise me if there were other spats along the way, but I don't keep up with all of these law suits. If Motorola goes knocking on the doors of the thousands of other H.264 users out there, I might believe there is a concern and that Motorola is trying to kill H.264. I don't believe that's the case, though. And I doubt that Motorola would charge you the same $4B to use their patents, either. Go ask them. In any case, when Google swallows Motorola, Google has an opportunity once again to prove that it does no evil. Google gets to manipulate those odds I mentioned. Paul From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 12, 2012 2:50 AM To: Paul E. Jones Cc: Basil Mohamed Gohar; rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline codec] On Thu, Apr 5, 2012 at 1:47 AM, Paul E. Jones

To be fair, Microsoft and Motorola are just having a lovers = quarrel.  Do recall that Microsoft has sued Motorola over Android, = now they’re suing back. It would not surprise me if there were = other spats along the way, but I don’t keep up with all of these = law suits.

 

If Motorola goes knocking on the doors of the thousands of other = H.264 users out there, I might believe there is a concern and that = Motorola is trying to kill H.264.  I don’t believe = that’s the case, though.  And I doubt that Motorola would = charge you the same $4B to use their patents, either.  Go ask = them.

 

In any case, when Google swallows Motorola, Google has an opportunity = once again to prove that it does no evil.  Google gets to = manipulate those odds I mentioned.

 

Paul

 

From:= = Dean Willis [mailto:dean.willis@softarmor.com]
Sent: = Thursday, April 12, 2012 2:50 AM
To: Paul E. = Jones
Cc: Basil Mohamed Gohar; = rtcweb@ietf.org
Subject: Re: [rtcweb] Google VP8 Patent Grant = for third parties [Was Re:Proposal for H.263 baseline = codec]

 

 

On Thu, Apr 5, 2012 at 1:47 AM, Paul E. Jones = <p

While there may be undisclosed IPR on = H.264, I find it hard to believe that
there would be much, if any, at = this point.  Keep in mind that H.264 is
product of the joint = effort of a bunch of people who are experts in the
field.  I = would be suspicious of any company not involved in the development
of = H.264 claiming to have IPR, because somebody in the joint = committee
probably owns that IPR.  Sure, there might be = something ... something very
minor. =  Perhaps.

 

Both H.264 and  VP8 are motion-vector codings, = right?

 

A = quick search on Google Patents shows about 32,400 existing motion vector = video patents. What do you want to bet some of those apply  to one = or the other? Or both? Or both plus H.263?

 

Just because they haven't been asserted yet doesn't = mean they're not real. It might mean that the people that own them = aren't paying attention. Or weren't, but have started. Or don't care, = but might be willing to sell their patent to someone who = does.

 

The simple fact is that there are a crapload of = patents out there, and creative reading can get a patent owner fired up = enough to start trying to collect revenue on even a very bad patent -- = and with hundreds of thousands of patents in the area, some of them are = likely to be very good. And in certain venues (the Eastern District of = Texas comes to mind), there's a strong presumption that patents are = valid and the courts are known to grant damages even though a = reexamination is pending. And even if the patent is bogus and you win, = you've still spent a lot of money. I'd guess your firm spends more than = my yearly revenue on defending even the lamest individual = suit.

 

So what I'm saying is that it doesn't matter whether = you use H.264 or VP8; you're eventually going to get sued by somebody, = and it's going to be expensive and annoying. Build in a revenue margin = to plan for it. But there is an argument to make that if you use H.264, = you know that somebody with an M in their name is going to be involved = SOON unless you fork out cash in advance, whereas if you use VP8, you = can hope to maybe wait longer for the surprise and can save your money = until then.

 

That said, they both still make me nervous. Can't we = just use tin cans and string? ;-)

 

--
Dean

------=_NextPart_000_0113_01CD1859.BB5D43E0-- From oej@edvina.net Thu Apr 12 00:21: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 6FB7421F85C7 for ; Thu, 12 Apr 2012 00:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 Tvtrv7tuniOD for ; Thu, 12 Apr 2012 00:21:41 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D721F85BB for ; Thu, 12 Apr 2012 00:21:40 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1008] (unknown [IPv6:2001:16d8:cc57:1000::42:1008]) by smtp7.webway.se (Postfix) with ESMTPA id CD3DA754A8AA; Thu, 12 Apr 2012 07:21:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 12 Apr 2012 09:21:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> To: Dean Willis X-Mailer: Apple Mail (2.1257) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 07:21:42 -0000 12 apr 2012 kl. 08:50 skrev Dean Willis: > So what I'm saying is that it doesn't matter whether you use H.264 or = VP8; you're eventually going to get sued by somebody, and it's going to = be expensive and annoying. Build in a revenue margin to plan for it. But = there is an argument to make that if you use H.264, you know that = somebody with an M in their name is going to be involved SOON unless you = fork out cash in advance, whereas if you use VP8, you can hope to maybe = wait longer for the surprise and can save your money until then. >=20 > That said, they both still make me nervous. Can't we just use tin cans = and string? ;-) >=20 This is really bad news for Open Source. Even if we try to get a way to = pay for licenses, our business model is far away from understandable for = most of the syndicates. I tried with the AMR codec once and it stopped = at initial order quantity. Anything under 10.000 licenses was not up for = discussion. G.729 is available on one-by-one basis which both Asterisk and = FreeSwitch sell to users... I have no insight into how these agreements = was worked out, but it at least indicates that someone tries to open up. /O From harald@alvestrand.no Thu Apr 12 01:46: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 69B6021F8644 for ; Thu, 12 Apr 2012 01:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, 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 VGNJvRbNE6W3 for ; Thu, 12 Apr 2012 01:46:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 66F0321F8636 for ; Thu, 12 Apr 2012 01:46:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A62B839E178 for ; Thu, 12 Apr 2012 10:46:01 +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 hcleHKqSvqBB for ; Thu, 12 Apr 2012 10:46:00 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BD34039E082 for ; Thu, 12 Apr 2012 10:46:00 +0200 (CEST) Message-ID: <4F869648.2020605@alvestrand.no> Date: Thu, 12 Apr 2012 10:46:00 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 08:46:03 -0000 Hello folks, after the IETF, I've attempted to gather together information about resolution negotiation and what we might need to do there. I pulled together the paragraphs below - this may want to be incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go somewhere else. Chairs' guidance is appreciated. At the moment, I have it in xml2rfc format, so it should be easy to do cut-and-paste on it, but don't want to push it as a separate I-D unless that's what the chairs desire. Note - there are some QUERY sections in there - I'm unsure what those should be resolved to. Comments? Harald 2. Requirements The relevant requirement for video resolution negotiation from the RTCWEB use cases document [I-D.ietf-rtcweb-use-cases-and-requirements] is: o F25 The browser SHOULD use encoding of streams suitable for the current rendering (e.g. video display size) and SHOULD change parameters if the rendering changes during the session. The resulting need is: o To negotiate a maximum spatial resolution for all videos at call setup time o To negotiate a maximum temporal resolution ("frame rate") across all videos at call setup time o To indicate the desire of the recipient for a particular spatial or temporal resolution on a particular video source o To indicate the intent of the sender to send a video source in a particular spatial or temporal resolution This document does not mention other requirements. 3. SDP negotiation of video resolution An RTCWEB client MUST support negotiation of resolution using the "imageattr" attribute, as documented in [RFC6236]. An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and MAY choose to support only the 1.0 value of the "sar" attribute. The interpretation of the negotiation is that any video stream in the m= line containing the a=imageattr attribute will have a resolution within the bounds established by the negotiation. An RTCWEB client MUST support negotiation of the "a=framerate" attribute, as specified in [RFC4566] section 6. Note that this is an upper bound on framerate; there is no lower bound negotiated. These requirements are necessary and sufficient for establishing the maximum spatial and temporal resolution for all videos at call setup time. These bounds MAY be renegotiated over the course of the call, but MUST NOT be renegotiated to render any currently transmitted video stream out of bounds; the sending video stream MUST first be changed to be of a resolution that fits within both the old and the new bounds, or halted. <> An RTCWEB client MUST support per-SSRC requests for video resolutions, as described in [I-D.lennox-mmusic-sdp-source-selection]. This satisfies the requirement to indicate the desire of the recipient for a particular spatial or temporal resolution. We assume that the media sent from a sender to a receiver contains enough information inside the media format to tell what the resolution and framerate is. <> 4. Non-SDP negotiation of video resolution An RTCWEB client MAY support the COP mechanism [I-D.westerlund-avtext-codec-operation-point] to negotiate the resolution of video within the limits established by the SDP negotiation without the need for additional SDP exchanges. 5. Relation to WebRTC API constraint It is intended that the resolution negotiation be influenced by the constraints set by the application of either mandatory or optional constraints at the WebRTC API, as registered in the registry established by [I-D.burnett-rtcweb-constraints-registry]. The following relationships hold for all attributes that the implementation intends to satisfy (note that the constraints listed here have NOT been registered yet): video-min-height >= value of imageattr y= xyrange lower bound video-max-height <= value of imageattr y= xyrange upper bound video-min-framerate is not represented in SDP video-max-framerate <= value of a=framerate attribute video-min-aspect-ratio <= value of imageattr "par=" prange lower bound video-max-aspect-ratio >= value of imageattr "par=" prange upper bound The implementation is free to increase "min" values or decrease "max" values (make requirements more restrictive) and add "step" in order to fit with its implementation restrictions. <>. Constraints specified at PeerConnection creation time are reflected as SDP-wide values. Constraints specified when creating a MediaStream or attaching a MediaStream to a PeerConnection are reflected as ssrc-specific values. From tterriberry@mozilla.com Thu Apr 12 02:09: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 4E2ED21F869A for ; Thu, 12 Apr 2012 02:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 F3sMPbfzhnO5 for ; Thu, 12 Apr 2012 02:09:46 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7916421F8698 for ; Thu, 12 Apr 2012 02:09:46 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 9B1794AEDA1 for ; Thu, 12 Apr 2012 02:09:45 -0700 (PDT) Message-ID: <4F869BD9.6020801@mozilla.com> Date: Thu, 12 Apr 2012 02:09:45 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 CC: "rtcweb@ietf.org" References: <4F869648.2020605@alvestrand.no> In-Reply-To: <4F869648.2020605@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 09:09:47 -0000 Harald Alvestrand wrote: > time. These bounds MAY be renegotiated over the course of the call, > but MUST NOT be renegotiated to render any currently transmitted > video stream out of bounds; the sending video stream MUST first be > changed to be of a resolution that fits within both the old and the > new bounds, or halted. < restriction???>> Is this restriction intended to be imposed on the sender only? I.e., can the recipient still attempt renegotiation (using SDP source selection) of a smaller resolution than is currently allowed (e.g., because it's CPU-bound)? From harald@alvestrand.no Thu Apr 12 05:47: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 4E00721F862F for ; Thu, 12 Apr 2012 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 vYxPt7M2-hok for ; Thu, 12 Apr 2012 05:47:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF5421F865E for ; Thu, 12 Apr 2012 05:47:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9173B39E178; Thu, 12 Apr 2012 14:47:46 +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 ci1YOwTrtuSw; Thu, 12 Apr 2012 14:47:46 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E324F39E082; Thu, 12 Apr 2012 14:47:45 +0200 (CEST) Message-ID: <4F86CEF1.80708@alvestrand.no> Date: Thu, 12 Apr 2012 14:47:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <4F869648.2020605@alvestrand.no> <4F869BD9.6020801@mozilla.com> In-Reply-To: <4F869BD9.6020801@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 12:47:48 -0000 On 04/12/2012 11:09 AM, Timothy B. Terriberry wrote: > Harald Alvestrand wrote: >> time. These bounds MAY be renegotiated over the course of the call, >> but MUST NOT be renegotiated to render any currently transmitted >> video stream out of bounds; the sending video stream MUST first be >> changed to be of a resolution that fits within both the old and the >> new bounds, or halted. <> restriction???>> > > Is this restriction intended to be imposed on the sender only? I.e., > can the recipient still attempt renegotiation (using SDP source > selection) of a smaller resolution than is currently allowed (e.g., > because it's CPU-bound)? What do you think it should say? What I was thinking about was the silly state you can get into if you have a running 1024x768 stream, based on negotiating "width between 1000 and 1500", and want to negotiate max resolution down to 480x360 by saying "width between 400 and 500". The possibilities that may make sense on the sender side: - Negotiate width between 400 and 1500, then change to 480x360, then negotiate width 400-500 - Stop the stream, negotiate width between 400 and 500, then turn on stream at new size - Keep sending 1024x768 until negotiation is complete, then change at your leisure - Switch to 480x360 even though it's not allowed by current parameters, then renegotiate The two first look ugly, but are (as I understand) compatible with current standards. The two last ones seem to break the "only send what you have negotiated" model. If the negotiation is receiver-initiated, it makes more sense (just thinking on the fly here) to say that it can be started at any time, and that the sender is free to change resolution to the new params at any time after he's decided the offer is acceptable. Perhaps he MUST do so before sending the answer? (This is one particular example of Cullen's "what are the steps to change a codec" scenario.....) Harald From ted.ietf@gmail.com Thu Apr 12 08:20: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 E7C7621F864D for ; Thu, 12 Apr 2012 08:20:58 -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 7DgmxPxCjz7l for ; Thu, 12 Apr 2012 08:20:58 -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 5108021F8661 for ; Thu, 12 Apr 2012 08:20:57 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1702076vbb.31 for ; Thu, 12 Apr 2012 08:20:56 -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=fFpCrhA2vK/8WwTNtYX09w4T4M+RL0zMdjHKzjxqnWA=; b=Nom2FE6GpN2UrCpfRWy12KFUjAboLe97YeUv3f3SJL853L0qsKsThIhkbmV3hZW03C sLQkXnsNEId2Z39jJPlA8glh0gHrpgfpbnkzVtPW7B37uyBZx6WG1hWnMuobMgCaC/eX Tap2xOFkvIvm0tTaG2cviMiLbTRIRr54mHxFCefsGSUdJXgKIm/oWdeA61u51yGuejd1 HdsjWHNWtmudieobObKyZdZ3OnTi40M/gQAKjjdY7Bfx4zGb+2chP7H3Jkiq9f1KNl7W rp8LUwhh1bATJ4T/TQ/BN1spRQqHFFn+HmS1Tlpri+B7IyvIUBd199ngprZDp5N91Vy5 hfNg== MIME-Version: 1.0 Received: by 10.220.230.67 with SMTP id jl3mr1467372vcb.50.1334244056830; Thu, 12 Apr 2012 08:20:56 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Thu, 12 Apr 2012 08:20:56 -0700 (PDT) Date: Thu, 12 Apr 2012 08:20:56 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Dates for upcoming interim 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 Apr 2012 15:20:59 -0000 After discussion between the WEBRTC and RTCWEB chairs, consulting the doodle poll, and working through the potential for co-location with CLUE, we have decided to set the date for the RTCWEB interim at June 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that the WEBRTC chairs will hold their meeting on June 11th. If CLUE wishes to co-locate their meeting, the 14th and 15th will be available. This would not have been possible on the previous week, given the national holiday in Sweden on the Wednesday of that week. We very much appreciated the work Eric put into his analysis, and in general we will try to prefer hubs; in this particular case, however, a large fraction of the Western European participants are either based in Stockholm or must fly through it to reach one of the larger hubs. Given the availability of a host and this data, we decided to select Stockholm for this meeting. regards, Ted Hardie, for the chairs. From erik@hookflash.com Thu Apr 12 08:31: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 B89E321F8699 for ; Thu, 12 Apr 2012 08:31:07 -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 gbrqgmZQ39qF for ; Thu, 12 Apr 2012 08:31:06 -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 C76AD21F8671 for ; Thu, 12 Apr 2012 08:31:06 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so607575pbb.31 for ; Thu, 12 Apr 2012 08:31:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=ZkXhU/+9Zsbix8dCAfzHiMm9xQMJT/aTPXycngKnA04=; b=cQEcnbOTbLBIvZoTk456f9gRChbZnIG8uecKvou6GRNHa+1CGJ2VgSY2WiPvszEf1z qmhMGn9swWDl0Q7ED26E+F3O0CkdMBkVxqBEToLOsZuZUrCuCUgY7/+0gXbOoQLSl0UX hRHLciMJsk6GEe0TUQSwri8z8u+uCKa+MsehHe0JJklayvDu7iK9Ne32F4Umt8GPPea1 6HEWpdYZsN6thQHEZWLJSI2YfsP+9Ip+8LlICLnCSzgORfuZXpcm5lo1wlDDKG0dF6K3 t0fGlQS4cWclB97lP9dwKkNnmuv+N5/r6wO76QZFDtCShwV/22wlGLWTmj9Ix6aj/R4l YXgQ== Received: by 10.68.138.232 with SMTP id qt8mr2616623pbb.114.1334244666340; Thu, 12 Apr 2012 08:31:06 -0700 (PDT) Received: from [192.168.1.108] (S010678cd8e61db1f.vn.shawcable.net. [174.7.103.13]) by mx.google.com with ESMTPS id i8sm5950208pbf.72.2012.04.12.08.31.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 08:31:04 -0700 (PDT) References: <046501cd179a$38ab3840$aa01a8c0$@packetizer.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-140D86EF-150A-469B-8D18-8F51276FDF20 Message-Id: <49E8B9A6-27F1-4CAE-9DF6-A869D1FE4D52@hookflash.com> X-Mailer: iPad Mail (9B176) From: Erik Lagerway Date: Thu, 12 Apr 2012 08:31:03 -0700 To: Dean Willis X-Gm-Message-State: ALoCoQnKihLAXfWPNBEHqGkCpVcFi0bGsLDU0575MbC/8fQVYvT+xWf/0FW7zPTjuSRDiJPu5Sk4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 15:31:07 -0000 --Apple-Mail-140D86EF-150A-469B-8D18-8F51276FDF20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As a poor and rather nervous developer trying to avoid any slithering reptil= es laying await in the grass, VP8 seems to be the not so obvious choice here= . Would be better if Google could get behind this a little more as the vague= ness could drive some to using H.263 (plegh), liability or not, most perceiv= e 263 as royalty free. As it stands... VP8 +1 On 2012-04-11, at 11:29 PM, Dean Willis wrote: >=20 >=20 > I said before, either direction is a gamble. But, the odds of not getting= > successfully sued are in your favor with H.264, in my opinion. Here's why= : >=20 >=20 > That's arguable. As a small developer (and a poor one), I'm not able to pa= y for licensing H.264. Therefore, my odds of getting sued (if anybody notice= s my work) are pretty high. Just ask Microsoft what the odds of getting sued= for using H.264 are ... or the costs of trying to license it (reports are t= hat Moto was asking $4 billion for their patents alone). >=20 > http://www.rethink-wireless.com/article.asp?article_id=3D23154 >=20 > I'm not saying VP8 is any safer in the long run, but it's certainly easier= to comply with its licensing terms up front. So I might accidentally infrin= ge, but it wouldn't be willful (at least on the essential core; there are a l= ot of patents about there about stuff you might want to do with the video th= at cover both codecs). >=20 > Think of it as picking up a random snake that MIGHT be venomous, versus pi= cking up one that's already buzzing its tail and striking at movement (caugh= t one in my yard Monday, actually). >=20 > The thing to remember is that you need to handle both with respect. They'r= e still snakes. Even an unenvenomed bite can get infected. And the quiet one= might be a cobra instead of a rattlesnake. >=20 > -- > Dean > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-140D86EF-150A-469B-8D18-8F51276FDF20 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
As a poor and rather nervous developer trying to avoid any slithering reptiles laying await in the grass, VP8 seems to be the not so obvious choice here. Would be better if Google could get behind this a little more as the vagueness could drive some to using H.263 (plegh), liability or not, most perceive 263 as royalty free.

As it stands...

VP8 +1

On 2012-04-11, at 11:29 PM, Dean Willis <dean.willis@softarmor.com> wrote:



I said before, either direction is a gamble.  But, the odds of not getting
successfully sued are in your favor with H.264, in my opinion.  Here's why:


That's arguable. As a small developer (and a poor one), I'm not able to pay for licensing H.264. Therefore, my odds of getting sued (if anybody notices my work) are pretty high. Just ask Microsoft what the odds of getting sued for using H.264 are ... or the costs of trying to license it (reports are that Moto was asking $4 billion for their patents alone).


I'm not saying VP8 is any safer in the long run, but it's certainly easier to comply with its licensing terms up front. So I might accidentally infringe, but it wouldn't be willful (at least on the essential core; there are a lot of patents about there about stuff you might want to do with the video that cover both codecs).

Think of it as picking up a random snake that MIGHT be venomous, versus picking up one that's already buzzing its tail and striking at movement (caught one in my yard Monday, actually).

The thing to remember is that you need to handle both with respect. They're still snakes. Even an unenvenomed bite can get infected. And the quiet one might be a cobra instead of a rattlesnake.

--
Dean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-140D86EF-150A-469B-8D18-8F51276FDF20-- From ekr@rtfm.com Thu Apr 12 08:50: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 AD84421F869D for ; Thu, 12 Apr 2012 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.835, 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 C3igkr1jxuYH for ; Thu, 12 Apr 2012 08:50:07 -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 C20C221F8693 for ; Thu, 12 Apr 2012 08:50:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1726542vbb.31 for ; Thu, 12 Apr 2012 08:50:07 -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=deeVSsvyKznI6er45PPgjuJrO2jgc+tZGBqdWQW+sKY=; b=BVZT4JDADPsIH+3Ev+GSbAB6xH3k5K95tGBDxnA8R+oxLYuRQKWGw0e5N93e/mEtxo nvpJRuU6uWhb5hRbtbjiLQIEdNUX3G7HthK8zvlpejY0wA28vPyVUn0dT5wB0Jifktdq P3hoeJXlPj6i3dKxDeQxSm5RoklsI1LTNu5U9vd2M5duYaoHFSXfDiQNM4The2suNlDB wngkybQHelDyX9Z/hU8Lt0I7SlnDadTUEZX1FIswnY6h7lJpEuzcg6weX2dNAHzm9rIT FcCNJMbJHzagMI55imnk2Epu/wRbm3F6R7KFZQRUYsYdSgLyKF8qJPhdTiceN63U8Rk9 qWOg== Received: by 10.52.65.134 with SMTP id x6mr1231182vds.60.1334245807228; Thu, 12 Apr 2012 08:50:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 12 Apr 2012 08:49:26 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Thu, 12 Apr 2012 08:49:26 -0700 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnju+QYU9cnui0e8w5QkDsu0E+NAISZourfEIPQkaWqlpMTgSDtE2gxzfjMom06aaSDlhKt Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Dates for upcoming interim 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 Apr 2012 15:50:09 -0000 On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: > After discussion between the WEBRTC and RTCWEB chairs, consulting the > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand that > the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE > wishes to co-locate their meeting, the 14th and 15th will be > available. =A0This would not have been possible on the previous week, > given the national holiday in Sweden on the Wednesday of that week. > > We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however, > a large fraction of the Western European participants are either based > in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting. Thanks for resolving this. Since I'm assuming we're going to be having more of these, I'd like to ask the chairs to publish ASAP whatever rotation they are planning to use in the future. This would be very useful for planning purposes, as well as to allow discussion of the proposes rota well in advance Thanks, -Ekr From kpfleming@digium.com Thu Apr 12 08:58: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 2485C21F86A8 for ; Thu, 12 Apr 2012 08:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 yZLs6Wsx9Et6 for ; Thu, 12 Apr 2012 08:58:26 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 588A621F86A2 for ; Thu, 12 Apr 2012 08:58:26 -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 1SIMPh-0002E7-3y for rtcweb@ietf.org; Thu, 12 Apr 2012 10:58:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 20B98D8004 for ; Thu, 12 Apr 2012 10:58:25 -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 JDFRF8ZgjTU7 for ; Thu, 12 Apr 2012 10:58:24 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id C2D44D8002 for ; Thu, 12 Apr 2012 10:58:24 -0500 (CDT) Message-ID: <4F86FBA0.6070607@digium.com> Date: Thu, 12 Apr 2012 10:58:24 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.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] Dates for upcoming interim 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 Apr 2012 15:58:27 -0000 On 04/12/2012 10:20 AM, Ted Hardie wrote: > After discussion between the WEBRTC and RTCWEB chairs, consulting the > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12& 13th, to be hosted by Ericsson in Stockholm. We understand that > the WEBRTC chairs will hold their meeting on June 11th. If CLUE > wishes to co-locate their meeting, the 14th and 15th will be > available. This would not have been possible on the previous week, > given the national holiday in Sweden on the Wednesday of that week. > > We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however, > a large fraction of the Western European participants are either based > in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting. Thanks for the update; please let us know once the details of remote participation (if any) are available. Airfare from the US to Stockholm for those dates is well north of US$1400 already, so a number of us won't be able to get travel dollars to attend in person. -- 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 Thu Apr 12 09:10: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 F082221F86D3 for ; Thu, 12 Apr 2012 09:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VzZTlYVBICd7 for ; Thu, 12 Apr 2012 09:10:00 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id C0E4C21F8512 for ; Thu, 12 Apr 2012 09:10:00 -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 1SIMau-0002Ta-GF for rtcweb@ietf.org; Thu, 12 Apr 2012 11:10:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 7A901D8004 for ; Thu, 12 Apr 2012 11:10:00 -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 Iz31dd2x1J8I for ; Thu, 12 Apr 2012 11:10:00 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 2980ED8002 for ; Thu, 12 Apr 2012 11:10:00 -0500 (CDT) Message-ID: <4F86FE57.8070704@digium.com> Date: Thu, 12 Apr 2012 11:09:59 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 16:10:02 -0000 On 04/12/2012 02:21 AM, Olle E. Johansson wrote: > This is really bad news for Open Source. Even if we try to get a way to pay for licenses, our business model is far away from understandable for most of the syndicates. I tried with the AMR codec once and it stopped at initial order quantity. Anything under 10.000 licenses was not up for discussion. > > G.729 is available on one-by-one basis which both Asterisk and FreeSwitch sell to users... I have no insight into how these agreements was worked out, but it at least indicates that someone tries to open up. It is my understanding that the licensing arrangements that have been made for G.729 are no longer an option for new licensees (not offered by the consortium), and to my knowledge such arrangements have never been an option for any of the other voice/video codecs that our customers have asked us about (including H.264, the AMR family and others). -- 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 ted.ietf@gmail.com Thu Apr 12 09:16: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 7489E21F86A6 for ; Thu, 12 Apr 2012 09:16:49 -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 UaDdqaTnfZyk for ; Thu, 12 Apr 2012 09:16:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F209221F85D1 for ; Thu, 12 Apr 2012 09:16:48 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1754712vcb.31 for ; Thu, 12 Apr 2012 09:16: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=i0mlbebvpxZE4Y9qjocbJF3mijEpqnRNa8mN+2S3Eec=; b=DdH/GQ1dNrI0LwSgePXdSOIBfTNKpgnP8HCMcr17wmNoDRZbdLSbTNjpJ3lFh6MWEb /Ll7PFydimq16Rrspzn0tgzDUr+fhfx99yKi0gSu9mlbg7ZWw7ttEjJnaO9ymAZbZN5w bYN8v3faUPOQpkTMQ9CkiP9ukCgrKMPPJrwEb1ySfIppagO6MSUDcyGg8WhFl3wvG/YS cBDZbVMpq4JGwSSfgJ9GyCskHjhGuwnNbMxRHWYiwyeMXuDRlos5858q46d25Pp+1fD7 nRiqB9RJqxfBrV9jABXa9OOY03uoM1LFSfgjPqql10u+0CBg+YXf45Cod2jL37B6vggh z1Nw== MIME-Version: 1.0 Received: by 10.52.89.106 with SMTP id bn10mr1230334vdb.116.1334247408492; Thu, 12 Apr 2012 09:16:48 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Thu, 12 Apr 2012 09:16:48 -0700 (PDT) In-Reply-To: <4F86FBA0.6070607@digium.com> References: <4F86FBA0.6070607@digium.com> Date: Thu, 12 Apr 2012 09:16:48 -0700 Message-ID: From: Ted Hardie To: "Kevin P. Fleming" Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Dates for upcoming interim 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 Apr 2012 16:16:49 -0000 On Thu, Apr 12, 2012 at 8:58 AM, Kevin P. Fleming wrote: > > Thanks for the update; please let us know once the details of remote > participation (if any) are available. Airfare from the US to Stockholm for > those dates is well north of US$1400 already, so a number of us won't be > able to get travel dollars to attend in person. > We will work to get the details to you as soon as possible. We definitely will have options for remote participation. regards, Ted Hardie From marshall.eubanks@gmail.com Thu Apr 12 09:19: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 CBD5821F869E for ; Thu, 12 Apr 2012 09:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.297 X-Spam-Level: X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_19=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 uTRPahXMg8hZ for ; Thu, 12 Apr 2012 09:19:18 -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 76D3A21F864D for ; Thu, 12 Apr 2012 09:19:15 -0700 (PDT) Received: by lbok13 with SMTP id k13so1881823lbo.31 for ; Thu, 12 Apr 2012 09:19:14 -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=8y9F5qPMixS4pmagmgNV6fmI/oIGNl5aNY2klCX7mY8=; b=sISBaLIUEhuG5IghDit72a/uO4ZLFgrwJbmBqhEmjDevPxyHGflE1qBwl44dcRxK0o meHj3a8WL3S+u3NjlCPoHqcSK3Gy0kmfIMqyna9vYJcB/JH9T64+FxoKp8xa4kJPAkOP zNySdoJlHL8kxXa0hOU3g7KqVesgj1IR0pynpwmrt4JurVLPcIQ/2UC0rTy2ST9dUGKv WIqV7R0VDvzCenZAHK2UpvIRBDbpblt9rom8rkag08dfk556BfJQjO+eTpCfaTzI6ppE j2RSQBcdg0npNtuebWJGbF4Fjrx935VJ7QJ5px7oPxlfqs8FnTHarnO27Y1m1fng9NrV G7vw== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr2964479lab.35.1334247554381; Thu, 12 Apr 2012 09:19:14 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Thu, 12 Apr 2012 09:19:14 -0700 (PDT) In-Reply-To: <4F869648.2020605@alvestrand.no> References: <4F869648.2020605@alvestrand.no> Date: Thu, 12 Apr 2012 12:19:14 -0400 Message-ID: From: Marshall Eubanks To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 16:19:18 -0000 On Thu, Apr 12, 2012 at 4:46 AM, Harald Alvestrand w= rote: > Hello folks, > > after the IETF, I've attempted to gather together information about > resolution negotiation and what we might need to do there. > > I pulled together the paragraphs below - this may want to be incorporated= in > an I-D on "SDP usage in RTCWEB", or it may want to go somewhere else. > Chairs' guidance is appreciated. > > At the moment, I have it in xml2rfc format, so it should be easy to do > cut-and-paste on it, but don't want to push it as a separate I-D unless > that's what the chairs desire. > Note - there are some QUERY sections in there - I'm unsure what those sho= uld > be resolved to. > > Comments? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald > > 2. =A0Requirements > > =A0 The relevant requirement for video resolution negotiation from the > =A0 RTCWEB use cases document > =A0 [I-D.ietf-rtcweb-use-cases-and-requirements] is: > > =A0 o =A0F25 The browser SHOULD use encoding of streams suitable for the > =A0 =A0 =A0current rendering (e.g. video display size) and SHOULD change > =A0 =A0 =A0parameters if the rendering changes during the session. > > =A0 The resulting need is: > > =A0 o =A0To negotiate a maximum spatial resolution for all videos at call > =A0 =A0 =A0setup time > > =A0 o =A0To negotiate a maximum temporal resolution ("frame rate") across > =A0 =A0 =A0all videos at call setup time > It is not clear if this is "per session" or "per browser" and that should be made clear. Here is why it makes a difference: Per session maximum video limits can give rise to a "race to the bottom" in the case of a mixed multiparty conference. Suppose, for example, you have 4 parties. One is on a low powered phone with a low bandwidth connection, and all they can handle is SIF at 384 kbps and 15 fps. The other three have the power to handle 1048p at > 1 Mbps and 30 fps. Restriction of all uses to the capability of the least-capable participant is, for example, not likely to go over well in mixed RTCWEB / CLUE Telepresence sessions. This is a very common situation, and the solution is to do this negotiation "per browser." Of course, in practice, this generally requires middleware (4.3.3. in draft-ietf-rtcweb-use-cases-and-requirements ). Regards Marshall > =A0 o =A0To indicate the desire of the recipient for a particular spatial > =A0 =A0 =A0or temporal resolution on a particular video source > > =A0 o =A0To indicate the intent of the sender to send a video source in a > =A0 =A0 =A0particular spatial or temporal resolution > > =A0 This document does not mention other requirements. > > > 3. =A0SDP negotiation of video resolution > > =A0 An RTCWEB client MUST support negotiation of resolution using the > =A0 "imageattr" attribute, as documented in [RFC6236]. > > =A0 An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and > =A0 MAY choose to support only the 1.0 value of the "sar" attribute. > > =A0 The interpretation of the negotiation is that any video stream in the > =A0 m=3D line containing the a=3Dimageattr attribute will have a resoluti= on > =A0 within the bounds established by the negotiation. > > =A0 An RTCWEB client MUST support negotiation of the "a=3Dframerate" > =A0 attribute, as specified in [RFC4566] section 6. =A0Note that this is = an > =A0 upper bound on framerate; there is no lower bound negotiated. > > =A0 These requirements are necessary and sufficient for establishing the > =A0 maximum spatial and temporal resolution for all videos at call setup > =A0 time. =A0These bounds MAY be renegotiated over the course of the call= , > =A0 but MUST NOT be renegotiated to render any currently transmitted > =A0 video stream out of bounds; the sending video stream MUST first be > =A0 changed to be of a resolution that fits within both the old and the > =A0 new bounds, or halted. < =A0 restriction???>> > > =A0 An RTCWEB client MUST support per-SSRC requests for video > =A0 resolutions, as described in > =A0 [I-D.lennox-mmusic-sdp-source-selection]. =A0This satisfies the > =A0 requirement to indicate the desire of the recipient for a particular > =A0 spatial or temporal resolution. > > =A0 We assume that the media sent from a sender to a receiver contains > =A0 enough information inside the media format to tell what the > =A0 resolution and framerate is. < =A0 with an "imageattr" or "framerate" attribute in the forward direction > =A0 instead?>> > > > 4. =A0Non-SDP negotiation of video resolution > > =A0 An RTCWEB client MAY support the COP mechanism > =A0 [I-D.westerlund-avtext-codec-operation-point] to negotiate the > =A0 resolution of video within the limits established by the SDP > =A0 negotiation without the need for additional SDP exchanges. > > > 5. =A0Relation to WebRTC API constraint > > =A0 It is intended that the resolution negotiation be influenced by the > =A0 constraints set by the application of either mandatory or optional > =A0 constraints at the WebRTC API, as registered in the registry > =A0 established by [I-D.burnett-rtcweb-constraints-registry]. > > =A0 The following relationships hold for all attributes that the > =A0 implementation intends to satisfy (note that the constraints listed > =A0 here have NOT been registered yet): > > =A0 video-min-height >=3D value of imageattr y=3D xyrange lower bound > > =A0 video-max-height <=3D value of imageattr y=3D xyrange upper bound > > =A0 video-min-framerate is not represented in SDP > > =A0 video-max-framerate <=3D value of a=3Dframerate attribute > > =A0 video-min-aspect-ratio <=3D value of imageattr "par=3D" prange lower > =A0 bound > > =A0 video-max-aspect-ratio >=3D value of imageattr "par=3D" prange upper > =A0 bound > > =A0 The implementation is free to increase "min" values or decrease "max" > =A0 values (make requirements more restrictive) and add "step" in order > =A0 to fit with its implementation restrictions. < =A0 of the direction of those assumptions>>. > > =A0 Constraints specified at PeerConnection creation time are reflected > =A0 as SDP-wide values. =A0Constraints specified when creating a > =A0 MediaStream or attaching a MediaStream to a PeerConnection are > =A0 reflected as ssrc-specific values. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Thu Apr 12 09:21: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 91F0F21F86A2 for ; Thu, 12 Apr 2012 09:21:53 -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 ZP9TIG3tgSa6 for ; Thu, 12 Apr 2012 09:21:52 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17B21F86DA for ; Thu, 12 Apr 2012 09:21:51 -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 9C925754A8BB; Thu, 12 Apr 2012 16:21:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4F86FE57.8070704@digium.com> Date: Thu, 12 Apr 2012 18:21:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> <4F86FE57.8070704@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1257) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 12 Apr 2012 16:21:53 -0000 12 apr 2012 kl. 18:09 skrev Kevin P. Fleming: > On 04/12/2012 02:21 AM, Olle E. Johansson wrote: >=20 >> This is really bad news for Open Source. Even if we try to get a way = to pay for licenses, our business model is far away from understandable = for most of the syndicates. I tried with the AMR codec once and it = stopped at initial order quantity. Anything under 10.000 licenses was = not up for discussion. >>=20 >> G.729 is available on one-by-one basis which both Asterisk and = FreeSwitch sell to users... I have no insight into how these agreements = was worked out, but it at least indicates that someone tries to open up. >=20 > It is my understanding that the licensing arrangements that have been = made for G.729 are no longer an option for new licensees (not offered by = the consortium), and to my knowledge such arrangements have never been = an option for any of the other voice/video codecs that our customers = have asked us about (including H.264, the AMR family and others). And isn't that a shame. The question here for the legal department is = wether Google's policies in regards to VP8 is enough for companies like = you to work with it in either binary addons or Open Source code? Does it = provide enough liability assurance? I think that question is where we are right now. If not, will Google try to offer a solution? /O= From harald@alvestrand.no Thu Apr 12 09:51: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 EE9CA21F863E for ; Thu, 12 Apr 2012 09:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, 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 YxPXKrfEleGs for ; Thu, 12 Apr 2012 09:51:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9C821F8604 for ; Thu, 12 Apr 2012 09:51:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BBD639E0A7; Thu, 12 Apr 2012 18:51:54 +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 aw8YqdKRdU75; Thu, 12 Apr 2012 18:51:52 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B875139E082; Thu, 12 Apr 2012 18:51:52 +0200 (CEST) Message-ID: <4F870828.5080201@alvestrand.no> Date: Thu, 12 Apr 2012 18:51:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Marshall Eubanks References: <4F869648.2020605@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 16:51:58 -0000 On 04/12/2012 06:19 PM, Marshall Eubanks wrote: > On Thu, Apr 12, 2012 at 4:46 AM, Harald Alvestrand wrote: >> Hello folks, >> >> after the IETF, I've attempted to gather together information about >> resolution negotiation and what we might need to do there. >> >> I pulled together the paragraphs below - this may want to be incorporated in >> an I-D on "SDP usage in RTCWEB", or it may want to go somewhere else. >> Chairs' guidance is appreciated. >> >> At the moment, I have it in xml2rfc format, so it should be easy to do >> cut-and-paste on it, but don't want to push it as a separate I-D unless >> that's what the chairs desire. >> Note - there are some QUERY sections in there - I'm unsure what those should >> be resolved to. >> >> Comments? >> >> Harald >> >> 2. Requirements >> >> The relevant requirement for video resolution negotiation from the >> RTCWEB use cases document >> [I-D.ietf-rtcweb-use-cases-and-requirements] is: >> >> o F25 The browser SHOULD use encoding of streams suitable for the >> current rendering (e.g. video display size) and SHOULD change >> parameters if the rendering changes during the session. >> >> The resulting need is: >> >> o To negotiate a maximum spatial resolution for all videos at call >> setup time >> >> o To negotiate a maximum temporal resolution ("frame rate") across >> all videos at call setup time >> > It is not clear if this is "per session" or "per browser" and that > should be made clear. Since this is negotiation, it has to be observable across the wire, which means that it's negotiated per SDP session - that is, per PeerConnection pair, which has an SDP session between them. I don't see how it could be otherwise. > Here is why it makes a difference: > > Per session maximum video limits can give rise to a "race to the > bottom" in the case of a mixed multiparty conference. > > Suppose, for example, you have 4 parties. One is on a low powered > phone with a low bandwidth connection, and > all they can handle is SIF at 384 kbps and 15 fps. The other three > have the power to handle 1048p at> 1 Mbps and 30 fps. > > Restriction of all uses to the capability of the least-capable > participant is, for example, not > likely to go over well in mixed RTCWEB / CLUE Telepresence sessions. I break this up differently than you do..... we might be talking about the same thing still. for the mesh conferencing situation, each participant has a direct connection to the "weakling". That session will need to negotiate down to what's available. It's up to the app to decide whether it produces multiple streams at different resolutions or not (and up to the browser to figure out if it can support that). For the centralized scenario, either the central unit provides downsampling (or stripping, if the end nodes are doing some kind of AVC or simulcast), or the "race to the bottom" you worry about will happen. The word "session" has become one of the words I try to avoid using without a qualifier.... > This is a very common situation, and the solution is to do this negotiation > "per browser." Of course, in practice, this generally requires > middleware (4.3.3. in > draft-ietf-rtcweb-use-cases-and-requirements ). > > Regards > Marshall > >> o To indicate the desire of the recipient for a particular spatial >> or temporal resolution on a particular video source >> >> o To indicate the intent of the sender to send a video source in a >> particular spatial or temporal resolution >> >> This document does not mention other requirements. >> >> >> 3. SDP negotiation of video resolution >> >> An RTCWEB client MUST support negotiation of resolution using the >> "imageattr" attribute, as documented in [RFC6236]. >> >> An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and >> MAY choose to support only the 1.0 value of the "sar" attribute. >> >> The interpretation of the negotiation is that any video stream in the >> m= line containing the a=imageattr attribute will have a resolution >> within the bounds established by the negotiation. >> >> An RTCWEB client MUST support negotiation of the "a=framerate" >> attribute, as specified in [RFC4566] section 6. Note that this is an >> upper bound on framerate; there is no lower bound negotiated. >> >> These requirements are necessary and sufficient for establishing the >> maximum spatial and temporal resolution for all videos at call setup >> time. These bounds MAY be renegotiated over the course of the call, >> but MUST NOT be renegotiated to render any currently transmitted >> video stream out of bounds; the sending video stream MUST first be >> changed to be of a resolution that fits within both the old and the >> new bounds, or halted.<> restriction???>> >> >> An RTCWEB client MUST support per-SSRC requests for video >> resolutions, as described in >> [I-D.lennox-mmusic-sdp-source-selection]. This satisfies the >> requirement to indicate the desire of the recipient for a particular >> spatial or temporal resolution. >> >> We assume that the media sent from a sender to a receiver contains >> enough information inside the media format to tell what the >> resolution and framerate is.<> with an "imageattr" or "framerate" attribute in the forward direction >> instead?>> >> >> >> 4. Non-SDP negotiation of video resolution >> >> An RTCWEB client MAY support the COP mechanism >> [I-D.westerlund-avtext-codec-operation-point] to negotiate the >> resolution of video within the limits established by the SDP >> negotiation without the need for additional SDP exchanges. >> >> >> 5. Relation to WebRTC API constraint >> >> It is intended that the resolution negotiation be influenced by the >> constraints set by the application of either mandatory or optional >> constraints at the WebRTC API, as registered in the registry >> established by [I-D.burnett-rtcweb-constraints-registry]. >> >> The following relationships hold for all attributes that the >> implementation intends to satisfy (note that the constraints listed >> here have NOT been registered yet): >> >> video-min-height>= value of imageattr y= xyrange lower bound >> >> video-max-height<= value of imageattr y= xyrange upper bound >> >> video-min-framerate is not represented in SDP >> >> video-max-framerate<= value of a=framerate attribute >> >> video-min-aspect-ratio<= value of imageattr "par=" prange lower >> bound >> >> video-max-aspect-ratio>= value of imageattr "par=" prange upper >> bound >> >> The implementation is free to increase "min" values or decrease "max" >> values (make requirements more restrictive) and add "step" in order >> to fit with its implementation restrictions.<> of the direction of those assumptions>>. >> >> Constraints specified at PeerConnection creation time are reflected >> as SDP-wide values. Constraints specified when creating a >> MediaStream or attaching a MediaStream to a PeerConnection are >> reflected as ssrc-specific values. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Thu Apr 12 10:42: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 72B3621F856C for ; Thu, 12 Apr 2012 10:42:41 -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 AbP58iZ0MZ5v for ; Thu, 12 Apr 2012 10:42:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF62121F855F for ; Thu, 12 Apr 2012 10:42:40 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1823267vcb.31 for ; Thu, 12 Apr 2012 10:42:40 -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 :content-transfer-encoding; bh=YUkRHaRfcG4sFssz37K9fDQaLu0NzkIJVhC3kyU4W8A=; b=ldURMoSKgrH+owexUsUb4jPGyAntd1kxH4IKWz9VfY+ybyFCNNYnOnwFtzhPCSovlo 2GQ4TRtVzerJEErjGCnXxhAvLsB9yXiI1AYJaNHRZrYey6Fg2VzTlMzfC4m4a1M4T9yd v79Zy+cTj2fWBW8M+1ic/3CP50GFeoP3Ddc3/blBu0RGSi8a/gW4+76nqZ+J1GSByNi5 7IjGZQ6fIqsiGw5u6bT/G8KnVmCi7XOs9mYs+CjLxTIE0e+JKdj/HnZSQfAyWlXHC649 xUz0R5iLpwEqT9B3YL4ccb4XAEyn2dQURge4XwjLK+zKeAFS3D8ycJ6N/vAi+Eiwl63E eJkA== MIME-Version: 1.0 Received: by 10.52.34.79 with SMTP id x15mr1409822vdi.0.1334252560458; Thu, 12 Apr 2012 10:42:40 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Thu, 12 Apr 2012 10:42:40 -0700 (PDT) Date: Thu, 12 Apr 2012 10:42:40 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, Magnus Westerlund , Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rai-ads@tools.ietf.org, clue-chairs@tools.ietf.org Subject: [rtcweb] URGENT: Dates for upcoming interim ON HOLD 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 Apr 2012 17:42:41 -0000 Please hold off making travel plans based on this timing. Because neither RAI area director will be available during this timing, they have asked to consider shifting this timing to the previous week, June 7th and 8th. Until the chairs have had a chance to discuss this, please hold off on booking travel plans. My apologies for this scramble, Ted Hardie On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: > After discussion between the WEBRTC and RTCWEB chairs, consulting the > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand that > the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE > wishes to co-locate their meeting, the 14th and 15th will be > available. =A0This would not have been possible on the previous week, > given the national holiday in Sweden on the Wednesday of that week. > > We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however, > a large fraction of the Western European participants are either based > in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting. > > regards, > > Ted Hardie, for the chairs. From stewe@stewe.org Thu Apr 12 11:20: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 D730521F85BD for ; Thu, 12 Apr 2012 11:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, J_CHICKENPOX_19=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 K93ZFU3foFb8 for ; Thu, 12 Apr 2012 11:20:23 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4C25821F85B5 for ; Thu, 12 Apr 2012 11:20:22 -0700 (PDT) Received: from mail43-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 18:20:21 +0000 Received: from mail43-db3 (localhost [127.0.0.1]) by mail43-db3-R.bigfish.com (Postfix) with ESMTP id 51676E04F5; Thu, 12 Apr 2012 18:20:21 +0000 (UTC) X-SpamScore: -33 X-BigFish: PS-33(zz168aJdf9M1432N98dKzz1202h1082kzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail43-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=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail43-db3 (localhost.localdomain [127.0.0.1]) by mail43-db3 (MessageSwitch) id 1334254819236346_12379; Thu, 12 Apr 2012 18:20:19 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.235]) by mail43-db3.bigfish.com (Postfix) with ESMTP id 32E17C00FF; Thu, 12 Apr 2012 18:20:19 +0000 (UTC) Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 18:20:17 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.23]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0143.004; Thu, 12 Apr 2012 18:19:51 +0000 From: Stephan Wenger To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Resolution negotiation - a contribution Thread-Index: AQHNGIi2N3AyBdvLYU+ocbL9B79QTJaXC0UA Date: Thu, 12 Apr 2012 18:19:51 +0000 Message-ID: In-Reply-To: <4F869648.2020605@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: <04526E7DCB753747BB38D31CED16E5EE@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 18:20:24 -0000 Hi Harald, Thanks for this strawman. I believe it should work, but I fail to see how a two dimensional negotiation requirement (negotiating max values for framerate and image size--which, in turn, also has two-dimensional properties) leads to better interop than a one dimensional negotiation (pixels per second processing requirement). Let alone a one dimensional negotiation with a fragmented value space and constraints imposed an maxima and minima for both resolution and frame rates to values that represent common operation points (such as MPEG-style levels). Actually, I fail to see ANY positive aspect, except perhaps that dimension/framerate may be a bit more intuitive than processing power demands. This goes for both the API and the protocol. One can argue a lot about the value of MPEG's profiles in today's software implementation world (and people do, myself included). But the level concept appears to make sense to me. As a side note, something along the lines of CLUE's simultaneous transmission sets concept (or however that thing is currently called; I lost track) would also be beneficial for a system that is inherently capable of displaying multiple video signals, such as a web browser. Regards, Stephan On 4.12.2012 01:46 , "Harald Alvestrand" wrote: >Hello folks, > >after the IETF, I've attempted to gather together information about >resolution negotiation and what we might need to do there. > >I pulled together the paragraphs below - this may want to be >incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go >somewhere else. Chairs' guidance is appreciated. > >At the moment, I have it in xml2rfc format, so it should be easy to do >cut-and-paste on it, but don't want to push it as a separate I-D unless >that's what the chairs desire. >Note - there are some QUERY sections in there - I'm unsure what those >should be resolved to. > >Comments? > > Harald > >2. Requirements > > The relevant requirement for video resolution negotiation from the > RTCWEB use cases document > [I-D.ietf-rtcweb-use-cases-and-requirements] is: > > o F25 The browser SHOULD use encoding of streams suitable for the > current rendering (e.g. video display size) and SHOULD change > parameters if the rendering changes during the session. > > The resulting need is: > > o To negotiate a maximum spatial resolution for all videos at call > setup time > > o To negotiate a maximum temporal resolution ("frame rate") across > all videos at call setup time > > o To indicate the desire of the recipient for a particular spatial > or temporal resolution on a particular video source > > o To indicate the intent of the sender to send a video source in a > particular spatial or temporal resolution > > This document does not mention other requirements. > > >3. SDP negotiation of video resolution > > An RTCWEB client MUST support negotiation of resolution using the > "imageattr" attribute, as documented in [RFC6236]. > > An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and > MAY choose to support only the 1.0 value of the "sar" attribute. > > The interpretation of the negotiation is that any video stream in the > m=3D line containing the a=3Dimageattr attribute will have a resolutio= n > within the bounds established by the negotiation. > > An RTCWEB client MUST support negotiation of the "a=3Dframerate" > attribute, as specified in [RFC4566] section 6. Note that this is an > upper bound on framerate; there is no lower bound negotiated. > > These requirements are necessary and sufficient for establishing the > maximum spatial and temporal resolution for all videos at call setup > time. These bounds MAY be renegotiated over the course of the call, > but MUST NOT be renegotiated to render any currently transmitted > video stream out of bounds; the sending video stream MUST first be > changed to be of a resolution that fits within both the old and the > new bounds, or halted. < restriction???>> > > An RTCWEB client MUST support per-SSRC requests for video > resolutions, as described in > [I-D.lennox-mmusic-sdp-source-selection]. This satisfies the > requirement to indicate the desire of the recipient for a particular > spatial or temporal resolution. > > We assume that the media sent from a sender to a receiver contains > enough information inside the media format to tell what the > resolution and framerate is. < with an "imageattr" or "framerate" attribute in the forward direction > instead?>> > > >4. Non-SDP negotiation of video resolution > > An RTCWEB client MAY support the COP mechanism > [I-D.westerlund-avtext-codec-operation-point] to negotiate the > resolution of video within the limits established by the SDP > negotiation without the need for additional SDP exchanges. > > >5. Relation to WebRTC API constraint > > It is intended that the resolution negotiation be influenced by the > constraints set by the application of either mandatory or optional > constraints at the WebRTC API, as registered in the registry > established by [I-D.burnett-rtcweb-constraints-registry]. > > The following relationships hold for all attributes that the > implementation intends to satisfy (note that the constraints listed > here have NOT been registered yet): > > video-min-height >=3D value of imageattr y=3D xyrange lower bound > > video-max-height <=3D value of imageattr y=3D xyrange upper bound > > video-min-framerate is not represented in SDP > > video-max-framerate <=3D value of a=3Dframerate attribute > > video-min-aspect-ratio <=3D value of imageattr "par=3D" prange lower > bound > > video-max-aspect-ratio >=3D value of imageattr "par=3D" prange upper > bound > > The implementation is free to increase "min" values or decrease "max" > values (make requirements more restrictive) and add "step" in order > to fit with its implementation restrictions. < of the direction of those assumptions>>. > > Constraints specified at PeerConnection creation time are reflected > as SDP-wide values. Constraints specified when creating a > MediaStream or attaching a MediaStream to a PeerConnection are > reflected as ssrc-specific values. > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Thu Apr 12 12:08: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 5F7AA21F8686 for ; Thu, 12 Apr 2012 12:08:10 -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 1oCYnTjSGqSi for ; Thu, 12 Apr 2012 12:08:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5321F854A for ; Thu, 12 Apr 2012 12:08:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2139939E0A7; Thu, 12 Apr 2012 21:08:07 +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 HXOp0xxHAGz4; Thu, 12 Apr 2012 21:08:06 +0200 (CEST) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6D4CD39E082; Thu, 12 Apr 2012 21:08:06 +0200 (CEST) Message-ID: <4F872816.6080309@alvestrand.no> Date: Thu, 12 Apr 2012 21:08:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 19:08:10 -0000 On 04/12/2012 08:19 PM, Stephan Wenger wrote: > Hi Harald, > Thanks for this strawman. I believe it should work, but I fail to see how > a two dimensional negotiation requirement (negotiating max values for > framerate and image size--which, in turn, also has two-dimensional > properties) leads to better interop than a one dimensional negotiation > (pixels per second processing requirement). Stephan, I do not see this (or the requirement from the use-cases document) first and foremost a decoder complexity negotiation; it is a negotiation of how much data it is useful to send, given the recipient's intended use of that data. For instance, in Google+ Hangouts, we use a similar function to make sure the participants who are not currently displayed in large format on anyone's screen only send the data needed to display the "thumbnail"; this represents a huge saving in bandwidth at our central servers. It just happens that the decoding complexity of the VP8 codec is sufficiently linear with the number of pixels displayed that we don't see any advantage in encumbering the negotiation of that codec with extra features like "profiles" - but that's a discussion for PAYLOAD, not RTCWEB. From stewe@stewe.org Thu Apr 12 14:14: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 9622221F871A for ; Thu, 12 Apr 2012 14:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-1.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 oHcmbxvlzv0G for ; Thu, 12 Apr 2012 14:14:13 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1FC21F870E for ; Thu, 12 Apr 2012 14:14:13 -0700 (PDT) Received: from mail49-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 21:14:12 +0000 Received: from mail49-va3 (localhost [127.0.0.1]) by mail49-va3-R.bigfish.com (Postfix) with ESMTP id BC94E4401AA; Thu, 12 Apr 2012 21:14:12 +0000 (UTC) X-SpamScore: -8 X-BigFish: PS-8(zzbb2dI9371I1432N98dKzz1202h1082kzzz2fh2a8h668h839h944h) 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 Received-SPF: pass (mail49-va3: 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 mail49-va3 (localhost.localdomain [127.0.0.1]) by mail49-va3 (MessageSwitch) id 1334265249914189_27251; Thu, 12 Apr 2012 21:14:09 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.245]) by mail49-va3.bigfish.com (Postfix) with ESMTP id D4FEA400A7; Thu, 12 Apr 2012 21:14:09 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 21:14:09 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.23]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0143.004; Thu, 12 Apr 2012 21:13:38 +0000 From: Stephan Wenger To: Harald Alvestrand Thread-Topic: [rtcweb] Resolution negotiation - a contribution Thread-Index: AQHNGIi2N3AyBdvLYU+ocbL9B79QTJaXC0UAgACC2AD//622gA== Date: Thu, 12 Apr 2012 21:13:38 +0000 Message-ID: In-Reply-To: <4F872816.6080309@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolution negotiation - a contribution 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 Apr 2012 21:14:14 -0000 On 4.12.2012 12:08 , "Harald Alvestrand" wrote: >On 04/12/2012 08:19 PM, Stephan Wenger wrote: >> Hi Harald, >> Thanks for this strawman. I believe it should work, but I fail to see >>how >> a two dimensional negotiation requirement (negotiating max values for >> framerate and image size--which, in turn, also has two-dimensional >> properties) leads to better interop than a one dimensional negotiation >> (pixels per second processing requirement). >Stephan, > >I do not see this (or the requirement from the use-cases document) first >and foremost a decoder complexity negotiation; it is a negotiation of >how much data it is useful to send, given the recipient's intended use >of that data. Then such a negotiation should be executed in addition. Decoder cycle requirement do matter in practical implementations. > >For instance, in Google+ Hangouts, we use a similar function to make >sure the participants who are not currently displayed in large format on >anyone's screen only send the data needed to display the "thumbnail"; >this represents a huge saving in bandwidth at our central servers. Oh, absolutely. I'm all in favor of resolution adaptation based on receiver (population) requirements. But only after an upper limit is established (that could be based on many factors, including screen size, connectivity, and computational resources (sic!). > >It just happens that the decoding complexity of the VP8 codec is >sufficiently linear with the number of pixels displayed that we don't >see any advantage in encumbering the negotiation of that codec with >extra features like "profiles" - but that's a discussion for PAYLOAD, >not RTCWEB. True, agreed, and not what I was arguing about. Stephan > > From harald@alvestrand.no Fri Apr 13 00:45: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 A7F3C21F86C4 for ; Fri, 13 Apr 2012 00:45:53 -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 Fb4LqkC5Ny6r for ; Fri, 13 Apr 2012 00:45:53 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0648B21F8655 for ; Fri, 13 Apr 2012 00:45:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1188939E0F3; Fri, 13 Apr 2012 09:45:52 +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 AOuZwazHaJL5; Fri, 13 Apr 2012 09:45:51 +0200 (CEST) Received: from [192.168.11.107] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3EA0939E088; Fri, 13 Apr 2012 09:45:51 +0200 (CEST) Message-ID: <4F87D9B1.4000206@alvestrand.no> Date: Fri, 13 Apr 2012 09:45:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Resolution negotiation - a contribution 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, 13 Apr 2012 07:45:53 -0000 On 04/12/2012 11:13 PM, Stephan Wenger wrote: > > On 4.12.2012 12:08 , "Harald Alvestrand" wrote: > >> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>> Hi Harald, >>> Thanks for this strawman. I believe it should work, but I fail to see >>> how >>> a two dimensional negotiation requirement (negotiating max values for >>> framerate and image size--which, in turn, also has two-dimensional >>> properties) leads to better interop than a one dimensional negotiation >>> (pixels per second processing requirement). >> Stephan, >> >> I do not see this (or the requirement from the use-cases document) first >> and foremost a decoder complexity negotiation; it is a negotiation of >> how much data it is useful to send, given the recipient's intended use >> of that data. > Then such a negotiation should be executed in addition. Decoder cycle > requirement do matter in practical implementations. Feel free to propose language that captures this requirement. As noted, my I-D fragment doesn't. From magnus.westerlund@ericsson.com Fri Apr 13 04:06: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 9080D21F85E4 for ; Fri, 13 Apr 2012 04:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 zafZfyobHMem for ; Fri, 13 Apr 2012 04:06:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9865221F85D4 for ; Fri, 13 Apr 2012 04:06:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-97-4f8808a1118b Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E2.9B.25560.1A8088F4; Fri, 13 Apr 2012 13:06:09 +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.213.0; Fri, 13 Apr 2012 13:06:08 +0200 Message-ID: <4F88089F.2070906@ericsson.com> Date: Fri, 13 Apr 2012 13:06:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Draft minutes for Wednesday session of IETF 83 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, 13 Apr 2012 11:06:14 -0000 WG, I have uploaded a first version of minutes for the first WG session in Paris. Please review so that the minutes accurately reflects your activities in the WG meeting session. http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.htm 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 Apr 13 04:33: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 32E9C21F8763 for ; Fri, 13 Apr 2012 04:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=0.057, 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 t57hC3yIlsSG for ; Fri, 13 Apr 2012 04:33:56 -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 73FFA21F875C for ; Fri, 13 Apr 2012 04:33:56 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1726344yhk.31 for ; Fri, 13 Apr 2012 04:33:56 -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=NT86fZs3y/LsESxErvEpqrxZM9PxUeNNjP6GvLW0ThM=; b=lqnNo7Wu9ZqTkVgUdESSv+advcVfDdvWlBc0vGtuSv3Bg9Ihy7z/9FRzH4O5zCL3G/ ljP2Qb5mCMCsyy9ZHPDGxJYAU0PRaSkNWfV9dZARhfixWk/suPWv+Jb5QXGQCHllPdp5 /nnUgM6CAUL0g+B42KN5nZpRYpHL86l6IaRkbIdv710btQcY1G7mzn2KTmQeZ7x5Tos8 yD9khrNr6kmoq0Nzy8/NOEmZJwD+pJrj9sVGl4uH9h2JUMnWRAGNIk969872zxa8n7bJ NVvJTQwPvpah8lY1kuOWD3cITsU/HmNS3aEgNDkRtnSKV7RLU50Ic59TUSDSTaOR5iE3 g1xA== Received: by 10.101.3.6 with SMTP id f6mr393676ani.7.1334316836024; Fri, 13 Apr 2012 04:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.7 with HTTP; Fri, 13 Apr 2012 04:33:35 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Apr 2012 13:33:35 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlsNwQIjCoElD7+tRQvvAXIP1voLA/+08B9qj/ecUGb9VNGagbm9QkSOwfbkly0sqGIaWNz Subject: [rtcweb] Just browser-browser and browser-"gateway"? is this an RTCweb assumption? 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, 13 Apr 2012 11:33:57 -0000 Hi, by reading RTCWeb Minutes IETF 83 [1] it seems that most of the folks here assume that WebRTC *media* communication can be done in two ways: 1) browser to browser (perhaps with a TURN server) 2) browser to gateway So... what about browser to SIP phone and browser to XMPP/Jingle endpoint (assuming ICE and SDES-SRTP support)? IMHO assuming that a media gateway is required for any browser to non-browser media communication is an artificial limitation. If so, why does RTCweb makes use of RTP and SDP? why not creating its own "media streaming protocol for RTCweb"? I hope this subject is clarified and such an assumption relaxed. Interoperability (*whithout* media gateways) is a good feature and makes RTCweb adoption easier. Not all the people interested in RTCweb are gateways vendors. NOTE: I do *not* mean supporting plain and insecure RTP. Regards. [1] http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.htm --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Fri Apr 13 04:39: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 7068D21F8763 for ; Fri, 13 Apr 2012 04:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 hRoklro30veb for ; Fri, 13 Apr 2012 04:39:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6673A21F875C for ; Fri, 13 Apr 2012 04:39:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 775E339E0C0 for ; Fri, 13 Apr 2012 13:39:07 +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 EF8L7gk2p0Ja for ; Fri, 13 Apr 2012 13:39:06 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DBB4539E088 for ; Fri, 13 Apr 2012 13:39:06 +0200 (CEST) Message-ID: <4F88105A.3060105@alvestrand.no> Date: Fri, 13 Apr 2012 13:39:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 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 Subject: Re: [rtcweb] Just browser-browser and browser-"gateway"? is this an RTCweb assumption? 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, 13 Apr 2012 11:39:09 -0000 On 04/13/2012 01:33 PM, Iñaki Baz Castillo wrote: > Hi, by reading RTCWeb Minutes IETF 83 [1] it seems that most of the > folks here assume that WebRTC *media* communication can be done in two > ways: > > 1) browser to browser (perhaps with a TURN server) > 2) browser to gateway > > So... what about browser to SIP phone and browser to XMPP/Jingle > endpoint (assuming ICE and SDES-SRTP support)? From -overview section 3: As for all protocol and API specifications, there is no restriction that the protocols can only be used to talk to another browser; since they are fully specified, any device that implements the protocols faithfully should be able to interoperate with the application running in the browser. Not all of us have been making the assumption you cite. > IMHO assuming that a media gateway is required for any browser to > non-browser media communication is an artificial limitation. If so, > why does RTCweb makes use of RTP and SDP? why not creating its own > "media streaming protocol for RTCweb"? > > I hope this subject is clarified and such an assumption relaxed. > Interoperability (*whithout* media gateways) is a good feature and > makes RTCweb adoption easier. Not all the people interested in RTCweb > are gateways vendors. > > NOTE: I do *not* mean supporting plain and insecure RTP. I agree, and that's the way the documents have been written "forever". But the burden is 1) on the RTCWEB group to define what the protocols are, and 2) on the other devices to conform to those protocols. Harald From roman@telurix.com Fri Apr 13 04:39: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 5EF3521F87D7 for ; Fri, 13 Apr 2012 04:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.027, 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 gkMfYh4oWXmn for ; Fri, 13 Apr 2012 04:39:18 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 61DB721F87D5 for ; Fri, 13 Apr 2012 04:39:18 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2445791wib.13 for ; Fri, 13 Apr 2012 04:39: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=PPrgsajOJANZVfMOMnUEikTjDe76ffiHY6WLENCfhmk=; b=PEqSH84W9KMkrl+fRtj2CUXmX0beCQXdsnpdLSTPnsBtMqQ7popcOYmZLlzZ71q9N0 im66bzIzGHdy6iGOOQNiFDctUKi4MAHqJwausqyv9tm05DIdMb0t84afLtPavaRcsAfC ZMGjIwn9WChtm+GqPnF8Ux9OB+DnhXqTQBB3R4OEdV79EcX5zI5n5IEvbMxcI79jClHB LM7/Gw9QhvbFJJmwMye9rTQt5Oflngbs9HKLYMecFEgFLfS41RszXGDm8QIxljXuEuXE E3Rc77jjeXCCB8WftkxoCgF9mNqIpu/55Mko5ClaMt0jAQBWx1BqvkLuom49B8IPMe/o ZPUw== Received: by 10.216.139.79 with SMTP id b57mr746389wej.37.1334317157560; Fri, 13 Apr 2012 04:39:17 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id ex2sm7085760wib.8.2012.04.13.04.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 04:39:16 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2842142bku.31 for ; Fri, 13 Apr 2012 04:39:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.126.14 with SMTP id gu14mr363361bkc.57.1334317155309; Fri, 13 Apr 2012 04:39:15 -0700 (PDT) Received: by 10.204.61.133 with HTTP; Fri, 13 Apr 2012 04:39:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Apr 2012 07:39:15 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cdfdb520f590104bd8dec1a X-Gm-Message-State: ALoCoQn12JEWxtk70Eh0h7BOI4gnWXo5dC1CaHWUiqvadMMhE7IQmoU4VrW4c5cGu6lULDYfjzC/ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Just browser-browser and browser-"gateway"? is this an RTCweb assumption? 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, 13 Apr 2012 11:39:19 -0000 --000e0cdfdb520f590104bd8dec1a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What about browser to a media server? Does anybody want to do, for instance, video upload from the browser to a video sharing site? _____________ Roman Shpount On Fri, Apr 13, 2012 at 7:33 AM, I=F1aki Baz Castillo wrote= : > Hi, by reading RTCWeb Minutes IETF 83 [1] it seems that most of the > folks here assume that WebRTC *media* communication can be done in two > ways: > > 1) browser to browser (perhaps with a TURN server) > 2) browser to gateway > > So... what about browser to SIP phone and browser to XMPP/Jingle > endpoint (assuming ICE and SDES-SRTP support)? > > IMHO assuming that a media gateway is required for any browser to > non-browser media communication is an artificial limitation. If so, > why does RTCweb makes use of RTP and SDP? why not creating its own > "media streaming protocol for RTCweb"? > > I hope this subject is clarified and such an assumption relaxed. > Interoperability (*whithout* media gateways) is a good feature and > makes RTCweb adoption easier. Not all the people interested in RTCweb > are gateways vendors. > > NOTE: I do *not* mean supporting plain and insecure RTP. > > Regards. > > > > [1] http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.htm > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000e0cdfdb520f590104bd8dec1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What about browser to a media server? Does anybody want to do, for instance= , video upload from the browser to a video sharing site?
= _____________
Roman Shpount


On Fri, Apr 13, 2012 at 7:33 AM, I=F1aki= Baz Castillo <ibc@al= iax.net> wrote:
Hi, by reading RTCWeb Minutes IETF 83 [1] it seems that most of the
folks here assume that WebRTC *media* communication can be done in two
ways:

=A01) browser to browser (perhaps with a TURN server)
=A02) browser to gateway

So... what about browser to SIP phone and browser to XMPP/Jingle
endpoint (assuming ICE and SDES-SRTP support)?

IMHO assuming that a media gateway is required for any browser to
non-browser media communication is an artificial limitation. If so,
why does RTCweb makes use of RTP and SDP? why not creating its own
"media streaming protocol for RTCweb"?

I hope this subject is clarified and such an assumption relaxed.
Interoperability (*whithout* media gateways) is a good feature and
makes RTCweb adoption easier. Not all the people interested in RTCweb
are gateways vendors.

NOTE: I do *not* mean supporting plain and insecure RTP.

Regards.



[1] http://www.ietf.org/proceedings/83/minutes/minutes-= 83-rtcweb.htm

--
I=F1aki Baz Castillo
<ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--000e0cdfdb520f590104bd8dec1a-- From ibc@aliax.net Fri Apr 13 04: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 635E421F8763 for ; Fri, 13 Apr 2012 04:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055, 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 86xGVJryJ5pG for ; Fri, 13 Apr 2012 04:55:15 -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 D958A21F875C for ; Fri, 13 Apr 2012 04:55:14 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1734498yhk.31 for ; Fri, 13 Apr 2012 04:55:14 -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=+HRGt9/qEcVNE1+9uEqYpys/nv7aIg8XNEdRTVGOLNU=; b=KcKhIqBtslNs+XZvEAPOAnsx9kXWVbqbpsGEsABQPfI5qm0h/dr+OQvoAvuke8g3Jj 9yeU+a+46LOXG0EAFIcOVdNmMTbbegF4naZyeXQ4BpDRkLaWenfPgh/kF5dmfdU5I1ms SG8bWeVZIKSjre11YonWl4E3bA2IC+oUYBYEIt0fMO8SoJ37n8/S7gp0E6WVIyae2WPJ UKvq7rDxEFBerCbHZqT3G0hxlLm20Pun0dlp+FqP5Y4vlOzg5NEDOWQmL0F++xhzLr31 SRo00OcUp3r5i/mzUUmzej4Lhkist5m0whDoW/5y/Vh47wAAip1ByjC8Rwxo2GiNeWOo OwXw== Received: by 10.236.143.106 with SMTP id k70mr1267587yhj.38.1334318114354; Fri, 13 Apr 2012 04:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.7 with HTTP; Fri, 13 Apr 2012 04:54:54 -0700 (PDT) In-Reply-To: <4F88105A.3060105@alvestrand.no> References: <4F88105A.3060105@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 13 Apr 2012 13:54:54 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmA0P+3mrePL8GpMMKyOyo3s5iJ/kVhhjjjBomIFi2GF2Tu1qTFFxNGXVbAvNRKclpJquyd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Just browser-browser and browser-"gateway"? is this an RTCweb assumption? 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, 13 Apr 2012 11:55:15 -0000 2012/4/13 Harald Alvestrand : > But the burden is 1) on the RTCWEB group to define what the protocols are= , > and 2) on the other devices to conform to those protocols. Right. But the more *new* RTCweb media specifications are required, the harder it will interoperate with other protocols. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Fri Apr 13 04: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 9695921F8763 for ; Fri, 13 Apr 2012 04:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 1i50wYDUtvwg for ; Fri, 13 Apr 2012 04:59:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0854021F871E for ; Fri, 13 Apr 2012 04:59:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 434A039E0F3; Fri, 13 Apr 2012 13:59:32 +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 3WIVJC2o6FHa; Fri, 13 Apr 2012 13:59:31 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AE4E039E088; Fri, 13 Apr 2012 13:59:31 +0200 (CEST) Message-ID: <4F881523.1080704@alvestrand.no> Date: Fri, 13 Apr 2012 13:59:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Roman Shpount References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Just browser-browser and browser-"gateway"? is this an RTCweb assumption? 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, 13 Apr 2012 11:59:33 -0000 On 04/13/2012 01:39 PM, Roman Shpount wrote: > What about browser to a media server? Does anybody want to do, for > instance, video upload from the browser to a video sharing site? Not necessarily real-time, so may be out of scope for RTCWEB, but people are definitely interested. For those who want to read about scenarios that don't necessarily involve real-time communication, but will most probably involve getUserMedia, I recommend this document: https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html It's being used to drive requirements on the getUserMedia API in the W3C. Harald From Jim.Barnett@genesyslab.com Fri Apr 13 05:50: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 7239221F8633 for ; Fri, 13 Apr 2012 05:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 I7L+FgxLa90s for ; Fri, 13 Apr 2012 05:50:33 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id 386A021F8629 for ; Fri, 13 Apr 2012 05:50:33 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q3DCoQZO014761; Fri, 13 Apr 2012 05:50:31 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 05:50:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1973.FFC20721" Date: Fri, 13 Apr 2012 05:50:19 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Just browser-browser and browser-"gateway"? is this an RTCweb assumption? Thread-Index: Ac0ZahRWaGLgQTo0TXu5s4bVO4wR5wACXXmA References: From: "Jim Barnett" To: "Roman Shpount" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-OriginalArrivalTime: 13 Apr 2012 12:50:26.0769 (UTC) FILETIME=[FFD4EC10:01CD1973] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Just browser-browser and browser-"gateway"? is this an RTCweb assumption? 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, 13 Apr 2012 12:50:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1973.FFC20721 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There's a W3C group that is interested in this, in the form of speech = enabling HTML 5 pages (i.e. adding text-to-speech and speech-to-text = capabilities). We are hoping to use the rtcweb work as part of this. = We'd have a browser one end, a media/IVR server on the other, and voice = and data channels. There's been no specific mention of video so far, = but I don't see any reason why it couldn't be added. =20 - Jim =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Roman Shpount Sent: Friday, April 13, 2012 7:39 AM To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Just browser-browser and browser-"gateway"? is = this an RTCweb assumption? =20 What about browser to a media server? Does anybody want to do, for = instance, video upload from the browser to a video sharing site?=20 _____________ Roman Shpount On Fri, Apr 13, 2012 at 7:33 AM, I=F1aki Baz Castillo = wrote: Hi, by reading RTCWeb Minutes IETF 83 [1] it seems that most of the folks here assume that WebRTC *media* communication can be done in two ways: 1) browser to browser (perhaps with a TURN server) 2) browser to gateway So... what about browser to SIP phone and browser to XMPP/Jingle endpoint (assuming ICE and SDES-SRTP support)? IMHO assuming that a media gateway is required for any browser to non-browser media communication is an artificial limitation. If so, why does RTCweb makes use of RTP and SDP? why not creating its own "media streaming protocol for RTCweb"? I hope this subject is clarified and such an assumption relaxed. Interoperability (*whithout* media gateways) is a good feature and makes RTCweb adoption easier. Not all the people interested in RTCweb are gateways vendors. NOTE: I do *not* mean supporting plain and insecure RTP. Regards. [1] http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.htm -- I=F1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CD1973.FFC20721 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

There’s a W3C group that=A0 is interested in this, in the form = of speech enabling HTML 5 pages (i.e. adding text-to-speech and=A0 = speech-to-text capabilities). =A0We are hoping to use the rtcweb work as = part of this.=A0 We’d have a browser one end, a media/IVR server = on the other, and voice and data channels.=A0 There’s been no = specific mention of=A0 video so far, but I don’t see any reason = why it couldn’t=A0 be added.

 

-          = Jim

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Friday, April 13, 2012 7:39 = AM
To: I=F1aki Baz Castillo
Cc: = rtcweb@ietf.org
Subject: Re: [rtcweb] Just browser-browser and = browser-"gateway"? is this an RTCweb = assumption?

 

What about browser to a media server? = Does anybody want to do, for instance, video upload from the browser to = a video sharing site?
_____________
Roman = Shpount

On Fri, Apr 13, = 2012 at 7:33 AM, I=F1aki Baz Castillo <ibc@aliax.net> = wrote:

Hi, by reading RTCWeb Minutes = IETF 83 [1] it seems that most of the
folks here assume that WebRTC = *media* communication can be done in two
ways:

 1) = browser to browser (perhaps with a TURN server)
 2) browser to = gateway

So... what about browser to SIP phone and browser to = XMPP/Jingle
endpoint (assuming ICE and SDES-SRTP = support)?

IMHO assuming that a media gateway is required for any = browser to
non-browser media communication is an artificial = limitation. If so,
why does RTCweb makes use of RTP and SDP? why not = creating its own
"media streaming protocol for = RTCweb"?

I hope this subject is clarified and such an = assumption relaxed.
Interoperability (*whithout* media gateways) is a = good feature and
makes RTCweb adoption easier. Not all the people = interested in RTCweb
are gateways vendors.

NOTE: I do *not* = mean supporting plain and insecure = RTP.

Regards.



[1] http://www.ietf.org/proceedings/83/minutes/minutes-83-r= tcweb.htm

--
I=F1aki Baz = Castillo
<ibc@aliax.net>
__________________= _____________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb=

 

------_=_NextPart_001_01CD1973.FFC20721-- From marshall.eubanks@gmail.com Fri Apr 13 11:14: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 AEABA11E809B for ; Fri, 13 Apr 2012 11:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 lUcv6WDZQaew for ; Fri, 13 Apr 2012 11:14:59 -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 07BEE11E8093 for ; Fri, 13 Apr 2012 11:14:58 -0700 (PDT) Received: by lbbgf14 with SMTP id gf14so680957lbb.31 for ; Fri, 13 Apr 2012 11:14:58 -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=Lmmp95/kIjcJ7bDvOTbCwYBS5msJvm5nfOQoTOEBDzg=; b=Nb8SHczeazB8rLONIlNtK29xxNmAeOU0gibMSMxR1dfOcWiaPSUXJ2xyjmzduwsx3M JGOhp1Ur3Ws8GK4VXiVw9tacA4YT3uv1COlhRUsuORudJtckRYkMXv4nXdE8cqDRbAci LEmdaRJb+ERxVk1bFXeOSddki2MoTe8jAxcA6aU00edeB79+S3lYgjnwZS1DLQIGLboW khybnInTsG+v0fGx0DHMxTrxRgrePJy+pZlMkTTwUERqrJVy4KcxrsjYsjixWVE7erQL r9P+xlavg1Alh2yKrWyb21u/Ec8TJdzBEI0uLuYZf6n/FL45uiXYVP1/u+FxXvAiIhE0 Fufg== MIME-Version: 1.0 Received: by 10.112.30.102 with SMTP id r6mr1222512lbh.30.1334340897882; Fri, 13 Apr 2012 11:14:57 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Fri, 13 Apr 2012 11:14:57 -0700 (PDT) Date: Fri, 13 Apr 2012 14:14:57 -0400 Message-ID: From: Marshall Eubanks To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability 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, 13 Apr 2012 18:14:59 -0000 I am posting this to both CLUE and RTCWEB. I am not sure which (if either) WG would want to adopt it, but I think both should see it. If this gains traction, I will make sure both WG are kept abreast of developments. Regards Marshall RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability References : RTCWEB Use Cases and Requirements : http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-07.txt CLUE : Use Cases for Telepresence Multi-streams http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-02.txt What follows is a first-cut at use cases for interoperability between a browser based videoconferencing system and Telepresence videoconferencing. This is an attempt to describe what should be done, without specifying in detail how. I have seen all of the below in the field, with Cases 1-T, 1-R.c and 2-R.b being the most widely supported. These cases are similar to the 4.2.10 use case in ID.draft-ietf-rtcweb-use-cases-and-requirements, but of course in the telepresence scenario there is a set of CLUE semantics overlaid on the basic display of screens. In this scenario, the browser is more likely to require higher level protocol changes than the telepresence units but, of course, the telepresence units or middleware MUST be able to accommodate RTCWEB codec and signaling choices. Base scenario. There are one or more browser based videoconferencing systems and one or more telepresence systems (each with at least two cameras and two screens) participating in an immersive-telepresence videoconferencing session. This may or may not require middleware (a server or MCU) to accomplish, both use cases with and without middleware SHOULD be supported. The telepresence units themselves are assumed to use CLUE and underlying protocols to decide suitable bit rates, resolutions, etc., between themselves; intra-telepresence negotiations are not in scope for this text. In telepresence, "screen" and "stream" are used more or less interchangeably, and will be done so here. In the base scenario, there are thus at least 3 screens (streams); conferences with 9 or more streams are not unusual, and conferences with dozens or even hundreds of streams are a commercial reality. It is useful to divide use cases between Transmission (T, what the browser sends) and Reception (R, what it receives). Browser based units SHOULD be able to decide between transmission and reception use cases independently, depending on capabilities and user choices. Case 1 : The one screen use case. In Case 1, it is possible for a CLUE Telepresence session and a browser to interact without any knowledge of CLUE on the part of the browser (i.e., by a telepresence unit or middleware acting as a single point videoconferencing unit). Such "Clueless" conferencing sessions are not in scope for this text. Case 1-Transmission : The browser sends one screen at the screen characteristics of the participating telepresence units or, failing that, at the maximum resolution and bandwidth it is capable or authorized to do so. Likewise, audio SHOULD be sent at the bit rate and using the codec negotiated by the CLUE telepresence session. Case 1 audio SHOULD be sent in mono. The browser MUST be able to use CLUE to negotiate these characteristics (which may change with time), and SHOULD be able to provide whatever meta-data is required by CLUE (e.g., the user's name or location). The browser may be one complete screen in the remote telepresence units. If care is taken by the browser user and software (for example, by matching head size and camera angle compared to the standards of the participating telepresence units, together with sufficient audio and video quality and resolution), the browser image and sound may approach immersive telepresence on the remote ends. (It would be useful if the system provided feedback or even automated zoom in/out to help with this adjustment for remote immersion. I have seen this done manually, but this has not to my knowledge been discussed to date in CLUE.) In the case of lower quality browser transmitted video, the receiving telepresence units may chose to display such videos in a composited form, with multiple browser transmissions sharing one screen. (This is common with low quality video from multiple browser-based participants.) Case 1-Reception : The browser displays one screen for all of the remote telepresence units. The browser receives one screen at the screen characteristics of the participating telepresence units or, failing that, at the maximum resolution and bandwidth it is capable of. Likewise, it SHOULD be able to receive audio at the bit rate and using the codec negotiated by the CLUE telepresence session. The browser MUST be able to negotiate these characteristics (which may change with time) using CLUE. In all Case 1-R sub cases, the browser MAY also display "thumbnail" (i.e., substantially reduced) images of other screens. These thumbnails might be shown for all screens, or for recently active screens (e.g., the last speaker), or for some static choice (e.g., the conference chair). The browser SHOULD be able to signal its desire / need to receive such thumbnails. Sub Case 1-R a : Static. The browser displays one screen only, as selected by the user or by some other method. (A simultaneous translator, for example, may prefer only to see the screen attached to their assigned speaker, regardless of whether or not they are speaking.) Sub Case 1-R b : Switching. The browser displays the "active" stream, typically of the current speaker. The browser MUST be able to switch rapidly between resolutions and other stream configuration choices, say if the active screen switches between a telepresence unit and another browser's transmission. Sub Case 1-R c : Compositing. The browser displays one screen, consisting of a static compositing of all (or conceivably a selection) of the other screens. This MAY indicate the active speaker (say, by highlighting them) and MAY display composited metadata (such as the attendees in each sub-screen, or their location). (If this display is an NxM matrix of equal size sub-screens, this display type is frequently called "Hollywood Squares," but other choices are possible.) In general this will be a static screen assignment, which MAY change with time (e.g., as participants come and go from the conference). This compositing could be done by the browser, but in current practice will most likely be done by either a telepresence unit or by middleware. Case 2 : Multiple Screens. The browser sends and/or receives multiple screens at the maximum resolution and bandwidth it is capable or authorized to do so. (This case is NOT intended to cover "thumbnail" sub screens, which may be sent or received in this case as well.) Case 2-Transmission. The browser has access to multiple cameras and sends multiple images to remote participants. If care is taken by the browser user / software, the browser images may approach immersive telepresence on the remote ends. For this to happen in the multi-screen transmission case, the browser MUST be able to fully participate in CLUE protocol negotiations, identifying, for example, which screen is left, center and right in the case of a three camera transmission. In Case 2-T, the browser SHOULD send stereo or multi-channel audio and SHOULD format any such audio to match the transmitted screens, e.g., with the left audio corresponding to the left screen. Such audio choices, if made, MUST be indicated in the CLUE configuration setup. Case 2-Reception. The browser displays multiple screens based on the multiple screens available from other telepresence participants. Sub Case 2-R a : Switched compositing. In this use case typically one composited screen is shown, of some or all of the telepresence participants, together with one or more full-sized screens of the active participants (or, at times, of one static screen. Note that the composited screens may have higher sub-screen resolution than for thumbnails, or may have very different aspect ratios than is typical for thumbnails. For example, a three screen telepresence unit, with an individual screen aspect ratio of 16:9, may transmit a 48:9 aspect ratio composite of all its screens in the proper display order. Several such composites could be combined into a single 16:9 aspect ratio to make the composited screen in this use case. This use case includes multiple screens for selected speakers, for example a composited screen to the left, the conference moderator in larger resolution in the center, and (also in larger resolution) the current or previous speaker (should the moderator be currently speaking) on the right. In Case 2-R a, the browser SHOULD display screens and use stereo or multi-channel audio conforming to the CLUE configuration, with (in the above example), the conference moderator being assigned the center audio channel and the current or previous speaker the right audio channel. Sub Case 2-R b : Telepresence mimicry. The browser displays screens as if it were a telepresence unit involved in the telepresence session. The browser MUST be able to fully participate in the CLUE protocol, displaying, for example, left screens on the left and center screens on the center. In general, these screens will be displayed at the same aspect ratio, but with lower size / resolution, than in the full telepresence session. Experience shows that, for participants who are used to multi-screen telepresence, even lesser quality telepresence mimicry is very popular and RTCWEB / CLUE SHOULD support this full telepresence functionality. At the high end of browser capabilities, the full resolution and bit rates available could be used to approach a truly immersive telepresence at the browser receive side; this is likely to become more common in the future. In Case 2-R b, the browser SHOULD display screens and stereo or multi-channel audio conforming to the CLUE configuration, with, e.g., the left audio channel corresponding to the left screen, etc. From ibc@aliax.net Fri Apr 13 13:49: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 0029621F86EF for ; Fri, 13 Apr 2012 13:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.053, 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 RUg5zQPmx1mf for ; Fri, 13 Apr 2012 13:49:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0586F21F86EE for ; Fri, 13 Apr 2012 13:49:53 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2782178vcb.31 for ; Fri, 13 Apr 2012 13:49:53 -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=YCZ93+ZFAd4TO4uH4WK5Yay62PBfrMotrWddxYCPMDs=; b=Q5sWTG3WjkhWU6LxtGyfjxfH/LTL4DjepYtw4L6TqQ6qKVQEl5iqWxBmEK/qoqKSSC Abe7mIdGa5vJ4IlFcDb7aw1kUh3KMYWOCITm7LggpfDj/uMuQ53/j1UohQarrB997ieq L72BgLUsteCoMI8zuy566B/aKp5eNlBdFrC87kfKx747ANM4bAe/UBi9AR6gRAZaJ5Mk Ozj46y7FGorCtDNnbys69S8KRoy68p5kQJ6x8vDBec0uZM1ME1BvSOI+dly71whDyBm+ UcIO1G1GxM9PagOFRuAU5hkX9aZuuVnNInTuPXSJub3h4Ei2P2SFO15ZNCNmPoZ1FNaJ lV1Q== MIME-Version: 1.0 Received: by 10.220.49.66 with SMTP id u2mr1644487vcf.2.1334350193391; Fri, 13 Apr 2012 13:49:53 -0700 (PDT) Received: by 10.52.170.165 with HTTP; Fri, 13 Apr 2012 13:49:53 -0700 (PDT) Received: by 10.52.170.165 with HTTP; Fri, 13 Apr 2012 13:49:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Apr 2012 22:49:53 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Marshall Eubanks Content-Type: multipart/alternative; boundary=14dae9cdc7f148782a04bd959d91 X-Gm-Message-State: ALoCoQn4MsT4vKh0RV0jArTMzwFS4SF1Wg3HcUrxbzcYUDgktq+D57548lEHanwnsUhXhM9uavBn Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability 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, 13 Apr 2012 20:49:55 -0000 --14dae9cdc7f148782a04bd959d91 Content-Type: text/plain; charset=UTF-8 Hi, an easy question... What does it mean CLUE? --14dae9cdc7f148782a04bd959d91 Content-Type: text/html; charset=UTF-8

Hi, an easy question... What does it mean CLUE?

--14dae9cdc7f148782a04bd959d91-- From marshall.eubanks@gmail.com Fri Apr 13 13:59: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 0853D21F8741 for ; Fri, 13 Apr 2012 13:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, 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 mrGwWLyjbsvw for ; Fri, 13 Apr 2012 13:59:14 -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 9A59121F8740 for ; Fri, 13 Apr 2012 13:59:11 -0700 (PDT) Received: by lagj5 with SMTP id j5so2915752lag.31 for ; Fri, 13 Apr 2012 13:59: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=m+Yd23pw2wgsZRvkorzkxUD9IlzhGNvc+50FfQLRVGI=; b=xeYKH//5z3rxeLddZKD4qUU6W2LD/jPVdXCISUe97y2y1+of+xiV/l22MBELy71x8G vZELd1rfa0fXzkrVXEkvCILyMjY8Es0cp91NUpBUpQYlu236zy8PdKE029mesWHe4uPt FQ30Dj5GeDcMClN/oi4rWYlAAofUAXb32zq25faDhYoOYTYC/rgQi/9EMaG6Omn0gC5M IwfoJGrkP+q3qLLVRMPqyBdCjxllBNkEwwNl1LOfkMV9V3OKo7yj446WJuNEVtCFb5fW UMYpqeVv5yxgFqO1xNwYuPECyh5xVmkf1M+xRNkWcb+/9E7/O+G6NM+bgg/mRQAGYHh7 gqhQ== MIME-Version: 1.0 Received: by 10.112.100.8 with SMTP id eu8mr1437269lbb.16.1334350750397; Fri, 13 Apr 2012 13:59:10 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Fri, 13 Apr 2012 13:59:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Apr 2012 16:59:10 -0400 Message-ID: From: Marshall Eubanks To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability 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, 13 Apr 2012 20:59:15 -0000 http://datatracker.ietf.org/wg/clue/charter/ On Fri, Apr 13, 2012 at 4:49 PM, I=F1aki Baz Castillo wrote= : > Hi, an easy question... What does it mean CLUE? From ted.ietf@gmail.com Fri Apr 13 15:38: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 6502321F8833 for ; Fri, 13 Apr 2012 15:38:42 -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 qfNZYD4zJGED for ; Fri, 13 Apr 2012 15:38:41 -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 9761321F8832 for ; Fri, 13 Apr 2012 15:38:41 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2822074vbb.31 for ; Fri, 13 Apr 2012 15:38:41 -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 :content-transfer-encoding; bh=ZevDMfOIKfuw++GsPpAcdeyxhc5+ONBl4fbL0MurV0c=; b=whW9B08EUSmXiqsOf0QAQ2KhOa9A9rstmI9hrRRH3jjp0K7AUs/tlqo6ZyVGxk5KYQ HMKfqtZLhUY1ZRR+0N62zK7IKmMYkGZxd4AFNCMQV0YFbcgU9TXPTL/vSGWsAh5V6tsi NTcBQhPqyqBPmtQ4HQQ4xi/o21GyZTwN/XkOm8amGkKxM9F3YF4S7wz3urY336zGyJ7W jVJ07XvIPcMmyZP2P3dPd/d8rNx0YcD13H9iiwJ3pyK3+xBfs+k7I64WBQ+J5q2IJVyw q4W6dY0oZzZuEmlCT9CGFeoaNuYomlQCkTZguyE/UvdazRKtQ903IGHqGzVAavxmlK9Y RyxA== MIME-Version: 1.0 Received: by 10.52.34.79 with SMTP id x15mr1354761vdi.0.1334356721086; Fri, 13 Apr 2012 15:38:41 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Fri, 13 Apr 2012 15:38:41 -0700 (PDT) Date: Fri, 13 Apr 2012 15:38:41 -0700 Message-ID: From: Ted Hardie To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: [rtcweb] UPDATED Draft minutes for Wednesday session of IETF 83 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, 13 Apr 2012 22:38:42 -0000 The proceedings seem to be set up to prefer a single set of minutes, rather than one per session. I've uploaded a set now that includes the ones Magnus originally put up, plus minutes from the second session. Many thanks to all of our note takers for their hard work. Please review the minutes and send corrections, thanks, Ted Hardie On Fri, Apr 13, 2012 at 4:06 AM, Magnus Westerlund wrote: > WG, > > I have uploaded a first version of minutes for the first WG session in > Paris. Please review so that the minutes accurately reflects your > activities in the WG meeting session. > > http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.htm > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia 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@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Fri Apr 13 19:26: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 CB7C611E809F for ; Fri, 13 Apr 2012 19:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.568, 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 FZkmM929zAx3 for ; Fri, 13 Apr 2012 19:26:50 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A1BAE11E809D for ; Fri, 13 Apr 2012 19:26:21 -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 1SIsgu-0005dm-Mr for rtcweb@ietf.org; Fri, 13 Apr 2012 21:26:20 -0500 Message-ID: <4F88DF63.5080803@jesup.org> Date: Fri, 13 Apr 2012 22:22:27 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F7575FB.8010201@ericsson.com> <4F762813.6040506@jesup.org> <4F76937B.9020901@ericsson.com> <4F7698EF.1090306@ericsson.com> <4F79AFD1.8030401@ericsson.com> In-Reply-To: <4F79AFD1.8030401@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] Interaction between MediaStream API and signaling 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, 14 Apr 2012 02:26:51 -0000 A reply I hadn't sent... On 4/2/2012 9:55 AM, Stefan Hakansson LK wrote: > On 04/02/2012 05:16 AM, Justin Uberti wrote: >>>> Yes. Just like in SIP. And so when you send an OFFER (or >> modified >> re-OFFER), you must be ready to receive data per that offer >> even if no >> ANSWER has been received - just like in SIP. And if its a >> re-offer, you >> need to accept the old, and accept the new (though you could >> probably >> use reception of obviously new-OFFER media to turn off >> decoding/rendering old-OFFER in preparation for the ANSWER). >> >> The flip side of this is the responder has to infer when the >> sender >> switches over to the result of the ANSWER from the media. >> For example: >> >> A B >> <--- H.261 ---> >> re-OFFER(VP8) ---> >> <-- ANSWER(VP8) (delayed in reception) >> <-----------VP8 (A should infer that B ANSWERed >> and accepted VP8) >> ----------> H.261 >> <-- ANSWER(VP8) (received) >> <--------VP8----------> (B should infer by reception of >> VP8 that ANSWER >> was received) >> >> (Personally, I hate inferences, but without a 3 (or 4) way >> handshake, >> you have to). If you switches of codecs are staged, then >> this isn't >> (much) of a problem. Either leave old codec on the list, or >> leave it on >> the list until accept, and then re-OFFER to remove the >> un-used codec. >> [ Stefan responded: ] >> I think I understand what you mean, and this would work fine as >> long as >> you just switch codecs that are used in already set-up MediaStreams. Ah, but how do you know which stream the packets are for: in bundle, the packets are designated by SSRC, but without the ANSWER you can't figure it out, and on ANSWER the SSRCs could change. Or if you change from non-bundle to bundle (admittedly, it's unclear when one would do so, but we're discussing a protocol, and that's not disallowed I assume). We have to consider, since we're designing a protocol, not only the preferred and likely negotiations, but all possible negotiations. Painful, but true. >> This may have been a very bad example. Probably you can tell them >> apart on the SSRC. But even so, the A browser won't know what the >> VP8 stream (if it has an unknown SSRC) represents without receiving >> the ANSWER. >> >> >> I think this is only an issue if you decide to add streams in the >> ANSWER. But even so, eventually the ANSWER arrives and you can start >> demuxing/decoding appropriately. > > Yes, I agree to that it is only an issue if you add streams in the > answer. Perhaps it is a model we should move away from - but that is the > model used in the basic examples of the JSEP draft. Even if you don't add streams you could change the Bundle; or the SSRC's could change messing up demux until ANSWER, etc. > I think there is a risk of clipping if you start sending immediately, > but can only start demuxing/decoding once an answer is received. I would agree. -- Randell Jesup randell-ietf@jesup.org From lists@infosecurity.ch Sun Apr 15 05:31: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 B128E21F8792 for ; Sun, 15 Apr 2012 05:31:16 -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 OFBLE0GQ8RYO for ; Sun, 15 Apr 2012 05:31:16 -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 E7E7621F878E for ; Sun, 15 Apr 2012 05:31:15 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3011482wgb.13 for ; Sun, 15 Apr 2012 05:31:14 -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:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=j7hCA9Nel5FlXP13V9rY/k1+fESJIKCu7NVnjMEYIOU=; b=UDErAbdOpiaR5If1ztPF4o5qaaCCIehw+0uRyNGRND7ZuaYsnR7BMyu6vsaOEiihM+ UZf+OR2TpGIp1aExNk9G5a1GxHv5DLOQk6IvXziSUpScMG2OlADRmSKkKX3xWmNi7wiE eEbvrkKFKOhNNbi78a2LSLW79NiaG5xnAP4GkDrIpNTORSFKQKSqEcZxUA5HMZTEkSo+ 7vnPIVcr5yO4aZE7byLywlfchCXWii1V0PEqjqpMAAMlaYAsPSTXSDYAby/k5vPLaY5J //elPk1EHi/5SaIA3hSSqtsgef1blcq6KSYUTtSoYsAUHFP01O0BwbuhQWNYP931GhRe /j/g== Received: by 10.180.104.230 with SMTP id gh6mr10343333wib.22.1334493074591; Sun, 15 Apr 2012 05:31:14 -0700 (PDT) Received: from sonyvaiop13.local (93-32-159-13.ip34.fastwebnet.it. [93.32.159.13]) by mx.google.com with ESMTPS id ff9sm11780535wib.2.2012.04.15.05.31.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 05:31:13 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F8ABF8E.9080706@infosecurity.ch> Date: Sun, 15 Apr 2012 14:31:10 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Randell Jesup References: <4F7DD0B8.2030900@infosecurity.ch> <4F7E77BF.4090006@jesup.org> In-Reply-To: <4F7E77BF.4090006@jesup.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnEC0nt9jbahxvhTXg2IMJmTcMXhF3A2Fv4714Naxl3wwGeoEFGYvOcf/Lw9IzNZKDTMvSd Cc: "" Subject: Re: [rtcweb] DTLS-SRTP with end-to-end security: Short Authentication String 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 Apr 2012 12:31:16 -0000 On 4/6/12 6:57 AM, Randell Jesup wrote: > tl;dr: I believe SAS should be supported by the browser (or non-browser > app/device) UI, and I believe that's the current plan though perhaps > it's not written as a MUST. I am much more hesitant to endorse > key-chaining due to usability issues. Well, that's an element of improvement that maybe strongly desiderable, as it would enable the current DTLS-SRTP standard to provide end-to-end security. Otherwise, without independent fingerprint verification method formalized and mandatory. The browser would just need to report whenever the communication has: - end-to-site security (trusting google/signaling provider) - end-to-end security (verifying it independently) The JS API would just allow the calling app to specify whenever the media security authentication would go trough: - without verification - with a third party IDP - with end-to-end authentication (via user to user authentication) This would really be a strong security improvement to the WebRTC standard as it would satisfy also end-to-end encryption needs. And user would be aware of the level of security of their call in a simple and user-friendly way. That way the level of security can be evaluated by the end-user, with security options to be provided by the calling app provider by the signaling service. This seems to me quite a reasonable, not so complicated, but very *powerful* security improvement as it bring end-to-end security to the standard. Otherwise we would never be able to say that "WebRTC provider end-to-end security" . >> I would like to bring the attention of the WG to provide a MANDATORY >> requirement to enable SAS verification. > > I think the question was asked at IETF (paraphrased): will SAS be > available through the UI in some manner? Yes. This would be really cool. It's just that current IETF internet-draft does not seems to reflect this statement (but i maybe wrong, in case point me to the right sentence highlighting the support for SAS) Fabio From stefan.lk.hakansson@ericsson.com Mon Apr 16 00:01: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 A9C6221F8711 for ; Mon, 16 Apr 2012 00:01:39 -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=[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 trfx+4q8TJEG for ; Mon, 16 Apr 2012 00:01:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1821F8702 for ; Mon, 16 Apr 2012 00:01:38 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-67-4f8bc3d1af05 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9C.FB.03534.1D3CB8F4; Mon, 16 Apr 2012 09:01:37 +0200 (CEST) Received: from [150.132.142.223] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 09:01:36 +0200 Message-ID: <4F8BC3D0.3060401@ericsson.com> Date: Mon, 16 Apr 2012 09:01:36 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4F7575FB.8010201@ericsson.com> <4F762813.6040506@jesup.org> <4F76937B.9020901@ericsson.com> <4F7698EF.1090306@ericsson.com> <4F79AFD1.8030401@ericsson.com> <4F88DF63.5080803@jesup.org> In-Reply-To: <4F88DF63.5080803@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Interaction between MediaStream API and signaling 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 Apr 2012 07:01:39 -0000 On 04/14/2012 04:22 AM, Randell Jesup wrote: > A reply I hadn't sent... > > On 4/2/2012 9:55 AM, Stefan Hakansson LK wrote: >> On 04/02/2012 05:16 AM, Justin Uberti wrote: >>>>> Yes. Just like in SIP. And so when you send an OFFER (or >>> modified >>> re-OFFER), you must be ready to receive data per that offer >>> even if no >>> ANSWER has been received - just like in SIP. And if its a >>> re-offer, you >>> need to accept the old, and accept the new (though you could >>> probably >>> use reception of obviously new-OFFER media to turn off >>> decoding/rendering old-OFFER in preparation for the ANSWER). >>> >>> The flip side of this is the responder has to infer when the >>> sender >>> switches over to the result of the ANSWER from the media. >>> For example: >>> >>> A B >>> <--- H.261 ---> >>> re-OFFER(VP8) ---> >>> <-- ANSWER(VP8) (delayed in reception) >>> <-----------VP8 (A should infer that B ANSWERed >>> and accepted VP8) >>> ----------> H.261 >>> <-- ANSWER(VP8) (received) >>> <--------VP8----------> (B should infer by reception of >>> VP8 that ANSWER >>> was received) >>> >>> (Personally, I hate inferences, but without a 3 (or 4) way >>> handshake, >>> you have to). If you switches of codecs are staged, then >>> this isn't >>> (much) of a problem. Either leave old codec on the list, or >>> leave it on >>> the list until accept, and then re-OFFER to remove the >>> un-used codec. >>> > > [ Stefan responded: ] > >>> I think I understand what you mean, and this would work fine as >>> long as >>> you just switch codecs that are used in already set-up MediaStreams. > > Ah, but how do you know which stream the packets are for: > in bundle, the packets are designated by SSRC, but without the ANSWER > you can't figure it out, and on ANSWER the SSRCs could change. If I read the spec right, the ANSWER can't change the SSRCs for streams going offerer -> answerer (but I agree to the first point you are making). > Or if > you change from non-bundle to bundle (admittedly, it's unclear when one > would do so, but we're discussing a protocol, and that's not disallowed > I assume). Right. > > We have to consider, since we're designing a protocol, not only the > preferred and likely negotiations, but all possible negotiations. > Painful, but true. Agree. IMO, there is a lot that is unclear, and need to be speced out. JSEP basically allows you to modify anything at any time, and to be able to build interoperable implementations we need to define what should happen. > >>> This may have been a very bad example. Probably you can tell them >>> apart on the SSRC. But even so, the A browser won't know what the >>> VP8 stream (if it has an unknown SSRC) represents without receiving >>> the ANSWER. >>> >>> >>> I think this is only an issue if you decide to add streams in the >>> ANSWER. But even so, eventually the ANSWER arrives and you can start >>> demuxing/decoding appropriately. >> >> Yes, I agree to that it is only an issue if you add streams in the >> answer. Perhaps it is a model we should move away from - but that is the >> model used in the basic examples of the JSEP draft. > > Even if you don't add streams you could change the Bundle; or the SSRC's > could change messing up demux until ANSWER, etc. > >> I think there is a risk of clipping if you start sending immediately, >> but can only start demuxing/decoding once an answer is received. > > I would agree. > > > From magnus.westerlund@ericsson.com Mon Apr 16 01:37: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 E0E7621F8610 for ; Mon, 16 Apr 2012 01:37:02 -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 VrDuQjyd57ve for ; Mon, 16 Apr 2012 01:37:02 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 18C7A21F85ED for ; Mon, 16 Apr 2012 01:37:01 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-2e-4f8bda2c1504 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2A.44.26681.C2ADB8F4; Mon, 16 Apr 2012 10:37:01 +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.213.0; Mon, 16 Apr 2012 10:37:00 +0200 Message-ID: <4F8BDA2B.3040204@ericsson.com> Date: Mon, 16 Apr 2012 10:36:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org, EKR References: <4F732531.2030208@ericsson.com> In-Reply-To: <4F732531.2030208@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Consensus call regarding media security 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 Apr 2012 08:37:03 -0000 WG, EKR The deadline for this call of consensus has ended. I note that there has been discussion of a number of details and additional views on the actual consensus statement made. Some supporting the consensus from the meeting room and some opposing it. In the end I determine that the two consensus statements are confirmed: The first was that there was overwhelming consensus that all RTP packets SHALL be protected by SRTP. Secondly that no one objected against making DTLS-SRTP a mandatory to implement and the default keying mechanism. Additional mechanisms are not precluded. >From the discussion in the thread I would note the following: 1) Null cipher for encryption is strongly desired but an actual proposal is needed for how to express this. 2) Details of the SRTP and DTLS-SRTP usage in this WG needs to be defined. This is for continued discussion. I hope our editor of the security architecture can make a proposal to the WG to consider. 3) The discussion of additional keying mechanisms such as Security Descriptions and Encrypted Key Transport will continue. Cheers Magnus On 2012-03-28 16:50, Magnus Westerlund wrote: > WG, > > In todays RTCWEB WG meeting there was discussion around media security > mechanism. In this meeting there was some clear consensus in the > meeting which we would like to confirm on the list. > > The first was that there was overwhelming consensus that all RTP > packets SHALL be protected by SRTP. > > Secondly that no one objected against making DTLS-SRTP a mandatory to > implement and the default keying mechanism. Additional mechanisms are > not precluded. > > WG participants may state their position regarding these consensus calls > until 12th of April when the chairs will declare the final consensus. If > you where present in the meeting room and comment on this, please > indicate that. > > Best Regards > > Magnus Westerlund > For the WG chairs > > _______________________________________________ > 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 magnus.westerlund@ericsson.com Mon Apr 16 01:41: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 6398821F866A for ; Mon, 16 Apr 2012 01:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 PV5fHP8So62g for ; Mon, 16 Apr 2012 01:41:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A57D021F8650 for ; Mon, 16 Apr 2012 01:41:54 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-e8-4f8bdb514f8e Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F2.35.26681.15BDB8F4; Mon, 16 Apr 2012 10:41:53 +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.213.0; Mon, 16 Apr 2012 10:41:52 +0200 Message-ID: <4F8BDB50.4070804@ericsson.com> Date: Mon, 16 Apr 2012 10:41:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UPDATED Draft minutes for Wednesday session of IETF 83 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 Apr 2012 08:41:55 -0000 On 2012-04-14 00:38, Ted Hardie wrote: > The proceedings seem to be set up to prefer a single set of minutes, > rather than one per session. I've uploaded a set now that includes > the ones Magnus originally put up, plus minutes from the second > session. Many thanks to all of our note takers for their hard work. > > Please review the minutes and send corrections, A link to the version containing both sessions are: http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.txt 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 ekr@rtfm.com Mon Apr 16 04:58: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 91F5F21F86B7 for ; Mon, 16 Apr 2012 04:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[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 OLpxt7F+nARM for ; Mon, 16 Apr 2012 04:58:26 -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 DB3F021F86A8 for ; Mon, 16 Apr 2012 04:58:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3896503vbb.31 for ; Mon, 16 Apr 2012 04:58:25 -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=SEGaHsjcy0r0LxfeEWoqxq3hs4VID1Cw9unkLwjRC3c=; b=K6lFER/ceE1w4UAk/jaxqN6TqSHlaMneY0PLIRDaJ6TQzF63HhOKBmTt2sblu1UTZx JogZKIH336a25ROhjRUP8Pr5MK9qFWCmnClwPwoBbRn8Bn34al0fG4ZHPKilKE/V0YkD DzLx3xkF+vskfEKs5MmjzdrSrFKrma9vbdJwCuuQjBGQypldEo5u7iuTz6X+sMCJ+FEu jz9sYL3p6qcL9/v8Wzf6MuJ0oLVT67CrWtCkTFSnpNInTOeLeZd0iLH9eZ166No1fHz7 BrDhRFP7AcwEoaitOlYOcD0+2jWxAeNJqFciRPBx7cNU6t2KbIASh9Jzh37CqRmZsnuW 7m1A== Received: by 10.220.153.8 with SMTP id i8mr5834613vcw.73.1334577505365; Mon, 16 Apr 2012 04:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Mon, 16 Apr 2012 04:57:44 -0700 (PDT) X-Originating-IP: [66.104.195.130] In-Reply-To: <4F8BDA2B.3040204@ericsson.com> References: <4F732531.2030208@ericsson.com> <4F8BDA2B.3040204@ericsson.com> From: Eric Rescorla Date: Mon, 16 Apr 2012 07:57:44 -0400 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlpGsSlDrc0pbX/VLPq9ChAK64+p33w+YSHxcLGHurnWUPfCJ9l/h7wOCfK75g37Jc82ayi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consensus call regarding media security 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 Apr 2012 11:58:26 -0000 On Mon, Apr 16, 2012 at 4:36 AM, Magnus Westerlund wrote: > WG, EKR > > The deadline for this call of consensus has ended. I note that there has > been discussion of a number of details and additional views on the > actual consensus statement made. Some supporting the consensus from the > meeting room and some opposing it. In the end I determine that the two > consensus statements are confirmed: > > =A0The first was that there was overwhelming consensus that all RTP > =A0packets SHALL be protected by SRTP. > > =A0Secondly that no one objected against making DTLS-SRTP a mandatory to > =A0implement and the default keying mechanism. Additional mechanisms are > =A0not precluded. > > From the discussion in the thread I would note the following: > > 1) Null cipher for encryption is strongly desired but an actual proposal > is needed for how to express this. > > 2) Details of the SRTP and DTLS-SRTP usage in this WG needs to be > defined. This is for continued discussion. I hope our editor of the > security architecture can make a proposal to the WG to consider. Acknowledged. I will do so. -Ekr From harald@alvestrand.no Mon Apr 16 05:01: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 2EABE21F8690 for ; Mon, 16 Apr 2012 05:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 LzJMHDXfJdmL for ; Mon, 16 Apr 2012 05:01:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1730121F8687 for ; Mon, 16 Apr 2012 05:01:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52DC239E113; Mon, 16 Apr 2012 14:01:15 +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 Ey2nEx6SyA3Y; Mon, 16 Apr 2012 14:01:14 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6B58D39E089; Mon, 16 Apr 2012 14:01:14 +0200 (CEST) Message-ID: <4F8C0A0A.6080002@alvestrand.no> Date: Mon, 16 Apr 2012 14:01:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Magnus Westerlund References: <4F8BDB50.4070804@ericsson.com> In-Reply-To: <4F8BDB50.4070804@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] UPDATED Draft minutes for Wednesday session of IETF 83 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 Apr 2012 12:01:19 -0000 Thanks for these! The only serious comments I have are on the codec discussion near the end; otherwise, there are grammar nits. Notes: - Please convert to ASCII. Quotes and non-ASCII characters are broken. - "One attack by claim to link to something, but what you really connect to is some other site" Grammar issue: by claim -> by claiming - "In Jingle to enable early response with the ICE candidates and the username and password are anyway needed." -> could not parse this sentence. Please reword. - One instance of "Collin Perkins" (misspelled name) - "straight forward" -> "straightforward" - "Regarding the key-exchange and the round trip time. We will encounter cases, like the trombone where the signaling server is far away and the media peer is close." - the first full stop should be a comma for grammatical correctness. - "no overhead in a waste majority of cases." -> "no overhead in the vast majority of cases" - "The chairs declared No Consensus between these two options due to very evenly strength hums." - grammatically, it needs to be "even strength hums"; I would formulate it as "approximately even strength hums", given that I don't remember them as *that* even (but I was not at the front of the room). - "Harald: I hope we can limit the number of cases where SDP manipulation is limited." - I certainly hope I said "needed" as the last word. - "Harald regards hints as steering wheel and brake pedal, while SDP is plugging in to engine control. Hopes can do what we need via hints." - "in to" -> "into"; "Hopes can do" -> "He hopes that we can do". - "you are talking of SCT/DTLS/UDP." -> SCTP/DTLS/UDP - "Tim (Mozilla)" -> Tim Terriberry - Tim P -> Tim Panton "Cullen: raise your hand in favor of H.261 H.264 VP8" The numbers (or proportions) need to be part of the minutes, and the minutes need to make it clear that this was a straw poll, not a hum for consensus (Ted made that very clear, but it's not clear from the minutes.) Allistair ??: The discussion was the same in H.323, and G.711 was selected as audio codec because of IPR free. None believes it would be useful, but this stopped the discussions. I believe this was followed by a remark saying a huge amount of current traffic is G.711 or worse. On 04/16/2012 10:41 AM, Magnus Westerlund wrote: > On 2012-04-14 00:38, Ted Hardie wrote: >> The proceedings seem to be set up to prefer a single set of minutes, >> rather than one per session. I've uploaded a set now that includes >> the ones Magnus originally put up, plus minutes from the second >> session. Many thanks to all of our note takers for their hard work. >> >> Please review the minutes and send corrections, > A link to the version containing both sessions are: > > http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.txt > > 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 Henry.Lum@genesyslab.com Mon Apr 16 08:52: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 EA2C921F8669 for ; Mon, 16 Apr 2012 08:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 jeM0qysgQW+L for ; Mon, 16 Apr 2012 08:52:58 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id 2030721F866A for ; Mon, 16 Apr 2012 08:52:58 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q3GFqvlg003706 for ; Mon, 16 Apr 2012 08:52:57 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 08:52:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1BE8.FE4C7434" Date: Mon, 16 Apr 2012 08:52:56 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74086657DB@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The meaning of SDP_PRANSWER Thread-Index: Ac0b6P2LYYaJABysS36nnM28Gg2Lzg== From: "Henry Lum" To: X-OriginalArrivalTime: 16 Apr 2012 15:52:58.0000 (UTC) FILETIME=[FE836900:01CD1BE8] Subject: [rtcweb] The meaning of SDP_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: Mon, 16 Apr 2012 15:52:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1BE8.FE4C7434 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's unclear to me what the purpose of SDP_PRANSWER is really for and why it needs to be there. Originally I thought it was meant for early media, but section 6.1.4 paragraph 3 says that it should not result in starting of media transmission. Is there a reason to provide an answer before media is ready to be transmitted? There are separate handles for processing ICE candidates so I don't see a need to have provisional answers.=20 =20 I am not proposing PRANSWER for handling early media though, since I believe early media is more of an application level issue (it's more like late-billing on the application side) and should be considered as a separate offer/answer if needed. =20 Regards, Henry=20 ------_=_NextPart_001_01CD1BE8.FE4C7434 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s unclear to me what the purpose of = SDP_PRANSWER is really for and why it needs to be there. Originally I thought it was = meant for early media, but section 6.1.4 paragraph 3 says that it should not result in = starting of media transmission. Is there a reason to provide an answer before = media is ready to be transmitted? There are separate handles for processing ICE = candidates so I don’t see a need to have provisional answers.

 

I am not proposing PRANSWER for handling early = media though, since I believe early media is more of an application level issue = (it’s more like late-billing on the application side) and should be considered = as a separate offer/answer if needed.

 

Regards,

Henry

------_=_NextPart_001_01CD1BE8.FE4C7434-- From fluffy@cisco.com Mon Apr 16 12:45: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 AC8C211E80B4 for ; Mon, 16 Apr 2012 12:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.243 X-Spam-Level: X-Spam-Status: No, score=-107.243 tagged_above=-999 required=5 tests=[AWL=3.356, 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 TqsRwlOKMSDc for ; Mon, 16 Apr 2012 12:45:32 -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 D052911E808C for ; Mon, 16 Apr 2012 12:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1127; q=dns/txt; s=iport; t=1334605533; x=1335815133; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Ia50UtNqWGE9JSEH20V+2+0roePWhwm+QH5uNjXjGEQ=; b=ii67OaOCdzp4SXolfCsLRdhHXxO9H/CJlKPMnLihkhCgn0YbeTfLA2Dj Ye2xIe1jNWo0H0jxOyCXatZlDSpAcTK4Ukq2SwoAHgvZJEHWymiZ86hhN 3hxXK7qED5ulGbFyiSWOspyScIhBCXeNXAqP0EDtNg1Wf2xwVb/tV+9cH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFACd2jE+rRDoG/2dsb2JhbABEgxyvd4EHgiIBJy8BD4Fzh2uZYJ9RjiWCQWMEiFqNE4VyiFqBaYMG X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="38220581" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 16 Apr 2012 19:45:30 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3GJjTLq024213; Mon, 16 Apr 2012 19:45:30 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Apr 2012 13:45:29 -0600 Message-Id: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Update of future interim meeting locations 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 Apr 2012 19:45:33 -0000 The CLUE and WebRTC groups are making plans based on WebRTC meeting June = 12 and 13 in Stockholm. The chairs believe that picking a different time = or locations at this point will not be beneficial so we plan to try and = confirm that date.=20 I'd like to try and answer the question about locations of RTCWeb = interim meetings after the ones currently planned. First of all, the chairs would are going to declare that there is WG = consensus for a 1:1:1 meeting rotation between west coast of north = america, europe, and east coast of north america and plan to run = approximately equal number of meetings in these locations. In counting = the number of past meetings in a given region, we will include all the = face to face RTCWeb and WebRTC meetings as this work is closely joined = and a large number of the participants travel to both sets of meetings. = The face to face meetings that happen at the main IETF or W3C meetings = are included in this count. Collocated meetings will be counted just = once as they only require one set of travel to that location. =20 Cullen From mary.ietf.barnes@gmail.com Mon Apr 16 14:04: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 65E3121F866A for ; Mon, 16 Apr 2012 14:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.61 X-Spam-Level: X-Spam-Status: No, score=-103.61 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 fgiZ73UfrZnS for ; Mon, 16 Apr 2012 14:04:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B649821F8667 for ; Mon, 16 Apr 2012 14:04:42 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so4377794vcb.31 for ; Mon, 16 Apr 2012 14:04: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=8T8zSLspDKCwvu8P0AjOc1mR0CvX5ai6a15HqixRsTI=; b=WOFb3gd7/qTXhs3CTQ0l6uvdDj1wAOC9LrGz2rZzUw+AumdPgHgPt985e/JGF6eQtk yvhTurvAHEd0w0jZCGDtV6jls3oCTgRsbylCOh4I3GL+VYM+rSyTnhcAP+FoAheaNSKg g2vmxwZfOTiBD78AeZgmo607xt2jVyaqF18DjVzRODRz7vetmSiTdfHDPFprehMTo/t4 x7DukqKCurXpkeVC21UxovTkVfkl0yuNsDxBwl2kOSdTpmGW/hMcsYtYsSKAL4mnPE9t fCNluJOIQkLXDz6XQE1uixQNqAB07UttQjvWTp4OyfghoB2nNxL6MN99J8LFrVtBDme4 vrpw== MIME-Version: 1.0 Received: by 10.52.72.169 with SMTP id e9mr5501986vdv.21.1334610282181; Mon, 16 Apr 2012 14:04:42 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 16 Apr 2012 14:04:42 -0700 (PDT) In-Reply-To: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> Date: Mon, 16 Apr 2012 16:04:42 -0500 Message-ID: From: Mary Barnes To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf3071d0a2c874e204bdd22b58 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:04:43 -0000 --20cf3071d0a2c874e204bdd22b58 Content-Type: text/plain; charset=ISO-8859-1 Just one clarification - I thought the W3C WebRTC group planned to meet on June 11th and then the IETF RTCWEB WG on June 12-13? The CLUE WG meeting still plans to meet on June 7-8. Regards, Mary. On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings wrote: > > The CLUE and WebRTC groups are making plans based on WebRTC meeting June > 12 and 13 in Stockholm. The chairs believe that picking a different time or > locations at this point will not be beneficial so we plan to try and > confirm that date. > > I'd like to try and answer the question about locations of RTCWeb interim > meetings after the ones currently planned. > > First of all, the chairs would are going to declare that there is WG > consensus for a 1:1:1 meeting rotation between west coast of north america, > europe, and east coast of north america and plan to run approximately equal > number of meetings in these locations. In counting the number of past > meetings in a given region, we will include all the face to face RTCWeb and > WebRTC meetings as this work is closely joined and a large number of the > participants travel to both sets of meetings. The face to face meetings > that happen at the main IETF or W3C meetings are included in this count. > Collocated meetings will be counted just once as they only require one set > of travel to that location. > > Cullen > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf3071d0a2c874e204bdd22b58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just one clarification - I thought the W3C WebRTC group planned to meet on = June 11th and then the IETF RTCWEB WG on June 12-13? =A0

The CLUE WG meeting still plans to meet on June 7-8. =A0

Regards,
Mary.=A0

O= n Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings <fluffy@cisco.com> wrote:

The CLUE and WebRTC groups are making plans based on WebRTC meeting June 12= and 13 in Stockholm. The chairs believe that picking a different time or l= ocations at this point will not be beneficial so we plan to try and confirm= that date.

I'd like to try and answer the question about locations of RTCWeb inter= im meetings after the ones currently planned.

First of all, the chairs would are going to declare that there is WG consen= sus for a 1:1:1 meeting rotation between west coast of north america, europ= e, and east coast of north america and plan to run approximately equal numb= er of meetings in these locations. =A0In counting the number of past meetin= gs in a given region, we will include all the face to face RTCWeb and WebRT= C meetings as this work is closely joined and a large number of the partici= pants travel to both sets of meetings. The face to face meetings that happe= n at the main IETF or W3C meetings are included in this count. Collocated m= eetings will be counted just once as they only require one set of travel to= that location.

Cullen =A0<RTCWeb co-chair>




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

--20cf3071d0a2c874e204bdd22b58-- From fluffy@cisco.com Mon Apr 16 14:18: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 9D16211E808A for ; Mon, 16 Apr 2012 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.921 X-Spam-Level: X-Spam-Status: No, score=-108.921 tagged_above=-999 required=5 tests=[AWL=1.678, 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 R4U6Zv+T37vB for ; Mon, 16 Apr 2012 14:18:36 -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 E274421F858D for ; Mon, 16 Apr 2012 14:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1861; q=dns/txt; s=iport; t=1334611116; x=1335820716; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oz0kq5G7cvI0PguC8WMkTbYVquwzxw+2yJzMzAnVpVk=; b=fIij+bHaaHb32rf6dy0ccjCEY2ywrNmqQMKa9Uyeiw2JB4fXsKcf6VZ/ VEhQcjJXPrxFMPHYIWx/nOwJ0WsQ36Fn90i5kFLa612asgR5Mc+tquaLN Jsfv8bp7wZ16aHz5XXIyD4Ryap7LyIIYO5o8Z75C8l3CMGwxvclah4jSP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAHyLjE+rRDoI/2dsb2JhbABEgxyvY4EHggkBAQEDAQEBAQ8BJy8BBAsFCwsYLicwBhMih2cEDJlRn18EkGZjBIhajROFcohagWmDBg X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="38234544" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 16 Apr 2012 21:18:36 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3GLIad2017697; Mon, 16 Apr 2012 21:18:36 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 16 Apr 2012 15:18:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <69E0EC88-CB36-4C9C-B149-1682DEBCA6EC@cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> To: "Mary Barnes" X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:18:37 -0000 Mary, I think you are correct that the dates being considered are=20 Clue - June 7 and 8=20 WebRTC - June 11 RTCWeb - June 12 and 13 Sorry for confusion.=20 On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote: > Just one clarification - I thought the W3C WebRTC group planned to = meet on June 11th and then the IETF RTCWEB WG on June 12-13? =20 >=20 > The CLUE WG meeting still plans to meet on June 7-8. =20 >=20 > Regards, > Mary.=20 >=20 > On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings = wrote: >=20 > The CLUE and WebRTC groups are making plans based on WebRTC meeting = June 12 and 13 in Stockholm. The chairs believe that picking a different = time or locations at this point will not be beneficial so we plan to try = and confirm that date. >=20 > I'd like to try and answer the question about locations of RTCWeb = interim meetings after the ones currently planned. >=20 > First of all, the chairs would are going to declare that there is WG = consensus for a 1:1:1 meeting rotation between west coast of north = america, europe, and east coast of north america and plan to run = approximately equal number of meetings in these locations. In counting = the number of past meetings in a given region, we will include all the = face to face RTCWeb and WebRTC meetings as this work is closely joined = and a large number of the participants travel to both sets of meetings. = The face to face meetings that happen at the main IETF or W3C meetings = are included in this count. Collocated meetings will be counted just = once as they only require one set of travel to that location. >=20 > Cullen >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From ron.even.tlv@gmail.com Mon Apr 16 14:39: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 9F10221F85B4 for ; Mon, 16 Apr 2012 14:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, 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 R6sdJeSsfN5n for ; Mon, 16 Apr 2012 14:39:45 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1521F85AF for ; Mon, 16 Apr 2012 14:39:45 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so4691034wib.13 for ; Mon, 16 Apr 2012 14:39:44 -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=r3jOxflPcT7SYRqs9gqi7QFeTB6ley+yLtUd6xKXEck=; b=ywZmW+l5z1EHiszLE8o6615wGg7Z5FUxEEYaw2rcwDcpoq/nSxfw+KKkpguYov+cIF uikmYkaOlKRXpZdcfAwxrvOqJg5uqJ6+SATADBor91MSdUYImZjBtMRi/1hNHnBQpYqY mh7ZH+MMFsjMPU0R4COjyI4jgTBsskabSeAy/0wxvSZe01jw2rbwp/hDmqqquxqeG+il /vqeTLomhT1WekI02Jz2eFlhMtlHrulPT0kSQbBxSrVFjOrrhKrD4DROAC96zEZ0vk9x NYUmrlbw9Con+PqQPi8vqym8dX3+U8OnwS48MWZlV9shrd0NeRElNQeuSdWi+QkyicQ/ +YGw== Received: by 10.180.95.197 with SMTP id dm5mr987422wib.20.1334612384573; Mon, 16 Apr 2012 14:39:44 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id e6sm22333601wix.8.2012.04.16.14.39.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 14:39:43 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'Cullen Jennings'" References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> In-Reply-To: Date: Tue, 17 Apr 2012 00:38:11 +0300 Message-ID: <4f8c919f.e64eb40a.3477.ffffdc0f@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01CD1C32.5FABCE90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0cFJK222zJbVpUSCW+zE/tSFQbMgABFbRQ Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:39:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005D_01CD1C32.5FABCE90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to suggest that the RTCweb meeting will be on the 11 and 12 followed by the webrtc allowing people to attend CLUE on the 7,8 and RTCweb without having to stay one more extra day after the weekend. Thanks Roni Even From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Tuesday, April 17, 2012 12:05 AM To: Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations Just one clarification - I thought the W3C WebRTC group planned to meet on June 11th and then the IETF RTCWEB WG on June 12-13? The CLUE WG meeting still plans to meet on June 7-8. Regards, Mary. On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings wrote: The CLUE and WebRTC groups are making plans based on WebRTC meeting June 12 and 13 in Stockholm. The chairs believe that picking a different time or locations at this point will not be beneficial so we plan to try and confirm that date. I'd like to try and answer the question about locations of RTCWeb interim meetings after the ones currently planned. First of all, the chairs would are going to declare that there is WG consensus for a 1:1:1 meeting rotation between west coast of north america, europe, and east coast of north america and plan to run approximately equal number of meetings in these locations. In counting the number of past meetings in a given region, we will include all the face to face RTCWeb and WebRTC meetings as this work is closely joined and a large number of the participants travel to both sets of meetings. The face to face meetings that happen at the main IETF or W3C meetings are included in this count. Collocated meetings will be counted just once as they only require one set of travel to that location. Cullen _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_005D_01CD1C32.5FABCE90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to suggest that the RTCweb meeting will be on the 11 and = 12 followed by the webrtc allowing people to attend CLUE on the 7,8 and = RTCweb without having to stay one more extra day after the = weekend.

Thanks

Roni Even

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Tuesday, April 17, 2012 12:05 = AM
To: Cullen Jennings
Cc: = rtcweb@ietf.org
Subject: Re: [rtcweb] Update of future interim = meeting locations

 

Just one = clarification - I thought the W3C WebRTC group planned to meet on June = 11th and then the IETF RTCWEB WG on June 12-13? =  

 

The CLUE WG meeting still plans to meet on June 7-8. =  

 

Regards,

Mary. 

 

On Mon, = Apr 16, 2012 at 2:45 PM, Cullen Jennings <fluffy@cisco.com> = wrote:


The CLUE and WebRTC groups = are making plans based on WebRTC meeting June 12 and 13 in Stockholm. = The chairs believe that picking a different time or locations at this = point will not be beneficial so we plan to try and confirm that = date.

I'd like to try and answer the question about locations of = RTCWeb interim meetings after the ones currently planned.

First = of all, the chairs would are going to declare that there is WG consensus = for a 1:1:1 meeting rotation between west coast of north america, = europe, and east coast of north america and plan to run approximately = equal number of meetings in these locations.  In counting the = number of past meetings in a given region, we will include all the face = to face RTCWeb and WebRTC meetings as this work is closely joined and a = large number of the participants travel to both sets of meetings. The = face to face meetings that happen at the main IETF or W3C meetings are = included in this count. Collocated meetings will be counted just once as = they only require one set of travel to that location.

Cullen =  <RTCWeb = co-chair>




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

 

------=_NextPart_000_005D_01CD1C32.5FABCE90-- From stewe@stewe.org Mon Apr 16 14:40: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 A571121F85D8; Mon, 16 Apr 2012 14:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=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 bd6Q+UVc+Q1w; Mon, 16 Apr 2012 14:40:21 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 941BE21F85AF; Mon, 16 Apr 2012 14:40:20 -0700 (PDT) Received: from mail49-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 16 Apr 2012 21:40:19 +0000 Received: from mail49-am1 (localhost [127.0.0.1]) by mail49-am1-R.bigfish.com (Postfix) with ESMTP id 955782C0779; Mon, 16 Apr 2012 21:40:19 +0000 (UTC) X-SpamScore: -21 X-BigFish: PS-21(zzbb2dI9371Ic89bh1454I14ffI1432N41c5N98dK179cMzz1202h1082kzzz2fh2a8h668h839h) 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 Received-SPF: pass (mail49-am1: 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 mail49-am1 (localhost.localdomain [127.0.0.1]) by mail49-am1 (MessageSwitch) id 133461241776465_6633; Mon, 16 Apr 2012 21:40:17 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.236]) by mail49-am1.bigfish.com (Postfix) with ESMTP id 040C824004E; Mon, 16 Apr 2012 21:40:17 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Apr 2012 21:40:16 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.165]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0143.004; Mon, 16 Apr 2012 21:40:10 +0000 From: Stephan Wenger To: Harald Alvestrand Thread-Topic: VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) Thread-Index: AQHNHBl/zPrIuhmKBk2PF+XRFqQqHg== Date: Mon, 16 Apr 2012 21:40:09 +0000 Message-ID: In-Reply-To: <4F87D9B1.4000206@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="iso-8859-1" Content-ID: <71C3AEB0F09920489EAE38D0873E7072@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" , "payload@ietf.org" Subject: [rtcweb] VP8 payload, decoder processing capabilities (was Re: Resolution negotiation - a contribution) 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 Apr 2012 21:40:21 -0000 Hi all, For context: Harald and myself have been at odds for a while now about the lack of support for a code point in the VP8 payload that can be used to negotiate a maximum decoder/bitstream complexity. Specifically, Harald (and other VP8 payload folks) suggested that generic mechanisms, such as the a=3Dframerate attribute of RFC4566 in conjunction with the picture size aspect of the imageattr of RFC 6236 can be used, at least in the rtcweb context. However, as far as I understood our argument, these two mechanisms in combination are not meant as a limit for decoder complexity (in terms of samples/sec processing rate), but rather as an indication, from receiver to sender, of an upper bound of what is "useful to send". See the email below. To me, it's quite obvious that an indication of "useful to send" includes "my decoder can handle this"; however, it could be more restrictive in that factors other than decoder horsepower could also be at play, such as screen size, user interface settings, and so on. I believe that the combination of what can be signaled using the above mechanisms should be sufficient for rtcweb. However, I also believe that it is insufficient for general purpose use, mostly because it requires the support of RFC 6236, which is not exactly a widely deployed technology. Further, the a=3Dframerate attribute is not a particularly useful attribute these days anymore, because variable frame rates, at least for software encoding/decoding, are the norm. In previous posts on the payload list (in response to the VP8 payload WGLC), I have commented on the practical shortcomings of the (lack of) complexity negotiation, and suggested that this needs to be fixed. Two options: 1) codify Harald's mechanism (based on a=3Dframerate and imageattr in the VP8 payload draft, at MUST strength. "In a declarative context, a prospective media sender supporting this (VP8 payload) specification MUST support RFC 4566 a=3Dframerate and RFC6236 imageattr, and MUST include code points according to both mechanisms to identify the properties of the media stream. In an offer-answer context, both offerer and answerer receiver supporting this VP8 payload specification MUST support a=3Dframertate and imageattr, and MUST include both in their respective offer/answer messages, so to identify an operation point that will not overload the media decoder's capabilities. The issue with this approach, IMO, is that we are dealing here with three individual code points (framerate, horizontal and vertical picture size), where a single code point ought to be sufficient for determining whether a d=E9cor is capable of decoding a stream, at least from a complexity viewpoint). 2) include, in the V8 payload, a negotiable SDP code point indicating the complexity of a stream, in units of samples per second processing requirements or a derivative thereof (such as: levels as used in the MPEG world). For example, the VP8 payload could include a single, optional, negotiable parameter "SamplePerSecond". If SamplePerSecond were absent in the SDP, a value of xxxxx must be inferred. (a sensible value for xxxxx could be, for example 9216000, which is the number of samples per second for VGA resolution at 30 Hz). If SamplePerSecond is present in a declarative context, it indicates the minimum processing requirements a decoder must support in order to successfully decode the stream. In a symmetric offer-answer context, SamplePerSecond can be used to "dial down" the complexity of the stream to a value that both encoder and decoder can support. My preference is obviously the second proposal, but I'm willing to help fleshing out either or both of them, just not today :-) Regards, Stephan =20 On 4.13.2012 00:45 , "Harald Alvestrand" wrote: >On 04/12/2012 11:13 PM, Stephan Wenger wrote: >> >> On 4.12.2012 12:08 , "Harald Alvestrand" wrote: >> >>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>>> Hi Harald, >>>> Thanks for this strawman. I believe it should work, but I fail to see >>>> how >>>> a two dimensional negotiation requirement (negotiating max values for >>>> framerate and image size--which, in turn, also has two-dimensional >>>> properties) leads to better interop than a one dimensional negotiation >>>> (pixels per second processing requirement). >>> Stephan, >>> >>> I do not see this (or the requirement from the use-cases document) >>>first >>> and foremost a decoder complexity negotiation; it is a negotiation of >>> how much data it is useful to send, given the recipient's intended use >>> of that data. >> Then such a negotiation should be executed in addition. Decoder cycle >> requirement do matter in practical implementations. >Feel free to propose language that captures this requirement. As noted, >my I-D fragment doesn't. > > From yuepeiyu@huawei.com Mon Apr 16 19:26: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 82ED221F851B; Mon, 16 Apr 2012 19:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.857 X-Spam-Level: X-Spam-Status: No, score=-96.857 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 h7wpZL1F81Q9; Mon, 16 Apr 2012 19:26:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A44D321F84FD; Mon, 16 Apr 2012 19:26:22 -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 AFG92446; Mon, 16 Apr 2012 22:26:22 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 19:23:47 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 19:22:54 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.236]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Tue, 17 Apr 2012 10:23:43 +0800 From: "Yuepeiyu (Roy)" To: "payload@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) Thread-Index: AQHNHBmOL5G/TLbF00O5BKbyP5dzR5adpMaAgACVo+A= Date: Tue, 17 Apr 2012 02:23:42 +0000 Message-ID: References: <4F8CBA11.1010600@alvestrand.no> In-Reply-To: <4F8CBA11.1010600@alvestrand.no> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.89] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] [payload] VP8 payload, decoder processing capabilities (was Re: Resolution negotiation - a contribution) 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 Apr 2012 02:26:55 -0000 SGkgSGFyYWxkIGFuZCBTdGVwaGVuLA0KDQpGaXJzdCBvZiBhbGwsIHRoZSAiU2FtcGxlUGVyU2Vj b25kIiBpbiB0aGUgb3B0aW9uIDIgc2hvdWxkIGJlIHRoZSBtYXhpbWFsIHNhbXBsZSBwZXIgc2Vj b25kIG9mIHRoZSBzdHJlYW0sIGJlY2F1c2Ugb2YgdGhlIHZhcmlhYmxlIGZyYW1lIHJhdGVzLg0K DQpTZWNvbmQsIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IHNpZ25hbGluZyBvZiBkZWNvZGVyIGNv bXBsZXhpdHkgcG9pbnQgb2YgdmlldywgDQoJMSkgSSBkb24ndCBzZWUgbXVjaCBkaWZmZXJlbmNl IGJldHdlZW4gb3B0aW9uIDEgYW5kIDIsIGlmIG9wdGlvbiAyIGlzIHRvIHNpZ25hbCB0aGUgcmVh bCBudW1iZXIgb2YgInNhbXBsZSBwZXIgc2Vjb25kIi4gDQoJMikgSSBiZWxpZXZlIGEgZGVyaXZh dGl2ZSBvZiAiU2FtcGxlUGVyU2Vjb25kIiAoc3RpbGwgb3B0aW9uIDIpIHdvdWxkIG1ha2UgbW9y ZSBzZW5zZSwgc2luY2UgdG8gc29tZSBleHRlbnQsIGxlc3MgdmFsdWVzIHdvdWxkIGJlIHNlZW4g YXMgYSBndWlkZWxpbmUgZm9yIHRoZSBlbmNvZGVyIHRvIHByb2R1Y2UgdGhlIG1lZGlhIHN0cmVh bS4gVGhpcyBpcyBtZWFuaW5nZnVsIGVzcGVjaWFsbHkgZm9yIHRoZSBkZWNsYXJhdGl2ZSBjb250 ZXh0IHdoZXJlIHRoZSBlbmNvZGVyIGhhcyBmZXdlciBpbmZvcm1hdGlvbiBvZiB0aGUgZGVjb2Rl cidzIGNhcGFiaWxpdHkuDQoNCkp1c3QgbXkgMiBjZW50cy4NClJveQ0KLS0tLS3Tyrz+1K28/i0t LS0tDQq3orz+yMs6IHBheWxvYWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBheWxvYWQtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBIYXJhbGQgQWx2ZXN0cmFuZA0Kt6LLzcqxvOQ6IDIwMTLE6jTU wjE3yNUgODozMg0KytW8/sjLOiBTdGVwaGFuIFdlbmdlcg0Ks63LzTogcGF5bG9hZEBpZXRmLm9y Zw0K1vfM4jogUmU6IFtwYXlsb2FkXSBWUDggcGF5bG9hZCwgZGVjb2RlciBwcm9jZXNzaW5nIGNh cGFiaWxpdGllcyAod2FzIFJlOiBbcnRjd2ViXSBSZXNvbHV0aW9uIG5lZ290aWF0aW9uIC0gYSBj b250cmlidXRpb24pDQoNClJlc3BvbmRpbmcgc3RyaWN0bHkgb24gdGhlIHBheWxvYWQgbGlzdCwg YW5kIHJlZ2FyZGluZyB0aGUgVlA4IHBheWxvYWQgDQpmb3JtYXQgb25seToNCg0KVGhlIGE9ZnJh bWVyYXRlIGF0dHJpYnV0ZSBpcyBhIG1heGltdW0gZnJhbWVyYXRlIG9ubHkuIFNpbmNlIHRoZSBt YXhpbXVtIA0KZnJhbWVyYXRlIGlzIHRoZSBvbmUgdGhhdCBwbGFjZXMgdGhlIG1vc3Qgc3RyZXNz IG9uIHRoZSBkZWNvZGVyLCB0aGUgDQphYmlsaXR5IHRvIHVzZSBsb3dlciBmcmFtZXJhdGVzIGlz IGlycmVsZXZhbnQgdG8gdGhlIHF1ZXN0aW9uIG9mIA0KcmVzdHJpY3RpbmcgdGhlIGRlY29kZXIg bG9hZC4NCg0KQXBhcnQgZnJvbSB0aGF0LCBJIGJlbGlldmUgd2UgYWdyZWUgb24gd2hhdCB3ZSBk aXNhZ3JlZSBhYm91dDsgdGhlIGlucHV0IA0Kb2Ygb3RoZXIgcGFydGljaXBhbnRzIHdvdWxkIGJl IHZhbHVhYmxlLg0KDQogICAgICAgICAgICAgICAgIEhhcmFsZA0KDQpPbiAwNC8xNi8yMDEyIDEx OjQwIFBNLCBTdGVwaGFuIFdlbmdlciB3cm90ZToNCj4gSGkgYWxsLA0KPg0KPiBGb3IgY29udGV4 dDogSGFyYWxkIGFuZCBteXNlbGYgaGF2ZSBiZWVuIGF0IG9kZHMgZm9yIGEgd2hpbGUgbm93IGFi b3V0IHRoZQ0KPiBsYWNrIG9mIHN1cHBvcnQgZm9yIGEgY29kZSBwb2ludCBpbiB0aGUgVlA4IHBh eWxvYWQgdGhhdCBjYW4gYmUgdXNlZCB0bw0KPiBuZWdvdGlhdGUgYSBtYXhpbXVtIGRlY29kZXIv Yml0c3RyZWFtIGNvbXBsZXhpdHkuICBTcGVjaWZpY2FsbHksIEhhcmFsZA0KPiAoYW5kIG90aGVy IFZQOCBwYXlsb2FkIGZvbGtzKSBzdWdnZXN0ZWQgdGhhdCBnZW5lcmljIG1lY2hhbmlzbXMsIHN1 Y2ggYXMNCj4gdGhlIGE9ZnJhbWVyYXRlIGF0dHJpYnV0ZSBvZiBSRkM0NTY2IGluIGNvbmp1bmN0 aW9uIHdpdGggdGhlIHBpY3R1cmUgc2l6ZQ0KPiBhc3BlY3Qgb2YgdGhlIGltYWdlYXR0ciBvZiBS RkMgNjIzNiBjYW4gYmUgdXNlZCwgYXQgbGVhc3QgaW4gdGhlIHJ0Y3dlYg0KPiBjb250ZXh0LiAg SG93ZXZlciwgYXMgZmFyIGFzIEkgdW5kZXJzdG9vZCBvdXIgYXJndW1lbnQsIHRoZXNlIHR3bw0K PiBtZWNoYW5pc21zIGluIGNvbWJpbmF0aW9uIGFyZSBub3QgbWVhbnQgYXMgYSBsaW1pdCBmb3Ig ZGVjb2RlciBjb21wbGV4aXR5DQo+IChpbiB0ZXJtcyBvZiBzYW1wbGVzL3NlYyBwcm9jZXNzaW5n IHJhdGUpLCBidXQgcmF0aGVyIGFzIGFuIGluZGljYXRpb24sDQo+IGZyb20gcmVjZWl2ZXIgdG8g c2VuZGVyLCBvZiBhbiB1cHBlciBib3VuZCBvZiB3aGF0IGlzICJ1c2VmdWwgdG8gc2VuZCIuDQo+ IFNlZSB0aGUgZW1haWwgYmVsb3cuICBUbyBtZSwgaXQncyBxdWl0ZSBvYnZpb3VzIHRoYXQgYW4g aW5kaWNhdGlvbiBvZg0KPiAidXNlZnVsIHRvIHNlbmQiIGluY2x1ZGVzICJteSBkZWNvZGVyIGNh biBoYW5kbGUgdGhpcyI7IGhvd2V2ZXIsIGl0IGNvdWxkDQo+IGJlIG1vcmUgcmVzdHJpY3RpdmUg aW4gdGhhdCBmYWN0b3JzIG90aGVyIHRoYW4gZGVjb2RlciBob3JzZXBvd2VyIGNvdWxkDQo+IGFs c28gYmUgYXQgcGxheSwgc3VjaCBhcyBzY3JlZW4gc2l6ZSwgdXNlciBpbnRlcmZhY2Ugc2V0dGlu Z3MsIGFuZCBzbyBvbi4NCj4NCj4gSSBiZWxpZXZlIHRoYXQgdGhlIGNvbWJpbmF0aW9uIG9mIHdo YXQgY2FuIGJlIHNpZ25hbGVkIHVzaW5nIHRoZSBhYm92ZQ0KPiBtZWNoYW5pc21zIHNob3VsZCBi ZSBzdWZmaWNpZW50IGZvciBydGN3ZWIuICBIb3dldmVyLCBJIGFsc28gYmVsaWV2ZSB0aGF0DQo+ IGl0IGlzIGluc3VmZmljaWVudCBmb3IgZ2VuZXJhbCBwdXJwb3NlIHVzZSwgbW9zdGx5IGJlY2F1 c2UgaXQgcmVxdWlyZXMgdGhlDQo+IHN1cHBvcnQgb2YgUkZDIDYyMzYsIHdoaWNoIGlzIG5vdCBl eGFjdGx5IGEgd2lkZWx5IGRlcGxveWVkIHRlY2hub2xvZ3kuDQo+IEZ1cnRoZXIsIHRoZSBhPWZy YW1lcmF0ZSBhdHRyaWJ1dGUgaXMgbm90IGEgcGFydGljdWxhcmx5IHVzZWZ1bCBhdHRyaWJ1dGUN Cj4gdGhlc2UgZGF5cyBhbnltb3JlLCBiZWNhdXNlIHZhcmlhYmxlIGZyYW1lIHJhdGVzLCBhdCBs ZWFzdCBmb3Igc29mdHdhcmUNCj4gZW5jb2RpbmcvZGVjb2RpbmcsIGFyZSB0aGUgbm9ybS4NCj4N Cj4gSW4gcHJldmlvdXMgcG9zdHMgb24gdGhlIHBheWxvYWQgbGlzdCAoaW4gcmVzcG9uc2UgdG8g dGhlIFZQOCBwYXlsb2FkDQo+IFdHTEMpLCBJIGhhdmUgY29tbWVudGVkIG9uIHRoZSBwcmFjdGlj YWwgc2hvcnRjb21pbmdzIG9mIHRoZSAobGFjayBvZikNCj4gY29tcGxleGl0eSBuZWdvdGlhdGlv biwgYW5kIHN1Z2dlc3RlZCB0aGF0IHRoaXMgbmVlZHMgdG8gYmUgZml4ZWQuDQo+DQo+IFR3byBv cHRpb25zOg0KPg0KPiAxKSBjb2RpZnkgSGFyYWxkJ3MgbWVjaGFuaXNtIChiYXNlZCBvbiBhPWZy YW1lcmF0ZSBhbmQgaW1hZ2VhdHRyIGluIHRoZQ0KPiBWUDggcGF5bG9hZCBkcmFmdCwgYXQgTVVT VCBzdHJlbmd0aC4gICJJbiBhIGRlY2xhcmF0aXZlIGNvbnRleHQsIGENCj4gcHJvc3BlY3RpdmUg bWVkaWEgc2VuZGVyIHN1cHBvcnRpbmcgdGhpcyAoVlA4IHBheWxvYWQpIHNwZWNpZmljYXRpb24g TVVTVA0KPiBzdXBwb3J0IFJGQyA0NTY2IGE9ZnJhbWVyYXRlIGFuZCBSRkM2MjM2IGltYWdlYXR0 ciwgYW5kIE1VU1QgaW5jbHVkZSBjb2RlDQo+IHBvaW50cyBhY2NvcmRpbmcgdG8gYm90aCBtZWNo YW5pc21zIHRvIGlkZW50aWZ5IHRoZSBwcm9wZXJ0aWVzIG9mIHRoZQ0KPiBtZWRpYSBzdHJlYW0u ICBJbiBhbiBvZmZlci1hbnN3ZXIgY29udGV4dCwgYm90aCBvZmZlcmVyIGFuZCBhbnN3ZXJlcg0K PiByZWNlaXZlciBzdXBwb3J0aW5nIHRoaXMgVlA4IHBheWxvYWQgc3BlY2lmaWNhdGlvbiBNVVNU IHN1cHBvcnQNCj4gYT1mcmFtZXJ0YXRlIGFuZCBpbWFnZWF0dHIsIGFuZCBNVVNUIGluY2x1ZGUg Ym90aCBpbiB0aGVpciByZXNwZWN0aXZlDQo+IG9mZmVyL2Fuc3dlciBtZXNzYWdlcywgc28gdG8g aWRlbnRpZnkgYW4gb3BlcmF0aW9uIHBvaW50IHRoYXQgd2lsbCBub3QNCj4gb3ZlcmxvYWQgdGhl IG1lZGlhIGRlY29kZXIncyBjYXBhYmlsaXRpZXMuDQo+DQo+IFRoZSBpc3N1ZSB3aXRoIHRoaXMg YXBwcm9hY2gsIElNTywgaXMgdGhhdCB3ZSBhcmUgZGVhbGluZyBoZXJlIHdpdGggdGhyZWUNCj4g aW5kaXZpZHVhbCBjb2RlIHBvaW50cyAoZnJhbWVyYXRlLCBob3Jpem9udGFsIGFuZCB2ZXJ0aWNh bCBwaWN0dXJlIHNpemUpLA0KPiB3aGVyZSBhIHNpbmdsZSBjb2RlIHBvaW50IG91Z2h0IHRvIGJl IHN1ZmZpY2llbnQgZm9yIGRldGVybWluaW5nIHdoZXRoZXIgYQ0KPiBkqKZjb3IgaXMgY2FwYWJs ZSBvZiBkZWNvZGluZyBhIHN0cmVhbSwgYXQgbGVhc3QgZnJvbSBhIGNvbXBsZXhpdHkNCj4gdmll d3BvaW50KS4NCj4NCj4gMikgaW5jbHVkZSwgaW4gdGhlIFY4IHBheWxvYWQsIGEgbmVnb3RpYWJs ZSBTRFAgY29kZSBwb2ludCBpbmRpY2F0aW5nIHRoZQ0KPiBjb21wbGV4aXR5IG9mIGEgc3RyZWFt LCBpbiB1bml0cyBvZiBzYW1wbGVzIHBlciBzZWNvbmQgcHJvY2Vzc2luZw0KPiByZXF1aXJlbWVu dHMgb3IgYSBkZXJpdmF0aXZlIHRoZXJlb2YgKHN1Y2ggYXM6IGxldmVscyBhcyB1c2VkIGluIHRo ZSBNUEVHDQo+IHdvcmxkKS4gIEZvciBleGFtcGxlLCB0aGUgVlA4IHBheWxvYWQgY291bGQgaW5j bHVkZSBhIHNpbmdsZSwgb3B0aW9uYWwsDQo+IG5lZ290aWFibGUgcGFyYW1ldGVyICJTYW1wbGVQ ZXJTZWNvbmQiLiAgSWYgU2FtcGxlUGVyU2Vjb25kIHdlcmUgYWJzZW50IGluDQo+IHRoZSBTRFAs IGEgdmFsdWUgb2YgeHh4eHggbXVzdCBiZSBpbmZlcnJlZC4gIChhIHNlbnNpYmxlIHZhbHVlIGZv ciB4eHh4eA0KPiBjb3VsZCBiZSwgZm9yIGV4YW1wbGUgOTIxNjAwMCwgd2hpY2ggaXMgdGhlIG51 bWJlciBvZiBzYW1wbGVzIHBlciBzZWNvbmQNCj4gZm9yIFZHQSByZXNvbHV0aW9uIGF0IDMwIEh6 KS4gIElmIFNhbXBsZVBlclNlY29uZCBpcyBwcmVzZW50IGluIGENCj4gZGVjbGFyYXRpdmUgY29u dGV4dCwgaXQgaW5kaWNhdGVzIHRoZSBtaW5pbXVtIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRzIGEN Cj4gZGVjb2RlciBtdXN0IHN1cHBvcnQgaW4gb3JkZXIgdG8gc3VjY2Vzc2Z1bGx5IGRlY29kZSB0 aGUgc3RyZWFtLiAgSW4gYQ0KPiBzeW1tZXRyaWMgb2ZmZXItYW5zd2VyIGNvbnRleHQsIFNhbXBs ZVBlclNlY29uZCBjYW4gYmUgdXNlZCB0byAiZGlhbCBkb3duIg0KPiB0aGUgY29tcGxleGl0eSBv ZiB0aGUgc3RyZWFtIHRvIGEgdmFsdWUgdGhhdCBib3RoIGVuY29kZXIgYW5kIGRlY29kZXIgY2Fu DQo+IHN1cHBvcnQuDQo+DQo+IE15IHByZWZlcmVuY2UgaXMgb2J2aW91c2x5IHRoZSBzZWNvbmQg cHJvcG9zYWwsIGJ1dCBJJ20gd2lsbGluZyB0byBoZWxwDQo+IGZsZXNoaW5nIG91dCBlaXRoZXIg b3IgYm90aCBvZiB0aGVtLCBqdXN0IG5vdCB0b2RheSA6LSkNCj4NCj4gUmVnYXJkcywNCj4gU3Rl cGhhbg0KPg0KPg0KPg0KPiBPbiA0LjEzLjIwMTIgMDA6NDUgLCAiSGFyYWxkIEFsdmVzdHJhbmQi PGhhcmFsZEBhbHZlc3RyYW5kLm5vPiAgd3JvdGU6DQo+DQo+PiBPbiAwNC8xMi8yMDEyIDExOjEz IFBNLCBTdGVwaGFuIFdlbmdlciB3cm90ZToNCj4+PiBPbiA0LjEyLjIwMTIgMTI6MDggLCAiSGFy YWxkIEFsdmVzdHJhbmQiPGhhcmFsZEBhbHZlc3RyYW5kLm5vPiAgIHdyb3RlOg0KPj4+DQo+Pj4+ IE9uIDA0LzEyLzIwMTIgMDg6MTkgUE0sIFN0ZXBoYW4gV2VuZ2VyIHdyb3RlOg0KPj4+Pj4gSGkg SGFyYWxkLA0KPj4+Pj4gVGhhbmtzIGZvciB0aGlzIHN0cmF3bWFuLiAgSSBiZWxpZXZlIGl0IHNo b3VsZCB3b3JrLCBidXQgSSBmYWlsIHRvIHNlZQ0KPj4+Pj4gaG93DQo+Pj4+PiBhIHR3byBkaW1l bnNpb25hbCBuZWdvdGlhdGlvbiByZXF1aXJlbWVudCAobmVnb3RpYXRpbmcgbWF4IHZhbHVlcyBm b3INCj4+Pj4+IGZyYW1lcmF0ZSBhbmQgaW1hZ2Ugc2l6ZS0td2hpY2gsIGluIHR1cm4sIGFsc28g aGFzIHR3by1kaW1lbnNpb25hbA0KPj4+Pj4gcHJvcGVydGllcykgbGVhZHMgdG8gYmV0dGVyIGlu dGVyb3AgdGhhbiBhIG9uZSBkaW1lbnNpb25hbCBuZWdvdGlhdGlvbg0KPj4+Pj4gKHBpeGVscyBw ZXIgc2Vjb25kIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnQpLg0KPj4+PiBTdGVwaGFuLA0KPj4+Pg0K Pj4+PiBJIGRvIG5vdCBzZWUgdGhpcyAob3IgdGhlIHJlcXVpcmVtZW50IGZyb20gdGhlIHVzZS1j YXNlcyBkb2N1bWVudCkNCj4+Pj4gZmlyc3QNCj4+Pj4gYW5kIGZvcmVtb3N0IGEgZGVjb2RlciBj b21wbGV4aXR5IG5lZ290aWF0aW9uOyBpdCBpcyBhIG5lZ290aWF0aW9uIG9mDQo+Pj4+IGhvdyBt dWNoIGRhdGEgaXQgaXMgdXNlZnVsIHRvIHNlbmQsIGdpdmVuIHRoZSByZWNpcGllbnQncyBpbnRl bmRlZCB1c2UNCj4+Pj4gb2YgdGhhdCBkYXRhLg0KPj4+IFRoZW4gc3VjaCBhIG5lZ290aWF0aW9u IHNob3VsZCBiZSBleGVjdXRlZCBpbiBhZGRpdGlvbi4gIERlY29kZXIgY3ljbGUNCj4+PiByZXF1 aXJlbWVudCBkbyBtYXR0ZXIgaW4gcHJhY3RpY2FsIGltcGxlbWVudGF0aW9ucy4NCj4+IEZlZWwg ZnJlZSB0byBwcm9wb3NlIGxhbmd1YWdlIHRoYXQgY2FwdHVyZXMgdGhpcyByZXF1aXJlbWVudC4g QXMgbm90ZWQsDQo+PiBteSBJLUQgZnJhZ21lbnQgZG9lc24ndC4NCj4+DQo+Pg0KPg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF5bG9hZCBt YWlsaW5nIGxpc3QNCnBheWxvYWRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF5bG9hZA0K From ekr@rtfm.com Tue Apr 17 13:58: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 8AC4311E80D0 for ; Tue, 17 Apr 2012 13:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.418, 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 aKQ7qa+Ut7J6 for ; Tue, 17 Apr 2012 13:58:22 -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 E6DAC11E80CB for ; Tue, 17 Apr 2012 13:58:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5225740vbb.31 for ; Tue, 17 Apr 2012 13:58:21 -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=0D+zgRegR+StnSUKWGGXKdjOvyA2sVUJx8lFu8RTPwg=; b=ofwOsAEipiccCW+NG4DzABe3cIweYr9ehhFT4pUqYCergXb8JUpcWsIpCDtiRxwpXN 0TtDnnfdC9ShlYFkguTct8dIZmv65Mnx400RAVKvSZOVCt6l05tRjYXThFHSJG08/X6t 6ubdWVZIfJgh3lNykYZZhivJnRVTfZ6RtF7ZggdIunGrFUgbGcHT9QiU3b2LtnhbxAGH vJhD23dKA0TP/kbmmOuXjyudGXP4ZutlGF+14wNIodE1nNYEatUFqABr7gIJXY0cCV9p or/FIs7uW1+keFKDFm1Q7SnS2q8QTTgy/dPL6H0BNw1tf5QTV6EWZ/niBSElj+FD0iUf ycPA== Received: by 10.220.57.205 with SMTP id d13mr8842117vch.53.1334696300848; Tue, 17 Apr 2012 13:58:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 17 Apr 2012 13:57:40 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> From: Eric Rescorla Date: Tue, 17 Apr 2012 16:57:40 -0400 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk86NhkYjZVUG1BgRdEhHCFSd8F6r7FDyj+gyNeMBZz9bW2RvaxEN54hX9g2EyJEMq/mSsx Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 20:58:22 -0000 On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrote: > First of all, the chairs would are going to declare that there is WG > consensus for a 1:1:1 meeting rotation between west coast of north > america, europe, and east coast of north america and plan to run > approximately equal number of meetings in these locations. In > counting the number of past meetings in a given region, we will > include all the face to face RTCWeb and WebRTC meetings as this work > is closely joined and a large number of the participants travel to > both sets of meetings. The face to face meetings that happen at the > main IETF or W3C meetings are included in this count. Collocated > meetings will be counted just once as they only require one set of > travel to that location. Cullen, Thanks for this clarification. Just to be totally sure I understand, do you mean the following algorithm? For an interim meeting at time X, sum up all the prior meetings for each of the regions. The region with the fewest prior meetings is then selected for the next interim. [0] Is this what you guys have in mind? -Ekr [0] For extra credit, ties need to be resolved somehow. I can suggest a mechanism if you need one :) From marshall.eubanks@gmail.com Tue Apr 17 14:06: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 9C50711E80B5 for ; Tue, 17 Apr 2012 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 VNl8It13+JoH for ; Tue, 17 Apr 2012 14:06:24 -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 F0AE111E80C7 for ; Tue, 17 Apr 2012 14:06:23 -0700 (PDT) Received: by lbgc1 with SMTP id c1so704471lbg.31 for ; Tue, 17 Apr 2012 14:06: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=SsKsig1fsLalFtAbSWVAB7a33rPQQ62hP2I0R4+BxN8=; b=gFNND/AT4oS0gYnjhLMNyidMX853i6V6j97raNrZH0mcgvjQ+IdxTC7FWHBgQ1ZwtG +I7WnfpF88Y/Eg1DHMrL/KlO9cZtDtxVMKw24fNPsjrWeXDNncoB9CiVJhBRvEp2aucF 82aVYiCbEC2rLUmBl6DqloR+a9i4eQeC+xhgWMpaJCQdRAZI7I/ySD7v4uoQBOETY+3x n//AONdJZf1yE5L3QwwHoH0afFv5QmzZRaYAQSgnEXi1uqCZIc2LsSjhFqmwC6JtaWiT JnaytGfvVXGIJhzrNlMzQlnvx0WMqdepCNQt5S0lGK3iJVv5KyxVcXvIVk9hBUyhyoLd xuyw== MIME-Version: 1.0 Received: by 10.112.100.8 with SMTP id eu8mr8054514lbb.16.1334696782921; Tue, 17 Apr 2012 14:06:22 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Tue, 17 Apr 2012 14:06:22 -0700 (PDT) In-Reply-To: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> Date: Tue, 17 Apr 2012 17:06:22 -0400 Message-ID: From: Marshall Eubanks To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:06:28 -0000 On Tue, Apr 17, 2012 at 4:57 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrote= : >> First of all, the chairs would are going to declare that there is WG >> consensus for a 1:1:1 meeting rotation between west coast of north >> america, europe, and east coast of north america and plan to run >> approximately equal number of meetings in these locations. =A0In >> counting the number of past meetings in a given region, we will >> include all the face to face RTCWeb and WebRTC meetings as this work >> is closely joined and a large number of the participants travel to >> both sets of meetings. The face to face meetings that happen at the >> main IETF or W3C meetings are included in this count. Collocated >> meetings will be counted just once as they only require one set of >> travel to that location. > > Cullen, > > Thanks for this clarification. Just to be totally sure I understand, > do you mean the following algorithm? > > =A0 For an interim meeting at time X, sum up all the prior meetings > =A0 for each of the regions. The region with the fewest prior > =A0 meetings is then selected for the next interim. [0] > Which implies that Paris doesn't count. Regards Marshall > Is this what you guys have in mind? > > -Ekr > > [0] For extra credit, ties need to be resolved somehow. I can > suggest a mechanism if you need one :) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Tue Apr 17 14:10: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 1FF4611E80BD for ; Tue, 17 Apr 2012 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=0.358, 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 yTaqNd9ynLn7 for ; Tue, 17 Apr 2012 14:10:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 880CB11E80B5 for ; Tue, 17 Apr 2012 14:10:28 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so670876vcb.31 for ; Tue, 17 Apr 2012 14:10:28 -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=3k60mNP2srBmqdTH6IgdzO4unqPF9GX/S9uHPODylj8=; b=ZiF0RreppbTyuQ8OcQKQrLjps6nOeojja8KZhkoBfpBrbRc49WBfY4j2oxS+EX0nZr z+/v0tnpPwooRMqTrwjzOzeeDYHrcciFIWyMK4wiZshlfRYPK8onlAhb6Jk9H4G5L2CU /HHpl0DFTQg2lGNkPSMA8BiHzm5xJXdCZG4G3/3sRh2CSi507n6h3gv2AUoC+CPcKw63 0XAeyRC9KSJGftLjgXO44KO4IdLq9w5EpeinlZQ2hc/XLxR+P3Gvy1gnTfe2VM7UExQY 1TB6ZhoEuIYvGRoCUXZ0vi4U7UBYsKNKkySR7eeVaou4zR+CdoO/NLGlyqchy7N6yUDp oS7Q== Received: by 10.220.150.134 with SMTP id y6mr2239117vcv.43.1334697028066; Tue, 17 Apr 2012 14:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 17 Apr 2012 14:09:47 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> From: Eric Rescorla Date: Tue, 17 Apr 2012 17:09:47 -0400 Message-ID: To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkYxEhPDTIkGgH+47Os+ZXcvI6smpsGSo/eT5lH5PL1LwFQ0ykZngqcgLm2JC1GZT4KebMS Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:10:29 -0000 On Tue, Apr 17, 2012 at 5:06 PM, Marshall Eubanks wrote: > On Tue, Apr 17, 2012 at 4:57 PM, Eric Rescorla wrote: >> On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrot= e: >>> First of all, the chairs would are going to declare that there is WG >>> consensus for a 1:1:1 meeting rotation between west coast of north >>> america, europe, and east coast of north america and plan to run >>> approximately equal number of meetings in these locations. =A0In >>> counting the number of past meetings in a given region, we will >>> include all the face to face RTCWeb and WebRTC meetings as this work >>> is closely joined and a large number of the participants travel to >>> both sets of meetings. The face to face meetings that happen at the >>> main IETF or W3C meetings are included in this count. Collocated >>> meetings will be counted just once as they only require one set of >>> travel to that location. >> >> Cullen, >> >> Thanks for this clarification. Just to be totally sure I understand, >> do you mean the following algorithm? >> >> =A0 For an interim meeting at time X, sum up all the prior meetings >> =A0 for each of the regions. The region with the fewest prior >> =A0 meetings is then selected for the next interim. [0] >> > > Which implies that =A0Paris doesn't count. That's certainly not what I meant. Perhaps it would help to rewrite "next interim" as "interim X". Concretely, to select an interim meeting in mid-September, I would expect to count meetings up to and including Vancouver. -Ekr From jmpolk@cisco.com Tue Apr 17 14: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 4859F11E80B2 for ; Tue, 17 Apr 2012 14:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.367 X-Spam-Level: X-Spam-Status: No, score=-110.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 ExC+dRAgCUUF for ; Tue, 17 Apr 2012 14:15:34 -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 D723F11E80C5 for ; Tue, 17 Apr 2012 14:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1965; q=dns/txt; s=iport; t=1334697334; x=1335906934; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=1rVciZBCR78g3XzD5KtmP+p9SpaKIJqAqY/IJI94JXE=; b=DKuvFRYZz0ASI4ehrwN2vrFnzcEJUJWvSsYT7YgmeQwgJrjZDU37hJ8p GkN4LBgkOhoeWghlsPwsLYr8O164P9i+c+iecAs+VtqCv297/Adw9cRkP 5O08ON+B+vWjYmP5DEG3KRR8PLgeJNd/SF86FS7RzAcJY7F+/j7eo98tK I=; X-IronPort-AV: E=Sophos;i="4.75,438,1330905600"; d="scan'208";a="40982529" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 17 Apr 2012 21:15:34 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3HLFY5M016762; Tue, 17 Apr 2012 21:15:34 GMT Message-Id: <201204172115.q3HLFY5M016762@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Apr 2012 16:15:33 -0500 To: Eric Rescorla , Marshall Eubanks From: "James M. Polk" In-Reply-To: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:15:39 -0000 At 04:09 PM 4/17/2012, Eric Rescorla wrote: >On Tue, Apr 17, 2012 at 5:06 PM, Marshall Eubanks > wrote: > > On Tue, Apr 17, 2012 at 4:57 PM, Eric Rescorla wrote: > >> On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrote: > >>> First of all, the chairs would are going to declare that there is WG > >>> consensus for a 1:1:1 meeting rotation between west coast of north > >>> america, europe, and east coast of north america and plan to run > >>> approximately equal number of meetings in these locations. In > >>> counting the number of past meetings in a given region, we will > >>> include all the face to face RTCWeb and WebRTC meetings as this work > >>> is closely joined and a large number of the participants travel to > >>> both sets of meetings. The face to face meetings that happen at the > >>> main IETF or W3C meetings are included in this count. Collocated > >>> meetings will be counted just once as they only require one set of > >>> travel to that location. > >> > >> Cullen, > >> > >> Thanks for this clarification. Just to be totally sure I understand, > >> do you mean the following algorithm? > >> > >> For an interim meeting at time X, sum up all the prior meetings > >> for each of the regions. The region with the fewest prior > >> meetings is then selected for the next interim. [0] > >> > > > > Which implies that Paris doesn't count. > >That's certainly not what I meant. Perhaps it would help to rewrite >"next interim" as "interim X". Concretely, to select an interim meeting >in mid-September, I would expect to count meetings up to and >including Vancouver. why don't Paris and Boston (I think that was the last interim, though that might have been CLUE) count here? James >-Ekr >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Tue Apr 17 14:29: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 6AC1F21F8471 for ; Tue, 17 Apr 2012 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.664 X-Spam-Level: X-Spam-Status: No, score=-102.664 tagged_above=-999 required=5 tests=[AWL=0.313, 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 rrnmtmfRhOKV for ; Tue, 17 Apr 2012 14:29:20 -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 B80A721F846F for ; Tue, 17 Apr 2012 14:29:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5245087vbb.31 for ; Tue, 17 Apr 2012 14:29:20 -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=QdMc5czscaHTCjcB7chej6zmoLFSv1NSoAoN9azpa7o=; b=Kus/nNHIcS1a3J7KMlBKKNgkvXaZv/JKtxTjNXOGNwvgl+ZmSjgwi4aFbIFEpG3dkL aEz1xuRPC3lnPkpsosMrnkFyivBCIYGSmjte2S5K3aWYjJvXAaDNPMpma0+Ae3y0hwSv 63sVh6ecoZZlQNEIyY5KOLyPPGLSQJoOTWo2mkCbV063cOoSwVgogRZLLXa95VW4y1I4 YXFXL6ZhMCyYfXRn5LYVGzZwBidY+wQNnZGxpAUQW9CefmrKNzwWfUQdbLZK0s0238bs Kdcax8DtlNS6uHeybmmwn1hp7n2jjRah8ujnLffyAu6jeAwaBDKYZyzIkch1ft4vyUih W1qQ== Received: by 10.52.65.134 with SMTP id x6mr7210336vds.60.1334698160241; Tue, 17 Apr 2012 14:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 17 Apr 2012 14:28:40 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <201204172115.q3HLFY5M016762@mtv-core-3.cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <201204172115.q3HLFY5M016762@mtv-core-3.cisco.com> From: Eric Rescorla Date: Tue, 17 Apr 2012 17:28:40 -0400 Message-ID: To: "James M. Polk" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnkzMPOV7CLYy0bPnvUC3sFVZFptbMrve16yqtr3VuTSAuiHx+ANx3MjFSzrtRMc66ywxZf Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:29:21 -0000 On Tue, Apr 17, 2012 at 5:15 PM, James M. Polk wrote: > At 04:09 PM 4/17/2012, Eric Rescorla wrote: >> >> On Tue, Apr 17, 2012 at 5:06 PM, Marshall Eubanks >> wrote: >> > On Tue, Apr 17, 2012 at 4:57 PM, Eric Rescorla wrote: >> >> On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings >> >> wrote: >> >>> First of all, the chairs would are going to declare that there is WG >> >>> consensus for a 1:1:1 meeting rotation between west coast of north >> >>> america, europe, and east coast of north america and plan to run >> >>> approximately equal number of meetings in these locations. =A0In >> >>> counting the number of past meetings in a given region, we will >> >>> include all the face to face RTCWeb and WebRTC meetings as this work >> >>> is closely joined and a large number of the participants travel to >> >>> both sets of meetings. The face to face meetings that happen at the >> >>> main IETF or W3C meetings are included in this count. Collocated >> >>> meetings will be counted just once as they only require one set of >> >>> travel to that location. >> >> >> >> Cullen, >> >> >> >> Thanks for this clarification. Just to be totally sure I understand, >> >> do you mean the following algorithm? >> >> >> >> =A0 For an interim meeting at time X, sum up all the prior meetings >> >> =A0 for each of the regions. The region with the fewest prior >> >> =A0 meetings is then selected for the next interim. [0] >> >> >> > >> > Which implies that =A0Paris doesn't count. >> >> That's certainly not what I meant. Perhaps it would help to rewrite >> "next interim" as "interim X". Concretely, to select an interim meeting >> in mid-September, I would expect to count meetings up to and >> including Vancouver. > > > why don't Paris and Boston (I think that was the last interim, though tha= t > might have been CLUE) count here? They would. That's why I said "Up to and including". Paris was before September 2012. Obviously I'm being unclear. Here's a slightly more formal description. Each scheduled or past meeting is represented as a tuple [region, date]. E.g., Paris would be something like [Europe, 20120325] To select an interim at date X, take the subset of all meetings with date <= X and count the number in each region. To just make up some data, this would look like: { 'Europe':1, 'West Coast':2:, 'East Coast':0 } Then, select the region with the smallest number of meetings for the interim at date X. So, in this case, the interim would be held on the East Coast. For additional concretenss, iff we were executing this algorithm to select = this interim, we would be building a table of all meetings up through Paris. I.e= ., the last two would be IETF 83 and the Jan/Feb Interim in Mountain View. [I'm assuming for the purposes of this discussion that we are not counting CLUE interims, since the chairs referred to "RTCWeb and WebRTC". One detail: you need to select the interims in chronological order because = the previous interim selections obviously affect the next ones. Best, -Ekr From fluffy@cisco.com Tue Apr 17 14:33: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 9482721F8498 for ; Tue, 17 Apr 2012 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.48 X-Spam-Level: X-Spam-Status: No, score=-109.48 tagged_above=-999 required=5 tests=[AWL=1.119, 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 Tp0sDCljTgT0 for ; Tue, 17 Apr 2012 14:33:17 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 69D4A21F8497 for ; Tue, 17 Apr 2012 14:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1676; q=dns/txt; s=iport; t=1334698397; x=1335907997; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kg7DDSenLQFl1qADeFv15bmOCtJdJw5Ygb3mdaX5rjo=; b=fK8qyG2MuPdSnePIMmF+7yr8umO8Qp77ui53KgMicgOuTMlpURJXJALj /77KkZgBYKF2DytD/F+GxJcL2pDMZsKSyyX1ureMhjWw9UwKmJY44uYta nrEjZVJJH8j7tmC4KgYGwEnbJ5SOFfp4bL94gh/RMPDqoHPei2cQYH/el w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAAPhjU+rRDoG/2dsb2JhbABEgxyuIYEHggkBAQEDARIBJy8BDwULCw4KLlcGEyKHZwSaA592kABjBIhcjROFcohbgWmDBg X-IronPort-AV: E=Sophos;i="4.75,438,1330905600"; d="scan'208";a="40893659" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 17 Apr 2012 21:33:17 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3HLXGvb010142; Tue, 17 Apr 2012 21:33:16 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 17 Apr 2012 15:33:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2382D535-6C12-4809-A528-5D388BCE572D@cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> To: "Eric Rescorla" X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:33:21 -0000 On Apr 17, 2012, at 2:57 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings = wrote: > > First of all, the chairs would are going to declare that there is WG > > consensus for a 1:1:1 meeting rotation between west coast of north > > america, europe, and east coast of north america and plan to run > > approximately equal number of meetings in these locations. In > > counting the number of past meetings in a given region, we will > > include all the face to face RTCWeb and WebRTC meetings as this work > > is closely joined and a large number of the participants travel to > > both sets of meetings. The face to face meetings that happen at the > > main IETF or W3C meetings are included in this count. Collocated > > meetings will be counted just once as they only require one set of > > travel to that location. >=20 > Cullen, >=20 > Thanks for this clarification. Just to be totally sure I understand, > do you mean the following algorithm? >=20 > For an interim meeting at time X, sum up all the prior meetings > for each of the regions. The region with the fewest prior > meetings is then selected for the next interim. [0] >=20 > Is this what you guys have in mind? >=20 > -Ekr >=20 > [0] For extra credit, ties need to be resolved somehow. I can > suggest a mechanism if you need one :) >=20 Yes - that is what I was thinking and I had not really thought much = about ties. So unless you want a maximally self serving tie breaking = algorithm of selecting the location closest to YYC, it would be great if = someone could suggest the tie breaking algorithm.=20 Cullen From jmpolk@cisco.com Tue Apr 17 14:39: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 39E7C11E8089 for ; Tue, 17 Apr 2012 14:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.418 X-Spam-Level: X-Spam-Status: No, score=-110.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 hS3Y-1TNDbc2 for ; Tue, 17 Apr 2012 14:39:17 -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 DA2B211E80A6 for ; Tue, 17 Apr 2012 14:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3670; q=dns/txt; s=iport; t=1334698757; x=1335908357; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=nml67H0haZLAyw5ygQGuQDfErzRMsDmeSxp0syGIZdA=; b=lUCg1y0KRkr5+djgavpuYnH6C+J+Pxlszuu1biLzyLNiaiiYrw6vTwug h0SdJbwcLtJU253L0wVqGTpTuihlEgNy5rcIR0BcSxeT6Ne3n5WwfB7gy fN/mygZnMKKjS+8uUI7kZAg7aT/vb4ufYyAWfB92mYP4ydVO330QOL+9s Y=; X-IronPort-AV: E=Sophos;i="4.75,438,1330905600"; d="scan'208";a="37872507" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Apr 2012 21:39:17 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3HLdHJB012574; Tue, 17 Apr 2012 21:39:17 GMT Message-Id: <201204172139.q3HLdHJB012574@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Apr 2012 16:39:17 -0500 To: Eric Rescorla , "James M. Polk" From: "James M. Polk" In-Reply-To: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <201204172115.q3HLFY5M016762@mtv-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:39:22 -0000 At 04:28 PM 4/17/2012, Eric Rescorla wrote: >On Tue, Apr 17, 2012 at 5:15 PM, James M. Polk wrote: > > At 04:09 PM 4/17/2012, Eric Rescorla wrote: > >> > >> On Tue, Apr 17, 2012 at 5:06 PM, Marshall Eubanks > >> wrote: > >> > On Tue, Apr 17, 2012 at 4:57 PM, Eric Rescorla wrote: > >> >> On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings > >> >> wrote: > >> >>> First of all, the chairs would are going to declare that there is WG > >> >>> consensus for a 1:1:1 meeting rotation between west coast of north > >> >>> america, europe, and east coast of north america and plan to run > >> >>> approximately equal number of meetings in these locations. In > >> >>> counting the number of past meetings in a given region, we will > >> >>> include all the face to face RTCWeb and WebRTC meetings as this work > >> >>> is closely joined and a large number of the participants travel to > >> >>> both sets of meetings. The face to face meetings that happen at the > >> >>> main IETF or W3C meetings are included in this count. Collocated > >> >>> meetings will be counted just once as they only require one set of > >> >>> travel to that location. > >> >> > >> >> Cullen, > >> >> > >> >> Thanks for this clarification. Just to be totally sure I understand, > >> >> do you mean the following algorithm? > >> >> > >> >> For an interim meeting at time X, sum up all the prior meetings > >> >> for each of the regions. The region with the fewest prior > >> >> meetings is then selected for the next interim. [0] > >> >> > >> > > >> > Which implies that Paris doesn't count. > >> > >> That's certainly not what I meant. Perhaps it would help to rewrite > >> "next interim" as "interim X". Concretely, to select an interim meeting > >> in mid-September, I would expect to count meetings up to and > >> including Vancouver. > > > > > > why don't Paris and Boston (I think that was the last interim, though that > > might have been CLUE) count here? > >They would. That's why I said "Up to and including". Paris was before >September 2012. > >Obviously I'm being unclear. No, I think I knew what you wanted to get to the first time, but what you have below articulates it quite nicely though. And, as you pointed out, we need a means for solving for ties - mostly because the goal of this is to have a tied once a year between 3 (if we keep the 1:1:1 format), then once a year between 2, right? James >Here's a slightly more formal description. > >Each scheduled or past meeting is represented as a tuple [region, date]. >E.g., Paris would be something like [Europe, 20120325] > >To select an interim at date X, take the subset of all meetings with date < X >and count the number in each region. To just make up some data, this >would look like: > >{ > 'Europe':1, > 'West Coast':2:, > 'East Coast':0 >} > >Then, select the region with the smallest number of meetings for the >interim at date X. >So, in this case, the interim would be held on the East Coast. > >For additional concretenss, iff we were executing this algorithm to >select this >interim, we would be building a table of all meetings up through Paris. I.e., >the last two would be IETF 83 and the Jan/Feb Interim in Mountain View. >[I'm assuming for the purposes of this discussion that we are not counting >CLUE interims, since the chairs referred to "RTCWeb and WebRTC". > >One detail: you need to select the interims in chronological order because the >previous interim selections obviously affect the next ones. > >Best, >-Ekr From jmpolk@cisco.com Tue Apr 17 14:44: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 A6DB311E80AD for ; Tue, 17 Apr 2012 14:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.436 X-Spam-Level: X-Spam-Status: No, score=-110.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 efZ6SAdccjPn for ; Tue, 17 Apr 2012 14:44:21 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3AA11E80A6 for ; Tue, 17 Apr 2012 14:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2420; q=dns/txt; s=iport; t=1334699061; x=1335908661; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=Yp5tL+CHMrTzDusCRSy6aHZzoGv/OBQxhXeihT0OESU=; b=Q+YOZnADMY/mMXApsx/NHqMbHHJ50dMr/xbaq3sVuBfxx53hni5ykOgN xtwJMDKEp+u31jOFgnqT2j3LS+/bnizPQuQmwT16IWhMcHUB0aUkm2Gvw 1iUYhKwdCbyKlveEcjB19bOoo3l8SJwDh+Ut8SWL7vMuZZ45M1Wb466r0 8=; X-IronPort-AV: E=Sophos;i="4.75,438,1330905600"; d="scan'208";a="40895182" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Apr 2012 21:44:21 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3HLiK0A029679; Tue, 17 Apr 2012 21:44:20 GMT Message-Id: <201204172144.q3HLiK0A029679@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Apr 2012 16:44:20 -0500 To: Cullen Jennings , "Eric Rescorla" From: "James M. Polk" In-Reply-To: <2382D535-6C12-4809-A528-5D388BCE572D@cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <2382D535-6C12-4809-A528-5D388BCE572D@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:44:25 -0000 At 04:33 PM 4/17/2012, Cullen Jennings wrote: >On Apr 17, 2012, at 2:57 PM, Eric Rescorla wrote: > > > On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrote: > > > First of all, the chairs would are going to declare that there is WG > > > consensus for a 1:1:1 meeting rotation between west coast of north > > > america, europe, and east coast of north america and plan to run > > > approximately equal number of meetings in these locations. In > > > counting the number of past meetings in a given region, we will > > > include all the face to face RTCWeb and WebRTC meetings as this work > > > is closely joined and a large number of the participants travel to > > > both sets of meetings. The face to face meetings that happen at the > > > main IETF or W3C meetings are included in this count. Collocated > > > meetings will be counted just once as they only require one set of > > > travel to that location. > > > > Cullen, > > > > Thanks for this clarification. Just to be totally sure I understand, > > do you mean the following algorithm? > > > > For an interim meeting at time X, sum up all the prior meetings > > for each of the regions. The region with the fewest prior > > meetings is then selected for the next interim. [0] > > > > Is this what you guys have in mind? > > > > -Ekr > > > > [0] For extra credit, ties need to be resolved somehow. I can > > suggest a mechanism if you need one :) > > > >Yes - that is what I was thinking and I had not really thought much >about ties. So unless you want a maximally self serving tie breaking >algorithm of selecting the location closest to YYC, it would be >great if someone could suggest the tie breaking algorithm. how about the previous and next IETF meetings disqualify that location (and potentially each location). Something like that should work in favor of covering the currently least travelled to location (in theory). I.e., last was Europe, next is West Coast NA, that means this interim must be on east coast NA (sorry Magnus ;-) perhaps this one ought to be that Europe now can't be for a year, because it is getting two RTCweb meetings in a row (Paris in March and Stockholm in June). James >Cullen > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Tue Apr 17 14:48: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 DC71C11E80AD for ; Tue, 17 Apr 2012 14:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=0.278, 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 K7VuziDogVwb for ; Tue, 17 Apr 2012 14:48:55 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5569711E8086 for ; Tue, 17 Apr 2012 14:48:55 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so694763vcb.31 for ; Tue, 17 Apr 2012 14:48:54 -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=m+OMUS/c2EcgQoaCeEY1421xOtkUxs7Ejs3LITzMQk0=; b=Vb9TarsT28ycbQmygBgk5q/9yLz0bfqwr2xe/c6ftnxpOBXqLYi1z/sFXh08RooObw 63vdQIofREFn28F2aAuZJMBzNiD7p/P8bXDhUvQBMlokX12mbS3ZgNkk3CNqXrIXmuxA 7UWIN+HVq2IkuRN/AisySVZQw7Bm1obJJv1xt1ZY9TizOr8YZj8xApK7hIK75RsPrsxU zUBikz+97+MTs0j7HS/aX398bE6PIy1u/enuckAhWfCGMuFzV15UjIeHNUU2OhIqDd4Z L1R640guYovoynialQjHHI32cHJu+mYarrVaVzbtmGmP+idE1aWew562mQglwpjIgl28 2FsQ== Received: by 10.220.106.144 with SMTP id x16mr8967563vco.63.1334699334645; Tue, 17 Apr 2012 14:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 17 Apr 2012 14:48:14 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <2382D535-6C12-4809-A528-5D388BCE572D@cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <2382D535-6C12-4809-A528-5D388BCE572D@cisco.com> From: Eric Rescorla Date: Tue, 17 Apr 2012 17:48:14 -0400 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm8Uk3kdxnZjGWOQZ9Rogtvhte8WZAL3k4rRzS+sUrG8eni0e3AiFbGNVdaCw5R30a39ZD6 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 21:48:56 -0000 On Tue, Apr 17, 2012 at 5:33 PM, Cullen Jennings wrote: > > On Apr 17, 2012, at 2:57 PM, Eric Rescorla wrote: > Yes - that is what I was thinking and I had not really thought much about= ties. So unless you want a maximally self serving tie breaking algorithm o= f selecting the location closest to YYC, it would be great if someone could= suggest the tie breaking algorithm. I would suggest picking the region (in the equivalence set) we were at least recently in the case of ties. -Ekr From Jim.Barnett@genesyslab.com Tue Apr 17 15:48: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 7A46421F852D for ; Tue, 17 Apr 2012 15:48:03 -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.151, 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 x8mG3RSyEzPo for ; Tue, 17 Apr 2012 15:47:59 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC8921F852C for ; Tue, 17 Apr 2012 15:47:59 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q3HMluIc014019; Tue, 17 Apr 2012 15:47:57 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 15:47:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 15:47:55 -0700 Message-ID: In-Reply-To: <2382D535-6C12-4809-A528-5D388BCE572D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Update of future interim meeting locations Thread-Index: Ac0c4bhVd25oO3VdRY+HLO7DY09FQwACin1g References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <2382D535-6C12-4809-A528-5D388BCE572D@cisco.com> From: "Jim Barnett" To: "Cullen Jennings" , "Eric Rescorla" X-OriginalArrivalTime: 17 Apr 2012 22:47:57.0375 (UTC) FILETIME=[221C44F0:01CD1CEC] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 22:48:03 -0000 Possible tie-breaking algorithm: If season=3D=3Dsummer =3D=3D> Europe elsif season=3D=3Dwinter =3D=3D> west coast elsif season=3D=3Dsorta-in-between =3D=3D> east coast -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, April 17, 2012 5:33 PM To: Eric Rescorla Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations On Apr 17, 2012, at 2:57 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrote: > > First of all, the chairs would are going to declare that there is WG > > consensus for a 1:1:1 meeting rotation between west coast of north=20 > > america, europe, and east coast of north america and plan to run=20 > > approximately equal number of meetings in these locations. In=20 > > counting the number of past meetings in a given region, we will=20 > > include all the face to face RTCWeb and WebRTC meetings as this work > > is closely joined and a large number of the participants travel to=20 > > both sets of meetings. The face to face meetings that happen at the=20 > > main IETF or W3C meetings are included in this count. Collocated=20 > > meetings will be counted just once as they only require one set of=20 > > travel to that location. >=20 > Cullen, >=20 > Thanks for this clarification. Just to be totally sure I understand,=20 > do you mean the following algorithm? >=20 > For an interim meeting at time X, sum up all the prior meetings > for each of the regions. The region with the fewest prior > meetings is then selected for the next interim. [0] >=20 > Is this what you guys have in mind? >=20 > -Ekr >=20 > [0] For extra credit, ties need to be resolved somehow. I can suggest=20 > a mechanism if you need one :) >=20 Yes - that is what I was thinking and I had not really thought much about ties. So unless you want a maximally self serving tie breaking algorithm of selecting the location closest to YYC, it would be great if someone could suggest the tie breaking algorithm.=20 Cullen _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Wed Apr 18 00:27: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 4C1BE21F85E7 for ; Wed, 18 Apr 2012 00:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 0bghCQQ56YAA for ; Wed, 18 Apr 2012 00:27:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECE321F85A0 for ; Wed, 18 Apr 2012 00:27:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A6F239E151; Wed, 18 Apr 2012 09:27:28 +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 zQ3mH5vRo6xu; Wed, 18 Apr 2012 09:27:23 +0200 (CEST) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2BDC039E112; Wed, 18 Apr 2012 09:27:23 +0200 (CEST) Message-ID: <4F8E6CDA.2010507@alvestrand.no> Date: Wed, 18 Apr 2012 09:27:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 07:27:38 -0000 1) I'd like to let the chairs have some flexibility 2) It's important when we start counting, too So far, my current list of meetings for this WG starts off with the October 2010 unofficial get-together, and has 1 interim meeting on it: Jan/Feb 2012, in Mountain View. Inbetween are 5 meetings at IETFs including the BOF. That makes my count: NA-West: 2 (both interims) NA-East: 1 Europe: 2 Asia: 2 The next 3 IETF meetings are 1 NA-West and 2 NA-East, so after that set plus the upcoming Europe interim, we'll have: NA-West: 3 NA-East: 3 Europe: 3 Asia: 2 Not too uneven. But just after the upcoming interim, it will seem like the maths of the situation should definitely force the chairs to schedule an NA-East interim; I'd like the chairs to have leeway about that. On 04/17/2012 10:57 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrote: >> First of all, the chairs would are going to declare that there is WG >> consensus for a 1:1:1 meeting rotation between west coast of north >> america, europe, and east coast of north america and plan to run >> approximately equal number of meetings in these locations. In >> counting the number of past meetings in a given region, we will >> include all the face to face RTCWeb and WebRTC meetings as this work >> is closely joined and a large number of the participants travel to >> both sets of meetings. The face to face meetings that happen at the >> main IETF or W3C meetings are included in this count. Collocated >> meetings will be counted just once as they only require one set of >> travel to that location. > Cullen, > > Thanks for this clarification. Just to be totally sure I understand, > do you mean the following algorithm? > > For an interim meeting at time X, sum up all the prior meetings > for each of the regions. The region with the fewest prior > meetings is then selected for the next interim. [0] > > Is this what you guys have in mind? > > -Ekr > > [0] For extra credit, ties need to be resolved somehow. I can > suggest a mechanism if you need one :) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From HKaplan@acmepacket.com Wed Apr 18 01:57: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 CA4CA21F84DA for ; Wed, 18 Apr 2012 01:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 QGmxeDwuROTu for ; Wed, 18 Apr 2012 01:57:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCE321F85A5 for ; Wed, 18 Apr 2012 01:57:51 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 18 Apr 2012 04:57:49 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.36]) with mapi id 14.02.0283.003; Wed, 18 Apr 2012 04:57:49 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] Update of future interim meeting locations Thread-Index: AQHNHNz2R5ucuaVuz0iZUkOoRobI+JagcrcA///WN5s= Date: Wed, 18 Apr 2012 08:57:48 +0000 Message-ID: <6C772188-B4EA-4363-A780-8731BC999F42@acmepacket.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> , <4F8E6CDA.2010507@alvestrand.no> In-Reply-To: <4F8E6CDA.2010507@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 08:57:55 -0000 This is all getting a little silly isn't it? :) The real issue is we have two WG chairs from NA-West and one from Europe - = there is no fair representation from NA-East!! (kidding) -hadriel Sent from my iPhone On Apr 18, 2012, at 3:27 AM, "Harald Alvestrand" wro= te: > 1) I'd like to let the chairs have some flexibility > 2) It's important when we start counting, too >=20 > So far, my current list of meetings for this WG starts off with the Octob= er 2010 unofficial get-together, and has 1 interim meeting on it: Jan/Feb 2= 012, in Mountain View. >=20 > Inbetween are 5 meetings at IETFs including the BOF. >=20 > That makes my count: >=20 > NA-West: 2 (both interims) > NA-East: 1 > Europe: 2 > Asia: 2 >=20 > The next 3 IETF meetings are 1 NA-West and 2 NA-East, so after that set p= lus the upcoming Europe interim, we'll have: >=20 > NA-West: 3 > NA-East: 3 > Europe: 3 > Asia: 2 >=20 > Not too uneven. But just after the upcoming interim, it will seem like th= e maths of the situation should definitely force the chairs to schedule an = NA-East interim; I'd like the chairs to have leeway about that. >=20 > On 04/17/2012 10:57 PM, Eric Rescorla wrote: >> On Mon, Apr 16, 2012 at 3:45 PM, Cullen Jennings wrot= e: >>> First of all, the chairs would are going to declare that there is WG >>> consensus for a 1:1:1 meeting rotation between west coast of north >>> america, europe, and east coast of north america and plan to run >>> approximately equal number of meetings in these locations. In >>> counting the number of past meetings in a given region, we will >>> include all the face to face RTCWeb and WebRTC meetings as this work >>> is closely joined and a large number of the participants travel to >>> both sets of meetings. The face to face meetings that happen at the >>> main IETF or W3C meetings are included in this count. Collocated >>> meetings will be counted just once as they only require one set of >>> travel to that location. >> Cullen, >>=20 >> Thanks for this clarification. Just to be totally sure I understand, >> do you mean the following algorithm? >>=20 >> For an interim meeting at time X, sum up all the prior meetings >> for each of the regions. The region with the fewest prior >> meetings is then selected for the next interim. [0] >>=20 >> Is this what you guys have in mind? >>=20 >> -Ekr >>=20 >> [0] For extra credit, ties need to be resolved somehow. I can >> suggest a mechanism if you need one :) >> _______________________________________________ >> 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 From ekr@rtfm.com Wed Apr 18 08:01: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 9F5E921F85CC for ; Wed, 18 Apr 2012 08:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[AWL=0.228, 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 esp++uGZAGcd for ; Wed, 18 Apr 2012 08:01:25 -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 9F35921F84F0 for ; Wed, 18 Apr 2012 08:01:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5819530vbb.31 for ; Wed, 18 Apr 2012 08:01:25 -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=O4FS9ArA0u5uTdY+5Lw5U60O3vmJdxYD+8KQHpjzaMU=; b=RZ/CJkuj3OIYxIibB+M4jZd2jJOeZDZyjjmIpikQX3fbKKgGmTnoW7KfQcZsOjvsyK VYcBrPyyVEgmaKhWO3z3BXEFPG4vVoamuhBvIe7puI6G7zgvqm8nvjPewLFyTC9Plzuh 2XjiCNfAlanZOQ4S1eBTBef0CYSIMmX8VS6Q+xMZjkayvaqqshpiA5uozFDqKLDSBaUn x4/YyeB1txRCRnxANLOCDtPHYONJdeZ1itcIZ8XWhtBZoY+SyRf5WZjgbRH2HkWhEWRz tJbJVYOG/UUjQy0LyZeFMI6zDpHQ0ikwAlnH/AmRyQzN1RQH1VMnHRHFg3PcesHydJvR k5hg== Received: by 10.52.65.134 with SMTP id x6mr1092237vds.60.1334761284907; Wed, 18 Apr 2012 08:01:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Wed, 18 Apr 2012 08:00:43 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F8E6CDA.2010507@alvestrand.no> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <4F8E6CDA.2010507@alvestrand.no> From: Eric Rescorla Date: Wed, 18 Apr 2012 08:00:43 -0700 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnVjTbUkee1bLfr8VD7sEWbaCOKEL76M60mlRRWyAYoyPupYaw2MPOoIgBWTV38OxE5Sr99 Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 15:01:26 -0000 On Wed, Apr 18, 2012 at 12:27 AM, Harald Alvestrand wrote: > 1) I'd like to let the chairs have some flexibility Frankly, I'm a lot less interested in the chairs having some flexibility than predictability. As it stands now, we're in the position of being less than 8 weeks out from the proposed interim and still not knowing whether it's happening or when or where it will be. Cullens last message says that the chairs will "try and confirm" Stockholm for June 12-13, but I for one don't want to plan a couple thousand dollars worth of travel on "try and confirm." We know precisely when the IETF and W3C meetings are for the next year or so, so there's really nothing that stops the chairs from promulgating a policy and then announcing the locations of the meetings now. From andrew.hutton@siemens-enterprise.com Wed Apr 18 08:27: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 6D66B21F84BF for ; Wed, 18 Apr 2012 08:27:05 -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 DpHh76EcSIh0 for ; Wed, 18 Apr 2012 08:27:01 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91521F8607 for ; Wed, 18 Apr 2012 08:27:01 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8F5AB23F0420; Wed, 18 Apr 2012 17:26:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 18 Apr 2012 17:26:59 +0200 From: "Hutton, Andrew" To: Eric Rescorla , Harald Alvestrand Date: Wed, 18 Apr 2012 17:26:58 +0200 Thread-Topic: [rtcweb] Update of future interim meeting locations Thread-Index: Ac0ddCUgdEfyLX8aRR6gE+m9kY3rugAAnKyg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312991106D3@MCHP058A.global-ad.net> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <4F8E6CDA.2010507@alvestrand.no> 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 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 15:27:05 -0000 Hi, Totally agree with Eric what I want is to be able to plan my time and budge= t well in advance and the main thing I need to know is the date. If the choice is between Europe, NA-West and NA-East then flight costs and = time tend not to be very variable. The main variable is actually hotel costs so just choose somewhere that is = close to a major international airport and that has reasonable hotel prices= and let us know well in advance. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: 18 April 2012 16:01 > To: Harald Alvestrand > Cc: Cullen Jennings; rtcweb@ietf.org > Subject: Re: [rtcweb] Update of future interim meeting locations >=20 > On Wed, Apr 18, 2012 at 12:27 AM, Harald Alvestrand > wrote: > > 1) I'd like to let the chairs have some flexibility >=20 > Frankly, I'm a lot less interested in the chairs having some > flexibility than > predictability. >=20 > As it stands now, we're in the position of being less than 8 weeks out > from the proposed interim and still not knowing whether it's happening > or when or where it will be. Cullens last message says that the chairs > will > "try and confirm" Stockholm for June 12-13, but I for one don't > want to plan a couple thousand dollars worth of travel on > "try and confirm." >=20 > We know precisely when the IETF and W3C meetings are for the next > year or so, so there's really nothing that stops the chairs from > promulgating > a policy and then announcing the locations of the meetings now. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Wed Apr 18 09:10: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 B82B121E8013 for ; Wed, 18 Apr 2012 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.111 X-Spam-Level: X-Spam-Status: No, score=-110.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 O+9sJOQhkuif for ; Wed, 18 Apr 2012 09:10:41 -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 531C311E8081 for ; Wed, 18 Apr 2012 09:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2202; q=dns/txt; s=iport; t=1334765441; x=1335975041; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/RhjmRu+n0FWs5lzKgZTMTAwSHO1gK3qeHB9z7Eua6I=; b=Jp0dkeLq5IcBXAQbZfJ1MoBAJrqX+ZFuatIE9nQWIDntEqQTOojUxICN R8dkv1ZzUnn8hXKQcH9p1PXjAnG154ULoPpcmOW35k9FHS6Oz+iIPwa4E SyPqppeyD3zjcQJw4jK0rd2y5f0cKCrdTU9mQ4TcfXjUGtE4dGYz4XMc7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUGAM7mjk+rRDoH/2dsb2JhbABEgxyuJIEHggkBAQEDAQEBAQ8BJzAECwUHBAsRBAEBAScHJx8JCAYTIodoBAyafqAcBI84TWMEiFyNE4VziF6BaYMG X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="38530753" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Apr 2012 16:10:40 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3IGAdOi032293; Wed, 18 Apr 2012 16:10:39 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312991106D3@MCHP058A.global-ad.net> Date: Wed, 18 Apr 2012 10:10:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <4F8E6CDA.2010507@alvestrand.no> <101C6067BEC68246B0C3F6843BCCC1E312991106D3@MCHP058A.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 16:10:45 -0000 +1 Eric and Andy.=20 I don't think the chairs need flexibility - Flexible chairs tend to not = be a pretty unstable.=20 On Apr 18, 2012, at 9:26 AM, Hutton, Andrew wrote: > Hi, >=20 > Totally agree with Eric what I want is to be able to plan my time and = budget well in advance and the main thing I need to know is the date. >=20 > If the choice is between Europe, NA-West and NA-East then flight costs = and time tend not to be very variable. >=20 > The main variable is actually hotel costs so just choose somewhere = that is close to a major international airport and that has reasonable = hotel prices and let us know well in advance. >=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: 18 April 2012 16:01 >> To: Harald Alvestrand >> Cc: Cullen Jennings; rtcweb@ietf.org >> Subject: Re: [rtcweb] Update of future interim meeting locations >>=20 >> On Wed, Apr 18, 2012 at 12:27 AM, Harald Alvestrand >> wrote: >>> 1) I'd like to let the chairs have some flexibility >>=20 >> Frankly, I'm a lot less interested in the chairs having some >> flexibility than >> predictability. >>=20 >> As it stands now, we're in the position of being less than 8 weeks = out >> from the proposed interim and still not knowing whether it's = happening >> or when or where it will be. Cullens last message says that the = chairs >> will >> "try and confirm" Stockholm for June 12-13, but I for one don't >> want to plan a couple thousand dollars worth of travel on >> "try and confirm." >>=20 >> We know precisely when the IETF and W3C meetings are for the next >> year or so, so there's really nothing that stops the chairs from >> promulgating >> a policy and then announcing the locations of the meetings now. >> _______________________________________________ >> 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 fluffy@cisco.com Wed Apr 18 09:30: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 53CC521F8570 for ; Wed, 18 Apr 2012 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 ANU+zmgE7dmd for ; Wed, 18 Apr 2012 09:30:25 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFE411E8085 for ; Wed, 18 Apr 2012 09:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=300; q=dns/txt; s=iport; t=1334766625; x=1335976225; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aiwTRoN95kmB/fPpKmkYAU91w4DPlz4vbespBktKal0=; b=jKF4KxsJvbHrXQjqhuTQ7cofspDSQ5nZeKyyCmeUiStFyCTBATIfE/1x eaq2LTNqXt5nbpuc4Ml/xb7n1Lz4FJGET7Xe6gu3tVLiq4K7/KncPWuut HkMNlQ7jYC/n1hanofOwOuK+OXmD+BFEINXzmmVoytzkNc61nTbV+3J6g U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAKXrjk+rRDoI/2dsb2JhbABEgxyuJIEHggkBAQEDARIBJz8FCwsOOFcGNYdoBJsMoCGQBWMEiFyNE4VziF6BaYMG X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="41019347" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 18 Apr 2012 16:30:25 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3IGUO1k007263; Wed, 18 Apr 2012 16:30:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <6C772188-B4EA-4363-A780-8731BC999F42@acmepacket.com> Date: Wed, 18 Apr 2012 10:30:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com>, <4F8E6CDA.2010507@alvestrand.no> <6C772188-B4EA-4363-A780-8731BC999F42@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 16:30:29 -0000 On Apr 18, 2012, at 2:57 AM, Hadriel Kaplan wrote: > This is all getting a little silly isn't it? :) > The real issue is we have two WG chairs from NA-West and one from = Europe - there is no fair representation from NA-East!! (kidding) >=20 > -hadriel I nominate Hadriel for chair :-) From martin.thomson@gmail.com Wed Apr 18 11:22: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 7AE9221F8476 for ; Wed, 18 Apr 2012 11:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.868 X-Spam-Level: X-Spam-Status: No, score=-3.868 tagged_above=-999 required=5 tests=[AWL=-0.269, 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 4ueccGi2YmCL for ; Wed, 18 Apr 2012 11:22:07 -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 AB1EE21F8470 for ; Wed, 18 Apr 2012 11:22:06 -0700 (PDT) Received: by bkuw5 with SMTP id w5so7110938bku.31 for ; Wed, 18 Apr 2012 11:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7TC4kDS/tK5p2PmYKztATBe7IknQ3UmNsGk0s3/FfJU=; b=oMHHDxa2W6CMQCaAsLgWCliH9FccnGUsnaVRQBhOwF9HBlmbK4ZLp/+IYF+Uu1lpfN ufkMBXWfoJ5P2P4XZM2t4pzXdN6TPlFOebpoAAmtA8uNtQ+zkybtqnH1PFl7gUPHIIQE JBsruduMzI/svfkb/LJN+A2rYEocwHRsc2t1OdDMeGlclWTGbo+BYgW2tulUch57psvi LmO30RVTY80wvH39ha+OCd3eUt2+LbMeLNGDQNPBOBokIGUswBTvy9kyB+2LpqxmO1vf ZBU58lXDGcfASf90bChV0PuB+J/uzaikGhWQty6kpCkOUuaNKDMTn2+Y0sWsdtJ5FliZ JZrA== MIME-Version: 1.0 Received: by 10.205.138.9 with SMTP id iq9mr1002993bkc.139.1334773325783; Wed, 18 Apr 2012 11:22:05 -0700 (PDT) Received: by 10.204.165.66 with HTTP; Wed, 18 Apr 2012 11:22:05 -0700 (PDT) In-Reply-To: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <4F8E6CDA.2010507@alvestrand.no> <6C772188-B4EA-4363-A780-8731BC999F42@acmepacket.com> Date: Wed, 18 Apr 2012 11:22:05 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 18:22:07 -0000 On 18 April 2012 09:30, Cullen Jennings wrote: >> The real issue is we have two WG chairs from NA-West and one from Europe= - there is no fair representation from NA-East!! =C2=A0(kidding) >> >> -hadriel > > I nominate Hadriel for chair :-) Seconded. It sounds like one of the NA-West chairs would have to step down to make this work though ;) From fluffy@cisco.com Wed Apr 18 12:55: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 A831E11E8094 for ; Wed, 18 Apr 2012 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 QtFeq+uch8bl for ; Wed, 18 Apr 2012 12:55:31 -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 8619711E8089 for ; Wed, 18 Apr 2012 12:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=500; q=dns/txt; s=iport; t=1334778931; x=1335988531; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vns7JATj7whLgZ6Jccc88vJM26SfJm1w6kqQPJgfOqY=; b=bZYdpp1xD8jneK+KVitZrBZqwXZ6lbGpf/wi4jT1WHDk50Mlo7laVvso yOR+9M3qIB7xFHq6+gwF6ge2Zm4+uRBIo3gsHmI2h8HL2S1ff5VgnC8st 5rxfbPfrbM3ECOHmuIRAlGVJXuC8aGXcgS/ZfMaUgVftMnM8QUwv2u/TZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGAJgbj0+rRDoG/2dsb2JhbABEgxyuJYEHggkBAQEDARIBJz8FCwsYLlcGEyKHaASadaAmj1JjBIhcjROFc4hegWmDBg X-IronPort-AV: E=Sophos;i="4.75,443,1330905600"; d="scan'208";a="38569825" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 18 Apr 2012 19:55:31 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3IJtUC0019946; Wed, 18 Apr 2012 19:55:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 18 Apr 2012 13:55:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <4F8E6CDA.2010507@alvestrand.no> <6C772188-B4EA-4363-A780-8731BC999F42@acmepacket.com> To: Martin Thomson X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 19:55:35 -0000 On Apr 18, 2012, at 12:22 PM, Martin Thomson wrote: > On 18 April 2012 09:30, Cullen Jennings wrote: >>> The real issue is we have two WG chairs from NA-West and one from = Europe - there is no fair representation from NA-East!! (kidding) >>>=20 >>> -hadriel >>=20 >> I nominate Hadriel for chair :-) >=20 > Seconded. It sounds like one of the NA-West chairs would have to step > down to make this work though ;) Note my phrasing was "chair", not "co-chair"=20 From HKaplan@acmepacket.com Wed Apr 18 15:06: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 DBF6511E809D for ; Wed, 18 Apr 2012 15:06:47 -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 llZ8t9aHTaG8 for ; Wed, 18 Apr 2012 15:06:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 81CE211E8091 for ; Wed, 18 Apr 2012 15:06:46 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 18 Apr 2012 18:06:45 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.36]) with mapi id 14.02.0283.003; Wed, 18 Apr 2012 18:06:45 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [rtcweb] Update of future interim meeting locations Thread-Index: AQHNHNz2R5ucuaVuz0iZUkOoRobI+A== Date: Wed, 18 Apr 2012 22:06:43 +0000 Message-ID: <16BDC3C1-3304-470B-AD6B-69E9C88BC185@acmepacket.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com>, <4F8E6CDA.2010507@alvestrand.no> <6C772188-B4EA-4363-A780-8731BC999F42@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <73103C1EA88D2647AE238B0017B2E2AF@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Update of future interim meeting locations 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 Apr 2012 22:06:48 -0000 On Apr 18, 2012, at 12:30 PM, Cullen Jennings wrote: > On Apr 18, 2012, at 2:57 AM, Hadriel Kaplan wrote: >=20 >> This is all getting a little silly isn't it? :) >> The real issue is we have two WG chairs from NA-West and one from Europe= - there is no fair representation from NA-East!! (kidding) >>=20 >> -hadriel >=20 > I nominate Hadriel for chair :-) Oh yes I would make a very unstable chair... My solution for interims would be to split the difference between all the l= ocations, by having every interim in Hawaii, and making it last exactly two= hours: one hour on Monday morning, one on Friday night. ;) -hadriel From paulej@packetizer.com Wed Apr 18 20:48: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 DC53411E807F for ; Wed, 18 Apr 2012 20:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_50=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 Se8uam+BENNw for ; Wed, 18 Apr 2012 20:48:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8390211E8075 for ; Wed, 18 Apr 2012 20:48:21 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3J3mE7N017997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 23:48:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334807296; bh=fw9XpGFdnar2B1v5m5QQx2mxgH3scRCNng87benahEo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=gcY0/se+X0+oOAhr/zi+NX7vZFUmYuw2cMqFu8jMKHZylk28CvqZOotj0KljTbyqn xfTvW+IkuzKhhDs5DDzyZblE9DJu3qmMAknvcSzCv5yH0Mcy7Ykut8sG6I3Ao5DHtT MtY3vpkCI+lKVRSbmyo1K06sVid7AO4PrJskyN4o= From: "Paul E. Jones" To: "'Olle E. Johansson'" , "'Kevin P. Fleming'" References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> <4F86FE57.8070704@digium.com> In-Reply-To: Date: Wed, 18 Apr 2012 23:48:33 -0400 Message-ID: <06d401cd1ddf$4bf78e80$e3e6ab80$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNwB1VzUBAGtdKoUAdUR/YICM5hPIgEftaPaAd+SP4UB8tiC0ZjQ80UA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 19 Apr 2012 03:48:26 -0000 Olle, > 12 apr 2012 kl. 18:09 skrev Kevin P. Fleming: > > > On 04/12/2012 02:21 AM, Olle E. Johansson wrote: > > > >> This is really bad news for Open Source. Even if we try to get a way to > pay for licenses, our business model is far away from understandable for > most of the syndicates. I tried with the AMR codec once and it stopped at > initial order quantity. Anything under 10.000 licenses was not up for > discussion. Would a patent holder even both with litigation if the patent owner fely that licensing in quantities of less than 10,000 units is not worth the money? Likely not. Litigation is expensive and patent trolls will only do it if there is money to be made. Legitimate companies do not sue unless there is either profit to be made or (as with the Microsoft/Motorola case) there is big money at stake related to something bigger than what the legal case is over. That said, there is always the risk of getting sued before you can get the front doors to your small business propped open. Still, one cannot stop out of fear of legal action. Half the companies in Silicon Valley would never have opened if they concerned themselves too much with patents. However, if successful, a day will come when it's "time to pay the fiddler his due." And when that day comes, there is some comfort in knowing who you go to in order to license the technology you are using. > >> G.729 is available on one-by-one basis which both Asterisk and > FreeSwitch sell to users... I have no insight into how these agreements > was worked out, but it at least indicates that someone tries to open up. > > > > It is my understanding that the licensing arrangements that have been > made for G.729 are no longer an option for new licensees (not offered by > the consortium), and to my knowledge such arrangements have never been an > option for any of the other voice/video codecs that our customers have > asked us about (including H.264, the AMR family and others). > > And isn't that a shame. The question here for the legal department is > wether Google's policies in regards to VP8 is enough for companies like > you to work with it in either binary addons or Open Source code? Does it > provide enough liability assurance? Google's policies will not prevent you from getting sued one day when successful. What would make me feel better is if Google could indemnify people. If they feel they own all of the technology in VP8, they could indemnify people. I would be pleasantly surprised if their legal team truly feels so confident that they own all of the technology in VP8, though. With H.264, you know where to go license technology once you start to see a little success. The IPR holders are known. I cannot imagine a troll out there who wouldn't have already filed a lawsuit by now. (And I'll note again that VP8 might even have elements that are covered by IPR holders who also own IPR on H.264 and who may not be so willing to license it for use with VP8. I see a definite business risk there that I don't see with AMR or H.264.) > I think that question is where we are right now. > > If not, will Google try to offer a solution? I would not suggest you hold your breath :-) I applaud Google for taking the steps it has taken so far, but I do not think there is more they can offer than what they have already. Paul From paulej@packetizer.com Wed Apr 18 20:54: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 2A6F021F8446 for ; Wed, 18 Apr 2012 20:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 ZWbNwj3PAFYx for ; Wed, 18 Apr 2012 20:54:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A19D621F8447 for ; Wed, 18 Apr 2012 20:54:13 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3J3s827018160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 23:54:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334807649; bh=jQ6EnG/jcM9e0t5LRxxn/zFpFVTV/lutHfQzm7kA5dk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Z4+mv5CEP+vQYfqyh9F7rYMSi6mFB7wbww/IZyT/T/NmhcjJimarvj3BPNIWvSS3t ZfTX+2BkjJ69S+cED5qcrXhxrS4xCVPhofd+ShRs0GsAappMwVknCxSJis90bp47MO 5wwBUNv81xW+2RHfNiXw5GeK8Qq8/LmJdI26ewEY= From: "Paul E. Jones" To: "'Olle E. Johansson'" , "'Kevin P. Fleming'" References: <03ac01cd120d$0ffe95f0$2ffbc1d0$@packetizer.com> <4F7BCD1A.7020508@librevideo.org> <03e301cd1223$153e6b60$3fbb4220$@packetizer.com> <4F7C4FB4.4070703@librevideo.org> <007b01cd12f7$fbcd72e0$f36858a0$@packetizer.com> <4F86FE57.8070704@digium.com> <06d401cd1ddf$4bf78e80$e3e6ab80$@packetizer.com> In-Reply-To: <06d401cd1ddf$4bf78e80$e3e6ab80$@packetizer.com> Date: Wed, 18 Apr 2012 23:54:27 -0400 Message-ID: <06d601cd1de0$1e5a3300$5b0e9900$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB2060nC5aqi+YrENoaiW0zV5P0JgFWJR9uAc/AjNwB1VzUBAGtdKoUAdUR/YICM5hPIgEftaPaAd+SP4UB8tiC0QIWgscXmMBHtOA= Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was Re:Proposal for H.263 baseline 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: Thu, 19 Apr 2012 03:54:18 -0000 I hate auto-correct. "even both" --> "even bother" "owner fely that" --> "owner felt that" ... I hope the text can be parsed by most ;-) Paul > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Paul E. Jones > Sent: Wednesday, April 18, 2012 11:49 PM > To: 'Olle E. Johansson'; 'Kevin P. Fleming' > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Google VP8 Patent Grant for third parties [Was > Re:Proposal for H.263 baseline codec] > > Olle, > > > 12 apr 2012 kl. 18:09 skrev Kevin P. Fleming: > > > > > On 04/12/2012 02:21 AM, Olle E. Johansson wrote: > > > > > >> This is really bad news for Open Source. Even if we try to get a > > >> way to > > pay for licenses, our business model is far away from understandable > > for most of the syndicates. I tried with the AMR codec once and it > > stopped at initial order quantity. Anything under 10.000 licenses was > > not up for discussion. > > Would a patent holder even both with litigation if the patent owner fely > that licensing in quantities of less than 10,000 units is not worth the > money? Likely not. Litigation is expensive and patent trolls will only > do it if there is money to be made. Legitimate companies do not sue > unless there is either profit to be made or (as with the > Microsoft/Motorola case) there is big money at stake related to something > bigger than what the legal case is over. > > That said, there is always the risk of getting sued before you can get the > front doors to your small business propped open. Still, one cannot stop > out of fear of legal action. Half the companies in Silicon Valley would > never have opened if they concerned themselves too much with patents. > > However, if successful, a day will come when it's "time to pay the fiddler > his due." And when that day comes, there is some comfort in knowing who > you go to in order to license the technology you are using. > > > >> G.729 is available on one-by-one basis which both Asterisk and > > FreeSwitch sell to users... I have no insight into how these > > agreements was worked out, but it at least indicates that someone tries > to open up. > > > > > > It is my understanding that the licensing arrangements that have > > > been > > made for G.729 are no longer an option for new licensees (not offered > > by the consortium), and to my knowledge such arrangements have never > > been an option for any of the other voice/video codecs that our > > customers have asked us about (including H.264, the AMR family and > others). > > > > And isn't that a shame. The question here for the legal department is > > wether Google's policies in regards to VP8 is enough for companies > > like you to work with it in either binary addons or Open Source code? > > Does it provide enough liability assurance? > > Google's policies will not prevent you from getting sued one day when > successful. What would make me feel better is if Google could indemnify > people. If they feel they own all of the technology in VP8, they could > indemnify people. I would be pleasantly surprised if their legal team > truly feels so confident that they own all of the technology in VP8, > though. > > With H.264, you know where to go license technology once you start to see > a little success. The IPR holders are known. I cannot imagine a troll > out there who wouldn't have already filed a lawsuit by now. (And I'll > note again that VP8 might even have elements that are covered by IPR > holders who also own IPR on H.264 and who may not be so willing to license > it for use with VP8. I see a definite business risk there that I don't > see with AMR or > H.264.) > > > I think that question is where we are right now. > > > > If not, will Google try to offer a solution? > > I would not suggest you hold your breath :-) I applaud Google for taking > the steps it has taken so far, but I do not think there is more they can > offer than what they have already. > > Paul > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Thu Apr 19 00:15: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 2916621F8493 for ; Thu, 19 Apr 2012 00:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_20=-0.74] 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 IVXkZEXvWWWi for ; Thu, 19 Apr 2012 00:15:56 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A99B21F84B8 for ; Thu, 19 Apr 2012 00:15:55 -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 1SKlas-00059C-7W for rtcweb@ietf.org; Thu, 19 Apr 2012 02:15:54 -0500 Message-ID: <4F8FBB8E.6000802@jesup.org> Date: Thu, 19 Apr 2012 03:15:26 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F746163.5090506@hidayahonline.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] Proposal for H.263 baseline 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: Thu, 19 Apr 2012 07:16:00 -0000 On 3/29/2012 1:12 PM, Silvia Pfeiffer wrote: > Very interesting discussion. Out of personal curiosity, I have some > questions inline. > > On Thu, Mar 29, 2012 at 7:20 AM, Stephan Wenger wrote: >> >> The most commonly cited timeline for a widely in use technology to be >> "save" from a patent viewpoint, based on equitable defenses such as laches >> (in the US) is six years. > > Very interesting to know the usually used limit on the number of > years. IIUC that would make Speex, Vorbis and Theora "save" codecs, > since they were released in 2003, 2000, and 2004 respectively? IANAL: No, since the defense (with some notable exceptions) is by a specific person against delayed assertion of a suit against them, so someone using Speex for example could not use that defense for circa 6 years after they began using it. Note that publication of a spec doesn't violate a patent (though using it may). In practice the defense might be even more limited, for example if the infringer made very limited use of the patent for years such that the owner didn't even know they were infringing; it's possible the court might start the clock when the owner knew or could/should have known of the infringement. -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Thu Apr 19 00:46: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 8C82421F84E4 for ; Thu, 19 Apr 2012 00:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 SobqStF8AjAR for ; Thu, 19 Apr 2012 00:46:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBB21F84C4 for ; Thu, 19 Apr 2012 00:46:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9E66539E0CD for ; Thu, 19 Apr 2012 09:46:41 +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 o96krT68Y0pV for ; Thu, 19 Apr 2012 09:46:41 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id ED6C339E098 for ; Thu, 19 Apr 2012 09:46:40 +0200 (CEST) Message-ID: <4F8FC2E0.60701@alvestrand.no> Date: Thu, 19 Apr 2012 09:46:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F869648.2020605@alvestrand.no> In-Reply-To: <4F869648.2020605@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions 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 Apr 2012 07:46:43 -0000 When discussing the issue of resolution negotiation locally, we found a quandary: We have two different negotiation needs: - Maximum resolution that's possible to use in a given context - The preferred resolution for a given context The current imageattr= spec (RFC 6236) doesn't specify clearly whether the result of the negotiation is to be considered mandatory or advisory (it uses the term "wishes" a lot), but the description reads most consistently if one assumes that it is a "MUST" type request. One interpretation is that the highest functionality available in the spec is the "limit", while the highest q value is the "preference", thus: recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1] would indicate that the receiver is capable of 200x160 to 1024x768, but wants 320x200. This maps reasonably to the capabilities spec's talk about "mandatory" vs "optional" capabilities. Does this interpretation make sense? Harald On 04/12/2012 10:46 AM, Harald Alvestrand wrote: > Hello folks, > > after the IETF, I've attempted to gather together information about > resolution negotiation and what we might need to do there. > > I pulled together the paragraphs below - this may want to be > incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go > somewhere else. Chairs' guidance is appreciated. > > At the moment, I have it in xml2rfc format, so it should be easy to do > cut-and-paste on it, but don't want to push it as a separate I-D > unless that's what the chairs desire. > Note - there are some QUERY sections in there - I'm unsure what those > should be resolved to. > > Comments? > > Harald > > 2. Requirements > > The relevant requirement for video resolution negotiation from the > RTCWEB use cases document > [I-D.ietf-rtcweb-use-cases-and-requirements] is: > > o F25 The browser SHOULD use encoding of streams suitable for the > current rendering (e.g. video display size) and SHOULD change > parameters if the rendering changes during the session. > > The resulting need is: > > o To negotiate a maximum spatial resolution for all videos at call > setup time > > o To negotiate a maximum temporal resolution ("frame rate") across > all videos at call setup time > > o To indicate the desire of the recipient for a particular spatial > or temporal resolution on a particular video source > > o To indicate the intent of the sender to send a video source in a > particular spatial or temporal resolution > > This document does not mention other requirements. From ron.even.tlv@gmail.com Thu Apr 19 01:20: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 8242C21F858F for ; Thu, 19 Apr 2012 01:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 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 o2Xj8al6kpkt for ; Thu, 19 Apr 2012 01:20:11 -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 35B1921F8565 for ; Thu, 19 Apr 2012 01:20:10 -0700 (PDT) Received: by werb10 with SMTP id b10so6422886wer.31 for ; Thu, 19 Apr 2012 01:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=U1H66F4lr2q+ShTNdT4rkR7gQabV1dk8A8Xs4GSqEho=; b=GRH1HTnX6kHtqIkQ6YetyZxNWsm4HDynC4gUBObdaxzcIxUUY9KfbYL5bJNdYxxQ2y XMiUpfLq6RsefXKGT5bpxvr+7O9X5EkoKcGUkAQO4JBWhQU4ZMQdMIo0Va/D+V1ruzaL 2jc4/wIY3NdCkOto8vl/nYMdxPXe2zeAkbssXCfee/zStO4uwvvQ67GnxwXJM68emzuY M3XLiGVPJ1VDdxd1cqMpf6FFIelfkZvPAbCtfgGYIV0rZV5HcnkBPWeTWqzkIc/yjj7D Y6y4PCLT8xT4luOlKmOJTgWzj5/I1nrSDhcecou3eFxLxwtB1zZRjfcXtNy/TM5JK9XJ 7x/A== Received: by 10.216.205.93 with SMTP id i71mr731530weo.51.1334823609328; Thu, 19 Apr 2012 01:20:09 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id gg2sm5853462wib.7.2012.04.19.01.20.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 01:20:08 -0700 (PDT) From: "Roni Even" To: "'Harald Alvestrand'" , References: <4F869648.2020605@alvestrand.no> <4F8FC2E0.60701@alvestrand.no> In-Reply-To: <4F8FC2E0.60701@alvestrand.no> Date: Thu, 19 Apr 2012 11:18:33 +0300 Message-ID: <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.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: Ac0eAJOsIQudWrn3Qru2QYVYap6e+wAA+jWQ Content-Language: en-us Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions 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 Apr 2012 08:20:17 -0000 Hi Harald, The reason for the language was that this is really what the receiver wished to receive. The issue is that at least for H.264 there is no mandatory requirement for the encoder to support all resolutions within the supported level. The receiver must be able to crop and scale. Roni Even > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Thursday, April 19, 2012 10:47 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory > resolutions > > When discussing the issue of resolution negotiation locally, we found a > quandary: > > We have two different negotiation needs: > - Maximum resolution that's possible to use in a given context > - The preferred resolution for a given context > > The current imageattr= spec (RFC 6236) doesn't specify clearly whether > the result of the negotiation is to be considered mandatory or advisory > (it uses the term "wishes" a lot), but the description reads most > consistently if one assumes that it is a "MUST" type request. > > One interpretation is that the highest functionality available in the > spec is the "limit", while the highest q value is the "preference", > thus: > > recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1] > > would indicate that the receiver is capable of 200x160 to 1024x768, but > wants 320x200. > > This maps reasonably to the capabilities spec's talk about "mandatory" > vs "optional" capabilities. > > Does this interpretation make sense? > > Harald > > > On 04/12/2012 10:46 AM, Harald Alvestrand wrote: > > Hello folks, > > > > after the IETF, I've attempted to gather together information about > > resolution negotiation and what we might need to do there. > > > > I pulled together the paragraphs below - this may want to be > > incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go > > somewhere else. Chairs' guidance is appreciated. > > > > At the moment, I have it in xml2rfc format, so it should be easy to > do > > cut-and-paste on it, but don't want to push it as a separate I-D > > unless that's what the chairs desire. > > Note - there are some QUERY sections in there - I'm unsure what those > > should be resolved to. > > > > Comments? > > > > Harald > > > > 2. Requirements > > > > The relevant requirement for video resolution negotiation from the > > RTCWEB use cases document > > [I-D.ietf-rtcweb-use-cases-and-requirements] is: > > > > o F25 The browser SHOULD use encoding of streams suitable for the > > current rendering (e.g. video display size) and SHOULD change > > parameters if the rendering changes during the session. > > > > The resulting need is: > > > > o To negotiate a maximum spatial resolution for all videos at > call > > setup time > > > > o To negotiate a maximum temporal resolution ("frame rate") > across > > all videos at call setup time > > > > o To indicate the desire of the recipient for a particular > spatial > > or temporal resolution on a particular video source > > > > o To indicate the intent of the sender to send a video source in > a > > particular spatial or temporal resolution > > > > This document does not mention other requirements. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Apr 19 01: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 3371921F84C9 for ; Thu, 19 Apr 2012 01:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 SYmoxvqkwynT for ; Thu, 19 Apr 2012 01:47:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C64D921F85C3 for ; Thu, 19 Apr 2012 01:47:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03AC639E0CD; Thu, 19 Apr 2012 10:47:46 +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 0uA02NzHwUXQ; Thu, 19 Apr 2012 10:47:41 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5FF3439E098; Thu, 19 Apr 2012 10:47:41 +0200 (CEST) Message-ID: <4F8FD12C.9070703@alvestrand.no> Date: Thu, 19 Apr 2012 10:47:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Roni Even References: <4F869648.2020605@alvestrand.no> <4F8FC2E0.60701@alvestrand.no> <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.com> In-Reply-To: <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions 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 Apr 2012 08:47:51 -0000 On 04/19/2012 10:18 AM, Roni Even wrote: > Hi Harald, > The reason for the language was that this is really what the receiver wished > to receive. The strength of his wish may be the issue here.... > The issue is that at least for H.264 there is no mandatory > requirement for the encoder to support all resolutions within the supported > level. The receiver must be able to crop and scale. I couldn't parse that. Does the sender have to (MUST) send a resolution within the boundaries of the "recv" spec, or can he send something outside it? (ie if the receiver sends recv [x=320,y=200], can the sender send something with x=320,y=240, or is he completely constrained?) What does the receiver have to be able to do? Harald > > Roni Even > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >> Sent: Thursday, April 19, 2012 10:47 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory >> resolutions >> >> When discussing the issue of resolution negotiation locally, we found a >> quandary: >> >> We have two different negotiation needs: >> - Maximum resolution that's possible to use in a given context >> - The preferred resolution for a given context >> >> The current imageattr= spec (RFC 6236) doesn't specify clearly whether >> the result of the negotiation is to be considered mandatory or advisory >> (it uses the term "wishes" a lot), but the description reads most >> consistently if one assumes that it is a "MUST" type request. >> >> One interpretation is that the highest functionality available in the >> spec is the "limit", while the highest q value is the "preference", >> thus: >> >> recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1] >> >> would indicate that the receiver is capable of 200x160 to 1024x768, but >> wants 320x200. >> >> This maps reasonably to the capabilities spec's talk about "mandatory" >> vs "optional" capabilities. >> >> Does this interpretation make sense? >> >> Harald >> >> >> On 04/12/2012 10:46 AM, Harald Alvestrand wrote: >>> Hello folks, >>> >>> after the IETF, I've attempted to gather together information about >>> resolution negotiation and what we might need to do there. >>> >>> I pulled together the paragraphs below - this may want to be >>> incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go >>> somewhere else. Chairs' guidance is appreciated. >>> >>> At the moment, I have it in xml2rfc format, so it should be easy to >> do >>> cut-and-paste on it, but don't want to push it as a separate I-D >>> unless that's what the chairs desire. >>> Note - there are some QUERY sections in there - I'm unsure what those >>> should be resolved to. >>> >>> Comments? >>> >>> Harald >>> >>> 2. Requirements >>> >>> The relevant requirement for video resolution negotiation from the >>> RTCWEB use cases document >>> [I-D.ietf-rtcweb-use-cases-and-requirements] is: >>> >>> o F25 The browser SHOULD use encoding of streams suitable for the >>> current rendering (e.g. video display size) and SHOULD change >>> parameters if the rendering changes during the session. >>> >>> The resulting need is: >>> >>> o To negotiate a maximum spatial resolution for all videos at >> call >>> setup time >>> >>> o To negotiate a maximum temporal resolution ("frame rate") >> across >>> all videos at call setup time >>> >>> o To indicate the desire of the recipient for a particular >> spatial >>> or temporal resolution on a particular video source >>> >>> o To indicate the intent of the sender to send a video source in >> a >>> particular spatial or temporal resolution >>> >>> This document does not mention other requirements. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From magnus.westerlund@ericsson.com Thu Apr 19 02:18: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 A672021F846D for ; Thu, 19 Apr 2012 02:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.207 X-Spam-Level: X-Spam-Status: No, score=-106.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 XeRinzAO1o6M for ; Thu, 19 Apr 2012 02:18:55 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D21C921F8460 for ; Thu, 19 Apr 2012 02:18:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-ba-4f8fd87cd73d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7B.0A.25560.C78DF8F4; Thu, 19 Apr 2012 11:18:53 +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.213.0; Thu, 19 Apr 2012 11:18:52 +0200 Message-ID: <4F8FD87C.2070907@ericsson.com> Date: Thu, 19 Apr 2012 11:18:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "rai-ads@tools.ietf.org" , "rtcweb@ietf.org" , "clue-chairs@tools.ietf.org" Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD 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 Apr 2012 09:18:55 -0000 RTCWEB WG, The dates for the upcoming interim is off the hold. I can confirm AD approval, and that we will hold an Face to Face interim meeting on the 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for each of those days. As a Host I can't confirm the location within Stockholm yet. We are aiming on either a location in Kista or in the central part of town. There are some hotels out in Kista, but even if we end up in Kista staying in central Stockholm allows for a short (17 min) subway ride from T-centralen plus a no more than 10 min walk to the Kista venue. Making it a very viable option to book a hotel room in the area around T-centralen or on Kungsholmen with easy access to the blue-line subway. Cheers Magnus Westerlund On 2012-04-12 19:42, Ted Hardie wrote: > Please hold off making travel plans based on this timing. Because > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June > 7th and 8th. Until the chairs have had a chance to discuss this, > please hold off on booking travel plans. > > My apologies for this scramble, > > Ted Hardie > > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: >> After discussion between the WEBRTC and RTCWEB chairs, consulting the >> doodle poll, and working through the potential for co-location with >> CLUE, we have decided to set the date for the RTCWEB interim at June >> 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that >> the WEBRTC chairs will hold their meeting on June 11th. If CLUE >> wishes to co-locate their meeting, the 14th and 15th will be >> available. This would not have been possible on the previous week, >> given the national holiday in Sweden on the Wednesday of that week. >> >> We very much appreciated the work Eric put into his analysis, and in >> general we will try to prefer hubs; in this particular case, however, >> a large fraction of the Western European participants are either based >> in Stockholm or must fly through it to reach one of the larger hubs. >> Given the availability of a host and this data, we decided to select >> Stockholm for this meeting. >> >> regards, >> >> Ted Hardie, for the chairs. > -- 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 magnus.westerlund@ericsson.com Thu Apr 19 02:21: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 A52DF21F8594 for ; Thu, 19 Apr 2012 02:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.041, 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 Ix1XDjjpxDfM for ; Thu, 19 Apr 2012 02:21:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 844FF21F8460 for ; Thu, 19 Apr 2012 02:21:17 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-55-4f8fd90c38cd Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6F.8E.26681.C09DF8F4; Thu, 19 Apr 2012 11:21:16 +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.213.0; Thu, 19 Apr 2012 11:21:16 +0200 Message-ID: <4F8FD90B.5040409@ericsson.com> Date: Thu, 19 Apr 2012 11:21:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 09:21:25 -0000 RTCWEB WG, The dates for the upcoming interim is off the hold. I can confirm AD approval, and that we will hold an Face to Face interim meeting on the 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for each of those days. As a Host I can't confirm the location within Stockholm yet. We are aiming on either a location in Kista or in the central part of town. There are some hotels out in Kista, but even if we end up in Kista staying in central Stockholm allows for a short (17 min) subway ride from T-centralen plus a no more than 10 min walk to the Kista venue. Making it a very viable option to book a hotel room in the area around T-centralen or on Kungsholmen with easy access to the blue-line subway. Cheers Magnus Westerlund -- 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 ron.even.tlv@gmail.com Thu Apr 19 02:58: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 A52D321F8568 for ; Thu, 19 Apr 2012 02:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Z7sOhf1BmPXz for ; Thu, 19 Apr 2012 02:58:02 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id B3DF921F8491 for ; Thu, 19 Apr 2012 02:58:01 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so1361975wib.1 for ; Thu, 19 Apr 2012 02:58:00 -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=q5VvOHU+cOMNY3FKDBJAlbAYa37RmMAVGeyafXCCLJM=; b=MiV020YbQkaa6SmtgkLnhCVVmGP7Pxw8EUdYQApNT8kI8y/VW5gxxQMteKP4+rgsMh iDM1vrEgWemGRFp/weo73UosAAJ1Qry3kdj0y89NdIwvEMaLTB0T+VZsJ8+Z6QSC0/93 Qc7GdTcG7zQOodWvvBx4qfGpQL8e25kQo9tjnZlj5rkHBWmoaXiUk3IEF+1ZFDq9TMe3 NEwYzlJ2tC7v9pecXSfDpeZeAHADVdCSGxyv22mtWHdG8C5bVfTvtAIJ+odXW38pkZdN 4bPMmWa2JFWe9k3QdK6i8Q5R3C6WCHGisaP0o83HGQKE1qTDtGa2j3V0wfVZF1kiaR4d dZDw== Received: by 10.180.95.74 with SMTP id di10mr4570357wib.1.1334829480826; Thu, 19 Apr 2012 02:58:00 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id ev10sm41177251wid.10.2012.04.19.02.57.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 02:57:59 -0700 (PDT) From: "Roni Even" To: "'Harald Alvestrand'" References: <4F869648.2020605@alvestrand.no> <4F8FC2E0.60701@alvestrand.no> <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.com> <4F8FD12C.9070703@alvestrand.no> In-Reply-To: <4F8FD12C.9070703@alvestrand.no> Date: Thu, 19 Apr 2012 12:56:24 +0300 Message-ID: <4f8fe1a7.2a0db50a.23db.136b@mx.google.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: Ac0eCRibOkP/qaAzTKy4nLRKPzV7pgABx9vw Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions 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 Apr 2012 09:58:03 -0000 Hi Harald, Look at example 4.2.1. The sender of the media will reject the recv value in the offer and may offer other send options. Typically they should be larger than the rejected value in order to allow cropping and/or scaling down to the right size. (Cropping may provide better quality than scaling up). Roni > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, April 19, 2012 11:48 AM > To: Roni Even > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory > resolutions > > On 04/19/2012 10:18 AM, Roni Even wrote: > > Hi Harald, > > The reason for the language was that this is really what the receiver > > wished to receive. > The strength of his wish may be the issue here.... > > The issue is that at least for H.264 there is no mandatory > > requirement for the encoder to support all resolutions within the > > supported level. The receiver must be able to crop and scale. > I couldn't parse that. > > Does the sender have to (MUST) send a resolution within the boundaries > of the "recv" spec, or can he send something outside it? (ie if the > receiver sends recv [x=320,y=200], can the sender send something with > x=320,y=240, or is he completely constrained?) > > What does the receiver have to be able to do? > > Harald > > > > Roni Even > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Harald Alvestrand > >> Sent: Thursday, April 19, 2012 10:47 AM > >> To: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory > >> resolutions > >> > >> When discussing the issue of resolution negotiation locally, we > found > >> a > >> quandary: > >> > >> We have two different negotiation needs: > >> - Maximum resolution that's possible to use in a given context > >> - The preferred resolution for a given context > >> > >> The current imageattr= spec (RFC 6236) doesn't specify clearly > >> whether the result of the negotiation is to be considered mandatory > >> or advisory (it uses the term "wishes" a lot), but the description > >> reads most consistently if one assumes that it is a "MUST" type > request. > >> > >> One interpretation is that the highest functionality available in > the > >> spec is the "limit", while the highest q value is the "preference", > >> thus: > >> > >> recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1] > >> > >> would indicate that the receiver is capable of 200x160 to 1024x768, > >> but wants 320x200. > >> > >> This maps reasonably to the capabilities spec's talk about > "mandatory" > >> vs "optional" capabilities. > >> > >> Does this interpretation make sense? > >> > >> Harald > >> > >> > >> On 04/12/2012 10:46 AM, Harald Alvestrand wrote: > >>> Hello folks, > >>> > >>> after the IETF, I've attempted to gather together information about > >>> resolution negotiation and what we might need to do there. > >>> > >>> I pulled together the paragraphs below - this may want to be > >>> incorporated in an I-D on "SDP usage in RTCWEB", or it may want to > >>> go somewhere else. Chairs' guidance is appreciated. > >>> > >>> At the moment, I have it in xml2rfc format, so it should be easy to > >> do > >>> cut-and-paste on it, but don't want to push it as a separate I-D > >>> unless that's what the chairs desire. > >>> Note - there are some QUERY sections in there - I'm unsure what > >>> those should be resolved to. > >>> > >>> Comments? > >>> > >>> Harald > >>> > >>> 2. Requirements > >>> > >>> The relevant requirement for video resolution negotiation from > the > >>> RTCWEB use cases document > >>> [I-D.ietf-rtcweb-use-cases-and-requirements] is: > >>> > >>> o F25 The browser SHOULD use encoding of streams suitable for > the > >>> current rendering (e.g. video display size) and SHOULD > change > >>> parameters if the rendering changes during the session. > >>> > >>> The resulting need is: > >>> > >>> o To negotiate a maximum spatial resolution for all videos at > >> call > >>> setup time > >>> > >>> o To negotiate a maximum temporal resolution ("frame rate") > >> across > >>> all videos at call setup time > >>> > >>> o To indicate the desire of the recipient for a particular > >> spatial > >>> or temporal resolution on a particular video source > >>> > >>> o To indicate the intent of the sender to send a video source > >>> in > >> a > >>> particular spatial or temporal resolution > >>> > >>> This document does not mention other requirements. > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > From harald@alvestrand.no Thu Apr 19 04:17: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 7080B21F85C4 for ; Thu, 19 Apr 2012 04:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 dwp60tPr+KFe for ; Thu, 19 Apr 2012 04:17:55 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E37E321F85D6 for ; Thu, 19 Apr 2012 04:17:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C537939E0CD; Thu, 19 Apr 2012 13:17:53 +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 sYGDZ+sQPlI5; Thu, 19 Apr 2012 13:17:49 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2617D39E098; Thu, 19 Apr 2012 13:17:49 +0200 (CEST) Message-ID: <4F8FF45C.7090003@alvestrand.no> Date: Thu, 19 Apr 2012 13:17:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Roni Even References: <4F869648.2020605@alvestrand.no> <4F8FC2E0.60701@alvestrand.no> <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.com> <4F8FD12C.9070703@alvestrand.no> <4f8fe1a7.2a0db50a.23db.136b@mx.google.com> In-Reply-To: <4f8fe1a7.2a0db50a.23db.136b@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions 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 Apr 2012 11:17:59 -0000 On 04/19/2012 11:56 AM, Roni Even wrote: > Hi Harald, > Look at example 4.2.1. The sender of the media will reject the recv value in > the offer and may offer other send options. Typically they should be larger > than the rejected value in order to allow cropping and/or scaling down to > the right size. (Cropping may provide better quality than scaling up). Thank you - that helps a bit. I interpret the example in 4.2.1 (second alternative) as consisting of 4 messages; in an offer/answer exchange, this would look like: 1) Alice -> Bob: OFFER a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \ recv [x=330,y=250] 2) Bob -> Alice: ANSWER a=imageattr:97 recv [x=800,y=640,sar=1.1] \ send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]] 3) Alice -> Bob: OFFER (re-invite, probably) a=imageattr:97 send [x=800,y=640,sar=1.1] \ recv [x=336,y=256] 4) Bob -> Alice: ANSWER a=imageattr:97 recv [x=800,y=640,sar=1.1] \ send [x=336,y=256] So after message 2, Bob cannot send anything, since he can't reproduce what Alice asked for, right? And after message 2, Alice can only send 800x640 with a sar of 1.1, right? It's forbidden for Alice to send a noncompensated image, or a 640x480 image? Again, it's the use of the words "wishes" and "desires" that I want to be sure I understand correctly - as used in RFC 6236, they both mean "demand" / "require" / "MUST". Right? > Roni > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Thursday, April 19, 2012 11:48 AM >> To: Roni Even >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory >> resolutions >> >> On 04/19/2012 10:18 AM, Roni Even wrote: >>> Hi Harald, >>> The reason for the language was that this is really what the receiver >>> wished to receive. >> The strength of his wish may be the issue here.... >>> The issue is that at least for H.264 there is no mandatory >>> requirement for the encoder to support all resolutions within the >>> supported level. The receiver must be able to crop and scale. >> I couldn't parse that. >> >> Does the sender have to (MUST) send a resolution within the boundaries >> of the "recv" spec, or can he send something outside it? (ie if the >> receiver sends recv [x=320,y=200], can the sender send something with >> x=320,y=240, or is he completely constrained?) >> >> What does the receiver have to be able to do? >> >> Harald >>> Roni Even >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Harald Alvestrand >>>> Sent: Thursday, April 19, 2012 10:47 AM >>>> To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory >>>> resolutions >>>> >>>> When discussing the issue of resolution negotiation locally, we >> found >>>> a >>>> quandary: >>>> >>>> We have two different negotiation needs: >>>> - Maximum resolution that's possible to use in a given context >>>> - The preferred resolution for a given context >>>> >>>> The current imageattr= spec (RFC 6236) doesn't specify clearly >>>> whether the result of the negotiation is to be considered mandatory >>>> or advisory (it uses the term "wishes" a lot), but the description >>>> reads most consistently if one assumes that it is a "MUST" type >> request. >>>> One interpretation is that the highest functionality available in >> the >>>> spec is the "limit", while the highest q value is the "preference", >>>> thus: >>>> >>>> recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1] >>>> >>>> would indicate that the receiver is capable of 200x160 to 1024x768, >>>> but wants 320x200. >>>> >>>> This maps reasonably to the capabilities spec's talk about >> "mandatory" >>>> vs "optional" capabilities. >>>> >>>> Does this interpretation make sense? >>>> >>>> Harald >>>> >>>> >>>> On 04/12/2012 10:46 AM, Harald Alvestrand wrote: >>>>> Hello folks, >>>>> >>>>> after the IETF, I've attempted to gather together information about >>>>> resolution negotiation and what we might need to do there. >>>>> >>>>> I pulled together the paragraphs below - this may want to be >>>>> incorporated in an I-D on "SDP usage in RTCWEB", or it may want to >>>>> go somewhere else. Chairs' guidance is appreciated. >>>>> >>>>> At the moment, I have it in xml2rfc format, so it should be easy to >>>> do >>>>> cut-and-paste on it, but don't want to push it as a separate I-D >>>>> unless that's what the chairs desire. >>>>> Note - there are some QUERY sections in there - I'm unsure what >>>>> those should be resolved to. >>>>> >>>>> Comments? >>>>> >>>>> Harald >>>>> >>>>> 2. Requirements >>>>> >>>>> The relevant requirement for video resolution negotiation from >> the >>>>> RTCWEB use cases document >>>>> [I-D.ietf-rtcweb-use-cases-and-requirements] is: >>>>> >>>>> o F25 The browser SHOULD use encoding of streams suitable for >> the >>>>> current rendering (e.g. video display size) and SHOULD >> change >>>>> parameters if the rendering changes during the session. >>>>> >>>>> The resulting need is: >>>>> >>>>> o To negotiate a maximum spatial resolution for all videos at >>>> call >>>>> setup time >>>>> >>>>> o To negotiate a maximum temporal resolution ("frame rate") >>>> across >>>>> all videos at call setup time >>>>> >>>>> o To indicate the desire of the recipient for a particular >>>> spatial >>>>> or temporal resolution on a particular video source >>>>> >>>>> o To indicate the intent of the sender to send a video source >>>>> in >>>> a >>>>> particular spatial or temporal resolution >>>>> >>>>> This document does not mention other requirements. >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb > From marshall.eubanks@gmail.com Thu Apr 19 04:32: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 6AAE021F858F for ; Thu, 19 Apr 2012 04:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 8pMejBiV1ltB for ; Thu, 19 Apr 2012 04:32:54 -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 0C0AF21F8604 for ; Thu, 19 Apr 2012 04:32:53 -0700 (PDT) Received: by lbgc1 with SMTP id c1so2133394lbg.31 for ; Thu, 19 Apr 2012 04:32:53 -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=fk4TDvzvRc6Osswrqkp+IJbHf2ch7YjJgPZITCyqVsU=; b=nOOY/ZEx6ZqyHvpDWZ94LbPVY43gJHGjtqjKj8WqhSo8yoKU2MZuE2LfU+1Imi6e9+ 1Otkjj/jusk6egWynWNKkG92EqkZ+205vcn8oWVfu7avoea708TFH+ROBS4/PnTaUCeq ZFGfqlkyYrtIdpc6eIA4LycBTJprvevuBfrhl6Xx3aBo1To5TwfCKipQf+m8ykoSiK/T CXGias5EEn6QKwThcuAbSCEZcdcJa1oJGiKOLwqYtholZbmTZxY5rxkv5ASBuJFD/UuN Mc21+cWIeNfSXJWcG01WxJrfs+dgEIAVQ6aQHOK/OMDphgn7JTTY0EaQcSvuZh/7GBli EqnQ== MIME-Version: 1.0 Received: by 10.112.44.106 with SMTP id d10mr857940lbm.30.1334835172916; Thu, 19 Apr 2012 04:32:52 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Thu, 19 Apr 2012 04:32:52 -0700 (PDT) In-Reply-To: <4F8FBB8E.6000802@jesup.org> References: <4F746163.5090506@hidayahonline.org> <4F8FBB8E.6000802@jesup.org> Date: Thu, 19 Apr 2012 07:32:52 -0400 Message-ID: From: Marshall Eubanks To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for H.263 baseline 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: Thu, 19 Apr 2012 11:32:59 -0000 On Thu, Apr 19, 2012 at 3:15 AM, Randell Jesup wro= te: > On 3/29/2012 1:12 PM, Silvia Pfeiffer wrote: >> >> Very interesting discussion. Out of personal curiosity, I have some >> questions inline. >> >> On Thu, Mar 29, 2012 at 7:20 AM, Stephan Wenger =A0wrot= e: >>> >>> >>> The most commonly cited timeline for a widely in use technology to be >>> "save" from a patent viewpoint, based on equitable defenses such as >>> laches >>> (in the US) is six years. >> >> >> Very interesting to know the usually used limit on the number of >> years. IIUC that would make Speex, Vorbis and Theora "save" codecs, >> since they were released in 2003, 2000, and 2004 respectively? > > > IANAL: =A0No, since the defense (with some notable exceptions) is by a > specific person against delayed assertion of a suit against them, so some= one > using Speex for example could not use that defense for circa 6 years afte= r > they began using it. =A0Note that publication of a spec doesn't violate a > patent (though using it may). =A0In practice the defense might be even mo= re > limited, for example if the infringer made very limited use of the patent > for years such that the owner didn't even know they were infringing; it's > possible the court might start the clock when the owner knew or could/sho= uld > have known of the infringement. > I found a fairly detailed analysis of the defense of laches in patent cases starting at page 27 of this http://www.fdml.com/defenses.pdf Reading this dense legal reasoning makes me very nervous about relying on any of this for any IETF decision. Engineers should not pretend they are lawyers. Regards Marshall > > -- > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ron.even.tlv@gmail.com Thu Apr 19 06:27: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 0B50321F8615 for ; Thu, 19 Apr 2012 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 sUrlLgjGIEKr for ; Thu, 19 Apr 2012 06:26:56 -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 E827A21F861A for ; Thu, 19 Apr 2012 06:26:54 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so5814115wgb.13 for ; Thu, 19 Apr 2012 06:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=WNPH0XrqWCXepJqqZtR+5LKZuhvVGiHr2XSnyxM288w=; b=ACrqipcWKfSgEXMtU683i81QEs2OKZiA5st6SUSKQ2NEsBp2dDpZOKI5BkQGA8yfCk xLp0ZneWkSnFP1L9+s8fBUuYmg1fQhwINH2tYfgZ0F12nb6S8jYhsnh1YFTHGoWp/rkY 3OQVfxD9YvpDig2SnbF+hPM2fh8T7JN8v4txn4NeM83VrhEw1Op9kZnkoflhAPqaXjBJ d5GdmjD6ndJvDTrXEw5iYCQ7sfNTTJcMbDdnG7GRY2zJQT8UfdLpJ1WUVcOQzoOTZ3Lx bRrYYfDhjldYRgmEomnofUv4PZvvuB/aCb0IL6XcxGoZ5VpodMhcQ/J/P355AN8QusGR w9Rg== Received: by 10.180.97.41 with SMTP id dx9mr26379915wib.9.1334842014024; Thu, 19 Apr 2012 06:26:54 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id o2sm8330962wiv.11.2012.04.19.06.26.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 06:26:51 -0700 (PDT) From: "Roni Even" To: "'Harald Alvestrand'" References: <4F869648.2020605@alvestrand.no> <4F8FC2E0.60701@alvestrand.no> <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.com> <4F8FD12C.9070703@alvestrand.no> <4f8fe1a7.2a0db50a.23db.136b@mx.google.com> <4F8FF45C.7090003@alvestrand.no> In-Reply-To: <4F8FF45C.7090003@alvestrand.no> Date: Thu, 19 Apr 2012 16:25:14 +0300 Message-ID: <4f90129b.e249b40a.4436.3455@mx.google.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: Ac0eHhEyBEjSd7dYTmGMLj3hSAkUWwADgkhA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions 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 Apr 2012 13:27:01 -0000 Hi Harald, This is a good question, my view will be that since Alice gave a preference like profile and level (and maybe bandwidth) in the original offer than Bob can send any video that will be within this level. The image attribute says that Alice prefers to get something specific to help with processing (note that Alice can limit the received video by using max-mbps and max-fs for H.264). It may be good to discuss it with others from MMUSIC. The usage of the image attribute in my view is more relevant to allow the receiver to ask for a specific image size since this is not defined in H.264 (in H.263 you can specify the common specific resolutions and frame rate using the optional parameters in RFC 4629). This was a requirement to allow a receiver to ask for a specific size. The usage of "wish" was because H.264 encoder is not required to support scale to a specific resolution and a compliant decoder must support everything within the negotiated profile and level. So when a receiver asks for a size it can happen only if the encoder can do it but if the encoder cannot it is still compliant. I think that one reason for no scaling requirements on encoder is to support simple video cameras that support one resolution and send an H.264 stream (no scaling/cropping capabilities) and the decoder must be able to display it on any output device (monitor). Roni > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, April 19, 2012 2:18 PM > To: Roni Even > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory > resolutions > > On 04/19/2012 11:56 AM, Roni Even wrote: > > Hi Harald, > > Look at example 4.2.1. The sender of the media will reject the recv > > value in the offer and may offer other send options. Typically they > > should be larger than the rejected value in order to allow cropping > > and/or scaling down to the right size. (Cropping may provide better > quality than scaling up). > > Thank you - that helps a bit. > > I interpret the example in 4.2.1 (second alternative) as consisting of > 4 messages; in an offer/answer exchange, this would look like: > > 1) Alice -> Bob: OFFER > a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \ > recv [x=330,y=250] > 2) Bob -> Alice: ANSWER > a=imageattr:97 recv [x=800,y=640,sar=1.1] \ > send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]] > 3) Alice -> Bob: OFFER (re-invite, probably) > a=imageattr:97 send [x=800,y=640,sar=1.1] \ > recv [x=336,y=256] > 4) Bob -> Alice: ANSWER > a=imageattr:97 recv [x=800,y=640,sar=1.1] \ > send [x=336,y=256] > > So after message 2, Bob cannot send anything, since he can't reproduce > what Alice asked for, right? > > And after message 2, Alice can only send 800x640 with a sar of 1.1, > right? It's forbidden for Alice to send a noncompensated image, or a > 640x480 image? > > Again, it's the use of the words "wishes" and "desires" that I want to > be sure I understand correctly - as used in RFC 6236, they both mean > "demand" / "require" / "MUST". Right? > > > Roni > > > >> -----Original Message----- > >> From: Harald Alvestrand [mailto:harald@alvestrand.no] > >> Sent: Thursday, April 19, 2012 11:48 AM > >> To: Roni Even > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory > >> resolutions > >> > >> On 04/19/2012 10:18 AM, Roni Even wrote: > >>> Hi Harald, > >>> The reason for the language was that this is really what the > >>> receiver wished to receive. > >> The strength of his wish may be the issue here.... > >>> The issue is that at least for H.264 there is no mandatory > >>> requirement for the encoder to support all resolutions within the > >>> supported level. The receiver must be able to crop and scale. > >> I couldn't parse that. > >> > >> Does the sender have to (MUST) send a resolution within the > >> boundaries of the "recv" spec, or can he send something outside it? > >> (ie if the receiver sends recv [x=320,y=200], can the sender send > >> something with x=320,y=240, or is he completely constrained?) > >> > >> What does the receiver have to be able to do? > >> > >> Harald > >>> Roni Even > >>> > >>>> -----Original Message----- > >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>>> Behalf Of Harald Alvestrand > >>>> Sent: Thursday, April 19, 2012 10:47 AM > >>>> To: rtcweb@ietf.org > >>>> Subject: Re: [rtcweb] Resolution negotiation - mandatory / > advisory > >>>> resolutions > >>>> > >>>> When discussing the issue of resolution negotiation locally, we > >> found > >>>> a > >>>> quandary: > >>>> > >>>> We have two different negotiation needs: > >>>> - Maximum resolution that's possible to use in a given context > >>>> - The preferred resolution for a given context > >>>> > >>>> The current imageattr= spec (RFC 6236) doesn't specify clearly > >>>> whether the result of the negotiation is to be considered > mandatory > >>>> or advisory (it uses the term "wishes" a lot), but the description > >>>> reads most consistently if one assumes that it is a "MUST" type > >> request. > >>>> One interpretation is that the highest functionality available in > >> the > >>>> spec is the "limit", while the highest q value is the > "preference", > >>>> thus: > >>>> > >>>> recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1] > >>>> > >>>> would indicate that the receiver is capable of 200x160 to > 1024x768, > >>>> but wants 320x200. > >>>> > >>>> This maps reasonably to the capabilities spec's talk about > >> "mandatory" > >>>> vs "optional" capabilities. > >>>> > >>>> Does this interpretation make sense? > >>>> > >>>> Harald > >>>> > >>>> > >>>> On 04/12/2012 10:46 AM, Harald Alvestrand wrote: > >>>>> Hello folks, > >>>>> > >>>>> after the IETF, I've attempted to gather together information > >>>>> about resolution negotiation and what we might need to do there. > >>>>> > >>>>> I pulled together the paragraphs below - this may want to be > >>>>> incorporated in an I-D on "SDP usage in RTCWEB", or it may want > to > >>>>> go somewhere else. Chairs' guidance is appreciated. > >>>>> > >>>>> At the moment, I have it in xml2rfc format, so it should be easy > >>>>> to > >>>> do > >>>>> cut-and-paste on it, but don't want to push it as a separate I-D > >>>>> unless that's what the chairs desire. > >>>>> Note - there are some QUERY sections in there - I'm unsure what > >>>>> those should be resolved to. > >>>>> > >>>>> Comments? > >>>>> > >>>>> Harald > >>>>> > >>>>> 2. Requirements > >>>>> > >>>>> The relevant requirement for video resolution negotiation > >>>>> from > >> the > >>>>> RTCWEB use cases document > >>>>> [I-D.ietf-rtcweb-use-cases-and-requirements] is: > >>>>> > >>>>> o F25 The browser SHOULD use encoding of streams suitable > >>>>> for > >> the > >>>>> current rendering (e.g. video display size) and SHOULD > >> change > >>>>> parameters if the rendering changes during the session. > >>>>> > >>>>> The resulting need is: > >>>>> > >>>>> o To negotiate a maximum spatial resolution for all videos > >>>>> at > >>>> call > >>>>> setup time > >>>>> > >>>>> o To negotiate a maximum temporal resolution ("frame rate") > >>>> across > >>>>> all videos at call setup time > >>>>> > >>>>> o To indicate the desire of the recipient for a particular > >>>> spatial > >>>>> or temporal resolution on a particular video source > >>>>> > >>>>> o To indicate the intent of the sender to send a video > >>>>> source in > >>>> a > >>>>> particular spatial or temporal resolution > >>>>> > >>>>> This document does not mention other requirements. > >>>> _______________________________________________ > >>>> rtcweb mailing list > >>>> rtcweb@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtcweb > > From kpfleming@digium.com Thu Apr 19 07:20: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 97CB821F858F for ; Thu, 19 Apr 2012 07:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tBt7AVOpAy+v for ; Thu, 19 Apr 2012 07:20:44 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3A221F8644 for ; Thu, 19 Apr 2012 07:20:43 -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 1SKsDz-0006g5-2a for rtcweb@ietf.org; Thu, 19 Apr 2012 09:20:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 131081A2011 for ; Thu, 19 Apr 2012 09:20:43 -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 G2v0R7UnIIh9 for ; Thu, 19 Apr 2012 09:20:38 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 0C2891A2001 for ; Thu, 19 Apr 2012 09:20:38 -0500 (CDT) Message-ID: <4F901F31.4030208@digium.com> Date: Thu, 19 Apr 2012 09:20:33 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F8FD90B.5040409@ericsson.com> In-Reply-To: <4F8FD90B.5040409@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 14:20:49 -0000 On 04/19/2012 04:21 AM, Magnus Westerlund wrote: > RTCWEB WG, > > The dates for the upcoming interim is off the hold. I can confirm AD > approval, and that we will hold an Face to Face interim meeting on the > 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a > meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for > each of those days. Is the W3C meeting 'open attendance' like the IETF meeting will be, or does it require membership or sponsorship? -- 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 harald@alvestrand.no Thu Apr 19 08:00: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 0394721F8609 for ; Thu, 19 Apr 2012 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.507 X-Spam-Level: X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 4Asms8W4mHnA for ; Thu, 19 Apr 2012 08:00:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E3BEE21F8630 for ; Thu, 19 Apr 2012 08:00:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55BF339E146; Thu, 19 Apr 2012 17:00:36 +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 LD7npNpyTPSJ; Thu, 19 Apr 2012 17:00:35 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C573B39E098; Thu, 19 Apr 2012 17:00:35 +0200 (CEST) Message-ID: <4F902893.5030803@alvestrand.no> Date: Thu, 19 Apr 2012 17:00:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4F8FD90B.5040409@ericsson.com> <4F901F31.4030208@digium.com> In-Reply-To: <4F901F31.4030208@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 15:00:43 -0000 On 04/19/2012 04:20 PM, Kevin P. Fleming wrote: > On 04/19/2012 04:21 AM, Magnus Westerlund wrote: >> RTCWEB WG, >> >> The dates for the upcoming interim is off the hold. I can confirm AD >> approval, and that we will hold an Face to Face interim meeting on the >> 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a >> meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for >> each of those days. > > Is the W3C meeting 'open attendance' like the IETF meeting will be, or > does it require membership or sponsorship? The WG chairs can welcome people into the meeting as "observers with speaking privilleges". All we want as formality is that you send us a note beforehand asking to be an observer. We will accept the request. Harald From randell-ietf@jesup.org Thu Apr 19 08:33: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 EBDCB21F85AC for ; Thu, 19 Apr 2012 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 BrnvXWOusziw for ; Thu, 19 Apr 2012 08:33:04 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5F221F8596 for ; Thu, 19 Apr 2012 08:33:04 -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 1SKtLy-0006dU-0B for rtcweb@ietf.org; Thu, 19 Apr 2012 10:33:03 -0500 Message-ID: <4F903010.80504@jesup.org> Date: Thu, 19 Apr 2012 11:32:32 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F746163.5090506@hidayahonline.org> <4F8FBB8E.6000802@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] Proposal for H.263 baseline 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: Thu, 19 Apr 2012 15:33:09 -0000 On 4/19/2012 7:32 AM, Marshall Eubanks wrote: > On Thu, Apr 19, 2012 at 3:15 AM, Randell Jesup wrote: >> On 3/29/2012 1:12 PM, Silvia Pfeiffer wrote: >>> >>> Very interesting discussion. Out of personal curiosity, I have some >>> questions inline. >>> >>> On Thu, Mar 29, 2012 at 7:20 AM, Stephan Wenger wrote: >>>> >>>> >>>> The most commonly cited timeline for a widely in use technology to be >>>> "save" from a patent viewpoint, based on equitable defenses such as >>>> laches >>>> (in the US) is six years. >>> >>> >>> Very interesting to know the usually used limit on the number of >>> years. IIUC that would make Speex, Vorbis and Theora "save" codecs, >>> since they were released in 2003, 2000, and 2004 respectively? >> >> >> IANAL: No, since the defense (with some notable exceptions) is by a >> specific person against delayed assertion of a suit against them, so someone >> using Speex for example could not use that defense for circa 6 years after >> they began using it. Note that publication of a spec doesn't violate a >> patent (though using it may). In practice the defense might be even more >> limited, for example if the infringer made very limited use of the patent >> for years such that the owner didn't even know they were infringing; it's >> possible the court might start the clock when the owner knew or could/should >> have known of the infringement. >> > > I found a fairly detailed analysis of the defense of laches in patent > cases starting at page 27 of this > > http://www.fdml.com/defenses.pdf > > Reading this dense legal reasoning makes me very nervous about relying > on any of this for any IETF decision. Engineers should not > pretend they are lawyers. Quite true (though I've played one on TV^H^H^H^H^H^H^H^H^H amateur lawyer quite a bit in a former job). That document agrees with my comments (IANAL!!) so far as I can tell, and the basic answer is still "No, do not assume you're safe because you're using a codec published more than 6 years ago." Not assuming you're safe is always the safe thing to do. ;-) -- Randell Jesup randell-ietf@jesup.org From mary.ietf.barnes@gmail.com Thu Apr 19 10:50: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 5A40821F8649 for ; Thu, 19 Apr 2012 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.608 X-Spam-Level: X-Spam-Status: No, score=-103.608 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 YN+PoLhB0pFl for ; Thu, 19 Apr 2012 10:50: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 E0C0721F8646 for ; Thu, 19 Apr 2012 10:50:12 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6834543vbb.31 for ; Thu, 19 Apr 2012 10:50:12 -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=BhniTg/HaYzgbs3XuYWfGr+gWpJghz1J6r2pSd3kfjg=; b=zYYgA2kKP2xMgbReG47nlNHv4bcPMjigHVCSmBlknKgaJtNTRPpi/jv9Y9CHWn5V3K YMN34nLgEbVTqbn36Ev9+iRKcehzUsmduTm1j7JcWoyxEu+gx06mBf1G8BcLWeg/O+F2 d5R8JZ2pBlEgWyudb9ve8nNqEexiA6Lqfzj14KQEvnBGSGaWbOolmT36bASEtSKX66RH eFpvo9oNBw0Eh4jccqFhDTyR8swq3g7CwYONz8Da3F3QJf7Yd+ejrw+9H2qh3eq+fpir 01vIt/Gx22Ub12csDAXIFX3AngjK4/qTS8sCmSOXJEf1WXi+8SsbxZVbi3/BKCa8Kl2x D1wA== MIME-Version: 1.0 Received: by 10.52.73.132 with SMTP id l4mr1335886vdv.4.1334857812380; Thu, 19 Apr 2012 10:50:12 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 19 Apr 2012 10:50:12 -0700 (PDT) Date: Thu, 19 Apr 2012 12:50:12 -0500 Message-ID: From: Mary Barnes To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf3071c7e0bb8d0b04be0bcd97 Subject: [rtcweb] CLUE WG interim 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 Apr 2012 17:50:14 -0000 --20cf3071c7e0bb8d0b04be0bcd97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For folks that are not on the CLUE WG mailing list, it is highly likely that we will be able to hold our interim meeting in Stockholm on June 7th-8th. If you would like to also attend the CLUE meeting, then if you could please indicate Stockholm as your location preference in our poll. Thanks, Mary CLUE WG co-chair ---------- Forwarded message ---------- From: Mary Barnes Date: Thu, Apr 19, 2012 at 12:46 PM Subject: Re: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON HOL= D To: Marshall Eubanks Cc: clue As I've highlighted in previous emails, we have a doodle for location selection for the CLUE meeting: http://www.doodle.com/wwrdycma9ymrdn3r This poll closes at noon Pacific today - i.e., in 1.5 hours. So, we will make the decision for the location at the end of today. Note that our date has been set for June 7-8 based on our original poll: http://doodle.com/nm3pp69znr3286cy Please note, that there are significantly fewer people that have responded to the location doodle poll than people that indicated they could attend the meeting on the 7th-8th, per the poll for meeting dates. So we'll assume whomever doesn't respond to the location poll is okay with any of the locations. Folks that want to attend both meetings are strongly encouraged to indicate their preference for Stockholm unless you want to spend the weekend traveling from Boston or San Jose. Thanks, Mary. On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > FYI > > > ---------- Forwarded message ---------- > From: Magnus Westerlund > Date: Thu, Apr 19, 2012 at 5:18 AM > Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD > To: Ted Hardie > Cc: Cullen Jennings , "rai-ads@tools.ietf.org" > , "rtcweb@ietf.org" , > "clue-chairs@tools.ietf.org" > > > RTCWEB WG, > > The dates for the upcoming interim is off the hold. I can confirm AD > approval, and that we will hold an Face to Face interim meeting on the > 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a > meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for > each of those days. > > As a Host I can't confirm the location within Stockholm yet. We are > aiming on either a location in Kista or in the central part of town. > There are some hotels out in Kista, but even if we end up in Kista > staying in central Stockholm allows for a short (17 min) subway ride > from T-centralen plus a no more than 10 min walk to the Kista venue. > Making it a very viable option to book a hotel room in the area around > T-centralen or on Kungsholmen with easy access to the blue-line subway. > > Cheers > > Magnus Westerlund > > > > > On 2012-04-12 19:42, Ted Hardie wrote: > > Please hold off making travel plans based on this timing. Because > > neither RAI area director will be available during this timing, they > > have asked to consider shifting this timing to the previous week, June > > 7th and 8th. Until the chairs have had a chance to discuss this, > > please hold off on booking travel plans. > > > > My apologies for this scramble, > > > > Ted Hardie > > > > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: > >> After discussion between the WEBRTC and RTCWEB chairs, consulting the > >> doodle poll, and working through the potential for co-location with > >> CLUE, we have decided to set the date for the RTCWEB interim at June > >> 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that > >> the WEBRTC chairs will hold their meeting on June 11th. If CLUE > >> wishes to co-locate their meeting, the 14th and 15th will be > >> available. This would not have been possible on the previous week, > >> given the national holiday in Sweden on the Wednesday of that week. > >> > >> We very much appreciated the work Eric put into his analysis, and in > >> general we will try to prefer hubs; in this particular case, however, > >> a large fraction of the Western European participants are either based > >> in Stockholm or must fly through it to reach one of the larger hubs. > >> Given the availability of a host and this data, we decided to select > >> Stockholm for this meeting. > >> > >> regards, > >> > >> Ted Hardie, for the chairs. > > > > > -- > > 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 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3071c7e0bb8d0b04be0bcd97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For folks that are not on the CLUE WG mailing list, it is highly likely tha= t we will be able to hold our interim meeting in Stockholm on June 7th-8th.= =A0If you would like to also attend the CLUE meeting, then if you could pl= ease indicate Stockholm as your location preference in our poll.=A0

Thanks,
Mary
CLUE WG co-chair

---------- Forwarded message ----------
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thu, Apr 19, 2012 at 12:46 PM
Subject: Re: [clue] Fwd: [rtcweb] UR= GENT: Dates for upcoming interim ON HOLD
To: Marshall Eubanks <marshall.eubanks@gmail.com><= br> Cc: clue <clue@ietf.org>

=
As I've highlighted in previous emails, we have a doodle for locati= on selection for the CLUE meeting:=A0
This poll closes at noon Pacific today - i.e., in 1.5 hours. =A0So, we= will make the decision for the location at the end of today.

Note that our date has been set for June 7-8 based on o= ur original poll: =A0=A0http://doodle.com/nm3pp69znr3286cy

Please note, that there are significantly fewer people that have responded = to the location doodle poll than people that indicated they could attend th= e meeting on the 7th-8th, per the poll for meeting dates. =A0So we'll a= ssume whomever doesn't respond to the location poll is okay with any of= the locations. =A0Folks that want to attend both meetings are strongly enc= ouraged to indicate their preference for Stockholm unless you want to spend= the weekend traveling from Boston or San Jose.=A0

Thanks,
Mary.=A0

On Thu, Apr 19, 2012 at 6:35 AM, Marshall Euba= nks <marshall.eubanks@gmail.com> wrote:
FYI


---------- Forwarded message ----------
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Thu, Apr 19, 2012 at 5:18 AM
Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD
To: Ted Hardie <= ted.ietf@gmail.com>
Cc: Cullen Jennings <fluffy@cisco.com>, "rai-ads@tools.ietf.org"
<rai-ads@too= ls.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>,
"clue-= chairs@tools.ietf.org" <clue-chairs@tools.ietf.org>


RTCWEB WG,

The dates for the upcoming interim is off the hold. I can confirm AD
approval, and that we will hold an Face to Face interim meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a
meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for
each of those days.

As a Host I can't confirm the location within Stockholm yet. We are
aiming on either a location in Kista or in the central part of town.
There are some hotels out in Kista, but even if we end up in Kista
staying in central Stockholm allows for a short (17 min) subway ride
from T-centralen plus a no more than 10 min walk to the Kista venue.
Making it a very viable option to book a hotel room in the area around
T-centralen or on Kungsholmen with easy access to the blue-line subway.

Cheers

Magnus Westerlund




On 2012-04-12 19:42, Ted Hardie wrote:
> Please hold off making travel plans based on this timing. =A0 Because<= br> > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June=
> 7th and 8th. =A0Until the chairs have had a chance to discuss this, > please hold off on booking travel plans.
>
> My apologies for this scramble,
>
> Ted Hardie
>
> On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> After discussion between the WEBRTC and RTCWEB chairs, consulting = the
>> doodle poll, and working through the potential for co-location wit= h
>> CLUE, we have decided to set the date for the RTCWEB interim at Ju= ne
>> 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We unders= tand that
>> the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE=
>> wishes to co-locate their meeting, the 14th and 15th will be
>> available. =A0This would not have been possible on the previous we= ek,
>> given the national holiday in Sweden on the Wednesday of that week= .
>>
>> We very much appreciated the work Eric put into his analysis, and = in
>> general we will try to prefer hubs; in this particular case, howev= er,
>> a large fraction of the Western European participants are either b= ased
>> in Stockholm or must fly through it to reach one of the larger hub= s.
>> Given the availability of a host and this data, we decided to sele= ct
>> Stockholm for this meeting.
>>
>> regards,
>>
>> Ted Hardie, for the chairs.
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia 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@ericsson.com
----------------------------------------------------------------------

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


--20cf3071c7e0bb8d0b04be0bcd97-- From mary.ietf.barnes@gmail.com Thu Apr 19 15:52: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 6186E21F85EF for ; Thu, 19 Apr 2012 15:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.014, 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 oKcSgmwDua0Q for ; Thu, 19 Apr 2012 15:52:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A666121F85ED for ; Thu, 19 Apr 2012 15:52:03 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2492194vcb.31 for ; Thu, 19 Apr 2012 15:52: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=IJfnWq71FI8vLprl43FbM0VmzNvpSblzJlnOHW0RHZ8=; b=CmBS3MXxtn3uxUqIQ/6oC5G+V773Jk1uEHe1FZnw/Ayz7z/Oqw+XMEGfsgJApscAUx h5G2qhtT3RIMfw46Pi3yCPDlm9nDIosWxKUXY3i+3tXFw/dsG1na6kKmXk4/QT/os2Oy IpE3VIzBnVBjLk5iMYfOxzrTjPm9W6E60tYFaOxklo++qCqJn3tB6Zljr1W+sRuuLWax u90cMzAxQsITk1IueP3VaA0gftFd8i+xvVUfxtvjr99Cmv60hI4mgsOHWKZFxY2m9c5a PX9FIFHp0SHcjA849GmSl411QrX7SJOckphpozfpgmZHiD4fDwZ6wKPYbOZHRCmed7nt LhEA== MIME-Version: 1.0 Received: by 10.220.38.200 with SMTP id c8mr2228547vce.28.1334875923172; Thu, 19 Apr 2012 15:52:03 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 19 Apr 2012 15:52:03 -0700 (PDT) In-Reply-To: <4F8FD90B.5040409@ericsson.com> References: <4F8FD90B.5040409@ericsson.com> Date: Thu, 19 Apr 2012 17:52:03 -0500 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec54ee6be384b8a04be1005ce Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 22:52:05 -0000 --bcaec54ee6be384b8a04be1005ce Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I looked on Google maps and it indicates an 18 minute drive to Kista, but it looks like a 45 min trip as opposed to 30. Of course, I just did the calculation from Central Kista to Central Stockholm, so that doesn't account for the walking to/from meeting location (which perhaps is closer than the route I measured) nor to/from hotels in the City center. Also, just to confirm, Ericsson is also still willing to host the CLUE meeting? Thanks, Mary. On Thu, Apr 19, 2012 at 4:21 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > RTCWEB WG, > > The dates for the upcoming interim is off the hold. I can confirm AD > approval, and that we will hold an Face to Face interim meeting on the > 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a > meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for > each of those days. > > As a Host I can't confirm the location within Stockholm yet. We are > aiming on either a location in Kista or in the central part of town. > There are some hotels out in Kista, but even if we end up in Kista > staying in central Stockholm allows for a short (17 min) subway ride > from T-centralen plus a no more than 10 min walk to the Kista venue. > Making it a very viable option to book a hotel room in the area around > T-centralen or on Kungsholmen with easy access to the blue-line subway. > > Cheers > > Magnus Westerlund > -- > > 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 > --bcaec54ee6be384b8a04be1005ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I looked on Google maps and it indicates an 18 minute drive to Kista, but i= t looks like a 45 min trip as opposed to 30. =A0Of course, I just did the c= alculation from Central Kista to Central Stockholm, so that doesn't acc= ount for the walking to/from meeting location (which perhaps is closer than= the route I measured) nor to/from hotels in the City center.=A0

Also, just to confirm, Ericsson is also still willing to hos= t the CLUE meeting? =A0=A0

Thanks,
Mary. = =A0=A0

On Thu, Apr 19, 2012 at 4:2= 1 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
RTCWEB WG,

The dates for the upcoming interim is off the hold. I can confirm AD
approval, and that we will hold an Face to Face interim meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a
meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for
each of those days.

As a Host I can't confirm the location within Stockholm yet. We are
aiming on either a location in Kista or in the central part of town.
There are some hotels out in Kista, but even if we end up in Kista
staying in central Stockholm allows for a short (17 min) subway ride
from T-centralen plus a no more than 10 min walk to the Kista venue.
Making it a very viable option to book a hotel room in the area around
T-centralen or on Kungsholmen with easy access to the blue-line subway.

Cheers

Magnus Westerlund
--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia 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@ericsson.com
----------------------------------------------------------------------

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

--bcaec54ee6be384b8a04be1005ce-- From dean.willis@softarmor.com Thu Apr 19 21:42: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 5F9D321F8417 for ; Thu, 19 Apr 2012 21:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 dQo-AffhxkYM for ; Thu, 19 Apr 2012 21:42: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 A289C21F8527 for ; Thu, 19 Apr 2012 21:42:43 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8788777obb.31 for ; Thu, 19 Apr 2012 21:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; bh=szpB1tSd7B6M1hYE1qZy6awW2KUMKi7rdgWjxgCCFwM=; b=aZ2AOp0xEdh8bU1euAheY01gHksC2SaKQHT7FdUSXqzlNiD1bd8G924DispbwSnGid K5hlTbK9IYqfSjXU4EJvc0lj+HPVnAg2ng8qh7iHnf8qWnJSkZM8c80bXA3zKPOdaOSt mVvuSDmcj0ZrAQjmGGVlieKfX9N9x4ML3laus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer :x-gm-message-state; bh=szpB1tSd7B6M1hYE1qZy6awW2KUMKi7rdgWjxgCCFwM=; b=D35bJCkjna7AuvXgKGu3WJe7D+hrxijCPNrz6F+hv2OnpTynldbROxhtRDmVV62RgG uEl+iqeXESkdsE25bqFWSZgtDNqsB1lY3G1vVHe+aIKk37QHpy31SBiuGq+NtFf3tpF7 3e/YQnIMUk8YyrzomSQwc4G8D223Zfr9eqhxt+MT5Lt+vwR2OI22uK7s6A2tXLVL6O62 2yB83V7LJ3RoVo/O3G7zr8ruLuu4QS0M0DJPLxWd2wyD1iBEi2Z6bG6AMqYvsqfz/Yyg aEM8sMHE6bmDOB+ccApOszlqBouqg3YtDUDJ/8wtAOCaoFT7gQdqpve/83ZPdyvMCTEz 3leg== Received: by 10.182.207.10 with SMTP id ls10mr6848575obc.9.1334896961374; Thu, 19 Apr 2012 21:42:41 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id h5sm5295565oba.17.2012.04.19.21.42.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 21:42:40 -0700 (PDT) References: <4F746163.5090506@hidayahonline.org> <4F8FBB8E.6000802@jesup.org> <4F903010.80504@jesup.org> In-Reply-To: <4F903010.80504@jesup.org> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Thu, 19 Apr 2012 23:42:39 -0500 To: Randell Jesup X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQks5/vYk5QpWuwIjM+dcD39relvs8fMpm/EiF3xDFDggmmt+Uqi9okDjs6eMjMCAgHeE15z Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for H.263 baseline 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: Fri, 20 Apr 2012 04:42:58 -0000 On Apr 19, 2012, at 10:32 AM, Randell Jesup wrote: >>=20 >=20 > Quite true (though I've played one on TV^H^H^H^H^H^H^H^H^H amateur = lawyer quite a bit in a former job). That document agrees with my = comments (IANAL!!) so far as I can tell, and the basic answer is still = "No, do not assume you're safe because you're using a codec published = more than 6 years ago." Not assuming you're safe is always the safe = thing to do. ;-) >=20 To paraphrase Whedon: You're never truly safe; the ancient ones are down = there waiting. Miss a blood sacrifice, and there''s hell to pay. Or, Lubarsky's alternative cognate: There's always one more patent. There is, however, a margin of safety in numbers. If many little red = riding hoods have walked the path before you and others walk beside you, = the chance of meeting a wolf are reduced. Or you might just meet a VERY = HUNGRY wolf. But you have a chance of hearing the screams and being able = to run away. On the other hand, if you KNOW there's a wolf on the hunt, stay home. -- Dean= From magnus.westerlund@ericsson.com Thu Apr 19 23:56: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 3F49721E8034 for ; Thu, 19 Apr 2012 23:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.21 X-Spam-Level: X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=0.039, 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 C1Wmex5L6Zxj for ; Thu, 19 Apr 2012 23:56:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E470521E8032 for ; Thu, 19 Apr 2012 23:56:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-ec-4f9108ab514d Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F0.F4.25560.CA8019F4; Fri, 20 Apr 2012 08:56:44 +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.213.0; Fri, 20 Apr 2012 08:56:43 +0200 Message-ID: <4F9108AB.9020002@ericsson.com> Date: Fri, 20 Apr 2012 08:56:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mary Barnes References: <4F8FD90B.5040409@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 06:56:49 -0000 On 2012-04-20 00:52, Mary Barnes wrote: > I looked on Google maps and it indicates an 18 minute drive to Kista, > but it looks like a 45 min trip as opposed to 30. Of course, I just did > the calculation from Central Kista to Central Stockholm, so that doesn't > account for the walking to/from meeting location (which perhaps is > closer than the route I measured) nor to/from hotels in the City center. Well, why would you be driving? The subway system takes approx 17 minutes between T-centralen and Kista station. If you would driving to and from central Stockholm in rush hour, which is what you will face arriving between 8-9 in the morning and going back around 18, it can definitely takes 30-40 minutes. Plus you have to pay congestion charges when entering or leaving downtown. Plus the expense of parking. As we haven't managed to get a solid booking on a meeting room yet I can't say exactly where the meeting will be held. I still think staying in the city center will be a good option for most as it gives easy access to a very large selection of restaurants. My recommendation is to not rent a car. Use the subway system or other trains to get around. A 72 hour (3 day) ticket for the subway, local trains and buses are 230 sek for unlimited travel. Anyone attending both the CLUE and WebRTC meetings a 7-day unlimited travel ticket might be a good buy, it cost 300 sek. Of course single tickets or strips for a limited number of trips are available (For more information on Stockholm local travel (http://sl.se/). The unlimited tickets even work on some boat lines. To get to and from the airport if you would staying in Kista you take a Taxi approx 400 sek. If one goes downtown and have a hotel in the vicinity of the central station then taking Arlanda Express (http://www.arlandaexpress.com) is a good option. 260 sek for single or 490 for a return ticket. This is an express train that takes 20 min from Arlanda to Centralen. Taxi Arlanda to central Stockholm is available for a fixed price from most Taxi companies which is around 520 sek. Important about Taxi in Stockholm. This is a de-regulated market. The driver or their companies can basically set the fares in the meters freely. The only requirement is that they have a yellow sticker visible that gives you a comparison price for a trip. They also need to display the drivers Taxi license. I strongly recommend that you use one of the three big companies: - Taxi 020 http://www.taxi020.se/ - Taxi Stockholm http://www.taxistockholm.se/ - Taxi Kurir http://www.taxikurir.se/stockholm The highest comparison price for a regular sized car shouldn't be more than around 310 Sek. If it is more than 400 you are definitely getting ripped off. Taxi is quite expensive in Sweden. A plus side is that all the big companies do take credit cards. > > Also, just to confirm, Ericsson is also still willing to host the CLUE > meeting? Yes, we are. 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 lars@netapp.com Fri Apr 20 01:37: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 1E9F521F8767 for ; Fri, 20 Apr 2012 01:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.731 X-Spam-Level: X-Spam-Status: No, score=-10.731 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 5P6UMBVQySEx for ; Fri, 20 Apr 2012 01:37:54 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 91CC321F875E for ; Fri, 20 Apr 2012 01:37:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,452,1330934400"; d="p7s'?scan'208";a="642231711" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Apr 2012 01:37:49 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q3K8bnrf022986; Fri, 20 Apr 2012 01:37:49 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.117]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Fri, 20 Apr 2012 01:37:49 -0700 From: "Eggert, Lars" To: Magnus Westerlund Thread-Topic: [rtcweb] Confirmation of F2F Interim meeting Thread-Index: AQHNHg3O+ERf37knqEGpA75TkxtX8ZajN0+AgACHaoCAABxBAA== Date: Fri, 20 Apr 2012 08:37:48 +0000 Message-ID: <3DECE915-FE20-4858-BBF0-46930DD36248@netapp.com> References: <4F8FD90B.5040409@ericsson.com> <4F9108AB.9020002@ericsson.com> In-Reply-To: <4F9108AB.9020002@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_04FB2037-C1A1-4283-B958-71F5DBF46D89"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 08:37:55 -0000 --Apple-Mail=_04FB2037-C1A1-4283-B958-71F5DBF46D89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 20, 2012, at 8:56, Magnus Westerlund wrote: > As we haven't managed to get a solid booking on a meeting room yet I > can't say exactly where the meeting will be held. I still think = staying > in the city center will be a good option for most as it gives easy > access to a very large selection of restaurants. +1 Take it from someone who travelled to Kista many times on project work: = you do want to stay downtown (on the blue line). Lars= --Apple-Mail=_04FB2037-C1A1-4283-B958-71F5DBF46D89 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMDA4Mzc1MVowIwYJKoZIhvcNAQkEMRYEFDk7 CjJe6wsqVFf69Izb2XdiREfFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAEJSSJNL WlcvTwRo3mGeRbyyPMG/s9fMqVaaI+eZ01a1NxOAhioRYgtCN8SZfbipLvyY9im9HQRsteAgZ1L0 1Rj9QpsuZDABXBtTlWoEXQ0+LlVWiLBN44/Ap8I5jE1/Ghgysqo2Q/+6ANZujd7AP/OXS1Jh7CMP Zj8Tjy3X6PwnScl13pkoO4nQAn8CVh8A1ovg/t7baxf8yDTsRBGVOxAsR1Hg9rSmPGFVZbM9A97T ftGhcSPxDacc0z9PFakPbNJpaZuxPxxdMI7WkhD0ypr3EGuS4iv8suvnR67ByOZrgdxawRwSIcQU iBeRRxIdUY60mAa3UgVmnc6wNBJvPEQAAAAAAAA= --Apple-Mail=_04FB2037-C1A1-4283-B958-71F5DBF46D89-- From mary.ietf.barnes@gmail.com Fri Apr 20 07:42: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 86BF821F8764 for ; Fri, 20 Apr 2012 07:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 kHoR+nQbT+cK for ; Fri, 20 Apr 2012 07:42:05 -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 1F17D21F872A for ; Fri, 20 Apr 2012 07:42:05 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7611011vbb.31 for ; Fri, 20 Apr 2012 07:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q/2fSd7UHVcpVVNeVKtsLtB2oMMMORef5gwM/wbRzZQ=; b=MwOv55scx3bAghyBiiLBTbDc4R/FT5YhylbDLz23DCHRVrehwO0COqOL2rQ57nB6F/ LIPzyREGjAwfjDQ6gVOJRFERVY7bAV+vdmBtwGu2NDLmm006xFK6tbQEDs2dY5IVP//Y SiblM6t0U417IFmKRKtko7yvxmZx4lFKR7AmaIOIAKcznW0a+sLdsVM8Cq35tUTknYnE H10UDQriIuaBv9mmJq/vuZzcfjvTVMf2WvcxIudoc6Sm98/wkwv5/16r/OFSSfOlES2l 5Ojr8XwueYmISrxYC5BlVPRcC2t+P0UcBShJCLUXuTM/JctPOLr/k7GxjkX2Tsdq+VuN lU+g== MIME-Version: 1.0 Received: by 10.220.115.82 with SMTP id h18mr5013793vcq.18.1334932924541; Fri, 20 Apr 2012 07:42:04 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Fri, 20 Apr 2012 07:42:04 -0700 (PDT) In-Reply-To: <4F9108AB.9020002@ericsson.com> References: <4F8FD90B.5040409@ericsson.com> <4F9108AB.9020002@ericsson.com> Date: Fri, 20 Apr 2012 09:42:04 -0500 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d043c7c78c429a604be1d4a4d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 14:42:07 -0000 --f46d043c7c78c429a604be1d4a4d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had not intention to drive, I used the train symbol option on Google maps. That's why my question as to perhaps Google maps calculations are off for that route. That calculation included walking time from what Google maps has as city centers to the train stations, but that's probably a reasonable buffer given the figures you note, which don't include the wait times for trains. Thanks, Mary. On Fri, Apr 20, 2012 at 1:56 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2012-04-20 00:52, Mary Barnes wrote: > > I looked on Google maps and it indicates an 18 minute drive to Kista, > > but it looks like a 45 min trip as opposed to 30. Of course, I just di= d > > the calculation from Central Kista to Central Stockholm, so that doesn'= t > > account for the walking to/from meeting location (which perhaps is > > closer than the route I measured) nor to/from hotels in the City center= . > > Well, why would you be driving? The subway system takes approx 17 > minutes between T-centralen and Kista station. If you would driving to > and from central Stockholm in rush hour, which is what you will face > arriving between 8-9 in the morning and going back around 18, it can > definitely takes 30-40 minutes. Plus you have to pay congestion charges > when entering or leaving downtown. Plus the expense of parking. > > As we haven't managed to get a solid booking on a meeting room yet I > can't say exactly where the meeting will be held. I still think staying > in the city center will be a good option for most as it gives easy > access to a very large selection of restaurants. > > My recommendation is to not rent a car. Use the subway system or other > trains to get around. A 72 hour (3 day) ticket for the subway, local > trains and buses are 230 sek for unlimited travel. Anyone attending both > the CLUE and WebRTC meetings a 7-day unlimited travel ticket might be a > good buy, it cost 300 sek. Of course single tickets or strips for a > limited number of trips are available (For more information on Stockholm > local travel (http://sl.se/). The unlimited tickets even work on some > boat lines. > > To get to and from the airport if you would staying in Kista you take a > Taxi approx 400 sek. If one goes downtown and have a hotel in the > vicinity of the central station then taking Arlanda Express > (http://www.arlandaexpress.com) is a good option. 260 sek for single or > 490 for a return ticket. This is an express train that takes 20 min from > Arlanda to Centralen. Taxi Arlanda to central Stockholm is available for > a fixed price from most Taxi companies which is around 520 sek. > > Important about Taxi in Stockholm. This is a de-regulated market. The > driver or their companies can basically set the fares in the meters > freely. The only requirement is that they have a yellow sticker visible > that gives you a comparison price for a trip. They also need to display > the drivers Taxi license. I strongly recommend that you use one of the > three big companies: > > - Taxi 020 http://www.taxi020.se/ > - Taxi Stockholm http://www.taxistockholm.se/ > - Taxi Kurir http://www.taxikurir.se/stockholm > > The highest comparison price for a regular sized car shouldn't be more > than around 310 Sek. If it is more than 400 you are definitely getting > ripped off. > > Taxi is quite expensive in Sweden. A plus side is that all the big > companies do take credit cards. > > > > > Also, just to confirm, Ericsson is also still willing to host the CLUE > > meeting? > > Yes, we are. > > 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 > ---------------------------------------------------------------------- > > --f46d043c7c78c429a604be1d4a4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had not intention to drive, I used the train symbol option on Google maps= . =A0That's why my question as to perhaps Google maps calculations are = off for that route. =A0 That calculation included walking time from what Go= ogle maps has as city centers to the train stations, but that's probabl= y a reasonable buffer given the figures you note, which don't include t= he wait times for trains.=A0

Thanks,
Mary.=A0

On Fri, Apr 20, 2012 at 1:56 AM, Magnus Westerlund <= magnus.westerlund@ericsso= n.com> wrote:
On 2012-04-20 00:52, Mary = Barnes wrote:
> I looked on Google maps and it indicates an 18 minute drive to Kista,<= br> > but it looks like a 45 min trip as opposed to 30. =A0Of course, I just= did
> the calculation from Central Kista to Central Stockholm, so that doesn= 't
> account for the walking to/from meeting location (which perhaps is
> closer than the route I measured) nor to/from hotels in the City cente= r.

Well, why would you be driving? The subway system takes approx 17
minutes between T-centralen and Kista station. If you would driving to
and from central Stockholm in rush hour, which is what you will face
arriving between 8-9 in the morning and going back around 18, it can
definitely takes 30-40 minutes. Plus you have to pay congestion charges
when entering or leaving downtown. Plus the expense of parking.

As we haven't managed to get a solid booking on a meeting room yet I can't say exactly where the meeting will be held. I still think staying=
in the city center will be a good option for most as it gives easy
access to a very large selection of restaurants.

My recommendation is to not rent a car. Use the subway system or other
trains to get around. A 72 hour (3 day) ticket for the subway, local
trains and buses are 230 sek for unlimited travel. Anyone attending both the CLUE and WebRTC meetings a 7-day unlimited travel ticket might be a
good buy, it cost 300 sek. Of course single tickets or strips for a
limited number of trips are available (For more information on Stockholm local travel (http://sl.se/= ). The unlimited tickets even work on some
boat lines.

To get to and from the airport if you would staying in Kista you take a
Taxi approx 400 sek. If one goes downtown and have a hotel in the
vicinity of the central station then taking Arlanda Express
(http://www.arl= andaexpress.com) is a good option. 260 sek for single or
490 for a return ticket. This is an express train that takes 20 min from Arlanda to Centralen. Taxi Arlanda to central Stockholm is available for a fixed price from most Taxi companies which is around 520 sek.

Important about Taxi in Stockholm. This is a de-regulated market. The
driver or their companies can basically set the fares in the meters
freely. The only requirement is that they have a yellow sticker visible
that gives you a comparison price for a trip. They also need to display
the drivers Taxi license. I strongly recommend that you use one of the
three big companies:

- Taxi 020 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.taxi020.se/
- Taxi Stockholm =A0 =A0 =A0 =A0http://www.taxistockholm.se/
- Taxi Kurir =A0 =A0 =A0 =A0 =A0 =A0http://www.taxikurir.se/stockholm

The highest comparison price for a regular sized car shouldn't be more<= br> than around 310 Sek. If it is more than 400 you are definitely getting
ripped off.

Taxi is quite expensive in Sweden. A plus side is that all the big
companies do take credit cards.

>
> Also, just to confirm, Ericsson is also still willing to host the CLUE=
> meeting?

Yes, we are.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia 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@ericsson.com
----------------------------------------------------------------------


--f46d043c7c78c429a604be1d4a4d-- From kpfleming@digium.com Fri Apr 20 13:25: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 7EC1321F855B for ; Fri, 20 Apr 2012 13:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 a6O5Do-V5kR3 for ; Fri, 20 Apr 2012 13:24:59 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id C38FF21F8549 for ; Fri, 20 Apr 2012 13:24:58 -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 1SLKO1-0008Iw-Pn for rtcweb@ietf.org; Fri, 20 Apr 2012 15:24:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C34911A2006 for ; Fri, 20 Apr 2012 15:24:57 -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 MMXCcauUlTqK for ; Fri, 20 Apr 2012 15:24:57 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 56E181A2001 for ; Fri, 20 Apr 2012 15:24:57 -0500 (CDT) Message-ID: <4F91C613.4050701@digium.com> Date: Fri, 20 Apr 2012 15:24:51 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.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] Proposal for H.263 baseline 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: Fri, 20 Apr 2012 20:25:00 -0000 On 03/29/2012 09:53 AM, Stephan Wenger wrote: > The other issue, though (the fact that the license grant extends only to > the VP8 implementation as provided by google, and does not extent to > derivative works such as hardware implementations) should be moderately > alarming even for an open source person. With respect to this clause, I This is concerning, even for us open source software distributors. In fact, a similar situation existed some time ago with iLBC; the license that GIPS offered covered only the code as distributed as part of the RFC (although the language stating this was quite poorly constructed), and that code had (and still has) fundamental issues (it has at least two places where it invokes 'undefined behavior' according to the C standard). When we fixed these problems in our distribution, and then I re-read the license, I realized that the license did not allow us to distribute this modified version. We later managed to get explicit permission from Google to distribute a modified version, as they have changed the license to no longer have this restriction. The WebM patent license has much of the same problem, though: it only applies to distributions of the code made by Google, without changes (no derivative works). At least, this is my reading of it, being an engineer married to a lawyer who handles such things, but not a lawyer myself :-) -- 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 basilgohar@librevideo.org Fri Apr 20 13:28: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 DB8A821F85AF for ; Fri, 20 Apr 2012 13:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.602, 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 iBkvAFVbGzy4 for ; Fri, 20 Apr 2012 13:28:15 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5EA21F8566 for ; Fri, 20 Apr 2012 13:28:15 -0700 (PDT) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (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 61DA76430F8 for ; Fri, 20 Apr 2012 16:28:14 -0400 (EDT) Message-ID: <4F91C6DC.3050001@librevideo.org> Date: Fri, 20 Apr 2012 16:28:12 -0400 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F91C613.4050701@digium.com> In-Reply-To: <4F91C613.4050701@digium.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for H.263 baseline 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: Fri, 20 Apr 2012 20:28:16 -0000 On 04/20/2012 04:24 PM, Kevin P. Fleming wrote: > On 03/29/2012 09:53 AM, Stephan Wenger wrote: > >> The other issue, though (the fact that the license grant extends only to >> the VP8 implementation as provided by google, and does not extent to >> derivative works such as hardware implementations) should be moderately >> alarming even for an open source person. With respect to this clause, I > > > This is concerning, even for us open source software distributors. In > fact, a similar situation existed some time ago with iLBC; the license > that GIPS offered covered only the code as distributed as part of the > RFC (although the language stating this was quite poorly constructed), > and that code had (and still has) fundamental issues (it has at least > two places where it invokes 'undefined behavior' according to the C > standard). When we fixed these problems in our distribution, and then > I re-read the license, I realized that the license did not allow us to > distribute this modified version. We later managed to get explicit > permission from Google to distribute a modified version, as they have > changed the license to no longer have this restriction. > > The WebM patent license has much of the same problem, though: it only > applies to distributions of the code made by Google, without changes > (no derivative works). At least, this is my reading of it, being an > engineer married to a lawyer who handles such things, but not a lawyer > myself :-) > The answer that I have seen mentioned is simply that Google cannot know what patents someone is infringing on if they extend or modify the code or make an independent implementation. One thing that I do know is a completely independent implementation is being done by some of the developers of x264 (and naming their project xvp8 as a result), and this is happening with the implicit blessing of Google, because development is being tracked in the #vp8 channel on FreeNode. So, Google is fine with this kind of development happening. However, having explicit license for this kind of behavior would be much better, and is sorely needed, considering all the other challenges facing VP8 adoption. -- Libre Video http://librevideo.org From harald@alvestrand.no Fri Apr 20 14:05: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 1C33C21F84E4 for ; Fri, 20 Apr 2012 14:05:57 -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 jQqMMfM8KXhS for ; Fri, 20 Apr 2012 14:05:56 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E160D21F84D8 for ; Fri, 20 Apr 2012 14:05:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D2ABB39E0C0 for ; Fri, 20 Apr 2012 23:05:54 +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 IsjAs+Edh96s for ; Fri, 20 Apr 2012 23:05:54 +0200 (CEST) Received: from [172.28.95.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EECD039E082 for ; Fri, 20 Apr 2012 23:05:53 +0200 (CEST) Message-ID: <4F91CFB0.6090101@alvestrand.no> Date: Fri, 20 Apr 2012 23:05:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F91C613.4050701@digium.com> In-Reply-To: <4F91C613.4050701@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for H.263 baseline 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: Fri, 20 Apr 2012 21:05:57 -0000 On 04/20/2012 10:24 PM, Kevin P. Fleming wrote: > On 03/29/2012 09:53 AM, Stephan Wenger wrote: > >> The other issue, though (the fact that the license grant extends only to >> the VP8 implementation as provided by google, and does not extent to >> derivative works such as hardware implementations) should be moderately >> alarming even for an open source person. With respect to this clause, I > > > This is concerning, even for us open source software distributors. In > fact, a similar situation existed some time ago with iLBC; the license > that GIPS offered covered only the code as distributed as part of the > RFC (although the language stating this was quite poorly constructed), > and that code had (and still has) fundamental issues (it has at least > two places where it invokes 'undefined behavior' according to the C > standard). When we fixed these problems in our distribution, and then > I re-read the license, I realized that the license did not allow us to > distribute this modified version. We later managed to get explicit > permission from Google to distribute a modified version, as they have > changed the license to no longer have this restriction. > > The WebM patent license has much of the same problem, though: it only > applies to distributions of the code made by Google, without changes > (no derivative works). At least, this is my reading of it, being an > engineer married to a lawyer who handles such things, but not a lawyer > myself :-) > This was already addressed by Serge' mail of April 3. See also the FAQ: http://www.webmproject.org/about/faq/#does-the-vp8-patent-grant-also-extend-to-hardware-implementations If this isn't clear enough, please explain why it is not, so that we can make it even clearer. From gmaxwell@juniper.net Fri Apr 20 14:22: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 26D9B21F8562 for ; Fri, 20 Apr 2012 14:22:14 -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 QwFdfe3dGl-J for ; Fri, 20 Apr 2012 14:22:12 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id BD5C821F8499 for ; Fri, 20 Apr 2012 14:22:11 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT5HTgcIHCvMZlVCVG9yuf0rGgDWWPsIl@postini.com; Fri, 20 Apr 2012 14:22:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 20 Apr 2012 14:19:12 -0700 From: Gregory Maxwell To: "EXT - kpfleming@digium.com" , "rtcweb@ietf.org" Date: Fri, 20 Apr 2012 14:19:11 -0700 Thread-Topic: [rtcweb] Proposal for H.263 baseline codec Thread-Index: Ac0fM6xo180AAEtzSLalmsQWWTSfhwAAfcYy Message-ID: References: ,<4F91C613.4050701@digium.com> In-Reply-To: <4F91C613.4050701@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Proposal for H.263 baseline 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: Fri, 20 Apr 2012 21:22:14 -0000 pfleming@digium.com wrote: >On 03/29/2012 09:53 AM, Stephan Wenger wrote: >> The other issue, though (the fact that the license grant extends only to >> the VP8 implementation as provided by google, and does not extent to >> derivative works such as hardware implementations) should be moderately > This is concerning, even for us open source software distributors. In > fact, a similar situation existed some time ago with iLBC; the license > that GIPS offered covered only the code as distributed as part of the > RFC (although the language stating this was quite poorly constructed), Stop. All of you are confused. Maybe I can help=97 There are _two_ VP8 patent license grants: One for the specification: http://www.webmproject.org/license/bitstream/ One for the software: http://www.webmproject.org/license/additional/ These grants are subtly different in the scope of what they cover. There are important licensing drafting reasons for a construction which distinguishes "an implementation" and "any implementation". In particular, the license drafter writing this kind of a royalty free license has a tricky time making sure that the permission is broad enough to include all the correct coverage, but not so over-broad that a malicious implementer could (e.g.) add a search engine to their VP8 encoder and claim that the VP8 license entitles them to search patents. So, the drafter says something like=97 "those patent claims [...] that are necessarily infringed by implementation of this specification", which achieves the desired limited scope=97 and that is _all_ you get with the MPEG-LA pool patent licenses. This is what the Google bitstream spec license provides. But, if we're to be serious and honest about making a royalty free format and implementation that permission isn't quite sufficient: The reference implementation might practice some VP8 related techniques which are not "necessarily infringed"=97 they're helpful performance enhancements, they could simply be one option out of many ways of doing the same thing, or could just be something that was incidentally included (or even a malicious patent trap snake in the grass)=97 and so it's important that everything in the reference software also be licensed=97 even if its not "necessarily infringed" by the specification. But since it's not a goal to also license unrelated things that a downstream user may cram in (e.g. a search engine), that license must be limited in scope to things which are actually in the reference implementation: "This grant does not include claims that would be infringed only as a consequence of further modification of this implementation." (this language is actually almost identical to the language for this purpose in the GPL, FWIW) So, in summary: You are licensed, via the bitstream license, for anything Google controls which is necessary to implement the specification=97 in hardware, software, home grown, or reference implementations. This is pretty much as strong a grant as you can find anyone offering for any other format specification. You are also licensed, via the additional rights license, for any use of the VP8 reference implementation including modified versions, limited to the extent that the modifications don't expand the scope of the coverage. (Exactly as the GPL explicit patent grant does) This has already been clarified by Google on this list: "Google confirms that the VP8 patent grant applies to both third-party hardware and software implementations of VP8." http://www.ietf.org/mail-archive/web/rtcweb/current/msg04006.html I admit that the fact that there are two similar but distinct licenses is a little confusing, but I don't understand why we have to go over it again and again on this list. I would think that the prior Google comment would have been sufficiently definitive. From kpfleming@digium.com Fri Apr 20 14:50: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 962A721F851B for ; Fri, 20 Apr 2012 14:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 rizD2nvrXIjr for ; Fri, 20 Apr 2012 14:50:47 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08521F850C for ; Fri, 20 Apr 2012 14:50:47 -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 1SLLj4-0000vx-6O for rtcweb@ietf.org; Fri, 20 Apr 2012 16:50:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 319021A2006 for ; Fri, 20 Apr 2012 16:50:46 -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 Zqf797JiSOV3 for ; Fri, 20 Apr 2012 16:50:45 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 9047F1A2001 for ; Fri, 20 Apr 2012 16:50:45 -0500 (CDT) Message-ID: <4F91DA2F.1080406@digium.com> Date: Fri, 20 Apr 2012 16:50:39 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 CC: "rtcweb@ietf.org" References: , <4F91C613.4050701@digium.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Proposal for H.263 baseline 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: Fri, 20 Apr 2012 21:50:48 -0000 On 04/20/2012 04:19 PM, Gregory Maxwell wrote: > pfleming@digium.com wrote: >> On 03/29/2012 09:53 AM, Stephan Wenger wrote: >>> The other issue, though (the fact that the license grant extends only= to >>> the VP8 implementation as provided by google, and does not extent to >>> derivative works such as hardware implementations) should be moderate= ly >> This is concerning, even for us open source software distributors. In >> fact, a similar situation existed some time ago with iLBC; the license >> that GIPS offered covered only the code as distributed as part of the >> RFC (although the language stating this was quite poorly constructed), > > Stop. All of you are confused. > > Maybe I can help=97 > > There are _two_ VP8 patent license grants: > > One for the specification: http://www.webmproject.org/license/bitstream= / > One for the software: http://www.webmproject.org/license/additional/ > > These grants are subtly different in the scope of what they cover. > > There are important licensing drafting reasons for a construction > which distinguishes "an implementation" and "any implementation". > In particular, the license drafter writing this kind of a royalty free > license has a tricky time making sure that the permission is broad > enough to include all the correct coverage, but not so over-broad that > a malicious implementer could (e.g.) add a search engine to their VP8 > encoder and claim that the VP8 license entitles them to search patents. > > So, the drafter says something like=97 "those patent claims [...] that > are necessarily infringed by implementation of this specification", > which achieves the desired limited scope=97 and that is _all_ you get > with the MPEG-LA pool patent licenses. This is what the Google bitstrea= m > spec license provides. > > But, if we're to be serious and honest about making a royalty free form= at > and implementation that permission isn't quite sufficient: The referenc= e > implementation might practice some VP8 related techniques which are not > "necessarily infringed"=97 they're helpful performance enhancements, > they could simply be one option out of many ways of doing the same thin= g, > or could just be something that was incidentally included (or even a > malicious patent trap snake in the grass)=97 and so it's important that > everything in the reference software also be licensed=97 even if its no= t > "necessarily infringed" by the specification. But since it's not a > goal to also license unrelated things that a downstream user may cram i= n > (e.g. a search engine), that license must be limited in scope to things > which are actually in the reference implementation: "This grant does no= t > include claims that would be infringed only as a consequence of further > modification of this implementation." (this language is actually almost > identical to the language for this purpose in the GPL, FWIW) > > So, in summary: > > You are licensed, via the bitstream license, for anything Google contro= ls > which is necessary to implement the specification=97 in hardware, > software, home grown, or reference implementations. This is pretty > much as strong a grant as you can find anyone offering for any other > format specification. > > You are also licensed, via the additional rights license, for any > use of the VP8 reference implementation including modified versions, > limited to the extent that the modifications don't expand the scope of > the coverage. (Exactly as the GPL explicit patent grant does) > > This has already been clarified by Google on this list: > "Google confirms that the VP8 patent grant applies to both > third-party hardware and software implementations of VP8." > http://www.ietf.org/mail-archive/web/rtcweb/current/msg04006.html > > I admit that the fact that there are two similar but distinct licenses > is a little confusing, but I don't understand why we have to go over > it again and again on this list. I would think that the prior Google > comment would have been sufficiently definitive. Well, I apologize, somehow I missed that while catching up on this list.=20 Your explanation certainly covers my concerns; the patent grant allows=20 us to distribute modified versions, as long as they don't infringe on=20 any patents that aren't necessarily infringed by the reference=20 implementation. Thanks for the clue-bat :-) --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ibc@aliax.net Sun Apr 22 10:12: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 376E621F860E for ; Sun, 22 Apr 2012 10:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, 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 u-WL7PzDf2Km for ; Sun, 22 Apr 2012 10:12:37 -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 B2D2921F8609 for ; Sun, 22 Apr 2012 10:12:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so8833762vbb.31 for ; Sun, 22 Apr 2012 10:12:36 -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=jbU/ucXSkBV5rpHH0rw2krWGyr+cQdEmTjFSktBVs2U=; b=ny8K/SzphkpUQ72J+pKK14lOnGtDtrXnLHHYrILgPfO5Ud1JyRmrcU6iXlQnIF0XHO +ehVN0N6ZyZPZOyFUcHzoFwIUYFR0PhMRfW934W1PBsPprrw+y9PHEvKfT2jn8qdEhdJ SNeLuv7Pq3+6/RQXCJ6W0M6MZW4rn7EiJlMcBUXqJknp0WUfOPwejCCj07LqyV85ISyF WJN8G+f6tShR5v4X/9FBg2EL6aduyaCyjjGSej48+xix4Uxk7gV8p4iab/Th7oqspqKf 4CShyu7q3i0IdV2JH5Hu0jgh2BU6ZsgO+6LmRaOGt7ILqmyteZlWwWi0tpW4thlIdsNK 1kzg== Received: by 10.220.241.12 with SMTP id lc12mr12556674vcb.22.1335114756223; Sun, 22 Apr 2012 10:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Sun, 22 Apr 2012 10:12:16 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 22 Apr 2012 19:12:16 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmQNRhyXLD1w1vvtOpli1aZMGIqwZ6AZIL4I+dSZN3afttxGWLgVpjn/mCbzGwZGUT9feS0 Subject: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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: Sun, 22 Apr 2012 17:12:40 -0000 Hi, a stream in an SDP cannot be removed but just "disabled" (by setting its port to 0). In the same media session a participant could add a video stream and "disable" it later multiple times. Let's assume a media session initiated with just an audio stream: 1) A participant adds a video stream and the remote accepts it. This involves a new media section in the SDP. 2) Later the same participant removes the video stream which means setting its port to 0 in the SDP. 3) Later he adds video again. 4) ...and so on. AFAIK there are two choices for step 2 and 3: a) Releasing video resources and the UDP socket so when video is enabled again a new line should be added to the SDP and new resources (ICE, UDP socket) required. b) Not releasing all the resources (keep the UDP socket but stop sending/receiving data on it), and re-enabling it when video is added again, so the same SDP line would be reused by setting its port to the previous value. Choice a) means more and more lines in the SDP for each video activation. Option b) means not releasing resources after disabling a media stream. If I'm not wrong in the above text, which would be the WebRTC approach for this topic? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Sun Apr 22 23:41: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 65D1821F84EC for ; Sun, 22 Apr 2012 23:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 hKDCF6S+Vt7i for ; Sun, 22 Apr 2012 23:41:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4138021F84EB for ; Sun, 22 Apr 2012 23:41:44 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-91-4f94f9a69cb3 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A1.2F.26681.7A9F49F4; Mon, 23 Apr 2012 08:41:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 23 Apr 2012 08:41:43 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Date: Mon, 23 Apr 2012 08:40:30 +0200 Thread-Topic: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines in SDP) Thread-Index: Ac0gqyJr2FeG35kHRfuFBPGQFWvMtQAcNdJg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 06:41:45 -0000 Hi, I see no reason why you couldn't release resources when you disable media (= read: set port to zero), but still re-use the associated m- line later. Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of I=F1ak= i Baz Castillo [ibc@aliax.net] Sent: Sunday, April 22, 2012 8:12 PM To: rtcweb@ietf.org Subject: [rtcweb] Add, remove, add, remove, add, remove a media stre= am (lines in SDP) Hi, a stream in an SDP cannot be removed but just "disabled" (by setting its port to 0). In the same media session a participant could add a video stream and "disable" it later multiple times. Let's assume a media session initiated with just an audio stream: 1) A participant adds a video stream and the remote accepts it. This involves a new media section in the SDP. 2) Later the same participant removes the video stream which means setting its port to 0 in the SDP. 3) Later he adds video again. 4) ...and so on. AFAIK there are two choices for step 2 and 3: a) Releasing video resources and the UDP socket so when video is enabled again a new line should be added to the SDP and new resources (ICE, UDP socket) required. b) Not releasing all the resources (keep the UDP socket but stop sending/receiving data on it), and re-enabling it when video is added again, so the same SDP line would be reused by setting its port to the previous value. Choice a) means more and more lines in the SDP for each video activation. Option b) means not releasing resources after disabling a media stream. If I'm not wrong in the above text, which would be the WebRTC approach for this topic? Thanks a lot. -- I=F1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From ibc@aliax.net Mon Apr 23 00:29: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 AF5CD21F8587 for ; Mon, 23 Apr 2012 00:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, 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 aBSZyAeotVV2 for ; Mon, 23 Apr 2012 00:29:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABFD121F857D for ; Mon, 23 Apr 2012 00:29:50 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4662902vcb.31 for ; Mon, 23 Apr 2012 00:29:49 -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=efDGjA2CTQ9DIaqq91naBS8/UJM8xvoAlgu0scghe9M=; b=nnCE8zWB214vURgkzDSbHOhosELmoeyzM9/w2jsxP8lOFP6dlTSw2LAC/4vfcJqilr AYTLE6p+JOVfhmCQafwW+QBzigj1E/FsiYcp3vT+RHgCZV7zUT7r1jk9CVim+k0CVtTg L0npcPk3LkoS/ECnRPuwfzDWQQqktKmXMZ0Bri6ZGUX3pKFGKr75qQbMVAWgyP04tbBK l2sUr5nGgmMs8ACFNMrJZNoSN4sG5vv5Y/AsimJBSj5p3pSGy7DZYT7CS8N/GQnnnOBZ 9e2AvadAX/u91o4zaYY8kMFemGDkbVfcFThnyVwjBBtuh+KmH6XxLCF3ZklPpWwLCNfT cFpQ== Received: by 10.220.49.66 with SMTP id u2mr4996076vcf.2.1335166189872; Mon, 23 Apr 2012 00:29:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 23 Apr 2012 00:29:29 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Apr 2012 09:29:29 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnL4LwNpTwnF//0xZ6QorCSzFJJCES4MnCAQSCsByhvYSph6vhW0WGUoBKSx2SQd+KiG2rW Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 07:29:51 -0000 2012/4/23 Christer Holmberg : > Hi, > > I see no reason why you couldn't release resources when you disable media= (read: set port to zero), but still re-use the associated m- line later. Maybe the previosly used UDP port is not available later. Probably there are no more reasons :) --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Mon Apr 23 00:41: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 F124121F854D for ; Mon, 23 Apr 2012 00:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, 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 AdrDBa3lZk1S for ; Mon, 23 Apr 2012 00:41:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0721F8547 for ; Mon, 23 Apr 2012 00:41:30 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id F0C70B01B4; Mon, 23 Apr 2012 09:41:28 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 9CD68B019C; Mon, 23 Apr 2012 09:41:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Mon, 23 Apr 2012 09:41:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D37D3F0-9A1C-4116-9A19-47E5A8929F71@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 07:41:32 -0000 Hi, On Apr 23, 2012, at 9:29 AM, I=F1aki Baz Castillo wrote: > 2012/4/23 Christer Holmberg : >> Hi, >>=20 >> I see no reason why you couldn't release resources when you disable = media (read: set port to zero), but still re-use the associated m- line = later. >=20 > Maybe the previosly used UDP port is not available later. Probably > there are no more reasons :) >=20 But when you disabled the stream you did set the port to zero, so when = you resurrect the stream you'd allocate a new port. Were you thinking = about setting the stream as inactive (a=3Dinactive in SDP terms) = instead? -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Apr 23 01:03: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 0E32A21F85E3 for ; Mon, 23 Apr 2012 01:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=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 SQj+ZgKZJw2f for ; Mon, 23 Apr 2012 01:03:56 -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 A928421F851D for ; Mon, 23 Apr 2012 01:03:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so9211074vbb.31 for ; Mon, 23 Apr 2012 01:03:56 -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=xhF2IeVJM4HASV/jhoNlvw7jdFc3XPQvgLVzCFrIqyU=; b=D/ZbO9T2eOfs/Dpt1s4oZO/O3RurKtUpPHeLW+o6r2qE5pPVeVAQo3D9Y2FMxvIekU DLrqtrExe+DHByXkG+hkVv8EfOnI/3xeovPrxxYrDiXceUMgowGT1Ih64OIbMaUaaBKv 61pzlIdy3+VAbao20+Gf0EcME43GkKtK14VGNBXD4b7hmgD0uyGGFziQ0ZYUN0gRqWUk w87wH+iPBl6fFuRoGSPJWU9dBkCmj7MGQ0QLX95s4jyec1b/ETAnXE7BorxMuH1lHv+u YRXZa6UpsoGKTDPA5QDeJa4cuLV8HyCCkh2LKAJkHIDdcCmIlRwOjm4DS5k/z9SAeUZ0 vIFg== Received: by 10.52.64.173 with SMTP id p13mr10570165vds.51.1335168236108; Mon, 23 Apr 2012 01:03:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 23 Apr 2012 01:03:34 -0700 (PDT) In-Reply-To: <5D37D3F0-9A1C-4116-9A19-47E5A8929F71@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> <5D37D3F0-9A1C-4116-9A19-47E5A8929F71@ag-projects.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Apr 2012 10:03:34 +0200 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmLou4R7Jyw0s7GxQWn5wsqa8ltkVXDdC4Z0ecqPNFENGKSi22tki0k8ODXXfveSGM/HVui Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 08:03:58 -0000 2012/4/23 Sa=C3=BAl Ibarra Corretg=C3=A9 : > On Apr 23, 2012, at 9:29 AM, I=C3=B1aki Baz Castillo wrote: >> Maybe the previosly used UDP port is not available later. Probably >> there are no more reasons :) >> > > But when you disabled the stream you did set the port to zero, so when yo= u resurrect the stream you'd allocate a new port. The stack could try to allocate the same port as default bahavior. > Were you thinking about setting the stream as inactive (a=3Dinactive in S= DP terms) instead? But setting a=3Dinactive just pauses the stream in a single direction (according to RFC 4566). You could be interested in stopping sending and receiving video. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Mon Apr 23 01:12: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 12F8821F85DF for ; Mon, 23 Apr 2012 01:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, 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 dz507ECUAXcN for ; Mon, 23 Apr 2012 01:12:17 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E07F021F84E4 for ; Mon, 23 Apr 2012 01:12:14 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 1D04AB01A2; Mon, 23 Apr 2012 10:12:14 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 4F084B019C; Mon, 23 Apr 2012 10:12:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Mon, 23 Apr 2012 10:12:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> <5D37D3F0-9A1C-4116-9A19-47E5A8929F71@ag-projects.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 08:12:21 -0000 On Apr 23, 2012, at 10:03 AM, I=F1aki Baz Castillo wrote: > 2012/4/23 Sa=FAl Ibarra Corretg=E9 : >> On Apr 23, 2012, at 9:29 AM, I=F1aki Baz Castillo wrote: >>> Maybe the previosly used UDP port is not available later. Probably >>> there are no more reasons :) >>>=20 >>=20 >> But when you disabled the stream you did set the port to zero, so = when you resurrect the stream you'd allocate a new port. >=20 > The stack could try to allocate the same port as default bahavior. >=20 Well, then the stack needs to be fixed :-) The stack should 'forget' the = port as soon as it sets it as zero in the stream, and allocate a new = one, the same way it would do for a brand new stream. >=20 >=20 >> Were you thinking about setting the stream as inactive (a=3Dinactive = in SDP terms) instead? >=20 > But setting a=3Dinactive just pauses the stream in a single direction > (according to RFC 4566). You could be interested in stopping sending > and receiving video. >=20 IIRC inactive pauses the stream in both directions. For pausing it in a = single direction you can use sendonly / recvonly. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Apr 23 01:24: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 4B9D721F860F for ; Mon, 23 Apr 2012 01:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=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 sw+pKXH6hLEB for ; Mon, 23 Apr 2012 01:24:30 -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 8116D21F85BD for ; Mon, 23 Apr 2012 01:24:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so9223444vbb.31 for ; Mon, 23 Apr 2012 01:24:30 -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=I6aQM2ofYVVQ7pZH6LeMLi7tUTlSzdlVoIwb+6lcTf8=; b=oLAwrSjmjt3kufl4X7kS7f6u2uBiQhVRee7qCW06HPAep3L4Xyn60mR6SeylZw71Xb /mVAeCABYLhVpVBNmTWAgK7I9Vkj9UlKhlU/iLK6iZfbWgcpFtyFV10ROagk4493s/1l qMJoRgqFY55CJcYypRHx8vNsYk5hnpGWWttjQfg6nICzVKiqe2XzzvOBOKvuSBGlGqQ5 NWRVxjBgT5tEURTHfqSIOgDeSBs+fNJcyveu/0Y9ykBhyK/Jf3ScH7RW/9pD9mW9USdU zvi/PF7x+hYpNilMZJ497kwZ1+sKexo9su8wsPjqz/VS8ZluIjCEkStejv8osaGPqMwK xEGw== Received: by 10.52.91.72 with SMTP id cc8mr13358567vdb.17.1335169470054; Mon, 23 Apr 2012 01:24:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 23 Apr 2012 01:24:09 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> <5D37D3F0-9A1C-4116-9A19-47E5A8929F71@ag-projects.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Apr 2012 10:24:09 +0200 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnF3vzjY+JYzwTgrYvngFw4jxmne7NFXF+vTaYFP4IClDo36CswxhAG3EMQwBK5+pJ7nV9I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 08:24:33 -0000 2012/4/23 Sa=C3=BAl Ibarra Corretg=C3=A9 : >>> But when you disabled the stream you did set the port to zero, so when = you resurrect the stream you'd allocate a new port. >> >> The stack could try to allocate the same port as default behavior. >> > > Well, then the stack needs to be fixed :-) The stack should 'forget' the = port as soon as it sets it as zero in the stream, and allocate a new one, t= he same way it would do for a brand new stream. The WebRTCP stack is being designed right now :) >>> Were you thinking about setting the stream as inactive (a=3Dinactive in= SDP terms) instead? >> >> But setting a=3Dinactive just pauses the stream in a single direction >> (according to RFC 4566). You could be interested in stopping sending >> and receiving video. >> > > IIRC inactive pauses the stream in both directions. For pausing it in a s= ingle direction you can use sendonly / recvonly. You are totally right, my fault. Anyhow setting a=3Dinactive means that resources are not freed (for example, RTCP must be still sent). Not sure if this is good or bad. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Mon Apr 23 01:26: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 6102E21F862B for ; Mon, 23 Apr 2012 01:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 zoJG+wswbwOX for ; Mon, 23 Apr 2012 01:26:52 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61721F8628 for ; Mon, 23 Apr 2012 01:26:51 -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 1SMEbh-00062l-TS for rtcweb@ietf.org; Mon, 23 Apr 2012 03:26:50 -0500 Message-ID: <4F951221.1050700@jesup.org> Date: Mon, 23 Apr 2012 04:26:09 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 08:26:55 -0000 On 4/23/2012 2:40 AM, Christer Holmberg wrote: > Hi, > > I see no reason why you couldn't release resources when you disable media (read: > set port to zero), but still re-use the associated m- line later. Exactly - m-lines can't be removed, but they can be re-used - and the critical point is that the port doesn't have to match the previous port. So generally they should be no worse than a high-water-mark of the number of audio and video streams in use at any one time. Of course with bundle the port issue is simpler. > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Iñaki Baz Castillo [ibc@aliax.net] > > Hi, a stream in an SDP cannot be removed but just "disabled" (by > setting its port to 0). In the same media session a participant could > add a video stream and "disable" it later multiple times. > > Let's assume a media session initiated with just an audio stream: > > 1) A participant adds a video stream and the remote accepts it. This > involves a new media section in the SDP. > 2) Later the same participant removes the video stream which means > setting its port to 0 in the SDP. > 3) Later he adds video again. > 4) ...and so on. > > AFAIK there are two choices for step 2 and 3: > > a) Releasing video resources and the UDP socket so when video is > enabled again a new line should be added to the SDP and new resources > (ICE, UDP socket) required. > > b) Not releasing all the resources (keep the UDP socket but stop > sending/receiving data on it), and re-enabling it when video is added > again, so the same SDP line would be reused by setting its port to the > previous value. > > > Choice a) means more and more lines in the SDP for each video > activation. Option b) means not releasing resources after disabling a > media stream. > > If I'm not wrong in the above text, which would be the WebRTC approach > for this topic? -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Mon Apr 23 01:33: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 72A7C21F8642 for ; Mon, 23 Apr 2012 01:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, 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 EwJIWIKc3Wvy for ; Mon, 23 Apr 2012 01:33:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E80721F863E for ; Mon, 23 Apr 2012 01:33:04 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4700232vcb.31 for ; Mon, 23 Apr 2012 01:33:04 -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=qdzrvIKpKHv18su70j6bByYGvLvuXBLphnZaxqH/gTY=; b=ONIFEfEH8ut/t1JKCwayc0TC6zJiH/tpd8cMOzvend/iS7MIw0ERnsdh+R7oYcGw5+ 0N4e4DfzkdQWoTz9tXX7DW4j9ttl/B6vUZK4qO5SINKRkbX/sqe3dyWqD+K+otk8RoDC yfHRof5YLhRHQLnmrIgEpaaYO4sOsl26+u7A8Tyu9b1hNiDb2l7qX5kjz0w/jNSx71C8 15m1VFACdK+gyfjEGCqsfbkXalTlJ8sJkXiB49rsww4mDzTtoELhZlZGJfZ5ef6R0gtY qfE7iAdcExcE7lJO61F/DgAtkfDc2nryAZxVpqXjMwsQ+2fEnxlic6gdDYD3YWp7ln6w AVtA== Received: by 10.52.64.173 with SMTP id p13mr10628009vds.51.1335169983777; Mon, 23 Apr 2012 01:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 23 Apr 2012 01:32:43 -0700 (PDT) In-Reply-To: <4F951221.1050700@jesup.org> References: <7F2072F1E0DE894DA4B517B93C6A05852C4400131A@ESESSCMS0356.eemea.ericsson.se> <4F951221.1050700@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Apr 2012 10:32:43 +0200 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk2Hug31wJl2pCC9vBAsxI3zukjbNq4nH7dNUHWsmM+9p4252A0SFXw4jW7GvkrxWvfPyV/ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Add, remove, add, remove, add, remove a media stream (lines 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 Apr 2012 08:33:07 -0000 2012/4/23 Randell Jesup : > Exactly - m-lines can't be removed, but they can be re-used - > and the critical point is that the port doesn't have to match the previou= s port. Definitely I need a coffee. No idea why I assumed that the same port should be re-used. So things become easier: - Reuse the same m-line. - Set port to zero when disabling the stream and free resources. - Allocate a new port when re-enabling it and write the new port in the m-l= ine. Sorry, I was creating a non existing issue. --=20 I=C3=B1aki Baz Castillo From juberti@google.com Mon Apr 23 20:02: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 6CEBC11E809B for ; Mon, 23 Apr 2012 20:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=1.252, 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 s0Y5Uj-3f3Yx for ; Mon, 23 Apr 2012 20:02:32 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6E9E11E8073 for ; Mon, 23 Apr 2012 20:02:32 -0700 (PDT) Received: by qcsq13 with SMTP id q13so130836qcs.31 for ; Mon, 23 Apr 2012 20:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=6HM6/+2T665QbG8JrBUgBPjDD3N44qPN2L0YF4iudsM=; b=AKPguMFRfCV+qhG7J1665e8uLuXuaqA5ehotuPX+9g/NHWjpjzFMuhjPv59Unyf2B4 UgRHBaH0UvihsGTqOSbdUn8jPb+Sanr01fBm/izNCtsDKNL1kwQgBTGVbLhdLnYjWSrP VV3iw5rs7qYGSOO2+Gv0dr7KcuI80ViS72DUl9tJulTLQ5XrGXbyTRS96+vTydpCAaE4 pqxX2a2Hn16tSO85eBVmucKD7lLuI074jcufyns7uh+6q3x5YS87d7gXRjTErvMPwbRr 0IX8NYWnTqw8TMupejZeUjtPRrhYxjBDTE86wYoFEdwNoW6OiUtT22DAsuACuxM9q1by bxbw== 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=6HM6/+2T665QbG8JrBUgBPjDD3N44qPN2L0YF4iudsM=; b=TBkxX+OP6SISh5PH+xqhMrCEG2iuioZXtBGRqoM7pV+6A+QrdjqExwQZbnRZWRv81y 6NT+bWuosrj+/tjCqWMU4xhRkyPA3nqO3jZc/FTHFmirdnBjiyyrBex/blDo4FvBVxGF 0TloDtp4WyusNylOeO4Df2hGry32KoE7OksHhumgjHyJ2SgvDQ6pQKW2rqfdB9Cn7VWm hrXb4tHNFzZnQ8t5UFQ+1drP0BUCNFPBe9OC4v+sx6yW0VpzVmn5Bh7YNVTa3pN17Uz7 pzfAnRDoeSYwPT+moqJRWeDaarW02C06KLgnM6YnC8Xku7H2qnfBOz0nf3Mc5DO/MMoT cAbA== Received: by 10.224.187.2 with SMTP id cu2mr860298qab.88.1335236552140; Mon, 23 Apr 2012 20:02:32 -0700 (PDT) Received: by 10.224.187.2 with SMTP id cu2mr860295qab.88.1335236552057; Mon, 23 Apr 2012 20:02:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Mon, 23 Apr 2012 20:02:11 -0700 (PDT) In-Reply-To: <059AF07365DC474393A19A3AF187DF74086657DB@NAHALD.us.int.genesyslab.com> References: <059AF07365DC474393A19A3AF187DF74086657DB@NAHALD.us.int.genesyslab.com> From: Justin Uberti Date: Mon, 23 Apr 2012 23:02:11 -0400 Message-ID: To: Henry Lum Content-Type: multipart/alternative; boundary=485b397dd77560654904be63fcd1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlLQXtQtTqhHgIRRnvZzs1c1xAWmAHlYoXQjXqVNd+ET6dOfaLvpqL01ut/TPr4f0M6jhBMK+XaoDKOV1LOechXEJ+LrTVn5LlaOk8o88bZcIGd/x57p3XibM6z355nQSSao32/ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The meaning of SDP_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: Tue, 24 Apr 2012 03:02:33 -0000 --485b397dd77560654904be63fcd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's needed to indicate to the offerer that the answer is not final; any resources associated with the offer should not yet be released. One example where this may be useful is when using RTCP mux; the initial answer may indicate that mux is to be used, but the final answer may come from a different endpoint and choose not to use mux. Using SDP_PRANSWER allows the offerer to honor the second answer, since the RTCP transport is not discarded by the first answer. On Mon, Apr 16, 2012 at 11:52 AM, Henry Lum wrote= : > It=E2=80=99s unclear to me what the purpose of SDP_PRANSWER is really fo= r and > why it needs to be there. Originally I thought it was meant for early > media, but section 6.1.4 paragraph 3 says that it should not result in > starting of media transmission. Is there a reason to provide an answer > before media is ready to be transmitted? There are separate handles for > processing ICE candidates so I don=E2=80=99t see a need to have provision= al > answers. **** > > ** ** > > I am not proposing PRANSWER for handling early media though, since I > believe early media is more of an application level issue (it=E2=80=99s m= ore like > late-billing on the application side) and should be considered as a > separate offer/answer if needed.**** > > ** ** > > Regards,**** > > Henry **** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --485b397dd77560654904be63fcd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's needed to indicate to the offerer that = the answer is not final; any resources associated with the offer should not= yet be released.

One example where this may be useful is when using RTCP mux; the initial an= swer may indicate that mux is to be used, but the final answer may come fro= m a different endpoint and choose not to use mux. Using SDP_PRANSWER allows= the offerer to honor the second answer, since the RTCP transport is not di= scarded by the first answer.

On Mon, Apr 16, 2012 at 11:52 AM, Henry Lum = <Henry.Lum@genesyslab.com> wrote:

It=E2=80=99s unclear to me what the purpose of SDP_P= RANSWER is really for and why it needs to be there. Originally I thought it was meant = for early media, but section 6.1.4 paragraph 3 says that it should not result in star= ting of media transmission. Is there a reason to provide an answer before media = is ready to be transmitted? There are separate handles for processing ICE cand= idates so I don=E2=80=99t see a need to have provisional answers.

=C2=A0

I am not proposing PRANSWER for handling early media= though, since I believe early media is more of an application level issue (it=E2=80= =99s more like late-billing on the application side) and should be considered as= a separate offer/answer if needed.

=C2=A0

Regards,

Henry


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


--485b397dd77560654904be63fcd1-- From magnus.westerlund@ericsson.com Tue Apr 24 00:19: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 0DBA221F8599 for ; Tue, 24 Apr 2012 00:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.109, 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 Ib+nBqXS7kRB for ; Tue, 24 Apr 2012 00:19:41 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3054321F8597 for ; Tue, 24 Apr 2012 00:19:41 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-f3-4f96540caf25 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 23.52.03534.C04569F4; Tue, 24 Apr 2012 09:19:40 +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.213.0; Tue, 24 Apr 2012 09:19:39 +0200 Message-ID: <4F9653FD.4040008@ericsson.com> Date: Tue, 24 Apr 2012 09:19:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mary Barnes References: <4F8FD90B.5040409@ericsson.com> <4F9108AB.9020002@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of F2F Interim meeting 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 Apr 2012 07:19:42 -0000 On 2012-04-20 16:42, Mary Barnes wrote: > I had not intention to drive, I used the train symbol option on Google > maps. That's why my question as to perhaps Google maps calculations are > off for that route. That calculation included walking time from what > Google maps has as city centers to the train stations, but that's > probably a reasonable buffer given the figures you note, which don't > include the wait times for trains. Yes, I would expect that door to door it does take approximately 30 minutes. Yes, if you during rush hour just go down to the station you will have to wait some few minutes on the next train. The train interval is either 7,8 or 10 minutes around the times when the meeting is planned to start and stop. Staying downtown (if we have the meeting in Kista) makes it easier in the evenings returning from dinner. Staying in Kista saves you some time in the morning. But you most likely are having dinner downtown anyway so you get the same amount of subway riding to do. I do want to point out that the subway is safe and runs until 1.00 AM weekdays. If we will have the meeting downtown staying in Kista is just adding travel with no benefit. 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 magnus.westerlund@ericsson.com Tue Apr 24 07:25: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 C859821F8807 for ; Tue, 24 Apr 2012 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.126 X-Spam-Level: X-Spam-Status: No, score=-106.126 tagged_above=-999 required=5 tests=[AWL=0.123, 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 cm9eLcQvrxR6 for ; Tue, 24 Apr 2012 07:25:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3023521F85AE for ; Tue, 24 Apr 2012 07:25:30 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-3d-4f96b7d9dc5e Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 98.AA.03534.9D7B69F4; Tue, 24 Apr 2012 16:25:30 +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.213.0; Tue, 24 Apr 2012 16:25:28 +0200 Message-ID: <4F96B7C9.1030609@ericsson.com> Date: Tue, 24 Apr 2012 16:25:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: <4F869648.2020605@alvestrand.no> In-Reply-To: <4F869648.2020605@alvestrand.no> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) 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 Apr 2012 14:25:32 -0000 Harald, WG, This is posted as individual. When it comes to this topic I will not engage in any chair activities because I do have an alternative proposal based on https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/. My proposal has some significant differences in how it works compared to Harald's. I will start with a discussion of requirements, in addition to Harald's, then an overview of my proposal, and ending with a discussion of the differences between the proposals. This is quite long but I do hope you will read it to the end. Requirements ------------ Let's start with the requirements that Harald have written. I think they should be formulated differently. First of all I think the requirements are negotiated, indicated etc in the context of a peer connection. Secondly, when it comes to maximum resolution and maximum frame-rate, there are actually three different limits that I think are important; Highest spatial resolution, highest frame-rate, and maximum complexity for a given video stream. The maximum complexity is often expressed as the number of macroblocks a video codec can process per second. This is a well-established complexity measure, used as part of standardized video codec's "level" definitions since the introduction of H.263 Annex X in 2004. As this is basically a joint maximum requirement on the maximum amount of pixels per frame times the maximum frame-rate, there exist cases where this complexity figure actually is the constraining factor forcing a sender or receiver to either request higher frame rate and lower resolution or higher resolution and a lower frame rate. The requirements should also be clearer in that one needs to handle multiple SSRCs per RTP session, including multiple cameras or audio streams (microphones) from a single end-point, where each stream can be encoded using different parameter values. I also think it is important that we consider what additional encoding property parameters that would make sense for WebRTC to have a possibility to dynamically negotiate, request and indicate. Some additional use cases that should be considered in the requirements: 1) We have use cases including multi-party communication. One way to realize these is to use a central node and I believe everyone agrees that we should have good support for getting this usage to work well. Thus in a basic star topology of different participants there is going to be different path characteristics between the central node and each participant. 1A) This makes it necessary to consider how one can ensure that the central node can deliver appropriate rates. One way is to de-couple the links by having the central node perform individual transcodings to every participant. A simpler non-transcoding central node, only forwarding streams between end-points, would have to enforce the lowest path characteristics to all. If one don't want to transcode at the central node and not use the lowest path characteristics to all, one need to consider either simulcast or scalable video coding. Both simulcast and scalable video coding result in that at least in the direction from a participant to the central node one needs to use multiple codec operation points. Either one per peer connection, which is how I see simulcast being realized with today's API and functionality, or using an encoding format supporting scalable coding within a single peer connection. 1B) In cases where the central node has minimal functionality and basically is a relay and an ICE plus DTLS-SRTP termination point (I assume EKT to avoid having to do re-encryption), there is a need to be able to handle sources from different participants. This puts extra requirements on how to successfully negotiate the parameters. For example changing the values for one media source should not force one to renegotiate with everyone. 2) The non-centralized multiparty use case appears to equally or more stress the need for having timely dynamic control. If each sender has a number of peer-connections to its peers, it may use local audio levels to determine if its media stream is to be sent or not. Thus the amount of bit-rate and screen estate needed to display will rapidly change as different users speaks. Thus the need for minimal delay when changing preferences are important. 3) We also have speech and audio including audio-only use cases. For audio there could also exist desire to request or indicate changes in the audio bandwidth required, or usage of multi-channel. 4) Adaptation to legacy node from a central node in a multi-party conference. In some use cases legacy nodes might have special needs that are within the profiles a WebRTC end-point is capable of producing. Thus the central node might request the nodes to constrain themselves to particular payload types, audio bandwidth etc to meet a joining session participant. 5) There appear to exist a need for expressing dynamic requests for target bit-rate as one parameter. This can be supported by TMMBR (RFC5104) but there exist additional transport related parameters could help with the adaptation. These include MTU, limits on packet rate, and amount of aggregation of audio frames in the payload. Overview -------- The basic idea in this proposal is to use JSEP to establish the outer limits for behavior and then use Codec Operation Point (COP) proposal as detailed in draft-westerlund-avtext-codec-operation-point to handle dynamic changes during the session. So highest resolution, frame-rate and maximum complexity are expressed in JSEP SDP. Complexity is in several video codecs expressed by profile and level. I know that VP8 currently doesn't have this but it is under discussion when it comes to these parameters. During the session the browser implementation detects when there is need to use COP to do any of the following things. A) Request new target values for codec operation, for example due to that the GUI element displaying a video has changed due to window resize. B) Indicate when the end-point in its role as sender change parameters. In addition to just spatial resolution and video frame rate, I propose that the following parameters are considered as parameters that could be dynamically possible to indicate and request. Spatial resolution (as x and y resolution), Frame-rate, Picture Aspect ratio, Sample Aspect Ratio, Payload Type, Bit-rate, Token Bucket Size (To control burstiness of sender), Channels, Sampling Rate, Maximum RTP Packet Size, Maximum RTP Packet Rate, and Application Data Unit Aggregation (to control amount of audio frames in the same RTP packet). Differences ----------- A) Using COP and using SDP based signaling for the dynamic changes are two quite different models in relation to how the interaction happens. For COP this all happens in the browser, normally initiated by the browser's own determination that a COP request or notification is needed. Harald's proposal appears to require that the JS initiate a renegotiation. This puts a requirement on the implementation to listen to the correct callbacks to know when changes happens, such as window resize. To my knowledge there are not yet any proposals for how the browser can initiate a JSEP renegotiation. Thus COP has the advantage that there is no API changes to get browser triggered parameter changes. W3C can select too but are not required to add API methods to allow JS to make codec parameter requests. The next thing is that COP does not require the JS application to have code to detect and handle re-negotiation. This makes it simpler for the basic application to get good behavior and they are not interrupted nor do they need to handle JSEP & Offer/Answer state machine lock-out effects due to dynamic changes. How big impact these API issues have are unclear as W3C currently appear not to have included any discussion of how the browser can initiate a offer/answer exchange towards the JS when it determines a need to change parameters. But I am worried that using SDP and with an API that requires the application to listen for triggers that could benefit from a codec parameter renegotiation. This will likely only result in good behavior for the JS application implementors that are really good and find out what listeners and what signaling tricks are needed with JSEP to get good performance. I would much rather prefer good behavior by default in simple applications, i.e. using the default behavior that the browser implementor have put in. B) Using the media plane, i.e. RTCP for this signaling lets it in most case go directly between the encoding and the decoding entity in the code. There is no need to involve the JS nor the signaling server. One issue of using JSEP and SDP is that the state machine lock-out effects that can occur if one has sent an Offer. Then that browser may not be able to send a new updated Offer reflecting the latest change until the answer has been properly processed. COP doesn't have these limitations. It can send a new parameter request immediately, only limited by RTCP bandwidth restrictions. Using the media plane in my view guarantees that COP is never worse than what the signaling plane can perform at its best. C) As the general restrictions are determined in the initial negotiation, COP doesn't have the issue that in-flight media streams can become out of bounds. Thus no need for a two phase change of signaling parameters. D) Relying on draft-lennox-mmusic-sdp-source-selection-04 has several additional implications that should be discussed separately. The draft currently includes the following functionalities. D1) It contains a media stream pause proposal. This makes it subject to the architectural debate currently ongoing in dispatch around draft-westerlund-avtext-rtp-stream-pause-00 which is a competing proposal for the same functionality. D2) The inclusion of max desired frame rate in a SSRC specific way D3) Extending the image attribute to be per SSRC specific expression of desired resolutions. D4) Expressing relative priority in receiving different SSRCs. D5) Providing an "information" on a sent SSRC D6) Indication if the media sender is actively sending media using the given SSRC. Is it a correct observation that only D2 and D3 are required for the functionality of Resolution negotiation? E) The standardization situation is similar for both proposals. They are both relying on Internet drafts that are currently individual submissions. Both are partially caught in the architectural discussion which was held in Paris in the DISPATCH WG around Media pause/resume (draft-westerlund-avtext-rtp-stream-pause-00) and Media Stream Selection (draft-westerlund-dispatch-stream-selection-00) on what the most appropriate level of discussion are. This discussion will continue on the RAI-Area mailing list. F) As seen by the discussion on the mailing list the imageattr definitions may not be a 100% match to what is desired with Harald's proposal. I believe that COP's are more appropriate especially the "target" values possibility. In addition these are still open for adjustment and if they don't match WebRTC's requirements. I would also like to point out that I believe this functionality is also highly desirable for CLUE and that their requirements should be taken into account. I do think that this is one of the aspects where having matching functionality will make it much easier to have WebRTC to CLUE interworking. Thanks for reading all the way here! 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 harald@alvestrand.no Tue Apr 24 09:43: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 AD92821F8709 for ; Tue, 24 Apr 2012 09:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 kGwkL0JCf3Hd for ; Tue, 24 Apr 2012 09:43:47 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EE39C21F8702 for ; Tue, 24 Apr 2012 09:43:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C525B39E0CD; Tue, 24 Apr 2012 18:43:45 +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 PqdWbrt4WxhO; Tue, 24 Apr 2012 18:43:44 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3F4AE39E089; Tue, 24 Apr 2012 18:43:44 +0200 (CEST) Message-ID: <4F96D83F.8020705@alvestrand.no> Date: Tue, 24 Apr 2012 18:43:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Magnus Westerlund References: <4F869648.2020605@alvestrand.no> <4F96B7C9.1030609@ericsson.com> In-Reply-To: <4F96B7C9.1030609@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) 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 Apr 2012 16:43:48 -0000 I'm happy to see this - there are a number of quibbles I want to make, but overall, I like it. My big worry is the IPR issue - I think that negotiation of video size during a call is likely to be "MUST implement", and I don't want to require implementation of a protocol where people have filed non-RF IPR claims against it if there are viable alternatives. Harald On 04/24/2012 04:25 PM, Magnus Westerlund wrote: > Harald, WG, > > This is posted as individual. When it comes to this topic I will not > engage in any chair activities because I do have an alternative proposal > based on > https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/. > > > My proposal has some significant differences in how it works compared to > Harald's. I will start with a discussion of requirements, in addition to > Harald's, then an overview of my proposal, and ending with a discussion > of the differences between the proposals. This is quite long but I do > hope you will read it to the end. > > Requirements > ------------ > > Let's start with the requirements that Harald have written. I think they > should be formulated differently. First of all I think the requirements > are negotiated, indicated etc in the context of a peer connection. > > Secondly, when it comes to maximum resolution and maximum frame-rate, > there are actually three different limits that I think are important; > Highest spatial resolution, highest frame-rate, and maximum complexity > for a given video stream. The maximum complexity is often expressed as > the number of macroblocks a video codec can process per second. This is > a well-established complexity measure, used as part of standardized > video codec's "level" definitions since the introduction of H.263 Annex > X in 2004. As this is basically a joint maximum requirement on the > maximum amount of pixels per frame times the maximum frame-rate, there > exist cases where this complexity figure actually is the constraining > factor forcing a sender or receiver to either request higher frame rate > and lower resolution or higher resolution and a lower frame rate. > > The requirements should also be clearer in that one needs to handle > multiple SSRCs per RTP session, including multiple cameras or audio > streams (microphones) from a single end-point, where each stream can be > encoded using different parameter values. > > I also think it is important that we consider what additional encoding > property parameters that would make sense for WebRTC to have a > possibility to dynamically negotiate, request and indicate. > > Some additional use cases that should be considered in the requirements: > > 1) We have use cases including multi-party communication. One way to > realize these is to use a central node and I believe everyone agrees > that we should have good support for getting this usage to work well. > Thus in a basic star topology of different participants there is going > to be different path characteristics between the central node and each > participant. > > 1A) This makes it necessary to consider how one can ensure that the > central node can deliver appropriate rates. One way is to de-couple the > links by having the central node perform individual transcodings to > every participant. A simpler non-transcoding central node, only > forwarding streams between end-points, would have to enforce the lowest > path characteristics to all. If one don't want to transcode at the > central node and not use the lowest path characteristics to all, one > need to consider either simulcast or scalable video coding. Both > simulcast and scalable video coding result in that at least in the > direction from a participant to the central node one needs to use > multiple codec operation points. Either one per peer connection, which > is how I see simulcast being realized with today's API and > functionality, or using an encoding format supporting scalable coding > within a single peer connection. > > 1B) In cases where the central node has minimal functionality and > basically is a relay and an ICE plus DTLS-SRTP termination point (I > assume EKT to avoid having to do re-encryption), there is a need to be > able to handle sources from different participants. This puts extra > requirements on how to successfully negotiate the parameters. For > example changing the values for one media source should not force one to > renegotiate with everyone. > > 2) The non-centralized multiparty use case appears to equally or more > stress the need for having timely dynamic control. If each sender has a > number of peer-connections to its peers, it may use local audio levels > to determine if its media stream is to be sent or not. Thus the amount > of bit-rate and screen estate needed to display will rapidly change as > different users speaks. Thus the need for minimal delay when changing > preferences are important. > > 3) We also have speech and audio including audio-only use cases. For > audio there could also exist desire to request or indicate changes in > the audio bandwidth required, or usage of multi-channel. > > 4) Adaptation to legacy node from a central node in a multi-party > conference. In some use cases legacy nodes might have special needs that > are within the profiles a WebRTC end-point is capable of producing. Thus > the central node might request the nodes to constrain themselves to > particular payload types, audio bandwidth etc to meet a joining session > participant. > > 5) There appear to exist a need for expressing dynamic requests for > target bit-rate as one parameter. This can be supported by TMMBR > (RFC5104) but there exist additional transport related parameters could > help with the adaptation. These include MTU, limits on packet rate, and > amount of aggregation of audio frames in the payload. > > Overview > -------- > > The basic idea in this proposal is to use JSEP to establish the outer > limits for behavior and then use Codec Operation Point (COP) proposal as > detailed in draft-westerlund-avtext-codec-operation-point to handle > dynamic changes during the session. > > So highest resolution, frame-rate and maximum complexity are expressed > in JSEP SDP. Complexity is in several video codecs expressed by profile > and level. I know that VP8 currently doesn't have this but it is under > discussion when it comes to these parameters. > > During the session the browser implementation detects when there is need > to use COP to do any of the following things. > > A) Request new target values for codec operation, for example due to > that the GUI element displaying a video has changed due to window resize. > > B) Indicate when the end-point in its role as sender change parameters. > > In addition to just spatial resolution and video frame rate, I propose > that the following parameters are considered as parameters that could be > dynamically possible to indicate and request. > > Spatial resolution (as x and y resolution), Frame-rate, Picture Aspect > ratio, Sample Aspect Ratio, Payload Type, Bit-rate, Token Bucket Size > (To control burstiness of sender), Channels, Sampling Rate, Maximum RTP > Packet Size, Maximum RTP Packet Rate, and Application Data Unit > Aggregation (to control amount of audio frames in the same RTP packet). > > > Differences > ----------- > > A) Using COP and using SDP based signaling for the dynamic changes are > two quite different models in relation to how the interaction happens. > > For COP this all happens in the browser, normally initiated by the > browser's own determination that a COP request or notification is > needed. Harald's proposal appears to require that the JS initiate a > renegotiation. This puts a requirement on the implementation to listen > to the correct callbacks to know when changes happens, such as window > resize. To my knowledge there are not yet any proposals for how the > browser can initiate a JSEP renegotiation. > > Thus COP has the advantage that there is no API changes to get browser > triggered parameter changes. W3C can select too but are not required to > add API methods to allow JS to make codec parameter requests. > > The next thing is that COP does not require the JS application to have > code to detect and handle re-negotiation. This makes it simpler for the > basic application to get good behavior and they are not interrupted nor > do they need to handle JSEP& Offer/Answer state machine lock-out > effects due to dynamic changes. > > How big impact these API issues have are unclear as W3C currently appear > not to have included any discussion of how the browser can initiate a > offer/answer exchange towards the JS when it determines a need to change > parameters. > > But I am worried that using SDP and with an API that requires the > application to listen for triggers that could benefit from a codec > parameter renegotiation. This will likely only result in good behavior > for the JS application implementors that are really good and find out > what listeners and what signaling tricks are needed with JSEP to get > good performance. I would much rather prefer good behavior by default in > simple applications, i.e. using the default behavior that the browser > implementor have put in. > > B) Using the media plane, i.e. RTCP for this signaling lets it in most > case go directly between the encoding and the decoding entity in the > code. There is no need to involve the JS nor the signaling server. One > issue of using JSEP and SDP is that the state machine lock-out effects > that can occur if one has sent an Offer. Then that browser may not be > able to send a new updated Offer reflecting the latest change until the > answer has been properly processed. COP doesn't have these limitations. > It can send a new parameter request immediately, only limited by RTCP > bandwidth restrictions. Using the media plane in my view guarantees that > COP is never worse than what the signaling plane can perform at its best. > > C) As the general restrictions are determined in the initial > negotiation, COP doesn't have the issue that in-flight media streams can > become out of bounds. Thus no need for a two phase change of signaling > parameters. > > D) Relying on draft-lennox-mmusic-sdp-source-selection-04 has several > additional implications that should be discussed separately. The draft > currently includes the following functionalities. > > D1) It contains a media stream pause proposal. This makes it subject > to the architectural debate currently ongoing in dispatch around > draft-westerlund-avtext-rtp-stream-pause-00 which is a competing > proposal for the same functionality. > > D2) The inclusion of max desired frame rate in a SSRC specific way > > D3) Extending the image attribute to be per SSRC specific expression > of desired resolutions. > > D4) Expressing relative priority in receiving different SSRCs. > > D5) Providing an "information" on a sent SSRC > > D6) Indication if the media sender is actively sending media using the > given SSRC. > > Is it a correct observation that only D2 and D3 are required for the > functionality of Resolution negotiation? > > E) The standardization situation is similar for both proposals. They are > both relying on Internet drafts that are currently individual > submissions. Both are partially caught in the architectural discussion > which was held in Paris in the DISPATCH WG around Media pause/resume > (draft-westerlund-avtext-rtp-stream-pause-00) and Media Stream Selection > (draft-westerlund-dispatch-stream-selection-00) on what the most > appropriate level of discussion are. This discussion will continue on > the RAI-Area mailing list. > > F) As seen by the discussion on the mailing list the imageattr > definitions may not be a 100% match to what is desired with Harald's > proposal. I believe that COP's are more appropriate especially the > "target" values possibility. In addition these are still open for > adjustment and if they don't match WebRTC's requirements. > > I would also like to point out that I believe this functionality is also > highly desirable for CLUE and that their requirements should be taken > into account. I do think that this is one of the aspects where having > matching functionality will make it much easier to have WebRTC to CLUE > interworking. > > Thanks for reading all the way here! > > 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 tterriberry@mozilla.com Tue Apr 24 09:47: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 D824E21F8755 for ; Tue, 24 Apr 2012 09:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 Gww6omr9qByL for ; Tue, 24 Apr 2012 09:47:30 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id E3F6A21F8733 for ; Tue, 24 Apr 2012 09:47:30 -0700 (PDT) Received: from [10.250.5.141] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 8B37D4AED97 for ; Tue, 24 Apr 2012 09:47:30 -0700 (PDT) Message-ID: <4F96D922.2090205@mozilla.com> Date: Tue, 24 Apr 2012 09:47:30 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120305 SeaMonkey/2.7.1 MIME-Version: 1.0 CC: "rtcweb@ietf.org" References: <4F869648.2020605@alvestrand.no> <4F96B7C9.1030609@ericsson.com> <4F96D83F.8020705@alvestrand.no> In-Reply-To: <4F96D83F.8020705@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) 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 Apr 2012 16:47:32 -0000 Harald Alvestrand wrote: > My big worry is the IPR issue - I think that negotiation of video size > during a call is likely to be "MUST implement", and I don't want to > require implementation of a protocol where people have filed non-RF IPR > claims against it if there are viable alternatives. Particularly when those claims come from the author's employer. From bernard_aboba@hotmail.com Tue Apr 24 11: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 EBB8F21F87AE for ; Tue, 24 Apr 2012 11:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=1.206, 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 sByDRjbVQAL0 for ; Tue, 24 Apr 2012 11:13:47 -0700 (PDT) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9230221F87AB for ; Tue, 24 Apr 2012 11:13:47 -0700 (PDT) Received: from BLU169-W83 ([65.55.116.73]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 11:13:46 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_788a7258-0d1c-4de8-89f5-7844106da596_" X-Originating-IP: [131.107.192.22] From: Bernard Aboba To: Date: Tue, 24 Apr 2012 11:13:46 -0700 Importance: Normal In-Reply-To: <4F96D83F.8020705@alvestrand.no> References: <4F869648.2020605@alvestrand.no> <4F96B7C9.1030609@ericsson.com>,<4F96D83F.8020705@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2012 18:13:46.0967 (UTC) FILETIME=[FDCB7670:01CD2245] Subject: Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) 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 Apr 2012 18:13:50 -0000 --_788a7258-0d1c-4de8-89f5-7844106da596_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Magnus' proposal for only using SDP to set the limits of behavior makes sense to me. Clearly SDP is not potentially viable for rapid adjustment. The question is really about what information it is useful for a receiver or sender to provide. For example=2C I would question=20 whether an SVC sender necessarily needs to send a message saying=20 it is adjusting its sending rate=2C assuming that the new rate is within=20 the range negotiated. =20 In any case=2C this really is not an RTCWEB-specific problem=2C and comimg up with different solutions in different IETF WGs seems highly undesirable. > > This is posted as individual. When it comes to this topic I will not > > engage in any chair activities because I do have an alternative proposa= l > > based on > > https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operatio= n-point/. > > > > > > My proposal has some significant differences in how it works compared t= o > > Harald's. I will start with a discussion of requirements=2C in addition= to > > Harald's=2C then an overview of my proposal=2C and ending with a discus= sion > > of the differences between the proposals. This is quite long but I do > > hope you will read it to the end. > > > > Requirements > > ------------ > > > > Let's start with the requirements that Harald have written. I think the= y > > should be formulated differently. First of all I think the requirements > > are negotiated=2C indicated etc in the context of a peer connection. > > > > Secondly=2C when it comes to maximum resolution and maximum frame-rate= =2C > > there are actually three different limits that I think are important=3B > > Highest spatial resolution=2C highest frame-rate=2C and maximum complex= ity > > for a given video stream. The maximum complexity is often expressed as > > the number of macroblocks a video codec can process per second. This is > > a well-established complexity measure=2C used as part of standardized > > video codec's "level" definitions since the introduction of H.263 Annex > > X in 2004. As this is basically a joint maximum requirement on the > > maximum amount of pixels per frame times the maximum frame-rate=2C ther= e > > exist cases where this complexity figure actually is the constraining > > factor forcing a sender or receiver to either request higher frame rate > > and lower resolution or higher resolution and a lower frame rate. > > > > The requirements should also be clearer in that one needs to handle > > multiple SSRCs per RTP session=2C including multiple cameras or audio > > streams (microphones) from a single end-point=2C where each stream can = be > > encoded using different parameter values. > > > > I also think it is important that we consider what additional encoding > > property parameters that would make sense for WebRTC to have a > > possibility to dynamically negotiate=2C request and indicate. > > > > Some additional use cases that should be considered in the requirements= : > > > > 1) We have use cases including multi-party communication. One way to > > realize these is to use a central node and I believe everyone agrees > > that we should have good support for getting this usage to work well. > > Thus in a basic star topology of different participants there is going > > to be different path characteristics between the central node and each > > participant. > > > > 1A) This makes it necessary to consider how one can ensure that the > > central node can deliver appropriate rates. One way is to de-couple the > > links by having the central node perform individual transcodings to > > every participant. A simpler non-transcoding central node=2C only > > forwarding streams between end-points=2C would have to enforce the lowe= st > > path characteristics to all. If one don't want to transcode at the > > central node and not use the lowest path characteristics to all=2C one > > need to consider either simulcast or scalable video coding. Both > > simulcast and scalable video coding result in that at least in the > > direction from a participant to the central node one needs to use > > multiple codec operation points. Either one per peer connection=2C whic= h > > is how I see simulcast being realized with today's API and > > functionality=2C or using an encoding format supporting scalable coding > > within a single peer connection. > > > > 1B) In cases where the central node has minimal functionality and > > basically is a relay and an ICE plus DTLS-SRTP termination point (I > > assume EKT to avoid having to do re-encryption)=2C there is a need to b= e > > able to handle sources from different participants. This puts extra > > requirements on how to successfully negotiate the parameters. For > > example changing the values for one media source should not force one t= o > > renegotiate with everyone. > > > > 2) The non-centralized multiparty use case appears to equally or more > > stress the need for having timely dynamic control. If each sender has a > > number of peer-connections to its peers=2C it may use local audio level= s > > to determine if its media stream is to be sent or not. Thus the amount > > of bit-rate and screen estate needed to display will rapidly change as > > different users speaks. Thus the need for minimal delay when changing > > preferences are important. > > > > 3) We also have speech and audio including audio-only use cases. For > > audio there could also exist desire to request or indicate changes in > > the audio bandwidth required=2C or usage of multi-channel. > > > > 4) Adaptation to legacy node from a central node in a multi-party > > conference. In some use cases legacy nodes might have special needs tha= t > > are within the profiles a WebRTC end-point is capable of producing. Thu= s > > the central node might request the nodes to constrain themselves to > > particular payload types=2C audio bandwidth etc to meet a joining sessi= on > > participant. > > > > 5) There appear to exist a need for expressing dynamic requests for > > target bit-rate as one parameter. This can be supported by TMMBR > > (RFC5104) but there exist additional transport related parameters could > > help with the adaptation. These include MTU=2C limits on packet rate=2C= and > > amount of aggregation of audio frames in the payload. > > > > Overview > > -------- > > > > The basic idea in this proposal is to use JSEP to establish the outer > > limits for behavior and then use Codec Operation Point (COP) proposal a= s > > detailed in draft-westerlund-avtext-codec-operation-point to handle > > dynamic changes during the session. > > > > So highest resolution=2C frame-rate and maximum complexity are expresse= d > > in JSEP SDP. Complexity is in several video codecs expressed by profile > > and level. I know that VP8 currently doesn't have this but it is under > > discussion when it comes to these parameters. > > > > During the session the browser implementation detects when there is nee= d > > to use COP to do any of the following things. > > > > A) Request new target values for codec operation=2C for example due to > > that the GUI element displaying a video has changed due to window resiz= e. > > > > B) Indicate when the end-point in its role as sender change parameters. > > > > In addition to just spatial resolution and video frame rate=2C I propos= e > > that the following parameters are considered as parameters that could b= e > > dynamically possible to indicate and request. > > > > Spatial resolution (as x and y resolution)=2C Frame-rate=2C Picture Asp= ect > > ratio=2C Sample Aspect Ratio=2C Payload Type=2C Bit-rate=2C Token Bucke= t Size > > (To control burstiness of sender)=2C Channels=2C Sampling Rate=2C Maxim= um RTP > > Packet Size=2C Maximum RTP Packet Rate=2C and Application Data Unit > > Aggregation (to control amount of audio frames in the same RTP packet). > > > > > > Differences > > ----------- > > > > A) Using COP and using SDP based signaling for the dynamic changes are > > two quite different models in relation to how the interaction happens. > > > > For COP this all happens in the browser=2C normally initiated by the > > browser's own determination that a COP request or notification is > > needed. Harald's proposal appears to require that the JS initiate a > > renegotiation. This puts a requirement on the implementation to listen > > to the correct callbacks to know when changes happens=2C such as window > > resize. To my knowledge there are not yet any proposals for how the > > browser can initiate a JSEP renegotiation. > > > > Thus COP has the advantage that there is no API changes to get browser > > triggered parameter changes. W3C can select too but are not required to > > add API methods to allow JS to make codec parameter requests. > > > > The next thing is that COP does not require the JS application to have > > code to detect and handle re-negotiation. This makes it simpler for the > > basic application to get good behavior and they are not interrupted nor > > do they need to handle JSEP& Offer/Answer state machine lock-out > > effects due to dynamic changes. > > > > How big impact these API issues have are unclear as W3C currently appea= r > > not to have included any discussion of how the browser can initiate a > > offer/answer exchange towards the JS when it determines a need to chang= e > > parameters. > > > > But I am worried that using SDP and with an API that requires the > > application to listen for triggers that could benefit from a codec > > parameter renegotiation. This will likely only result in good behavior > > for the JS application implementors that are really good and find out > > what listeners and what signaling tricks are needed with JSEP to get > > good performance. I would much rather prefer good behavior by default i= n > > simple applications=2C i.e. using the default behavior that the browser > > implementor have put in. > > > > B) Using the media plane=2C i.e. RTCP for this signaling lets it in mos= t > > case go directly between the encoding and the decoding entity in the > > code. There is no need to involve the JS nor the signaling server. One > > issue of using JSEP and SDP is that the state machine lock-out effects > > that can occur if one has sent an Offer. Then that browser may not be > > able to send a new updated Offer reflecting the latest change until the > > answer has been properly processed. COP doesn't have these limitations. > > It can send a new parameter request immediately=2C only limited by RTCP > > bandwidth restrictions. Using the media plane in my view guarantees tha= t > > COP is never worse than what the signaling plane can perform at its bes= t. > > > > C) As the general restrictions are determined in the initial > > negotiation=2C COP doesn't have the issue that in-flight media streams = can > > become out of bounds. Thus no need for a two phase change of signaling > > parameters. > > > > D) Relying on draft-lennox-mmusic-sdp-source-selection-04 has several > > additional implications that should be discussed separately. The draft > > currently includes the following functionalities. > > > > D1) It contains a media stream pause proposal. This makes it subject > > to the architectural debate currently ongoing in dispatch around > > draft-westerlund-avtext-rtp-stream-pause-00 which is a competing > > proposal for the same functionality. > > > > D2) The inclusion of max desired frame rate in a SSRC specific way > > > > D3) Extending the image attribute to be per SSRC specific expression > > of desired resolutions. > > > > D4) Expressing relative priority in receiving different SSRCs. > > > > D5) Providing an "information" on a sent SSRC > > > > D6) Indication if the media sender is actively sending media using t= he > > given SSRC. > > > > Is it a correct observation that only D2 and D3 are required for the > > functionality of Resolution negotiation? > > > > E) The standardization situation is similar for both proposals. They ar= e > > both relying on Internet drafts that are currently individual > > submissions. Both are partially caught in the architectural discussion > > which was held in Paris in the DISPATCH WG around Media pause/resume > > (draft-westerlund-avtext-rtp-stream-pause-00) and Media Stream Selectio= n > > (draft-westerlund-dispatch-stream-selection-00) on what the most > > appropriate level of discussion are. This discussion will continue on > > the RAI-Area mailing list. > > > > F) As seen by the discussion on the mailing list the imageattr > > definitions may not be a 100% match to what is desired with Harald's > > proposal. I believe that COP's are more appropriate especially the > > "target" values possibility. In addition these are still open for > > adjustment and if they don't match WebRTC's requirements. > > > > I would also like to point out that I believe this functionality is als= o > > highly desirable for CLUE and that their requirements should be taken > > into account. I do think that this is one of the aspects where having > > matching functionality will make it much easier to have WebRTC to CLUE > > interworking. > > > > Thanks for reading all the way here! > > > > 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 > > ---------------------------------------------------------------------- > > > > > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_788a7258-0d1c-4de8-89f5-7844106da596_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Magnus' proposal for only using SDP to set the limits of behavior makes
= sense to me. =3B Clearly SDP is not potentially viable for rapid adjust= ment.

The question is really about what information it is useful
= for a receiver or sender to provide. =3B For example=2C I would questio= n
whether an SVC sender necessarily needs to send a message saying
= it is adjusting its sending rate=2C assuming that the new rate is within the range negotiated. =3B

In any case=2C this really is not a= n RTCWEB-specific problem=2C and comimg
up with different solutions in d= ifferent IETF WGs seems highly undesirable.




>=3B = >=3B This is posted as individual. When it comes to this topic I will not=
>=3B >=3B engage in any chair activities because I do have an alter= native proposal
>=3B >=3B based on
>=3B >=3B https://datatrac= ker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/.
>=3B = >=3B
>=3B >=3B
>=3B >=3B My proposal has some significant d= ifferences in how it works compared to
>=3B >=3B Harald's. I will st= art with a discussion of requirements=2C in addition to
>=3B >=3B Ha= rald's=2C then an overview of my proposal=2C and ending with a discussion>=3B >=3B of the differences between the proposals. This is quite lon= g but I do
>=3B >=3B hope you will read it to the end.
>=3B >= =3B
>=3B >=3B Requirements
>=3B >=3B ------------
>=3B &= gt=3B
>=3B >=3B Let's start with the requirements that Harald have w= ritten. I think they
>=3B >=3B should be formulated differently. Fir= st of all I think the requirements
>=3B >=3B are negotiated=2C indic= ated etc in the context of a peer connection.
>=3B >=3B
>=3B &g= t=3B Secondly=2C when it comes to maximum resolution and maximum frame-rate= =2C
>=3B >=3B there are actually three different limits that I think= are important=3B
>=3B >=3B Highest spatial resolution=2C highest fr= ame-rate=2C and maximum complexity
>=3B >=3B for a given video strea= m. The maximum complexity is often expressed as
>=3B >=3B the number= of macroblocks a video codec can process per second. This is
>=3B >= =3B a well-established complexity measure=2C used as part of standardized>=3B >=3B video codec's "level" definitions since the introduction of= H.263 Annex
>=3B >=3B X in 2004. As this is basically a joint maxim= um requirement on the
>=3B >=3B maximum amount of pixels per frame t= imes the maximum frame-rate=2C there
>=3B >=3B exist cases where thi= s complexity figure actually is the constraining
>=3B >=3B factor fo= rcing a sender or receiver to either request higher frame rate
>=3B &g= t=3B and lower resolution or higher resolution and a lower frame rate.
&= gt=3B >=3B
>=3B >=3B The requirements should also be clearer in th= at one needs to handle
>=3B >=3B multiple SSRCs per RTP session=2C i= ncluding multiple cameras or audio
>=3B >=3B streams (microphones) f= rom a single end-point=2C where each stream can be
>=3B >=3B encoded= using different parameter values.
>=3B >=3B
>=3B >=3B I also= think it is important that we consider what additional encoding
>=3B = >=3B property parameters that would make sense for WebRTC to have a
&g= t=3B >=3B possibility to dynamically negotiate=2C request and indicate.>=3B >=3B
>=3B >=3B Some additional use cases that should be c= onsidered in the requirements:
>=3B >=3B
>=3B >=3B 1) We have= use cases including multi-party communication. One way to
>=3B >=3B= realize these is to use a central node and I believe everyone agrees
&g= t=3B >=3B that we should have good support for getting this usage to work= well.
>=3B >=3B Thus in a basic star topology of different particip= ants there is going
>=3B >=3B to be different path characteristics b= etween the central node and each
>=3B >=3B participant.
>=3B &g= t=3B
>=3B >=3B 1A) This makes it necessary to consider how one can e= nsure that the
>=3B >=3B central node can deliver appropriate rates.= One way is to de-couple the
>=3B >=3B links by having the central n= ode perform individual transcodings to
>=3B >=3B every participant. = A simpler non-transcoding central node=2C only
>=3B >=3B forwarding = streams between end-points=2C would have to enforce the lowest
>=3B &g= t=3B path characteristics to all. If one don't want to transcode at the
= >=3B >=3B central node and not use the lowest path characteristics to a= ll=2C one
>=3B >=3B need to consider either simulcast or scalable vi= deo coding. Both
>=3B >=3B simulcast and scalable video coding resul= t in that at least in the
>=3B >=3B direction from a participant to = the central node one needs to use
>=3B >=3B multiple codec operation= points. Either one per peer connection=2C which
>=3B >=3B is how I = see simulcast being realized with today's API and
>=3B >=3B function= ality=2C or using an encoding format supporting scalable coding
>=3B &= gt=3B within a single peer connection.
>=3B >=3B
>=3B >=3B 1B= ) In cases where the central node has minimal functionality and
>=3B &= gt=3B basically is a relay and an ICE plus DTLS-SRTP termination point (I>=3B >=3B assume EKT to avoid having to do re-encryption)=2C there is= a need to be
>=3B >=3B able to handle sources from different partic= ipants. This puts extra
>=3B >=3B requirements on how to successfull= y negotiate the parameters. For
>=3B >=3B example changing the value= s for one media source should not force one to
>=3B >=3B renegotiate= with everyone.
>=3B >=3B
>=3B >=3B 2) The non-centralized mu= ltiparty use case appears to equally or more
>=3B >=3B stress the ne= ed for having timely dynamic control. If each sender has a
>=3B >=3B= number of peer-connections to its peers=2C it may use local audio levels>=3B >=3B to determine if its media stream is to be sent or not. Thus= the amount
>=3B >=3B of bit-rate and screen estate needed to displa= y will rapidly change as
>=3B >=3B different users speaks. Thus the = need for minimal delay when changing
>=3B >=3B preferences are impor= tant.
>=3B >=3B
>=3B >=3B 3) We also have speech and audio in= cluding audio-only use cases. For
>=3B >=3B audio there could also e= xist desire to request or indicate changes in
>=3B >=3B the audio ba= ndwidth required=2C or usage of multi-channel.
>=3B >=3B
>=3B &= gt=3B 4) Adaptation to legacy node from a central node in a multi-party
= >=3B >=3B conference. In some use cases legacy nodes might have special= needs that
>=3B >=3B are within the profiles a WebRTC end-point is = capable of producing. Thus
>=3B >=3B the central node might request = the nodes to constrain themselves to
>=3B >=3B particular payload ty= pes=2C audio bandwidth etc to meet a joining session
>=3B >=3B parti= cipant.
>=3B >=3B
>=3B >=3B 5) There appear to exist a need f= or expressing dynamic requests for
>=3B >=3B target bit-rate as one = parameter. This can be supported by TMMBR
>=3B >=3B (RFC5104) but th= ere exist additional transport related parameters could
>=3B >=3B he= lp with the adaptation. These include MTU=2C limits on packet rate=2C and>=3B >=3B amount of aggregation of audio frames in the payload.
&g= t=3B >=3B
>=3B >=3B Overview
>=3B >=3B --------
>=3B &= gt=3B
>=3B >=3B The basic idea in this proposal is to use JSEP to es= tablish the outer
>=3B >=3B limits for behavior and then use Codec O= peration Point (COP) proposal as
>=3B >=3B detailed in draft-westerl= und-avtext-codec-operation-point to handle
>=3B >=3B dynamic changes= during the session.
>=3B >=3B
>=3B >=3B So highest resolutio= n=2C frame-rate and maximum complexity are expressed
>=3B >=3B in JS= EP SDP. Complexity is in several video codecs expressed by profile
>= =3B >=3B and level. I know that VP8 currently doesn't have this but it is= under
>=3B >=3B discussion when it comes to these parameters.
&g= t=3B >=3B
>=3B >=3B During the session the browser implementation = detects when there is need
>=3B >=3B to use COP to do any of the fol= lowing things.
>=3B >=3B
>=3B >=3B A) Request new target valu= es for codec operation=2C for example due to
>=3B >=3B that the GUI = element displaying a video has changed due to window resize.
>=3B >= =3B
>=3B >=3B B) Indicate when the end-point in its role as sender c= hange parameters.
>=3B >=3B
>=3B >=3B In addition to just spa= tial resolution and video frame rate=2C I propose
>=3B >=3B that the= following parameters are considered as parameters that could be
>=3B = >=3B dynamically possible to indicate and request.
>=3B >=3B
&g= t=3B >=3B Spatial resolution (as x and y resolution)=2C Frame-rate=2C Pic= ture Aspect
>=3B >=3B ratio=2C Sample Aspect Ratio=2C Payload Type= =2C Bit-rate=2C Token Bucket Size
>=3B >=3B (To control burstiness o= f sender)=2C Channels=2C Sampling Rate=2C Maximum RTP
>=3B >=3B Pack= et Size=2C Maximum RTP Packet Rate=2C and Application Data Unit
>=3B &= gt=3B Aggregation (to control amount of audio frames in the same RTP packet= ).
>=3B >=3B
>=3B >=3B
>=3B >=3B Differences
>=3B= >=3B -----------
>=3B >=3B
>=3B >=3B A) Using COP and usin= g SDP based signaling for the dynamic changes are
>=3B >=3B two quit= e different models in relation to how the interaction happens.
>=3B &g= t=3B
>=3B >=3B For COP this all happens in the browser=2C normally i= nitiated by the
>=3B >=3B browser's own determination that a COP req= uest or notification is
>=3B >=3B needed. Harald's proposal appears = to require that the JS initiate a
>=3B >=3B renegotiation. This puts= a requirement on the implementation to listen
>=3B >=3B to the corr= ect callbacks to know when changes happens=2C such as window
>=3B >= =3B resize. To my knowledge there are not yet any proposals for how the
= >=3B >=3B browser can initiate a JSEP renegotiation.
>=3B >=3B>=3B >=3B Thus COP has the advantage that there is no API changes to = get browser
>=3B >=3B triggered parameter changes. W3C can select to= o but are not required to
>=3B >=3B add API methods to allow JS to m= ake codec parameter requests.
>=3B >=3B
>=3B >=3B The next th= ing is that COP does not require the JS application to have
>=3B >= =3B code to detect and handle re-negotiation. This makes it simpler for the=
>=3B >=3B basic application to get good behavior and they are not i= nterrupted nor
>=3B >=3B do they need to handle JSEP&=3B Offer/A= nswer state machine lock-out
>=3B >=3B effects due to dynamic change= s.
>=3B >=3B
>=3B >=3B How big impact these API issues have a= re unclear as W3C currently appear
>=3B >=3B not to have included an= y discussion of how the browser can initiate a
>=3B >=3B offer/answe= r exchange towards the JS when it determines a need to change
>=3B >= =3B parameters.
>=3B >=3B
>=3B >=3B But I am worried that usi= ng SDP and with an API that requires the
>=3B >=3B application to li= sten for triggers that could benefit from a codec
>=3B >=3B paramete= r renegotiation. This will likely only result in good behavior
>=3B &g= t=3B for the JS application implementors that are really good and find out<= br>>=3B >=3B what listeners and what signaling tricks are needed with J= SEP to get
>=3B >=3B good performance. I would much rather prefer go= od behavior by default in
>=3B >=3B simple applications=2C i.e. usin= g the default behavior that the browser
>=3B >=3B implementor have p= ut in.
>=3B >=3B
>=3B >=3B B) Using the media plane=2C i.e. R= TCP for this signaling lets it in most
>=3B >=3B case go directly be= tween the encoding and the decoding entity in the
>=3B >=3B code. Th= ere is no need to involve the JS nor the signaling server. One
>=3B &g= t=3B issue of using JSEP and SDP is that the state machine lock-out effects=
>=3B >=3B that can occur if one has sent an Offer. Then that browse= r may not be
>=3B >=3B able to send a new updated Offer reflecting t= he latest change until the
>=3B >=3B answer has been properly proces= sed. COP doesn't have these limitations.
>=3B >=3B It can send a new= parameter request immediately=2C only limited by RTCP
>=3B >=3B ban= dwidth restrictions. Using the media plane in my view guarantees that
&g= t=3B >=3B COP is never worse than what the signaling plane can perform at= its best.
>=3B >=3B
>=3B >=3B C) As the general restrictions= are determined in the initial
>=3B >=3B negotiation=2C COP doesn't = have the issue that in-flight media streams can
>=3B >=3B become out= of bounds. Thus no need for a two phase change of signaling
>=3B >= =3B parameters.
>=3B >=3B
>=3B >=3B D) Relying on draft-lenno= x-mmusic-sdp-source-selection-04 has several
>=3B >=3B additional im= plications that should be discussed separately. The draft
>=3B >=3B = currently includes the following functionalities.
>=3B >=3B
>= =3B >=3B D1) It contains a media stream pause proposal. This makes it = subject
>=3B >=3B to the architectural debate currently ongoing in d= ispatch around
>=3B >=3B draft-westerlund-avtext-rtp-stream-pause-00= which is a competing
>=3B >=3B proposal for the same functionality.=
>=3B >=3B
>=3B >=3B D2) The inclusion of max desired fram= e rate in a SSRC specific way
>=3B >=3B
>=3B >=3B D3) Exte= nding the image attribute to be per SSRC specific expression
>=3B >= =3B of desired resolutions.
>=3B >=3B
>=3B >=3B D4) Expres= sing relative priority in receiving different SSRCs.
>=3B >=3B
&g= t=3B >=3B D5) Providing an "information" on a sent SSRC
>=3B >= =3B
>=3B >=3B D6) Indication if the media sender is actively send= ing media using the
>=3B >=3B given SSRC.
>=3B >=3B
>=3B= >=3B Is it a correct observation that only D2 and D3 are required for th= e
>=3B >=3B functionality of Resolution negotiation?
>=3B >= =3B
>=3B >=3B E) The standardization situation is similar for both p= roposals. They are
>=3B >=3B both relying on Internet drafts that ar= e currently individual
>=3B >=3B submissions. Both are partially cau= ght in the architectural discussion
>=3B >=3B which was held in Pari= s in the DISPATCH WG around Media pause/resume
>=3B >=3B (draft-west= erlund-avtext-rtp-stream-pause-00) and Media Stream Selection
>=3B >= =3B (draft-westerlund-dispatch-stream-selection-00) on what the most
>= =3B >=3B appropriate level of discussion are. This discussion will contin= ue on
>=3B >=3B the RAI-Area mailing list.
>=3B >=3B
>= =3B >=3B F) As seen by the discussion on the mailing list the imageattr>=3B >=3B definitions may not be a 100% match to what is desired with= Harald's
>=3B >=3B proposal. I believe that COP's are more appropri= ate especially the
>=3B >=3B "target" values possibility. In additio= n these are still open for
>=3B >=3B adjustment and if they don't ma= tch WebRTC's requirements.
>=3B >=3B
>=3B >=3B I would also l= ike to point out that I believe this functionality is also
>=3B >=3B= highly desirable for CLUE and that their requirements should be taken
&= gt=3B >=3B into account. I do think that this is one of the aspects where= having
>=3B >=3B matching functionality will make it much easier to= have WebRTC to CLUE
>=3B >=3B interworking.
>=3B >=3B
>= =3B >=3B Thanks for reading all the way here!
>=3B >=3B
>=3B = >=3B Cheers
>=3B >=3B
>=3B >=3B Magnus Westerlund
>=3B= >=3B
>=3B >=3B --------------------------------------------------= --------------------
>=3B >=3B Multimedia Technologies=2C Ericsson R= esearch EAB/TVM
>=3B >=3B ------------------------------------------= ----------------------------
>=3B >=3B Ericsson AB | = Phone +46 10 7148287
>=3B >=3B F=E4r=F6gatan 6 | Mob= ile +46 73 0949079
>=3B >=3B SE-164 80 Stockholm=2C Sweden| mailto: = magnus.westerlund@ericsson.com
>=3B >=3B ---------------------------= -------------------------------------------
>=3B >=3B
>=3B >= =3B
>=3B >=3B
>=3B
>=3B _________________________________= ______________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
&= gt=3B https://www.ietf.org/mailman/listinfo/rtcweb
= --_788a7258-0d1c-4de8-89f5-7844106da596_-- From harald@alvestrand.no Tue Apr 24 13:05: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 35A1C21E80AC for ; Tue, 24 Apr 2012 13:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.178 X-Spam-Level: X-Spam-Status: No, score=-110.178 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, 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 3SLe0BM7a0kS for ; Tue, 24 Apr 2012 13:05:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8CF21E8050 for ; Tue, 24 Apr 2012 13:05:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5F3039E0CD for ; Tue, 24 Apr 2012 22:05: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 ujBilKpi75QW for ; Tue, 24 Apr 2012 22:05:17 +0200 (CEST) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0A80C39E089 for ; Tue, 24 Apr 2012 22:05:17 +0200 (CEST) Message-ID: <4F97077C.6040302@alvestrand.no> Date: Tue, 24 Apr 2012 22:05:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F869648.2020605@alvestrand.no> <4F96B7C9.1030609@ericsson.com>, <4F96D83F.8020705@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010501090006060309080305" Subject: Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) 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 Apr 2012 20:05:20 -0000 This is a multi-part message in MIME format. --------------010501090006060309080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/24/2012 08:13 PM, Bernard Aboba wrote: > Magnus' proposal for only using SDP to set the limits of behavior makes > sense to me. Clearly SDP is not potentially viable for rapid adjustment. I would make that "potentially not viable" - if the RTT between clients and server is very low, and the server processing time is very short, there can be scenarios where sub-500-ms renegotiates are reasonable to expect even with server-mediated renegotiation, and there's always the potential of SDP exchange over a data channel, once that's commonly implemented. But it will be trivially easy for something to get implemented in a nonoptimal fashion, and for this to take quite a bit longer. > > The question is really about what information it is useful > for a receiver or sender to provide. For example, I would question > whether an SVC sender necessarily needs to send a message saying > it is adjusting its sending rate, assuming that the new rate is within > the range negotiated. > > In any case, this really is not an RTCWEB-specific problem, and comimg > up with different solutions in different IETF WGs seems highly > undesirable. I would love to not invent mechanisms. All the mechanisms so far suggested have been previously proposed elsewhere, but only the m-line-level a=imageattr spec (RFC 6236) has been published as a standars-track RFC. --------------010501090006060309080305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/24/2012 08:13 PM, Bernard Aboba wrote:
Magnus' proposal for only using SDP to set the limits of behavior makes
sense to me.  Clearly SDP is not potentially viable for rapid adjustment.
I would make that "potentially not viable" - if the RTT between clients and server is very low, and the server processing time is very short, there can be scenarios where sub-500-ms renegotiates are reasonable to expect even with server-mediated renegotiation, and there's always the potential of SDP exchange over a data channel, once that's commonly implemented. But it will be trivially easy for something to get implemented in a nonoptimal fashion, and for this to take quite a bit longer.

The question is really about what information it is useful
for a receiver or sender to provide.  For example, I would question
whether an SVC sender necessarily needs to send a message saying
it is adjusting its sending rate, assuming that the new rate is within
the range negotiated. 

In any case, this really is not an RTCWEB-specific problem, and comimg
up with different solutions in different IETF WGs seems highly undesirable.
I would love to not invent mechanisms. All the mechanisms so far suggested have been previously proposed elsewhere, but only the m-line-level a=imageattr spec (RFC 6236) has been published as a standars-track RFC.

--------------010501090006060309080305-- From juberti@google.com Tue Apr 24 20:20: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 A03FF21E8026 for ; Tue, 24 Apr 2012 20:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.037 X-Spam-Level: X-Spam-Status: No, score=-102.037 tagged_above=-999 required=5 tests=[AWL=0.939, 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 HuLz0G+iF9j3 for ; Tue, 24 Apr 2012 20:20:42 -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 30A7C21E8024 for ; Tue, 24 Apr 2012 20:20:41 -0700 (PDT) Received: by qaea16 with SMTP id a16so547821qae.10 for ; Tue, 24 Apr 2012 20:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=iHWd/+ObhokveWgDZDyHyCtxHuY3RgfVb2O6J04z1iE=; b=QRJkCiT/jdjylfViYyucG2lYy73flvlCG2EP/PIuDsNcvNJ+IPlHUEVTM7ZAdQ2uf2 SYTONyr4/uNThnyyIRCw7bc7Y20DKjViheiH35fRd/8ilYhAqiq1Wou2TWe0S5T8LqQs 7hn8wZfLGjTaABt9PBzWqxeRjP8hCAXFSRovSqNG+ucNkAp3HGp+TvvGq3p0QvdgL5aQ 6MZ/cxTiEsF1/3/YHbqbFDDz0HrY0nCzd/hFbVfuweGQRnvzV56ZmZHg6v1CI5T8XBz1 drUrgW9yufrOVnGM9zXN7ksWbdPbu8p3lwzij5n/xi5RHlawjHuYkS4+p/VxdXwAjV36 PjRA== 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=iHWd/+ObhokveWgDZDyHyCtxHuY3RgfVb2O6J04z1iE=; b=Te+ODL6ifqiSXpTc/3dqbSCTYTaLocdeJGY9OODTePXiN2WavvA7cGA7DpIuDeAJKW wn98z0F40qj8N2Q0jzfbd4H4d8/2IuZEB3v3DZsFVK1HQvwZ9EHULC2MMzPqW2UxkEcP 1YMdyr+Y4obcC22yBYjAmZ1jb7tmFsZTariPdshddxh1U6C3bzE5qiTYPHs224SOLz1J Cv/Ok7SFxy6hlM8lEARBCXcVjc10ItedFidjPWVKzQsGDv114fJFfxU9ACX/Bv3fZV4e HfHPoxWQvLsiMtbhuI5Vo3VyBS2R50nzBM8zZmwBHvrUkXn1XOWxZkQrKKq7nRlSjVjO OKtw== Received: by 10.224.182.75 with SMTP id cb11mr948824qab.26.1335324041395; Tue, 24 Apr 2012 20:20:41 -0700 (PDT) Received: by 10.224.182.75 with SMTP id cb11mr948814qab.26.1335324041170; Tue, 24 Apr 2012 20:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Tue, 24 Apr 2012 20:20:19 -0700 (PDT) In-Reply-To: <4F96B7C9.1030609@ericsson.com> References: <4F869648.2020605@alvestrand.no> <4F96B7C9.1030609@ericsson.com> From: Justin Uberti Date: Tue, 24 Apr 2012 23:20:19 -0400 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf303b42db224db704be785bda X-System-Of-Record: true X-Gm-Message-State: ALoCoQn/1bHkteFghsz0a7RubSw9rhUC+EN5QGl/IGJNYpevBU4AmKYRSAHdH6XxEJMnX/c1SY62YVD6IyXCXX/5L4alAlpflO4euSY6/oVv+FLZErQs2ySD7hSrbJi5FKNF4Kv1pPBh Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) 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 Apr 2012 03:20:44 -0000 --20cf303b42db224db704be785bda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 24, 2012 at 10:25 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > > Harald, WG, > > This is posted as individual. When it comes to this topic I will not > engage in any chair activities because I do have an alternative proposal > based on > > https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-= point/ > . > > > My proposal has some significant differences in how it works compared to > Harald's. I will start with a discussion of requirements, in addition to > Harald's, then an overview of my proposal, and ending with a discussion > of the differences between the proposals. This is quite long but I do > hope you will read it to the end. > > Requirements > ------------ > > Let's start with the requirements that Harald have written. I think they > should be formulated differently. First of all I think the requirements > are negotiated, indicated etc in the context of a peer connection. > > Secondly, when it comes to maximum resolution and maximum frame-rate, > there are actually three different limits that I think are important; > Highest spatial resolution, highest frame-rate, and maximum complexity > for a given video stream. The maximum complexity is often expressed as > the number of macroblocks a video codec can process per second. This is > a well-established complexity measure, used as part of standardized > video codec's "level" definitions since the introduction of H.263 Annex > X in 2004. As this is basically a joint maximum requirement on the > maximum amount of pixels per frame times the maximum frame-rate, there > exist cases where this complexity figure actually is the constraining > factor forcing a sender or receiver to either request higher frame rate > and lower resolution or higher resolution and a lower frame rate. > > The requirements should also be clearer in that one needs to handle > multiple SSRCs per RTP session, including multiple cameras or audio > streams (microphones) from a single end-point, where each stream can be > encoded using different parameter values. > > I also think it is important that we consider what additional encoding > property parameters that would make sense for WebRTC to have a > possibility to dynamically negotiate, request and indicate. > > Some additional use cases that should be considered in the requirements: > > 1) We have use cases including multi-party communication. One way to > realize these is to use a central node and I believe everyone agrees > that we should have good support for getting this usage to work well. > Thus in a basic star topology of different participants there is going > to be different path characteristics between the central node and each > participant. > > 1A) This makes it necessary to consider how one can ensure that the > central node can deliver appropriate rates. One way is to de-couple the > links by having the central node perform individual transcodings to > every participant. A simpler non-transcoding central node, only > forwarding streams between end-points, would have to enforce the lowest > path characteristics to all. If one don't want to transcode at the > central node and not use the lowest path characteristics to all, one > need to consider either simulcast or scalable video coding. Both > simulcast and scalable video coding result in that at least in the > direction from a participant to the central node one needs to use > multiple codec operation points. Either one per peer connection, which > is how I see simulcast being realized with today's API and > functionality, or using an encoding format supporting scalable coding > within a single peer connection. > > 1B) In cases where the central node has minimal functionality and > basically is a relay and an ICE plus DTLS-SRTP termination point (I > assume EKT to avoid having to do re-encryption), there is a need to be > able to handle sources from different participants. This puts extra > requirements on how to successfully negotiate the parameters. For > example changing the values for one media source should not force one to > renegotiate with everyone. > > 2) The non-centralized multiparty use case appears to equally or more > stress the need for having timely dynamic control. If each sender has a > number of peer-connections to its peers, it may use local audio levels > to determine if its media stream is to be sent or not. Thus the amount > of bit-rate and screen estate needed to display will rapidly change as > different users speaks. Thus the need for minimal delay when changing > preferences are important. > > 3) We also have speech and audio including audio-only use cases. For > audio there could also exist desire to request or indicate changes in > the audio bandwidth required, or usage of multi-channel. > > 4) Adaptation to legacy node from a central node in a multi-party > conference. In some use cases legacy nodes might have special needs that > are within the profiles a WebRTC end-point is capable of producing. Thus > the central node might request the nodes to constrain themselves to > particular payload types, audio bandwidth etc to meet a joining session > participant. > > 5) There appear to exist a need for expressing dynamic requests for > target bit-rate as one parameter. This can be supported by TMMBR > (RFC5104) but there exist additional transport related parameters could > help with the adaptation. These include MTU, limits on packet rate, and > amount of aggregation of audio frames in the payload. > > Overview > -------- > > The basic idea in this proposal is to use JSEP to establish the outer > limits for behavior and then use Codec Operation Point (COP) proposal as > detailed in draft-westerlund-avtext-codec-operation-point to handle > dynamic changes during the session. > > So highest resolution, frame-rate and maximum complexity are expressed > in JSEP SDP. Complexity is in several video codecs expressed by profile > and level. I know that VP8 currently doesn't have this but it is under > discussion when it comes to these parameters. > > During the session the browser implementation detects when there is need > to use COP to do any of the following things. > > A) Request new target values for codec operation, for example due to > that the GUI element displaying a video has changed due to window resize. > > B) Indicate when the end-point in its role as sender change parameters. > > In addition to just spatial resolution and video frame rate, I propose > that the following parameters are considered as parameters that could be > dynamically possible to indicate and request. > > Spatial resolution (as x and y resolution), Frame-rate, Picture Aspect > ratio, Sample Aspect Ratio, Payload Type, Bit-rate, Token Bucket Size > (To control burstiness of sender), Channels, Sampling Rate, Maximum RTP > Packet Size, Maximum RTP Packet Rate, and Application Data Unit > Aggregation (to control amount of audio frames in the same RTP packet). > > > Differences > ----------- > > A) Using COP and using SDP based signaling for the dynamic changes are > two quite different models in relation to how the interaction happens. > > For COP this all happens in the browser, normally initiated by the > browser's own determination that a COP request or notification is > needed. Harald's proposal appears to require that the JS initiate a > renegotiation. This puts a requirement on the implementation to listen > to the correct callbacks to know when changes happens, such as window > resize. To my knowledge there are not yet any proposals for how the > browser can initiate a JSEP renegotiation. > Maybe I misunderstand what you are saying, but the application will definitely know when the browser size changes, and can then trigger a JSEP renegotiation by calling createOffer and shipping it off. I have the opposite concern - how can the browser know when the application makes a change, for instance to display a participant in a large view versus a small view? This may be possible if using a
--20cf303b42db224db704be785bda-- From magnus.westerlund@ericsson.com Wed Apr 25 07:35: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 70EF121F874C for ; Wed, 25 Apr 2012 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.133 X-Spam-Level: X-Spam-Status: No, score=-106.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 trA4-2K0F0NE for ; Wed, 25 Apr 2012 07:35:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5540B21F86C2 for ; Wed, 25 Apr 2012 07:35:41 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-af-4f980bbc1736 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C5.EB.26681.CBB089F4; Wed, 25 Apr 2012 16:35:40 +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.213.0; Wed, 25 Apr 2012 16:35:38 +0200 Message-ID: <4F980BA6.7070405@ericsson.com> Date: Wed, 25 Apr 2012 16:35:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Justin Uberti References: <4F869648.2020605@alvestrand.no> <4F96B7C9.1030609@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) 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 Apr 2012 14:35:42 -0000 On 2012-04-25 05:20, Justin Uberti wrote: > On Tue, Apr 24, 2012 at 10:25 AM, Magnus Westerlund > > > wrote: > > A) Using COP and using SDP based signaling for the dynamic changes are > two quite different models in relation to how the interaction happens. > > For COP this all happens in the browser, normally initiated by the > browser's own determination that a COP request or notification is > needed. Harald's proposal appears to require that the JS initiate a > renegotiation. This puts a requirement on the implementation to listen > to the correct callbacks to know when changes happens, such as window > resize. To my knowledge there are not yet any proposals for how the > browser can initiate a JSEP renegotiation. > > > Maybe I misunderstand what you are saying, but the application will > definitely know when the browser size changes, and can then trigger a > JSEP renegotiation by calling createOffer and shipping it off. Yes, they can but that requires them to write code to do this. With COP the browser can do it and it works well for all applications, not only the ones that have implementors that are aware of the need to do this. I am proposing a mechanism that makes the default behavior if you care nothing about controlling or optimizing this behavior in your JS to be good. In addition JS that wants to control it can affect the behavior through generic mechanisms, such as controlling the video element. And if clear need is shown and some functionality is missing, W3C can create an API to provide explicit control. > > I have the opposite concern - how can the browser know when the > application makes a change, for instance to display a participant in a > large view versus a small view? This may be possible if using a